2015年09月23日

iOSの広告ブロックの今後を考えてみる

iOS 9でリリース後の話題をさらったのは広告ブロックが許可されたことですよね。実際に広告ブロックを入れるような人はクリックすることもなく、アクティビティが低いから広告主のためにもならないから広告ブロックをした方が良い、という意見もあります。とはいえ、今後の可能性としてはそう穏やかに終わらない可能性もあると思っています。

僕自身は変な広告を見るのが好きだし、Facebookの居住地はUSのままにしているので「英語圏だと、こういう広告で攻めてくるのかー、これは面白いな」みたいな気づきもあるので、入れることはありませんが可能性をいろいろ考えてみました。僕は広告の専門家ではないので、用語とか変なところがあるかもしれませんが、ご容赦ください。

一番穏やかなケース

広告を表示するものの、クリックする確率が低いユーザが減りました。出稿した広告数に対するクリック数が増えて、広告を出す費用に対して広告効果がアップしました。めでたしめでたし。

難易度ハード

続きを読む
posted by @shibukawa at 21:35 | TrackBack(0) | 日記 はてなブックマーク - iOSの広告ブロックの今後を考えてみる

2015年09月15日

SIerの未来は明るい?

XP祭り2015に参加してきました。スタッフの方々お疲れ様でした。今回は、あまり外に情報が出てくることがないと思われる、社内SE業で成果を出すために実践してきたことを発表してきました。

前のブログのエントリーでも書きましたが、今回考えさせられたのが岩切さんの発表の「在庫切れのメカニズムの原因となる事象を把握していたのが、社内の情報部門の人間だけだった」ということです。また、その後の質疑でも、「金融系もそうだった」という話が出ました。ここで説明したいと思っていたのが「業務はどんどん狭く深くなる」ということですが、内容が膨れてきたので前のエントリーに分けました。

だいたいビジネス書とかで語られているような仕事効率の基本原則は、同じ時間で成果を上げるためには、儲かる部分にフォーカスして儲からない部分は削るということです。時間あたりのビジネスの効率があがれば、忙しさを抑えてインカムも増えてハッピー、歩合制の仕事であれば、空いた時間でさらに多くの仕事をこなせて2倍美味しい、というストーリーです。実際には、サラリーマンだと後者のインセンティブはなかったりもしますが、だいたいそんな感じの内容が多いですよね。

儲からない部分を削るには、うるさいだけでお金を出さない客を切るということと、定型的な仕事は自動化/省力化するという主に2つの方法があります。省力化/自動化は脳の力をなるべく使わない(脳で酸素をムダに使わない)方法と言い換える方法がありますが、コンテキストスイッチを減らしたり、繰り返しのルーチンワークを効率化したり、情報の伝達のムダを減らすにはコンピュータが活用があります。企業としても利益率向上は存在理由に直結する部分なので、がんばる時間を設定したり、ITに投資したりして改善をします。分業を徹底的に行なって1つのタスクにフォーカスして成果をどんどん上げる、そして他の人との情報のやりとりは必要最低限にフィルタリングされて、余計な情報に煩わされることはない、という姿が理想型でしょう。

企業が意思を持ってそのような変革をしなかったとしても、仕事をする中でそのような方向への変革のフォースは常に発生しています。Aという仕事が得意な人と、Bという仕事が得意な人が同じチームにいれば、自然と分業されていきます。「相手を信頼して任せる」「現場に権限移譲」が成功の秘訣です。

このように業務内容が変わらないと想定しても、分業は進んでいくと考えられますが、競争力を保つためにより高度な仕事の仕組みを作り上げていったり、高度な商品の開発を行っていくと、仕事はどんどん深くなっていきますし、1人が面倒を見切れる範囲には限界があるので、その分対象は狭くなって専門化していきます。これは前回のエントリーで書いたことです。

ドメインエキスパートはどこにいる?

続きを読む
posted by @shibukawa at 23:53 | TrackBack(0) | 日記 はてなブックマーク - SIerの未来は明るい?

2015年09月13日

仕事はどんどん狭く深くなる法則

XP祭り2015の感想を書き始めたのですが、脱線した内容が爆発してきたので、単独のエントリーにしました。その感想で紹介しようと思っていたのが、僕がぼんやり考えてきたことで「業種問わず、仕事はどんどん狭く深くなる」ということです。

例えば、ソーシャルゲーム業界は、どこもガラケー時代に比べて利益率が落ちていますが、これは必然です。これは、ファスト&スロー(上) あなたの意思はどのように決まるか? に書かれている、「平均回帰」で説明できます。少ない手間でたくさん利益を生むような「金鉱」的な市場が開拓されたとします。その初期にはたくさんの好収益企業が出てきます。チャンスを狙って多くの会社が新規参入してきますし、コンソールゲームを出すよりも利益いいんだったら、こっちに参入したほうがいいよね?みたいな話も出てくるでしょう。そうなるとプレーヤーが増えてきます。

そういう中で売上上位を獲得するにはどうすればいいでしょうか?それは開発期間をかけてよりゲームとして深みのあるシステムを組み込んだり、デザイナーを多数起用して美しいグラフィックを隅から隅まで配する他ないでしょう。幸い、スマホの性能はガンガン上がっているため、コストに見合うビジュアルは出せます。そうして開発費が高騰すれば利益率が下がっていきます。最近では広告の投入も必要です。で、他のゲーム開発と同程度までは落ちる可能性があります。もちろん初期には(今でも少しは)変化球なゲームが突発的に人気になったりしますが、アイディア一発だと類似ゲームも出しやすいので、よっぽど真似しづらいブランドを獲得しないと(マンボウとか、ねこあつめとか)同じく平均回帰が起きます。

続きを読む
posted by @shibukawa at 23:29 | TrackBack(0) | 日記 はてなブックマーク - 仕事はどんどん狭く深くなる法則

2015年08月07日

