そういうわけなので自作していきます。 豆は(とくにこの時期)買いづらいので頑張って探してください。豆には以下のような品種があります フォラステロ クリオロ トリニタリオ 覚えておくこととしては、だいたい普通の人が簡単に買える豆はフォラステロ種のみで、これは下ふたつの豆と比較するとだいぶ品質が劣るということです。なので牛乳や生クリームなどでやっていく必要があります。カカオと甘味料だけのまじでうまいチョコレートみたいのを作りたい人は気合を入れて貿易業者などに自力で問合せてトリニタリオ種の豆を手に入れましょう。俺はやったことない。 そのような事情なので豆以外に以下のものを用意する必要があります ココアバター 砂糖 生クリーム 筋力 筋力は最も重要です。 写真で制作過程を追っていきます。 チョコレート作ってます pic.twitter.com/zNate2OeXR — 竹達彩奈と回転する炎の剣 (

君の名は。という映画をみたところ大変に感動しました。 この映画では二人の人間の意識をつなぐという形で時間遡行が行われます。そしてその時間遡行/超越能力は主人公である宮水三葉の一族に相伝されてきた能力であることが示唆されます。 そしてその宮水の一族が暮らす糸守町は何度も隕石による災害を受けてきました。確認できる限り最低二回、あるいは三回もの隕石の直撃を受けています。 隕石だと確実なもの 御神体クレーター 作中のメインイベントである 2013 年彗星災害 不確実 糸守町の隣にあるクレーター状の湖 また彗星の軌道が非常に不可解であることが有志により指摘されています。 これが意味するものは何か。それはティアマト彗星とは自然現象ではなく糸守の排除を目的としている軌道爆撃機だということです。作中でもティアマト彗星の分離が自然現象としては説明し難いということが解説されており、同じ個所を何回も隕石が衝突す

自動運転が社会に浸透する結果ドライバーが無職になる！！大変！！という話ばかりを見るような気がしますが、事態はもっと深刻なのではないでしょうか。 自動運転タクシーが社会に浸透し、定額乗り放題プランが普通となり、そして車を所有するよりも定額乗り放題を契約するほうが遥かに安いという日は、すぐに来るでしょう。そのようになった日、誰が車を買うだろか、という問題があります。 そのような日、車の需要とは自動運転タクシー会社の消耗分のみになるでしょう。一部超高級車や趣味性の高い車は依然として需要が残るでしょうが、それらの需要では大した雇用を生まないことは分かりきっています。 車の需要が大幅に減少する結果として車一台一台のコストは上昇するでしょうが、いずれにせよ自動車製造業という莫大な雇用がほぼ消滅に追い込まれることは確実なのではないでしょうか。 また住宅の需要という問題もあります。通勤/通学の時間が多少伸

Go でアプリケーションを作ると、そのまま他になにもなくとも実行できるバイナリが出来あがります。この特性によりデプロイが大変楽です。 このような特性があるので、 Go を使う場合 Docker のようなオーケストレーションツールを使わなくても多くのサーバーにアプリをデプロイしていくことも可能かと思われますが、そこはまあ Docker という巨人に乗っておくと楽なことが多いです。具体的には swarm と docker-compose が便利なので Docker 上で実行したい。 ここで問題となってくるのが何も考えずに Docker イメージを作るとイメージサイズが膨れあがってしまってシングルバイナリによる手軽さなどが損なわれてしまうという点です。 たとえば golang:alpine のような比較的小さいイメージを使ってもファイルサイズはバイナリサイズ + 300MB ほどにもなってしまい

顧客は SPA であることを望んでいるのか？そうではないです。技術者は SPA を作りたいのか？そうではないです。 ではなぜ SPA 的なものが出来てしまうかといえば、いちいち UI の遷移のために大量のデータをロードしているのは時間と資源の無駄だからです。 もちろんあるべき姿としては、サーバーの CPU やストレージやメモリは爆速で、回線も爆速で、用いられるデータは必要最低限で、クライアントマシンも爆速で、クライアント側でフォームを一個書き換えるたびにページをフルロードしても全くストレス無く使える、というような世界観です。 しかし実際にはサーバーのスペックも回線もクライアントのスペックも不足気味ですから頑張って補っていく必要があります。 すると最初にロードしたデータをクライアントは保持し続けて、 HTML 全体を書き換えるのではなく必要なところだけを最小限の通信とともに書き換えてみたいな

そういうわけですから、今日はバーベキューに取り組みます。長い記事を読まない皆さんの為にとりあえず完成したものを共有したいと思います。 バーベキューはゴールデンウイークの娯楽としては極めて一般的です。僕は普通の人間なのでバーベキューをします。 まずはバーベキューとは何かという問題について考えていきます。最初に以下の画像をご覧ください。 左は単なる外でやる焼肉、右は美味しそうな食べ物であることが一目瞭然です。我々は右を目指さなければならない。 そこでいくつかバーベキューの定義を調べてみると、バーベキューラブやらなんらかのソースやらを揉み込んだ肉を長時間グリルで蒸し焼きにしたものがバーベキューであることが分かります。 肉が焼き上がったあとにこれでもかというほどソースを塗るのがテキサス風というイメージが僕のなかではなんとなくありましたが、あれは焼き上がりから提供までに時間がかかるバーベキュー大会や

最後は総務部を追い出し部屋にしたことです。やめさせたい人間をグループウェアから登録解除し、総務部という名前を持った統合思念体に統一し、PCも共有で1台しか与えない。昨日までエンジニアをしていた人間がスーツを着て社内を歩いて備品の補充をする。そんなことが許されていました。 ドワンゴは大量退職に関する印象操作をやめろ - hiroki-uemuraのブログ 一番大きなのは給与の問題。ソシャゲバブルのタイミング。開発環境の問題。インフラの問題。そのほかいろいろな理由。ほぼ、事実認識としては間違ってないじゃん。ニュアンスの違いは立場が違うからしょうがない / “ドワンゴは大量退職に関する…” http://t.co/cEZY0Pa9zf — kadongo38 (@kadongo38) September 1, 2015 ドワンゴ川上、 kuzuha のエントリが事実として間違ってないといってるし

Heroku は最近料金体系に変更があって、無料では一日 18 時間までしかアプリを起動できなくなりました。 自分専用のアプリとかそういうものなら全く問題はないのですが、それなりにユーザーがついているようなアプリだとなんだかんだで 24 時間 Dyno が起動しっぱなしということはおおいと思います。 一番安いプランは 7 ドルで、とりあえずこれだけ払えば 24 時間 Dyno を起動しっぱなしにできます。 公開しているアプリが 1 個ならまあ 7 ドルぐらい払っとけよで済む話なのですが、私のように 18 時間制限にひっかかってるアプリが 30 個もあるとなると 210 ドルを払うのは躊躇してしまいます。 ということで今日は石に齧りついてでも Heroku をタダで使う方法を考えていきます。 基本的なアイディア Heroku でアプリ 2 個用意して、同じ DB 向くようにして、 12 時間

というわけで YAPC Asia 2015 の 0-1 日目のレポートです。 技術ブログを書くことについて語るときに僕の語ること はてな社員 id:y_uuki の発表。技術ブログ書いてブクマ稼ぐにはみたいな話。 人間は先頭しか読まない、日本人はアメリカに弱い、はてなブックマーカーはアカデミズムに弱い、信じられないレベルで役に立つ知見だ — チャレンジ (@fuba) August 20, 2015 Docker という単語が後ろに行くだけでブックマーク数が半分になる — チャレンジ (@fuba) August 20, 2015 というような内容。スライドの後半にはいい文章書くにはみたいな話もあったんだけど時間なくてそこはかっとばされてた。あとは「僕がブログ書くときの哲学」みたいな話とかしてたけど、わりとどうでもいい感じだった。 「人は先頭しか読まない」ということをいってたので質疑応答で

うちには 2013 年末ごろからずっと docker コンテナを運用し続けていた物理ホストがあったのだけど、最近 $ docker ps とかしても結果が戻ってくるのに 20 秒ぐらいかかるし、コンテナの起動とかにも同じくらい時間がかかる $ /etc/init.d/docker restart などとしようもんならコンテナが使用可能になるまで 3 時間ぐらいかかってた。とはいえそう頻繁にコンテナを手動で起動したり終了したりするホストではないし、 docker のデーモン自体を再起動するとかは本当に稀なのでずっと放置してたんだけど、さすがに放置できなくなってきた。 $ docker ps --all | wc -l とすると 103781 とかなってて、ゴミコンテナやイメージが大量にありすぎるのが諸悪の根源なのではないかという予想を立てた。 そこでこのようなスクリプトでコンテナを掃除してみ

Amazon API Gateway と S3 においた静的なファイルだけで、動的なサイトを作ることができそうなのでやってみました。 http://ssig33-keijiban.s3-website-ap-northeast-1.amazonaws.com/ わりと楽に作れます。めんどうなのは CORS 対応だけです。うまくまとまったドキュメントがあるので参考にしましょう。 認証とかが必要な場合は、 Cognito が使えると思います。 データストアに Dynamo DB などを使えば本当に何も考えずに自動的にスケールしていくサイトを作ることが出来るのではないかと思います。 現状やってみて分かった課題は以下のとおりです AWS Lambda Function のデプロイと管理がやりづらい Amazon API Gateway の設定をコードで管理できないと絶対に破滅する どうやら API