今年で回目となる「東京Node学園祭」に参加した、まとめ感想

振り返るとどうやら、第1回目の東京Node学園祭に参加してたようだ
そのときは、socket.ioの作者、Guillermo Rauchライブコーディング
強烈だったのを覚えている

今年も盛りだくさん
RoomAとBに分かれてのセッションだったため、
自分の聞いたセッションの中で気になったものを
以下、まとめと感想

1.ウェブ初心者が Electron でフロントエンド入門した話
@Linda_ppさんの発表

Electronをそろそろ触りたいなーと思っていたいので、非常にわかり易い解説で
大変勉強になりました
そもそものElectronが動く仕組みの話や、
初心者が陥り易いワナの解説もあって、
うなずくばかりでした

2.大規模Node.jsを支えるロードバランスとオートスケールの独自実装
@kidach1さんの発表

Node.jsで本格運用しようとおもったら、誰もがはまる道、
スケールさせるにはどのような構成にするべきか、という話

もちろん、この発表はオートスケールまで考慮してありますが、
自分が一番共感したのは、スケールするための設計のはなし

たぶん、どこも同じ結論に達するのではないかと思ってます

基本的に、リアルタイム通信(Websocket)を使うところは
振り分けサーバから、同じルームに入る人は
同じプロセス(同じメモリ空間)に割当てしまうのが
最終的には妥当(楽!)、というかんじ

過去に携わったプロジェクト(今も運用中だけど)ではPub/Subをつかって違うプロセスにいっても
問題にないようにしていましたが、
そもそも振り分けサーバでユーザを振り分けしていたので
同じプロセスかどうかまでみて、振り分けてしまえばよかった
(Pub/Subをつかわなくてもすむので)

オートスケールの話とか、FRPの話とかは、自分にとっては
わりとおまけ的に感じました
(オートスケールの話だったら、セッション数によって増減する
 サーバの数とか可視化してくれたらわかり易くて面白かったと思います)

3.Node.jsでのゲームサーバ開発 愛すべきバッドノウハウ3選
@qsonaさんの発表

身内の発表でしたが(事業部が違うので内容は楽しみました)
Nodeあるあるって感じの話でした

asyncまわりのコーディングルールは、過去に携わったプロジェクトでも
悩んだ結果、一定の書き方に落ち着いたという経緯があったので
ふむふむ、といった感想

uncaught exceptionをどうするってはなしも
プロジェクトの最初でルール決めしました

domainをつかって握りつぶす話も当然ありましたが、
結論、バグの検知が遅れる、という理由で
そのまま、想定しないエラーが起こると
プロセスが死ぬつくりに(遅くともステージングで気付くでしょってはなし)

テストが必須のプロジェクトだったので、
そんな大変な事にはならなかった、というのが救いどころ

※資料はまだ公開されていません(11/9時点)

4.フロントエンドに秩序を取り戻す方法 ~はてなブログ編集画面をリニューアルするためにやったこと~
@amagitakayosiさんの発表

これは、きいているのが、めっちゃおもしろかった

率直におもった感想が、はてなのブログの開発ですら
混沌としたファイルがあるということ(1ファイル5524行!)に
桃源郷はないんだ!
思ってしまいました

秩序はどこのプロジェクトでも求められるものなんだなと

このあたり(秩序を失う事)は、散々過去の経験から学んだので、
最初に全力ださないとな!と再度おもったところです

この発表で参考にしたいな、と思ったのは
技術選定するときの理由のところ

もろもろ要件があるところですが、
重視したのは、一旦決めた技術のもう一度移行するときのコストを
考慮している点

要件ばかりに目がいきがちですが、
この考え方には、はっとさせられました

自由過ぎるものを除外してたのも、自分としては好感がもてました!

5.unassert: JavaScript でも契約による設計で堅牢なプログラミングを行う
@t_wadaさんの発表

powera-assertにつづき、unassertという
優れものライブラリの紹介!

とにかく、つかえってかんじです

6.CyberAgentゲーム事業Node.js編
弊社グループの石川くんのスポンサーLTの発表

弊社でもNode.jsをこんな風につかってきました、という事例
よく考えると、
Node.jsとMySQLという組み合わせも珍しいかも
それなりにMySQLとの連携は問題なく動いてます

