先日、社内でストリーミングの技術背景について勉強会をしました。 HTTP ストリーミングや HTML5 が身近なものとなり、スマートデバイスの普及によって古いブラウザを気にせずそれらの技術を享受できるようになりました。その動向の背景には、規格戦争があり、標準化や互換性やベンダーロックインがあり、直接的に技術とは関係ないエコシステムに翻弄されたりもします。そして、そういったものに振り回されるのは、体系的にいまの状況を把握できていないからだという自身の反省からまとめたものです。 たぶんこの資料は、これからストリーミング機能の開発を任せられた新人プログラマーが、どこを調べれば良いか、何ができて何ができないかを把握するのには適しています。足りない点も多々あるように思いますが、その先は自分で調べてください。また、このスライドを公開後に年月が経ってから見ると内容が古くなって適切ではない可能性が高いので

※本記事は最後まで読まないと誤解されかねない内容を含むため、Web広告に敵愾心を抱いてる方、プライバシやくざの方などは閲覧をご遠慮ください http://hatenablog.com/js Hatena.Diary.setupTrackとかHatena.Diary.trackEventNowとかあるのにnavigator.doNotTrackを見てないのが気になりました。 別にこのことを批判したいわけではありません。ぱっと見た感じ表示しているURLやreferrerなどの一般的なサーバーのアクセスログに記録される情報だったり、表示にかかった時間やスクリプトエラーなどのセンシティブでない情報を記録してるだけに見えます。Do Not Trackがこの手のものまで禁止してるかも知りません。 ただ今回の件ではてなブックマークボタンのトラッキングの件にふれてる人が見当たらなかったので一言いっておきた

Ext JS や Sencha Touch など Sencha 製品は、世界中で使われています。Ext Japan のサイトでは、「世界中で100万人以上の開発者が Sencha フレームワークを使っています」と普及の規模を謳っています。携わるエンジニアが増えれば、コミュニティが発生するのは自然の流れで、Sencha 製品を利用する有志のコミュニティが世界各地で作られています。 大規模なところだと、ロンドン、シカゴ、パリ、、そして先日、日本でも Sencha 製品のユーザーグループが設立されました。 Japan Sencha User Group： http://www.meetup.com/Japan-Sencha-User-Group Japan Sencha User Group（※略して Sencha UG）は、Ext JS や Sencha Touch を使っているエンジニア同士

ありえるたんは英語を話せるのかな？ プログラマーは英語の読み書きに慣れていますが、普段の生活の中で話す機会は少ないかもしれません。いざ話そうとしてみると、英単語が思い浮かばなかったり、うまい言い回しができなかったりします。 今回の勉強会の目的は英語を話すことです。自分のやっていることや思ったことを英語で伝える練習の場です。既に定員には達してしまいましたが、シリーズ化するという噂も聞きますし、補欠登録しておいて頂ければ定員追加も検討します。 開催概要 日程: 2012-10-17 (水) 19:00 – 21:00 場所: アリエル・ネットワーク 会議室 (黒崎ビル6階) 登録はこちらから: http://connpass.com/event/1063/ ハッシュタグ: #pyhack_en

誰の陰謀か知りませんが、ある日、会社のデスクの上にGoogle Adwordsの無料クーポンが置いてありました。せっかくなので使ってみました。 Googleでemacsを検索するとありえるえりあの広告がでます。証拠のスクリーンショットです。

先日, とある飲み屋で「OpenFlow って何？」と聞かれた際に, 『SDN を実現する一手法』とか『スイッチをプログラマブルに制御する手法』といった辞書的な説明しかその場でできなかった時, 自分の未熟さを痛感しました. その分野に精通するという事は, 相手に平易な言葉で容易に理解させる事も含んでいると思うので, この場で先日の屈辱を晴らしたいと思います. 『OpenFlow の本質とは？』 NEC の OpenFlow 事業の大物. 岩田氏曰く OpenFlowの本質は「プログラマブルであること」 だそうです. ここでの話は, OpenFlow での L2 から L4 までのプログラマブル制御により, ヘテロジニアスなネットワークを柔軟かつフレキシブルに設計できるという内容です. OpenFlow の出発点となった, ネットワーク系のトップカンファレンスの ACM SIGCOMM で発

最近の社内の新卒第1期生ブームを受けて、第ゼロ期生が本気を出し始めました。 もともと才能は一級品と言われてきた逸材です。そんな第ゼロ期生のレポートを本人了承を得た上で掲載します。トラフィック制限の話です。 iptablesのhashlimitでトラフィック制限 参考サイト http://c-heart.sakura.ne.jp/mt/archives/2009/10/iptables.html http://kfujio.blog78.fc2.com/blog-entry-72.html 設定 特定のIPアドレスとの通信のhashlimitを1666パケット/secに設定 (mtu = 1500の場合 1666 (packets/sec) * 1500 (byte/packets) /1024/1024 = 2.38MByte/sec となる事を意図) それ以外の通信については all p

