外出先での作業にモバイルモニターを導入した感想
動機
- ほしかった
- やってみたかった
- 便利そうだった
購入したもの
- 4Kにしなかったのは、使用PCとdpiがズレすぎると文字が小さすぎたり大きすぎたり問題が起きることが多い、という経験則
- 4Kノート＋フルHDモニターを併用したことあると、結構面倒ごとが多かった
- 高dpi制御に対応してないアプリとか、表示崩れがひどい
良かった点
- 広々と使える
- Thunderbolt3対応ならケーブル１本で電力供給とディスプレイ接続が行える
思ってたんと違う点
- 商品画像と比べて、実物はクッソ分厚く見える
- まあ、それ自体はあんまり責めてはいない
実際に使ってみた問題点
GPU負荷が大きい
- 意外な問題点だった
- i7Uの組み込みGPUだとWin+Tabでディスプレイ一覧を見るときとかめっちゃディレイが発生する
消費電力デカイ
- Thinkpad X1 Carbon だと、稼働時間が２～３割減る
- Android Studioを起動してると、２時間程度でバッテリーが枯渇する
- 頑張って3時間弱だろうか
腰にくる
- 500gくらいの重量がある
- 数値としてみるとそうでもないが、リュックで背負うと腰へのダメージがガンガンくる
利用シーン
- 確実に充電ができる箇所
- ちょっと気分転換で外作業したいとき
- 歩き回ることが確定していたり、電源確保が不定のときに使うもんじゃない
全体として
- 腰は大事
突然Google App Engineの特定APIが2回に1回しか繋がらなくなった問題への対処
状況
- GAE/Go 1.12を使っている
- 複数のServiceをデプロイしていて、今回問題になったのは
認証用APIを提供しているService - 環境セットアップのため、APIを連続で叩いてているとき、それはおこった
- 50回くらい同じAPIを叩く
動かなくなる直前
- ナニもしていない。
- 僕はナニもしていない
最後に動いていた時刻
- 18:30頃まで、APIは叩けていた
動かなくなった時刻
- コードを変更せず（リトライの検証のため）再実行すると、2回に1回しかAPIが呼び出せない
- 成功 -> 即座にレスポンスが返る
- 失敗 ->connect timeout.
- 必ず交互に発生する
- 失敗する場合、ログを見る限りサーバーまでリクエストが届いていないようだ
改善した方法
理由の推測
Windows版Android Studioのターミナルでbashする
Windows版のTerminal
- IntelliJやAndroid Studioの標準Terminalはプラットフォームに合わせて起動する
- Windowsはcmd.exeが起動
- bashのほうがなれてて使いやすい
Terminalを変更する
- Settings > Tools > Terminal > Shell Path
- 標準だとcmdになってる
- こんなバッチを書いた（
terminal.cmdとかファイル名で適当な場所に保存）
C:\Users\eaglesakura\tools\git-sdk-installer-1.0.7-64.7z\usr\bin\bash.exe --login -i
Ubuntu環境使えばいいやん？
Mac環境使えばいいやん？
- 16コア32スレッド環境 -> 6コア12スレッド環境へのダウングレードは、通常開発環境として受け入れがたい
- 大型水冷筐体 -> 小型空冷筐体による、騒音問題も受け入れがたい
- iOS/Flutterするときだけ使う
Windows版Android Studioの動作を軽くする
Windows版Android Studioは遅い
- どういうわけかデフォルト設定だと遅い
- CPUスペックとかに関係なく遅そう
- Code Completionが遅い
- LayoutEditorのプレビューが遅い
- そもそも起動が遅い
- どうにか高速化したい
- LinuxとかMacとかでは軽い
原因
- Android Studio 3.5くらいだろうか、いつからだろうか？
- ポップアップでAnti Virusの例外指定しろという通知が出た
- Windows Defencerに例外を追加した
- このへん参考
- その他、ChromeとかShiftとか常駐しているアプリの一部をホワイトリストに加えた
その他
- JVMに食わせるメモリ量を控えた
- RAM容量に対してキャッシュがデカすぎたらしい
org.gradle.jvmargs=-Xmx2g -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8 -Dkotlin.daemon.jvm.options="-Xmx2g"
- Android Emulatorをシャットダウンした
- 外部リソース最高！
- 実機最高！
結果
- 軽い
開発リソースがないなら、Google Playのリリースは取り下げておけ、という経験則
こんな状況は危ない
- 昔は自社でアプリ開発してたけど、もうメンテしなくなって久しい
- とりあえずアップしておいて、使う人がいるならソレでいいや
何が起きるか
- Google Playは年１〜２回くらいはConsoleのアップデートがある
- アップデートにより、一部のアプリは修正が必須となる場合がある
- アプリ内容だけでなく、プライバシーポリシーとかが必須となったり
放置すると何が起きるか
- アプリがBANされる
- BANされるとメールが飛んでくるが、見逃しがち
BANされたものは復帰できるか
- 開発リソースがあるのなら、BAN理由に対して対応を行う
- 基本的にノーコストでBAN解除はしてもらえない
- Google is GOD.
開発リソースがないとどうなるか
- とりあえず放置しがち
BANが増えていくとどうなるか（都市伝説）
- これは都市伝説だが、3BANでGoogle アカウントBANとなる
- 都市伝説だが。
対応コストが高すぎる、サービス終了してアップデートの予定もない
- 仕方ない、
アプリは提供終了しましたというTextViewだけ表示するアプリに上書きアップロードしよう
最悪のパターン
- 署名鍵を紛失し、Cloud Signしてない場合は詰む
そうなる前に
- アプリの継続的アップデートができないと判断したら、さっさとアプリは非公開にしたほうが精神的に良い
- あとから公開に戻せるから
- いままでDLした人は継続的にDLできるから
- もしくは、開発用・個人用のアカウントとGoogle Play Consoleに使うアカウントは完全に別にする
最後に
- グーメン
やっぱ時刻でIDとってるようなのはダメだな
Flutterのプロジェクトが始まったらまずやること
XCodeと仲良くScheme設定
- だいたいProductionとDevelop環境別れてるんだからSchemeを作成する
- SchemeとDebug/Releaseの組み合わせに合わせてConfigurationファイルを作成する
- 何をする用事がなくても、pre buildスクリプトはSchemeごとに設定しておく
build.gradleと仲良くFlavor設定
- まあFlavorわけるよな
- デフォルトで「適当にapplication id設定しとくか」ってやって、本番用に書き換えようとしたら「あのファイルとこのファイルとあのファイルが古いままだよ」ってなるから
- 早めに設定してスッキリしておこう
- まあ、ケツを叩いてさっさと決めてもらおうな、Application ID
.gitignore整理
- お前なんでそんなにすぐ差分発生するんだよ
- XCode お前だよお前
わかる範囲で入れそうなpubspec.yamlに突っ込んでおく
- お前らどうせプラグイン同士で干渉するんだよ、わかってるぞ？
- ほら、patchあててやるから、こっちにおいで
Flutterは
- たのしい
- うれしい
- クロスプラットフォーム