スポンサーセッションは
Kaizenさんの子連れLTからはじまり
dwangoさんの○○事業はじめます、のぶっちゃけトークがあったり
思いのほか楽しめました

東京Node学園という名前も
ぐぐったときに
もしかして"東京Node学園?"とでてきてほしい
というおもいからつけた、という、やっぱりね、という話も聞けました

自分自身、実は、Node.jsでプログラミングしてないですが、
まる1日たのしめたNode学園祭でした

来年も参加するぞ!

第95回 PHP勉強会@東京に参加してきました。

PHPカンファレンスのLTで話そうと思っていたネタを
今回のPHP勉強会LT枠で話しました

ISUCON5 予選をPHPで戦った話です。

ISUCON5の予選は悔しいことばかり
スライドに書き忘れましたが
提供されていた環境のPHPのバージョンは5.6だったので
PHP7を試すのは結構ありだったなー、と今さらながら思ったところです

第95回  PHP勉強会@東京も様々な発表がありました

以下、まとめと感想です

まずは、@tomzohさんの
「Speeding up the Web with PHP 7 おさらい」

PHPカンファレンスのラスマスさんの講演のおさらいです
ちょうど講演の時間は、自分のセッションの発表とかぶっていたので
きけなかったのですが、このおさらいでおおよそ内容を把握する事ができました

個人的にはPHP7のExceptionがキャッチできるようになる話は
やっとかー、ってかんじです
いままでのtry-catchは、catchする前に死ぬ事があったので
あんま意味ないなーと思っていたので

isset地獄から抜けられるかもしれないオペレータ(??)の追加はいいですね

最後のベンチマークの話は、試してみようかなと思っています

GCC Feedback-Directed Optimization (FDO)
$ make clean
$ make -j8 prof-gen
...
$ sapi/cgi/php-cgi -T 1000 /var/www/wordpress/index.php > /dev/null
$ make prof-clean
$ make -j8 prof-use

PHP7は期待いっぱいです

次に、@wa_teradaさんの
ReactJS を PHP で理解する

ReactJSを理解するためにPHPでReactJSを再現する話
かなりぶっとんだ内容です
会場がわきました

ReactJSのチュートリアルをPHPに移植したデモ

ReactJSはブラウザ上のJavaScriptで動作するので
サーバサイドのPHPでどう再現するだろう、とおもったら
ajaxの部分から全部、サーバ側へ処理をもっていく荒技

POSTボタンをおすと、ページがリフレッシュされます
(サーバ側でHTMLを組み立てるので)

ReactJSとのPHPで再現したソースとのdiffがおもしろかったです

次に、M.Okazakiさんの
PHPでRaspberryPi

会場で実際に動いているものをみないと
面白さがつたわらないので残念ですが
RaspberyPiをPHPで制御する話です

Lチカからはじまり
サーボモータ
温度計
最後に
全部あわせたやつ

と、デモは最高に面白かったです

次に、mizukiさんの
「PHPプロファイラについて」

サイトがおもい、という問い合わせをうけ
PHPプロファイラを用いてチューニングする話

uprofilerとかblackfireの単語がでてきましたが
使った事がなかったので、次の機会に使おうかとおもってます

オチの
おそかったのは、JavaScript
JavaScriptをキャッシュさせたら解決した
というのは爆笑でした


次回もPHP勉強会に参加します
ブログ再開!

技術ネタを引き続き書いていきます

いまさらな話ですが、iOS9bundle Identifierではまった話を書きます

iOS9がでて一ヶ月が経とうとしています

以前から社内では
モック段階のアプリをOTA(Over The Air)
インストールしていました

iOS9でOTAでインストールしようと思ったら
InstallError

エラーが発生

Deviceのconsoleログをしらべてみると
-----------------------------------------

 Oct 10 19:36:43 GoodooiPad itunesstored[121] &ltWarning>: BundleValidator: Failed bundleIdentifier: com.example.foo-in-house does not match expected bundleIdentifier: com.example.foo-inHouse

-----------------------------------------

BundleValidator:Failedの文字が!

アプリのbundle Identifierを確認してみると
com.example.foo-inHouse
でした(名称は仮称です)

どうやら、OTAでインストールさせようとしたときのリンク(plistの記述)がおかしいらしい・・・

