Couchbaseの作者Damien Katz氏は，C言語はバックエンドプログラミングにおいて現在でも優れた言語である，という意見を持っている。しかし他の開発者は，C言語はあまりにも欠陥が多いとしてC++やJavaを支持するもの，あるいはいずれも好まないというものなどさまざまだ。 CouchDB の開発者であるDamien Katz氏は，The Unreasonable Effectiveness of C と題した先日のブログ記事において，C言語がバックエンドのための優れた言語であると断言した。氏はC++やJava，さらにはErlangやRubyのようなより現代的な言語よりも，今後もC言語を支持していくつもりだという。ただし単純に，C言語を他のどれよりも優れた言語だと言っている訳ではない。"言語自体のパフォーマンスと信頼性が重視される場面においては，C言語に比類する言語は皆無である"，別

概要 : AMQP のプロトコルを読むと、一瞥して送信はパケットを送るだけ、受信はソケットを読み込むだけのようにも見える。しかしながら、実際に書いてみると、再送処理を自前で実装する必要があるため、現実には大変に複雑な処理が必要だ。 そもそもなぜ RabbitMQ を使うのかという話、あるいはなぜ再送が必要かという話たんにコンポーネント同士が疎結合で通信したいのであればわざわざ MQ を使う必然性は皆無である。ごくあたりまえに TCP で通信すればそれでいい。暗号通信が必要なら当然 SSL でいいし、パケットエンティティに依存する複雑な L7 リバースプロキシを MQ を使って実現することも、不可能ではないが、普通そういうのは varnish とかでやるだろう。 MQ において優れているのはデータの durability だ。つまり、一旦キューにためておけば、その両側のコンポーネントは好き勝

三つ子の魂百までとはよく言ったもので、子供のころの強烈に印象に残ってる体験というか、まあテレビで見たわけだけども、その当時ヨーロッパのまんなかのへんで政権交代が局所的なブームだったのさ。んでまあカラフルな壁をツルハシで壊してるドイツの人たちの強烈な笑顔というのが、今でも忘れられなくてですね。もちろん、今から振り返って見れば、1989年をよいとか悪いとかいう単純な評価で切り捨てるのが大きな間違いなのは分かる。けど、当時は政治とかよくわかんない程度に子供だったから、みんな「なにかが終わって喜んでるんだ」ということしか、俺には理解できなかった。だってあの人ら喜んでたでしょ。そのくらいは俺にも分かったよ。 まあそういうわけで、たしかにそのあと色々あったし一面的な評価が誤りだということは理解していますと繰り返し申し上げたうえで、でもやっぱり、少なくともあの瞬間には、終わることはよいことだったんだよ。

