ゆるふわ.rb　in 大洲　〜鯛しゃぶをつつきながらCodeIQに挑戦！！（前編）〜　を開催しました

ゆるふわ 勉強会

2/15(土) にゆるふわ.rb を開催しました。
ゆるふわ.rb in 大洲 〜鯛しゃぶをつつきながらCodeIQに挑戦！！（前編）〜 - ゆるふわ.rb | Doorkeeper

今回は「CodeIQに挑戦！！（前編）」と題し、CodeIQに挑戦するための下地づくりとしてRubyをみんなで勉強しましょうという主旨で開催しました。
次回3/1(土) には「CodeIQに挑戦！！（後編）」を開催し、実際にCodeIQに挑戦します。
ゆるふわ.rb in 大洲 〜鯛しゃぶをつつきながらCodeIQに挑戦！！（後編）〜 - ゆるふわ.rb | Doorkeeper

会場は調理室

今回もゆるふわ.rb 定番の調理室で実施しました。
そして今回も会場案内は「ふるふわ.rb」・・・こちらは定番とせず早く「ゆるふわ.rb」と修正してもらいたいものです（笑）

ウェルカムチョコレートとウェルカムドリンクと自己紹介

前日がバレンタインデーだったということで、今回はウェルカムチョコレートを用意しました。
ただ酒飲みなみなさんだったようであまり人気はなかったです（笑）

もちろん定番のウェルカムドリンクも用意しました。
今回はお麩のみそ汁・・・を用意したんですがお麩を入れ過ぎてお麩がメインかみそ汁がメインか分からなくなってしまいました（笑）
これらを頂いて体も場の空気も温まったところでみなさんに自己紹介して頂きました。

CodeIQとドットインストールの説明

続いて私からCodeIQとドットインストールの２つについて簡単な説明をしました。
もう説明する必要もないくらい有名なサービスですが「新しいことを始めるなら分厚い入門書を読むだけでなくドットインストールでとりあえず動かしてみながら学ぶ方が上達が早いんじゃないかな」とか「CodeIQでは単なる答え合わせではなく出題者の方から生の声でフィードバックをもらえるのが良いよね」など私の所感をお伝えしました。

ドットインストールと鯛しゃぶと酒

次にhttp://dotinstall.com/lessons/basic_rubyの実践に移りました。
全３２回、参加者は私を除いて８名ということで「４回 × ８人」で分担してその内容をA4半分の大きさの紙にまとめ、あとでみんなでそれを共有するという方式で進めました。
これらの紙を次回CodeIQに挑戦する際のインプットにしようと思っていたんですが、酔っ払っていたせいか収集するのをすっかり忘れてしまうというポカをやってしまいました。。。
次回・・・どうしようかな。

（自分担当分をみんなに説明している様子）

みんなで共有後はビアバッシュ、鯛しゃぶしながらお酒を酌み交わしました。
Rubyの話だけでなく仕事の話とかプログラマとしてのあるべき姿とか、熱い語り合いが出来てとても楽しい時間を過ごせました。

チェックアウト

最後にみんなで片付けをして、ゴミ１つ残さず会場を後にしました。

今回も大洲という田舎での開催だったんですが、多くの方にわざわざ遠く松山から来て頂いてとても嬉しく思いました。
これからもそうやって足を運んでもらえるよう、「ゆるく楽しく」を大事にして魅力ある場を目指してやっていこうと思います。
参加して頂いたみなさん、ありがとうございました。

越境する開発 〜分散する開発現場への挑戦〜 に参加してきました

IT業界 勉強会

2/1(土) に 越境する開発 〜分散する開発現場への挑戦〜 - DevLOVE四国 | Doorkeeper に参加してきました。
当日の流れはこんな感じ。

  • はじめに
  • 自己紹介 & 開発現場での悩みごと共有
  • 「越境する開発 〜分散する開発の現場〜」（市谷聡啓さん）
  • 「"地方エンジニア"という考え方はすでに終わっている」（わたし）
  • 「ダイヤモンドクロスで生まれたWEBアプリケーション」（岩井克之さん）

