Webフロントエンド ハイパフォーマンス チューニングを読んだ

今週のお題「読書の秋」

Webフロントエンド ハイパフォーマンス チューニング

Webフロントエンド ハイパフォーマンス チューニング

だいたいサーバーサイドの仕事ばっかりやってるので、SQLのチューニングとか何かしらのアルゴリズムの選定とか極力オブジェクト作らないようにするとか、そういうところが高速化の主だったところなのだけど、フロントエンド側もちゃんと知っとかないとなーと思いまして。通勤中、地下鉄に乗る十数分だけ読み進めていっていたので、だいぶ長い時間かかって読み終わった。

内容的にはWebページをレンダリングするためにブラウザが何をしているか、DOMの操作でレンダリングパイプラインのどこに影響が出るか、CSSが変わった時にどうなるか、どういうことをすればその影響を限定できるか、などが細かく記されていてつどつど読み返したい内容だった。実際にはどれだけ時間切り詰めても、サーバー側で大量のデータを扱ったりするとどうしても時間がかかってしまうのでサーバーサイドもクライアントサイドも合わせて、ユーザーを待たせないUIを作らないといけないのだけどフロントエンド側の知識もこの本を片手に色々議論できるようになるんじゃないだろうかと思う。

読んだ端から割と忘れてるので、ささっと出せるようにしておきたいね。

Software Design 2016/12

ソフトウェアデザイン 2016年 12 月号 [雑誌]

毎月会社に送られてくるので一通り目を通すのだけど、今回はNoSQLまわりの話が気になったので。自社でつくってるものを考えると、基本的にはリレーショナルデータベースをもとに設計していくのが標準的なんだけど、でもJSONはよく使うからMySQLのJSON対応なんかはうまく使うと開発楽そうだ。MongoDBは前に個人の開発でつかったりしたけど、最近の動向は追っていなかったのでそのあたり書かれているのがよい情報源。

そういやMySQLといえば文字コード問題も開発環境をつくるときに引っかかったりするので、読んで頭にたたき込んでおこう。

余談。ITむかしばなしスペシャルをぱらぱら読んでいると、見知った名前が出てきたので思わず吹いてしまった。あの人ならまあこの内容だろうなぁと思ったので、元気そうでなによりです。

Spork使うことになったので、メモ他

Spork

今のプロジェクトで使っているRailsのバージョンが3系列なこともあり、最近は4系列の話ばかりWeb上の情報を拾ってしまうので、まとめたことなどをメモしておく。

sporkrb/spork

Sporkはテスト時のRailsサーバを予め起動しておいてテスト実行時間を短縮してくれるものという認識。

プロジェクトの方針としてなるべくユニットテスト書きましょうよって話になり、これまでも場当たり的にかかれていたのをきっちりやりましょうよということで、きっちり環境整備。Spork*1自体はプロジェクトのGemfileに入っていたのだけど、頻繁にブランチを切り替えるような使い方になると都度都度立ち上げ直すのもだるいので、プロジェクトとは別に導入。

gem install spork

後はコマンド叩いて起動。自分の開発環境ではtmuxinatorを導入してRailsサーバ、rails consoleなどを一斉に立ち上げているのでsporkも同様に立ち上げています。後、開発サーバがあってそこでみんなが揃って開発しているような場合、sporkの使用するポート番号がかぶるのでexport RSPEC_DRB=33334のように環境変数設定しておく。これをしておかないとrspec test.rbみたいにコマンド叩いてrspecを起動したときにデフォルトポートを使用しているsporkに接続して、意図と違うRailsサーバでテストを開始しようとするので注意。

テストでの悩みどころ

• プロジェクト柄、DB構造が結構複雑になっていてテストデータつくるのが大分つらい
  • テストケースもいろいろ考えられるので、このへんに時間かかるのは仕方ないと思いつつもうちょっとらくできないかと思う
