しるろぐ

いろいろ書きます。

最近のお米の炊き方

友達に炊き方教えるついでにブログに書いておく。
結構適当な感じでやっても炊けるので、時間とか量とか適当に変えてみて味の変化を楽しむと良い。

米を洗う

いつも通りに洗う。
最初の一回で米が水を吸うらしいので、最初だけブリタの水使ってるけど、味変わってるか分からん。

水に浸す

30分から1時間ぐらい浸す。

鍋にいれる

浸した水を捨てて、米を鍋にいれて、米と同じ量だけ水を入れる。
同じ容器で同じ量だけ入れてあげればOK。分量的には、米の1.n倍とからしいが、米の隙間がいい感じなので同じ容器ではかるとよしなに1.n倍になってくれるはず。

強火でふきこぼれる寸前まで

大体5分ぐらい。
やばいやばいって火を弱める。

弱めた感じで10分ぐつぐつ

吹きこぼれるギリギリが良いらしいけど、自分はひっついてるの面倒なので、最初の5分はちょっと安全な火加減にしておいて、水分減ってきたなってあたりでちょっと強めてあげてる。
大体合計で10分ぐらいぐつぐつしてると、チリチリって音がなるので、いい音だなーってちょっと音を楽しんだら、強火で10秒20秒すると良い感じにお焦げができる。土鍋だと。普通の鍋だともうちょい必要な気がする。

15分ほど蒸らす

蓋は開けない。
一瞬開けて真ん中にお箸で穴を開けると良いって聞いたことあるけど試したことない。

混ぜてできあがり

食べるなりパックに入れるなりしよう。

はてブのTwitter連携で投稿されるURLをコメントページじゃなくて元ページにする

はてブ経由でTwitterに投稿されたURLがいつの間にかはてブのコメントページになっていて、2クリックするの嫌だなーと思っていたら、設定で変更できるらしい。

f:id:ofsilvers:20130701112349p:plain

ここのチェックを外せばOK。
告知見てなかったのであまり言えないけど、デフォルトが変わるのはなあ……。

#frontrend Vol.5に行ってきた

2013/05/25にサイバーエージェントで行われたFrontrend Vol.5に行ってきました。

Frontrendは今年の2/9に行われたVol.4に参加したのが初めてだったので、今回が2回目の参加でした。今回は、アメーバ水の提供がありました。サイバーエージェントの皆様ありがとうございました。

Functional JavaScript with Lo-Dash.js

lodashについて。
Functional JavaScriptってなんやって話と、underscoreと互換性があってパフォーマンス上がってるlodashが素敵!という話だった。

http://jsperf.com/lo-dash-v1-1-1-vs-underscore-v1-4-4/2 で比較されてるやつ見ると、ブラウザによっては逆転しているところがあって、敢えてunderscoreをlodashにしなくても良いかなーと思ったけど、deep cloneがあるのでとても心が揺れ動いている。undersocreにはない。
あとカスタムビルドも素敵。underscore build, backbone buildみたいなのもある。

Flash Toolkit for CreateJSで作るスマートフォン用アニメーション

最初の発表の予定だったが、機材トラブルで2番目の発表に。
CreateJSの紹介やハマリどころなど。

CreateJSは昔ちょっと調査したことがある。
そのときは、そもそも自分がFlashあまりできないのとで敬遠してしまったけど、話を聞いてみるとちょっと試してみる価値はあるかなと思った。
ワンソースでいろいろ対応できるのはよい。Flash経験者は無条件でかぶりつくのかな。わからんけど。

出力されたJS直にいじることはありますか?という質問があったけど、

  • 色をランダムにしたり
  • サーバからデータを渡すところをごにょったり

程度らしいので、あっちいったりこっちいったり行く心配なくて良かった。

あと、GalaxyはやっぱりGalaxyだなって思った。

Amebaプラットフォームの作り方

chikuwa.jsについて。

面白いなーと思ったけどJSにViewテンプレート書くのが気持ち悪すぎる。
すっごい細かくパーツ化できているからやれることなのかなと思ったけど、HTMLはもうちょっと生っぽく書きたいなと思った。
CPU負荷が高いのはこの仕組みだとどうしようもない気がする。

いろいろ刺激になったので設計思想とか聞きたいなと思った。

終わり

Vol.4に続いてVol.5も参加させていただきましたが、前回に引き続きとてもおもしろかったです。今回は主催の人がピザの決裁権限を持っていなかったそうなので、次回はピザ決裁権限もらえると良いですね!