世界最速でMithril本をリリースした話

DSC_5516

オライリー・ジャパンから、Mithrilの本を出しました。今まで本は何冊も出してきましたが、今回が初の単著です。O'reilly Authorの帽子もいただきました。出版にあたってはいろいろな方々にお世話になりました。ありがとうございました。もちろん、購入していただいた方、興味をもってシェアしていただいた方々もありがとうございます。

ちょっとお酒が入って酔っぱらっている状況ですが、本について紹介しようと思います。

Mithrilのどこに惹かれたのか?

続きを読む
posted by @shibukawa at 02:38 | TrackBack(0) | 日記 はてなブックマーク - 世界最速でMithril本をリリースした話

2015年05月22日

HTTP/2とES 6 Modulesで、concatはいらなくなるのか?

サーバーサイドpushはまあ現実的に使えるのか難しいよね、サーバーサイドpushに夢求めすぎてたよねっていうのは一度は誰もが経験するところではあって、みんな夢は覚めたと思うけど、場合によっては使えるかもねと思うケースは1つあります。起点となるhtmlの最終更新日を見てそれよりも新しいファイルがあれば一括で送りつける、というのは可能かもと思います。サーバ側でシーケンシャルな日付のリストを用意しておけば難しくないですし。ただ、ダウンロード失敗等を考えると、前回ダウンロードに成功したファイルの中の一番新しいファイルの更新日時を送ればより安全かなぁ、と思います。index.htmlがサーバで動的生成されるファイルだとまた話はややこしいのですが・・・まぁ、確実でムダのないサーバーサイドpushは難しいですよね。上記のブログに書かれている手法で本当に行けるのかな?と思うてんを列挙します。

ファイル一覧をダウンロードする方式でES6 Modules使えるのか?

続きを読む
posted by @shibukawa at 20:48 | TrackBack(0) | 日記 はてなブックマーク - HTTP/2とES 6 Modulesで、concatはいらなくなるのか?

2015年03月24日

cURL as DSLとは何だったのか。あるいは細かすぎて伝わらないcURL as DSL。

DSL Internet Access
By Jeremy Brooks under CC BY-NC

先日、cURL as DSLというツールを公開しました。その後、何度も同じような質問を受けたりしたので、ブログにまとめてみます。

なぜこのツールを作ったの?

RESTfulというものは大分一般的になってきました。HTTPでAPIを提供というのもよく見かけます。ですが、僕はこのRESTfulというやつが嫌いです。

GETのURLをシェアすればいつでも同じページがある(変な状態を持たない)、みたいな思想はいいんですが、HTTPのAPIはどうも使いにくい。ドキュメントのHTTPのサンプルを見て、ドキュメントをじっくり読み込んで、パラメータをJSONやらXMLで組み立ててボディに乗っけて(しかも大抵パラメータがアホのように多い)、いろいろ決められたルールで認証してヘッダに埋め込んで・・・・ちょっとでも違うと、400しか返してくれないとかザラです。どこがうまくいかないのかきちんと情報を返してくれればいいんですけどね。やりたいこと(機能を1つ呼び出す)に対して、そこまでなかなか遠い。だいたい、ここを読んでいる人たちも、RESTful APIと、自分が使っている言語(RubyでもPythonでもnode.jsでも)のクライアントライブラリの両方があったら、迷わず後者を選びますよね?RESTful APIを触っている時の気持ちは、libffi経由でCで書かれた共有ライブラリを呼び出しているのと似ている気がします。で、バリデーションは送信側にしろ受信側にしろ、出て実装しないといけない。

だいぶ前にやったXMLRPCの方がまだ開発のしやすさは圧倒的に高い。また、WSDLとか、CORBAとか、我々人類はもっと便利なものを一度は手にしたのに、なぜ退化しちゃっているのか?ブラウザ主体だと、JSができることがメインとならざるを得なくて、それでXMLHttpRequestとかjQueryのAjax APIなんかで扱いやすい仕組みとしてRESTfulが主流になってきたのかなぁ・・・とか考えていますが、実際のところはよくわかりません。

RESTful時代にドキュメントとして書かれるのはHTTPのテキストと、たまにcURLコマンドです。それらのドキュメントの中にある情報の断片でクライアントが作れれば、試行錯誤の回数は確実に減ります。人間向けのドキュメントを機械が読んでくれたらうれしいですよね?本当はセマンティックウェブを実現しているSphinxのhttpドメインを使いたかったんですが・・・

とは言え、便利に使いたい、というだけであれば、Swaggerもあるし、これの開発を初めて、1-2個の言語出力ができるようになった時に、GoogleがgRPCを発表しました。使えるのであれば絶対にこっちの方がいいと思います。インタフェース生成の仕組みのお陰で、送信前に変なリクエストは事前に除外できますし、バリデータを自分で書かなくてもいいし、開発の効率は良いと思います。

用途としては、ウェブアプリのテストとか作るのが簡単になったらいいなぁ、とちょびっと思っています。

GolangのHTTPのAPI

続きを読む
posted by @shibukawa at 03:21 | TrackBack(0) | 日記 はてなブックマーク - cURL as DSLとは何だったのか。あるいは細かすぎて伝わらないcURL as DSL。

2014年11月19日

iOSはなぜAndroidの半分のスペックでも快適なのか

この記事が突っ込みどころが多いと話題になっています。初期の頃はiOSのなめらかな動きと比べたらAndroidは劣化版と言われても反論できない感じでしたが、Nexus 4/Nexus 5ともなるとだいぶ快適で乗り換えても違和感なく使えるようになりましたが、同じぐらいの快適さが得られるハードウェアを比べてみると、メモリも半分で、コア数も半分で、クロック周波数も半分で、バッテリーにやさしいハードウェアになっていることは確か。なぜそれでやっていけるのか、ということについて僕なりの理解をまとめます。元の英語記事は読んでません。

メモリ管理方式の違い