確認したところ次のような記述になってました
-----------------------------------------

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
&ltplist version="1.0">
&ltdict>
&ltkey>items</key>
&ltarray>
&ltdict>
&ltkey>assets</key>
&ltarray>
&ltdict>
&ltkey>kind</key>
&ltstring>software-package</string>
&ltkey>url</key>
&ltstring>https://example.com/foo.ipa</string>
</dict>
</array>
&ltkey>metadata</key>
&ltdict>
&ltkey>bundle-identifier</key>
&ltstring>com.example.foo-in-house</string>
&ltkey>bundle-version</key>
&ltstring>1.1.0</string>
&ltkey>kind</key>
&ltstring>software</string>
&ltkey>title</key>
&ltstring>Foo</string>
</dict>
</dict>
</array>
</dict>
</plist>

-----------------------------------------

なんと、bundle-identifierが
まちがった文字列
com.example.foo-in-house
になってました(ぐぬぬ・・・)

いままで(iOS8)までは、このplistのbundle-identifierが
ダウンロードするipaのものと一致していなくても
問題なかったんですね(逆にびっくり)

iOS9から厳密になってインストールエラーになったというお話でした

ぐぐっても日本語の情報にすぐたどりつかなかったので、ブログネタとしての投稿です
「PHPerにも出来た
 初めてのChefの教室 #eytokyo」


の勉強会へ参加してきました。

phpmastsuri2012
吉羽さんのおはなし
を聞いてから

・全てを自動化する
・全てをバージョン管理下におく


という考えを実践しようとおもい、
Chefに興味を持ち始めました。
(以前はPuppet派でした)

そこへ、Yandoさんが主催のChefの勉強会が開催されるということで
ナイスなタイミングでした。(開始2時間ほどまえに1席あいていたので滑り込みました。)

naoyaさんのblogの記事を見ながらVagrantknife-soloを試していたのですが、
ChefのRecipeってかくの面倒だなー、と思っていました。

そんななか、Recipeについて
勉強会で良い情報をいただきました。

「先人たちのRecipeがGithubにある」

https://github.com/opscode-cookbooks
https://github.com/rightscale/cookbooks_public
https://github.com/engineyard/ey-cloud-recipes
https://github.com/aws/opsworks-cookbooks
https://github.com/pivotal/pivotal_workstation

などなど、


Yandoさんのプレゼンで紹介があったのですが、
実際につかわれているRecipeはすごく参考になります。
(pivotalのRecipeは面白かったです。Macの壁紙のRecipeとか)

じっくり読んでみたいと思います。

Yandoさんのプレゼンで何がささったかというと

「Engine Yardは
 Gentoo Linux + Chefで
 できている!」

だったりします。

ちなみに、私は、元、Gentoo Linuxユーザです。
(Gentoo Linuxっていいですよね!)


様々な人のLTがありましたが、
先日AWSから発表のあった
AWS OpsWorksのLTが興味深かったです。
実際にはつかってみないと、ってとろこですが、
便利そうなのがわかりました。

ただし、吉羽さんのプレゼンにもありますが、
自分が考えているインフラの現在の方向性として
開発環境の構築の仕方と
本番環境の構築の仕方を
同じ手順でやりたいと、考えています。
そのため、
AWS OpsWorksをつかうかどうかは
検討が必要だなというイメージです。
(AWS OpsWorksは便利なのですが、
 いくつかWeb経由になりそうなので(APIはまだ調べてませんが、))

また、様々な人の話を聞くにつれ、
Chef-soloをつかって実際に運用してはまりそうだなと
思ったのが、Recipeのテストの話です。



test-kichenつかってますか?
とか(参加者のなかではあまりつかわれてなさそうだった)

・VagrantでSaharaつかって
いじくりまわしてみる、(naoyaさん談)
とか

knife solo cook <host> -W
とか(why-runはわりとみなさんやってるかんじでした。)


Chefをつかって運用を始めた場合、
Recipeの保守で困ることがおこるかもしれないので
ここらへんは押さえておきたいですね。

「Chefの実行は冪等であるべき」
(複数回実行しても影響が無い状態にすべき)

どなたかの発表の中で出た話ですが、
Recipeの作成方法の気をつけるべき点がわかってなかったので、
はっとしました。