• Ralisのバージョンアップが速いので、どれがどのバージョンの情報なのかわかりづらい
  • 常に最新バージョン使い続けるというものであればいいのだけど、移行も時間かかるしのう
  • Rspecにしても記述方法かわってたりして、なかなか大変

とにかくテストデータ周りはFactoryGirl導入とかそういう話ではなく、もともとの仕様が複雑になってるところが要因なのでなんとか楽にしたいなーと思う。プロジェクト内でもそろそろ技術的負債*2を返すための期間を設けようか、という話も出てきているので何かしらネタを考えておきたいな。

*1:Rails4系列ならrails/springなんだろうし、Rails3.2なら導入できたんだろうけどいろいろお察しである。

*2:出ましたねこのワード

「インフラエンジニアの教科書」を読む

インフラエンジニアの教科書

　前職で新人だったころはわりとサーバ室にこもりきりになって雑用をやってたんだけど、ここのところラックを見ることもなく、基本VimとRubyとデスクトップマシンを相手にしているところもあって、こういう本でざっくり知識を確かめておきたいなと思い購入。

　読んでみると文章は非常に平易に書かれているし、本当にエンジニア1年生が読むにはいい本と思う。もちろん全183ページで本当に基礎的なところ（インフラ構築ってなんぞや、SIerだと色々専門で分かれてるけどWeb業界だと全部やるよねとか、メモリ・CPU・OSの種類など）から始まってるので、マニアックな話まで載ってるわけではないが全体像をつかむのには持ってこいだと思う。（自分でも忘れているところなどが少し……）

　個人的には数ページでしたが、購買や資産管理について言及した章もあり大きい意味での運用の話もあって、おおっと思った。コラムに書かれていたロット不良やファームウェアバグの話も、過去にブレードサーバのランプが赤く点滅して死んでることが多発して（しかも挿し直すと治る）、結果ロット不良でしたというオチだったなどつらい思い出が蘇るほど「あるある」なお話でございました。

　もう少しLINEでの苦労話やLINEを運営するにあたって細かい技術的な話があると読み応えがあったかなと思います。本を読んでほしいターゲット層からすると、そういう話がなかったのはまあ分かるんですが、ちょっと物足りなかったかな。

はてまでいってしまえ 【サークル敷居亭C84新刊とかそういうの話】

　サークル敷居亭が世に送り出す今のところ区切りの最終巻となる新刊が完成しました。

　自分がそこそこ関わってるのはこちらの『敷居の部屋の終幕-Curtain Call-』。例の例の田村ゆかりライブに誘ってくれた人がアイドルのライブにたくさん行っているところに目を付けた@taitokuにそそのかされたので、交渉して引っ張ってきてみたり時々発破かけたり、魂の一選にウンウンうなって断腸の思いで一つに決めたり、誤字脱字チェックや文章のおかしいところをチェックしたりとやっておりました。
　まあ自身の転職活動とかでバタバタしてたり、大体伯爵ががんばってくれたおかげでお届け出来るようになりました。めでたい！

　表紙はお馴染みくらふと氏。最後にふさわしい晴れのステージに立つ彼女たちはいったい何を思うのでしようか？ この表紙のコンセプトが決まったのは大分前で、くらふと氏を含めた敷居体の一部が焼き肉を食べている最中でした。そのときに『カーテンコール』というタイトルも同時に生み出され、まさしく締めにふさわしい本と運命づけられたのでした。

　幕張で何が発表されるか分からないこの現状、過去・現在・未来のアイマスとニコマスをぎゅぎゅっと集めた『敷居の部屋の終幕-Curtain Call-』を読んでライブの日を待ちましょう。

こちらもお忘れなく

　テキスト系Web創作の今にがっつりと取り組んだこちらもよろしく。
　原稿読んでるんだけど、本当に面白いです。掛け値なしに。

情報

コミケ情報

　日時：2013年8月11日（日）（C84二日目）

　場所：東館O-49b（サークル敷居亭）

　価格：どちらもコミケでは500円（通販、委託は未定）