前日に行われた アジャイル型開発におけるプラクティス活用リファレンスガイドの勘所と活用方法 で松山に来られていた市谷さん、本橋さんもいらっしゃるという、いつもの愛媛の勉強会より豪華な感じで開催されました。
参加者のほとんどは顔見知りということで終止アットホームな雰囲気で進んでいきました。

#agile459 アジャイル型開発におけるプラクティス活用リファレンスガイドの勘所と活用方法 - Togetter

はじめに

今後も増え続けるであろう開発現場が物理的に分散するスタイルについて、どのようにデザインするのが良いのか、どのように乗り越えていけるかをみんなで考えよう、という勉強会の主旨を市谷さんから説明されました。

自己紹介 & 開発現場での悩みごと共有

一人一人自己紹介をしました。
基本的にはみんな顔見知りだったので「最近太ってきちゃって大変」とか「ここまでチャリで来ました」とか開発現場とは関係ない話があったり(笑) と、楽しい雰囲気で進みました。

「越境する開発 〜分散する開発の現場〜」（市谷聡啓さん）

続いては市谷さんの発表、実際に市谷さんがやられた分散開発の事例を元に、うまくいかなかった点を整理し、どうすればもっとうまくやれたんだろう？ということをみんなでディスカッションしました。
結構オフレコなことが多くて詳細についてはあまり触れられないんですが、みんなから色んな視点で意見が出ました。
そんな中で私が印象に残っているのは「物理的に現場が分散するとコミュニケーションはどうしても弱くなってしまう」がそこをどう乗り越えるか？という議論です。

私なりの答えは こんな感じでリモート勤務やってます - ITエンジニアとして生きる でも少し触れていますが、コミュニケーションに割くリソースを最小化して開発リソースを最大化する、動くものを早く完成させて動くものベースで会話をすることによって１回１回を密度の濃いコミュニケーションにする、というものです。
これは私が分散開発を実践していく中で色々試し、失敗して学び、それを通して辿り着いたものなのでこれも１つの解だとは思っています。

ただこの議論の中で「普段コミュニケーションで埋めているものは何だろう？」という問いがあってですね、、、この問いに対する回答を明文化出来れば、ひょっとしたら前述の私なりの答えよりもっとうまいやり方とかに辿り着けるかも？という想いが沸いて個人的にとても興味をそそられたのです。
またいつか色んな方々とこのテーマについて話してみたいですね。

「"地方エンジニア"という考え方はすでに終わっている」（わたし）

続いては私の発表、これから「地方」という考え方が終わりゆくものになっていく、その時代を生き抜いていくためには信頼を得る仕事力が大事である、という話をさせて頂きました。

「ダイヤモンドクロスで生まれたWEBアプリケーション」（岩井克之さん）

ラストは岩井さん、松山のコワーキングスペースである ダイヤモンドクロス のニーズから生まれたクラウド型給与計算アプリについてのお話でした。
http://ncpartwork.nextcode.jp/#/service

普段忙しくてずっと手付かずだった機能を今回の発表が決まってから導入したそうです。
これからも機能追加を依頼したい場合は、まずどこかの勉強会での発表を依頼するとスムーズに追加してもらえるかもしれません(笑)

おしまい

とても濃い時間を過ごせた勉強会でした。
参加者のみなさんにはそれぞれの世界観があって、みんなで議論するのがとても楽しかったです。
また普段なかなかお会い出来ない市谷さん、本橋さんら東京でご活躍される方々と議論し合えるのもとても嬉しく思いました。
これからも愛媛、盛り上がっていきますよ〜！！

こんな感じでリモート勤務やってます

IT業界 リモート勤務

久しぶりのリモート勤務ネタです。
最近ちょこちょこ「リモート勤務ってどんな感じですか？」という質問を受けることがあって、いい機会なのでまとめてみました。

こんな感じで受託開発やってます

ハートレイルズでは大きく以下の２パターンで受託開発しています。

  1. 顧客との窓口になるメンバーが１人いて、そのメンバーがオンサイト顧客代理となる
  2. 開発メンバー自身が顧客とやりとりをする

