東京 Ruby 会議 10 の 3 日目に行ってきた

2013 02 11 1

1 日目に続き、東京 Ruby 会議 10 の 3 日目に行ってきました。(2 日目は目が覚めたら外が真っ白だったので断念しました) 今回は渋谷区文化総合センター大和田さくらホールで開催されました。

「シン・東京 Ruby 会議 10 劇場版 ||=」というタイトルがついており、劇場版構成で 19 時〜21 時まで休憩なしで発表がありました。

以下、メモなど。 スライドの URL は TL から把握できたものは記載しています。

大和田 Ruby 会議(@june29 さん)

URL:

東京 Ruby 会議が始まる前に「大和田 Ruby 会議」というタイトルで、@june29 さんの発表がありました。

  • Ruby について理解が深まった機会

  • enumerable

  • yield

  • ??(次はなんだ!)

  • メタプログラミング Ruby がよい

  • 「言語を選ぶということは話す相手を選ぶということだ」

  • before_filter は only 、except どちらで書くか?

  • 人それぞれの考え方がある

  • コードを弄る未来の人への気遣い

感想 「メタプログラミング Ruby」は、Ruby な本の中で一番好きかも、というくらい読んでいます。(まだ 2 回目ですが) 「一回目は何を書いてあるのか良くわからなかったが、ライブラリのコードとか読んだあとに二回目を読んでみると何を書いてあるか分かってきた」という話はとても同意できました。 WEB+DB PRESS Vol.73 がとても楽しみです。

Rails エンジニアの日常(@joker1007 さん)

URL: https://speakerdeck.com/joker1007/railsenziniafalseri-chang

  • メンタルモデルと実装の一致

  • よくわからない… DDD 本に書かれているとのこと

  • 自動化の準備

  • プロジェクトの最初の段階でやっておく

  • 名前付け超大事

  • 業務領域の言葉を意識する

  • Java などと違って名前が変更しにくい -> RubyMine はどうなんだろう?

  • AR にとらわれ過ぎない: モデルが太っていく

  • vs Fat Model

  • モジュールの活用

  • 小さなクラス(OOP エクササイズ、デザパタ、リファクタリング)

  • DCI

  • ビュー

  • Active Decorator

  • jbuilder: JSON 生成(パフォーマンスがどんなものなのか気になる)

  • 知識のリンク

  • Ruby によるデザインパターン

  • リファクタリング Ruby

  • ドメイン駆動設計

  • 実戦テスト駆動開発

  • 大事なのは真実に向かおうとする意思

  • JOJO はエンジニアの精神的な教科書とのこと

感想 とても濃い発表でした。話し方がハッキリしていた分かりやすかったです。 DDD の話は良くわからなかったので、DDD 本を読んでみたいと思います。 DCI もあまり追っかけていないので、勉強せねば...。 jbuilder のパフォーマンスが気になるところです。rabl を使ったときは思ったより重くて諦めたので。試してみよう。

Rails Hackathon in Okinawa(@yasulab さん)

URL: https://speakerdeck.com/yasulab/report-of-rails-hackathon-in-okinawa

  • 海でコードを書いたら、砂が入って MacBook が故障した

  • 台風そん: 沖縄が暴風域に入ってから出るまでのハッカソン

  • 合同ハッカソン

  • Minami.rb/Shibuya.rb/Okinawa.rb

  • お土産駆動開発

  • gistar: はてブされた gist を表示

  • (2 位を聞きそびれた)

  • ScreenX TV: ターミナルを配信できる

  • 東京〜沖縄 往復 5000 円(?)

  • Weekly Meetup: ギークハウス沖縄で開催!宿泊可!

  • 宿泊は Twitter で予約ができる

  • 沖縄で Ruby の仕事はあるのか?

  • 本職は少ない。東京の Ruby な会社で(万葉さんなど)、リモートで作業しているところはある

感想 沖縄でハッカソン良さそうです。冬に行ってみたい。 写真で見た懇親会の雰囲気とか、沖縄っぽくて良いなあと思いました。 ScreenX TV のかっこ良さが半端無かったです。

Introduction to Ember.js(@ursm さん)

