読者です 読者をやめる 読者になる 読者になる

リーダブルコード 感想

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

「リーダブルなコードを書こうぜ!」という,
タイトルそのまんまながら,とても大事なことを説いている書籍.

アプリケーションやシステムを開発するお仕事に携わると,
どのような立場でも大なり小なり「コードを読む」という作業が出てくる.
単純にコードレビューやデバッグをすることもあるし,
過去の誰かが残していったコードを設計書無しで改造する場面も出てくる.

そうなると,コードの品質を語る上で
「読みやすさ」という概念が登場するのは自然な流れなわけだけど,
プログラマというか,開発現場全体として,
この「読みやすさ」というのは,軽視されがちにあると思う.

何故そのようになってしまうのか?
どういうコードが「読みにくい」コードなのか?
それらをどのようにすれば,「読みやすい」コードになるのか?
この辺りを整理しているのが,本書.

肝心の中身はというと,正直に言えば
「え?それって当たり前じゃないの?」
という事項が結構並んでいる.
というか,訳者まえがきにもその点は触れられている.

ただし,
「そうか,当たり前か……で,お前はそれをちゃんとやってるの?」
と自分に問いかけてみると,案外やってないものだったりするので,
気づきを与えてくれるという点で,この本自体は決して無駄じゃない.
ここに書いてあることをチェックリスト化して,
日々心がけるようにするだけでも,
コードの読みやすさは断然変わるんじゃないかな.

一方で,読みやすいプログラムというものは
メモリを冗長に使用したり,処理速度という面で劣っていたりするので,
全てのコードに対して適用すれば良い,というわけでもない.
そのあたりはケースバイケースで使い分ける必要がある.


まあ,細かいルールを考えないにしても,
コードを書いている途中で,
「さて,これ本当に読みやすいのかな?」
と立ち止まる癖をつけるだけでも,ずっと変わるんじゃないかな.

Gradle徹底入門 感想

Gradle徹底入門 次世代ビルドツールによる自動化基盤の構築

Gradle徹底入門 次世代ビルドツールによる自動化基盤の構築

Gradleの「グ」の文も理解していなかったので,
Android Studio導入に当たり,どうせならと購読.

「Gradle」とは,AntやMavenのようなビルドツールのこと.
そもそも,「ビルド」の定義自体が,とても曖昧なのだけれど,
本書内では
ソースコードをソフトウェアに変換するまでのプロセス(およびその結果)」
と定めている.
コンパイルとか,テストとか,リリースとか.
そういう作業を自動化してくれるのが,ビルドツール

先に述べたAntとかMavenも非常に強力なビルドツールなのだけれど,
XMLという,本来静的構造を記述するための言語を採用しているので,
細かなビルドを定義するには向いてない.
(出来ないことは無いけれど,手間がかかる)
その点,GradleはGroovyベースのスクリプト言語なので
コーディングライクにビルドを定義できる.

で,本書はそのビルドの入門書.
基本的な操作から,EclipseAndroid StudioといったIDEとの
連携方法についても書いてくれており,
「とりあえずGradle触ってみたい」という人が知りたい情報は
この1冊でほぼ網羅できるようになっていると思う.

また,アーキテクチャレベルの話もある程度は書いてあるので,
Gradleの深いところまで知りたいという人でも,
読んで無駄にはならないんじゃないかな.

MavenやAntが完全に駆逐されるとは思わないけれど,
既にGradleを選択するのが常識になりつつある(気がする)ので,
少しずつでも慣れ親しんでおいた方が良いと思う.


先日GitHubに投げたAndroidアプリも,これ参考にしながら作成しました.

三毛猫ホームズの推理 感想

三毛猫ホームズの推理 (角川文庫 (5680))

三毛猫ホームズの推理 (角川文庫 (5680))

赤川次郎の人気シリーズの第一作目.
調べてみたら,30年近く前からの長寿シリーズとのこと.

ジャンルとしては推理小説
主人公は片山という名の,刑事にも拘わらず血が苦手という変わり者.
その相棒が,タイトルにもなっている雌猫のホームズ.
ホームズはあくまで普通の猫という設定であるが,
まるで全てを見通した上で片山にヒントを伝えているような
振る舞いを示し続け,
そこから片山が謎の解読を進めていく,というのが基本プロット.

