@kyanny's blog

My thoughts, my life. Views/opinions are my own.

2年遅れの男

興味が出たり、必要になったりして、何かしらの技術を学ぼうとすると、検索してヒットするものがだいたい2年くらい前に書かれていることが多い。自分は2年遅れているということだ。

動きの早いこの世界で2年のビハインドは周回遅れもいいところだが、そのペースで全く通用しないということもないよな、という手応えもある。

2年経ってまだ廃れていないものは十分に枯れていて、ノウハウも出尽くしている。もっと新しい技術が出てきているので今さら誰も話題には挙げないが、残っているだけあってまだまだ現役で通用する。

そういうものを一つずつ着実に自分のものにしていく、というノロマなやり方が、自分には一番合っているようだ。ハイペースでトレンドを追っても、息切れしてリタイアしてしまったら台無しだ。

何かを調べているとき、新しすぎたら「無理してペースをあげすぎていないか?」と振り返ってみる。逆に古すぎたら「学ぶ意欲が落ちていないか?もしくは、もはや選ぶべきではないものを選ぼうとしていないか?」と自問してみる。そういうベンチマーク基準として、「自分は世間から2年遅れ」という認識を持つ。

前にも似たようなことを書いた気がする。大事なことは何度も見ることになる、というのと同じで、大事なことは何度も書くことになる。

Marionette.View の onRender/onShow/onAttach の違い

「ビューが表示されたら DOM について何かする」みたいな処理を、 onRender/onShow どちらのフックに書くのが適切なのか?と疑問に思ったのでチャットルームで質問してみた

onRender と onShow の違いってなんなの?使い分けるべきなの?

https://gitter.im/marionettejs/backbone.marionette?at=55892fa0d682cdb709fc2c9a https://gitter.im/marionettejs/backbone.marionette?at=558931c6de13aa467b1fe48b

onRender はそのビューのテンプレートが HTML 文字列として render されたときに呼ばれる。だから onRender が呼ばれただけでは、そのビューが region の中に表示されているとは限らない。一方 onShow はビューが region の中に表示されたときに呼ばれる。だから onShow が呼ばれただけでは、そのビューの HTML が DOM に attach されているとは限らない。

(後者に想像で補足: どの region にも show されていない LayoutView の中の region に show したら、そういう状況が起こり得る。 Bootstrap modal が消えてる状態で modal の中に show した、とかで発生しそう)

jQuery プラグインを適用したい、みたいなケースでは結局どれを使えばいいの?

http://marionettejs.com/docs/v2.4.2/marionette.view.html#view-attach--onattach-event

View の HTML が DOM に attach された時点で attach イベントが発火する。 onAttach というフックもあるからそれを使うのがおそらくもっとも適切。

最近読んだもの

It’s The Future | The Circle Blog

釣り記事。風刺が効いてて面白かった。


釣り記事のフォローアップぽいが、いまいち主題がよくわからなかった。最初からこちらが本命と狙っていたというよりは、炎上してしまったから書いた、的な印象を持った。

コンテナ技術はアプリケーションのスケーリングという難しい問題を解決しようとしていて、しかも「簡単」に見えるように pretend していない、だから難解なのは仕方ないことだ、的な論調だが、そもそもそういう問題を別に自分で解決しなくていいよという多くの人にも「これが未来だ、古い技術は死んだし未来についてこれなければお前も死ぬ」的な恐怖でもって迫るような風潮はやはり好きになれない(コンテナ技術に限らず)、と思った。


釣り記事のフロントエンド技術バージョン。やはりネタ元のほうがよくできていた。

最近読んだもの

How We Moved Our API From Ruby to Go and Saved Our Sanity

 
Rails や Rack が吸収してくれていた、へんな HTTP リクエストをよしなに扱う部分を一つずつ自前で再実装するくだりが、すげーめんどくさそうだなと思った。相当余裕がある組織じゃないとやっぱり無茶なんだな、ということが伺えた。あと、コメント欄で JRuby の開発者が言ってることも一読に値する。もし自分が将来似た状況に出くわしたら JRuby を試すことを忘れないようにしたい。
 

Launching Today: The Code Climate Platform - Code Climate Blog

CLI が Docker イメージとして配布されている??さっぱり意味がわからないし、 OSX の場合は boot2docker というのを使うとよいとあるのでインストールしてみたけどコマンドを実行してもなんかエラーが出るし、 README にある docker pull をしてもまた違うエラーが出てしまうし、こういうところでももう Docker とそのエコシステムのいろいろなものの使い方がわからないと何もできなくなってしまっているのか、とショックを受けた。その後どうにか docker run で codeclimate help は出るようになったが brew tap でインストールした codeclimate コマンドラインは無反応、使い方も依然としてわからなかった。 boot2docker が何なのかもぼんやりわかった(Docker がインストール済みの VirtualBox イメージ + α)

Universal JavaScript — Medium

JavaScript Weekly Issue 237: June 19, 2015 より。確かに。

Flynn を試した

社内勉強会で「次期ステージングサーバー環境の候補の一つ」と紹介されてから Chrome のタブを固定したままたっぷり一ヶ月以上は経ってしまった。

Installation – Flynn を見ながら MacBook Pro 上に Vagrant で demo 環境を作り、 Using Flynn の example アプリケーションを Flynn 環境上にデプロイして動作確認するところまで。

  • flynn コマンドをインストールせずに demo 環境を立ち上げてしまって少しはまった。単にドキュメントの読み間違い。
  • cert をダウンロードして Add という手順で非常にはまった。 Chrome の下部にでるダウンロード通知領域から cert ファイルをクリックして KeyChain Access.app を起動すると sudo パスワードのダイアログ上に虹色クルクルが出てどうやっても消せなくなり、 Chrome も kill できなくなる。この謎の不安定挙動で三回再起動するハメになった。 Finder からファイルを開いて追加したら無事うまくいった。都度 make destroy && make init && cert 削除・追加をせねばならず面倒だった。
  • 本当に一番上っ面の部分だけ試す分には heroku っぽいが、土台というか Flynn 本体部分の動作の仕組みを全く理解せず使っているのでちょっと何かうまくいかないと全部最初からやり直しになってしまう。 Linux の使い方を勉強していた十数年前と同じような感じ。これもやはり Docker とかそういうのを覚えないと使いこなせないものなのか、とだいぶ落胆した。コンテナ技術、自分が習得して嬉しくなる未来が描けず、あまり興味も持てないのにただ必要にだけはやたらと迫られて嫌な感じだ。というかそもそも仮想化技術から順を追って習得しないと無理だ。

ともあれ一応試してブログに書いたので、これでようやくタブを一つ閉じられた。