関数プログラミング実践入門 - ランレングス復号化を書いてみた
ランレングス圧縮が例題として載っていたので、練習がてら復号化を書いてみることに。
とりあえず書けたのだが。
安全でないreadを使っているのはさておき、なんだろうこの微妙感は。
追記（2016/05/05）：
`let`を活用することで少し読みやすくなった。冗長だった処理もリファクタリング出来た。
Swiftソースのメソッド名とかの数を数えるスクリプト
Rubyの勉強がてら。自分用なので適当。
テスト自動化勉強会のスライド
前に自分で作ったスライドが行方不明になって探してしまったけれど見つかった。
www.slideshare.net
最近、仕事でユニットテストをよく書くようになったり、テスト駆動でやるようになったので、久しぶりに自分で作ったスライドを読んでみた。
発表用スライドとしてはチープさがあって、一般論を多く語っているけれど、それなりに上手くまとまっていると１年前の自分を褒めてやりたいと思った。
一緒に仕事をしているメンバーにもせっかくだし共有してあげようかしら・・・ありがた迷惑かもわからないけど。
iOS8開発テクニック集 Xcode6編を読んだ
Kindleで1コイン以下で購入できたので試しに買って読んでみた。www.amazon.co.jp
いわゆるXcode Tips本なのだけれど、以外と知らないテクニックも多かったので良い買い物だった。
以下、初めて知ったことなど。
Tips.05 途中まで補完する
入力補完においてTabキーで点線の部分までキーワード保管できる。
Tips.09 スコープの可視化
Editor → Code Folding → Focus Follows Selection で。（使う機会は少ないかも）
Tips.13 検索結果を見やすく
Xcode設定 → General → Find Navigator Detail で1件あたりの行数を指定できる。
実際にやってみた感じ、1行にしたほうが視認性がよくて効率良さそう。
Tips.15 ビルドエラーで該当場所を表示
ビルドエラー時に、エラー箇所に自動的に飛ぶというもの。
便利そうなので使ってみたいと思ったのだが、うまく動かなかった・・・。
（Xcode → Behaviors → Edit Behaviors... でそういった設定を全部カスタマイズできるらしい）
Tips.17 Storyboardのプレビュー
言語ごとのプレビューもできるのは初めて知った。
Tips.19 Exitで戻る
Storyboard上の「Exit」使わずに、 `[self.navigationController popViewController]`とかやってた。
Tips.20 FirstResponderを使う
どういったケースで使うと便利なのかイマイチ分かってないけれど、複数ViewControllerで同じ処理を書くときに便利なのかもしれない。
Tips.21 アセットカタログでプレビュー
アセットカタログでもQuickLookが使える。
Tips.22 伸縮自在なイメージ
アセットカタログでのやり方は知っていたけれど、Stretchingでも指定できる。
Tips.24 ブレークポイントでログ出力
Edit Breakpoint... → Actionを「LogMessage」に。@変数名＠で変数内容も表示できる。
普段はNSLogで済ませていたけれど、案外便利かもしれない。（他にも色々出来るみたいだし）
Tips.26 シンボリックブレークポイント
全ViewControllerのviewDidLoadの動きをデバッグしたい、といった時に使える。（ログ出力だけでもOK）
デバッグナビゲータ → Add Symbolic Breakpoint
Tips.28 ウォッチポイント
今まで使っていなかったけれど、変数の変更監視に便利なはず。
Tips.30 もう一度やり直す
一時停止中の現在行のマーカーはドラッグで移動できる。
Tips.33 素早い言語切り替え
シミュレータの設定ではなくて、スキーム設定でも行える。
Tips.34 着信ステータスバー
シミュレータ上で⌘＋Y。
Tips.40 タスクベースドタブ
タブ名はダブルクリックで編集できる！
Project、Storyboard、Edit、Image、Debugみたいな感じで分けると良さげらしい。
1スプリントごとの振り返りで本当に問題は解決するか？
アジャイル開発プロセスの1つ「スクラム」では1スプリント（1イテレーション）ごとの終わりに「振り返り」をやる決まりになっている。
振り返ることは良いことだ。
振り返ることで、チームの生産性（ベロシティ）や結束力・協力性などが向上するだろう。
問題となるのは、プロジェクトが多くのトラブルを抱えているケースである。
例えば、頭でさっと考えるだけで7つも8つも問題が思い浮かぶような状況だった場合、振り返りだけでプロジェクトが抱える多くの問題を（いずれは）解決できるだろうか？
私はそうは思わない。
それは例えるなら、あちこちにガタがきている建物に対して、その場しのぎの補強を繰り返しているようなもので、そこだけピンポイントで解決できたとしても、すぐに新しい場所にガタがくるだろう。
最初にも言ったけれど、振り返り自体はとても良いものだ。それは単なる「問題解決」以上の効果を開発チーム、あるいはプロジェクトにもたらすものだ。
しかし、プロジェクトが多くの問題を抱えすぎている場合は、振り返りだけで解決することを期待しないことだ。現状の問題に対して真摯に向き合い、必要であれば振り返り以外のタイミングでも問題の解決を試みる・・・それが健全なアジャイル開発の姿だと私は思う。
・・・戯言だけれど。