URL: https://docs.google.com/presentation/d/1JMs01OIrEJ4riqXl4YpmZWRAfyKSCL55HVpGax2cH9Y/edit?usp=sharing

  • client-side MVC framework とは

  • クライアント側にロジックを持たせるような機会が増えていく

  • jquery でやるのはつらいのでそこで client-side MVC framework

  • ember.js

  • Template

  • 表示対象が更新されると自動的に書き換わる

  • View

  • DOM Event をドメインの用語に変換して適切な相手に送りつける

  • Controller

  • Application State を保持する

  • Model

  • Persistent State を保持する

  • 永続化が必要な場合はそれ用のライブラリを使う

  • Router Rails の Router + Action みたいなイメージ

  • DOM を操作するコードを書かなくて良い

  • one more thing…

  • 永和システムで作っている IRC の代替チャットシステム。良さそう。

  • github, travis などのサービス連携

感想 KnockoutJS を使っていましたが、Router という概念が無かったので、どういうものか気になりました。 MVC(MVVM も含め) framework は色々あって分からない… 本体のコードの読みやすさも重要ですよね。 永続化は必要なの?とも思ったり。 CoffeeScript でだいぶマシになったものの、JS アレルギーな僕はあまり近づきたくない世界でした。

RubyMotion ではじめる!楽しい iOS アプリ開発(@satococoa さん)

URL: https://speakerdeck.com/satococoa/tkrk10-rubymotion

  • Ruby Motion は課金アイテム
  • TODO アプリのクライアントをライブコーディング形式で実装
  • 「ほのぼの rake」 by id:naoya
  • 動いた

**感想** Sublime Text の補完がなかなか素敵でした。 RubyMotion 検討していたのですが、やはり高いなあということで見送っていました… ライブラリも充実してきたとのことですし、また検討しても良いのかもしれません。

巻き込まれ型人間のボッチ脱出計画(@sugamasao さん)

URL: https://speakerdeck.com/sugamasao/juan-kiip-marexing-ren-jian-falsebotutituo-chu-ji-hua

  • Ruby 会議のレポート班のお誘いが来た

  • 待ちガイルに有効だったとおもわれる方法

  • コードを書こう

  • 自分のための code を書こう // Speaker Deck https://speakerdeck.com/hibariya/code

  • 自分が欲しいものを作れば良い

  • Rubygems はダウンロード数が見えるので射幸心が煽られる

  • 勉強会に行こう

  • 10 数名の勉強会に行く Rails 勉強会、地域のコミュニティなど

  • アルコールでブースト

  • ブログを書こう

  • 圧倒的王道

  • 自分のメモみたいなものが他人の助けになることも

感想 ブログを書くとか、良く書いているコードのライブラリ化とか、積極的にやっていきたいなと思いました。 アルコールは重要だと思います!

自分の道具を知る(@ryopeko さん)

URL: https://speakerdeck.com/ryopeko/zi-fen-falsedao-ju-wozhi-ru

  • ハイパフォーマンスのための低レベル実装

  • 一歩踏み込むと、Rails によらない知識や経験が必要

  • サバンナを生きる技術: 何が出来るのか、何を知っているのか、何が足りないのか、を認識することが大事

  • ドキュメントを読まない、ドキュメントをアテにしない: ドキュメントを当てにすると拠り所が分散する

  • 自動生成できるコメント以外は信用出来ない

  • 信頼出来るドキュメント: 自動生成されるドキュメント(YARD いいね!)/コード

  • 「人がやっていることだからドキュメントがメンテされていないこともあるよね」

  • 動作が分からないときはコードを読む

  • コードを読むと確実に動作が分かる

  • 知らない機能の発見(opts とか)

  • スーパーハカーのコードを読める!

  • 生きたデザインパターンの用例: Module: Capistrano::Deploy::Strategy

  • 「social coding!」というが、コードを読まないとできないもの

  • まとめ

  • 一歩踏み込もう

  • もっとコードを読もう

  • ペアコードリーディングおすすめ

感想 スーパーハカーのコードを読めるのはオープンソースの良さですね。とても参考になるなあと思います。 他の人のコードリーディングのやり方とか気になります。どうしているのだろうか。 そういう意味ではペアコードリーディングは面白そう。

感想

今回は(も)、いい話ばかりでした。休憩なしで一気に聞いたのも中々良かった気がします。

考え方や設計の話が僕は好きなのだなと思いました。って当たり前か。 日頃から使っているライブラリは読む癖をつけていかないとですね。

もっとコードを読んで、もっとブログやコードを公開していかないとなあと思いました。 Ruby コミュニティにも何らかの形で貢献したいなあ、と思います。頑張ります。

ところどころにジョジョの話が出てきたのですが、ジョジョを読んだことのない僕にはあまり分かりませんでした。 よくオススメされるので読んでみようと思います。

今から東京 Ruby 会議 11 が楽しみです! とても素晴らしい会をありがとうございました。

© 2023 暇人じゃない. All rights reserved.