No Regrets in Bathing

カレーを週に一度食っていく

鮨のローディングアニメーション

Sushicorp Advent Calender 2015の8日目です。

ページローディング中は、読込中を表すスピナーを回す習わしになっていますね。

f:id:hashrock:20151208035014g:plain

でも、これって一体何でしたっけ? そもそもなんでこれを回してるのか、よく考えると意味がわかりませんね。

f:id:hashrock:20151208035014g:plain

待たされてる感があってイライラしますね。 ホスピタリティが今ひとつ感じられません。

こんなよくわからないものよりも、鮨を回すべきじゃないですか?

というわけで、回しました。

f:id:hashrock:20151208034508g:plain

DEMO: Sushi Loading

あなたも、スピナーなんかより、鮨を回してみませんか。 リポジトリはこちらです。

github.com

鮨の物理演算

Sushicorp Advent Calender 2015の一日目です。

親方!空からsushiが!

f:id:hashrock:20151130154717g:plain

http://hashrock-sandbox.github.io/study-matterjs/

matter.jsとても簡単ですね。 デフォルトレンダラが大変有能で、デフォルトでワイヤーフレームON、 OFFの場合は指定したテクスチャで物体を描画してくれます。

ソースはこちら

hashrock-sandbox/study-matterjs · GitHub

明日は弊社CTOが弊社について何か書いてくれるはずです。

参考サイト

「Matter.js」を使ってCanvasの物理演算をやってみました | スターフィールド株式会社

ごはんデッキ構築

ある程度見栄えのする食卓にするには、一汁三菜にする必要がある。 しかし一汁はともかく、三菜を毎日考えるのはつらい。

一日に下せる判断の数は限られていると聞く。 食べるくらいのことでいちいち考えたくない。 思考ルーチンを固めておきたいところだ。

言っておくが料理は下手である。

制約条件

買い物ができる状態では、材料はボトルネックにはならない。 どちらかと言えば、大事なのは同時に調理できる数とか環境だ。

調理器具

  • コンロは2つ
  • レンジ+ルクレーゼ
  • 味噌汁用鍋
  • フライパン
  • 深い厚手の鍋
  • ミニ鍋(ソースパン?)
  • 玉子焼き用フライパン

鍋とコンロ一つは味噌汁で専有されてしまうので、 三菜をコンロひとつとレンジで作らねばならない。

1菜目(少し冷えてもいいもの)

レンジで作れるものだと、安全だし放置できて楽である。 最初に作って入れっぱなしにしておけば保温にもなる。

  • 魚(レンジ蒸しが楽)
  • おひたし、煮浸し(小松菜もしくはほうれん草があれば)
  • きんぴら
  • ナムル
  • 玉子焼き
  • ほうれん草と卵のサラダ

味噌汁

基本的に葉物野菜のあまりで作る。 何もなければ、なめこや豆腐、油揚げと乾燥わかめで作ればよい。

2菜目(非加熱料理)

1菜目作ったあとに材料を切っておき、和えるのは最後で良い。

乾燥わかめ、キャベツ、トマトでとりあえずサラダは作れる。 タンパク源がなければ蒸鶏を乗せてバンバンジー風とかでもよい。

面倒な時はつけもの(浅漬やキムチなど)を買ってくる。 もしくは半額コロッケとかでもよい。

3菜目(メイン)

メインディッシュなので量を作らねばならない。 基本的には肉(ベーコンや豚コマ、ひき肉、鶏肉) または豆腐などで作る。

  • 中華(麻婆豆腐やチンジャオロースなど)
  • 和食炒めもの(生姜焼きや味噌炒めなど)
  • 煮込み料理(ポトフ、カレー、ミルフィーユ鍋など)
  • パスタ

しかし、米+炒めものばかりだと飽きるので、少しレパートリーを増やしておきたいところ。

地下鉄、じいさん

電車に乗ったら、誰かが叫んでいた。

見ると、じいさんが何か叫んでいて、傍らの奥さんらしきおばあさんが「いいのよ、やめて」って言っていた。

誰かがおばあさんに何かして、それをじいさんが咎めているのか?と思ったのだけど、どうも様子が違った。どうやら、じいさんが周りに人に絡んでいるだけのようだった。

内容を聞くと、以下のような事を言っていた。

  • 「あんたがた、そんな事をするのはやめなさい」
  • スマホだかなんだか知らないが、そんなに情報ばかり求めて、頭がよろしいのかバカなのか知らないけどねぇ」
  • 「そんなに夢中になって、よほど大した仕事をなさってるんでしょうねぇ」
  • 「やめなさいよそんなことは」
  • 「(おばあさんにたしなめられて)好きな事を言って何が悪い、みんな自由にやってるじゃない、俺だって自由にいうだけですよ」
  • 「みなさんも自由にされてるんだから、自由に言って何が悪いの」

