若い人たちは、「文字列型」があるプログラミング言語しか知らないかもしれない。だが、汎用的な文字列型が一般的になったのは、プログラミング言語の歴史の中でも比較的最近のことである。 たとえば、1972年に誕生したC言語には文字列型がない。1980年代に良く使われていたPascalの文字列型は最大255文字しか格納できなかった。 なぜか？　それはメモリが貴重なリソースだったから。 1980年代のPCの搭載メモリは多くて数メガバイト。これに対し、長編小説の長さは1MB程度に達する*1。 当時、メモリはとても貴重な資源であり、テキストを処理するプログラムを開発するにあたっては、文字列をどのようにメモリ内に展開するかプログラマが細かくコーディングする必要があった。 だから、汎用的な「文字列型」というのは「夢」にすぎなかった。CあるいはPascalにおける文字列（CのASCIIZ文字列あるいはPasca

Webサービスのようなプロダクトについての議論について教えて下さい - Kentaro Kuribayashi's blog で呼ばれたような気がしてたけど放置してた。でも今日、express という node.js 上で動作するメジャーなウェブアプリケーションフレームワークを作っているチームが、次世代の製品に取り組み始めたと聞いたので、メモを以下に貼ります。 ------------------------------ ✂ ------------------------------ ソフトウェア技術の配布手法のトレンドは以下のように推移してきた。 プロプライエタリ（仕様も実装もベンダー固有） オープンシステム（仕様は共通、実装はベンダー固有） オープンソース（実装を皆で共有） ハードウェアにしても、プロプライエタリから業界標準主導なアプローチにかわってきている。 つまり、時代とともに、

@ITに以下のような記事が出て、 今回からしばらくの間は、まったく逆の例、つまり使うとプログラムの処理性能が上がるというシステムコールを紹介していく。システムコールを呼ぶ回数は少ない方が処理性能は高くなるという原則は変わらないが、呼び出しておくと処理性能が向上するシステムコールというものが存在するのだ。こうしたシステムコールを使わないでいることは、とてももったいない。 今回紹介するシステムコールは「mmap(2)」だ。ここでは詳しく仕組みを解説しないが、mmap(2)は、プログラムの処理性能に必ず良い影響を与える。 やはりあった？ 高速化に効くシステムコール (1/2)：知ってトクするシステムコール（3） - ＠IT それを真に受けたのか、「Go言語でmmapシステムコールを使ったファイル読み込みの高速化検討とC言語のコンパイラの話 - ryochack.blog」のようなブログエントリも

前提: ゲームに限らずランキング機能が必要になるケースは多い つまり需要はある だが、MySQLで高速なランキング表示は難しい 具体的に言うと、以下の要件を満たすのが不可能 １行の更新コストが要素数Nに対して O(log N) 以下 任意のランキング位置周辺のSELECTコストが O(log N) 以下 ならば、専用のストレージエンジンを作ればいいのではないか いつやるか？　今でしょ！　以下理由 MySQL 5.5以降?だとストレージエンジンをまたぐトランザクションがまともになってるはず*1 ランキング専用でいいから、テーブル構造とか固定でいい（つまり実装が簡単！） ランキング専用だから、テーブル・ロックで十分（つまり実装が簡単！） 更新すると順位がずれる（つまりテーブルの大部分に影響がある）ので行ロック実装するメリットが小さい*2 ランキング専用でいいから、全データをメモリにもっても問題

Linux のシステムコールである write(2) の ドキュメントを読むと Atomic/non-atomic: A write is atomic if the whole amount written in one operation is not interleaved with data from any other process. This is useful when there are multiple writers sending data to a single reader. Applications need to know how large a write request can be expected to be performed atomically. This maximum is called {PIPE_BUF}. This volume of

Monoceros は @kazeburo さんが開発してる Plack 用ウェブサーバ。prefork型だけど、待機中の接続をイベントドリブンのマネージャで管理することで、同時接続10,000本とか行ける（ソケットの受け渡しは SCM_RIGHTS とか使う）。 で、雑感 大好き！！！ Starletより遅い問題は、以下のようにすれば解決できると思う listen するソケットに TCP_DEFER_ACCEPT つけて、accept(2) は worker でのみ実行する worker は HTTP レスポンス送信後に read(2) してみて、後続のリクエストが来てない場合にのみ、マネージャプロセスにソケットを返還する (追記) 「返還」ではなく、マネージャプロセスが管理しているソケットのいずれかにデータがきている場合のみ、そのソケットとworkerのソケットを「交換」する、とすれば

