ヽ(´・肉・`)ノログ

How do we fighting without fighting?

Sapporo.jsに参加した

( 道場以外では ) 久しぶりに参加させてもらった気がする.

色々刺激を受けたので今度参加するときは発表して恩返ししたい.

Getting Started with Ember.js

@tricknotes による Ember.js のはじめかた.

「やりたい事書いてくれたら,DOM 操作とか描画はこっち ( フレームワーク ) で何とかするから」というコンセプトは非常に良いなあと感じている.

僕が Ruby を触って最初に「すげえ!」と思ったのは,配列の要素を操作したい場合に for 文を書かなくてよいことだった.

配列の要素を操作したいのだけど,直接はできないから for 文というのを利用してですねえ…… という,コンピューターの事情のために,やりたいことと書かなくてはいけないことのスキマを人間が埋めることに慣れていた.

だけど Ruby の場合,配列の一個ずつを操作するメソッド (each) というものを用意してくれていて, 「僕がやりたいことをそのまま書けるのが ( 僕にとって ) 良いプログラムと考えていいんだな」と教えてもらった.

「ある値を変えたとき,画面の内容を更新するようにしたい」というのをやりたいなと思ったとき, 直接は書けないから,値を変更するイベントをフックして,jQuery で id を元に DOM をとってきてですねえ…… というのでも画面は更新できるけど,やりたいこと以外の細々したことはできるだけ書きたくない.

そういうところをよしなにやってくれる感じを Ruby や から受けたように Ember.js からも受ける.

ポエムになってしまった.あとは実際に触ってみて試してみよう.

ちょっとだけためそうとした形跡があるのでリンクしておく.Ember.js の GUiDE の日本語訳もちょっとだけあるよ.

Concurrent Programming in JavaScript

@y_jono による JavaScript の並行プログラミング技法.

途中から,JavaScript の処理を順番に並べようとして生まれた様々なアイディアたちの紹介になったかもしれない ( 個人の感想です ). 紹介された中には僕が知らない手法もありとてもタメになった.いくつか思いつく感想を書いておく.

連続して重い処理を実行する際,合間に描画させる時間を取らせるために setTimeout を使う技を知らなかったのだけど, 「次の処理がちょっと遅れて始まる」と書いているのに「その間に画面の描画を期待する」のは個人的には変な感じがする. 苦しい中から生まれたバッドノウハウなのだろうか?

Java の GUI アプリケーションには EventDispatchThread (EDT) というのがあって, このスレッドが GUI の表示を変更してくれるので,このスレッドで重い処理を行ってしまうと,画面の描画が止まってしまう. なので,重い処理は別のスレッドを作ってその中で行うことになっている. だけど,複雑な構成になってくると 「今自分が書いているのは EDT で走る処理だったか,それ以外で走る処理だったか?」 と混乱してくることがある.

JavaScript のシングルスレッドかつ非同期処理だと,そういうのに悩まなくてすむところはよい点だと思う.

jQuery の Promise オブジェクトは 「成功,もしくは失敗のどちらかが入っている.どちらかは必ずある.まだ値が決まっていなければ,値が手に入るまで取りに来たやつを待たせる ( ブロックする )」 ようなオブジェクトだと思っているのだけど,認識はあっているのだろうか. Haskell の Either みたいなものを考えている.

Generator の yield は,以前 Ruby の Fiber をいじってみていたので理解しやすかったかもしれない.