grunt bower yeoman入門記事 - lxyuma BLOG
※これは、社内の勉強会の資料の下書きです。 ここ数年で、js環境が整理されてきた。 js開発するなら、これらの知識は必須。無いとめっちゃ不便。 という事で、今日は、gruntとbowerとyeomanの話。 各ツール概説 Yeoman applicationのひな形を作る アプリ構築に必要な様々な作業を任せられる Grunt build / preview / testに使う Bower 依存性の管理を行う 手動でDLやscript管理する必要無 rails開発者のために ぶっちゃけ、どれも、railsの環境にそっくり。rails知ってる人は、要するに、以下の事。 grunt => rails server実行時に勝手にやってくれる作業を切り離してカスタマイズできるようにしたもの(coffeeのコンパイルとか) bower => ruby gem管理をjsのclient側で実現した物。 y
普通のrailsアプリのBackboneにMarionette付けて思った事 - lxyuma BLOG
以前書いた記事の反省を元にMarionetteに移行した。 思った以上に快適！ 大規模になったらMarionette.js使えとか書いているのは嘘で、普通にBackbone使うときは、初めから使うべき。 Backboneで一番恐ろしいのは、各現場/各開発者毎に異なるオレオレ実装。オレオレ実装作るコストに加え、使う人の思わぬバグや学習コストやスイッチングコスト等諸々考えると、特別な理由がない限りMarionetteみたいな既存のframework使うべき。 あんど。データバインディングを提供してくれる、stickitと一緒に使うと、より一層効果的。 めっちゃ、ソースコードの量が減って、ソースの意図が明快になった。悩みも少ない。工数も勿論減る。 ここから、幾つか思った事を、サッカー見ながらお酒飲みながら、ダラダラ書く。※ちなみに、日本vsオランダ戦見てる。 railsアプリでのjs周辺の作りの
普通のrailsアプリにbackbone適用して思った事その２ - lxyuma BLOG
普通のrailsアプリにbackbone適用して思った事の続き ６）深い階層のView BackboneのView書いてると、どうしても、親子階層が必要になってくるのは、前回の記事で書いた通り。 で、更に、書いてると、親子の子の中に更に別のViewクラスとか、親子Viewとか埋めたくなってくる。 画面次第なのだが、Viewの作りとして、あるべき構成だし、その方が正しい。のだが、 最終的に、振り返ると、どこにどのViewがあるのか、全体像が掴みにくくなる。 辿るには、親から確認していかないといけない。 うーん。 イマイチである。 こういうの、Marionetteのlayoutあると助かる。 layout/Region見れば、全体像が分かるし、layoutの中にlayout組めるのも、 こういった階層化がよくあるからなのだろう。 ７）誰かと一緒に作業するには、やっぱり、template必要 初
普通のrailsアプリにbackbone適用して思った事 - lxyuma BLOG
普通のrailsのwebアプリにbackboneを埋め込んでみて思った事等を書く。 賛否あるかもだが、あくまで個人的な意見。 １）ウチの現場でBackboneを使うべきか否か？ どこも初めに考える事。 大規模になったら使えとか、Single Page Applicationなら使えとか、色々意見あると思うが、 今時の普通のwebアプリならjsガリガリ動くので、迷わずBackbone使っていいと思う。 ※単調なB向けの基幹システム作ってるとかは例外として。 どこで使う？ 別に全てのpageでBackbone使う必要は無いけど、 フォーム送信系で色々js動かす所とか、検索条件指定、絞り込みとか、 画像/詳細表示、LightBoxとか、 こういう所でjsガリガリ書かないと行けなくなったら Backboneでモジュールを整理していけばいいと思う。 実際使ってみてどうだったか？ before 元々、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