Java-based な OpenFlow コントローラとして Jaxon を開発しました. http://jaxon.onuos.org/ 一般的に「OpenFlow コントローラ」と言った場合には, OpenFlow Controller を実現するアプリケーションフレームを指します. Jaxon は Java での OpenFlow アプリケーションフレームワークになります. ご存知 (かどうかは知りませんが) OpenFlow は Switch を制御するための共通規格で, SDN (Software Defined Network) を実現するもっとも有力かつ現実的な方法として注目されています. 最近では, Software Design で連載されている NEC (の中の人) が主に開発している Trema プロジェクトが有名ですが. 他にも Nettle や Floodlig

前回に続いてトーキョーギークスタイル(TGS)に登壇しました。「Webアプリのアーキテクチャの歴史と進化」について話しました。セミナー資料を公開します(過去文書含めて、上部の「ドキュメント」メニューからたどれます)。 Webアプリのアーキテクチャの歴史と進化 セミナー後、Webアプリの歴史がDIまでって中途半端じゃないですかと指摘を受けました。その指摘は正しいと思います。私的メモではもう少し先のPlay Frameworkまでの史観を作っていました。 セミナーでの説明をDIでやめた理由は、それ以上話すと内容が更に散漫になりそうだったことと、評価の定まっていない動向を語るのに躊躇したこと、そしてそもそもPlay Frameworkを語って新しい動向も知ってますアピールをして自己満足したいだけではないかと自己分析してしまったからです。 ここに書く分にはどうでもいいので手元で作っていた私的史観を

自信のないタイトルは1年前に「2011年には流石にリリースされると思います」と書いてしまった反省からです。 リリースに関わっているわけでもないのに根拠のない予言をするものではありません。更にさかのぼること3年前には、Apache2.4カウントダウン?のタイトルで記事を書いています。もはや狼少年状態です。 Apache2.4の新機能の中で意外にフィーチャーされていませんが、個人的な注目はevent MPM(とAsynchronous support)です。いわゆる非同期I/O動作のイベントドリブンなmpmです。非同期I/Oのイベントドリブンと聞くと、nginxと同じ動作?と思う人もいるかもしれませんが、動作モデルは異なります。 Apacheを知っている人は、event mpmがバージョン2.2から存在するのを知っているかもしれません。バージョン2.2では実験的(experimental)mp

ハイデラバードの話の続きです。 ハイデラバードの某大学の図書館に行きました。そこで設置してあるPCのOSはFedoraでした。ちなみに書架にもFedora本とRedHat本はたくさんありました。一方、Ubuntu本とDebian本はあまりありません。プログラミング言語の書籍は、C、C++、C#、Java、Perl、Pythonが揃っている印象でした。日本と比べて少ないと感じたのが、JavaScript、PHP、Rubyです。正確に言うとRuby本は探しても見つけられませんでした。もちろん、図書館なので、人気があって借りられている可能性も否定できません。 さて、今回は本が主題ではありません。図書館の設置PCの話です。 最近は、公共機関に設置するPCはWebブラウザさえ動けば充分な場合も多いと思われます。このため、無償OSでコスト削減する流れが一定数増えてもおかしくありません。 世の中の一部に

最初に注意事項です。下記の話は「たった3人」に聞いた話です。統計的な意味はまったくありません。念のため。 昨年末、インドのハイデラバードに行きました。そこで3人の学生と話す機会がありました。そして驚きました。なんと彼ら3人が揃いも揃ってVimユーザだったのです。 こう聞くと、なんだインド人のITスキルは凄いと聞いていたけれど、実はIT後進国なんだね可愛そうに、と思うかもしれません。 その認識は間違いです。インドの他の都市はともかくハイデラバードはIT先進都市です。Vim使いの学生たちのレベルも日本のトップ高の学生に引けを取りません。彼らはHadoopを使うプロジェクトに従事しています。Amazon EC2も使いこなしています。単なるツールの使い手というだけではありません。たとえばSVM、DHT、HMMなどの略語が説明なしで学生に通じます。略語は順にサポートベクタマシン、分散ハッシュテーブル

前回の「オブジェクト指向について語った時に使ったメモ」に続いて、今度はインターフェースについて話しました。 用語や表現が違うだけで結局オブジェクト指向の時と同じことを話していないかと思ったなら、たぶんその直観は正しいのだと思います。自分でもそう思います。 前回も少し言いましたが、「オブジェクト指向」という用語には、過剰な思い入れや大げさな物言いがまわりにまとわりすぎて、快く思わない部分があります。オブジェクト指向設計ぐらいなら許せますが、オブジェクト指向を認知論や世界観と結びつけるような説明は誇大広告めいて好きではありません。 それに比べるとインターフェースは巨大な対象を分割統治していく時の武器として実にわかりやすく、素直に向き合えます。 20代の頃、Lotus Notesの数百万行のコードと格闘していました。デバッガで追えば細部は理解できますし、バグも直せました。しかしいくらコードを読み