Androidはマーク・アンド・スイープ方式のGCで、iOSはNSAutoreleasePoolにしろ、ARCにしろ、基本的にリファレンスカウントです。リファレンスカウントはプリミティブなGCです。マーク・アンド・スイープは処理全体を止めるので、あまり発生させたくないです。そのため、同じようなプログラムを実行して同じようなユーザ体験を得るためにメモリを多めに積んで置いてGCさせないようにするのはあるかと思います。また、断片化したメモリの対策もないので、徐々に性能が落ちると評判でしたし。あと、Androidは2.3あたりからコンカレントGCが入ったという記事を見かけます。コンカレントGCだとGC用スレッドが別に動くのでマルチスレッド性能もしくはCPU速度が欲しくなりますよね。

Android 5.0だとパーシャルマーク・アンド・スイープでGCが改善して停止時間が短くなっていたり、断片化の解消の機能が入るらしいので、少ないメモリで動かした時の快適さは改善するんじゃないでしょうか。

VM方式か、ネイティブ方式か

Androidは長らくDalvik VMでした。iOSは、C言語にオブジェクト指向ランタイムを乗っけたObjective-C。ネイティブの方が当然パフォーマンスは良いのでクロック周波数を無理にあげなくても大丈夫です。VM方式はそのままでは遅いのでJITを使って高速化を行います。こうすると、バイトコードと同じ役割のネイティブコードがメモリにいたり(確証はないけど、たぶんバイトコードの開放はしてない気がする)、JITするホットスポットを見つけるためのログを保存したり、JITコンパイラ自身がメモリにいたり、メモリにはやさしくないことは確か(そこまでメモリは使わないという話も聞くけど)。また性能もネイティブに比べると劣る。

Android 5.0から事前コンパイルをするARTが搭載されます。中間コードをネイティブにする方式と、最初からネイティブだと、後者のほうがまだパフォーマンスは良いとは思いますが、ベンチマークの性能もだいぶ上がっているとのことなので(自分では測ってない)、CPUのクロックをもっと下げても快適な動きをするようになると思います。記事によってはメモリ消費量は犠牲になるという気になることを書いているのもあるので、まだiOSの方が多少は有利だと思いますが。

バックグラウンドタスク

Androidの方がバックグラウンドでやれることが多く、iOSの方が少なかったので、コア数やメモリが少なくても問題なかったというのはあると思います。メモリが半分というのはここが一番大きな差かな、と思っています。ただ、iOSも少しずつこのあたりの機能が増えてますし、どちらも通知機能がリッチになっていく方向に進化しているので差は減ってくると思います。

解像度

Retinaを打ち出したAppleの方が最初でしたが、その後はAndroid勢の方が解像度アップに積極的で、Full HDはおろか、MacBook Pro 13 with Retina並みの解像度の端末まで出てくる始末。解像度って液晶の消費電力にも影響あるし、メモリも食うし(VRAMが別にあれば問題ないと思うけど)、GPUの負荷もあがります。当然性能にも影響あります。直近の例だと、Nexus 9とShield Tabletですね。同じTegra K1だけど、解像度が小さいShield Tabletの方がフレームレートが上がります。算数の世界の話。

個人的にはiPhone 5の細かさで全然問題ないので、これ以上上げないで欲しいです。

まとめ

スペックに影響がありそうなところを適当にピックアップしました。これ以外にも、3GS時代にはAndroidにはストレージ速度の問題がありました。Galaxy S初代と3GSでは体感で倍以上違う感覚がありました。その分、データを事前にメモリにロードしておかないと、みたいな作りが必要でした。また内蔵メモリが少なくて、より低速なSDカードを使わせる機種も多かったですからね。今どきはそこまでストレージ速度に差はないみたいです。

元記事見てもiOSにメモリが1GBしかない理由がかかれてないというツッコミもありますが、どちらかというと、Androidが性能差を埋めるために必要なメモリ量が2GBでした、という方が近いのかなという気がしました。今後のARTのこなれ具合と、64ビット化でこの差がどれだけ縮まるのかは個人的に愉しみにしています。

posted by @shibukawa at 13:17 | TrackBack(0) | 日記 はてなブックマーク - iOSはなぜAndroidの半分のスペックでも快適なのか

2014年10月27日

SphinxCon JP 2014でOktaviaの宣伝してきた

スタッフ、会場提供のVoyage Groupさま、参加者のみなさま、お疲れ様でした。スライドのビュー数も一晩で2300超えと、今までSlideshareに上げたスライドの中では一番伸びがいい気がします。PyCon JPの時の発表を日本語で再演するのでいいから出てください、と言われてたのですが、末永さんの検索本もちょうど直後に出てて説明省けたし、転置インデックスの検索の説明はざっと削って、あらたに進捗をちょびっと足しました。

イベントの前に、こんなリポジトリをでっち上げました。Markdown形式でOSSライセンス文を集めたリポジトリがあったので、手でフォーマットを直しました。Sphinxで何かしらのツールのドキュメントを書くときは、この中のファイルをコピーして入れるとお手軽ですね。LICENSE.rstという名前で入れておいて、index.rstに .. include:: LICENSE.rstを入れておくのが僕のマイブームです。後から考えれば、PanDoc使えばよかった!

パフォーマンスチューニング

続きを読む
posted by @shibukawa at 21:40 | TrackBack(0) | 日記 はてなブックマーク - SphinxCon JP 2014でOktaviaの宣伝してきた

2014年09月19日

Qtにもパッケージマネージャが欲しい