スライド上がってるの見かけたら載っけます。

O'ReillyのEbook購入時に領収書をもらう方法

最近、オライリー電子書籍を領収書付きで欲しいなと思って、問い合わせてみた。

発行方法

注文後に届くメールアドレス宛に

  • 購入を特定できる情報
    • paypalのメールアドレス
    • 大体の購入日時
    • 購入金額
  • 領収書の宛名

を送れば良いっぽい。
領収書は、pdf形式で送ってもらえる。

サンプル

ちなみにぼくが送ったのはこんな感じで、大体30分ぐらいでpdfが送られてきた。

取引日時:2013年2月20日 11:03:46 JST
購入金額:2,184 JPY
購入書籍:モバイルデザインパターン
メールアドレス:自分のメールアドレス
領収書の宛名:自分の名前

ファイアピストンに心惹かれる

【物理】未だに隕石が高温になるのが摩擦だと言ってる奴多いが 宇宙&物理2chまとめを読んでいたら、>>23にファイアピストンという道具が紹介されていてすごい心惹かれるものがあったので、動画載せとく。

実際に火をつけるのは2:40ぐらい。

ファイアピストンの仕組みは簡単で、ピストンを勢いよく押し込むことで断熱圧縮によりシリンダー内を高熱にさせるというもの。たったこれだけで火がおこせるというのがすごい。

そういえば、火をおこすと言えば最近衝撃を受けたのは次の動画。

煙草とか吸わないのに欲しくなってくる。

GREE Tech Talk: GitHub:E Casual Talk に行ってきた #greetech02

2013年1月23日に開催されたGREE Teck Talk #02 : GitHub:E Casual Talkに行ってきたのでメモ。

全体の感想

ちょっと導入を考えていたので、勉強になった。そして、ちょっとくじけた。

PullReqとかGHEの恩恵とかを理解していれば全然高くはないと思うんだけど、最初の導入時のハードルがでかいかなという印象。今のままでいいじゃん、って声が多分たくさんあがる。お金さえあれば、「まあまあ、試しに使ってみてよ」ってのんびり検証しつつ徐々に移行とかできそうだけど、そうでないなら、ちゃんとした計画立てないとつらそう。

ということで、本気で人やプロジェクトが多くなって「レビューつらい」と思うまではちょっと待っても良いかなという結論に落ち着いた。


19:00 トラブルシューティングから見るGitHub:E運用の勘所

グリー株式会社 大場光一郎

内容と感想

greeがたくさん苦労したからみんな楽してるんだ!という話。
一人あたり$20/monthぐらいなのでコーヒー二杯分(帝国ホテル)ですね!これっぽち払えない会社なんて!


19:20 GitHub:Eじゃなくてもいいじゃん

株式会社ドリコム Takafumi ONAKA

内容と感想

subversionからのGHEはさすがに厳しいので、まずは無料のgitlabで肩慣らししてる。でも、お金があったらGHEで問題ないよ、という話。

たしかに、subversionからgitは色々使い勝手違うし、暗黒時代の便利ツール群なんかも使えなくなるので、厳しそう。gitlabはrails詳しい人が社内に多ければいいかなーとも思うけど、gitlabメンテナンスのコスト考えるとGHEでいいんじゃねって気がする。

PullReq文化 VS お金というのは、すごい分かりやすいけど、PullReq文化に慣れてない人にどう文化を広めるかが大変そう。そこを、ドリコムはgitlabで文化浸透させてるみたいだけど、他の方法としては、なんかうっかりしちゃっても問題ないやつをgithubのプライベートリポジトリで運用して慣れさせるのもありかなって思った。文化広めるだけなら。

19:40 GHEとAWSと私 クックパッド

クックパッド株式会社 高井直人

内容と感想

githubを使わないのはセキュリティ上の理由と、落ちたら困るから。
でも、開発者が増えてレビューが辛くなってきたのでPullReqしたいよねっていうのでGHE導入を検討。
今の運用とできるだけ変えたくないので、開発環境と自社のgitサーバーの間にGHEを入れて、GHEにデプロイはgitサーバーからにすることでGHEが落ちてもデプロイだけは出来る状態にしたという話。

Chrome拡張でfavicon変えてミスしないように、というのが面白かった。大事!

資料

20:10 なめらかにGHEに移行する方法

株式会社はてな Yohei Fushii