ぼけてるのかなと思ったけど、話の内容を聞くに、頭はたいそう回っているようだった。スマホ批判っぽいのは誤解があって、別に情報のインプットをしている訳ではなく、暇つぶしのゲームとか人付き合い程度のツールなのだけど。

まぁじいさんのいう事にも一理あるかなと思ったので、最近は本を読むようにしている。最上段から偉そうに説教するぐらいなら、多めにもらえるその年金分けてくれよと思ったが。

ブレながら進む

golangやったり、meteorやったり、schemeやったりcssやったりと、最近は中途半端でブレブレである。

というか、人生全体そんな感じで器用貧乏で、密度高く生きている人を横目にみると効率が悪くて悲しくなる。

ただ、ぶれて損をしたこともそんなになくて、むしろ得難いポジションを得られる可能性もあるのかもしれないなーと思う。例えば、ひと昔前は、ゲームデザイナーという職も、UIデザイナーという職も存在しなかった。

名前がつけば陳腐化する。だので名前のつかない領域で暴れればいい。そんな感じで、前向きに考えて生きていけばいいかな。

静的サイトジェネレータ使い比べ

ちょっとしたサイトを作るときの「よっこいせ」感を軽減したいと思った。

というわけで、静的サイトジェネレータをいろいろ使い比べてみる。

選定ポイント

  • gh-pagesへのデプロイが簡単か
  • ワークフローが短いやつがよい
  • 反映速度
  • ローカルプレビュー
  • blog機能は重視しない(はてなでいいじゃん)
  • nodeもしくはgoで書かれていると助かる
  • コード量が少ないと助かる
  • コードハイライト対応可能(gfm対応)

候補

  • jekyll on github
  • hexo
  • hugo
  • jedie

感想

jekyll on github

自動処理してくれるのは嬉しいんだけど、pluginの使用が制限されている。 また、kramdownのgfmオプションも動かなかった。

自動処理は10分くらい待たされるイメージだったんだが、実測してみると、小さなサイトでおおよそ10秒ほどで反映されるようになっていた。

jekyll自体がwindowsで動くか割と微妙なのと、そもそもjekyllのビルドはかなり遅い部類なのが微妙だ。ローカルビルドとgithub pages上のビルド環境がずれそうなのも、はまりそうで危険。

サンプルは以下。

github.com

hexo

templateがないとビルド自体できない。templateをがっつり書くのも大変なので、今回は見送る。

deployコマンドがあったり、cliでのサポートが手厚いイメージはある。vuejs.orgでも使われている。

hugo

hexoと同じ。テンプレートのダウンロードが終わらなくてそこで利用を諦めた。

jedie

mattnさん作のjekyllクローン。_pagesがないとビルドできなかったりと、特定のユースに特化している印象はあるけれど、結構動いている。ビルドは0.01秒前後で終わるので、jekyll比で100倍速ぐらいだ。

subtree経由でのデプロイも含めると、下記のような構成になる。

hashrock-sandbox/jedie-mysite-subtree · GitHub

感想

テンプレート充実とかは、あとあと足枷になるという認識なので、あまりありがたみを感じない。ごりごり書いたほうが結局早かったりするものだ。今回のような雑なサイトをモックするという用途では、marxが便利だった。

MeteorとVue.jsの連携

Qiitaに書いたのだけれど、以前作ったVue.jsとMeteorのサンプルを完成させた。 セキュリティに関する配慮が必要だったので、その辺りの修正をしてから記事として仕上げた。

isomorphic tokyo meetupで、Meteorに対して「時代が追い付いていない」という評価があったけれど、実はとっくに追いついているのではないだろうか。

リアルタイムWebとは、別にチャットアプリだけに必要なものではないような気がしている。通知にも必要だし、Wikiのように、同時編集されたら困るアプリにとっても、リアルタイムWebは複雑さを解決する方法となりうる。

作り始めた時には、いつリアルタイムWebが必要なのかは予想がつかない。そう考えると、プロトタイピングはまずリアルタイムWebで行い、リソース削減のためにRESTベースのAPIに落としこんで行く方がいいのかもしれない。

普通の企業はプロトタイピングを重視しない。だから、個人としてはプロトタイピングを掘り下げる方がきっと面白い。