JSXのパッケージマネージャ(npmへのあいのり)対応のパッチを書いたりもしましたが、今どきのプログラミング言語ではパッケージマネージャは必要不可欠なインフラだと思います。Qtももっといろいろなコードが流通するといいと思うのですが、いまだに、昔ながらの強力なコアAPI + 人力で努力みたいなノリなのかなぁ、と思ったり。欲しいのは、パッケージというかモジュールというかライブラリの流通インフラ。以下妄想。モデルはnodeのnpm。

  • qpm(仮称)コマンドで、必要なライブラリを取得。
  • システムのフォルダには手を加えない
  • qt_modulesフォルダにファイルが入る。孫依存もフラットに並べる。
  • qt_package.jsonに依存関係が書かれる。依存は、ビルドに必要、ライブラリの利用にも必要の2種類。
  • パッケージは基本的にgithubに置く。ブランチ、タグで指定
  • ブランチとタグはgithub APIで取得可能。タグブランチ
  • バージョンは、メジャー、マイナー、パッチを指定することである程度柔軟な組み合わせができる
  • パッケージはソースコード(gitリポジトリチェックアウト)、バイナリ(リリース)のどちらかで提供。
  • パッケージには、追加すべきファイル情報を持つ。
  • アプリのプロジェクトのルートは必ず、subdirs形式。その中に同名のルートのプロジェクトが入る。
  • ビルドが必要なソース形式のパッケージは、ルート直下にライブラリのプロジェクトとして追加。
  • ルートのプロジェクトの.pro、アプリのプロジェクトの.proは、qpmが作るをインクルードする。このファイルは機械生成で、依存ファイル利用に必要な情報などをすべて含む

なんとなくできそうな気はしてきた。パッケージ作成支援の部分もうちょっと考えると良さそう。configure使うのは、パッケージマネージャがかわりにビルドというのも手かなぁ。

追記 9/27

  • 静的リンクもしくはソースコードとして提供するなら、subdirsじゃなくてもいい。階層構造じゃない素の構成の方がわかりやすいかな。
  • ソースコード提供はqt_modules内にgit cloneが良いかも。パッチ当ててpull request出したりしやすい
  • git ls-remoteで、cloneしなくてもリポジトリのタグとかブランチ情報は取ってこれる
  • ファイル形式は.jsonじゃなくて.iniにしたい。コンフリクトに強いし、素のQtで扱える。
posted by @shibukawa at 11:53 | TrackBack(0) | 日記 はてなブックマーク - Qtにもパッケージマネージャが欲しい

2014年09月18日

PyConJP & 引っ越し

久しぶりにPyConJPに参加しました。きけば500人を超える人数とのこと。石本さんのブログによれば、10年前のPyConが400人ということで、それよりも大きな人数を集めたというのはすごいですよね。日本の10年前のイベントでは、仕事で使っている人はごく少数で、多くの人はPythonに興味があって、いつか仕事で使いたいなぁと夢見る若者たち(ほぼ男性)だったのが、今回は実際に使っている人たちが大勢集まっていました。大きなカンファレンスなんだけども、当初のグループのメンバーというだけでオリジナルの趣旨とは全然違う話題も取り込むことで延命しているイベントもあり、なおかつ知名度と情報量と書籍の量で国内ではRubyが圧倒的な中、Python 100%でここまで大きなイベントができるというのは10年前は想像できませんでした。タカノリさん、寺田さんをはじめ、多くの方々の頑張りに拍手です。

Oktavia

僕が発表したのは自分で作った検索エンジンですが、ブラウザ上で動かしたいという偏った同期からスタートしているのであまり一般的な題材ではなかったと思います。なんとか前日にPython版をPyPIにリリースして、発表資料も一晩で作り上げて、原稿も作らず練習もせずに英語でぶっつけ本番ながら、時間を枠内に収めることができました。欧米圏の人に、アジアの言語だと検索のアルゴリズムそのままだとツライんだよ、というのを説明するのが第一の目的でしたので、一応自分としてはそこはクリアしたつもり。

数年前のPyConJPと比較して、客層が大きく変わった気はしましたが、ウェブ系の人の人数はそのままに、データ解析系の人がプラスで追加された感じでした。セッションも、データ系とか機械学習の数が多くて人気そうでした。一方で、Pythonのコアとか処理系に対する話とかはそれほど数が多くなく、毛深い(Python用語)発表の割合は減ったかなぁという気がしました。

僕自身、最近は仕事でもPythonを書くことがなくて、たまにちょこちょこ趣味コードを書くぐらい。PyConJPの客層のメインストリームからは外れた気がしました。とはいえ、触り始めが古いだけの人が幅を利かせているのは健全ではないし、外れること自体は正しいことなので、この勢いで、現在Pythonと触れる機会の多い人がどんどん進出して、めだって、活躍して欲しいと思います。Python界の新アイドルも出てきましたし、Pythonの未来は明るいです。ラーメンの大盛りを注文しては後悔するような年齢になってしまったおじさんは、今後はポスターセッションか何かで、実用とはほど遠いかもしれないマニアックなネタで細々と生きていこうと思います。あと、The History of Pythonもきちんと訳さないとなぁ。来年のPyConJPまでに。

10月はSphinxConもやりますよ。Sphinxオンリーイベントが開かれるのは日本だけ!

引っ越し

日本に帰ってきて、不動産屋に行ったり下見をしたりして家を決めたまではすぐだったのですが、2ヶ月ぐらいたってようやく入居しました。まだ開けてないダンボールもいくつかありますし、ちょこちょこメンテのために業者に来てもらったり、表札の完成待ちだったり、タスクはいろいろありますが、だいぶ快適です。スペックは、丘の上の中古の庭付き一軒家です。4人家族の広さだと、家賃補助をプラスしても渋谷周辺は高くなってしまうし、買ってしまったほうが月々の支払いがだいぶ少なそうなので買いました。駒込時代よりも2.5倍の広さで月々の支払いはほぼ同じで通勤時間はそれほど変わらずです。ウィッシュリストはこちらです。そのうち、親しい仲間を呼んで、ハウスウォーミングしたいですね。

posted by @shibukawa at 01:40 | TrackBack(0) | 日記 はてなブックマーク - PyConJP & 引っ越し

