Old Brains - kuenishi's blog
そろそろ歳も40近くなり、老いについて考えることが増えてきた。たとえば10ヶ月も続く在宅勤務の中で少しでも運動をサボると左膝がすぐに痛みだしたり、うっかり水分を摂り忘れたりすると頭痛がきたりする。もちろん体重は史上ピークを記録し続けている。身体の老いについては、まあそういうものであるし、特に外見などに気を遣って生きてきたわけでもないからそんなには気にしていない。しかしながら、人間の人間たる由来はその精神や振る舞いにあると思っているから、そちらでの老いの方が問題だ。 前職までは大抵、わたし自身は年齢が1番か2番めくらいに若い職場で仕事をしていることがほとんどであった。ほとんど同年代か、10から20くらい上であることが多かったように思う。単に物理的な年齢もあるが、職業経験も私より長い人たちばかりであったので、教わることの方が多かったから、物事の考え方が揃っていたことが心地よかったということには
あなたの知らない time(1) の世界 - kuenishi's blog
自分が書いたプログラムのメモリ使用量を測定したいことがある。プログラムがOOM Killerによってお亡くなりになった場合や、ページフォルトをなくして高速化したい場合などだ。定常的に起動するサーバーのプログラムなら、sarや meminfo など（今なら Datadog とかだろうか）を使ってじーっと見つめるわけだ。もっとモダンにやるなら perf や DTrace を使ってもよいかもしれない。しかしこれらのツールは基本的にプロセスIDを渡してサンプリングして外から覗く方法だ。 わたしのユースケースはデーモンプロセスではなく、 main から入って必要な計算をして、それが終わったら main を抜けるバッチジョブ（単にコンソールから実行して終わるまで待つ、いわゆる "Hello world!" 的なやつ）だ。これだと、プログラムが起動して終わるまでそこそこの時間で終わってしまって、外部プロ
Stellar Consensus Protocol - kuenishi's blog
筑波大の川島さんに教えてもらって読んだ論文 The Stellar Consensus Protocol: A Federated Model for Internet-level Consensus がけっこう面白いので、紹介しようと思う。 32ページの長文で証明つきなのでガッツリ読み込めたわけではないのだけども。。。 背景 Bitcoinを始めとする電子貨幣（暗号貨幣）のブームは大きな投資を呼び込んで市場を開拓しつつある。またBitcoinの署名チェーンの部分のみを応用して、チェーンの合意を独自に構築する類似技術や製品をブロックチェーンと呼んだりする。私の理解だと、いずれもProof of WorkやProof of stakeの部分が難しい。PoWだと必要以上にアナーキーで時間がかかり、やたらCPUを食ってエコではないし、PoSでは結局は既存貨幣と同様に権威による認証が必要になること
次世代ウェブカンファレンス #nextwebconf に参加できませんでしたのでお詫びします - kuenishi's blog
去る10月18日に行われた次世代ウェブカンファレンスは、わたしもサーバーアーキテクチャーというセッションにスピーカーとして呼ばれていた。わたしも話す気満々だったが、当日の朝になって次男が発熱してしまい家庭の予定を変更して妻は次男、わたしは長男を連れて彼の予定をこなすことにした。ので泣く泣く当日朝に参加を断った。当日は盛況だったようで何よりである。 当日はスタッフが充実していて、ストリーミングや録画も行われた。わたしが出るはずだった server_arch セッションの動画も公開されている。ここでは、当日言おうと思っていたことと、この動画を見て言いたいことをここに書いて当日参加できなかった詫びとしたい。すまんかった。 ウェブ is 何 / 次世代 is 何 CERN発祥のHTTP/HTMLで情報伝達する仕組み（昔WWWとか言われていたもの）が普及しきって、あらゆる情報がインターネットを介して
Papers We Love というコミュニティ - kuenishi's blog
第4回 システム系論文輪読会 - connpassが開催されると聞いて、思い出した話。日本だと、○○読み会という形で、特定の国際会議の論文をうわぁーっと集中的に輪読するコミュニティはいくつかあるけど、ある分野なりをまとめて回し読みしようという試みはないように思うので、ここで Papers We Love というコミュニティを紹介しようと思う。 Papers We Love Too - October 2014 - YouTube 予め断っておくが、ぼくはまだ参加したことはないし、同僚がたまたまファウンダーの一人なので知っただけだ。これがなかなか面白い試みだ。 Papers We Love is a repository of academic computer science papers and a community who loves reading them. ということで、計算機
Riak Core の紹介 - kuenishi's blog
Erlang アドベントカレンダー 2014の23日目の記事です。 Erlang/OTPでアプリケーションを書いていると、システムを冗長化するために複数ノードでうまく協調動作するようにさせるために、Distributed Erlangの上に構築されたFailoverやTakeoverを使う場面がいずれ出てくる。しかし、これらの仕組みは、Riakのようにシステムをスケールアウトさせたい場合には不十分だ。スケールアウトするシステムの本質は アクセスしたいモノの物理的な位置を隠蔽して論理的な位置でアクセスできるようにする 物理的な位置が故障やスケールアウトのために変化しても常に追跡できて同じ論理的な位置でアクセスする アクセスしたいモノが偏らず、ほぼ均等に分散されている の3点がサポートされていることだ。これだけだといろんなものが該当するが、 Riak風に翻訳すると アクセスしたいデータがどのノ
そろそろGoについて一言いっておくか - kuenishi's blog
昨日、GoCon（ごうこん）なるイベントに参加してきた。以下に続く話は5割以上がフィクションなので虚実織り混ざっている様を楽しみながらお読みいただけたらと思う。 最初に発表されたニュースを聞いたときは、Goはよい車輪のよい再発明で、結局GoogleはC++やJavaを使い続けるだろうし、世間はGoogle独自言語としてみなすのだろうなという予感はあったし、2010年だから2011年ころはそういう見方をされていたように記憶されている。私もそういうものだと思っていたし、特に関心を持つこともしなかった。いま思えば正常性バイアスだったのだろう。 実際に昨日のカンファレンスで一番興味深かったのは鵜飼さんによるGoの解説だった。比較対象がC++, Python, Javaだったことが最も印象的で、普段からErlangやOCamlといった関数型言語に接していた身として新鮮だった。話を聞くうちにGoogl
ひとりでやるRiak Advent Calendar 2012 day6 - MapReduceで遊んでみよう - kuenishi's blog
ふつうのKVSだと、シンプルなput/get/deleteの3種類のオペレーションがあって、あとはせいぜいリッチなやつだとスキャンができたり、分散してないやつだとインデックスが張れたりトランザクションぽいものができたりするようになっている。しかしSQLのようなクエリを書けるものはドキュメント指向DBと呼ばれる一部のものだけだ。 まずは準備として、どこでもよいのでRiakをひとつ立ち上げる。コンソールから手書きでMapReduceを書いてもよいのだがエスケープやJSONの括弧を閉めるのが大変なのでオモチャのようなGUIを作ったので、まずはこれをbrowser.htmlという名前でダウンロードしていただきたい。ええいHTML/CSSがダサいのは分かっておるわ！ ではそのファイルをRiakに入れよう。 $ curl -X PUT http://localhost:8098/buckets/sta
erlang + flymake = fun !! - kuenishi's blog
以前ErlangでFlymakeしてヒャッハー！という記事を書きましたがついにErlang/OTPの公式リリースにerlang-flymake.elが入りました。R14B04から入ったようです。これで.emacsをダラダラ書く生活から一歩遠ざかりましたね。 (setq load-path (cons "/usr/local/otp/lib/tools-<ToolsVer>/emacs" load-path)) (setq erlang-root-dir "/usr/local/otp") (setq exec-path (cons "/usr/local/otp/bin" exec-path)) (require 'erlang-start) (require 'erlang-flymake)
新卒準備カレンダー2011 - kuenishi's blog
この記事は、新卒準備カレンダー2011に参加しています。 お前、誰よ？ 研究者と開発者の間、29歳、4年目、わりと大きな会社でこっそり働いています。仕事ではLinuxやC/C++をつかってサーバーを作ったりしています。 もともとプログラムを書きたくて、でもいわゆるプログラマーという仕事に就いたところで、プログラムを書くことはできるけど、自分の望んだプログラムを書けるかというとそーでもない、という獏とした知識から今の会社をなんとなく選びました。 趣味では、ErlangやOCamlを使ってオモチャを作っています。最近PSPでタクティクス・オウガをずーっとやっています。 いちねんめ もともとはニートとか高等遊民になりたかったのですが、残念ながら庶民の家に産まれてしまったので、大学院を出る頃には親元を離れて自分でメシ食って暮らしていかなければなりませんでした。仕方がないので、（肉体的な意味で）なる
node.js vs Erlang (ネタ) - kuenishi's blog
ついぞ最近node.jsなんてのがでて、繁華街のあちこちでチヤホヤされてる。そんなときに、モヒカン族Erlang村(erlang-questions)に「node.jsってどうなの？」的燃料が投下されたわけですよ。これは炎上しそうだ…と追いかけてたら、ネタどころか案外真面目なハナシばっかりだったのですが。まずは真面目に問いかけをする純朴な成年（想像）。 「Erlang好きだし使ってるんだけど、Erlangとnode.jsてそれぞれどういうジャンルがすごいの？RabbitMQとかejabberdみたいなのつくろうとしたらどうなるの？簡単なチャットサーバーつくるくらうならnode.jsのが断然簡単だよね？分散システムで使うなら断然違うとか？ Ulf Wigerによると、ブロックする関数の問題を簡単に解決してくれるとか書いてあるみたいだけど (link)」 おっお。素直な質問。これはみんな釣られ
イノベーションできませんっ！！！ - kuenishi's blog
受託開発で顧客が要件を決められず、要求を聞き出せない受注側がスキルが足りず出来上がってしまったのはゼンゼンワケの分からないものだったが、誰も顧客が本当に必要だったものを知らなかった、という笑い話がある。ご存じない方は断固凱氏がまとめたものを参照いただきたい。世界中どこでもよくあるような話なのかもしれないが、ことプログラマーのビジネス的な価値が軽視される日本では笑い事ではない。 よいソフトウェアを作るためには、役割に応じて優秀な人材を集めればよい。ソフトウェアを使ったビジネスを考える人、ビジネスと仕様を考える人、仕様と設計を考える人、設計と実装を考える人、…こういうと役割分担できそうだが、役割分担されていてもチームワークは重要である。ところが、日本の労働慣習では、ビジネスが拡大したからといって、優秀で経験ある人間を社外から簡単に集めることはできない。大企業が終身雇用制によって優秀な人材を囲い
第四回 Erlang 分散システム勉強会で発表してきたよ - Tokyo Erlang Workshop #4 - kuenishi's blog
第四回 Erlang 分散システム勉強会の前説と本番に参加して、いろいろ勉強し、私もそこでYatceの話をしてきました。今回から幹事が id:cooldaemon になりましたが、すばらしい運営でした。幹事力は大切な社会人スキルだと思います（私にはとてもできない）。私がいろいろな話を聴けたり、公衆の面前で話をできたりするのも cooldaemonさんのおかげです。感謝感謝です。（写真は記事の内容とはほとんど関係ありません） 前説 「分散ストレージに使えるかもしれないアルゴリズム(たけまる)」この発表が一番分からなかった。資料が事前公開されたし、個人的に参考資料ももらっていたし、発表も駆け足なりに割と丁寧に説明されていたし、懇親会でもたけまるさんを捕まえて訊いたのだけど、あまり理解できていなくて、実装できる気がしない。あのDynamoの発表を押さえてSOSP'07の分散システムのセッションで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
