パセリ種まき

gyazo.com

やっていきます。

gyazo.com

茶色い土のようなものはパームピートと呼ばれるヤシ殻の繊維で、たいへん吸湿性があるやつです。
水耕栽培の培地としてはメジャーなやつです。

gyazo.com

主役。

gyazo.com

小さい。

gyazo.com

適当にばらまきます。どうせ間引くので多すぎても問題なし。

gyazo.com

ファサー

gyazo.com

毒々しい色の溶液たち。ハイポネックスを500倍希釈します。
洗瓶と何かの瓶があるのは妻が化学屋のためです。東急ハンズに売っている。
洗瓶はペットボトルに溶液を足すのに便利。

gyazo.com

窓際族として配属。

gyazo.com

植物用LEDライトをてきとうな時間につくようにしています。
他のやつらはチンゲン菜で、我が家の小動物のおやつです。 栽培容器にアルミホイルを巻いているのは、藻の発生を抑止するためです。
気を抜くと藻とカビが大量発生するのが水耕栽培の世界らしい。

背景

パセリが好物なのだが、スーパーで死んだパセリを買ってくるとすぐに萎びてしまう。
なので、数ヶ月前から栽培に挑戦しており、夏には苗から水耕栽培へ植え替えしてみたのだが見事に敗北した。
というわけで今回は種からやってみることに。
食せるようになるまで数ヶ月前かかる模様。

今回の懸念点はスポンジの硬い部分を切り取らなかったこと。*1
一応真ん中に穴の空いたスポンジではあるが、根が下まで到達できるかに成否がかかっている。

*1:やるだけなのにいけるやろ〜でやらなかった

チームとフレームワークについて

フレームワークとは

設計思想の観点を大事にして考えると、フレームワークとは設計思想の柔軟性を犠牲に、チーム内の設計思想を調整・統一するコストを下げる働きを持つ仕組みである。
便利機能を抽象化して車輪としたライブラリと異なる点は思想の強制性である。

設計思想がないとき

フロントエンドGUIアプリをチームで作ってる時にたいへん苦労した経験があるのだが、共通認識となる思想がないシステムをチームで作るときは、何を実装するにしても設計・実装の方針が合わないことがある。
例えばReact + Reduxを使って状態をどこで管理するかというありふれたテーマですら、実装する内容によって状態の持ち方で議論になる。*1
たしかに議論を繰り返してチーム内での認識を徐々に揃えていけば最小のコミュニケーションコストで「いい感じ」に開発していくことは可能なのだけども、この時にできあがっているのは属人化された暗黙知でできたチームである。当然チームとしてのスケーラビリティなんてものはない。

例えばDDDを読む

私は読んだのだけども、一人で読んだら意味がなかった。ちゃんと業務で時間を取ってチーム全員が咀嚼できるまで読書会をして初めて意味がある。
しかし、読書会ですら書いてある内容の解釈を巡って暗黙知を育てていく過程があることは自明で、これは別の意味で「フレームワーク」を導入したことになる。
チーム全体で実装されるコードとしては何らかの合意された思想に基づいた、コードとしてのフレームワークには依存しない「よい設計」の成果が出てくるのだが、これもまたスケーラビリティには難がある。

言語化でも銀の弾丸にならない

チーム内の思想を言語化してドキュメントに落とし込めばよい。よいのはよいが、読書会で解釈の補強をする議論が必要なことと同じように言語化されたもので暗黙知を網羅することは難しい。*2
当然無いよりは相当マシではあり何もないよりはスケールするはずだが、人の流動に弱い点には代わりがない。

フレームワークと生産性のトレードオフ

フレームワークは何故必要なのかに立ち戻ると、「コミュニケーションコストを下げるために少ない人数(一人)で作ったほうがよいのでは」という仮説が出てくる。
しかし、常人の100倍の生産性を持った設計・実装スキル抜群の超人が居たとしても、思想の統一された集団には長期的に勝ち目がない。
ここで言う「統一された思想」とはコードとしてのフレームワークでもよいし、何らかの読書会で議論を重ねた結果でもよい。
よって、営利活動として収益を求めて競争をする限りにおいて組織はあったほうが強いし、組織内ではフレームワークが効率化に寄与するのである。*3

安いフレームワーク

そして、「コードとしてのフレームワーク」と「チームで議論した結果のフレームワーク」のどちらを重視するかという問題が残るが、これは各組織の現実に合わせて解く問題である。*4
作るシステムの規模が大きく関わる人が多いのならば後者の議論を行うコストが相当高くなるし、関わる人間が少なくてすむ要件のシステムを作るのなら他人の作ったフレームワークの制約は不便なものになる。*5