超軽量Twitterクライアント「もふったー」コンシューマシークレットキー難読化最後の挑戦 - GIGAZINE もふったーコンシューマシークレットキー難読化最後の挑戦 ・ω・ - Windows 2000 Blog あたりの話について。記憶に頼って書いてるので間違ってたらごめんなさい。 問：鍵を隠すことができるか 答：以下の理由から可能なはず。 HMACのキーは前置型でハッシュ関数のブロックサイズ SHA-1*1はMerkle-Damgaard法で構築される ブロックをまたぐ際のステート値はファイナライズ処理を除けば最終的なハッシュ値と同じ 以上より、鍵のハッシュを演算後の内部ステートをもつ、鍵ごとに特化したHMAC関数（正確に言うと、鍵ごとに特化したハッシュ値同様の安全性をもつ（つまり鍵を回復することのできないステート値）を生成し、鍵のかわりに、そのステート値を埋め込んだ専用HMAC関

go言語なんか import "http://github.com/mattn/xxx " だったりする。rubyもそういうの面白いかもしれない。require "http://github.com/mattn/xxx "みたいな。 mattn on Twitter: "go言語なんか import "http://t.co/9qiwho7OMZ" だったりする。rubyもそういうの面白いかもしれない。require "http://t.co/9qiwho7OMZ"みたいな。" @mattn_jp それコンパイル型言語なら許されるけどスクリプト型だとセキュリティホールとされるものでは？ (e.g. PHP) Kazuho Oku on Twitter: "@mattn_jp それコンパイル型言語なら許されるけどスクリプト型だとセキュリティホールとされるものでは？ (e.g. PHP)" と

静的型付けと動的型付けのどっちが優れているか。どのようなプログラムを書いているかによって答えはかわるんじゃないの？ たとえば、自社で開発・運用しているウェブサービスなら「問題が出たら修正」すればいいんだし、バグがないことを保証するよりも迅速に開発できるプログラミング言語（つまり動的型付けの言語）がいい。 逆に、客先への納品が発生するソフトウェア製品なら「バグがない形で出荷する（様々な状況・環境下でちゃんと動作する）」ことが重要だから、静的型付けの言語を使うことで品質を高めるというのは合理的な選択*1。 細かな論点はいろいろあるだろうけど、基本的には、このようなソフトウェア開発に対するスタンスの違いで決まる話だと思います。 別の言い方をすると、動的型付けの言語は流行ったのは、ウェブには前者のアプローチが適していたからだし、スマホアプリには静的型付けの言語がむいていると言えるのでしょうね。それ

開発者の皆さんは、gzipされたcore-fileを送りつけられた経験をお持ちのことだと思います。ですが、ディスク容量に厳しいSSDやVM上で作業していると、展開すると数10GBにもなるコアファイルを受け取ってもどうしようもありません。 で！も！　コアファイルをスパースファイルとして展開すれば解決☆ gunzip - < ../core.12345.gz | cp --sparse=always /proc/self/fd/0 core.12345具体的にいうとこんな感じですね。なんか一仕事終えた感あります。まだ解析してないんですけど。

Labeled Tab-separated Values (LTSV) がブームのようです。 LTSV については、ラベルをつけることで柔軟に拡張できるという点が、その特徴として取り上げられますが、もう一点、タブをセパレータに使うことでログのパースが簡単になった、という点を忘れるべきではないでしょう。 特に httpd のログは NCSA httpd という HTTP/0.9 時代のWebサーバのログフォーマットがベースに拡張されてきたため、以下のようにセパレータとして空白、[]、ダブルクォート ("")*1が混在するという、とても処理しづらいものになっていました。どれほど複雑かは「404 Blog Not Found:perl - Apache Combined Log を LTSV に」の実装を見れば明らかでしょう。 127.0.0.1 - - [08/Feb/2012:23:52:4

JSX の進化速度が半端ない - ぐるぐる～ で紹介していただいているとおり、最新の JSX では function expression の型宣言を省略できるようになっています。これを利用して、たとえば配列の合計を求める場合、 var sum = 0; [ 1, 2, 3, 4, 5, 6, 7, 8 ].forEach(function (n) { sum += n; }); のように、JavaScript と 100% 同様に書くことができるようになりました。省略形を利用して [ ... ].forEach((n) -> { sum + n; }); でもいいです。 ところでこのコード、見た目は同じなんですが、実は JSX だと JavaScript よりも５倍以上速く動くんです。まだ最適化があまいところがあるのに。 なぜか。JavaScript の Array#forEach は配

なぜ「速い」のか、について JSX 開発者の立場から。 たとえば、シューティングゲームで一番重たい処理は何か。言うまでもなく衝突判定。多数の弾や敵機の衝突判定を毎フレームごとに行う必要があり、この演算が重たい。 JSX に同梱されている web/example/shooting.jsx には衝突判定のコードが複数あるが、一番重たいのは Bullet#update 関数で、その処理は以下のようになっている*1。 for (var rockKey in st.rocks) { var rock = st.rocks[rockKey]; if (this.detectCollision(rock)) { if (rock.hp == 0) return false; inDisplay = false; if (--rock.hp == 0) { st.score = Math.min(st.s