赤川次郎の文体は相変わらず軽くて読みやすい.
時代が時代なら,ライトノベル作家になっていたんじゃないかな.
気楽に小説を読みたいときには,うってつけの作家だと思う.

この作品の難点を挙げるなら,最後の展開が唐突というか,
広げた風呂敷を無理やり畳んでそそくさと撤収している感が否めない.
デビュー間もないころの作品ということを考えると,そのあたりは
当時の作者の経験の浅さが出てしまっているのかもしれない.

シリーズとはいえ基本的に順番に読む必要はないはず.
どの本屋にも99%の確率でおいてあるシリーズなので,
興味がある方は,一度手に取って読んでみても良いかもしれない.

Saifu(家計簿アプリ)公開

何とか作り終えたのでコミット.

GitHub - nk5jp/Saifu: 自作の家計簿アプリ

家計簿アプリです.
Androidの4.0系以上なら動くはず.
コントローラやアクティビティの自動テストが無かったり,
一部のテストがあからさまにザルなのは,
飽き……もとい仕様.

■インストール方法
色々試してみたけれど,たぶん以下が一番早い.
(1) 事前にAndroid端末の「本体設定」->「ロックとセキュリティ」にある
  「提供元不明のアプリ」にチェックを入れておく
(2) PCなどで,上記リンクのappフォルダ内にあるapp-release.apkをダウンロードする.
(3) それを添付して,android端末にメール送付する.
(4) Android端末でメールを受け取り,添付ファイルを選択する.
(5) 「インストールしてOK?」と聞かれるので許可する.

■画面説明
アプリを開くとメイン画面の下に4つアイコンがある.左から順に,
(1) カレンダー画面:出費を投入する.過去日/未来日の投入可能.
(2) 予算画面:月々の予算を投入する.予算額と有効/無効の変更もここで.
(3) 振替画面:口座の中のお金を移す.給料など外部からの一方的な振込もここで.
(4) 口座画面:口座を作る.リストの口座を押すと有効/無効の切り替え.

■基本的な運用
(1) とりあえず口座画面で口座(財布も口座の一種という発想)を作る.
(2) 振替画面で,口座(財布)に入っている金額を振り込んでおく.
(3) その月の予算を出費画面で設定する.
(4) 日々の買い物をカレンダー画面から投入していく.

コリジョンルールの勉強

今年のプロ野球界のホットワードな気がするけど,
あまりちゃんと把握していないので,これを機に勉強してみる.

野球をあまり見ない人でも,
スポーツニュース等で「コリジョンルール」という単語を
耳にしたことがあると思う.
これは,今年からNPBで採用されたルールであり,
結構なインパクトのある改正なので,頻繁に議論の的になっている.

コリジョンルールとは,野球規則の6.01(i)のこと.
一応,変更点については以下でアナウンスされている.
http://npb.jp/npb/2016rules.html

まず(1)に,「走者は野手に対して意図的に衝突するな」とある.
要はタックルすんなということ.
阪神マートンをはじめとする外国人に特に多かったタックル行為が,
今年から明確な反則として取り締まられることとなる.

もう1つの(2)は,ボール持ってない捕手はブロックするなということ.
ボールを持つまで,捕手は最低限の進路を,走者に明け渡さないといけない.
ここで言う最低限とは,
「ランナーがスライディングすることでキャッチャーとの接触を避けられる」
レベルと書いてある.要は足1個分ということだろうか.
ただし,送球の乱れ等でやむを得ず進路を防ぐのは許容される.

ちなみに,
「ボール持たずにブロック試みた捕手 VS タックル試みた走者」
では,このルールを読む限り,走者がアウトになるようだ.


ただし,このルールが出来る前から,
ボールを持っていない捕手のブロック禁止については
オブストラクション(走塁妨害)の項で触れられているので,
やはりこのルールの主眼は
(1)の「タックルするな」にあると思って良い.

で,このルールで揉めているのは,主眼じゃない(2)の方.
とにかく,審判側の基準が曖昧すぎるのだ.

特に話題になったのが,4月11日の巨人対阪神戦の3回表.
2アウト2塁からの巨人脇谷のセンター前ヒットにより,
本塁で走者小林と捕手原口のクロスプレーとなった.
一度はアウトの判定が下ったものの,
審判団のビデオ判定の結果,上記の(2)が適用され,セーフに覆った.