最も基礎的なフレームワーク

勉強・教養と呼ばれるものになる。例えば「計算量の計算ができるかどうか」「計算機で命令が実行される仕組みを知っているか」など。
ここまで書いて気づいたが、思想と知識を峻別する意味はないような気がする。思想が古くなり広範な合意が得られれば知識である。
こうした古典と呼ばれる知見は、より望ましい「チームで議論した結果のフレームワーク」を下支えする基盤であり、つまり古典の勉強は重要というありふれた結論が得られる。
そして、古典を無理やり教えてくれるのが大学であり、ちゃんと学んだ結果の学位は強いのである……。*6

おわり。

*1:GUIアプリケーションの設計方針にはReduxの制約でもまだ足りない。実際世界には様々なスタイルのReduxで書かれたアプリケーションがある。

*2:ドキュメントすぐ陳腐化する問題

*3:OSSとかlinuxはメーリスやissueで散々議論積み重ねてますね。それに設計にケチをつける独裁者もよくいる。

*4:個人的には柔軟性のほうが重要だと思っている

*5:同じシステムを作るときに人間が少なくてすむということは人間の能力が高く生産性が高いということに

*6:大学に戻って勉強し直したい

alt属性充実してくれ

Googleは未だにwebの会社でもあるのでそのうち読み上げに対応するだろうと思っている。
そもそもHTMLのセマンティクスとして読み上げ用文字列に適当なのはalt属性であり、Google Homeのシステムはaltを優先度高くすることが予想できる。
cookpadの場合はユーザが投稿したレシピ文字列をそのままaltに突っ込むと読み上げるには冗長という問題があるかもしれない。
このときサマライズとか口語変換とかの研究が効いてきそうですが、実用性はどんなもんなのでしょうか。

余談

Google Homeのようなシステムを人工知能業界ではエージェントと呼ぶ。
定義は様々あり、

aidiary.hatenablog.com

Interface agent 計算機の新たな利用者インタフェース、利用者とコミュニケーションするソフトウェアがエージェントと呼ばれる。表情を持つなど擬人化されたものも多い。

がこの場合適切そう。ただのインターフェースというよりは、人間に近い点が強調されるときにエージェントと言ってた気がする。
文章考えるの面倒になったので以下、論だけ。*1

なんでGUIだけではなくエージェントが必要か
  • 人間ではないシステムを相手にすると、人間はナメてかかるから
  • 計算機上のシステムを使うシーンによっては、人間ぽいインターフェースが全く必要ないこともあるのだが、例えば人にものを教えてくれるシステムでは人間らしさがあるとよいとされる*2
  • その他として、人間は人間とコミュニケーションするからプロトコル合わせると人間が楽だよねとかありそう
例えば、広く普及したエージェントの一つとしてSiriがある
  • 人間(iOSの操作が難しい人)にとってやさしいインターフェース
  • 何らかの便利システムのインターフェースでしかないので、本質はシステムそのものであり、システムには目的がある
  • システムの目的を達成するのにソフトウェアだけで済む場合もあるが、ハードウェアがあるほうがより強い(便利)
Google Homeとは
  • Google Calendarの予定とかが確認できるらしい
  • 今のところハードウェア(エージェントの身体)はChromecastと一部の家電くらいで家電はこれから増えそう
  • つまり、Google Homeはエージェントインターフェースを主に売っていて、ハードウェアは他社のものを取り込んでいる
    • 当然だがハードウェアをいちから作って普及させるのはめちゃくちゃ大変
    • 成功すればとても儲かるプラットフォームになり、コマンドを入力するインターフェースだけ提供するのはGoogleの得意分野とマッチしていそう
    • この点が各社が家電制御エージェントを作っている背景だと思われる
    • 似たような構造として自動運転がある
音声認識インターフェースの問題点
  • 精度が命
    • 例えばキーボードの入力精度は100%といっても問題ないレベル
    • 90%とか論外で99%でもまだボタン一つに敵わない
  • 精度が悪いと人間が怒る
    • 耳が遠い人はよく怒られる
      • そもそも人間同士の意思伝達の精度が100%なのかという疑問はあるが……
  • 精度が悪くて入力ミスが発生すると困る
  • 既存の入力インターフェースが精度100%近いので、並んでから初めて勝負になる

