I/O BLOG;

input を整理して ouput する訓練ブログ

久しぶりに料理

甘々と稲妻みてたら、料理したくなって、ハンバーグ作った。

とおーい昔の記憶とネットのレシピを頼りに、家に無い食材を買ってきていざ調理。
久しぶりに玉ねぎのみじん切りで、目がやられないようにあまり顔は近づけないようにしたら、なんとかなった。
座高が高くて助かったって、やかましいわ。

タネまでは問題なくできた。適当にたたきつけて、中の空気を抜く。
どれぐらいの火で焼いたらいいのかわからない。
タネは3つぐらいあるので、実験的に一つずつ焼いて、焼き方を研究する。

最初の2つを焼いて、油が多すぎたことに気がついた。 焼いただけでは、まだ中は赤いままだったので、水を足して蒸す。
しばらくすると、綺麗に火が通った。
食べてみると悪くない食感。玉ねぎだいぶ粗くなったけど、問題ないように感じる。
ただ味が薄い。塩が足りてなかったのと、コショウが黒胡椒しかないのが原因かと疑った。

3つめのタネは2つ目までの反省を踏まえて、焼く前にすこし塩を足す。油の量も最小限に。
片面に焼き色が着いたら、裏返して、水を足して蒸す。

暫くして中を確認すれでも、まだ赤い。もう少し蒸す。
綺麗に火が通ったので食べる。
味があって美味しいけど、すこししょっぱい。
塩の加減は慣れかな。

次回に向けて

また食べたくなったら作ろう。 今度は、

  • 玉ねぎもうちょっと細かく
  • 塩コショウを気持ち多めに
  • 焼きはしっかり、途中で蓋を開けない。

で、まともになるだろう。

所感

見た目からでは中に火が通ってるかわからない。
穴を開けて、透明な肉汁が出ても赤い時は赤い。
一般的な強火や弱火の概念がわからない。

総じてみると、火加減の感覚がわかっていないようだ。

レシピ

  • 牛豚ミンチ 220g
  • 玉ねぎ 1/2
  • 卵 1コ
  • パン粉 45cc
  • 塩コショウ

GraphQL

これよんだ。

githubengineering.com

GitHub では API について RESTful な設計にしてきたけど、一部のサービスで GraphQL を採用しました。
実際にサービスが動いてる状態ですっていう話。
自分も GitHubAPI 多少利用しているので、これが公式利用可能になって楽できたらいいな。

GraphQL

GraphQL はリクエスト側が欲しいデータ構造を指定、要求して、その通りにレスポンスが返ってくる設計。
REST だと返ってくる形は、概ね最初から設計されて決まっている。それはあまり柔軟ではない。 例えば、あるデータ一式がほしい時、APIの設計上、一度のリクエストで揃わない場合がある。そういう時は、複数のリクエストを分けて送らないといけない時がある。
GraphQL ではリクエスト側が、レスポンスの形を決めるので、一度のリクエストでとってこれる。とかそんなところ。

Links

使ってる Ruby gem は以下らしい。

GitHub もいくつか open source 化している

ドキュメンテーションはこっち


GraphQL represents a massive leap forward for API development.

GraphQL で API 開発は大きく前進するかもしれない。

働く意味みたいなモノ

比較的僕の身の回りの社会には余裕があって、急を要するような仕事はあんまりない気がする。 それをすると便利だけど、別になくても生きていけるみたいな。 そんな中で、ほんとに必要でそれがないと困る!みたいな仕事をやっていきたいと思うようになった。

医療

多分、"医療" あたりがそうなのかなって思う。自分にゆかりがあるし。 偶然と医療技術のおかげで死ぬはずだったものが、今もケロッと生きてるわけで。 その恩恵で今の時間があるのなら、稼げたこの時間で、その分野にコントリビュートしても悪くないんじゃないか。

誰かの生活を便利にしたり、エンターテイメントを提供したりとか、そういうことじゃなくて。 医療みたいな、ちょっと人間の根本的な"生"に関わるインパクトの大きな仕事をしてみたいと思うようになってきた。

僕が技術を勉強してるのは、技術のわからないおじさんたちに説明するためじゃないんだよね。 直接的に技術が生きるような仕事ができるようにしていこう。