コリジョンルールが追加されてから,
コリジョン適用を避けるため,捕手はバックホームをベースの前で受けろ」
としばしば言われており,このケースでは
原口がベースの後ろで捕球およびタッグしたことが
コリジョンの決め手と言われる.

個人的意見としては,このプレーは走者アウトであるべきだと思う
事実として,小林は一切減速することなくホームにスライディングし,
原口もミット以外は接触させることなくタッグを成立させたからだ.
この時点で,コリジョンルールの(2)に書いてある
「最低限の進路は開けろ」
は満たされているはず.
この原口の対応すらNGであれば,
「捕手はバックホームをベースより後ろで受けることを禁ずる」
レベルにした方が,いっそ清々しいし明確だと思う.


コリジョンについては,先行適用したMLBでも色々揉めているようで,
日本側も,そちらと連携しながらルールの明確化を早急に図るべきだと思う.
少なくとも,「点取れた or 取れない」で
これだけ頻繁に試合が止まるのは,興を削ぐという意味で非常によろしくない.

AndroidでStream APIっぽいことをしたい場合

次世代のSDKから,Androidでも
ラムダ式やStream APIなどのJava8相当機能が
使えるようになるそうですね.

First Preview of Android N: Developer APIs & Tools | Android Developers Blog

で,恥ずかしながら,
「そもそも今のAndroid開発環境でも頑張ればStream API使えるよ」
というのを今更ながら知ったので,メモっておく.

Stream APIというのは,Java8から実装された概念で,
荒っぽく言うならば「for文この世から抹消しようぜ」なAPI
リファレンスは下記.

Stream (Java Platform SE 8)

サンプルをそのまま引っ張ってきてみる.

int sum = widgets.stream() //widgetsというコレクションにstream API適用するぜ!という宣言
                 .filter(w -> w.getColor() == RED) //colorプロパティがREDのものでフィルタリング
                 .mapToInt(w -> w.getWeight()) //weightプロパティをコレクション対象に置換
                 .sum(); //その合計値を返却

Java7までならば,for文で手続的に記述されていた箇所が,
Stream APIにより,宣言的に記述できるようになる.

で,これを素直にやろうとすると怒られるんだけど,
どうやら以下の「LightWeight-Stream-API」を使うと
適用できるようになるらしい.というか実際,試したら出来た.

GitHub - aNNiMON/Lightweight-Stream-API: Stream API from Java 8 rewrited on iterators for Java 7 and below

Java8のStream APIで出来ることは大体これで代用できるが,
上記の例で言うところのsumがない.
作者によると
「既存の関数の組み合わせで出来るし.それ実装したら"lightweight"ちゃうやんけ」
とのこと.以下がそのやりとり.

Sum operator is not implemented · Issue #10 · aNNiMON/Lightweight-Stream-API · GitHub

なお,前提としてラムダ式を使っているので,
Retrolambdaなどのプラグインも入れておく必要がある.

GitHub - evant/gradle-retrolambda: A gradle plugin for getting java lambda support in java 6, 7 and android


ひとまずこれでStreamを使いこなす練習をしておこうかと.

CalendarViewとListViewが混在する場合の注意点

件名のシチュエーションで変なバグを踏んだので,備忘録.

今作っているアプリのActivityの仕様の1つが以下の内容.
・カレンダーで日付を選択できる.
・日付を選択すると,その日付に紐づく情報がリスト化されて表示される.
まあ,なんてことはなく,
CalendarViewとListViewの組み合わせで終了させるつもりだった.

実装はサクっと完了して,自動テストも全パス,
バーチャルデバイス上の動きにも特に問題はなかったので,
とりあえず自端末にα版としてリリース.

ここまでは本当に順調だったんだけど,
そのアプリを起動して該当のActivityを開こうとしたところ,
アプリが完全にフリーズしてうんともすんとも言わなくなった.
再現性100%であったため,割とシャレにならない状態.

で,色々ググってたら,
以下のような調査をされている方のサイトに遭遇.
灯火: Android : CalendarView のエラー諸々 (* cannot be cast to android.widget.CalendarView$WeekView とか、ずっと GC が走ってアプリが起動しないとか)

今回のようにClaendarViewとListViewが混在して,
かつCalendarViewの高さにwrap_contentを使っていると,こうなるらしい.
対処方法は,CalendarViewの高さを具体的な数字で指定してやること.

layout.xmlを書き換えて再ビルド&再リリースすると,解決しました.