自前Recipeを書くときには要注意ですね。


以上、勉強会のレポートでした。

ちなみにタイトルは naoyaさんのBlogの記事をオマージュしたものです。


Node.js史上最高のIDEといううわさのCloud9を
Macでつかいたくなったので、インストールしてみた。

以下、結構はまったので、インストールメモ。

一番最初に大事なことを書いておきます。
はまったのは、node.jsのバージョン

「You should use 0.6.x, not 0.8.2. Cloud9 isn't compatible with 0.8 yet.」
引用もと:https://github.com/ajaxorg/cloud9/issues/1900

つまり、Cloud9はまだ、node.jsの0.8.xに対応していない!

Macportsだと、0.8.3がインストールされてしまうのですが、
このままだとCloud9はインストールすらままならないです。

というわけで、まず、node.jsの0.6.20をインストールすることにします。

node.jsのバージョン管理ツールは
nvmと
naveと2種類あります。

どちらでも好みのものをつかってよいとおもいますが、
自分は、naveを使いました。


$ git clone git://github.com/isaacs/nave.git
$ cd ~/nave
$ ./nave.sh install 0.6.20

しばらく時間がかかりますが、node.jsのバージョン0.6.20がインストールされます。

$ cd ~/nave
$ ./nave.sh use 0.6.20

0.6.20を使うように指定します。

つづいて、Cloud9をインストールします。
githubからもってきます。

$ git clone git://github.com/ajaxorg/cloud9.git
$ cd ~/cloud9

naveでnode.jsのバージョン0.6.20の環境でnpmをつかって必要なモジュールをインストールします。

$ cd ~/cloud9
$ npm install

だいたい必要なものをインストールしてくれるのですが、
依存関係が完全ではないらしく、いくつかインストールされないモジュールがあります。
以下、手動でインストール

が、しかし、npmでみつけてくれないモジュールが1つ・・・
vfs-architectをうまくみつけてくれないです。

しょうがないので、githubからもってきます。

$ git clone https://github.com/c9/vfs-architect.git
$ cd ~/cloud9
$ npm install ../vfs-architect

上記、で無事vfs-architextはインストール
以下たらないモジュールのインストール

$ cd ~/cloud9
$ npm install jsDAV
$ npm install socket.io
$ npm install asyncjs
$ npm install vfs-nodefs-adapter
$ npm install v8debug
$ npm install amd-loader
$ npm install async
$ npm install sourcemint-loader-js
$ npm install ace
$ npm install treehugger

上記で多分全部たらないものはいれたはず・・

そしてcloud9の起動!

$ cd ~/cloud9
$ ./bin/cloud9.sh
make: Nothing to be done for `update'.
OSX
connect plugin start
Connect server listening at http://localhost:3131
MINT /^\/static\/bundles\/helloworld(?:.js)?(\/.*)?$/ /Users/sugu/GitClone/cloud9/configs/../plugins-client/ext.helloworld
info - socket.io started
IDE SERVER PLUGIN: auth
IDE SERVER PLUGIN: git
IDE SERVER PLUGIN: gittools
IDE SERVER PLUGIN: hg
IDE SERVER PLUGIN: npm
IDE SERVER PLUGIN: search
IDE SERVER PLUGIN: revisions
IDE SERVER PLUGIN: settings
IDE SERVER PLUGIN: shell
IDE SERVER PLUGIN: state
IDE SERVER PLUGIN: watcher
IDE SERVER PLUGIN: node-runtime
IDE SERVER PLUGIN: npm-runtime
IDE SERVER PLUGIN: python-runtime
IDE SERVER PLUGIN: apache-runtime
IDE SERVER PLUGIN: ruby-runtime
IDE SERVER PLUGIN: php-runtime
Started '/Users/sugu/GitClone/cloud9/configs/default'!
IDE server initialized. Listening on localhost:3131

localhostのポート3131を待受ポートとして起動しました。

おもむろにSafariで
http://localhost:3131
にアクセスする!

渋谷で働くソーシャルアプリエンジニアのブログ-cloud9

ブラウザ越しに動いているとは思えない、インターフェースです。

ただ、自分のなかでは、JavaScriptのIDEでいけてるのは
WebStormだとおもっているので、
使い勝手を今後比較してみます。