ちょっと最近腹に据えかねる記事がネットで散見されるので敢えてアレなタイトルで、よろしくおねがいします。 なおこの記事は、自分はソフトウェアエンジニアリングの専門家であるので、そのような領域を大雑把に想定して書かれております。が、たぶん他の専門領域においても似たような状況なのではないかと推察しております。 専門用語ばかり使って会話するような人は本当のプロではない という言説を最近ちょくちょく見ますね。曰く、普通の人に説明できないようではダメだ。曰く、普通の人でも重要性が理解できないように話せないということは、実際にはお前のやっていることは重要ではないのだ。曰く、専門用語ばかりで会話するようでは実際の能力はわからない、専門用語などわからなくても本当に能力がある人にはあるのだ。 んなわけねーだろ。 専門家というのは、非専門家には扱えない問題を扱う専門家だから専門家として働けていて、それなりの待遇

最近 Fluentd の通信プロトコルまわりをアップデートするためにあれこれいじっている*1んだけど、これはおおむね fluent-plugin-secure-forward がサポートしていた内容を Fluentd 組込みの forward plugin でもサポートしますよ、というものになる。 んで問題なのが secure-forward は SSL/TLS での接続のみしかサポートしてなかったんだけど forward では生の TCP で通信する*2ので、本当に secure-forward と forward それぞれの実装間で互換性が保たれているのか、直接的には確認する手段がない、ということになってしまう。 TCP server の SSL/TLS 化 一方世の中には SSL/TLS ターミネータという機能があって、たとえばロードバランサなんかがこの機能を持っている。何をやるかと

以前に書いた話の続きなんだけど、Docker 1.8が出た。 blog.docker.com で、それに Fluentd logging driver が入っている。これで Docker container で起動したプロセスのSTDOUTやSTDERRを直接Fluentdに向けて投げることが可能になった。Dockerにpull-reqを送ったのは初めてだったんだけど、無事マージされてリリースまでこぎつけたので、本当に出たときはほっとした。途中だいぶ大変だったので……。 Collecting All Docker Logs with Fluentd | Treasure Data Blog 5 Use Cases Enabled by Docker 1.8’s Fluentd Logging Driver | Treasure Data Blog Treasure Data blogで既に

継続的にあれこれアップデートを続けてきているOSSプロダクト Norikra ですが、このたびあれこれ機能を追加したバージョン v1.3.0 をリリースしました。 tagomoris in English — Norikra v1.3.0, more flexible stream processing v1.0.0を出してからあまり個別のアップデートについてエントリを書いていませんでしたが、1.3.0での変更も含めてあれこれ機能および使い勝手が向上していると思います。 Listener pluginの追加*1 クエリのサスペンドとレジューム NULLABLE(field) 指定の追加、フィールドが存在しない場合も強制的にNULLとして扱えるように HUPシグナルによる新規にインストールされたプラグインのリロード*2 Esper 5.2.0 のバンドル そのほかpull requestをい

HiveやPrestoにWebブラウザからクエリを簡単に投げられるツールとして、shibというプロダクトを作っています。 tagomoris/shib · GitHub こちら、特に機能は増えていないのですが、内部的にあれこれ整理をしまして、最近 v1 としてリリース*1しました。 最近ある環境で特にクエリの総実行数が増えてきたりクエリの同時実行数が増えたりしたときに不安定になる問題があったため、そのあたりを直したりしております。 ただしこれに伴い内部用データベース(SQLite)のスキーマを変更しました。よって、旧バージョン v0 系を利用していた方は、v1への移行に伴いマイグレーション作業が必要となります。以下のページあたりに書いてありますので参考にしてください。 https://github.com/tagomoris/shib#migrate-metadata-database-f

