こんにちは、@key_amb です。ご無沙汰しています。 最近ブログの更新が遅れてまして、なんとなく申し訳ない気持ちになっている今日このごろです。 なんと、2ヶ月も更新してなかったんですね。*1 さて、前回の Gotanda.pm #5 では、テーマ(「高速化」でした)ガン無視の LT をしましたが、今回はちゃんと「障害」というテーマに沿って発表をしました。 障害を防ぎ、サービスを守るために #gotandapm from IKEDA Kiyoshi 時間がかなり余ったようで、もう少しネタを用意しておけばよかったなと思いました。 今回はこれまで仕事上、いろいろと障害やアラートの対応をやってきた中で、自分なりに大事だと思っている考え方をまとめてみました。 で、その中でどういうツールを使っているかなどの紹介をしました。 どちらかといえば概論的な話で、各論にはあまり踏み込んでいないのですが、何か

7/10(金) 吉祥寺.pm #4 で発表をしてきました。 お題が「PerlとPerl以外」ということだったので、PerlとPerl以外のWebアプリケーションのサーバサイド運用について話そうかなーと思い、発表枠で申し込みました。 …で、下のスライドで話をしました。 PerlとPerl以外の運用 #kichijojipm from IKEDA Kiyoshi 職場では、数年前まではサーバサイドの Web アプリケーションといえば Perl が主だったのですが、最近は Ruby を採用する案件も増えてきました。 本発表では Perl, Ruby の運用まわりでいくつかトピックを挙げ、それぞれどんなツール/ライブラリを使っているかなど紹介しました。 共通するものも、異なるものもありますが、紹介した切り口ではほぼ同等の要件を達成しています。 ツールは内製したものもあれば、OSS を利用したもの、

今日は1周年を迎えた Gotanda.pm #5 で Koyomi の LT をしてきました！ Koyomi は私が個人で開発している分散ジョブスケジューラです。 v0.1 をリリースした際に、下のエントリで紹介しました。 シンプルな分散ジョブスケジューラを作ってみた #appkoyomi - weblog of key_amb 本日の LT 資料はこちらです: Introduction to koyomi #appkoyomi from IKEDA Kiyoshi たごもりすさんのメソッド*1に倣って、スライドは英語にしてみました。 発表自体はもちろん(？)日本語で喋りましたよ。 内容としては、Koyomiのアーキテクチャの簡単な紹介といったところです。 短いスライドで、さくっと読めると思うので、よかったら見てみてください。 懇親会では「Koyomiが使えそうな案件がある」という方もいた