内容と感想

リポジトリが多いし、一気に移行すると混乱するのでなめらかに移行したい。
GHEと自社のリポジトリをミラーリングして、どっちを利用しても自社のリポジトリにはすべてのプロジェクトがある状態を保った、というのはクックパッドに似てる。

スライド

20:30 ペパボでのちょっと変わったGitHubの使い方

株式会社paperboy&co. Gosuke Miyashita

内容と感想

ペパボでの GitHub の使い方 - Gosuke Miyashitaとほぼ同じ内容。

ペパボはGHEじゃなくてgithubでサービスごとに組織アカウントを持っているらしい。
デザインプロセスの共有に使用するのはイイナと思った。
質疑応答で、デザイナはどうやって使ってる?という質問があったが、コマンドラインを使ってるらしい。すごい……。

ちなみに、当日の朝、GHE導入が決定したらしい。


20:50 GitHub:e運用錬金術!?

株式会社ディー・エヌ・エー 吉田拓真

内容と感想

「無理矢理書き換えて」「えっ」

スライド


21:10 特別講演:GitHubEnterprise

GitHub Inc. Drew Woods

内容と感想

次のリリースの内容とか。
どれぐらいのスペックがあればいいのさ、という質問があって、金と相談ではあるけど、最低メモリ8GB(可能なら16GB)でディスクIOは大切。CPUはさほど重要じゃないよという回答。あとは、ルートパーティション満杯にならないように気をつけてねとのこと。


#cross2013 で継続的サービス改善について話してきました

エンジニアサポートCROSS 2013の「継続的サービス改善のゲンバのハナシ」というパネルディスカッションに参加してきました。

実はこういうイベントで話すのは初めてで、すごい緊張してしまい、質問に答えるだけでいっぱいいっぱいだったのですが、何かひとつでも参考になる話ができていれば嬉しいです。
セッションオーナーの@tagomorisさん、一緒に登壇した@kentaroさん、@oranieさん、@tokorotenさん、ご来場の皆様、ありがとうございました。

話した内容

質問は結構範囲が広かったので、簡単にまとめづらいですが、一言でいうと「ユーザをちゃんと見る」ということを中心に話していました。サービス改善に限らず、集団でプロジェクトを動かすと、政治的なしがらみとかいろいろ面倒なことがあると思います。そんな中でプロジェクトの方向を定める一番の指標はユーザです。ユーザに価値を提供できるか、ユーザの問題を解決できるか、ということを考えれば、自ずと改善マインドが育って、継続的なサービス改善につながるんじゃないかなと思います。

サービス改善と聞いて何を思い浮かべるか

そんなわけで、ぼくがサービス改善と聞いて最初にやるのは、ユーザ目線での不満の洗い出しと解消です。自分たちのサービスは自分たちが一番使っていると自慢できるぐらい使い倒して、元々そのサービスが提供したかった価値がきちんと提供できているかというのを確かめます。その上で、企画者が考えるユーザ体験と、実際のユーザ体験との差を埋めるようにサービスを改善していきます。もちろん、ユーザ体験が大幅に違う場合は企画自体の見直しも視野に入れます。

また、これは個人的な好みなのですが、とにかく早いサービスが好きなので、表示速度の改善は常にやります。どこが遅いのか調べていると、サービス全体を触ることになるので、不満の洗い出しにもちょうど良いです。

サービス状況の把握

ユーザを第一に考えるにはユーザの声を拾う必要があります。自分が不満に思うところを解消、というのはある程度は良いのですが、一定の改善ラインを超えるとあまり役に立たなくなります。

ぼくがやったことをあげると、ページ速度の改善については、それ専用の社内サービスみたいなものを立ち上げて、だれでも、すべてのサービスの表示速度・SQLの実行速度を確認できるようにしました。これは週に一度レポートメールを送るようにしています。「だれでも」というのが重要で、ページ速度の改善は理解されにくく、「そんなことしてる暇があったら新しい機能を」みたいな返答をされたときに突きつけるためです。二月ぐらいデータ取ると、このページが徐々に遅くなってるねーとか、この新しく入ったクエリ遅いねーとかいろいろな発見があって面白いです。