著者の宮下さんから送っていただきました*1。ありがとうございます。 o'reillyに電子版もありますね。 送っていただいてからちょっと私事でばたばたしていたら大量にレビューが書かれているので、どう紹介したものかと思っているうちに更に日が経ってしまった。 他の多くの人が書いている「まさにServerspec作者にしか書けない内容だから必見」というのは同意する部分しかないんだが、自分が同じこと書いてもなあ。 ということで、ちょっと視点を変えて「なぜServerspecが必要なのか」について書こうと思う。……と思ってここまで書いたんだが、このServerspec本にも書いてあったしもう一度確認しよう、と思って読み直してみたところ、自分の考えていたことが全部書いてあった。 1.4 Serverspecの必要性 (p8) Serverspecって本当に必要なの？ という意見もよくTwitter等で

「Webエンジニアが知っておきたいインフラの基本」を著者の馬場さんから献本いただきました*1。ありがとうございます。 ITインフラの設計やら構築やら運用やらに関わりながら仕事をするようになってそれなりの年数になった。日頃おろそかにしている部分もあれば専門だと思って自信をもってやれることもある。その中でたまに思うのは、何が当たり前で何は当たり前ではないのか、ということがよくわからなくなってきたなあ、ということだ。 障害対応時の心構えは？ そもそもシステムメンテナンスにおける心構えとは？ Webアプリケーション基盤の設計方法は？ 非機能要件にはどのようなものがあるか？ パフォーマンスとは何を指すのか？ どんなサーバにも入っているツールで調べものをするときの鉄板は？ サーバのパフォーマンスを示すグラフの見方は？ どのような兆候が出ていたら注意しなければならないのか？ どの数字にどういった意味があ

Fluentd Casual Talks #2 で聞いた fluentd + esper によるCEP実現の話が非常に素敵な感じで、自分の手元でもああいう感じで書きやすく投入しやすいストリームクエリがやりたくてしょうがないお年頃なので、以下のようなものを作ろうかと考えている。勢いあまって(まだ1バイトも書いてないのに) the RubyKaigi 2013 のCFPにsubmitしてしまった。通ったら何がなんでも2ヶ月くらいで書いて動かさないといけない。 ということで以下のようなものを作ろうかと考えている。この内容は Fluentd Casual Talks #2 の懇親会でFluentdコミッタ陣と @angostura11 さんとで頭をつきあわせてゴニョゴニョ話していた内容で、100%自分で考えたものでないことは最初に記しておく。だいたいそもそものアイデアは @angostura11

毎回あれー？ってなってドキュメント読んだりググったりするんだけどうまく見付けられないので書いておく。 Ansibleはデフォルトだとtaskの実行が全ホストで失敗しない限り続く。言いかえると、あるタスクがあるホストで失敗したらそのホストについては以降実行されないが、成功した他のホストについてはplaybookの実行は継続される。 これは特に分散ストレージのセットアップなどにおいて、大変よくない。 よくないので1台でもtaskの実行に失敗した時点で止めたいというタスクには以下のように書いておく。 - hosts: ippai max_fail_percentage: 0 tasks: - name: .... failしているホストのパーセンテージが max_fail_percentage を「超えた」場合にplaybookが停止するので、1台でも fail したら即座に止めたい場合は 0

RAIDアレイをなんらかの指標をもとに設計するとき、容量、性能および安全性と価格が最初に来るのはともかくとして、それに付随する重要な要素としてディスクがfailしたときのリビルドの所要時間およびリビルド中のパフォーマンス低下具合についても注意は必要だ。ほぼ切れ目なく高負荷がかかり続けるような用途ならそれを前提としてパフォーマンスの最低ライン(つまりRAIDアレイのリビルド中のスループット)をそこに合わせる必要があるし、日中のみ高負荷がかかるが夜間はほとんどI/Oが発生しないような用途であれば、夜間帯のうちにリビルドが終わることがわかっていればリビルド中のパフォーマンス低下が大きくても許容できる。用途を考え、数値を計測することがなによりもはじまりとなる。 リビルド中のパフォーマンスを正確に見積もるのは難しい。ストレージの性能特性は様々な要因によって左右される。read/writeの比率の想定