2014年07月30日

「納品をなくせばうまくいく」を読みました!

著者の倉貫さんから、「納品」をなくせばうまくいくの献本をいただきました。ありがとうございます。

日本人の日本人による日本人の顧客のための本

今まで出ていたソフトウェア開発方法論の関連の書籍の多くは、英語から翻訳された本でした。また、基本的にメインの想定読者はソフトウェア開発側のメンバーです。当然、ソフトウェア開発者の言葉を使って書かれています。翻訳者もみなプログラマ側のメンバーでした。もちろん、読んではいけないということはないし、読んでもらった方がメリットがある本も数多くありますが、必要な部分とそうじゃない部分をうまく切り分けつつ、欧米の文化と日本の文化の違いを考慮に入れつつ、自分の立場に合わせて情報をカスタマイズしつつ読むのは簡単ではないでしょう。

本書は、徹底的に「日本のお客様」視点に立って書かれている本です。「ソフトウェアがビジネスに必要なのは分かるんだけど、ソフトウェアの開発とかわからんし、エンジニア雇うのも簡単じゃないし、ぼったくられたらいやだ」という日本の顧客むけです。実際のお客様の言葉なども盛り込んであって、お客さんの不安を解消し、成功しそう(失敗しなさそう)という気持ちになってもらう、という姿勢が徹底されているなと思いました。

アジャイル本として

続きを読む
posted by @shibukawa at 01:46 | TrackBack(0) | 日記 はてなブックマーク - 「納品をなくせばうまくいく」を読みました!

2014年06月25日

未来のないJavaScriptと非同期とErlang

JavaScriptはもう好き嫌いを超えて、最低限の読み書きはもはや教養レベルといっても言い過ぎではないと思います。ブラウザ限定だったら他の言語もありますが、ブラウザで標準で使える言語はJavaScript以外には選択肢はありません。3DCG系のツールのマクロ言語は未だにPythonがトップシェアだと思いますが、Flash, Photoshop, Illustratorの仕事を効率化するマクロ言語はJavaScriptですよね。先日AppleのOS Xの次期バージョンの自動化ツールが独自言語に加えてJavaScriptをサポートすることを発表しました。サーバサイドで使われるnode.jsは、コンパイル言語を除けばトップクラスの性能です。QtもQMLとしてJavaScriptを中心とした開発を推し進めてますし、Qt4時代からQtアプリのマクロ言語として提供されているQtScriptEngineはJavaScirptです。node WebKitというGUI環境もあります。Cocos 2d-xのJSバインディングとかも情報が沢山出回ってますよね。.netも初期バージョンからJavaScriptのコンパイラがついてました。Unityで使えるという型付きJSはこれなのかな?ブラウザからデスクトップ、サーバ、スマートフォン、ゲームにいたるまで勢力を広げています。ハードウェアまで広がろうとしています。

で、JavaScriptというと話題によく出てくるのが非同期のプログラミングです。ブラウザやnode.jsでは、コールバックの嵐になるとよく言われたものです。それに対するソリューションはいくつかあり、僕が使ったことがあるのはasync.jsと、次期JavaScriptに入ることが確定しているPromiseです。

Futureはどこへ?

続きを読む
posted by @shibukawa at 16:48 | TrackBack(0) | 日記 はてなブックマーク - 未来のないJavaScriptと非同期とErlang

「納品をなくせばうまくいく」を読んでません

「納品」をなくせばうまくいくという本が流行っているみたいです。僕はまだ読んでいませんが、タイトルを一目見れば、倉貫さんファンからすると内容を想像するのは難しくないでしょう。きっと今まで倉貫さんが語ってこられてきたことの集大成であろうと想像しています。

こちらのブログにはこのモデルを採用することでいろいろ問題が解決するよね!ということが書かれていますが、こちらに書いてない話で、「なぜダメと分かっている方法論がまかり通っているのか」をまとめてみたいと思います。もしかしたら倉貫さんの本にすでに書かれているかもしれませんが。

ムダのない予算管理がムダを生む

続きを読む
posted by @shibukawa at 06:42 | TrackBack(0) | 日記 はてなブックマーク - 「納品をなくせばうまくいく」を読んでません

2014年05月22日

コードを書くときに心がけていること

なんか流行っているので乗ってみます。

趣味コード

趣味とはいっても、暇つぶしだったり、流行りもののチュートリアルに触って「おれ新しい◯◯やってみたぜ」みたいなのは極力しないようにしてます。仕事で必要になった時に、仕事の時間の中で集中的に学ぶ方が学習効率が高いので、趣味時間の活用という意味ではもったいないですよね。幸い、まったく未知の基礎的な内容というのはほとんど出会わなくなってきて、新しい技術といっても、既存の知識を土台にして、軽く検索すればOKなことがほとんど。ということで、趣味といっても、将来の仕事で役に立ちそうな種となる可能性のあるものを作るように心がけています。実際に種になるかどうかは運次第なので、命中率に関しては気にしません。

とは言うものの、先月末に二人目の子供が生まれてからは趣味のコードの時間はまったく取れてません。まあしばらくは潜伏期間かな。子供が二人いれば、少し大きくなったら子供同士で遊んだりしてくれるようになるらしいので!家で勉強する父親の背中を子どもたちには見せる予定です。勉強しない大人から「勉強しろ」って言われても説得力がないし、反発されるだけですしね。Wishリストはこちらです。

仕事のコード

いろいろ書いているけど、「いきなりチームに投入されても、既存のチームメンバーの邪魔をせずに、きちんと成果を出す」というのがコアですね。

ドキュメントなんて存在しない

続きを読む
posted by @shibukawa at 17:19 | TrackBack(0) | 日記 はてなブックマーク - コードを書くときに心がけていること

2014年05月17日

Spotifyの実験