以上。おわり。
実用的なエージェントが家庭に普及する流れになるのが思ったより早くて驚いている。SF感あってよいですね。

*1:scrapboxとかでブログ書くほうが性に合ってるかもしれない

*2:自明でよいと思うが適当に論文引っ張ってきた https://www.jstage.jst.go.jp/article/tjsai/19/3/19_3_184/_pdf

靴がない

足の特徴
  • 扁平足
  • ワイズC

今の靴はインソール入れており、インソールないと足首が内側に倒れてしまう状態。
それだけならインソール作ってもらえばよいのだけど、ワイズCがたいへん厄介で、まず店頭在庫がない。
どうも世の中ではワイズEから上しか居ないらしい。
寺町のアシックスウォーキングではすべてを満たした靴が入手できるのだけど、デザインが微妙なのと、それでも選択肢が少ないのが課題。
今雨用のブーツが欲しくてとにかく困っている。

キログラムの再定義の話がよくわからなかったので調べた

産総研:質量の単位「キログラム」の新たな基準となるプランク定数の決定に貢献

で何故アボガドロ定数を求めているのか、さらに何故質量にプランク定数が関わるのかわからなかったので調べてなんとなく理解したメモ。
だいたいこの研究をしていた人の論文 基礎物理定数の新しい推奨値 に書いてあった。

質量とプランク定数

新しいSIの定義 - Wikipedia

プランク定数の次元がJという単純な話でした。プランク定数が選ばれたのは物理学の世界で重要だからでしょうか。

アボガドロ定数プランク定数

gyazo.com

1モルの電子の質量は電子質量かけるアボガドロ定数で、電子と陽子の質量比は電子モル質量と陽子モル質量の比と等しいという式変形をして、

gyazo.com リュードベリ定数(https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%A5%E3%83%BC%E3%83%89%E3%83%99%E3%83%AA%E5%AE%9A%E6%95%B0)を突っ込んだらこうなる。
皆さん定数*1なので、アボガドロ定数プランク定数の関係になる。

アボガドロ定数を求める方法

gyazo.com gyazo.com 1つのシリコン結晶の単位格子に8シリコン原子が含まれている。単位格子での密度と巨視的なインゴットの密度が等しいという仮定がある。
↑の式はアボガドロ定数の定義に、単位格子と密度の関係突っ込んだら出てくる。
なのでレーザー干渉計および質量原器を使って密度を求め、温度を一定の条件にして格子定数を求めるとアボガドロ定数が出てくる。
温度によって原子間の平均距離つまり格子定数が変わるので、温度を一定にするのが大事なんですね。
シリコンのモル質量が正確に出てくるのは同位体の存在比によって計算できるし、このインゴットはシリコンのほとんど単結晶とのこと。すごいですね〜。

もう一つのプランク定数の測定方法

キップルバランス法というのがあるらしい。何でこれより精度がよいということになってるかは突っ込んで調べていない。

雑感

というのが一読して理解できなかった理由だろうと思っている。最先端の研究に高校理科の単語がポンポン出てきて謎の関係があるとびっくりして混乱する。
元のリリースもあいだの理論端折られすぎではないか……。

それにしても干渉計ってすごいですね。

*1:キログラム定義に求められる精度においては

ISUCON7予選で得た知見

きっちんゴリラ*1*2というチーム名で、id:tyage, id:nonyleneと出場しました。
結果は、max 113,846、score 95,352でした。

詳しい内容は

nonylene.hatenablog.jp

の通りです。

準備

去年の反省を活かしてデプロイスクリプトやベンチマーカーが混んだときのための負荷クライアントの雛形を準備していきました。
結果、提供されたベンチマーカーのスケーラビリティが素晴らしく後者は無用となりました。*3*4

作戦

結果的に、以下の作戦になりました。

  • app1サーバのnginxでロードバランサになる
  • app1サーバだけで/iconsに関わるすべての処理を受ける
  • app1, app2サーバで残りの処理をする
  • pumaのthreadsを増やしまくってCPUを使い切れる範囲でいい感じの値を二分探索する
  • ベンチマークガチャを引き続ける

役割分担

  • 全員
    • 初期の足場硬め
    • ログやメトリクスの収集環境構築
    • デプロイの仕組み
  • tyage
    • アプリのチューニング
    • /iconsの処理をDBから剥がす
    • N+1の解消
  • nonylene
    • インフラの設定とチューニング
    • HTTP Cache問題の解決
    • nginxやsystemdの設定