先日書いたエントリでも触れたけど、日本OSS奨励賞、というものをいただくことになりました。ご推薦いただいた方がいるということで、本当にありがとうございます。 「第9回 日本OSS貢献者賞・日本OSS奨励賞」受賞者を選定 | 日本OSS推進フォーラム で、せっかくの機会だし、普段思っていることを書いておこうと思う。この内容はほとんど将来の自分に対する自戒だ。アレな内容になることを申し上げておきます。先日に引き続いてアレですが、まあせっかくの機会なんですよ。ねえ。 ちなみに、ちょー長くなりました。あっはっは。 業務としてのオープンソース活動 自分はフルタイムのオープンソースコミッタではない。オープンソース活動に貢献すること、などという文言は自分の業務内容にはひと言も含まれていないし、自分が所属する部署の目標にも無い。自分の業務はあくまで自社サービスに貢献すること、自社サービスの開発および運用を

今からちょうど4年前の2010年2月、某巨大SIerの片隅でExcelやPowerPointばかりを眺めて過ごしていた頃、おれは仕事でも仕事以外でもコードなんかまったく書いていなかったし、GitHubのアカウントも持ってなかった。毎日見積書とWBSと納品書と請求書と、Excel方眼紙の詳細設計書と格闘してた。 当時おれは30歳だった。一度はプログラマとして生きるのは自分には無理だと思って入社したSIerで数年やってて、そこそこ成功した数年を送っているとは思っていたけど、でもやっぱり、そんな毎日に飽きていた。 技術力を重視とか言いながらプロパー社員にコードを書かせようとしない会社の方針にも、svnもgitも閉じられててガチガチに監視されたネットワークに繋がせておいてオープンソースがどうのと言う文化にも、手順や履歴を重視とか言いながらロクにバージョン管理システムを使おうとしない一部の同僚にも、

登壇の機会をいただけたので、普段技術的なトピックが中心にあるカンファレンスとは違うことだし、普段あまりやらない話をしよう、ということで、そんな話をしてきました。 社内システムの構造と設計、実装のはなし from SATOSHI TAGOMORI 今回はスライドにはトピックだけ出して、あとは壇上でべらべらしゃべる、というスタイルをとったため、このスライドだけではちょっと意味がわからないところが多いだろうなあ、という気がします*1。 と思っていたら id:rx7 さんが内容をすごく丁寧にメモっておいてくださってました。こちらをどうぞ。ありがとうございます。 デブサミ2014「社内システムの構造と設計、実装のはなし」講演メモ #devsumi - 元RX-7乗りの適当な日々 自分でも内容をまとめてみようかと思いましたが、なんか散漫になるなあ、ということでいったん書いたけど削除 ＞＜ rx7さんの

グラフツールをひとつ作り、ひととおり動くらしいところまでいったので、とりあえず v0.1.0 としました。Focuslight と名付けています。 https://github.com/tagomoris/focuslight これは何かというと、このblogでも何度も紹介している GrowthForecast のRuby移植版です。同じ機能というだけでなく、内部データの互換性がありますし、HTTP APIの互換性も可能な限り保っています。ビューまわりは丸パクりしてます。 既に日本国内ではGrowthForecastは割と知られているだろう、という前提で説明をすると、これは「GrowthForecastの話は聞くが、でもPerlのツールはなー、ちょっとなー」というわがままさんのために作られたものであり、それ以上でもそれ以下でもありません。自分はおそらく今後もGrowthForecastを使

直接成果が外に出ない僕らの仕事は大抵、最初は空模様が怪しい。いまいち見通しが悪くテンションも上がらない曇り空が続いたあと、努力が報われれば、ありがたくもそのうちに晴れ間が見えるようになる。たまにとんでもない快晴にめぐりあえることもある。 でも途中で目的地を見失ったり、脚が萎えてその場にくずれおちたりすると、天候はあっという間に変わる。動けないうちに嵐がやってくる。 その嵐には僕の中では、コストセンターというラベルが貼ってある。 http://www.picgifs.com/wallpapers/storm/wallpaper_storm_animaatjes-9-970507/ あまり好きな表現ではないが、コストセンターという言葉がある。この言葉の定義自体いろいろあるらしいというか、明確には定義があるようだというのはこのあたりを読むとふむふむという感じ。 だが、おそらく多くの人の頭には「コ