エンジニアの年収データをスプレッドシートに記入させて集めているようです.
Why not just a simple spreadsheet of salaries? | Hacker News
アンケートフォームから入力すると, スプレッドシートに記入されて公開されます.
このデータはCSV形式で抽出できるのでそれを利用してあれこれやっております.
Data Visualization of Hacker News Salary Spreadsheet — Medium
その結果視覚的にいろいろわかりやすくなって, あきらかにヨーロッパに比べてのシリコンバレーの年収は高いようです.
勤務年数や経験年数は関係なく, 最初から, 2~3倍の年収の違いが見えます.
優秀な人が集ってこうなるのか, お金があるから優秀な人が集まるのか, 都市別.
これだけインターネットが発達してリモートな開発がしやすくなりましたが, ここまで差がでるとな.
まあ, それなりに狭い分母だとは思いますが.
開発中に何十回, 何百回と端末またはエミュレータで動かしてテストしていると思います.
回数が多い分, 数十秒でも大きく生産性に影響します.
Terminal からの選択しながらのビルドや Gradle コンソールで詳細を確認したりする方法は, まあ, あるっちゃああるけどもいちいちそんなの調べてやるのもなんだかめんどくさかったりして.
「ビルド時間の短縮」というようなキーワードでググればまあそれなりに似たような結果がみつかる.
今回, なんとなくいちいちHTMLで結果が出力されるという
「コマンドラインオプションに --profile をつける」
というのをなんとなくやってみたら, Runから実行までの時間が 1分から2秒 になったのでまあ書いてみるが.
とするだけ.
「Run」するたびにHTMLで, build/reports/profile/ 以下 にそれぞれにかかった時間をまとめたHTMLファイルが出力される.
閲覧するには, Run後出力されたHTMLから右クリックでブラウザを起動するといい.
こんなかんじで出力された.
50秒のうち45秒が「Crashlystis」の処理に使われている.
デバッグ時には, このような処理は当然必要ない.
しかも謎なのは Fabric は使っているが Crashlytics は使っていないのだが.
この処理を殺す.
その後結果.
いろいろ謎なことは多いが, オプション「--profile」をつけるだけで一回の「ビルド→実行」時間が数十倍に短縮された.
やみくもにググるよりか, いわゆる「ログ」のような「profile」を見ながらググるほうが効率的.
なぜなら, GUIダイアログから「--profile」と入力しておくだけだもの.
ひとつの部分を変更しようとして, 必死に複数のファイルをいったりきたりしながら更新してみると, 意図しないところが壊れている.
想像してみてください.
マネージャー会社, プログラマー会社, 人事会社, マーケティング会社がある.
プログラマー会社には, マネージャーやマーケティングや人事の人はいなくて, プログラマーしかいない.
いきなり src 直下に「activities」「fragments」「views」ディレクトリを作成してしまうことに似ていません?
「何をするか」ではなく「何であるか」でまとめられたものは, 探そうとすると何度も大きく移動しなければならない.
「会社の業種別」「会社別」のような「何をするか」を優先させたイメージでディレクトリを構成していくと以下のようになります.
良い点
- 高モジュール化.
- 見つけるのが分かりやすい.
- 高レベルな抽象化.
- 機能とレイヤー両方で分けられている
- 構成のメンテがやりやすい.
- 凝縮されている.
- スケール変更しやすい
- 関係ないクラスやファイルを変更するアクシデントが少なくなる.
- 機能の追加や削除がしやすい.
- 再利用しやすい.
Package by features, not layers — The linkedcare Engineering team — Medium
【2015-10-14 公開!!】Google I/O 2015 のソースコードに見るディレクトリ構成
ひとつの考え方として根底にあったほうがよいと思いました.
これに合わせてリソースディレクトリも小分けにできるという話は以下から.
res ディレクトリは小分けにしたほうがいいのではないか