東京Ruby会議10 3日目の感想メモ
2/11に行われた東京Ruby会議10 3日目に参加しました。話聞きに行っただけですが、参加したっていってもいいんですかね、いいのか。
１月の実施時に雪が振って途中中断になったそうで、仕切り直しのようです。まあそのおかげで私は３日目に参加すべりこめたわけですが。
ぼっちの私がなぜ行ったかというと、本物のハッカーがどういうものか見てみたかったのです。
そして私自身のモチベーションが高まることにつながればいいと思っていました。
本物は凄いですね。あれこそプログラマです。私が普段やってることと比べてしまい、生きる気力を失いそうです。下がってるじゃん。
講演のメモ的なもの。＠は私が思ったこと、のはずだったんですが、ただの愚痴にしか見えなくてつらい。タイトル敬称略です。
自分が実践していなくちゃなーと思ったまとめ
・Webだからといってパラダイスになるわけではないが、プログラミングに対して真剣になれる環境はある。
・コードを書く、勉強会にいく、ブログをいく、とフラグが立つ。
・オープンソースを使うならちゃんとソース読もう。
・joker1007 「Railsエンジニアの日常」
https://speakerdeck.com/joker1007/railsenziniafalseri-chang
システム開発ってなんだろう？
知りたいこと
何をしたい、それによって何がうれしい、登場人物、概念、入力と出力
自分たちがやること
アジャイル開発だからといって、いきなり作り出してもうまくいかない
＠耳が痛い言葉。受託だからだめ、SIerだからだめ、Webだからいい、OSSだからいい、とはなりえないという事実を改めてつきつけられて耳が痛い。
メンタルモデルと実装の一致
＠受託SIerとして共感できる。業務の言葉でそのまま考えたものがソースコードになっていないと、翻訳のような思考が必要になり、凄い疲弊する。
開発スタート
いろいろ自動化
＠手動で資産管理している現場にぶちこまれえいる身としてはうらやましく思う。日付のフォルダ毎日つくて放り込めってな！HAHAHA！
Railsのはなし
まずモデル
名前付け超大事、クラス名、メソッド名、変数→業務領域の言葉を使う
＠ほんとに大事。ただし客先とかでは相応しくない名前でも勝手にリファクタリングできないしストレスと不具合の元。
モデル＝ビジネスロジック
ARに囚われ過ぎない ARパターン
VS FAT MODEL
モジュールを活用
小さなクラス設計 バリューオブジェクト、
OOPエクササイズ、デザパタ、リファクタリング
コントローラー
コントローラーとURL
その画面でやりたいこと
そのURL リソースモデリングパターン
ビュー
hdelperからdecoratorへ
javascriptテンプレート
テスト
受け入れテストの自動化
＠自動テストがある現場で働けたことがないので憂鬱。
知識がリンクする
Rubyによるデザインパターン
リファクタリングRubyエディション
EEのドメイン駆動設計
実践テスト駆動開発
継続的デリバリー
＠是非読もうと思う
DCIについて
・安川洋平 「沖縄でRails Hackathonやってみた @yasulab」
沖縄.rbからきました
ビーチでコーディング
台風そん 暴風域にある間がハッカソンの期間だ！
＠楽しそうすぎて鼻血でそう
沖縄.rb、渋谷.rbの合同ハッカソン
上位３つ
GISTAR
webskypeのチーム？の名言「僕たちは良いプロダクトを作りたいんじゃない、新しい技術を使いたいんだ」
＠ちょっとうろ覚えだけどこんな感じ。というか大いに共感した。
＠何かやろうとすると、それは誰が責任もつのとか、工数はだれが用意するのとか、儲からないからだめでしょ、とかそういうのばかりだものなー（遠い目
screenxtv
＠これすごい。コーディングしてるウインドウをリアルタイムでストリーミング？できるサービス
沖縄の話
沖縄でRubyをやれる会社はほぼないが、リモート勤務する会社の人がいたりする。
・ursm 「Introduction to Ember.js」
Chilent-side MVC Framework であるEmberJSについて
従来のWebアプリケーションは、ロジックが全てサーバーある
しかし、クライアント側の重要さがましてきている
＠VBの業務アプリとかGUI上でMVCで組むような意識は見聞きする。
＠現役バリバリな10年選手のJavaAplleの画面は某ベンダー製のフレームワークで、全然疎でないMVCのようなものを日常的にみかけているなー（遠い目
でもJqueryではつらい
BackBone.js、AngularJS、EmberJSなどがある
EmberJSのデモ
DOMを操作するコードを隠してくれる
モデルの操作を記述しているだけ
＠確かにDOM操作の記述がない。凄い！
＠その分学習コストがお高いんでしょう？ あ、モデルの操作だけ書けばいいからむしろ楽なのか。
EmberJS
Tmplete
表示対象が更新されると自動的に書き換わる
Handlebarsでかく
View
プレゼンテーションロジックをもっている
Contoroller
アプリケーション状態を保持する
Model
Guidesを見るのがおすすめ、書いてないこともある
クライアントサイドは状態を持たなければならず難しい。EmberJSでクライアントサイドすべてにできるものでもない
・海老沢聡 「RubyMotion ではじめる！楽しい iOS アプリ開発」
https://speakerdeck.com/sugamasao/you-are-not-alone-tkrk10-equals
RubyでiOSアプリ開発ができるRubymotion。しかし有料なので最初の敷居が高い。
そこで興味ある人のためにライブコーディング
RubyMotionで画面を表示。
TableViewで値を表示。
TableViewにサーバーからとってきた値を表示。
時間内に完成！
そして名言「Rubyを知ってるだけでは作れないんです」
＠ですよねー。結局iOSわかってる人が記述量減らすためにRubyっぽく書けるよ！的なツールかと思いました
＠SublimeText2使ってるなー。入力補完がリアルタイムで出てくるの凄い、あんなプラグインあるのかー、
＠ていうかコーディングめっちゃ早い。事実として私の10倍くらいは早いと思う。いやこれは比べるのがおこがましいね・・・
・すがまさお 「巻き込まれ型人間のぼっち脱出計画」
Rubyコミニティ楽しそう参加したいでもどうすれば！？
ある日突然メールもらった！
どうやってメールをもらうに至ったか？
なにをしたか
コードを書こう
いきなり凄いものかけるわけない
Hibaraya Hiさんの「自分のためにコードを書こう」
自分が日々の生活の中でちょっと楽になるツールくらいをつくればいい
人に使ってもらえると嬉しい
＠これこれこういうことをしたいと思っても、とっさに道具が引き出せないのでお蔵入りになること多数。自分のレベルが低すぎて泣きたい。
＠そういえばむかしに、ちょっと残ってツール書こうと思ったら用もないのに残るなと怒られました。残業じゃないですといっても怒られました。どうしろと。
勉強会にいこう
大規模な勉強会だとコミュケーションが難しい
１０数人くらいのやつが良い。Rails勉強会とかなんちゃら.rbとか
何度かいこう。懇談会で話そう。
＠私が今後やっていきたいのがこれ。もっと外に出て行こう。東京Rails勉強会が毎月開催でなくなったので悲しい。
ブログを書こう
圧倒的王道。ストックできる。
自分のメモみたいなものが他の人の助けになることもある
ほってんとりーにならなくても読んでくれる人がいるよ！
＠今ちょうど作ってるsinatraアプリでつまったところをぐぐったら、すがさんのブログに何度もたどり着いていたことに後から気づきました。本当にありがとうございます
自分のやってることを形に残すのはオススメ＝待ちガイル戦法
やってきたことがめぐって人との出会いとなる
プッチの名言
＠スライドにJOJOネタ入れてくる人多くてちょっと笑った
・関口良一 @ryopeko 自分の道具を知る
DeNAのひと
日々の開発でしっておかないといけないこと
エディタ、OS、Web、開発手法、言語、ライブラリ
言語とライブラリについて
RailsとGemで簡単にできる
Railsエコシステムは強力→万能感
一歩踏み込むとRailsによらないものが必要
メンテナンス
テストのしやすさ
DRY
ハイパフォーマンスのための低レベル実装
自分は
何ができるのか
何を知っているのか
何が足りないのか
ドキュメントを読まない、あてにしない
名言「お客さんにドキュメントが間違ってたんで不具合になりました。って言えますか？私は言えないです」
＠この時の会場の静けさときたらもう・・・。でも客先にいて顧客資産で開発してると意外とこれで通る時があって、それで済ませちゃう自分を情けなく思いました。やっぱ本物は違うなぁ。
ドキュメントを当てにすると拠り所が分散してしまう
コードとドキュメント
自動生成されるドキュメント以外は信用してはいけない
仕事ですらできないのに、オープソースのものならなおさらできない
＠物凄い勢いで納得。
信用できるドキュメント
自動生成されるドキュメント
コード
＠SIはコードよりもドキュメント重視的な感じをうけます。お客さんがコードを読めないので自然とそうなったのでしょうか。そもそもお客先の情報システム部の人がコード読めないとか、プロマネのSEがコード読めないから、ドキュメントで判断するしかないとかはよく聞く話。
ドキュメントがリッチだからといって正しいとは限らないよ！
コードを読むと確実に動作がわかる
＠本当にその通りだと思う。でも業務アプリだと、なぜそれが必要だったか、はその業務に精通してないと理解できなかったりするので辛い。
副産物
ドキュメントにない使い方や引数
スーパーハカーが書いた生きたコード
生きたデザインパターンの用例
普段使わないメソッド、機能
Thorのコマンド定義
まとめ
もっとコードを読もう！
＠読みます！sinatraすごかったのでとりあえず読みたい。
