https://trello.com をずっと使っているが、段々とボードが増えてきてボード間の移動などがやりにくくなっていた。
項目を増やしたり移動はしなくなったけど、消したくないボードはアーカイブをすればよいらしい。
実験するとアーカイブされたボードの中身も検索対象に含められるようなので読み返すのには困らなさそうだ。
https://trello.com をずっと使っているが、段々とボードが増えてきてボード間の移動などがやりにくくなっていた。
項目を増やしたり移動はしなくなったけど、消したくないボードはアーカイブをすればよいらしい。
実験するとアーカイブされたボードの中身も検索対象に含められるようなので読み返すのには困らなさそうだ。
Rubyの型チェッカーSorbetのドキュメントを読んでいる。今回はrbiファイルの出力機能について。
srb init(2回目以降は srb rbi update)でプロジェクト内のRubyスクリプトを辿ってrbi(RuBy Interface)ファイルを自動生成してくれる。budlerの設定を元に使っているgemのrbiも生成する。
rbiの実態はメソッドの実装の中身が空のRubyスクリプトで、静的チェックやコード補完のときはrbiだけを読み込むことで高速に型チェックできることを期待している。この辺りの思想は他のRuby型チェッカーsteepなどと同じ?ようだ。ただし型定義にはSorbetが独自に定義したsig関数を使っている。
自動生成の場合、rbiには明示的なクラス名やメソッド名は出力されるが、引数や戻り値の型、メタプログラミングで動的に生成されるものは出力されない。もっと詳細なrbiが欲しいときは手動でrbiを書くこともできる。また、gem内にgem作成者が記述したrbiが存在する、GitHubのsorbet-typedレポジトリに対応するrbiが存在する場合はそちらが使われる。
ソースコードに埋め込んだ型アノテーションから型定義ファイルを生成、sobet-typeとflow-typedなど、SorbetはJavaScriptの型チェッカーライブラリflowの影響を受けている印象がある(実際にflowを使っている訳ではないので勘違いかもしれないけど)。flowを調べるとSorbetがどのような着地点を目指しているか分かるかもしれない。
RubyKaigi2019で発表されていたStripeのSorbetというライブラリが楽しみ。
高速に動作することとIDEサポートをコア機能として挙げていることが好印象。静的型チェックはテストと一緒に実行するならある程度時間がかかっても許容できるけど、コード補完はできるだけレスポンスが早い方がよいので。
最近Rubyにこの機能があったらもっと便利になるのになーというものがあって、1つはバイナリgemのビルド無しでRubyで作ったものを簡単に再配布できる機能、もう1つが簡単に導入できて快適に使えるIDEサポートだと思っているのだが、Sorbutないしは他の静的型付け機能で高速なLSPサポートができるようになったら後者は解決するのではないかと期待している。
公開されたらWindowsでビルドできるのかなども含めて色々と触ってみたい。
3つのルールでやっている(これも短文ブログ)。
特にモバイルだと大量のリンクを集めて貼り付ける作業は大変面倒くさい。
また大量のリンクが貼られた記事はモバイルだと読むのも面倒。
しかしリンクが無い記事だとそこで完結してしまい関連した記事を次々に読めるWebのメリットが生かせない。結論としてリンクは1つでよい。
リンクをたくさん貼る代わりにスクショなどを駆使して画像を1枚貼ると分かりやすく文書を少なくできる。
スクリーンショットの保存や切り取り加工、ブログへの画像の投稿機能などはむしろモバイルの方が充実しているので積極的に活用する。
複数のテーマを展開させるとどうしても文書が長くなるので1つの記事のテーマは1つに絞る。
テーマを変えながら関連した話題を続けたい場合は新しい記事を書いてそのURLへのリンクを元記事に貼る。
モバイルで最初から最後まで書けないとどうしても気合いを入れないと書けなくなってしまう。
技術的な話題だと大量のリンクや引用を挟まないと書きにくいものが多いが、どうすればできるようになるかはこのルールに沿いながら模索が必要。
テキストの記述はTextwellのおかげでモバイルでも思い通りに文書が書けるようになった(スライドによるカーソルのスクロールが超便利)。Scrapboxやはてなブログへのエクスポートもアクションを使えば簡単。
私のようなPC大好きっ子でもモバイルの便利さには勝てず記事を読むのにモバイルを使う割合が年々増えている。それに伴いブログを書く時間も著しく減ってしまった。
同じような状況の人は増えているように感じており、商業的な文書ではないのに、ある側面では専門家の人より詳しく書いてあるような面白いブログに出会える機会が減っている(注: 私のブログは昔から駄文です)。これは文書プラットフォームにおける中間層の喪失ではないだろうか。
アウトプットはインプットに比例するため、インプットの中心となるモバイルで書きやすい記事のフォーマットとして、短文ブログというルールを考え中。
テスト駆動開発を読み終わった。評判通りの良い本だった。
ソフトウェアを書くときにテストフレームワークを使ってテストを書くことはやっていたが、きちんとテストファーストで書いたり(実験的にそういうことをやろうとしていた時期はあった)、体系的に学んだことはなかった。内容がテスト駆動開発(TDD)だけにフォーカスしているのもよさそうで手に取った。
まえがきがとてもシンプルにTDDとはなにかに言及しているのがよい(まえがきをペラペラと数ページ読んで購入を決めた)。
- 自動化されたテストが失敗したときのみ、新しいコードを書く。
- 重複を除去する。
これが実践できるようになれば本の重要なことの50%は達成できたといってよい。(しかしそれを現実のソフトウェア開発でやるのが難しい。)
どのように進めればうまくいくのか?以降に実例を挙げて説明されていく。
実際にコードを書きながらコードとTODOリストを育てていく様も見ることができるのが個人的には嬉しかった。(自分はちょっと大きめにTODOのタスクを切り出してしまう癖があることを発見した。)
ネットの情報を漁ると、なぜテストが重要なのか、どのようなツールを使うとテストをかけるのか、といった情報が多い。しかし実際にテスト駆動開発を始めようとすると必要な知識はその先になる。
書籍にはうまくテストを書いていくには何に気をつければよいのかの例がたくさん書いてある。
「フィクスチャー」など専門用語の意味も書籍のお陰で分かった。
あとがきの訳者解説も面白い。
TDD初期から最近までのテストにまつわる歴史や訳者の見解がぎっしり書かれている。
原著は割と古い本なのだがこのあとがきのおかげで最新技術とのギャップを上手く補完してくれている。(とはいえ、原著の内容はほとんど古さを感じることはなく、私自身あとがきを読むまで気がつかなかった。)
個人的には”TDD is dead, Long live testing.”がどのような文脈で出てきた記事なのかが分かったのがよかった。
「教条主義化と意味の希薄化」は技術が盛り上がったときにどこでも起きうる現象なので気をつけたい(いい言葉を知った)。
全体を通して感じたのはTDDとは考えることを少なくするための技術だということだ。
テストを書くときはテストのことだけ、実装のときは実装だけ、リファクタリングのときはリファクタリングだけに集中する。それを繰り返すことで大きなソフトウェアになる。ソフトウェアが大きくなったときにはすでにたくさんのテストコードがあるので安心して修正できるようになっている。
派手な技術ではないが、堅実に長くソフトウェアを作るのに大変役に立つ。
ブログの執筆環境に使っている。
iPadはいつも台座付きでリビングに置いてあるので便利。