ユーザの声については、ソーシャルメディアや某巨大掲示板の発言をIRCに流すようにしました。昔はユーザの声を拾うにはユーザ座談会やアンケート、お問い合わせぐらいしかありませんでしたが、最近は便利ですね。リアルタイムに情報が流れてくるので、不具合の発見につながったり、ユーザからの良い評価でモチベーションがあがったりして大変よろしい。弊社はIRCがあるのでそれに流していますが、そういったコミュニケーションツールがない場合は、それ用の社内サービス作ったり、メールで社内orプロジェクト全員に送ると良いんじゃないかなと思います。こちらも、だれでも見れるというのが重要です。

エンジニアと営業企画との対立


まーこの通りなんですが、立場ごとに向いている方向が違うと、意見が対立してしまったりしますが、ユーザを中心に考えれば対立なんてしないんじゃないかなーという考えです。もちろん、ユーザのためになるから一週間かかる作業を今日中に作ってよ!みたいなことを言われたら突っぱねますが、そういった時間的、物理的な問題じゃない限り、「なぜこうしたいのか」「それはユーザにどんな価値を与えるか」ということをしっかり話せば、案外スムーズに話がまとまるもんです。
弊社の場合は、「残業ありきのスケジュールを切らない」というモットーがあって、時間的な問題はないです。技術的な問題については、コストに対して効果はどうか、ということが主な判断基準になります。
「そんなこと言ってもうちの部長は!」みたいな場合は、上に書いたとおり、ユーザの声を武器にしましょう。

ユーザからの無茶なお問い合わせ

とは言っても、ユーザの言うことを全部聞けってことではなくて、そこはサービスの目的であったり、全ユーザのことを考えて、判断をする必要があります。
@tokorotenさんがフォードの話を例に出していましたがその通りで、ユーザは自分で自分の要望を分かっていないことが多々あります。そんなときに、力を発揮するのがユーザビリティ調査であったり、データ分析です。

改善案の提案と評価

改善案があるけどそれを許してくれない場合はどうしたら良いかというと、ひたすら啓蒙活動をしつつ、裏で作っちゃう、というのが一番楽です。実際に動くものを作れるというのがエンジニアの強みなので、そこを最大限に生かしましょう。

ぼくの場合は、日報であったり社内ポータルにいろいろ書いたりしつつ、diffを差し出して、「こういう理由でこんな変更を入れたいです」と言っています。だた、セッション中に「理想郷だ」と言われた通り、弊社は結構エンジニア的には恵まれているほうで、自分の意見が通らないということがあまりなくて、ちょっとよく分からないです。

今のところ、そういうようなことはないですが、もし駄目だと言われたら、「何かあったら全部自分が責任追うので、せめてA/Bテストだけでも!」と頼み込んで結果が思わしくなかったら静かに会社を去る覚悟です。逆に言うと、改善する場合はそこまでの自信(とそれを裏付けるデータ)が必要なんじゃないかな。

という意見がありましたが、もちろん誰にも知らせず変更するのはダメ!絶対!

改善と失敗

というのはちょっと言い過ぎな感じはありますが、

失敗したところでやめてしまうから失敗になる。
成功するところまで続ければ、それは成功になる

という松下幸之助の名言がありますがそれと同じで、継続的にサービスを改善するということはそういうことです。PDCAサイクルを常に回すことで、改善し続けるというのが重要です。評価をどうするかという話については、いろいろあると思いますが、上に書いたとおり、ユーザの声であったり、アクセス解析や表示速度などのデータ分析です。

サービスの立ち上げと運用

ページ速度の分析サービスを作ったときに、ただ作るだけじゃ利用されないなと思って、レポートメールの送信日にあわせて「負荷分析ミーティング」というのを開催し始めました。毎週金曜に時間をとって、各プロジェクトから最低1名参加を義務づけた勉強会です。内容としてはレポートメールを見ながら、すべてのサービスについてどう対策を取るか話し合ったり、先週のアクションプランを実施してどう改善されたかというのを話し合う会です。
運用を考えた開発をしないと、ここで苦労することになるので、運用に優しい開発ができます。

まとめ

ということがうまく伝わったかは分かりませんが、聞いていただいた皆様ありがとうございました。
他の登壇者の方と比べると、言葉に詰まっていたりしてお聞き苦しいところがあったかもしれませんが、こんなことを言ってました。

togetterにセッション中の発言まとめを作りましたので参考にしてください。
CROSS2013 「継続的サービス改善のゲンバのハナシ」 #cross2013 #cross2013a

最後に、発表の機会をくださった@tagomorisさん、エンジニアサポートCROSS 2013 実行委員会の皆様、ありがとうございました。

おまけ