曲のリストのところのメニューで、Copy Embed Codeというのがあったので貼ってみた。普段良く聴いている、Sonic Colors、Sonic Generationsにも参加しているCash CashというグループのCash CashというアルバムのCash Cashという名前の曲です。

訂正: 違った、アルバム名はTake it to the floorでした。Cash Cashというアルバムも別にあるけどそっちには入ってないっぽい。

posted by @shibukawa at 11:03 | TrackBack(0) | 日記 はてなブックマーク - Spotifyの実験

2014年05月14日

プログラマは酵母菌じゃないんだよ

オープンソースという言葉が一般化して、多くの人が使うようになってきたというのは感慨深いものです。ただ、同床異夢というというか、オープンソースというものに対していろいろな誤解とか先入観があるように感じます。僕もまだ業務としてプロダクトを作ってオープンソース化したことはないので(パッチとかpull requestはよく送っている)、至らぬところもあるかもしれませんが、そのようなものがあればTwitter等で補足してもらえればと思います。

手間を減らすために、公開すればいいじゃんという誤解

今あるコードをgithubにgit commit, git pushすればすべてがバラ色、というのがよく言われることです。公開するのはコストゼロというのは本当なんでしょうか?少なくとも僕が知る限りではそうではありません。ざっと考えてこのぐらいの項目のコストがかかるかなぁ、と考えています。

  • 社内の特許などの技術に関わるコードがないか、調査したり書き換えるコスト
  • 外部ベンダー製のコードがあれば、書き換えるもしくは契約を結びなおすなどのコスト
  • 社内のビルド環境に特化した部分などを書き換えるためのコスト
  • ドキュメント整備のためのコスト
  • ソフトウェアの資産=人件費の減価償却が終わってなければその精算

Windows規模ともなると、コードの調査だけで億の単位でお金がかかるんじゃないかな、と思います。マイクロソフトの場合は、互換性のためにバイナリバージョンを厳しく保持しているので、ビルドシステムも特殊かと思いますし、コンシューマOS、サーバとの共通コンポーネントなどもあって、必要なものを切り出してビルドできるようにするのも一苦労だと思います。公開したら即make worldコマンド一発でヒャッハーというわけにはいかないと思います。

企業内でもう使うことがないプロダクトか、そうじゃないかにもよって多少は変わってきます。企業で今後も使っていく場合には、開発の主体・意思決定を内部に持ったまま、外にだすことになります。当然、外部のユーザから来た要望に対して、企業の方針とすりあわせて方針を決定したり、変更が許容できない場合は今ある機能でどうやってそれを実現していくのかを説明するコストが必要となります。カスタマーサポート的なコストですね。エンジニアを数人張り付きで提供するならそれだけで数千万の費用になったりしますよね。それ以外にも法務のチェックとか、いろいろな部署に協力をお願いすることになるんじゃないでしょうか。

これらのコストをマイクロソフトが負担した上で公開しろ、というのは交渉としては成り立つ要素はゼロですよね。Blenderみたいにコミュニティで必要なお金を寄付で集めて、企業から買い取るという形で実現した例もあるので、お金を用意できればプロダクトによっては可能性はゼロではありません。Windows XPの場合にそれができるかというと、有料で延長サポートというのを行っているし、組み込み向けのWindows XPはまだ使われているので、マイクロソフトとしては「まだ生きている」という扱いなので門前払いじゃないですかね。

あと、すでにマイクロソフトはカーネルのコード等は契約を結んだところには公開しているみたいです。シェアードソースイニシアチブとかでぐぐると出てきます。ただ、問題はカーネルだけではないでしょうし、ネットワーク系のところとか、ブラウザとか多岐に渡りますし、そのすべてのコンポーネントのコードを公開しているかどうかは不明です。

コミュニティのためのコスト

続きを読む
posted by @shibukawa at 05:01 | TrackBack(0) | 日記 はてなブックマーク - プログラマは酵母菌じゃないんだよ

2014年03月30日

JavaScriptのメモリリークを10倍速で発見する

Leak

メモリリーク。一言でプログラマを死に追いやる恐怖の言葉。C/C++の世界ではmallocしたのにfreeしないとかのケアレスミスでよく起きていた問題です。その後、ガベージコレクタが掃除してくれるプログラミング言語が増え、一部の言語で循環参照に気をつけるぐらいであまり気にしなくても良い的な風潮になっています。

というものの、そうとも言ってられなくない状況も増えてきています。クラウドのスケールアウトブームも一段落というかコモディティ化し、go言語で再び性能向上方面に関心が寄せられたり、日本でErlangの勉強会が満席になったり、スケールアウトから再びスケールアップ方面に話題が移りつつあるのを感じます。長時間稼働のサーバで、スケールアップしてさらに数多くのリクエストを大量に受けるようになると、少しのリークでも大問題になります。

僕は現在はnode.jsを頻繁に使っています。node.jsはV8のおかげで、コンパイル言語から比べると遅いかもしれないけど、他のスクリプト言語の中では高速な部類に入りますし、今後もさまざまな場所で使われていくと思います。このエントリーではnode.jsのメモリリークの発見の方法について紹介します。

node.jsの基本的なメモリリークの発見方法

メモリリークの発見を難しくしてしている要因は、クロージャと無名関数です。

ガベージコレクタを搭載した言語のメモリリークは、「変数を持ち続けているために、リンクが残り続けてしまう」のが原因です。Chromeの開発者ツールを使うと、その時のオブジェクトのスナップショットを取得できてクラス情報も得られます。クラス名が得られますし、定義したクラスを使っている箇所は何箇所かに絞れることが多いので、比較的原因箇所を見つけるのは難しくないと思います。

やっかいなのは、クロージャです。クロージャは、構文的なつながりはなくとも、内部から参照していればその外の変数をキャプチャします。クロージャが残っていれば、そのキャプチャされている変数も残り続けます。たとえその変数がローカル変数であってもです。実際にそれが無名関数として定義されていれば(そのケースが多いはず)、難易度は上がります。具体的に見て行きましょう。