オブジェクトについて抽象から具象まで取り混ぜて説明していた時、最も具象なレベルで見れば、オブジェクトはメモリ上に確保した領域にすぎないと説明しました。 そんな説明をしていた時、メソッドの実体ってどこにどうあるのですかと質問を受けました。人の心はどこにどうあるのですかという質問に比べると緩い質問ですが、良い質問だと思いました。こういう疑問を持つのは大事だと思うからです。自分もかつてプログラムとは結局のところどう実行されるのかが気になりました。プログラマなら誰もが通る道だと思います。 そんなわけでJavaのような箱入り娘から離れて、デレのないツンデレ娘ことC言語で古のテクニックを見せることにしました。 とりあえず次の簡単なコードから始めます。C言語は知らなくても構いません。関数fnがあって、引数に2を加算して返すことだけを読み取ってください。 #include <stdio.h>

追記 タイトルが微妙にミスリーディングだったかもしれません。RangeヘッダのCVE-2011-3192はリバースプロキシとは無関係に起きる問題です。 Rangeヘッダの問題(CVE-2011-3192)が大きすぎて、Apacheにある他のリバースプロクシの問題の影が薄いので書いておきます。きっかけは、このITmediaの記事です。ふたつの別個の問題を混在して伝えている気がするからです(書き方が思わせぶりで詳細を書かないので真相は不明ですが)。 Apacheをリバースプロクシで使った時に次のふたつの問題が最近見つかっています。 mod_proxy_ajpとmod_proxy_balancerを組み合わせた時に起きる問題。不正リクエストを送ってDoS攻撃が可能 mod_proxyと特定の設定で起きる問題。内部サーバなどに外部からアクセスされる可能性がある 前者のCVE-2011-3348のバ

来月9月にパーフェクトJavaScriptが出ます。紛らわしいですが、パーフェクトJava (PERFECT SERIES) (PERFECT SERIES 2)ではなくパーフェクトJavaScriptです(「パーフェクトJava」のJava7対応はしたいとは思っていますが未定です)。 今年4月に実践JS サーバサイド JavaScript 入門を出したので、1年に2冊執筆とは凄いな(=暇だな)、と思うかもしれません。自分の中では「実践JS サーバサイド JavaScript 入門」は去年執筆した本で「パーフェクトJavaScript」は今年執筆した本なので、1年1冊ペースです。 「実践JS サーバサイド JavaScript 入門」はタイトルに反してNode.jsの話が少ないじゃないかと言われましたが、今回の「パーフェクトJavaScript」は2章分もNode.jsに割きました。前作で

「実践JS サーバサイド JavaScript 入門」を書いている最中に名前だけは聞いていて、モノがないのになぜか存在感だけのある不思議なサーバサイドJavaScriptにWakandaというものがあります。 そのWakandaが遂に登場したようです。2年間もWebサイトにcoming soonを載せ続けた大物ソフトです。Chandlerぐらい期待したくなるソフトです。 JavaScript処理系はWebKitのJavaScriptCore系(Squirrelfish)を使っているようです。JavaScriptCoreはSafariのJavaScript処理系です。Chromeのv8(node.jsが使っているので有名)、FirefoxのSpiderMonkey(多くのサーバサイドJavaScriptが採用)、JVMのRhino(JVM系のサーバサイドJavaScriptが採用)がある中、

GAE for Goがでたので、試してみました。Golangはとっても好きな言語ではあるんですが、まだ、それでちゃんとしたモノを作る、っていう気にはなれませんでした。僕はわりと言語には保守的なんです。でもGAE for Goがでたので、この用途にはちょうどいいかな?と。Google App Engineの日本語のサイトではGoの情報はまだ、でていません。SDKのリンクすら見当たりません。なので、英語のサイトをみます。 [続きを読む…]

Google App EngineでもDjango使っている人が多そうな気がしますが、僕はDjangoはよく分かりません。Djangoの本は買ったりしましたが1ページも読んでません。Pythonでは普段は大体Flaskを使っています。これぐらいの規模のフレームワークが僕にはしっくり来ます。それで、GAEでFlaskを使って開発しようとしたときのメモです。 [続きを読む…]

アナウンスメールです。ハング(hang)するとか、クラッシュ(crash)するとか、互換性バグ(breaks binary compatibility)とか怖い文句が並んでいます。 Apacheほど保守的なリリース方針でもこんなことが起きます。ソフトウェア開発がいかに難しいかわかります。