Joel on Software に、「漏れのある抽象化」という項目がある。 TCPは、下層にある信頼性のないネットワークに対する完全な抽象化を提供しようとしているが、しかし、ときどきネットワークは抽象化から漏れ出て、あなたは、抽象化があなたを守ってくれない何物かの存在を感じ取る。そうしてこれは、私が「漏れのある抽象化の法則」と名付けた法則の一例になっている。 自明ではない抽象化はすべて、程度の差こそあれ、漏れがある。 漏れのある抽象化の法則が問題である理由の1つは、抽象化が、それが意図されているほどには私たちの生活を楽にはしてくれないことにある。誰かをC++プログラマとして鍛えていると、char*とかポインタ演算とかについて教えずに済めばいいのにと思う。すぐにSTLのstringに進むことができたらいいのに。しかしある日、彼らが"foo"+"bar"のようなコードを書いて、とても奇妙なこ

Mighttpd 作者の @kazu_yamamoto さんが、Warp をどうやって高速化したのかというのを Yesod ブログで書いています。 Improving the performance of Warp Sending header and body at once Caching file descriptors Composing HTTP response headers Avoiding system calls 頑張って読んだのでメモしておきます。 Improving the performance of Warp GHC 6 の IO マネージャは select システムコールのせいで 1024 以上にコネクション使えないし、マネージャがプロセス毎に１個しか無いからマルチコアで使いにくい。 GHC 7 になって epoll+kqueue になったから前者の問題は解決