主に新人向けとして、Unixサーバで作業をする際の注意点を書いておく。 ここに書いてある内容は絶対的なものではないし、会社や現場ごとにルールがあるので、適宜ルールに合わせて実践すれば良い。 ログを取れ 何をやったか、何をやらなかったか、というエビデンスのためにログは必ず残しておく。SSHクライアントによっては毎回自動的にログ取得する設定が可能なので、設定しておくと良いだろう。 作業後に問題が発生した場合に作業内容を確認するためにも使うため、必ずログは取得しておくこと。 (追記) 当たり前だが、コマンドとその出力をペアで取ることに意味がある。 set -x (set verbose) しろ ログを取得しても、コマンドラインを編集した際には以下のように非常に見づらいものとなってしまう。(がんばれば解析することは出来るが…) ESC[0mESC[27mESC[24mESC[JESC[1myasu

今回のお題は char 幅じゃなくて word 幅の memset 、つまりプロトタイプだと void* memset64(void* destination, uint64_t image, int num_words); をどれだけ高速に行うかという話。なぜ高速化するかというと、塗りつぶす領域がけっこうでかいから。 候補 1: REP STOSvoid* memset64(void* d, uint64_t i, int n) { asm("cld; rep stosq;" :: "D"(d), "a"(i), "c"(n) : "memory"); return d; } 最近の CPU はクソ賢い。そのため、下手に手で loop unrolling するよりも、逆に CPU に「ここはループなんだぞおおお～」というのを明示的に指示してあげたほうが CPU 側が勝手かつ不気味に最適な

コメント欄にて書き込みのあった「沢田マンション」は、テレビなどでも取り上げられ脚光を浴び、今では見学ツアーも組まれるほどの人気なので、知っている人も多いと思うんだけども、素人が独力独学で建てた、高知県高知市薊野（あぞうの）北町に建つ鉄筋コンクリート造の建築物。 wikipediaによると、幼少時に雑誌で見た「アパート」の様子に感動した沢田嘉農（1927年8月11日-2003年3月16日）さんが、1971年、高知市薊野の土地550坪を買い求め、憧れだった集合住宅、沢田マンションの建設に取り掛かる。最初は夫婦2人ではじめたが、後に子どもも加わり、家族一丸となって建設されたんだそうだ。

地方で勉強会とか仙台Ruby会議とかやってて、いろいろ試行錯誤した自分の経験から、 Ruby会議について思うことをつらつらと書こうかと思ったけど、書き始めたら先に書かれた人達と相当かぶったので、さらっと。 Ruby会議のご利益とコスト 去年東北デベロッパーズコミュニティのイベントにて、吉岡さんが話してくれた資料からそのまま引用。 http://d.hatena.ne.jp/hyoshiok/20090305#p1 勉強会の法則 御利益＞コスト 自然と続く 御利益＝コスト 幹事の頑張りに依存 御利益＜コスト 続かない私見では・・・ Ruby会議の参加者は御利益のほうがコストを遙かに上回っている。 スポンサーは・・・どうなんでしょ？コストが上回っているのかな？スポンサーさんの意見が知りたい。 スピーカーはご利益のほうがコストを上回っていると思う。 で、スタッフの状態というのは、外から見てると、

各所にトラバしまくりの記事ですみません、スパム扱いになってるかも。特にハンドルネーム無しことid:sugioでございます。 私は庄司創というペンネームで2008年秋のアフタヌーン四季大賞という漫画家デビューを目指す新人のための賞を受賞いたしまして、昨年「辺獄にて」という読み切りで月刊アフタヌーンにてデビューしておりました。今発売中の9月号にも載っています。 30代も半ばを超えて漫画家になるなどというのは手放しでおめでたい話とは言えませんが、まずは起業できました事をネット上の皆様に御礼申し上げます。 なぜ今ごろ２年前の話かと申しますと、私は作画が遅いものでして、元々ネット好きな私が漫画関係のブログなど始めたらますます遅くなりますから、まずはプロモーションよりプロダクトをと我慢していたためお知らせも遅れてしまいました。 しかし今回、制作スタッフ募集のためにこちらの開設にふみきりますので（→作画

そろそろリリースするから今の方針をまとめておくよ 無保証の大前提本音と建前を華麗に使い分けるおまえらのためにこれは建前だとあらかじめ宣言しておくけれど、 Ruby 本体がなんらかの保証を行ったことは過去にもないし将来の予定もない。おまえらの用途にあうかも (fitness for a particular purpose)、商用利用の可能性についても (merchantability)、明確に COPYING で保証しないことを記しているし、それ以外のあらゆる保証もやはりない。だから社会的責任(笑)とかも、ない。 ともかく少なくとも表面上は俺がやってるのはただのおせっかいに過ぎないことをおまえらは注意しておく必要がある。たとえば最近の俺はかなり注意深く「サポート」という単語を回避する傾向にあるけど、それはなぜかというと COPYING の範囲を逸脱する状況に陥ると俺の手に余るからだ。Rub

今回のiPhoneの件は要するにAtariショックを避けようとしてるんだと思うと色々と腑に落ちてくるものがある つまりAppleがやってるのは露骨な任天堂の猿真似ってわけね。DSでFlashが動くかよって話。 いやもちろん、我等が偉大なる任天堂様のなさる審査とAppleの杜撰な検閲を一緒にしないで頂戴、とかの質的な議論はありうると思うんだけども、じゃあといってDS向け同人ゲーをコミケで頒布させろとかの声がマジョリティとかには絶対ならないというのは、やっぱゲーム業界は痛い目見た経験を生かしてるからなんじゃないの。 だからさ、実はAppleはおまえらプログラマを切り捨てているように見えるけど、本当は逆で、あれはおまえらを保護しようとしてるんじゃないか? クソゲーとかから。そう思うとあながち逆噴射な発想じゃないとおもうんだよなー 以上まったく根拠のないチラシの裏でした。