前者はオンサイト顧客代理が開発メンバーにクラウド上（GitHub や Bitbucket）でタスクを割り当てて仕事を進めるスタイルです。トラックナンバー１になりがちですが、いい意味で情報を精査出来るので小さめのプロジェクトには向いていると思います。
またオンサイト顧客代理も顧客先に常駐しているわけではなく、顧客先を訪問するのはせいぜい隔週１回くらいですので労働集約的にはなりません。
顧客と開発フローを話し合ってお互い離れていても円滑に仕事が出来るような体制を敷いています。

後者は開発メンバーがクラウド上で直接顧客とやり取りします。
やり取りする方法は前者と似ていて、クラウド上で顧客とタスクを渡し合いながら仕事を進めます。
情報がクラウド上に集約されてトラックナンバーも増やせるというメリットはありますが、開発メンバーからは顧客の表情が見えないので、知らず知らずに信頼貯金を減らしてしまうようなことをしてしまうリスクはあるかもしれません。
また矢面に立つメンバーが情報を噛み砕いてくれるということは無いので、クラウド上に集約された情報を自ら追って内容を整理したり、どの辺りがプロジェクトのボトルネックになりそうかといったことを推測していくスキルが開発メンバーに求められるように思います。

こんな感じでチーム開発やってます

http://wazanova.jp/items/675

ハートレイルズでもここで紹介されている Github と似たような形で、基本的に「pull request／chat を中心にコミュニケーションは非同期スタイル」を採用しています。
これは開発メンバーが仕事に打ち込む時間や裁量を最大化出来るというメリットがある反面、管理側からは仕事が見えにくいというデメリットもあります。（しばらく開発メンバーからアウトプットが出て来ないときは管理者から「何やってますか？」という chat が飛んだりします。）

私がその解決策として実践しているのは、単純ですが「作業を分割すること」で、私の場合だと大体「２時間〜１日」くらいの単位で分割してなるべく毎日成果が出せるように心がけています。
そうすることで管理側から仕事も見えやすくなりますし、アウトプットの単位が小さいのでレビュー範囲も小さく、フィードバックも素早くもらえます。
この「作業を分割して毎日成果が出せるようにすること」はリモート勤務を実践する上で最も大事なことではないかと思っています。

ちょっと付け足し

リモートチームは物理的にロケーションが離れているので、同じ現場にいるように議論や確認、意見交換は不可能です。
慣れてくれば高いレベルでそういうことも実現出来るかもしれませんが、同じ現場にいる時と大差なく、というのは難しいように思います。
そんな中でどうやって成果を出すのか・・・？？？

ハートレイルズでは、コミュニケーションに割くリソースを最小化して、開発リソース（個々の開発者の裁量）を最大化することによって成果の最大化を目指しているように思います。
もちろん全く指示を受けないわけではないですが、設計・開発における大部分について裁量を頂いています。
そのかわり個々人にはプロフェッショナルな自覚や責任、スキルが求められますし、何より「任せたらやってくれる！」という信頼関係がなければなりません。
そういった各々が自立した集団でないとリモートチームは機能しないように感じますし、そういったレベルをしきい値として求められているような気がしています。

まとめ

今回はどんな感じでリモート勤務しているのかを書いてみました。
色々求められるスキルやら何やら書きましたが、一番大事なのは信頼して裁量を与えられているその仕事に最大限応えようとするマインドではないかと思います。
そのマインドがあればスキルは後からついてくるのかなと。
これからもこのマインドを大事に、もっとスキルを磨いてより良いエンジニアを目指して頑張ってゆこうと思う今日この頃でした。

ExceptionNotifier.notify_exception で処理されない３つの Exception

Ruby Tips

exception_notification v4.0.0 の話です。
GitHub - smartinez87/exception_notification at v4.0.0

v4.0.0から通知処理をバックグラウンド実行する、以下のようなコードが書けるようになりました。

begin
  some code...
rescue => e
  ExceptionNotifier.notify_exception(e)
end

これは便利なのですが、１点認識しておかないといけないことがあります。
ExceptionNotifier では以下の３つの Exception についてはデフォルトで処理しないようにハードコードされています。