私はmackerelの設定といった細かい雑用やベンチマーク結果のエラーを眺めてボトルネックの指摘をしていたくらいで、特に実装上の貢献はありませんでした。
が、チームの皆様が優秀で/iconsのHTTP Cache設定およびimageテーブルの破棄(と、パラメータチューニング)がうまくいって10万点付近まで浮上することができました。

知見

戦略をちゃんと考える

戦略はありませんでした。しかし、今回のisuconは戦略を立てられたかどうかでHTTP Cacheの問題をクリアした後の点に大きく差がついたであろうことにあとで気づきました。

ISUCON7予選 当日マニュアル.md · GitHub

fetchにもN+1があり、POSTは3倍の点なのでfetchを遅くしてfetchで食うリソースを減らす。fetchでworkerが取られるのでthread数は思い切って増やすという戦略が有効だった。(もう遅い

2017/10/23 19:25
b.hatena.ne.jp

ということです。

isucon.net

にも書いてあるとおりです。
元の当日マニュアルにはちゃんとヒントが散りばめられています。太字になってすらいますね。
ドキュメントは落ち着いて隅から隅まで読まないければならないことがわかります。
実作業をして手を動かしてるとどんどん視野が狭くなっていくので、最初のうちに戦略を死ぬほど考えるとよいかもしれません。*5

CPUを早いうちに使い切る

Mackerelを導入してグラフが見えているのにも関わらず、CPUを使いきれてないことの問題をはっきりとは意識できてませんでした。
CPUが使い切れていないということは、ネットワークやディスク、メモリのいずれかがボトルネックになっているということであり、まず最初の目標はCPU使用率を100%になるよう設定を弄ることだったのかもしれません。
意識していても設定を弄ったりコードを読んでると忘れてしまいがちなので、ここを最初にクリアするのが重要です。*6

ベンチマーカーの気持ちになって考える

ユーザやjsのクライアント実装の気持ちになるとも言えます。
解説にもあるように、jsクライアントの実装は/fetchを起点としたmessageの取得になっています。
ブラウザでしっかりとアプリケーションの動作を確認して図にしておくと、当日マニュアルの読み込みが効いてきそうです。

感想

いいチームでおもしろい問題を解き、10万点の大台に乗れた点で概ね満足できました。
特にsleep(1)が一見不要に見えて本質的なパラメータになってるのは、とても面白かったです。インフラとアプリのバランスも良かったように思います。

運営および作問、インフラ設営、チームのみなさまありがとうございました。とても楽しく有意義な8時間でした。

*1:京都市左京区にある飲食店

*2:てきとうに決めた

*3:めでたいことです

*4:去年はfailしまくったので、外形監視テストでカバーできないかと考えていた

*5:実装をしない人をロールとして設定し考えさせてもよい

*6:仮にマルチコアでもtopを見ればわかるはず

プログラマのような知的労働者は、労働者自身が生産手段を半ば独占できているので、使用者に対して強気に出ても問題がないと思っている。*1
もちろん、チームで作って運用し続けられる規模のシステムだからこそ会社として業が成り立つのであり、自分ひとりの我儘で事態が大きく変わることは少ない(ように組織が設計されているべきだ)。
だが、「プログラマが辞めたあとに現場が混乱した」というイキり武勇伝は、話の真偽はともかく、労働者による生産手段の独占にそのような効用があることは間違いがないことを示している。
一人欠けただけで生産体制が崩壊するようなシステムはよくないのだが、組織労働の最大の敵はコミュニケーションなので、話をつけて調整する相手が少なければ少ないほど効率が上がることには違いがない。
なので、労働とくに知的労働と属人化がトレードオフになることは避けがたく、生産手段の独占され具合が強い業種ほど労働者が強くなれる。
このような前提のなかで、現代のプログラマはPCとインターネットさえあれば仕事ができるので、生産手段のうち大きな部分を専有しているといえる。*2*3*4*5 別にプログラマを称揚する意図は無いのだが、仕事のために必要な(一般人がアクセスできない)道具が少なければ少ないほど生産手段を独占しているといってよいだろう。

non117.hatenablog.com

追記

というか一般的に知識ってそういうもんでは?

*1:労働契約がすごい適当な文言だし……

*2:OSSによって、物理的ではない生産手段がパブリックアクセス可能なのも寄与している

*3:とはいえ銀行システムとかの超でかいやつの設計・開発・運用にそのまま理屈が適用できるとは思えない

*4:大規模プロジェクトは別の知識が必要になる説

*5:計算機科学ちゃんとやってきた人は何やっても強い気はしなくもない