- プロダクトマネージャー
- Webエンジニア
- 通訳・翻訳
- 他75件の職種
-
開発
- Webエンジニア
- アーキテクト(バックエンド)
- アーキテクト(フロントエンド)
- フルスタックエンジニア
- フロントエンドマネージャー
- バックエンドエンジニア
- Webフロントエンド
- Webエンジニア
- フロントエンドエンジニア
- サーバーサイドエンジニア
- エンジニア@大阪
- エンジニア オープンポジション
- エンジニア@京都
- Rails@京都
- バックエンド@BFW
- Androidエンジニア
- iOSエンジニア
- SRE
- クラウドエンジニア
- SRE、インフラエンジニア
- テスト自動化エンジニア
- SDET
- QAエンジニア
- マーケティングエンジニア
- Webアナリティクスエンジニア
- QA関連職種オープンポジション
- QAエンジニア
- セキュリティエンジニア
- Webデザイナー
- コミュニケーションデザイナー
- UIデザイナー
- プロダクトデザイナー
- デザイナーオープンポジション
- グラフィックデザイナー
-
ビジネス
- プロダクトマネージャー
- プロダクトマネージャー
- シニアプロダクトマネージャー
- スクラムマスター
- コーポレートブランディング
- 経理
- 内部監査
- AML/CFTコンプライアンス
- AML・金融犯罪対策Ops
- 金融コンプライアンス
- システム監査
- ビジネス採用担当
- 経営企画(予実・IR)
- HRBP
- 法務
- 債権管理/MFK
- 事業開発
- 新規事業開発
- ビジネス職
- フィールドセールス
- インサイドセールス SDR
- インサイドセールス企画
- オンラインセールス
- SaaS営業、MFBC
- インサイドセールス MFBC
- セールス MFBC
- マーケティング・PR
- マーケター
- サービス企画
- データマーケター
- BtoBマーケティングリーダー
- CRMスペシャリスト
- WEBマーケティング(B2B)
- イベントマーケター
- コンテンツマーケ MFBC
- SEO MFBC
- その他
【速報】RubyKaigi 2014レポ:The Twelve-factor Ruby 「Ruby を良くするための12のポイント」
RubyKaigi 2014の参加レポート速報! 二日目!
Session
9/19(金) 14:00 Hall B
The Twelve-factor Ruby 「Ruby を良くするための12のポイント」
GMO Pepabo, Inc. , Hiroshi SHIBATAさん
参加レポート
@hsbtさんの自己紹介
コミッターとしてやったこと removed test-unitremoved minitestmake bundled gem mechanismcoordinate to Ruby Committers Rubyコミッターは協調性がない(笑)nagotiate to sponcers
Rubyスポンサー企業に感謝!GMOペパボについて 新しいプロダクトはRubyいろんなプロダクトのコミット権をもらっているので会社では午前の時間を使ってそれらの開発やってる(=その辺りがよくなると、社内のエンジニアの効率もあがる)
Rubyの開発について
Rubyのコアクラスはmatzが全てジャッジするスタンダードライブラリはメインメンテナーバンドルライブラリは@hsbtさんコミッターには燃料投下が必要 コミッターに適切に問題を伝えることが大事
Rubyをよくする12個のポイント
Reporting Line tweetでRubyおせーとか型欲しいとかいっても無駄redmine(bugs.ruby.org) 題名とほしい内容を書いてチケット作ってGitHub is OK ここでpullrequest作ってコミッターに送るただ、GitHubはRubyのサブリポジトリmatzもredmineにしか生息していない matzの判断を仰ぐ系の修正とかは必ずredmineyour benefit approved later とりあえず出しておくだけでいいことがきっとあるずっと放置されててもめげないでrelated issuesgood bikeshedusecase その要望、思いが通ると何が嬉しいのか、何に使うのかを説明する このメソッドの返り値はこうであるべき!以上!みたいなチケットが多いAcceptable issue without usecase symmetricalPOSIX[BUG] [SEGV]codeをつける !!!!!! I propose awesome function !!!!!!!!!!!!!! 誰がつくるの・・・がポイント基本は欲しいといった人が作るべきbugレポートでもコードをつけるべき 問題の本質がRubyにあるのか、Rubyの上にあるRailsにあるのか切り分けしやすくなる試しに直してみましたというコードが綺麗である必要はないgit format-patch sha1 [dir]Naming ここまでの前提があっても、ネーミングがいまいちだと却下されるAvoid to Red Ocean GCのチューニングとか・・Blue Ocean Win/AIX/SolarisRails with trunk プロダクションじゃなくていいので、テスト走らせてみるとか、そこで落ちるみたいなフィードバックは大歓迎documentationlanguage 日本語 is okEnglish is betterポイントはできるだけ多くの人に見てもらうことだけど、敷居が高すぎても意味ないexpectation Good bugreport 直す側が知りたいのはどういう挙動を期待していて、それがどういう結果になったのかという点。minimum case 問題が再現する最小限のコードこれがあると解決が速い nakadaさんがすぐにパッチしてくれるRailsで落ちましただけじゃわからないので、crashログを貼り付けて欲しい。 crashログを見ると、Rubyじゃなくてnative extensionで落ちてるとかわかりやすいtrunkでも落ちるか バグ修正はtrunkでしか行われず、それを各バージョンのブランチに展開しているので、trunkのどのバージョンで落ちますとかっていうのがあると助かるshould be good reportDev MTG Agenda Matz JudgeIssue TriageRelease PlanningMatz approval Matzがいいといったものはいいみたいな文化Matzを説得する技術が求められる(笑)