node-webkit-agentで増加したオブジェクト一覧を見る

続きを読む
posted by @shibukawa at 18:31 | TrackBack(0) | 日記 はてなブックマーク - JavaScriptのメモリリークを10倍速で発見する

2014年03月11日

詳細設計書は必要か?

よく使われている or 仕様が分かっているフレームワーク上で作業するならコード読めば理解できるので不要だと思います。実際、数週間前からチーム変わったけど、社内の共通フレームワーク上で平準化されているので、まったくドキュメント不要でした。すべての箇所に平等に書く必要性はないと思います。

とはいえ、去年、僕が当時詳しくなかったアルゴリズムのFM-indexで検索エンジンを作った時は、解説の本、論文、参考実装のC言語のコードがないと手が出なかったので、完全に無くせるかというとムリかなぁ、と思います。今も別の論文を読みつつ実装にチャレンジしてますが、コード1行に対して数倍の解説が欲しいぐらい難解でなかなか進まないです。

まぁ、詳細のドキュメントがいらないような簡単な仕事しかしてないと、どんどん自分のエンジニアとしての価値を切り売りしているような気がするので、「一行一行、コメントめちゃくちゃ書きたい!」ってついつい思うような難易度の高いことにどんどんチャレンジしていきたいですね。

posted by @shibukawa at 12:32 | TrackBack(0) | 日記 はてなブックマーク - 詳細設計書は必要か?

2014年03月01日

華氏で気温を言われてもしっくりこないんです・・・

アメリカは自分中心すぎる、みたいに言われる理由の一つが温度。アメリカでは天気予報が華氏(℉)を使っています。とはいえ、日本でも馴染みがあるけど他国で使われてない単位とかいっぱいあるし、タタミ一畳の広さは地域によって違うとか、さらにヒドイものもあるし、まぁ郷に入っては郷に従えでいいのかな、と思っています。

DeNAサン・フランシスコの大塚さんが、以前Facebookにこんなことを書いてました。

そもそも、摂氏のほうが、水の凝固点が0度、沸点が100度と、曖昧なポイントに0度と100度がある華氏よりも実用的だと個人的には思うのですが、アメリカ人の友人には、「そんなことはない。華氏100度になると、人間はくたばる。華氏0度になると、やっぱり人間はくたばる。だから華氏の方が明確で実用的だ。」と言われ、少し負けたと思ってしまいました。

これは分かりやすい。摂氏は水が基準。華氏は人間が基準。華氏も人間の体感と結びつけて考えれば数値を言われた時に「ああ、このぐらいか」「こういう服装でいけばいいか」と考えやすいのではないかな、と思います。頭に換算表を作るのではなく、イメージを作るというのがこのエントリーのゴールなので、あえて摂氏は書きません。

  • 0: 人間が死ぬ温度。スキー場でも北海道の内陸とかじゃないといかない温度。
  • 50: アメリカ人がTシャツになり始める温度。日本人は長袖。サン・フランシスコの冬、東京の秋がこのぐらい。
  • 70: 日本人もTシャツになり始める温度。アメリカ人は上半身ハダカになり始める。サン・フランシスコの夏がこのぐらい。
  • 80: マイアミとかリゾートな温度。
  • 100: 人間が死ぬ温度。熱中症とかがニュースに出てくる温度。体温として考えても、病院にいったり薬を飲む温度。
  • 375: 天ぷらとかオーブン料理をする温度。

だいぶ僕の中でもイメージができあがってきました。

posted by @shibukawa at 05:52 | TrackBack(0) | 日記 はてなブックマーク - 華氏で気温を言われてもしっくりこないんです・・・

2014年02月12日

Re: 東京の飯の話

カリブ海に1週間クルーズ行ってきました。世界最大の船のAllure of the Seasは圧倒的な大きさでサンダルで歩いたら擦れて足が痛くなるレベルでした。バハマとかは行ったけど、パスポートの提示を求められることは少なく、アメリカ入国で税関書類は書くけど入国スタンプは押されないし、国内旅行の延長扱いでI-94ステータスの更新にはならない(Customs and Border Protectionの窓口で確認済み)のでアメリカ滞在者は要注意ですよ。

帰ってきたらいつの間にか都知事選が終わっていたり、オリンピックが始まっていたり(クルーズ船の中のスポーツバーで放送してたのはスーパーボールとXGameとNBAぐらいなので知らなかった)していたのと、なんか東京の食事に関するブログの記事が話題になってました。

まあ東京圏の人数とWikipedia?に書かれていたのは東京+横浜で、中本は大宮とか北の方にはあったけど南はあまりなくてちょっと偏りがあるので厳密なカウントではないけど、だいたいのオーダーはこんなもんかと思います。

東京はでかいので、人口比を計算すると、他の町の方が圧倒的だったりすることがよくあります。「とちぎRuby、人口比でいったら東京の勉強会よりも圧倒的に多いじゃん」みたいな話をしたこともありましたね。10数人参加だと、毎月Ruby Kaigiクラスの勉強会を開催しているイメージですよ。あと、「一見さん相手だけでも生き残れる」というのは、観光地の鎌倉がそんな感じ、という話を聞いたことがあります。とにかくランチを食べる場所が少ないし、観光客相手の店が多くてみんな高い、と鎌倉で仕事をされていたカヤックさんの方が言われてました。鎌倉に比べたら東京は選択肢が桁違いに多い気がします。

サン・フランシスコにいると、ちょっとしたレストランでも結構かかります。ただでさえ高いうえに、チップ+税金(外税)で3割近く額面から増えることもザラ。チップも、税金を抜いた額の15%程度で、ランチは10%、みたいな日本語の説明はあるけど、15〜20%、社交的なイケメンはざっと切り上げてさらに気前よくチップを置いとく、みたいな感じで15%は最低限という感じですね。