この記事は Python Tips Advent Calendar 2012 ２２日目の記事です。 Python でデータを圧縮したい時、通常は zlib モジュールを使ったりするかもしれませんが、特に特殊な指定を必要としないのであれば、encode 関数で事足ります。 >>> s = 'Hello World!!' >>> s.encode('zlib') 'x\x9c\xf3H\xcd\xc9\xc9W\x08\xcf/\xcaIQT\x04\x00 \xa8\x04_' >>> s.encode('zlib').decode('zlib') 'Hello World!!' 同様に base64 もあるので、単純な利用の場合はこちらを使うといいでしょう。 >>> s.encode('base64') 'SGVsbG8gV29ybGQhIQ==\n' >>> s.encode('base

この記事は Python Tips Advent Calendar 2012 ２４日目の記事です。 Python の正規表現には、便利な機能がいくつかあります。ということで、いくつか見ていきましょう。 コメント機能 >>> import re >>> re.compile(r''' ... ^ # start of a line ... \[font # the font tag ... (?:=(?P<size> # optional [font=+size] ... [-+][0-9]{1,2} # size specification ... ))? ... \] # end of tag ... (.*?) # text between the tags ... \[/font\] # end of the tag ... ''', re.VERBOSE) #doctest: +E

この記事は Python Tips Advent Calendar 2012 ３日目の記事です。 今日は Python のスライス操作についてです。 基本的なスライス操作 >>> xs = range(10) >>> xs[2:5] # 2以上5未満までのインデックス [2, 3, 4] >>> xs[:2] # 前を省略した場合は0と同じ [0, 1] >>> xs[7:] # 後ろを省略した場合はlen(xs)、つまり10と同じ [7, 8, 9] >>> xs[-3:] # -3 は後ろから 3 番目（つまり len(xs)-3 と同じ） [7, 8, 9] >>> xs[-3:-1] # 当然 2 個目にもマイナスを入れられる [7, 8] >>> xs[::4] # 3 個目にはスキップ数が入れられる [0, 4, 8] >>> xs[2:-2:3] # 組み合わせ [2, 5]

C++03 には shrink-to-fit というイディオムがあります。 More C++ Idioms/縮めて合わせる(Shrink-to-fit) - Wikibooks std::vector<int> v; //... たくさんの push_back と、たくさんの v に対する削除 //その結果、v のサイズは小さいが、容量は大きい。 std::vector<int>(v).swap (v); C++11 では、この動作を行う shrink_to_fit というメンバ関数が basic_string, deque, vector に追加されました。 ただ、その辺を詳しく調べてみると、ちょっと以外な仕様があったので記事にしてみました。 何もしない shrink-to-fit shrink_to_fit メンバ関数には「〜という動作を行わなければならない」といった規定はありません。

C++11 には、複数の Lockable なオブジェクトをロックしてくれる std::lock 関数があります。 template<class L1, class L2, class... L3> void lock(L1& m1, L2& m2, L3&... m3); この関数の最大の特徴は、決してデッドロックしないことです。 そして、このデッドロックしないという要件を満たすために使われるアルゴリズムが、try-and-back-off アルゴリズムと呼ばれるものです。 今回はこの try-and-back-off アルゴリズムについて説明します。 （この記事には独自解釈が含まれているので、間違ってる部分とかあれば指摘して頂けると嬉しいです） デッドロックの条件 デッドロックは、正確ではないですが、大まかに言って以下の条件を満たすと発生します。 ロックを取得するために待機を行なう あ

TypeScript - JavaScript that scales. MicrosoftがJavaScript系の新言語「TypeScript」を発表、C#の父が開発 | 日経 xTECH（クロステック） TypeScript、JavaScript とある程度互換性あるし、読みやすい JavaScript のコードに変換してくれるし、既に実験場も仕様書もあってすごい。 ということでちょっと仕様書をざっと眺めてみました。そのときに面白いなーとか思ったのとかをメモ。 Structual Subtyping Structual Subtyping は、静的型付けの型チェックと、動的型付けのアドホックを混ぜあわせたような、いいとこ取りの機能で、 interface Point { x: number; y: number; } function getX(p: Point) { return

cabal は dependency hell が怖いので、こんな使い方をするのが一番いいんじゃないかなーという方法です。 毎回 cabal-dev を使うのは非常に時間が掛かるし容量も取るのですが、まあ dep hell に引っかかって時間を無駄にするよりはいいんじゃないかなーと。 cabal は cabal-dev をインストールするだけ cabal install cabal-dev cabal の出番はこれだけで、あとは cabal-dev を使います。 とりあえず ~/.cabal/bin へのパスは通しておきましょう。 あと、cabal install cabal-dev に失敗してしまうようなら、もうスパッと rm -rf ~/.cabal rm -rf ~/.ghc とかやって、cabal 環境を綺麗にしてしまいましょう。 作りたいアプリケーションごとに cabal-dev

発表資料: Effective STL 11 - Google スライド 10分間のLTのくせに48ページも使いました。 が、ちゃんと10分ぐらいで終わった気がします。ビデオまだ見てないのでわかりませんけど。 で、この資料は10分で説明することを目的にしてて、あまりに簡潔すぎて足りてないところがあるので、それを補足していきます。 第4項 size()で0を調べる代わりにemptyを呼び出そう empty()とsize()は、効率的には同じになりましたが、だからといって必ずsize()を使いましょうという訳ではないです。 あくまで、empty()とsize()を"効率の観点で"使い分ける必要が無くなったというだけです。 なので、どちらの方がいいかというのは、「空かどうかを調べたい」という意思が強いのか「要素数が0なのかどうかを調べたい」という意思が強いのかあたりで使い分ければいいと思います。

昨日、partake.inで、10分ぐらいでEventSourceの話をしてきました。 発表資料は一応あるのですが、それだけだと全く意味が分からないので、当日話したことをここにまとめておきます。 EventSource とは HTTP の仕組みを使って、クライアント側でリアルタイムにデータを受信するための仕組みです。 html5 の一部になっていて、 Server-sent Events に仕様が載っています。 EventSource は、技術的には単なるロングポーリングです。 つまりクライアントは HTTP を繋ぎっぱなしにすることで、レスポンスデータをリアルタイムにずっと受信し続けるという仕組みです。 普通の HTTP 通信だと、クライアントがリクエストを送信すると、サーバがレスポンスを返して終わりなのですが、EventSource はレスポンスのデータを途中までしか送信しないので、接

例えばテキストを埋め込むだけなら、 main = putStrLn $(LitE . StringL <$> runIO (readFile "hoge.txt")) -- hoge.txt の中身は hogefuga と書かれているとする。 とするだけで、 main = putStrLn "hogefuga" と同じ意味になってくれます。 ファイルが無かったり何らかのエラーが発生したらコンパイルエラーになるだけなので安心です。 型を分解していくとこんな感じ。 readFile "hoge.txt" :: IO String runIO :: IO a -> Q a StringL :: String -> Lit LitE :: Lit -> Exp runIO で IO モナドから Q モナドに変換してくれるので、あとは Q String から文字列リテラルの Q Exp に変換してる

絶対これ忘れるので、今のうちにできるだけ書いておく インストール $ km i386/qwerty/jp106.map.gz を選択 フォントはスキップ$ /arch/setup 1 Select source testing系以外は選択 3 Set clock 時間はAsia/Tokyo ntp設定する 4 Prepare hard drive(s) FSはよく分からないのでEnter連打 最後はext3を選択 5 Select packages インストールパッケージはデフォルト 7 Configure system rc.conf の設定で en_US を ja_JP にする locale.gen の設定で ja_JP.UTF-8 UTF-8 のコメントを外す パスワードも設定する pacman // ドライバとかいろいろ xorg // startx とか用 xorg-xinit

この記事は Boost Advent Calendar 13 日目の記事です。 Boost.Context は、跋扈するコンテキスト切り替えの利用を統一するべく颯爽と現れた救世主です（大げさ）。 そもそもコンテキスト切り替えって何ぞや？という場合は、適当にググるか、自分の Boost.Coroutine の発表資料あたりを読んで下さい。 現在コンテキスト切り替えを使ったライブラリで提案されているのは、LibrariesUnderConstruction – Boost C++ Libraries を調べた感じだと、 GitHub - boost-vault/Concurrent-Programming にある boost-coroutine* boost.task-0.4.3.tar.bz2 continuation.tar.gz （ここに昔は Boost.Fiber があったはずなんだけ

この記事は C++11 Advent Calendar 13 日目の記事です。 C++03 で用意されていた標準ライブラリは基本的にそのまま残っていたり deprecate されていたりとかぐらいしかありませんが、それでも少し仕様が変更されていたりとかしています。 後方互換性を維持するためあまりダイナミックな変更はされていませんが、それでも結構嬉しい変更だったりするので、覚えてる部分だけ紹介しておきます。（誰か一覧とか作ってくれませんかね？） のアルゴリズム関数に渡す関数オブジェクトの制限の緩和 C++03 では、 のアルゴリズム関数（accumulate, inner_product, partial_sum, adjacent_difference）に渡す関数オブジェクトでは、一切の副作用が禁止されていました。そのため、 struct Hoge { int operator()(int

これは Haskell Advent Calendar 2011 3日目の記事です。 Data.Enumerator はいろいろすごいらしいです。 どれぐらいすごいのかは 2010-08-24 Enumerator Package – Yet Another Iteratee Tutorial | Preferred Research 使ってみよう Enumerator - あどけない話 Enumeratorは終了条件の検査からの解放だ - あどけない話 iterateeとは何か、何が良いのか - www.kotha.netの裏 あたりが分かりやすい気もします。まあ全く理解できませんでしたが。 で、自分はこのライブラリで IO を使うときに例外処理をどう扱えばいいのかよくわからなくなったので、ここにその戦いの記録を残す次第であります。 「誰かこの辺分かりやすくまとめてくれたりとかしませんか

vector は vector に対して特殊化されていて、領域を無駄にしないように、ビット単位で格納されるようになっています。 これは使用する領域が少なくなる反面、 &v[0]+i == &v[i] であるという、vector としての特徴の一つを満たさなくなってしまいます。 他にもいくつか、bool 以外の vector と異なる動作をする箇所があります。 そのため、Twitter や掲示板等で vector の話が出るたびに必ずといっていいほど「あれは使うな。失敗作だ」とか「あれはもう忘れろ」という趣旨の発言が見られます。 そういった場面に遭遇するたびに自分は微妙な気分になります。 実際のところ、「大量のビットを格納したいけれどもメモリを無駄にしたくない」という状況がある*1とき、vector 以外の選択肢はどの程度あるんでしょうか？ まず自分で作るという選択肢、これはほとんどの場合は

Haskell にはポイントフリースタイルというのがあります。 例えば foo x = f (g x) という中の x というのが「ポイント」と言うらしいです（型を明示していないから x の型が a->b だったりする可能性もあるけどその可能性は置いといて）。要するに値のことですね。 で、このポイントを除けてプログラミングするのをポイントフリースタイルと言います。 この場合、 foo = f.g となります。 ということで、ありとあらゆるコードをポイントフリースタイルで書けるように訓練しましょう。 基本的に、書いてれば慣れるのでどんどん書きましょう。 基本 基本的に (.) 関数を使います。 foo x = f (g x) foo x = (f.g) x foo = f.g です。 また、(.) は二項演算子なので、これを関数形式で書けば、 f.g = (.) f g となり、更に = (

JSON を扱うライブラリで一番簡単に見つかるのは Text.JSON ですが、しばらく使ってると、あまりの使いにくさに発狂しそうでした。 ということで他のを探した結果、Data.Aeson というのがかなりよさげだったので、これを使うことにしました。 しばらく使ってみた感じかなり良かったので、いくつか代表的な使い方を書いてみます。 インストール aeson ではなく、aeson-native を入れて下さい。 cabal install aeson-native import それぞれのコードは、これらの import （と LANGUAGE プラグマ）が先頭にあると思ってください。 {-# LANGUAGE OverloadedStrings #-} import Control.Applicative (Applicative,pure,(<$>),(<*>)) import Con

何か FizzBuzz 問題をちょっとだけパワーアップさせたものに FibBuzz とかいうのがあるそうで、0 から 100 までの整数を FizzBuzz する代わりにフィボナッチ数の各項に対して FizzBuzz する問題なようです。 面白そうなので久々に Control.Arrow を引っ張り出してやってみました。 ラムダ式使わずポイントフリースタイルで書いてます。この辺は基本ですね。 import Control.Arrow import Data.Function (on) fib = loop (((fst >>> uncurry (on (.) (:))) &&& (snd &&& fst >>> app) >>> app) &&& (snd >>> (snd &&& uncurry (+) >>>) >>> (uncurry (+) &&&) >>> (>>> uncurr

で、こんな風に考えることにしました。 モナドは箱 モナドは単に値をくるんでるだけであると。 a をモナド化すれば m a。 でもってこうするための関数が return。単に m を付けるだけ。 モナドから値を取り出す なぜか知らないのですが、m a -> a なる関数は存在してないようです。 謎です。 ただ、do 記法というのを使えば取り出せるようです。 main = let ma = return "hoge" in do a <- ma print a return "hoge" でモナド化された ma は、do 内のみにおいてだけ a <- ma とすることで不思議な力が働いて値が取り出せます。何でこんなややこしいことするのか分かりませんが、とにかくそういうことらしいです。 モナド悲しみの連鎖 m a -> a なる関数が無いということは、一度モナド化したら、それを戻すことはできない

Real World Haskell にはこんなコードが載ってます。 myFoldl :: (a -> b -> a) -> a -> [b] -> a myFoldl f z xs = foldr step id xs z where step x g a = g (f a x) Real World Haskell p100 4.6.8 右からの畳み込み foldl は foldr を使って書けるという例です。 こんな風にほとんどのリスト処理は再帰を使わなくても foldr を使えば書けるらしい*1ので、どこまでできるのか確認するために Prelude にある Data.List の関数を再定義してみました。 ルールは、 再定義した関数は直接的または間接的に再帰していてはならない（foldr は除く） 再帰しないで作った関数を他の関数で使うのは OK 再定義した関数は元の関数と同じ計算

Data.ConfigFile 設定ファイル読み込み用のパッケージ。 こんな感じでよく使ってる。 printUsage = print "..." main = do args <- getArgs case args of [] -> pringUsage (configFile:_) -> do val <- readfile emptyCP{optionxform = id} configFile let cp = forceEither val -- 設定ファイル読み込みに失敗したら死ねばいい start cp emptyCP の optionxform はデフォルトで toLower になってて、キー値が小文字にされちゃって嫌なので何もしないようにしてたり。 あと自分は "DEFAULT" しか使わなかったり、キー値が無ければさっさと終わってくれていいようなケースが多いので、 g

std::endl って、どのヘッダで定義されているか知っていますか？ と思った人はハズレです。実は std::endl は で定義されてます。 これって を include するだけだと標準に準拠した動作にならないんじゃね？とか思ったのですけど、どうやら は も include することが決まっているようです。 ということで、どのヘッダがどのヘッダを include するのかが気になったので調べてみました。 調べ方は、仕様書の各 synopsis にある #include <...> の部分を見ました。 これが必ず include されることは、 §17.6.5.2¶1 によって決まっているようです。 以下のような結果になりました。 header include , <map> ,,, 意外に全然 include してないですね。 が特殊だったというだけのようです。 ということでちゃんと

CSS3 の ease-in や ease-out は結構綺麗なので、あの動きを実装してみようかなーと思ったわけです。 CSS3 のベジエ曲線は３次曲線なので４点が必要ですが、最初の点と最後の点は固定値なので、指定するのは２番目と３番目の位置だけです。 Ceaser - CSS Easing Animation Tool - Matthew Lein がすごく分かりやすい。 で、３次のベジエ曲線の計算式は らしいです。 で、CSS3 では と というのは固定で、,,, の範囲も決まっているので、 となります。 ただこの式を直接使えばいいかというとそうではなくて、CSS3 ではX軸を時間軸として、Y軸を結果の軸として使っているので、 から を求め、その求めた から を求める必要があります。 ということで を３次方程式として求めて を出せばいいかなと思い、ちょっと解の公式をググってみると何かい

に行って、Squirrel 言語について発表してきました。 Squirrel View more presentations from melpon 動画はこちら あといくつか補足しておきます。 Squirrel の発音について ということで、場所によって発音が微妙に違うらしいのでやっぱりみんな適当に呼びましょう ライセンスについて ということらしいです。情報ありがとうございます！ Lua より遅い件について 個人的には Lua の半分ぐらいの遅さというのは大して気にしていなかったりしているのですが、そこら辺を言うのを忘れてました。 Lua で書くと十分な速度が出て、Squirrel で書くと処理が間に合わないようなスクリプトになってしまった場合、その後スクリプトを少し追加すると、スクリプトは簡単にスケールして、すぐに Lua も処理が間に合わなくなります。 まあ当然速い方がいいのですが、