その他ブログ

• テキスト系Web創作の”今”を切り取る - 夏コミ新刊『敷居の部屋の最前線-Front Line-』
• 最後の？　敷居亭アイマス本 - 夏コミ新刊その２『敷居の部屋の終幕-Curtain Call-』
• 橙乃ままれ概論 〜名無しの「>>1」から物語作家に至った人物をひとつのSSから紐解く〜 - 敷居の先住民
• 橙乃ままれインタビューの一部を贅沢に公開しちゃうよ。（12438文字）
• 終幕だけど最前線—サークル敷居亭C84新刊のすすめ—

AngularJSをいじってたのでjsdo.itにおいてみた

個人的にちまちまやってることがあって、それの勉強として書いてみた。
ここのところずーっと端末の一機能（カード情報読み取ったりとか、バーコード読んだりとか）だったりして、そもそもWebのフロントエンドを弄る仕事がほとんどなかったりしたせいで、むかーしやってたことをだいぶ忘れていたりしたので簡単なコードでもなかなか大変だったりしましたが、Web系の開発も面白いなぁというのがここまでの感想。

ドットインストールの入門とかがわかりやすくて、フォーム系とかはまあまあわかった感じではあるけど、もっと深く突っ込んだところはまだまだピンッと来ていないので、Androiderに贈るAngularJS概説 #AngularJS #JavaScript - Qiitaなどを読みつつ深堀りして行きたい。

GitHub創設者の話を聞きに行ったのでメモをとってみた

GitHub創設者が語る"立ち上げから利用者300万人までの軌跡" | PeaTiX

---

Github創業者の話がキャンパスプラザ京都で聞ける！ということを一昨日知り、その場ですぐさま予約しまして、本日聞きに行ってきました。
近くの郵便局によってから会場に行くと、19:10ぐらいに到着。すでに席が半分ほど埋まっており、自分が座った後も次から次に人が受付に並んでいて、ほぼ満席になっていました。注目度の高さがうかがえましたねぇ。

以下、Evernoteに書き取ったメモ。大体のエッセンスを書いていっただけなので、多少意味が違っているかもしれません。

Githubができるまで

　はじめはGitHub COO PJ Hyett氏による今に至るまでの流れ。いろんなプロジェクトに関わったり、Rubyコミュニティで発表なりしていくうちにGithubにたどり着いた……アウトプット大事よねというのが感想。なにより楽しそうにやってるってのがいいなぁ。

　Before Github
　いろんな言語を勉強 -> Rubyにぞっこん 
　Wayfaring : Google Mapsでいろいろできる
　CHOWHOUND : Ruby on railsで一からリライト

　RubyについてのBlog立ち上げ　-> 人気になる
　CNETに嫌気 -> ruby on railsのコンサルを始める
　自由にやれると思った -> クライアントがボス
　試しに自由にサイトを作ってみる -> FamSpam -> お金にはならなかった

　Ruby meetups が増えてきた　-> Fun!
　meetupsのあとでGithubのアイディアを生み出す -> 翌日にGithubのドメインを取得

　forkをネガティブな意味からポジティブに！（コラボレーションのエッセンスとして）

　初期はヴィジョンが小さかった
　　gitの管理がめんどくさい -> そこを解消したい

　Engine Yard ： Ruby on railsのホスティングサービス -> 提携して良い効果（ホスティングは大変）

　beta版 少数の招待（メール通して）

　オフィス -> 2年ほどカフェ、レストランや自分の家でやってた。
　GithubでGithubを作る。Campfireが重要だった。

　ruby on railsがGithubにホスティングされる

　Scot -> ruby meetups, git meetupsで出会い、最初の社員になる。

　給料を払おう
　-> 毎月売上の目標設定を達成すればちょっとずつ上げていく。最終的にコンサルやっていたときと同じぐらいの給料になった。

