NBA公式のソーシャルゲームがついに登場!!
■CyberX代表ブログhttp://ameblo.jp/spotlight/
■Twitter: @mcrin72
■CyberX広報ブログhttp://ameblo.jp/cyberx-pr-news/
■Twitter: @cyberx_PR
読書会のススメ
CyberX エンジニアの石川です。
日々、業務に追われているとなかなか勉強する時間が持てないというのはエンジニアに限らず感じている人は多いのではないかなと思います。
いざ始めても一人だと途中で挫折してしまうというのもよくある話です。
そんな中、CyberXでは「読書会」を始めてもうすぐ２年になります。
折角なので「CyberX流 読書会」が２年続いた理由をまとめてみようと思います。
読書会のスタイルは以下の様なものです。
1.メンバーは３人
2.毎週月曜日朝９時から３０分間（弊社の始業時間は朝１０時です）
3.当番が対象の本の１節（２０ページ前後）をまとめて発表
4.発表者は毎週交代
5.月曜日がお休みの場合はお休み
このスタイルで読書会の対象の本の厚さにもよりますが、年２冊ぐらいを読み進めています。
それではまとめてみます！
1.少人数でやる
あまり大人数で行うより少人数の方が、欠席しづらいので継続しやすいです。
また、自分が対象の本の内容をまとめる当番が毎月１～２回ぐらいが無理もなく継続できます。
2.集中できる時間にやる
業務時間中に行うとどうしても忙しくて２の次になってしまいがちなので、誰もいない時間帯に行うと集中して行えます。特に、月曜日の朝は休み明けもあってか、一番人が少ない時間帯です。
また、月曜日の朝は疲れもなく頭も冴えているので読書会にうってつけです！
3.同じ本を読む
同じ時間に同じ場所に集まって別々の本を読むより同じ本を読み進めることをオススメします。
感想を共有したり、その場で質問したりすることでより理解度が深まります。
4.１回のボリュームをあまり大きくしない
折角始めても挫折しては意味がありません。
少しでも良いのできちんと理解し、続ける事を優先した方が良いです。
5.興味のある本を読む
当たり前ですが、興味のある本でないと苦痛になって継続するのが難しくなってしまいます。
出来れば、業務に還元できるものが良いです。仕事中に少し悩んでいる時などに「あっ！ここ本に書いてあったことを活用できる！」的な空気を味わえてより読書会への意欲が湧きます！
以上が「CyberX流 読書会」のまとめです
いかがだったでしょうか？少しでも皆さんの参考になれば幸いです。
思わぬ副産物でしたが、一人だと挫折しがちだった読書ですが、２年続けている内に習慣化されて読書会とは別に継続的に本を読むようになっていました。
最後に「CyberX流 読書会」で読んだ本を紹介して終わりたいと思います。
リファクタリング―プログラムの体質改善テクニック (Object Technology Ser.../ピアソンエデュケーション
￥5,040
Amazon.co.jp
言わずと知れた名著です。良いコードとはどんなコードか、どのようにコードを書けば良いか？というテクニックが盛りだくさんです。
プログラマの方には是非読んでいただきたいです！
レガシーコード改善ガイド (Object Oriented SELECTION)/翔泳社
￥4,410
Amazon.co.jp
これもまた、言わずと知れた名著です。すでにモンスターと化してしまったプログラムに立ち向かっているプログラマの方は必見です！
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory i.../オライリージャパン
￥2,520
Amazon.co.jp
読みやすいコードとはどんなコードなのかを例を用いながら解説してくれています。プログラム初心者の方にもオススメです！
Nodeクックブック/オライリージャパン
￥3,570
Amazon.co.jp
Node.jsの基本的なレシピが学べます。もし、Node.jsに興味があって色々試してみたいという方にオススメです！
日々、業務に追われているとなかなか勉強する時間が持てないというのはエンジニアに限らず感じている人は多いのではないかなと思います。
いざ始めても一人だと途中で挫折してしまうというのもよくある話です。
そんな中、CyberXでは「読書会」を始めてもうすぐ２年になります。
折角なので「CyberX流 読書会」が２年続いた理由をまとめてみようと思います。
読書会のスタイルは以下の様なものです。
1.メンバーは３人
2.毎週月曜日朝９時から３０分間（弊社の始業時間は朝１０時です）
3.当番が対象の本の１節（２０ページ前後）をまとめて発表
4.発表者は毎週交代
5.月曜日がお休みの場合はお休み
このスタイルで読書会の対象の本の厚さにもよりますが、年２冊ぐらいを読み進めています。
それではまとめてみます！
1.少人数でやる
あまり大人数で行うより少人数の方が、欠席しづらいので継続しやすいです。
また、自分が対象の本の内容をまとめる当番が毎月１～２回ぐらいが無理もなく継続できます。
2.集中できる時間にやる
業務時間中に行うとどうしても忙しくて２の次になってしまいがちなので、誰もいない時間帯に行うと集中して行えます。特に、月曜日の朝は休み明けもあってか、一番人が少ない時間帯です。
また、月曜日の朝は疲れもなく頭も冴えているので読書会にうってつけです！
3.同じ本を読む
同じ時間に同じ場所に集まって別々の本を読むより同じ本を読み進めることをオススメします。
感想を共有したり、その場で質問したりすることでより理解度が深まります。
4.１回のボリュームをあまり大きくしない
折角始めても挫折しては意味がありません。
少しでも良いのできちんと理解し、続ける事を優先した方が良いです。
5.興味のある本を読む
当たり前ですが、興味のある本でないと苦痛になって継続するのが難しくなってしまいます。
出来れば、業務に還元できるものが良いです。仕事中に少し悩んでいる時などに「あっ！ここ本に書いてあったことを活用できる！」的な空気を味わえてより読書会への意欲が湧きます！
以上が「CyberX流 読書会」のまとめです
いかがだったでしょうか？少しでも皆さんの参考になれば幸いです。
思わぬ副産物でしたが、一人だと挫折しがちだった読書ですが、２年続けている内に習慣化されて読書会とは別に継続的に本を読むようになっていました。
最後に「CyberX流 読書会」で読んだ本を紹介して終わりたいと思います。
リファクタリング―プログラムの体質改善テクニック (Object Technology Ser.../ピアソンエデュケーション
￥5,040
Amazon.co.jp
言わずと知れた名著です。良いコードとはどんなコードか、どのようにコードを書けば良いか？というテクニックが盛りだくさんです。
プログラマの方には是非読んでいただきたいです！
レガシーコード改善ガイド (Object Oriented SELECTION)/翔泳社
￥4,410
Amazon.co.jp
これもまた、言わずと知れた名著です。すでにモンスターと化してしまったプログラムに立ち向かっているプログラマの方は必見です！
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory i.../オライリージャパン
￥2,520
Amazon.co.jp
読みやすいコードとはどんなコードなのかを例を用いながら解説してくれています。プログラム初心者の方にもオススメです！
Nodeクックブック/オライリージャパン
￥3,570
Amazon.co.jp
Node.jsの基本的なレシピが学べます。もし、Node.jsに興味があって色々試してみたいという方にオススメです！
コードレビューしてますか？
CyberX エンジニアの塚原です。
チームでアプリの開発・運用をしていると、
機能追加やバグ修正などで他人の書いたソースコードを読む機会が多々ありますよね。
その際に、コーディング規約に沿っていないオレオレなソースコードだったり、
メソッドが長過ぎるコードに出会ってPCを閉じたくなった経験はエンジニアなら誰でもあるはず。
そういったコードは保守性に欠け、バグも生み出してしまいます。
（そんなことは理解していても、開発期間が足りずに泣く泣くそのままリリースすることも）
「// 最低なソースでごめんなさい。。。朝5時なんです。」なんてコメントがあったりw
とはいえ、出来るだけ始めからキレイなコードにしておきたいですよね。
ということで、今回は「コードレビュー」をテーマにしてみました。
今更な感じはありますが、
結局のところコレが皆が幸せになる手っ取り早い方法なのかな、と。
他人のソースコードを読んでいると
ここはこう書くべきでは？
とか思いますよね。
それを早い段階で指摘しておければいいわけです。
じゃあコードレビューをしましょうよ、と。
コードレビューには次のようなメリットがあります。
＊ソースコードが共有できる
書いた本人がいなくなったら誰もわからない。。。
ってことが防げるはず。
ちょっと話がズレますが、
以前の職場で、ある日になるとプログラムが動かなくなる処理が意図的に組み込まれていて困ったことがあります。。。
まぁこんなことはあまりないと思いますが、これもレビューしてれば防げます。
＊勉強になる
レビューする側、される側の双方にとって効果が見込めるはず。
ペアプログラミングと同じような効果があるかと。
他人の書き方で勉強になることは多いです。
新しくjoinした方に規約などを教える機会にもなります。
＊ソースコードの質が向上する
指摘はなるべく受けたくないですよね？
となると必然的にコードの質は上がります。
保守性があがり、バグも減るでしょう。
もうコレだけでやる価値があると思いませんか。
「いやいや、そんなこといっても時間もかかるし、導入は面倒だよ」
という考えもあるでしょう。
その時は時間を要しますが、長い目でみれば少なく済むはずです。
変更しやすく拡張性が高いコードになっているはずですから、
機能追加やバグ修正には少ない時間で対応できます。
「上司や先輩には指摘し辛い」というのもあるでしょう。
これはチームで先にルールを決めておきましょう。
立場に関係なく議論できる環境を用意しておけばきっと良いレビューが増えるでしょう。
コードを書いた人ではなく、コード自体に意見するんだよ、ということ。
レビューの手法として取り入れ易いものをいくつか例を挙げると
＊ペアレビュー
コードを書いた人とレビューする人がペアで進める手法。
2人で進めるため、抜け漏れがあるかも。
＊パスアラウンド
複数人が非同期でレビューする手法。
GitHubやGerritを利用するのが多い。
＊アドホックレビュー
必要になった時にチームメンバーにコードをみてもらう手法。
これが一番ハードルが低いと思います。
あとは、ブランチにコミットする前にレビューするのか、後にレビューするか。
非同期でレビューを行うならば、コミット後の方が都合が良いでしょう。
ただ、手法はいくつもありますが、どれも完璧ではないので、
複数組み合わせたり、ペアプログラミングと組み合わせたり、
より自分たちに合ったやり方を探す必要があります。
（パスアラウンド＋アドホック＋たまにはペアプログラミングがやり易いかな）
＋テスト駆動開発でバグのないキレイなソースコードでハッピーになりましょう！
参考文献：
http://gihyo.jp/magazine/wdpress/archive/2013/vol72
参考URL：
http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC
https://speakerdeck.com/fujimura/aiminggithub
チームでアプリの開発・運用をしていると、
機能追加やバグ修正などで他人の書いたソースコードを読む機会が多々ありますよね。
その際に、コーディング規約に沿っていないオレオレなソースコードだったり、
メソッドが長過ぎるコードに出会ってPCを閉じたくなった経験はエンジニアなら誰でもあるはず。
そういったコードは保守性に欠け、バグも生み出してしまいます。
（そんなことは理解していても、開発期間が足りずに泣く泣くそのままリリースすることも）
「// 最低なソースでごめんなさい。。。朝5時なんです。」なんてコメントがあったりw
とはいえ、出来るだけ始めからキレイなコードにしておきたいですよね。
ということで、今回は「コードレビュー」をテーマにしてみました。
今更な感じはありますが、
結局のところコレが皆が幸せになる手っ取り早い方法なのかな、と。
他人のソースコードを読んでいると
ここはこう書くべきでは？
とか思いますよね。
それを早い段階で指摘しておければいいわけです。
じゃあコードレビューをしましょうよ、と。
コードレビューには次のようなメリットがあります。
＊ソースコードが共有できる
書いた本人がいなくなったら誰もわからない。。。
ってことが防げるはず。
ちょっと話がズレますが、
以前の職場で、ある日になるとプログラムが動かなくなる処理が意図的に組み込まれていて困ったことがあります。。。
まぁこんなことはあまりないと思いますが、これもレビューしてれば防げます。
＊勉強になる
レビューする側、される側の双方にとって効果が見込めるはず。
ペアプログラミングと同じような効果があるかと。
他人の書き方で勉強になることは多いです。
新しくjoinした方に規約などを教える機会にもなります。
＊ソースコードの質が向上する
指摘はなるべく受けたくないですよね？
となると必然的にコードの質は上がります。
保守性があがり、バグも減るでしょう。
もうコレだけでやる価値があると思いませんか。
「いやいや、そんなこといっても時間もかかるし、導入は面倒だよ」
という考えもあるでしょう。
その時は時間を要しますが、長い目でみれば少なく済むはずです。
変更しやすく拡張性が高いコードになっているはずですから、
機能追加やバグ修正には少ない時間で対応できます。
「上司や先輩には指摘し辛い」というのもあるでしょう。
これはチームで先にルールを決めておきましょう。
立場に関係なく議論できる環境を用意しておけばきっと良いレビューが増えるでしょう。
コードを書いた人ではなく、コード自体に意見するんだよ、ということ。
レビューの手法として取り入れ易いものをいくつか例を挙げると
＊ペアレビュー
コードを書いた人とレビューする人がペアで進める手法。
2人で進めるため、抜け漏れがあるかも。
＊パスアラウンド
複数人が非同期でレビューする手法。
GitHubやGerritを利用するのが多い。
＊アドホックレビュー
必要になった時にチームメンバーにコードをみてもらう手法。
これが一番ハードルが低いと思います。
あとは、ブランチにコミットする前にレビューするのか、後にレビューするか。
非同期でレビューを行うならば、コミット後の方が都合が良いでしょう。
ただ、手法はいくつもありますが、どれも完璧ではないので、
複数組み合わせたり、ペアプログラミングと組み合わせたり、
より自分たちに合ったやり方を探す必要があります。
（パスアラウンド＋アドホック＋たまにはペアプログラミングがやり易いかな）
＋テスト駆動開発でバグのないキレイなソースコードでハッピーになりましょう！
参考文献：
http://gihyo.jp/magazine/wdpress/archive/2013/vol72
参考URL：
http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC
https://speakerdeck.com/fujimura/aiminggithub
自作node.jsフレームワークと nginxを使ってラジオサイトを作ってみた
はじめまして！ エンジニアのちゃん武です。
CyberXエンジニアブログ初の投稿ということで、
緊張のあまり手をガタガタさせながらこの記事を書かせていただきました。
さて、初投稿のブログですが、
「node.jsとnginxでラジオサイト作りました！」
という内容でブログを書かせていただきます。
node.jsやnginxと聞くと、中小企業やスタートアップを中心に、
尖りに尖ったエンジニアたちが使い始めたおかげで以前に比べだいぶ認知度も上がり、
socket.ioを中心としてリアルタイムウェブプログラミング環境の代名詞としてその名を世に知らしめていることと思います。
僕も、以前から興味を持っており、node.js周辺の勉強会などにちょこちょこ参加させていただいていたのですが、
仕事での開発とプライベートでやっているサービスの開発と運用で、node.jsさんに時間をかけることが出来ずにほったらかしにしておりました。
しかし、とあるチャンスが僕に到来します。
なんと、知り合いのデザイナーとダブルパーソナリティでラジオ番組を始めることになりました。
ラジオをやるということは、もちろんWEBサイトが必要ですよね？
というこで、node.jsを使ってwebサイトを作ることにしました！
ただ、一言でnode.jsを使ってサイトを作るとはいえ、
スクラッチで書いたり、FWを使ったり、サードパーティ性のモジュールやライブラリを使ったりと色々な開発スタイルがあります。
が、ここでフレームワークを使ってしまったら、node.jsでのプログラミングのイロハをなんとなく理解した気になって大人になってしまう 汗。。
と思い、時間はあまりかけられませんが、自分でプチフレームワークを作って勉強しがてらサイトをつくろうと決めました！
その開発までの経緯から、設計・開発、完成までを資料にまとめて社内勉強会で発表したので、
その記事を添付させていただきます。
■自作node.jsフレームワークとnginxを使ってラジオサイトを作ってみた
＊資料中のコードは若干端折って書いております。
2日で作ったので、各モジュールごとの結合が高かったり、
割と強引なことをしていますが、何よりも、javascriptでWEBサーバーや
MVCフレームワークを構築する作業はハマったところも含め、自分の知見が広がりとてもタメになるものでした。
ただ、結論として、普通のWEBサイトを作るだけなら、
phpやruby、pythonなどで本当に十分です！！！笑
理由としては、きちんとしたクラス設計が出来ない、イベントドリブンスタイルであり、
手続き型の言語になれたプログラマには少し理解に時間がかかるというjsの言語仕様的なポイントと、
慣れないシングルスレッドのイベントループモデルであることで、それによって起る問題を推測しにくいといったものです。
ただ、僕はnode.js大好きです♥
次回は、socket.ioを使ったリアルタイムウェブプログラミングやネットワークプログラミングなどnode.jsの得意な部分を使ったサービスを開発して、みなさんに発表したいと思います。
CyberXエンジニアブログをお読みいただきありがとうございました。
CyberXエンジニアブログ初の投稿ということで、
緊張のあまり手をガタガタさせながらこの記事を書かせていただきました。
さて、初投稿のブログですが、
「node.jsとnginxでラジオサイト作りました！」
という内容でブログを書かせていただきます。
node.jsやnginxと聞くと、中小企業やスタートアップを中心に、
尖りに尖ったエンジニアたちが使い始めたおかげで以前に比べだいぶ認知度も上がり、
socket.ioを中心としてリアルタイムウェブプログラミング環境の代名詞としてその名を世に知らしめていることと思います。
僕も、以前から興味を持っており、node.js周辺の勉強会などにちょこちょこ参加させていただいていたのですが、
仕事での開発とプライベートでやっているサービスの開発と運用で、node.jsさんに時間をかけることが出来ずにほったらかしにしておりました。
しかし、とあるチャンスが僕に到来します。
なんと、知り合いのデザイナーとダブルパーソナリティでラジオ番組を始めることになりました。
ラジオをやるということは、もちろんWEBサイトが必要ですよね？
というこで、node.jsを使ってwebサイトを作ることにしました！
ただ、一言でnode.jsを使ってサイトを作るとはいえ、
スクラッチで書いたり、FWを使ったり、サードパーティ性のモジュールやライブラリを使ったりと色々な開発スタイルがあります。
が、ここでフレームワークを使ってしまったら、node.jsでのプログラミングのイロハをなんとなく理解した気になって大人になってしまう 汗。。
と思い、時間はあまりかけられませんが、自分でプチフレームワークを作って勉強しがてらサイトをつくろうと決めました！
その開発までの経緯から、設計・開発、完成までを資料にまとめて社内勉強会で発表したので、
その記事を添付させていただきます。
■自作node.jsフレームワークとnginxを使ってラジオサイトを作ってみた
＊資料中のコードは若干端折って書いております。
2日で作ったので、各モジュールごとの結合が高かったり、
割と強引なことをしていますが、何よりも、javascriptでWEBサーバーや
MVCフレームワークを構築する作業はハマったところも含め、自分の知見が広がりとてもタメになるものでした。
ただ、結論として、普通のWEBサイトを作るだけなら、
phpやruby、pythonなどで本当に十分です！！！笑
理由としては、きちんとしたクラス設計が出来ない、イベントドリブンスタイルであり、
手続き型の言語になれたプログラマには少し理解に時間がかかるというjsの言語仕様的なポイントと、
慣れないシングルスレッドのイベントループモデルであることで、それによって起る問題を推測しにくいといったものです。
ただ、僕はnode.js大好きです♥
次回は、socket.ioを使ったリアルタイムウェブプログラミングやネットワークプログラミングなどnode.jsの得意な部分を使ったサービスを開発して、みなさんに発表したいと思います。
CyberXエンジニアブログをお読みいただきありがとうございました。