Corporate Reliability Engineering - 世界線航跡蔵
最近、SRE - Site Reliability EngineeringのアナロジーとしてCorporate Reliability Engineeringというのを考えられないかみたいな話を社内でしている。 SREは伝統的なシステム運用チームの仕事を再定義したものだ。SREはシステムの安定だけを至上目的にするのではなく、際限なく増え続ける運用タスクを真面目にこなすことを目的にするのではない。開発チームを巻き込んで適切なシステム安定度を見いだし、より少ない手間でシステムを安定運用するための開発を自ら行なう。運用のルーチンワークに費やす時間を全体の50%に抑えるように努力する。そして残り50%で今後もその配分を保つ為の開発や、更に上を目指すための仕組み作りを行なう。 同じ発想は業務システムや社内セキュリティ、更にはコーポレート部門にも適用できるのではないか。つまり、業務システムを運用して社
APIデザインケーススタディ —— Rubyライブラリを移植する前に読む本 - 世界線航跡蔵
『 APIデザインケーススタディ 』という本を頂戴したので読んでみた。 ライブラリ作者に向けて この本はRuby標準ライブラリを題材にして、分かりやすく、多様な機能をサポートして、互換性を保つAPIの設計をするにはどのように考えるべきかを教えてくれる。 ここでAPIと言っているのは、一般的なRubyのクラスとオブジェクトとメソッドから成るライブラリをどうデザインするか、という話である。 別にChef RecipeやRSpec DSLのようなちょっと変わったDSLを設計するとかそういう話ではない。確かにその種の言語内DSLのデザインには固有のセンスが必要とされるし、 Ruby DSL Handbook なんて本が書かれているように実装にあたってもある種のテクニックが必要なのも確かだ。でも、それ以外の「ふつう」のライブラリのデザインは果たして簡単だろうか。 適切な粒度のクラスを定義する。必要な
Automation Accountパターン - 世界線航跡蔵
コンテキスト あなたが開発しているサービスはユーザー向けにAPIを提供している。そして、APIを利用するにはユーザーは短寿命の認可情報(たとえばOAuth2トークン)を提示しなければならない。 ユーザーは認可情報が紐付いているアカウントの権限でリソースを読み取ったり、作成したり、所有したり、編集または削除したりする。 ここで、ユーザーは人間(が操作するユーザーエージェント)であることもあるが、人間の手を離れてバックグラウンドで自動実行されるプログラムかもしれない。 また、あなたは悪用目的でアカウントが大量登録されるのを防ぐためにCaptchaを利用したいと思っている。 さらに、課金目的で請求書送付先を登録させたいとも思っているかもしれない。 問題 プログラムが利用するアカウントを安全に管理するのがユーザーにとって困難である。 プログラムは自分でCaptchaを解いたりEメールを受け取るのが
gRPC-JSON proxy - 世界線航跡蔵
grpc-gateway という gRPC からJSON APIへの変換プロキシ生成機を書いた。 これを使えばシステム内部ののmicroservicesはgRPCで通信しつつ公開APIはJSON APIで提供する、みたいなことが簡単になる。 なお、gRPCそのものについては mattnさんの記事 が参考になる。 背景 gRPCの良い点はいくつもある。 データはデフォルトでprotocol buffersで直列化される。ベストではないにせよ十分にコンパクト且つ高速だし、サイズで言えばJSONとは比べるべくもない。 簡単に複数の言語でサーバーのテンプレートやクライアントを生成できる。通信の詳細はgRPCにまかせて開発者はサーバーロジックの実装に注力できる。 design by Googleという安心感。 gRPCの素晴らしさは認めるものの、一方では欠点もある。まず、クライアントライブラリの多く
言語処理100本ノックを敢えてRubyで (1) - 世界線航跡蔵
言語処理100本ノック を(飽きるまで)やってみるにあたり、敢えてRubyで書いてみる。 基本的にはPythonを想定しているらしいし、そもそもNLPライブラリの充実度から言ってもPythonを使うのが極めて妥当な選択といえるだろう。そこを敢えてRubyで。 00. 文字列の逆順 puts "stressed".reverse RubyでもPythonでも大差ない。 01. 「パタトクカシーー」 str = "パタトクカシーー" puts 1.step(7, 2).map{|i| str[i]}.join やはりスライスにstepを指定できるPythonのほうが楽である。 02. 「パトカー」＋「タクシー」＝「パタトクカシーー」 strs = %w[パトカー タクシー] puts strs.map(&:chars).inject(&:zip).flatten.join 別解 strs =
アンダースタンディング・コンピュテーション - 世界線航跡蔵
『 アンダースタンディング コンピュテーション ―単純な機械から不可能なプログラムまで 』を監訳者の笹田さんから頂戴したので、読んだ感想をまとめてみる。 この本はRubyを用いて計算理論を紹介しようというものだ。具体的には次のようなトピックを扱っている。 形式的意味論 操作的意味論 表示的意味論 オートマトンとチョムスキー階層 ラムダ計算 停止性問題と計算不能性 静的意味論と型システム サンプルが丁寧に書かれていて簡単に動作させられること。これが本書の強みだと言える。 正直なところ今までオートマトンはともかく形式的意味論は他の本を何度を読んでもいまいちピンと来なかったのだが、本書のサンプルプログラムを動かして初めて理解が進んだ気がする。 そもそも本文にも書かれているように、ミニ言語の形式的意味論をより強く(曖昧な)言語であるRubyで書いたところで理論的には意味は無い。 意味の定義がRub
libchanを読んだ - 世界線航跡蔵
libchan を読んだのでまとめてみる。 libchanとは libchanはdockerに使われているライブラリの1つで、先月の DockerCon で発表された。 非同期かつ一方向の通信チャネルをインプロセスでもネットワーク越しでも扱えるというGoライブラリである。 一方向とはいうものの、チャネル自体をデータに添えて他のチャネル越しに送れる。なので、返信や待ち合わせが必要ならば自分宛のチャネルを送って相手に使ってもらい、自分はそのチャネルの上で待機していれば良い。 早い話がGo言語の機能であるチャネルをネットワーク対応したようなものだ、と書いてある。 DockerはこのDockerConではDocker 1.0に加えてlibcontainer, libchan, libswarm, Docker Hubを発表していて一応キーノートの話題の１つではあったものの、 個人的にはlibswa
Rubyのメタクラス階層 - 世界線航跡蔵
この記事は、先日開催した 第3回 RHGの逆襲 のまとめみたいなものである。と、同時に『初めてのRuby(仮題)』の宣伝である。 クラス、その例外、そのトリック Rubyはクラスベースのオブジェクト指向だから、メソッドの情報はクラスに属している。インスタンスメソッドを呼び出すときには、そのオブジェクトの属するクラスを調べて、そのクラスの持っているインスタンスメソッドの中から探す。 でも、Rubyの場合は例外がある。1つはモジュール。モジュールはクラスではないのに、でもインスタンスメソッドを提供している。1つは特異メソッド。特異メソッドは特定のインスタンスに直接所属するメソッドだ。 でも、ここには実装上のトリックがある。Rubyにとってはモジュールのインスタンスメソッドも特異メソッドも、等しくクラスに属するインスタンスメソッドなんだな。 モジュール モジュールをクラスにincludeすると、
Ruby1.9 のクラスのメタ階層とかevil-rubyとか - 世界線航跡蔵
sumimさんの「 Ruby1.9のクラスのメタ階層を整理する 」という記事、Rubyの型階層は雑然としているというのは、なんかsumimさんの図が悪いような気もするなぁ。整理すればもうちょっと情報を引き出せるよ。あと、モジュールのせいもある。 前提知識 Rubyは基本的には単一継承のクラスベースオブジェクト指向言語なのだけれども、幾つか注意すべき処がある。 クラスはClassクラスのインスタンスである。 モジュール 制限付きの実装多重継承をもたらす仕組み。内部的には、モジュールの「化身」となるクラスを継承階層を挟み込むことで実装されている。 以下、モジュール M に対してその化身クラスを I(M) と表記する。 詳しくは 以前の記事 を参照。 特異クラス 特定のオブジェクトに専属するクラスのこと。特定のオブジェクトにだけ存在するメソッド「特異メソッド」を定義すると、内部的には特異クラスを
日本Rubyカンファレンス2006 (4) Matz基調講演 - 世界線航跡蔵
前の記事 に続いて日本Rubyカンファレンス2006をレポートする。 State of the Dominion Ruby作者のMatzことまつもとゆきひろさんによる基調講演。 タイトルはアメリカ合衆国「一般教書演説: State of the Union」のパロディである、Perlの" State of the Onion "のそのまたパロディだそうだ。wordsファイルを'nion$'でgrepしてそれらしい言葉を選んだという。 Matzは"State of the Onion"を「タマネギがどうした! って感じ」と言ってたけど、Larry Wallは「 努力、忍耐、謙遜 」でPerl界をタマネギに例えてるから、"State of the Onion"はそういう意味なんでないの? いや、みんなそれを分かってるのを前提としてのジョークなのか? Matzの思考を読むには私のハッカー度がまだ
Rails勉強会@東京 第7回 - 世界線航跡蔵
Rails勉強会@東京 第7回 に行ってきた。今回はドリコム恵比寿オフィスにて。 小雨の降る中、参加者がぞろぞろと集まってくる。残りの人を待っている間、話題になるのは 昨日のはぶにっき のこと。はぶさんから提示された「RailsのやりかたはDOAへの退化ではないか」という疑問と、いくつかの質問。そしてそれへのid:takahashimこと高橋会長のコメント。これは懇親会の話題にも続いた。 ドリコムのオフィスはビリヤード台が設置された素敵な感じ。 前半セッション 4つのセッションに分かれた。 DHHの講演の録音を聴く 「ARを詳しく」をあとで読む Railsのパフォーマンス問題の英語のテキストを読む AWDwRの付録Aを読む。 私は「Railsのパフォーマンス問題」に出た。ネタにしたのは A Look at Common Performance Problems in Rails 。よしみさ
理工書の買いかた - 世界線航跡蔵
「 がんばれ！アドミンくん - 情報砂漠 」は結構しゃれにならない。 私が本を買うときは、こんな感じの方針だ。 理論は重要 背景理論、技術が変わっても色褪せない基礎知識の本は吟味の上、理解するために必要なものを買う。 陳腐化しないので役に立つ 数学重要 技術者たるもの学会誌を購読したり、論文を取り寄せて読んだりしてナンボ。 といいつつAOPの研究とかに全然追い付けていない私 学生バイトは図書館で読めるので実は恵まれてる。私ゃ卒業したらそこらへんのお金がかさむようになった。 基礎も重要 基礎技術の本にはお金を惜しまない あまり陳腐化しないので資産になる あとで後輩の教育に使いまわせることも多々ある 歴史重要 古典的名著の類にはお金を惜しまない。Knuthの本とか。 ハッカーのジョークを理解し易くなるし。 なんとなく満足感があるし いくらか陳腐化してても、完全に陳腐化仕切ることはまれだし 使い
Rails勉強会@東京第6回 - 世界線航跡蔵
一週間ほど遅れたけれども、5月21日に Rails勉強会@東京第6回 に行ってきたのでレポートする。今回も会場は秋葉原で、30人弱が参加した。 連絡事項 会場の確保でいろいろ無理をしていて、これから先確実に確保できるとは限らないので、どこか他の場所を提供してくれる人を探しているそうです。完全に非営利なので公民館などの公共の施設を無料もしくは安く借りる手もあるのだけれども、問題はそういうところは予約が埋まっていて定期開催がとても難しいということだという。10人ずつ別室でも良いので毎月定期的に30人ほどの集まりができるような場所に、どなたか心当たりはありませんか? 日本Rubyカンファレンスで、ボランティアで音響機器の操作（発表者のマイク調整と、セッションの録音程度）をしてくれる人を急募するそうです。バンドやっているとか、ちょっとでも音響関係の経験のあるカンファレンススタッフを募集中です。 知
tracとquickMLの連携 - 世界線航跡蔵
qwikWeb は素晴らしい。エンドユーザーにもわかりやすくて良い。quickML部分の仕様は、実際の運用形態を考えたら、たいていの場合はこれで必要十分なんだよね。そして、qwikWebだ。wikiページとMLへのポストを一緒に扱えるのは良い。 で、ソフトウェア開発においては、tracでこういう機能を使えたらもっといいんじゃないかと思う。tracとメーリングリストの連携については MailArchiveプラグイン が秀逸だ。でも、これ自体にはメーリングリストの管理機能は無い。そこで、将来はquickML/qwikWebをtrac pluginにportすることを見据えつつ、まずはメーリングリスト機能にはquickMLを利用し、tracと連携させることにした。 まずはMailArchivePluginをインストール。mailarchive-admin.pyを/usr/local/binに配置
Rails, SOAP, WSDL, ActionWebService Rails勉強会＠東京第5回 @ 2006年04月 @ ratio - rational - irrational @ IDM
Rails勉強会＠東京第5回 に行ってきた。前回はプロジェクトが既に遅れ気味にて参加できなかったので2ヶ月ぶりとなる。 小雨の振る中、秋葉原駅前というか、雨を避けてダイビル前に寄ったあたりに集まった。怪しい集団が飲物片手に集まっているので、ダイビルの守衛さんに「敷地内飲食禁止だよ」と怒られる。でも、どこまで公道でどこから敷地なのか不明。 今回は勉強会・懇親会ともに参加者が過去最高ということである。大阪の勉強会の大規模さと本格さには及ばないけれど、東京も盛り上がってきた。 毎度おなじみ、前半・後半に分けてそれぞれオープンスペース形式を採った。 前半 3つのセッションに分かれた。 Rails 1.1の新機能 『たのしいRailsレシピ』（仮）打ち合わせ AWDwR chap.2を読む 私は、「『たのしいRailsレシピ』（仮）打ち合わせ」に出た。ソフトバンク・クリエイティブから出版予定のRai
ActionWebServiceを使ってみた - 世界線航跡蔵
Railsはweb serviceの開発でも開発効率いいよ。 ここ2日掛かって実装した代物と同等の物が3時間でできたよ。 でもやっぱり、実行速度はsoap4rでベタに実装したほうがずっといいよ 動的型言語で普通にSOAP実装しようとすると、型情報が不足しててWSDLを生成できないよ。 WSDLは自由度の半面、message, operation, port, binding, serviceとレイヤーが挟まってて冗長だから、書くのが大変だよ。 ActionWebServiceならお得意の所謂DSLっていうのを使って型情報を補足できるよ 生のWSDLより抽象度を落としてレイヤーを少なくしてる分、記述はDRYだよ でも、普通はこれで足りるよ。っていうか、あんまり変なWSDLを書くとクライアント側のマッパーが理解できないよ。 documentじゃなくてRPCスタイルっていう前提があるなら、これぐ
Rails勉強会 東京 第3回 2006年02月
Rails勉強会＠東京第3回 に行ってきた。 集合 寝過ごしてしまって、シャワーを浴びて慌てて出掛ける。秋葉原に着くと、駅前で「完全メイド宣言」たらいうよくわからないグループが歌って踊り始めた。それを眺めながら参加者が集まるのを待つ。今回は参加者がちょっと少なめ。 前回 までと同じくオープンセッション方式を採った。 前半 前半は3つのテーブルに分かれた。私は、「自分は経験が無いのだけれど、誰か詳しい人、Railsの国際化について教えてください」と言って国際化のセッションを開いた。 Railsのキャッシング Railsの国際化 Special Generator を読んでみよう 背景 さて、私がRailsの国際化なんて話題を取り出したのは、RoR日本語メーリングリストにちょっと前に流れた十河さんによる質問、 [rails:934] ロケールによるテンプレートの切り替え による。 私が今まで開
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
レポート書かないかも - 世界線航跡蔵