もしこれらを処理したいのであればモンキーパッチ的な対応やら何やら施す必要があります。

【修正】
http://smartinez87.github.io/exception_notification/#ignore-exceptions/ignore_exceptions
ここにあるように ignore_exceptions オプションを利用して、例えば下記のような定義をすればモンキーパッチ的な対応をしなくても３つのExceptionを処理対象とすることが出来るようですね。

Whatever::Application.config.middleware.use ExceptionNotification::Rack,
  :ignore_exceptions => '',
  :email => {
    :email_prefix         => "[Whatever] ",
    :sender_address       => %{"notifier" <notifier@example.com>},
    :exception_recipients => %w{exceptions@example.com}
  }

ELB の Cross-Zone Load Balancing という機能

AWS Tips

旧来のELB

旧来のELBの有名な話で、マルチAZで均等にリクエストを振り分けるためには各AZに配置するインスタンス数を同数とする必要がありました。
これはELBがAZ毎にLBを置き、その配下のインスタンスにしかリクエストを転送できないアーキテクチャとなっていたためです。

この性質はオートスケールと組み合わせて考えた場合に困ります。
なぜならオートスケール時はAZ間で足並みそろえてスケールされるわけではないため、例えば以下のような設定とした場合、一方のAZでは１台のインスタンス、他方のAZでは５台のインスタンスという状態が発生し得るからです。

＜ELBとオートスケール設定＞

Cross-Zone Load Balancing という機能

これまで前述の事項は避けようがなかったのですが、それを解決してくれる「Cross-Zone Load Balancing」という機能が2013年11月にリリースされました。
Elastic Load Balancing Announces Cross-Zone Load Balancing

アーキテクチャとしてはこれまで同様にAZ毎にLBが置かれるようですが、Cross-Zone Load Balancing を有効化すると各LBがAZを跨いでリクエストを転送できるようにしてくれるようです。
したがって、AZ単位ではなく、ELB配下のインスタンス単位でリクエストを均等に振り分けることが出来るようになるため、AZ間でインスタンス数を合わる必要がなくなり、オートスケール時も懸念する必要がなくなりました。
ナイスな機能ですね。


ちなみに Cross-Zone Load Balancing は CLI で有効化できるようです。（現時点ではまだマネージメントコンソールは未対応。。。）
Configure Cross-Zone Load Balancing for Your Classic Load Balancer - Elastic Load Balancing

定数を環境変数から取得したい、かつデフォルト値を定義したい

Ruby Tips

▼文字列を取得したい場合

LOCALE = ENV['LOCALE'] || 'ja'

▼数値を取得したい場合

MAX_COUNT = (c = ENV["MAX_COUNT"].to_i) > 0 ? c : 30
TIMEOUT = (t = ENV["TIMEOUT"].to_f) > 0 ? t : 0.5

※ nil.to_i は「0」nil.to_f は「0.0」 であるため、文字列を取得したい場合と同じように書くとデフォルト値が採用されない。

MAX_COUNT = ENV["MAX_COUNT"].to_i || 30    # 環境変数が定義されていない場合「MAX_COUNT：0」となる
TIMEOUT = ENV["TIMEOUT"].to_f || 0.5       # 環境変数が定義されていない場合「TIMEOUT：0.0」となる


【2012/12/12 追記】
コメント頂きました。
数値を取得したい場合はこちらの方が良い気がする。

MAX_COUNT = (ENV["MAX_COUNT"] || 30).to_i
TIMEOUT = (ENV["TIMEOUT"] || 0.5).to_f

RDSのクエリ調査

AWS Tips

RDSのクエリ調査を実施する際にすべきこと。

（1）RDSの設定

  • general_log：1 ・・・全てのクエリをログに残す
  • slow_query_log：1　・・・スロークエリ（時間のかかっているクエリをログに残す）
  • long_query_time：1　・・・スロークエリの時間（秒）

（２）設定確認

  • show global variables like 'general_log';
  • show global variables like 'slow_query_log';
  • show global variables like 'long_query_time';

（３）全クエリの確認

  • select * from mysql.general_log;

（４）スロークエリの確認

  • select * from mysql.slow_log;