それは話が逆になっている
種を明かせば簡単で、エンジニアはしょぼいアイディアでも自分で実装できちゃうというだけの話なのですよ、これ。実装を一人でできるので、アイディアの段階で枝刈りされることがなくて、結果として世の中に出てくるものの数で言えば「エンジニアが出したしょぼいアイディア」を実装したものが多くなる。一方で、エンジニアじゃない人はがんばってしょぼくないアイディアを考えて、アイディアがしょぼくないことをエンジニアに説得して頼み込んでやっと実装してもらえるので、明らかにしょぼいアイディアは世に出ないという。
アイディアのしょぼさと当たるかどうかには強い相関性はないというのが現在の常識だと思うので(適当に言ってるけど)、つまり実装できる人が、試行回数を最大化できる分、強いと言うことになる。がんばってしょぼくないアイディアを考えて枝刈りを避けないといけない人は大変ですねーという感じ。がんばってください。
技術的制約がどうのこうのとか、ユーザーベースでサービスを考えるとか、その辺はまあどっちでもいいや。僕も似たようなことを考えるし。
Cross Origin Resource Sharingのプリフライトの背景を理解する
Ajaxで他のホストのデータにアクセスできるようになるやつについてです。
この辺のドキュメントを読んでいても、どうも今ひとつ納得できなかったりすることがないかと思います。
- シンプルなリクエストとプリフライトリクエストはなにが違うの?
- まずシンプルなリクエストとプリフライトリクエストをなぜ区別しているの?
- プリフライトリクエストは「実際のリクエストを送信しても安全かを確かめるために」あると書いてあるが、「安全な」リクエストと「安全でない」リクエストはどう違うの?
シンプルなリクエストとプリフライトリクエストの二つがあることはわかるけど、なぜ二つに分けないといけないのか良くわからないし、その定義もなんか無駄に複雑に見えて良く理解できない。なぜ application/x-www-form-urlencoded
が特別扱いされているのか。そもそも、プリフライトリクエストとはなんのためのものなのかは、全然具体的に説明されていない。プリフライトリクエストではなにをすれば良いのだろう。何も考えずに200を返すだけで良いのだろうか。何らかの認証を行うのは、プリフライトリクエストのなかでやって良いのだろうか?キャッシュの時間はどの程度の長さにして良いのだろう?
まあ、こんな感じ。
さて、適当にぐぐってみると、Stack Overflowの記事が見つかります。
おお。これっぽい。
プリフライトリクエストの背景
簡単に言うと、
- シンプルなリクエストは、元々Webブラウザで発行可能だったクロスドメインなリクエスト
- これまでもできていたことなので、これからもできないといけない
- Webアプリケーションの責任として、このようなリクエストはきちんと処理できなくてはいけない
- プリフライトリクエストは、CORSによって発行可能になったリクエスト
- この種類のリクエストが発行されたときにきちんと動作しないのは、Webアプリケーションの責任ではない
- Webブラウザの側で、リクエストを発行して大丈夫であることを確認しないといけない
ということです。
シンプルなリクエストを良く見てみると、
- カスタムヘッダなしのGETはこれまでもWebブラウザから発行できていたリクエストなので、特別な対応は必要ない → シンプルなリクエスト
- 普通の
form
を通して他のドメインにPOSTできていたようなもの(カスタムヘッダがないとか、content-typeがapplication/x-www-form-urlencoded
とか)は、これまでも普通にWebブラウザから発行できていたので、普通のWebアプリケーションは処理できるはず → シンプルなリクエスト
ということです。
一方でプリフライトリクエストはと言うと、それ以外のもので、つまりXHRとかを使わないとブラウザ内からは発行できないものです。CORSで初めて発行可能になったリクエストなので、Webサーバが対応しているかどうかを、確実に検査する必要があるわけですね。
サーバがCORSに対応しているかどうかって……Access-Control-Allow-Originと何が違うの?
一瞬混乱するかもしれませんが、違います。
Access-Control-Allow-Origin
は、リクエストが処理されて、ブラウザに返ってきたときに見えるやつなので、POST
みたいな冪等でないリクエストの場合にはやくにたちません。ブラウザに返事が返ってきた時点では、すでにPOST
が処理されてしまっていて、サーバのデータが変更されてしまっているわけです。
まとめ
- プリフライトリクエストはWebアプリケーションがCORSに対応しているかどうかを確認するためのもの
- 対応してるなら、深く考えずに200返しちゃって問題ない(多分)
- キャッシュの時間も「やっぱりCORS止めます!」みたいなことがないなら、適当に決めれば良い(多分)
MacからDELLのディスプレイにきれいに画面を出力させる方法
MacでMini DisplayportからDELLのディスプレイに画面を出すと、とても汚いことがあります。これを直す方法。僕はU2713Hで気づきましたが、U2713HMとかU2711とかでも同じ問題が発生しているはずだし、他のディスプレイでも同じことが起きているかもしれない。
tl;dr
上のURLから、patch-edid.rbをダウンロードして実行すると、DisplayVendorID-10ac
みたいなディレクトリがすぐ下にできるので、それを/System/Library/Displays/Overrides
にコピーして再起動する。再起動すると、DELLのディスプレイがちゃんと良い感じに表示されるようになっている。
私になにがおきたのか
DELLのU2713Hというディスプレイを買って、昨日無事に届いて、Macに接続したらすごい汚い表示で愕然とした、というのが発生した現象。シャープネスを強くするフィルタをかけたような表示。ディスプレイにはシャープネスを設定する機能があるので、それを初期値50を0にすると、まあなんとなくまともになった。
とりあえず、社内のMac何台かで試したけど、同じ表示だったので、初期不良を疑って、DELLに電話して、交換品を届けてもらったのが今朝。
Macにつないでみると、やっぱり汚い。念のため、Windowsにつないでみると普通にきれいに表示されている。これはおかしい。
というわけで、上のURLを見て、良い感じになったという話でした。DELLのディスプレイでも、U2713HMとU2711は、そこまで汚くなかったので、気づいていなかった。同じ問題は発生しているはずなので、試しにU2711のもRGBにしてみたけど、これできれいになったのかというとよくわからない……
開発のスループットを犠牲にしてレイテンシを向上させる
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
- 作者: Mike Cohn,マイクコーン,安井力,角谷信太郎
- 出版社/メーカー: 毎日コミュニケーションズ
- 発売日: 2009/01/29
- メディア: 単行本(ソフトカバー)
- 購入: 74人 クリック: 764回
- この商品を含むブログ (223件) を見る
ソフトウェア製品の一部をまず完成させる。次に、別の一部を完成させる。もう一つ、別の一部を完成させる。こういうやり方を続けていくと、最初のほうに作った部分と最近になって作った部分のコードは、かなり違ったものになってしまう。最近になって必要になったモデルの機能は、最初のほうに書いたコードのデザインとうまく一体化していない。そこで、全体を直す作業が必要になる。これをリファクタリングと言う。一つ機能を追加するたびにリファクタリングする必要があるので、当然、開発のスループットは落ちる。それでも、一部ずつソフトウェアができあがっていくので、進捗を開発者以外とも共有しやすいし、できてから初めて気づいた問題にも素早く対処できる。実は必要がなかった機能を実装してしまう可能性は、少なくなる。スループットが落ちる代わりに、ソフトウェアの価値が発生し始めるまでのレイテンシは短い。
最初に全部を見渡して完璧な設計を導出できるなら、リファクタリングは必要がない。リファクタリングに必要な時間がいらなくなるので、スループットは向上する。一方で、完璧な設計にたどり着くまで、ソフトウェアの設計はなかなか進まない。レイテンシは悪化する。
もちろんビジネスの種類にはよるんだけど、ものすごいざっくりと言えば、原則としてスループットを捨ててレイテンシを取るほうが賢い戦略だと思う。少なくとも僕が生きている自分で適当なWebサービスを開発するような世界では、レイテンシ向上をデフォルトの戦略にするのが良いと思う。
ただし、当然だけど例外があって、レイテンシの向上でもたらせる利益によって帳消しにできないくらいにスループットの低下が激しい場合には、後者の戦略のほうが正しい。
レイテンシの向上が利益をもたらさないのはどういう場合かというと、スコープと期間があらかじめ厳密に定められていて、変更ができない場合である。スループットの低下が無視できないくらい大きいのはどういう場合かというと、リファクタリング(に相当する作業)のコストが大きい場合である。例えば、よく知らないけどハードウェアの開発とかそれに関するものとかだときっと大変でしょうね。
僕の感想だけど、どっちの条件についても緩和される方向に、人類が進化するのが正しいと思う。
inputでエンターキーを押しても、formのsubmitイベントが発生しないのはどうすれば良いの?
いつも忘れて混乱するので書いておく。細かいルールを解説したページを前見たんだけど見つけられない……
formの中にinput[type=submit]
なinput要素がないと、テキストフィールドでエンターを押してもsubmitイベントが発生しない。見えないようにしたsubmitボタンを、
<input type="submit" style="float:left; opacity:0; height:1px; width:1px; margin:0" value="to fire submit event on enter">
とでも書いて、設置しておく。display:none
だと、やっぱりsubmitイベントが発生しない。
でこの辺に悩んだ結果「Enterキーが押されたらsubmit」とかやると、日本語変換の確定とかの思わぬタイミングでsubmitされて悲しい思いをすることになる。まあ日本人ならちょっと触った時点で気づくだろうから、ここに書いてもしょうがないだろうけど。アメリカ人は最後まで気づかないんだと思う。例:Pivotal TrackerのTask欄。
テキストフィールドの値の変更の監視にはkeyupイベントではなくてinputイベントを使おう
漢字が読めないがいこくじんやようちえんじにもひらがなならよめるね!アクセシブル!
という話ではなくて、keyupイベントを使ってテキストフィールドの変更を監視するとiOSでこんなことになります(多分、変換の確定がキーイベントじゃない)。左上の「かんじ」は本当は「漢字」になっててほしかった。(ちなみにコピペしたときも更新されずに問題が起きます。)
inputイベントを使うとこういう問題は発生しません。
先ほど指摘されましたので、ユビレジのkeyupはすべてinputに置き換わりました。漏れはないはず。
ユビレジで水が飲めるようになるまでの話
水が飲めるようになるまでの例え話にだけ食いついてみる。まあタイトルはちょっと嘘で「お菓子を食べられるようになるまで」の話ですけどね。
ユビレジは、2010年に始めたスタートアップです。現在のスタッフは10名で、まあ今のところ不自由なくオフィスで作業中にお菓子をつまむことができています。この体制を確立するまでの経緯で、その中に権限の委譲に相当するものがあったのか、ちょっと考えてみたい。
一番最初:手の空いてる人がお菓子を買いに行っていた時代
最初は、お菓子の買い出しは社長の木戸の仕事でした。木戸と私しかいない時代のことです。このときは、別に私がお菓子を買いに行くのをすごいいやがったとか、私がたまにお菓子を買い出しに行くと木戸の嫌いなものしか買ってこないとか、そういう事情ではなくて、Webサービスを作るようなスタートアップの場合、最初は(ソフトウェア開発ができない)人ってお菓子の買い出しくらいしかやることがないのよね……という状況。*1
僕が黙々とお菓子を食べながら開発をして、木戸が唯々諾々とお菓子の買い出しに行ってました。
この体制の問題は……そんなにないな。まあ暇な人が暇なときに買い出しに行くという体制なので、忙しいとお菓子がなくなるという問題があります。でも忙しいときは近所のコンビニでうまい棒買ってくればそれで良いよね。
まとめ
- 暇な人が暇なときに買いに行く
- 二人とかの体制だと特に問題はない
東京に出てきてから:渋谷のドンキホーテに木戸がお菓子を買いに行っていた時代
上と変わらないので省略
権限の委譲1:僕がドンキホーテにお菓子を買いに行っていた時代
さて、このころ何があったかというと、
- オフィスの分割:開発チームとセールスチームで別々の拠点になりました
- 会社のクレジットカードを作って、木戸と僕が持つようになった
という二つがありました。あ、お菓子の文脈で言うと、ですからね。他にもありましたよ、人が増えたりとか。
木戸はセールスチームを指揮しているので、開発チームのオフィスにはお菓子がなくなりました。なくなったというか、まあほっといても補充されなくなった。
しょうが無いので、僕がお菓子を買いに行くことになりました。なぜ僕がお菓子を買いに行くかというと、僕は役員なのでどれだけ働いても給料が変わらないからです。これを社員の人にやってもらおうとすると、お菓子を買い出しに行く時間のお給料を払う必要があります。当然ですが、社員の人はユビレジの開発をしてもらうためにユビレジで仕事してもらっているので、そんなことに給料は払いたくありません。そこで払わないという手もあるとは思いますが、まあ道徳的にそういうのは避けるべきです。僕が買いに行っていました。
もう一つの僕が買い物に行く理由としては、精算をできるだけ簡単にすませたいというものがあります。僕は会社のカードを持っているので、そのカードで買い物をすればそれですみます。このカードを持っていない人が買い物をすると、領収書を持ってきてもらって、経費の申請をして、計算をして、振り込まなくてはいけません。まじめんどい(僕はやったことないけど)。
だいたい、2週間から1月に1回くらい、深夜にドンキホーテまでてくてく歩いて行って、お菓子を買って、帰ってきて、みんなで食べてました。ちなみに、お菓子は切れるとなかなか補充されません。なぜかというと僕が買いに行くのを忘れるから。仕事してたいよねー。
まとめ
- 役員の報酬は定額なので、雑用はできるだけ役員にやらせるほうが(金銭的な面で)都合が良い
- クレジットカードという支払いに関する権限が松本に委譲されたので、支払いができるようになった
- 一度お菓子が切れると、松本が買い物に行く気になるまで補充されないので、お菓子なしの状態が続くことがあった
アスクルの活用
さて、お菓子がなかなか補充されない状態にぶち切れた開発チームのスタッフが、ある日こんなことを言い出します。「Amazonか楽天でお菓子を買おう!」これはすばらしいアイディアです。ドンキまでてくてく片道20分かけて歩いて買いに行っていたことを考えると、インターネットで3回くらいクリックするだけでお菓子が届きます。IT革命です。
何度かお菓子を買いましたが、もっとよく考えてみると、そういうのに特化したサービスが世の中にはあります。アスクルです。
さっそくアカウントを作って、お菓子の買い物はアスクルで行われるようになりました。同時に、松本はお菓子の買い出しの職務から外されることになりました。なぜかというと、他にやることがあるので、どうしてもどんどん後回しになってしまい、お菓子不足に悩まされる期間が長く続く傾向にあったからです。ユビレジのお菓子係は、さらに年功序列の上位であることから、デザイナの宮内という子に引き継がれました。彼女は(松本に比べると)非常に几帳面で、お菓子が切れた状況が何週間も放置されることはなくなりました。
当初は、アスクルで注文するときにも、なんとなく私が相談されていたのですが、現在では完全に彼女が一人でお菓子の発注を担当しています。お菓子の発注という権限は、こうして完全に委譲されたのでした。
こうして、ユビレジではいつでもお菓子が食べられる体制を2年かけて確立したのでした。たかがお菓子といえども、なかなか苦労するものですね。いや苦労は特にしてないけど。時間はかかった。
まとめ
- お菓子の買い出しを通販で行うというイノベーションが発生
- これにより、買い出しにかかる時間が劇的に短縮され、役員の時間外の雑用から社員の業務(の一部)へと、買い出しが昇格
- 安定したお菓子の供給が可能になった
結論
こうしてみてみると、まさに権限の委譲と呼ぶにふさわしい変遷をたどってきていることがわかります。お菓子を買うという、社長にのみ許された特権的な行為が、一般の取締役に開放され、現在は社員が行っています。あと1年もすれば「誰もやる人がいなかったので、できるだけ省力化できるように最適化を進めた」という記憶は失われ、きっと「お菓子の買い出し」がそれ自体で一つの権限として確立される日が来ることでしょう(来ない)。
でもこれって要するにめんどくさい雑用が合理的に押しつけられる先に流れていったとかいう話なので、なんかこうソフトウェア開発みたいな仕事とかスクラムがどうとかそういう文脈で話を出しても、なんか良くわからなくなるよなーとか思いました。
いつもの宣伝です
お菓子が安定して供給される体制を2年がかりで確立したユビレジでは、現在、求人を行っています。どうやら今は「事業開発担当者」とかを募集しているみたいです。ソフトウェアエンジニアではなさそうなことは推理できますが、具体的に何をする人なのか僕はあんまり良くわかってなかったりします。
興味がある方はメールをください。
*1:正確に言うと、木戸は渋谷に出稼ぎに行って僕の給料を稼いできていたので、ちゃんと仕事してましたが、サービスの開発という面ではまああんまりやることがなかったのは否定しにくいと思う。