seri::diary

プログラミングのこととかポエムとか

今更ながらTurbolinksを初めて仕事で使ってみたので色々調べてみた

f:id:serihiro:20140802065933j:plain

※このエントリーで使用している検証環境の各種バージョンは下記の通りです。

  • Railsのバージョンは4.1.4
  • Rubyのバージョンは2.1.2p95
  • Chromeのバージョンは36.0.1985.125 m

※このエントリーの最終更新日は2014.8.11です

2013年辺りのRails4について書かれたブログを読むとTurbolinksに関するエントリが結構多いんですね。

ざっとググって1ページ目に来るのがこれらのエントリー。

そして同じぐらい目にするのが「Turbolinksをオフにする方法」

Railsを使ってなかった頃からtwitterとかでちょいちょい流れてくるTurbolinksの記事を流し読み程度に読んでいたのですが、色んな人が解説エントリを書くほど注目されている一方で、何故か無効にする方法がやたら充実しています。
使っていいのダメなの??ということが外から判断できないということで、どんな恐ろしい機能なのかとjavaを書きながら横目でチラチラを見守っていたのですが、遂に今の職場で使う機会に巡りあいました。これも何かの運命でしょうか。

で、良い機会ですのでTurbolinksについてじっくり調べてみました。 さらに身を持ってその仕様を体験するためにちょっとした実験をやってみたのでその結果をご紹介します。

なお、本エントリーはRailsでアプリを作る人がturbolinksを使う時に気をつけること、というレベルでまとめたので、Turbolinksの実装の詳細についてはあまり触れていませんが、冒頭で紹介したリンク先の内容に詳しく記述されていますのでそちらを読むとさらに理解が深まると思います。

Turbolinksとは

Githubの本家リポジトリrails/turbolinks · GitHubでは以下のように説明されています。

  • Turbolinksはあなたのアプリケーションを早くするよ!
  • ブラウザにjs,cssをリコンパイルさせずに現在のページをActiveに保ってbodyとtitleとheadだけを書き変えるよ!
  • pjaxと似てるけど、Turbolinksは何も考えずにbodyをガバっとreplaceしてくれるのでサーバ側で特別なことをせずにpjaxを使うのとほぼ同じような恩恵を得られるよ!
  • もちろん(現在のページをActiveに保つということは)ブラウザ上でjsの長時間のプロセスを持続することになるので、処理の肥大化やメモリリークに気をつける必要があるけど、あなたがファンキーなことをしなければ多分大丈夫だよ!

要するにページ遷移(GETのみ)を通常のページ移動ではなくajaxで取得したhtmlでbodyを入れ変えるだけの処理に差し替えることで高速化するgemです。 似たようなことをしてくれるライブラリとしてpjaxというjqueryライブラリがあります。

Turbolinksにおけるjsの取り扱い

しかし手放しで何も考えずに入れとけばちゃんと動くというものでもないようです。

  • 最初にロードしたページがActive状態であり続ける
  • jsのプロセスが持続する

この事実を考慮すると今まで書いていたjsがそのまま動くのかちょっと不安になります。

例えばこんなコードはTurbolinksを使ってるページでもページ遷移毎に実行されるのでしょうか?

<script>
window.onload = function(){
  console.log('nya-n');
});
</script>

window.onloadの実行タイミングはページ全体がロードされた後のはず。 ってことは、最初の1ページ目の表示では問題なくwindow.onloadが発火しそうですが、Turbolinksが有効になっているページでページ遷移した時は動くのでしょうか? ついでに頻繁に使う$(document).ready

迷ったら実験しましょう。

実験 各イベントはいつ発火するのか

rails4.1.4で簡単なサンプルを作りました。
サンプルコードのリポジトリこちらです。

$ rake routes
Prefix Verb URI Pattern      Controller#Action
  root GET  /                index#index
 other GET  /other(.:format) index#other

/views/index/index.html.erb

/views/index/other.html.erb

/assets/javascripts/index.js.coffee

rails sして実際にアクセスしてみます。

実験1  index/indexのURLを指定してアクセス

f:id:serihiro:20140810144656p:plain

  1. ベタ書きしたjsの即時関数
  2. assets配下のCoffeeScriptに書いた$(document).ready
  3. ベタ書きした$(document).ready
  4. page:change
  5. page:update
  6. assets配下のCofeeScriptに書いた$(window).load
  7. ベタ書きした$(window).load

実験2 リンクをクリックしてindex/otherへページ遷移

f:id:serihiro:20140810145149p:plain

  1. page:before-change
  2. page:fetch
  3. page:receive
  4. ベタ書きしたjsの即時関数
  5. ベタ書きした$(document).ready
  6. page:change
  7. page:update
  8. page:load

実験3 リンクをクリックしてindex/indexへページ遷移

f:id:serihiro:20140810145730p:plain

  1. page:before-change
  2. page:fetch
  3. page:receive
  4. ベタ書きしたjsの即時関数
  5. ベタ書きした$(document).ready
  6. page:change
  7. page:update
  8. page:load

この結果から以下のことが言えます。

  • $(window).loadはページの初回表示時のみ実行され、リンクをクリックして遷移した場合は実行されない
  • $(document).readyはページの初回表示時のみ実行され、リンクをクリックして遷移した場合は実行されない
  • テンプレートファイルにベタ書きしたjsはページ遷移毎に実行される
  • テンプレートファイルにベタ書きした$(documebt).readyはページ遷移毎に実行される
  • テンプレートファイルにベタ書きした$(window).loadはリンクをクリックして遷移した場合は実行されない

assets配下のCoffeScriptに書いた処理はTurbolinksの管理配下の挙動になり、テンプレートファイルに書いたjsはページ遷移毎にそのまま実行されるようです。
こちらの記事にも書いてありますが、ページ遷移の度にロードされたhtml内のbodyタグ内のjsタグを取得して、新規のjsタグを組み立て再度差し込んで実行させているようです。