結果、夫婦でハンバーガーとかラーメンのお店で$35とかいっちゃいますし、「レストラン」という感じのところだと最低で$50ぐらいのイメージ。ランチでしゃぶしゃぶ(SHABUWAY)で$25、ベトナム料理のフォーとかアジア料理の店で$20-$25というのが安いクラスかなぁ。それ以下だとマクドナルドとかバーガーキングみたいな安い上にチップがいらない店とか、ホットドッグ等の食事というかスナックみたいなものしかないですね。コストで考えれば東京の方が1000円以下ぐらいのところで選択肢がいろいろあって、良い所が多いと思います。モールのフードコートも日本の方が値段的に良い気がします。Panda ExpressとかモンゴリアンBBQがかろうじて勝負できるぐらいかな、と。サン・フランシスコとかストレスがマッハな気がするので、食事事情が大事という人はあまり来ないほうがいいかもしれません。カレー10食連続でもOKという程度の意識の低い僕には問題ないですが。

他人の味覚という世界

味覚って言葉で正確に伝えるのって不可能なんですよね。冷たい水の味がどう感じるのか、言葉で説明できる人はおそらくいない。あくまでも、同じようなバックグラウンドを持つ人が「この料理みたいな味」とか相対的に伝えるか、ワインのソムリエみたいなイメージで伝えるしかなくて、直接的に表現するのはできない。で、バックグラウンドが違うとおそらく会話ができない。優劣をきちんとつけるのも難しいし、一方的な相手のDisにしかなりようがない気がします。

このことは過去Twitterで何度か書いているので僕を知っている人は何回か見聞きしているかもしれませんが、以前、インドの人(ヒンズー教で牛がダメ、週に一回すべての肉類がダメ)とパキスタンの人(イスラム教で豚がダメ)を一緒にランチに連れて行くという過酷なミッションを遂行したことがありますが、その時は「まぁ豆腐のコース料理の店なら肉使ってないから大丈夫でしょ」と思って連れて行ったら、「味がない」というようなことを言われました。チリに行った元同僚も「チリは塩味が濃い」と言っていたし、基準となる塩味のレベルですら地域差が結構あって、「すべての人が満足」という味を作るのは不可能なんだな、と悟ったできごとでした。

で、日本の人は「ダシが大事」と言いますが、しばらくアメリカにいてから久しぶりに日本に戻ると違和感を感じるものがあります。うまみ調味料(グルタミン酸ナトリウム)というやつです。日本ではいろんなところでうま味調味料がすごい使われています。アメリカではグルタミン酸ナトリウムはあまり健康に良くないものという扱いで、No MSGとか書かれている店とか食品がたくさん目につきます。うまく消化できない人に体調不良になることもあります。アメリカでは塩と脂が多少多くてもうまみ調味料を使うことはないので、料理がシンプルな味に感じます。まぁ、塩分がちょっと多いアメリカのSalt & Vinegarのポテチと、うま味調味料が効いていて塩分が多少少ないカルビーのコンソメパンチのどちらが体に悪いかというとどっちも良くない気はしますが、ちょっと距離をおいてみると日本は「うまみ調味料依存症」だなぁ、と感じます。僕はSalt Vinegarのアメリカンポテチの方が好きですね。

あと、サン・フランシスコでありがたいのは、屋内の喫煙が禁止な点。日本の飲み屋とかの室内のタバコの臭いとか僕にはちょっとムリです。サン・フランシスコも外に出ればタバコとかマリファナとか臭ってくることもありますが、バーとかレストランで煙の匂いが一切しないのはうれしいです。

別の例をあげます。日本のスーパーにはさまざまな種類の醤油がおいてあります。出汁も、カツオからコンブから煮干しからいろいろあります。当然日本人でこれらの差を識別できる人はたくさんいます。で、一方のアメリカ。今朝近所のスーパーで撮ってきたんですが、アメリカには大量のバーベキューソースが売っています。同じ銘柄でも何種類も。日本人の僕にとっては、まだこれらの味の差がよくわからないです。「アメリカ人はバーベキューソースをかけてみんな同じ味にしてしまう」ということを言っている日本人もいます。でも、これだけ種類があるということは、アメリカ人にはこれらのソースの味の差が付けられるということです。

この「味覚の解像度の差」は結果として以下の2種類の判断につながります。

  • 自分にはこの味の差がよく分かる。あいつらは「味がない」とか「違いがない」とか言いやがる。俺の方が味覚がすぐれている。
  • あいつらはどれもこれも同じ味にして満足しやがる。あいつらの味覚は壊れている。俺のほうが味覚がすぐれている。

どちらも同じ結果になって、お互いに「俺のほうが優れいている」という考えを強化しあうことになります。最初にあげた水の味だって、状況次第でまったく「おいしさ」が変わりますよね。僕は料理番組の中では、難しい顔して食べてる料理の鉄人よりも、幸せいっぱいに食事を楽しんでいるでぶやの方が好きです。

トイプー教のススメ

まとめると:

  • 東京はまだマシな方。サン・フランシスコにも中本と丸亀製麺欲しい。
  • 味覚をお互いに比較するのは難しいし、生産的な会話にならない。

とりあえず、味覚で相手をDisった記憶が一度でもある人は、下記の言葉を胸に刻んで、町中でトイプーを見かけるたびに手を合わせて拝むようにすれば、不要な争いはなくなるんじゃないでしょうかね。

そういえば、Twitterのアカウントを増やしました。日本語のツイートは今後@shibu_jpになります。

posted by @shibukawa at 04:19 | TrackBack(0) | 日記 はてなブックマーク - Re: 東京の飯の話
検索ボックス

Twitter

www.flickr.com
This is a Flickr badge showing public photos and videos from shibukawa.yoshiki. Make your own badge here.
<< 2018年12月 >>
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
最近の記事
カテゴリ
過去ログ
Powered by さくらのブログ