今年の YAPC::Asia Tokyo は 8月20〜22日に予定されています。 今年は最後の YAPC::Asia Tokyo ということで、トーク応募にも気合いの入ったエントリーが多いような気がします。 〆切は明日までとのことですが、これを書いている 6/14 現時点で 128個 のトーク応募があります。 ゆうべ、たまたま Twitter を見ていたところ、主催者のため息が聞こえてきました。 Seriously I have no clue how/if we can choose 40 or so talks out of 124 talks… and we still have almost 48 hrs till we stop accepting talks.— Daisuke Maki (anovaさん） (@lestrrat) 2015年6月13日 英語が苦手な方でもなん

6/2 に開催された Shibuya Perl Mongers テクニカルトーク #17 に参加してきました。 自分は初参加だったのですが、なんと前回開催から4年ぶりの開催とのこと。 「もうみんな Perl なんて書いてませんよね」というアイロニーな雰囲気が漂いつつも、「やっぱり Perl 書いてる」という人もたぶん 40% 以上ぐらいはいて、LT の盛り上がり具合から見てもみんな Perl が好きなんだなと感じるひとときでした。 以下、セッションの内容になります。 一部資料はネットにアップされているようです。 観測範囲で捕捉したものは、順次本記事にも追加していきます。 例によって愚直にメモを取っていたら、かなりの分量になってしまったのですが、あまり削ったりせずに、ほぼそのまま上げておきます。 開会の挨拶 @takesako さん 前回 - 正規表現祭り 2011/7月 shibuya.p

今週も秋葉原のクリエーションラインさんのオフィスにお邪魔してきました。*1 今回は「HashiCorp道場〜入門編〜」ということで、HashiCorp 製品ラインナップの Overview と各製品の機能概要、既存の同種のツールとの比較について講演がありました。 HashiCorp 製品はいろいろと記事を読んだりはしていたものの、Vagrant ぐらいしかまともに使ったことがありませんでした。 そんな私にとっては Vagrant も含めて各製品の情報をまとめて得られるという、とてもありがたいセミナーでした。 講師は @zembutsu さんでした。 発表資料は下のスライドです: HashiCode 01 - HashiCorp道と自動化ツール群 from Masahito Zembutsu 以下、講演内容のメモになります。 Tao of HashiCorp (HasihCorp道) ※今日

今夜は、Mackerel Meetup #4 Tokyo に行ってきました。 元々は 5/12 に開催予定でしたが、台風上陸のため延期となりました。 さて、DataDog など監視 SaaS の情報はときどき仕入れていたのですが、実際に使ったことはありませんでした。 ので、こういう Meetup で参考になる情報が得られるといいな、と思い参加しました。 発表ではビズリーチさんのユーザ事例を聞くことができ、懇親会でも何名かユーザの方とお話しができたので、有意義だったなと思います。 5/28、Mackerel のブログで発表資料が公開されました。 本稿でも資料のスライドは共有しますが、上記記事も参考にして頂けるとよいかと。 以下、発表内容のメモになります。 進化するMackerel：最新機能アップデートとロードマップの紹介 はてなCTO @stanaka さんより、最近の Mackerel の

5/20 クリエーションライン社で行われた「CHEF Business Meetup ~CHEF社Dicretor来日イベント~」に行ってきました。 内容は前半が ChefConf 2015(3/31-4/2開催)のレポート、後半が Chef Evangelist の Seth Thomas によるセッションでした。 以下、聴講のメモです。 ChefConf 2015 レポート クリエーションライン社顧問 鈴木さん 15分ぐらい遅刻して、前半部分を聞き損ねました。 こちらの資料は後ほど CL Lab に公開されるとのことでした。 Disney の事例 IT投資してる OSS 組合せて独自にシステム構築 独自 Cookbook 多数 独自 Supermarket 300 台の Hadoop 30 個の Cookbook 20 PB の Hadoop ストレージ BI Chef, Docker

これもだいぶ今更感ありますが、Mac の zsh に peco を入れて設定してみました。 peco について知らない人のために一応かんたんに説明すると、@lestrrat さんが元は Python の percol というツールだったものを Go 言語に移植したもの*1で、テキストをフィルタして、history などの検索を楽にしてくれるものです。 ネット上で話題になって、一部の技術者界隈で流行ったのはたぶん半年以上前で、そのときにも一瞬だけ触ったのだけど、そのときは使い込まずに終わりました。 …で、なくてもなんとかなるかなと思っていたのですが、最近「pecoないと死ぬ」と言っている人が周囲に3人ぐらいいたので、「そんなに便利なのか」と、そろそろもう1回トライしておくことにしました。 今では Qiita などに先人たちの .zshrc や .bashrc の設定がアップされているので、あ

なんとなく自分の中で暗黙知になっていることをまとめる。 職場での経験や、外部で見聞した情報がベースになってると思います。 今のご時世においては、一般ユーザとしてフリーソフトを使うようなケースでも、ある程度当てはまりそう。 前提 OSS なり、自前で開発・保守していない、外部のソフトウェアを利用する場合のこと 初回システム構築時でなく、運用フェーズの話 原則 必要なバージョンアップは実施する 不要なバージョンアップは見送る 旧バージョンと互換性のない変更や、仕様変更によって問題が生じることがあり得る ふつう、バージョン差異が大きいほどこのリスクが高まると言っていいだろう 保守が停止したソフトウェアは捨てるか、自前で保守していくか選択しなければならない バグ・セキュリティが修正されないため 脆弱性が問題になるリスクが低いケースもありそう 例えば内部ネットワーク内でしか利用しないソフトウェア ず

CONFIG GET ができないとかいう制約があるのは別として、最近ハマって、他の人もハマりかねないだろうと思うことを書いておきます。 Cache Cluster のスペックアップができない RDS のように作成した Cache Cluster のインスタンスタイプを変更することはできません。 AWSサポートに問い合わせても現時点ではできないという回答でした。 また、異なるインスタンスタイプのノードをレプリケーショングループに追加することもできないため、現時点でスペックアップしたい場合、新たな Cache Cluster を作成して手動でデータ移行と、アプリケーション側のエンドポイント切り替えを行う必要があります。 最近 Multi-AZ なクラスタ構成がサポートされたので、近い将来にはスペックアップ(インスタンスタイプ変更)もサポートされると期待したいものです。 Freeable Mem

昨日 2015/4/26 は統一地方選挙後半の投票日でした。 …ので、投票してきました。 港区の区議会議員の候補者は47人ほどいました。 選挙公報が公開されたのは 4/20 月曜でした。 平日は時間が作れず、土曜も所用があり、候補者の情報について調べ始めたのは、選挙当日の AM 1時ぐらいでした。 プリントアウトした選挙公報を片目に、2時間強ネットで情報収集しました。 さすがに全員分とは行かず、半分弱程度の候補者の情報しか調べられませんでしたが。。 わかったこと: インターネットでの情報発信の程度は候補者によってばらばらである。 自分自身の公式HPを持っている人は多い。 更に Twitter, Facebook 等活用している人もいれば、ネットで検索しても何の情報も得られないような人もいる。 ネット上で情報発信している人であっても、こちらが知りたい情報が手に入るかというと、そうでもない。

「GCP を検討しているエンジニアのための Compute Engine と AWS の比較」というイベントで、本郷三丁目にあるコワーキングスペースに行ってきました。 仕事などで AWS を使う機会はあったのですが、 GCP は触ったことがありませんでした。 一方で、GCP ではここ最近 Nearline Storage や Cloud Logging のリリースといったニュースもあり、本イベントは気になるテーマでした。 本イベントでは、発表が1つと、GCE でインスタンスを動かしてみるというハンズオンがありました。 イベントに関するツイートは下の togetter でまとめられています。 以下、イベントの内容のメモとなります。 GCPを検討しているエンジニアのための GCE と AWS の比較 ～どんな時に GCE を使うの？～ ハートビーツ @rrreeeyyy さんの発表 20分ぐら

Atom エディタ最近使い始めたのですが、以前に調べたときにやり方がわからなかったので、メモしておきます。 今は日本語の情報も少ないので、初心者はハマりそうな気がします。 動作環境としては MacOS X Marverics で、Atom 0.189.0 を使っています。 少し前に触った時から設定周りの UI がだいぶ変わったような気がします。 ここで、trailing space というのは行末の空白のことです。 多くのプログラム言語含む文書ファイルでは不要なものなので、デフォルトで自動削除なのはわからなくもないのですが、例えば Markdown だと trailing space で改行を表したりしますので、このデフォルト設定に戸惑う人もいると思います。 この trailing space の削除は core package に含まれる whitespace *1 の機能です。 このパ

JAWS-UG中央線第5回勉強会に行ってきました。 初めて JAWS-UG のイベントに参加しました。 けっこうカジュアルな感じでしたね。 個人的には Aerospike の話が面白かったです。 Aerospikeの話おもしろかったな。レプリカ作れて容易にスケールアウトできて高速なKVS普通に便利。けど最後の「DynamoDB使った方がいいと思います」で力が抜けてしまった(笑) #jawsug— きいあむ → @progrhyme (@key_amb) 2015年4月3日 色んな言語のクライアントライブラリあるみたいだし、オンプレだったらmemdの代わりとかで使えるんじゃないかなと思った。 #jawsug— きいあむ → @progrhyme (@key_amb) 2015年4月3日 キャッシュとしてならオンプレもクラウドもありだと思います RT @key_amb: 色んな言語のクライアン

(追記) タイトルを "【緩募】Markdownによる中規模ドキュメンテーションシステム" から変えました。 (更に追記) 後日談 => Hugo で "bootie-docs" というドキュメンテーション用のテーマを作った #Hugo - weblog of key_amb 下のような疑問を持ったのがきっかけで、Twitter でつぶやきつつ調べたりしていました。 結論としては下の方に書いてある通り、静的サイトジェネレータの Jekyll や MkDocs あたりを使うのがよさそうです。 最初、Sphinx が手堅いだろうと思いましたが、今や Sphinx でなければならない理由はないかな、と。 そこそこの規模のソフトウェアドキュメントをテキストベースで書くのに最適なツールなんですかね？ Sphinx はカタいのですが、できればMarkdownで管理したい。— きいあむ → @progr

私は以前から、ニュース・フィードの情報取得にRSSリーダーを愛用しています。 これまでのスタイルをまとめると、次のようでした: RSS リーダーが主 技術系ブログ + α CNET、毎日新聞など一般のニュースフィード Googleリーダーがサービス終了して以降、RSS リーダーとしては Feedly を使っていました。 なぜ RSS リーダーなのか？ 一時、スマートニュースの利用も考えたのですが、仕事柄ブログなど確実にチェックしておきたいニッチな情報ソースもあり、スマートニュース等の自動推薦型(と勝手に呼ぶことにする)のニュースアプリはそういう用途には向いてないようでした。 RSS リーダーの問題点 ですが、RSSリーダーは「未読があると読まないといけない気がする」という側面があります。 上述のニッチな情報だけであればそんなに更新頻度は高くないのでいいのですが、人として偏らないようにふだん