処理的には、turbolinks本体のCoffeeScriptを読み込んだ時にAタグをクリックした際にxhrオブジェクトを作ってxhrオブジェクトからリクエストを飛ばす処理をbindしているのですが、ページ遷移時の詳細な挙動はQiitaのこちらの記事に詳しく説明されています。 CoffeeScript側のソースだけなら436行しかないのですぐ読めますので気になる方は一度全部読んでみると良いと思います。実装自体は割と素直に書いてありますので読みやすいです。

Turbolinks導入のメリット

最初に書いたようにTurbolinksを導入することの利点はページロードの高速化です。html全体を再ロードしないため、ブラウザ上での体感速度向上が期待できます。

Turbolinks導入のデメリット

これまで書いてきたjsが動かなくなる可能性が高い

通常のwebページとjsの挙動が大きく変わるためこれまで作ってきたjsが上手く動作しない可能性が高くなります。
これまでRails3で作ってきたrailsアプリケーションをrails4にアップグレードした途端に正しく動かなくなるといったことが簡単に発生します。

ページ遷移してもmetaタグが更新されない

ページ遷移してもCSRF-Token以外のmetaタグが更新されないという挙動になっています。

そのため、普通ページ毎に内容が異なるogタグ等もページ遷移しても更新されません。 しかし、実際にfacebookのいいね!ボタンをクリックしたりした場合においては、フルロードしたコンテンツを各SNSが取得してくれるはずなので問題無いのでは?というようなコメントがついています。DHHも「それが必要なユースケースは聞いたことがない(I haven't heard a compelling use case yet)」とコメントしています。

既存のjsが動かなくなるケース

既存のjsをそのまま使おうとした時にどんな問題が起きるか具体例を上げて説明します。

$(document).readyにイベントをbindする処理を書いてたら最初にアクセスしたページではbindされるが遷移したらbindされない

$(document).readyはリンククリックでのページ遷移では発火しないので、同じjsファイルを読み込んでいるのに「外部リンクから最初にやってきた時しか正しく動かない」ということが起きます。

$(document)に同じイベントが多重bindされて正しい挙動にならない

全ページで読み込むjsで(例えば共有しているテンプレートファイルにベタ書き)即時関数で以下のbind処理を記述したとします。

<script>
$(function(){
  $(document).on('click', '#button', function(){
    console.log('ニャーン');
  })();
});
</script>

で、何度もページ遷移してから#bindをクリックするとページ遷移した分だけconsoleに「ニャーン」と表示されます。猫好きの私歓喜!とか言ってる場合じゃありません。

これが発生する原因は、最初に書いたとおりjsのプロセスがずっと継続するため、$(document)のオブジェクトはページ遷移してもずっと同一のものが生存し続けています。
そのため、ページ遷移する度にbindするようにすると、同一の$(document)オブジェクトに再度bindしてしまうため、何重にも同じイベントがbindされることになります。 私も最初この挙動にハマって小一時間悩みました…。1回のアクションでajaxリクエストが複数回飛んでるっぽい?などの分かりにくい問題が起こります。

なんでみんなオフにしたがるのか?

既存アプリにTurbolinksを導入する場合、「デメリットの方が多くなるケースが多い」ということに尽きると思います。 具体的には * jsをTurbolinksの挙動に合わせて修正するコストが高い * Turbolinksの挙動を正しく理解していないと簡単にトラブルになる * フロントエンドを担当するエンジニアへの負担が大きくなる といった所が問題になりそうです。想像の範囲ですが。

それでもTurbolinksを有効にする場合に気をつけること

urbolinksを使用する際のjs実装について気をつけることについて説明します。

ページ遷移の度に実行したいjsの実装

lightboxやmasonryなどのデザイン系のjQueryプラグインを適用するケースによくある「ページ遷移の度に実行したい」場合。 多重実行されるとやっぱり挙動がおかしくなるので、「複数回実行はさせたくないがページ遷移毎に1回だけ実行したい」という要件になります。

これを実現するにはいくつか方法があります。

1. テンプレートファイルにベタ書きする

毎回実行されることが保証されていますのでテンプレートファイルに記述すれば良さそうです。ただ、jsはassetsで管理してapplication.jsの1ファイルにまとめてロードするというrailsの作法からはちょっと外れる形にはなります(これも厳密に守るのはかなり難しい作法ですが)

2. $(document).readypage:loadの両方で実行されるようにassets管理下のjs,coffeescriptに記述する

$(document).readyはページ初回表示時にのみ実行され、page:loadはページ遷移時にのみ実行されます。ページ初回表示時には実行されません。

なので、同じ処理を両イベントでbindしておけば、常にページ遷移ごとに一回だけ実行されることが保証されます。

以下のように記述します。

$(document).on 'ready page:load', -> 
  console.log 'ready and load'

これでページ遷移毎に実行され、かつ一回だけ実行されます。

ただし、ブラウザバックで戻った時にはpage:loadが実行されないので、ブラウザバックで実行されなくて困る処理はpage:changeにbindする必要があります。 しかし、turbolinks使用時にブラウザの戻るボタンをクリックした場合、turbolinksが内部でキャッシュしているpageCacheからページが復元され(turbolinksはURLの書き換え等にhisotry APIを使っています)、pushStateが使えない場合はリダイレクトされる(location.hrefを書き変えてます)ので大体の場合において問題は起きないと思います。

イベントのbind

難しいのはこっちで、いくつか方法が考えられますがどの方法を取るにしても開発チーム内で話し合って決めておく必要があります。 主な関心事としては「多重bind」をいかに防止するかということになりますが、逆に多重bindされても問題がないようにイベントのハンドラを実装しておくというの手です。

まず前提条件としてテンプレートファイルにベタ書きせず、assetで管理されているjs、CoffeeScriptのファイルに記述することが条件になります。
テンプレートファイルにイベントをbindする処理を普通に書くとページ遷移毎にイベントがbindされるので$(document)の場合は上手くワークしません。 テンプレートファイルにjsを書かなければいけないケースはControllerから値を渡すようなケースに限定して、使わないように開発チーム内で取り決めをしておく必要があります。

1.$(document)にbindする場合

ajaxで後からロードするhtmlに対してイベントを定義しておく場合などによく用いられるケースです。

assetでapplication.js1つにjsがまとめられる場合は、$(document).ready内でbindするように記述します。

■/assets/path/index.js.coffee

$(document).ready ->
  $(document).on 'click', '#popup', (e)->
    alert('popup') 
  $(document).on 'hover', '.menu', (e)->
    e.currentTarget.addClass('hovered')

上述の通り初回表示時にのみ実行されるため、初回表示時に$(document)にbindする全てのイベントがbindされその後ページ遷移しても実行されません。
これにより確実に一回だけイベントがbindされます。ページ遷移毎に$(document) にbindするように実装すると上述した通り同じイベントが同じDOMに何重にもbindされて不具合を起こすケースがあります。

イベントのbind自体は$(document)に直接bindするのが一番早いようですし、パフォーマンス的にも問題は起こりにくい方法だと考えられますので、特別な理由が無い限り、イベントのbindは$(document).on({event}, {selector}, {callback})の形式に統一してしまうのが良いのではないかと思います。
参考:高速で安全なjQueryを書くために今できること | Dress Cording

ページごとにjsを読み込む場合は、そもそもturbolinksのページ遷移にならず通常の遷移になるので気にする必要はないですが、turbolinksの恩恵を受けられなくなります。

2.指定のセレクタにbindする場合

$(document).'ready page:load'でbindするようにすればページ遷移毎に実行されますので、これで対応出来ると思います。

こんな面倒なことしてられるか!俺はRails4でも今までどおりに開発させてもらう!という場合

特定のリンク時のみturbolinksで遷移せず通常のページ遷移をするようにする場合

aタグにdata-no-turbolinkという属性を付けます。 例:

<a href="/user" data-no-turbolink>User List</a>

全ページでリンククリック時のページ遷移にturbolinksを使わない場合

gemファイルとturbolinksを読み込んでる箇所をjs,htmlから削除します。turbolinksのソース読み込んだ時にAタグにbindingされるんでそりゃそうですが。
詳しい手順はこちらを参照。

まとめ

以上、簡単ですがturbolinksの挙動と実際に使う場合の注意点について述べました。
文中でも書いたとおり、これまでの色々なweb上でのjsの常識が通じなくなりますので、既存のjsを流用する場合はかなりの手間が必要になります。
またAngular.jsなどのフロントエンドフレームワークを使う場合においても対応が必要なようです。

そのためjsを多用したSPAを作る場合や、開発メンバーが不慣れな場合はturbolinks自体使わないという選択肢もアリだと思います。正直私も最近初めて使ったのですが最初は色々なものが動いたり動かなかったりでなんじゃこりゃと思いました。

ただ、Rails4から標準で有効になっている以上、Railsの作法の一つとして実装されているものだと考えています。
今後のバージョンアップでどうなるか分かりませんが、今後Railsで新規アプリを作っていくのであれば、うまい付き合い方を知っておいた方が結果的にRails Wayの恩恵をより受けられるようになっていくのではないかと勝手に考え、今回の機会にまとめてみました。

【お前のチケット】チーム開発でのチケット改善術【解読不能】

f:id:serihiro:20140809224222j:plain

Issue管理システムを使っている開発現場では同僚の書いたチケットに悩まされる以下の様な光景が良く見られます。

事例1「何の目的で作られたのか分からないチケット」

ソースレビューを振られたのでチケットを見てみたら、何を変更したいかは分かるけどこの変更がどういう意味があるのか分からないケース

担当者の対応

作業したメンバーの席まで歩いて行って
「ねーねーこれさー、何のために作ったの?
「あーそれはですね、まず○○という話がありまして、それで…」
(背景から説明されて15分経過)

事例2「ソースを全部読まないと何を変更したか分からないチケット」

ソースレビューを振られたのでチケットを見てみたら10コミットぐらい入れてあるけどチケットの説明が簡素過ぎて何の仕様をどう変更したか(もしくは新規に作ったか)がソースの差分を全部読み込まないと分からないケース

担当者の対応

作業したメンバーの席まで歩いて行って
「ねーねーこれさー、要するに何変えたの?
「あー、ちょっと待ってもらって良いですか?(いっぱい変えたからすぐ出てこない…)」
(思い出して変更点を列挙するまでに10分経過)

事例3「意味がわからないチケット」

誰かが切ったチケットを振られたのはいいけど何が書いてあるか分からないケース

担当者の対応

チケットを切ったメンバーの席まで歩いて行って
「ねーねーこれさー、何?
「あー、これ別のチケットから派生して作られたんで良くわからないっすねー」
「Aさんが詳しいはずだからAさんに聞いてみましょう」
Aさん「良く分かんないからBさんにも聞きましょう」
Bさん「いや俺知らんし」

運が悪いとドラクエの如くいろんな人の所にタライ回しにされ1時間近く彷徨うハメになります。

事例4「後になって振り返ると全然分からないチケット」

チケットは正常に処理され、作業者とレビュアーは合意が取れておりすでに本番にリリースされているのに、第三者がそのチケットを読んだだけでは内容がサッパリ分からない。 しかしその修正で障害が発生したので担当者を問い詰めなければいけないケース。

当事者の対応

作業したメンバーとレビューしたメンバーの席まで走って行って問い詰めるが当人達も覚えていなくて全社を巻き込んで泥沼化する
→最悪殴り合いに発展

何が原因か?

RedmineBacklogJIRAGithubといったIssue管理システムを使う最近の開発では、個々のチケットを通じて相手に作業依頼をするケースが多くなります。

口頭やメールで依頼する内容をつらつら書いたりすることなく、Issue管理システム上でチケットの担当者を変更し、Issue管理システムから飛んでくるメールで作業を依頼されたことを周知させている現場も多いのではないかと思います(少なくとも自分が関わった現場ではそうでした)。

そのため、他人に意思を正しく伝えるには、チケットに必要な情報が十分に掲載されている必要があります。
そうしないと上記のように、作業を振られる度にいちいち担当者の所まで行って質問しに行かなければならず、質問しに行ったついでにあれやこれや雑談していると簡単に10分、15分を無駄にしてしまいます。チーム内で同じことがどこかで毎日起きていたら間違いなくチーム全体の生産性の低下につながります。(そして何故か問題として取り扱われにくいですコレ)

どうするか

そんな重大な問題を引き起こしかねない一方で、上記の事例は全て「チケットの書き方」をちょっと改善することで大方解決できそうな問題です。

以下に説明する「ちょっとした気遣い」程度のことで、チームの生産性を大きく向上させることが出来ると信じています。

伝わりやすいチケットを書く上で自分が気をつけていること

現職ではGithubをIssue管理に使っていますが、IssueやPullRequestの説明やコメントを書くときに以下のことに気をつけています。

背景、目的、作業内容を必ず書く

簡単でも良いのでこの3点を押さえていれば、プロジェクト内の第三者が読んだ時に困ることは無いと思います。 この3点さえ抑えれば他の事は自ずと導かれてくるはずです。

しかし残念ながらこの3点すら書かれていないチケットを数多く目にし、その度にチケットを切ったメンバーの所に「そもそもコレってどういう話ですか?」という所から問答をスタートしなければならないケースが多々ありました…

<背景>

ユーザー新規登録画面においてページ離脱率を向上させる施策を実施したい。
そのために入力フォームがどのくらい入力された段階で離脱したかを知る必要がある。

<目的>

ユーザーが離脱した時点でどの入力フォームが入力済みであるかを知る。

<作業内容>

Google Analyticsのイベントトラッキングで以下のイベントを
トラッキングできるようにjsを仕込む。

TODO:
・入力フォームに入力してfocusが外れた時。未入力時は飛ばさない
(個々のinputタグのnameと入力された文字数をGoogle Analyticsに飛ばす)
・確認ボタンのonsubtmit
・ページ離脱(beforeunloadにbindする)

Redmineを使ってる場合はIssue Templateプラグインを入れてテンプレートとして上記のような項目のタイトルを入れておくと良いと思います。

また、Githubの場合はタスクリストをチェックボックスで作ることができるので、PullRequestの場合は必ず説明文に入れています。

画像で表現できるものは必ず画像を貼る

web画面やスマフォアプリ等でGUIがあるアプリの場合、必ずキャプチャを貼ります。 口で「UserControllerのlistで表示される画面の上から3番目のtableでさ~」なんて言われても分かりませんが、
キャプチャ取って丸つけとけば一発です。百聞は一見に如かずと昔の人は言いましたが今でも通用します。

文章では伝わらないことが画像や絵なら一発で伝わることも少なくありません。面倒臭がらずに画像に頼りましょう。 私はwebのキャプチャを取るためにChromeExtentionのAwesome Screenshotを使っています。
全体キャプチャ・部分キャプチャ・トリミングだけでなく、文字の表示や、四角・丸などで該当箇所を囲んだりといった加工がブラウザ上でできます。最近なんか挙動が怪しいですが、とりあえず使えてます。

f:id:serihiro:20140809220832p:plain

あとはMacだったら画面の動作をQuickTimeでキャプチャしてGifアニメにして貼るのもオススメです。

チケットの説明文に書く情報は出来るだけ沢山

バグチケットの場合だと情報が多すぎて困るケースは殆んどありません、というか多分ないです。
バグ調査の情報として載せられるものは何でも載っけましょう。 私の場合は以下をよく載せています。

  • サーバサイドのエラーログ
  • 問題を引き起こしてるSQL
  • 問題が起きている画面のキャプチャ
  • 問題が起きた際のmysqlshow full processlistのログ
  • 関連する資料ファイル(Excel,pptなどの外部ファイルがあれば)
  • 関連するチケットへのリンク

自分の作業メモをチケット上に残す

実践している人が意外とあまりいないtipsですが、自分がチケットを作ったり実際に作業している際に考え方こと、仕様決定で迷ったことなどをチケット上に残しておくと、レビュアーやテスター対してコミットの意図が伝わりやすくなります。

後で作業者や起票者の「思考をトレース出来る」というのは文章によるコミュニケーションの大きな利点ですので活用しない手はありません。
ただしあまり沢山書くと邪魔になってしまうので、ある程度バーっと書いてからあとで整理しておくのがオススメです。

自分の場合は以下の様なものをチケットに書いています。

  • 自分が手を入れている部分の仕様メモ
  • 疑問点とそれに対する回答(自分で聞いて回って解決したら回答を付け足しておく)
  • 実装中に「これでいいのかな?」と思ったこと(あとでレビュアーにレビュー依頼時に重点的に見てもらうために)
  • 設計の意図
  • 作業中に作った画面のキャプチャ(作業中は自分が見る用に、レビュー/テスト時はレビュアー/テスターが分かるように)

最後に

こういう話をすると高確率で「めんどくさい」「うちのチームは誰もチケットの内容なんて誰も読まない」 「Face to Faceで十分会話してるから問題ない」とか何とか言われます。

しかし、ちょっとやってみれば分かりますが、チケットを切る際に背景・目的・作業内容の3点を箇条書きにするようにするだけなら、時間は5分もかかりません。

その5分の労力によって、マネージャーや他のメンバーが質問しに来る時間を無くしてチーム全体の生産性を高めてみんな早く帰れるようになると考えれば、業務中にtwitterfacebookを眺める5分間を差し出すことは十分割に合うことだと思うのですが、どうでしょうか?w

先ず隗より始めよということで、自分からチケットの書き方を変えてみると良いと思います。 別に文句を言う人はいないはずです(多分)

自分も1人で上記のようなことを勝手に始めましたが、段々他の人が真似するようになりました。

パスタ大量消費に備えてニンニクをオリーブオイル漬けにした話

f:id:serihiro:20140809113846j:plain

遂に料理ネタにまで手を出してしまいますます何のブログか分からなくなってきましたが、色々ネタがあった方が楽しいので良いことにしましょうw

2014.8.19追記

先週までは平気だったのにニンニクから酸味がし始めたので捨てましたorz

元々傷んでたのか(いくつか色が怪しいのがあったので)瓶に入ってから発酵し始めたのか分かりませんが、とにかく危険なので処分しました…
さよならまだ結構余ってたニンニク達…

発端

普段在宅でリモートワークしていることもあって食事は家で済ませる事が多いのですが、大体時間がない中で作るのでサクっと作れるものが良い訳なんですね。

ところで私、若いころからペペロンチーノ厨でして、今でも2日に一回は作って食べてます。調理時間が大体15分ぐらいで済むので昼でもサクっと作れるのも良いのですね。

普段自炊しないけどペペロンチーノだけは自分で作る

で、このペペロンチーノですが、作るのは簡単ですぐ出来るしアレンジもし易いし飽きにくいわで大変優れた料理なのですが、「ニンニクの皮を剥いてスライスするのがめんどくさい」という課題を抱えておりました。

逆に料理らしい工程はそこぐらいのような気がしなくもないのですが、私のように2日に1回ニンニク加工をしておりますとそれなりの作業時間になりますし、毎回毎回繰り返すのもDRYの原則に反しています。普段仕事でRails使ってる人間としてはそれはイカン訳ですね。

ということで何か良い方法はないかとネットを調べた所、どうもニンニクをオリーブオイル漬けにして大量保存するのがポピュラーなソリューションであることが分かりました。 クックパッドでレシピをいくつか調べた所、煮沸した瓶にスライスしたニンニクを放り込みオリーブオイル攻めにすれば良いということが分かりました。

これぐらいならすぐ出来そう、ということで土曜日で休みの今日、朝からスーパー行ってニンニクを6個とオリーブオイルを購入し、ハンズで500mlの密閉ビンを買って来て釜茹での刑(但しお湯)にしました。

作業手順

1.ニンニクを並べる

特に意味はありませんが6個もニンニクを一気に調理するとなるとさすがに気分が高揚します。

f:id:serihiro:20140809103520j:plain

なお、手前の一個は、皮を剥いた所実に強い変色が見られた上に刺激臭がしたので速攻でゴミ箱にシューしました。

なので今回加工したのは5個です。

2.皮を剥く

剥きます。

f:id:serihiro:20140809110327j:plain

因みに水につけておくと簡単に剥けるようになるらしいので次回試してみます。

3.下の方を切り落とす

切り落とします。

f:id:serihiro:20140809110630j:plain

4.芽を取る

因みに今回買ったやつは何故か芽が無い?というか、可食部と強く結合していて上手く除去できないものが多かったのでスライスしてからちまちま取りました。

ニンニクの収穫期は5月末~6月とのことなので、8月上旬に出回ってるやつはまだ実が新しいのが多いせいもあるのでしょうかね。普段ならケツを切って電子レンジに放り込んで30秒加熱すると、芽を下からほじくって引っ張るとスルっと抜けるようになりますのでそうしています。

5.スライスする

スライスします。スライスしないで漬ける人もいるようですが、私の場合用途はペペロンチーノ一択ですので躊躇なく切ります。御免。

f:id:serihiro:20140809113319j:plain

6.オリーブオイル攻めにする

フタいっぱいまで入れるのがいいそうなんで、写真を取った後にもう少し足してギリギリまで入れました。

f:id:serihiro:20140809113520j:plain

7.フタを締めて暗くて冷たい所に監禁する

犯罪臭がしますね

f:id:serihiro:20140809113813j:plain

こんな感じで今後多少ペペロンチーノライフが改善しそうです。

今回の作業時間

  • 密閉ビン釜茹での刑 15分
  • ニンニク5個の加工・瓶詰め 40分
    合計:55分

使用した食材

  • にんにく5個
  • オリーブオイル300mlぐらい

リモートワークを始めて3週間が経ったので所感をまとめてみる

7月1日に株式会社ハートレイルズで勤務し始め、3週間ちょっとが経ちました。

最初は色々不安もあったリモートワークという働き方ですが、なんだかんだで上手く回っている気がします。仕事の方もそれなりに貢献出来ていると思いますw

このエントリーではリモートワークをして感じたこと、気づいたことを簡単にまとめてみます。

 生活リズムが安定するようになった

朝起きる時間、寝る時間が前に比べて安定するようになりました。

私の平日のスケジュールは大体こんな感じです。

  • AM6:00 起床(天気が良ければジョギングor散歩)
  • AM6:45~7:30 朝食・シャワー・身支度
  • AM7:30~AM8:50 洗濯、掃除、ギター弾く、本読む、提督業務、ネットをダラダラ見る
  • AM9:00 自宅で業務開始。hangoutで社員と朝の挨拶、進捗共有、雑談などをしてから業務開始
  • PM2:00頃 昼休み。家で適当に作って食べるか外食する。時間が余れば本屋に行って小説や技術書物色したりカフェでコーヒー飲みつつネットダラ見or読書など。
  • PM3:00頃 業務再開
  • PM7:00~PM8:00 業務終了。日報を提出して(日報共有は弊社が提供するサービス3arrowsを使っています)仕事用のPCをシャットダウン。

退勤後は夕食を食べてネットダラ見してニコ動観て提督業務して本読んだりギター弾いたりコード書いたりとダラダラしてから23:00頃に就寝します。勉強会がある日は早めに切り上げて勉強会に行ったりもします。

ハートレイルズは勤務時間がきっちり決まっている訳ではないのですが、他の社員が勤務している時間帯やお客様の営業時間に合わせると自然と時間が決まってきます。

なので生活リズムは割と固定化されます。また、通勤時間が無くなった分プライベートに充てられる時間も増えたので「帰りが遅くなったけど読みたい本が…今週中に読譜して練習しないとヤバい曲が…試したいライブラリが…提督業務が…」みたいに夜更かしする理由があまり無くなったので、その日の未練を残さずさっさと寝られるようになったためか、寝る時間も固定化してきました。

仕事の生産性が高くなった

前職より1日に書けるコード量が増えた気がします。

色々理由はあると思うのですが、

  1. コミュニケーションはオンラインツールを使った非同期コミュニケーションなので作業を中断されるタイミングが減ったこと
  2. 自分が作業し易い環境を自分で作って作業していること
  3. 職場が静かなので(当たり前ですがww)

といった所が理由かなーと思います。

1.作業を中断されるタイミングが減った

コミュニケーションには以下のツールを使っています

全てオンライン上でコミュニケーションをしていることもあって、オフラインでのMTGや会話と違って同期生が求められません。なので返せる時にレスを返すというスタイルになるので、自分の作業の状況に合わせて対応できます。

もちろんGithubやHipChatでメンションがあったらすぐ分かるようにサウンドを鳴らしたりメーラーのデスクトップ通知はONにしていますが、それでもすぐに反応すべきかどうかをすぐ判断出来るので、人から話しかけられる度に作業が中断する、といったことがありません。

そのため、まとまった作業時間が長く取れるようになったので、結果的に作業効率が上がっているのだと思います。

2.自分が作業し易い環境を自分で作って作業していること

と言っても、盛岡への引越しコストがあるのでそこまでお金はかけてないのですがw、今の所こんな感じです。

f:id:serihiro:20140719111512j:plain

こんな感じです。

今の所プライベートのPCとディスプレイ、キーボードを共有してるのでELECOMのKVMスイッチ「 KVM-DVHDU2 」を使って切り替えています。

なおこのKVMスイッチは前職の同僚一同から退職時に頂いたものです。このブログ見てるか分かりませんが大活躍しています。ありがとうございます!

引っ越して落ち着いたら前職のオフィスにあったDELL27inchディスプレイと Wireless Keyboard を揃えたいですが、とりあえずそれまではこれで十分です。

3.職場が静か

独り暮らしなので当たり前ですが、静かですw

ただ、個室で仕事するようになって分かったのは、オフィスで他人の雑談が聞こえるのは結構ストレスだったのだなぁということです。割と賑やかなオフィスで働いていたせいかもしれませんが、静かだと集中したい時にスッと集中モードに入れる気がします。

ただ、逆に集中が切れた時とか疲れた時は好きな音楽かけたりも出来ますし、自分の場合、所属しているマンドリンオケの演奏会で弾く曲の練習録音を確認しながら仕事、なんてこともしています。この辺の柔軟性はやはりリモートワークならではといった所でしょうか。業務中にヘッドホンかけて良い職場だったらまた違うでしょうけど、大体の職場はイヤフォン・ヘッドホン禁止でしょうから。

 

やっぱりたまには寂しくなるw

当然課題もあります。

当たり前ですが、要するに引き篭もりスタイルなのでオフラインでの人との交流が圧倒的に減ります。週末のマンドリンオケでの練習ぐらいでしか人と話さない、という週もあります。

なのでたまには寂しくなります。仕事中は全く寂しさを感じませんが、仕事が終わったあとに夜1人で過ごしているとそういうことを感じる時もあります。なので以前より勉強会で人に話しかけることが増えた気がします。コミュ症はコミュ症なりに寂しさを感じるということなのでしょうw

リアルな人との交流を持つ機会を増やすことは今の課題でもあります。今は川崎に住んでるのでもうちょっと勉強会とか社会人が集まるコミュニティに顔出してみたりした方がいいんでしょうね。この辺りの情報ももっと探して行きたいところです。

あとは今はずっと自宅で作業していますが、慣れてきてプロジェクトが忙しくなければコワーキングスペースで仕事したり誰かとランチを食べたり飲みに行ったり、ということも増やしていければと思います。ということで早速来週は元同僚とランチの約束をしてたりしますw9月末までは川崎にいるので、東京圏にいる間に他の人と交流しておきたいですね。

 

とりあえずこんな感じでリモートワークをしています。

最後に色々書きましたが、総じて楽しくやっておりますw

Railsで仕事するのも初めてだったので最初は不安もありましたが、ソースレビューをきっちりやるスタイルなのでまずい所は指摘してもらえますし、自分でもパーフェクトRubyやパーフェクトRuby on railsを読みながら勉強することでついていけている感じです。

技術的な話についてもturbolinksの挙動について「うおおおおおおおお」ってなることがあったり「CoffeScript最初はビビったけど使ってると超便利!」「 jquery-ujs.js使うと$.postする時に勝手にCSRF-Token付与してくれてて便利!」みたいなこととか色々書きたいネタが沢山あるのですが、これらについてはまた別エントリーで書きたいと思います。

「盛岡徘徊欲」、というのがあってですね

多分私しか言ってない訳ですが、そういうのがあるんですねwという話。

 

自分は大学時代からレヴァンテ・マンドリンオーケストラという、岩手県盛岡市を中心に活動している社会人マンドリンオケ団体に所属してギターを弾いています。かれこれ7年ぐらいになります。長いもんですね。

岩手大学に在学していた頃は練習も徒歩で行ける距離の公民館とかでやってたので「地元の団体」という感じだったのですが、社会人になって埼玉やら神奈川やらに住むようになってからは事情が変わりました。

レヴァンテは1年に1回定期演奏会があって、この演奏会の4~5ヶ月前から練習が始まります。練習が始まると平日の夜や土日に集まって練習をする訳ですが、当然「地元」でなくなった以上、平日の夜や土日に気軽に参加することはできなくなります。

 

f:id:serihiro:20140711005837j:plain

そのため社会人になってからは、練習が無い時期は殆んど団体活動にタッチせず、練習が始まってからは月に1回程度にペースで、土日に盛岡までギター担いで行って練習してビジホに泊まって返ってくるスタイルになります。こうなると盛岡に行くというのが「ちょっとした小旅行」みたいな感じになるんですね。

そうなってくると不思議なもので、学生の頃は毎日見ていた町も見方が変わってきました。「あ、ここ良い所だったんだ」って。

f:id:serihiro:20130209090135j:plain

そう思い始めたのは社会人になって半年ぐらいしてから盛岡に行ってからでしょうかね。つまり社会人になってすぐw

 んで盛岡に行く度に、練習の前とかに盛岡の町を「徘徊」するのが習慣になっていました。大体は夜行バスで朝着いて練習が始まる9時ぐらいまでの間です。(練習が始まれば夜まで練習です)

上の写真は岩手大学農学部の構内なんですが、ここまで駅から30分ぐらいかけて歩いてきました。氷点下の中を。ギター担いで雪道をスーツケース引いて。

正直アホです。
しかし盛岡の町を歩くのはなんだか分からないのですが、とても楽しいのです。例え気温が氷点下10度近くても。

学生時代を思い出して懐かしいと感じる部分もありますが、今、社会人になった自分の感覚で盛岡にくるととても居心地が良いんですね。これが不思議なくらい。

f:id:serihiro:20140711011214j:plain

知ってる道なのに来る度に歩いて風景を見たくなる。そんな場所は自分にとって盛岡しかありません。

今は「たまにしか」訪れないからかも知れませんが、それでも、一度住んだ町を離れて改めて見るとそこに居心地の良さを感じることもあるという発見でした。

f:id:serihiro:20140711011708j:plain

そして明日また夜行バスで盛岡に行くので初夏の盛岡を「徘徊」してこようと思います。

 

 

第2回 かわいいKotlin勉強会 #jkug に参加しました

第2回 かわいいKotlin勉強会に参加してきました。

普段はあまり勉強会レポートとか書かないんですが、最後のじゃんけん大会に勝ってイケメンなサムライズム社長からIntelijIDEAのライセンスをタダで頂くという幸運に恵まれたのでこうして筆を取った訳でありまして候。

Intelij IDEAで私もKotlin書くよ!

 

所感

結局当日まで 一行もKotlin書かないまま、ロクな事前知識もなく行ったので細かいお話は他の人にお譲りして思ったことをつらつらと。当日の様子はイケメンが撮影してたUst録画がyoutubeに動画が上がってるのでこっちを見るのが早いです。

あと関係ないけどKotlinってKotolinってtypoしやすいの何とかなりませんか。

みんなjavaは辛いと思っていて救済を求めてる

らしいなぁ、、というのが一番感じたことでしたw

自分は1年半javaをずっと仕事でメインで使っていてストラッツとかスプリングとか使ってサーバサイドjavaを書いてた訳ですが、web開発だとそこまで長すぎるsyntaxが辛いとか匿名クラス作るのウザいとか思わなかったんですよね。

IDEのコード補完使い倒せば本質的でない部分は殆んど書かなくてすみますし。とりあえずeclipse使ってるならctrl + spaceとctrl + 1とalt + shift + mで世界は平和になります。

ただ、Androidになるとやっぱり話は別なんでしょうかね?会場でアンケート取ったら殆どの人がAndroiderでした。
Androidjava書くのがしんどい事情、実はよく分かってないのでいずれ勉強しないとですね。。仕事の関係でAndroidアプリやることになってから慌ててもしょうがないので。

Kotlin良さそう

java勢としては複雑な思いでLTを聞いていたのですがw、全体的にはkotlin良さそうだなと思いました。

変数が基本的にimmutableだったり、デフォルトでnull入れられなかったり、java 8よりもクロージャがスッキリ書けたり、javaだと人間が気をつけないといけなかった部分を言語仕様でかなり肩代わりしてくれる感じですね。

前職でSwiftを少し触った身としてはSwiftっぽいなーと思ったものですが、というよりは「今時の言語っぽい」ということなんでしょうね。Scalaも似たような言語思想ですし(なんて言うとScala逆引きレシピ著者に怒られるからやめときましょうかw)

ただ、開発環境がまだIntelij IDEAじゃないと辛いとか、言語仕様がコロコロ変わっている段階なので言語の上に乗っかるframeworkを作りにくいとか、まだまだキツイところはあるみたいなので、今後の発展に期待ですね。

個人的にははよwebアプリ作りたい所ですが、なんか主要なWAFはどれも開発が長いこと止まっちゃってるみたいな…話もあるようですが…アレ?

最後に

主催者のみなさんお疲れ様でした。

懇親会出られなかったけどまた機会があったら飲みましょう。

Kotlinサイコー

退職しました

6月いっぱいで現在の会社を辞めることになり、昨日が最終出社日でした。

関係者のみなさまには大変お世話になりました。
この場をお借りして御礼申し上げます。

 

「自社サービス事業とは何たるや」ということを身をもって学ばせて頂きました。

今の職場で勤務したのは1年と半年程ですが、それまで受託開発しか知らなかった自分にとって、単にシステムを作ることと、事業を行ってお金を稼ぐことの違いを学ばせて頂き、いかに儲かる仕組みを作るかが価値であり、そうでないものは世間からも仲間からも評価されない、ということを知ることが出来ました。

 

自分より優秀な沢山のエンジニアと働くことができました。

就職してからずっと目標に出来る先輩がいませんでしたが、この会社では初めて「この人のようになりたい」と思える人と出会い、その下で働くことができました。とても幸せなことだったと思います。

 また、僅かな期間でしたが、Scalaで有名な@takezoeさんには、言語に関係なく、OSS活動や今後の技術動向についてなど多くのことを教えていただきました。書籍を執筆したり外部で公演を多く行っている方は物事の捉え方が鋭く、またそれを分かり易く伝えることが出来ていて、こういうコミュニケーションの取り方が出来るようになりたいと思いました。

f:id:serihiro:20140621082511j:plain

 

Scala逆引きレシピ (PROGRAMMER’S RECiPE)

Scala逆引きレシピ (PROGRAMMER’S RECiPE)

 

 

Java逆引きレシピ

Java逆引きレシピ

 

 

javaという言語のパワーと魅力について知ることができました。

前職まではPHPとjsぐらいしか知らなかった自分にとって静的言語はめんどくさい言語という程度の認識しかありませんでしたが、IDEのコード補完を駆使して高速にコーディングするという概念や、DIコンテナAOP等の新しい概念をSAStrutsやSpring等のWAFを通じて知ることが出来ました。またDBFluteというORMの使用、及び作者の@jfluteさんのハンズオンチュートリアルを通じて、変更に強いDB設計の仕方や、データ取得時の「起点テーブル」という新しい概念について学ばせて頂きました。
DBFluteDDLが書かれたSQLファイルを直接読み込んで(というか実際にSQLを実行してDBを作る)そこからModelクラスを自動生成してタイプセーフにDBアクセスすることができ、DB定義書(html)までも自動生成し、テストデータもexcelで管理できて簡単にimport/dumpができ、かつmigration管理機能まで揃っているかなり強力なフレームワークです。javaC#版がありますので、それらの言語で開発しているプロジェクトで是非使って欲しいと思います。

f:id:serihiro:20140621081527j:plain

勉強会を開催し始めました。

f:id:serihiro:20140621081901j:plain

今でも続いていますが、オフィスにイベントスペースようなものが出来たので、渋谷javaという勉強会を自社で開催させていただき、今でも2ヶ月に1回ぐらいの頻度で開催しています。
初めはカジュアルにjavaの話が出来る勉強会が無いのでやってみるかー、ぐらいのノリで始めたのですが、今では毎回満員御礼になる盛況で、FWの紹介やJVMチューニングの話やJUnitの特殊なテストケース対応や、果てはvert.xやScalaやgroovyやkotolinの話題まで飛び出すかなり濃い勉強会となっています。
自分はペーペーなので自分が使ったライブラリやFWの紹介ぐらいしか出来てませんが、毎回新しいことを学ばせて頂いていて、javaの魅力というか底力をひしひしと感じます。
この勉強会については、私が辞めた後も引き続き株式会社ビズリーチのオフィスにて不定期で実施させて頂く予定です。

 

来月からリモート勤務します。

さて辞めた後の話ですが、来月からは株式会社ハートレイルズでお世話になり、リモート勤務という新しい働き方にチャレンジする予定です。

あと言語がrubyメインになるので、今必死こいて勉強している所ですw

rubyの勉強にはパーフェクトRubyや初めてのRubyRailsの勉強にはRailsチュートリアルとパーフェクトRailsRSpecによるRailsテスト入門を使って、サンプルアプリをゴリゴリ作っています。この辺もあとで別エントリーにまとめたいと思います。

 

初めてのRuby

初めてのRuby

 

 

パーフェクトRuby (PERFECT SERIES 6)

パーフェクトRuby (PERFECT SERIES 6)

 

 

パーフェクト Ruby on Rails

パーフェクト Ruby on Rails

 

Everyday Rails… Aaron Sumner 著 et al. [Leanpub PDF/iPad/Kindle]

Ruby on Rails チュートリアル:実例を使って Rails を学ぼう

 

で、リモート勤務に慣れた頃に、大学時代を過ごした盛岡に移転する予定です。

私は大学時代から盛岡のレヴァンテマンドリンオーケストラというマンドリンオーケストラに所属してギターを弾いていて、今でも月1ぐらいのペースで盛岡に夜行バスで行って練習してくるという日々を送っておりましたが、この活動に本腰を入れたいと思ったのと、後は単純に田舎好きな人間なので、大学時代を過ごした住みやすい環境で、仕事や趣味に全力で打ち込みたいと考えたからです。

盛岡ではIWDDという勉強会コミュニティもあるし、スマフォアプリのもくもく会なども定期的に開催されているようですので、向こうに行っても色んなコミュニティに顔を出して現地のエンジニアの方々と交流していきたいと思います。あとjavaの勉強会がなかったらiwate.javaみたいのを作ってもいいかもしれませんがw、まぁそこは向こうに行ってから考えます。

 

この決断をするにあたってかなり悩みました。ただの自分の我侭じゃないのか?通勤電車や人混みや東京の環境の悪さが辛いのは誰もが一緒なのに、自分だけそこから逃げていいのか?等々。あと結婚してないのにリモート勤務とか、理由が完全に俺の『自分が住みやすい場所に住んで働きたい』っていう我侭しかないじゃん…そんなのを自分自身で許していいのだろうか…」といった感じに。

でもやはり自分に嘘はつけないという結論となり、さらにソニックガーデンでリモート勤務をされている@jnchitoさんのブログ「give IT a try」や、ハートレイルズでリモート勤務をされている@ogin_s57さんのブログ「ITエンジニアとして生きる」を読んで、決して不可能な働き方ではないと勇気づけられ、決断に至りました。また、37シグナルズの「強いチームはオフィスを捨てる」という書籍を読んで、リモート勤務の具体的なイメージをして、何とか自分なら出来そうだと感じたのも理由の一つです。

 

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」

強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」

 

 リモート勤務はまだ日本では実例が少ない働き方ですが、家庭を持っている方や地方在住の方にとっては大きな恩恵を得る事ができる良い働き方だと考えておりますので、このブログでもその働き方を通して感じたことや工夫していることについて紹介していきたいと思います。

 

以上、長くなりましたが退職エントリーとさせていただきました。

今後ともみなさま、よろしくお願いしますm(_ _)m