　社員の殆どが社内では働いていない。
　オフィスにいることは必須にしていない。オフィスはみんなと交流する場。
　2010年に更に大きなオフィスに引っ越し。
　楽しいことを目的にオフィスをデザイン。仕事をすることが目的ではない。

Q&A

　みんながんがん英語で質問を投げるというなかなかすごい場に居合わせることができたなぁ。さっきの話にしてもQ&Aの内容を聞いていても思うのは、「自分たちが楽しいか、自分たちが必要なのか」がまずあってそこから掘り下げていく力がすごいなと。マネタイズなんか考えてねーよというある種の割り切り感も思考のシンプルさを物語っているなぁと思います。

　自分の好きなことをできるけど、管理出来る人がいないときはどうするのか。
　A： マネージャーがいない -> 好きなときに貢献できる
　　　たまにガイダンス必要な人がいるときはある。「一人で作業しない」

　Githubにホストされているプロジェクトの質の高さ -> スタンダードが高いから。
　Githubの社員が特別なわけではない。トップダウン型ではなく、みんなが好きな事ができるようにしている。

　なぜ最初からビジネスモデルを立ててやったのか、投資家から資金を募らなかったのか
　-> 以前やったサービスで無料ばらまいたらコストがえらいことになったので、
　　はじめからビジネスモデルを定めた。
　　投資家には口出されたくなかったのでアプローチしなかった

　Githubでのコミュニケーション
　-> githubで管理、メールやCampfireも使ってる。非同期でやってるよ。

　Githubのテストが早いけど、ほんと？ なにか工夫している？
　-> ほんと。テストはたくさんやるので、プライオリティ高いのでリソースをかけてる。

　エンジニアとかパートナーシップはどこでみつける？
　-> ruby meetupsとか2年ぐらいかけて信頼を積み重ねた

　なんでrubyとかrailsを使ったのか。他の技術はどうなのか。
　-> 開発の経験が大きかった。rubyは読みやすい。

　開発者じゃない人にもGithubを使わせるような今後の展望があるか。
　->それぞれにいいソリューションがある。githubはdiffしてmergeして、振り返れるコードに着目。

　新機能出すときのプロセスは？
　-> オープンソースみたいな感じで開発してて、勝手に新機能を追加。
　　気に入ったらパブリックに出される、気に入らなかったら戻される。
　　マネタイズの部分は見てない、開発者にとっていいか悪いかを考えている。

　会社つくるときに集まって起業しようという目的意識があったのか？ 自然と集まって至ったのか？
　-> 一緒にしたいという気持ちはあったが、どちらかというと自然とそんな感じになった。

　給料とかどう決めてるの？
　-> しばらくみんな同じ給料な時期があったけど、今は前の会社の給料に+5000ドルして決めてる
　　互いに評価したりとかしているわけではない。

　その人といて楽しいかどうかが重要！ 
　いっしょにいたことがある人とやるのが、大切（前田さん）

　はじめの目的（gitホスティングを簡単にする）から変わってきたのは何がきっかけ？
　-> 自分たちで使ってきてソーシャルコーディングのほうに変わってきた。
　　コラボレーションすることがいいよねというのがわかってきた。

　Githubの成功って他のOpensourceにも適応できそうだけど、どう？
　-> ユーザにとって一番いいものにフォーカスしていかないと、成功しないのじゃないか

　Github上で政治的なコラボレーションはどうか？
　-> 実際に例はあるが、githubはプログラムに適応してる。他の場所で同じようなコラボレーションをするところが出てくるのではないか。

　売上の企業と個人の割合
　-> 7:3ぐらい

　Github最大のピンチとそれを乗り越えた方法は？
　-> 特に大きなのはなかったけど、なにか危なそうなところとかはその後できっちり対策たててる。
　　情報発信大事！ 

　Githubのコラボレーションの側面ははじめから考えがあったのか、それともユーザの中で醸成されていったのか。
　-> 哲学があったわけでもユーザがいたためでもなく、自分たちに必要なものを追加していったらそうなった。