2014-09-15

学習のためにGithubを徘徊する

ちょっと間が空きましたが前回の補足。

プログラミング初心者が中・上級者になるためには、GithubのリポジトリをWatchすればいいんじゃないかな - iakioの日記

自分で問題を解決しようとするだけだと、自分の発想にとらわれがちなので、他人のコードも参考にした方が良い
だけど、コードを0から読むのは大変なので、興味のあるところからつまみ食いするのが良い
そこで、GithubのPull RequestをWatchするのはどうか。興味の持てそうな話題以外は読み飛ばしても良い（数十件に1つくらいを真面目に見てみるくらいの感覚で良いと思う）

という話でした。

さて実際、僕がGithubを徘徊していてなるほどなと思った体験を1つ挙げてみます。

Gitlistは、PHPで実装されたGitのリポジトリビュワーで、Silexというフレームワークを使って実装されています。SilexはSymfonyのコンポーネントを使った軽量Webフレームワークで、Symfonyの開発者でもあるfabpotことFabien Potencier氏が開発しています。

で、このGitlistを見ていたら、fabpotからのPull Requestがありました。

Refactoring by fabpot · Pull Request #74 · klaussilveira/gitlist · GitHub

例えて言うなら、RailsのアプリケーションをGithubで公開していたらDHHからPull Requestが来たみたいな話です。まさに「Silexを使うならこう使え」と言わんばかりの内容でした。

特に今まで何のためにあるのかわからなかったPimpleのextendメソッドの使い方はなるほどなと思いました、という話は以前にも書いたので詳しくはこちらをご覧ください。

Pimple 2.0がリリースされたのでPimpleについて復習してみる - iakioの日記

さて、そういったことを思い返してみると、人に注目してみるのはGithubを徘徊する1つの方法かもしれません。あのライブラリを書いた作者は他にはどんなものを作っているのだろう。どんな他のプロジェクトに注目しているのだろう、といった具合に。

あるいは、Most active GitHub users (by contributions). http://twitter.com/paulmillrで、お気に入りの言語からアクティブなユーザーを見つけて、そこからたどってみるのも良いかもしれません。

2014-09-03

プログラミング初心者が中・上級者になるためには、GithubのリポジトリをWatchすればいいんじゃないかな

よく、プログラミングを学ぶ方法として「まずは何か作りたいものを見つけて、、、」といったアドバイスを見かける。たしかに何かを作り上げることで学ぶことも多いのだけれど、どちらかというとそれは実装方法よりもデプロイだったりライブラリやツールの使い方といったところの方が大きいように感じる。

一方で、実装方法については、自分で問題を解決しているだけだとどうしても自分の考え方にとらわれてしまう。

プログラミングの上達のためにきっと一番大切なことは環境で、近くに良い師匠がいるのであれば様々な問題の解決方法を学ぶことができるだろう。

そうでない場合は、インターネット上でお手本を見つけるのが良いと思う。

f:id:iakio:20140903122012p:plain

あまり大きすぎず、ある程度活発なお気に入りのプロジェクトをGithubで見つけてWatchする。毎日届くNotificationをざっとで良いので目を通す。最初はほとんど意味がわからないだろうけどかまわない。でも見続けているうちにこんな風に思うかもしれない。

このライブラリ、こんな機能もあったんだ
次のバージョンではこんな機能が入るのか
バグだって指摘されたけどそれバグじゃねーよって言われてる。あ、ドキュメントがわかりづらいということで直すことになったようだ
新機能提案したけどそれこのライブラリでやることじゃねーからって却下されてる
リファクタリングでがっつり行数減ってるけど、なんかあらたなライブラリを導入したんだろうか

といった感じで、理解も深まるし親しみももてるようになる。ある程度の規模の開発のリズムみたいなものも知ることができるだろう。

そして、ある程度の規模のソースコードを読むのは初心者には大変だけれど、Pull Requestだけざっと見て面白そうなとこから読んでいった方が、飽きないし発見も多いんじゃないかな。

プログラミング初心者が中・上級者になるための近道

2014-08-24

#mozaicfm #7 REST を聞いた

#7 REST - mozaic.fm

RESTの引力に惹かれたREST人達を、RESTの伝道師たる@yoheiが粛清する話。だったと思う。

APIバージョニングの話を聞きながら、/api/v1/fooじゃなくいっそ/api/v1.2.*/fooとか/api/>=v1.3.4,<v1.4/fooとかだったらどうなるだろう。とか想像した。APIのセマンティックバージョニング。まあマイナーバージョンは必要無いかな。

とはいえ、もともとはURLの設計としてどうかというよりサーバー側をどう実装するかの話だったので、そういう意味ではほぼ無理ゲーな気がする。たとえバージョンごとに別々のサーバーがあったとしても、最終的には永続化レイヤーが問題になるんだろうなあ。

Goのバージョンの話が出てたけど、最近TypeScriptを勉強していて、あの.d.tsもなかなか大変なことになってるなと思った。

伊勢神宮の話が面白かった。昔（多分十年以上前）、どこかで「工場のようなソフトウェア」という話を読んだのを思い出した。もう元ネタは探し出せなかったけど。

2014-08-03

PHPUnitでGrowl通知する方法を書いた件

PHPUnitの実行結果をGrowlに通知する方法 - Qiita

事の発端は、去年の年末あたりからRails Tutorialをやっていて、GuardのGrowl通知いいなーと思い始めたことだった
PHPUnitの実行にguardやglupを使うという方法もあったけど、ちょっとした用途には大げさかなと思ったのと、その手のやつはPHPUnitの標準出力をパースして結果を取得しているのがイケてないなー、PHPUnitを拡張するような方法でできないだろうかと思っていた
まず最初にPHPUnit_Framework_TestListenerを思いついたけど、これは個々のTestやTestuSuiteに対して呼び出されるのでちょっと頻度が多すぎる。で、次にprinterClassを見つけた
次にどうやってGrowlに通知する方法、gntpnotifyやgntp-sendといったコマンドを実行させるという方法はあまり好きじゃなかったのでGNTPを実装したモジュールを探したけど、イマイチ良いのが無かったので結局自分でGNTPを実装することにしたんだけどインターフェースを決めきれずに数か月放置
なんやかんやでPackagestにも登録して、Qiitaに投稿しようかなと説明を書き始めたところでphar版PHPUnitでテストしてないことに気が付いて、まさにRebuild: 52: TLDR Driven Development (Naoya Ito)でやっていた「先にREADMEを書く」ことの効果を気づかされることになった
書いたコードはわずかでもリリースするところまでやると色々学ぶことがあるなーと思った。PHPUnitを調べたりComposerを調べたり。あとTravisのMatrixを使ってPHPとPHPUnitの複数のバージョンでテストする方法を試せたのが良かった