式年遷宮の様な感じですが、数年おきにブログを作り直してます(前回)。今回は Gatsby でデザインした UI をほぼそのままに、フレームワークを Astro に移行しました。静的サイトの作成では Astro の開発者体験が最高に優れているので、2 年間ほぼ塩漬けにしてしまっていた Gatsby のコードを無事に移行できてよかったです。 Astro とは？ Astro は 一言で言うと、Better HTML です。Astro というフォーマットでサイトが記述できるのですが、普通の(素の)HTML も Astro としてそのまま使えます。厳密には違いますが、HTML のスーパーセットみたいな感じです。その HTML の要素群を component としてまとめることで関心を分離できて(この辺は Web Components でも実現できます)、必要に応じてビルド時にロジックも走らせることが

7 年勤めた Amazon を辞めて、Autify という startup に Technical Support Engineer として入りました。場所は変わらず Vancouver, Canada のままです。これからは副業も何かやってみようと思っているので、お気軽にお声がけ下さい。 Today is my last day at Amazon. Lots of excitements and learnings in the past 7 years. Thank you for all of my customers and colleagues. I’ll start the next job soon and will update the status here. Stay tuned! pic.twitter.com/uqGv50jhvN — Ryosuke Iwanag

大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは？ 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体

ハッカーは遅延評価勉強法をするものだそうです。確かに僕の知ってるすごい人達は、皆必要になった時の吸収力が半端無くて、それを紹介した時には自分の方が詳しかったはずなのに、あっという間に追い抜かれてしまいます。 僕はハッカーになりたいけどハッカーじゃない人間ですが、やはり大上段から入って時間をかけて勉強していくのは嫌いなので、基本的には遅延評価勉強法をしてきました。でも言葉どおりに「必要になるまで」勉強しなかったら、得られないものが多すぎるなと最近感じてます。それは「普遍的な知識」です。 自分の仕事や興味だけに従っていると、訪れる機会は必然的に偏ります。たとえば web アプリの開発ばかりやっていれば、LL や HTTP や通信の知識は幅広く身につくかもしれませんが、スマホ開発や仮想環境やハードウェアなどはなかなか身につきません。必要にならないんだから勉強しなくていいんじゃない？というのはもち

1 年ちょっとサンフランシスコで生活してましたが、日本に帰任ということで 12 月末に日本に帰ります。SF でお世話になった方々ありがとうございました。今後も仲良くしてください。日本の方々、アメリカかぶれですがまたよろしくおねがいします。 英語について 英語が流暢になった、とはとても言えないですが、少なくとも行く前に持った「覚悟」に加えて「度胸」がつきました。文法めちゃくちゃだろうと発音がひどかろうと単語が聞き取れなかろうと語彙がなかろうと、伝えたい・聞きたいという思いを形にするだけの度胸は多少ついたと思います。そうしないと生活できないから。 仕事でもいわゆる日本とのブリッジみたいな仕事ではなく、こちらの会社の普通の 1 メンバーとして周りにも仕事相手にも全然日本人がいない環境で仕事ができたので、英語がわからないとか言ってられない感じでした。なんとかサバイブできてよかったです。だいぶ迷惑は

naoya さんのポータブルな Web アプリケーションを受けて最近思ってることをば。140 文字で時々書いてるんだけど、まとまりがないので一回まとめておきます。 12-factor app ステートフルなアプリケーションについては、Heroku の人が提唱してる 12-factor app というのが現在の状況をよく表してます。 The Twelve-Factor App The Twelve-Factor App（日本語訳） Heroku や他の PaaS によってもたらされたこうした一種の”制約”によって、アプリケーションの新しいカタチが生まれてきています。引き算によって新しい価値が生まれてきているわけですね。 とはいえ、PaaS は PaaS でそれぞれに独自の仕様を持っているわけですが、Heroku の buildpack という仕組みを使って、Heroku とインタフェース仕様

perl で色々管理スクリプト書いてるんですが、そのなかでこんなコードを書きました。 system("ssh remote 'rsync ...'"); で、rsyncが走ってる途中でやっぱやめたと思ってCtrl+C=SIGINTを送ったんですが、もちろん perl のプロセスは死ぬんですけど、remoteで動いてるrsyncはそのままゾンビになって残ってしまいました。 はて、いろんなところに原因が考えられるなぁということで調べてみました。 host1> ssh host2 'some-command' host2> strace -p 20279 # some-command's pid Process 20279 attached - interrupt to quit read(0, # then "Ctrl+C" on host1 (host2) "", 4096) = 0 wri

App::llenvというのを書いたり、Touryoというサーバの設定管理ツールを書いたりする中で、広義な「パッケージ管理」というものにすごい興味を持っているので、思うことを書いてみる。 **【追記】**タイトルが意味不明っていっぱい言われたのでえいやと変えてみた **【追記】**結論書き忘れてたので続きを書いた: 若者がパッケージ管理について思うことの今の結論 – As a Futurist… パッケージ管理って怖くてよく分からないとか思ってる人に少しでもパッケージ管理に親しんでもらえればと思って書いてる。かく言う僕も Perl の Catalyst や Plagger のインストールに泣いたり、rpm の依存ぶっ壊して戦々恐々としたりした経験があってここにいるわけなんですが、もうみんながそういう苦労するのあほらしいよなぁと思うので、パッケージ管理ってどういうところが勘所なのか知ってもら

先日エントリを書いたら、各方面から「長い」「タイトルが意味不明」「若いっていいよね」とたくさんの dis を頂きありがとうございました。 そういえば、長くなりすぎて今のところの自分の結論書くのも忘れてたので、頂いたアドバイスも交えてもうちょっと書きます。 結論：あるサーバの正しい状態が定義できれば管理方法は問わない というわけで、パッケージ管理と呼んでいるものの外側から、ともかく正しい状態というのを何かしら定義することができれば、別にパッケージ管理の手法は問わないし何種類も組み合わせていいと思ってます。Touryo という自作のツールはそういう思想も受け入れていて、一部そういう管理を試しているところです。 抽象的で分かりにくいのでもうちょっと具体化すると、例えば rpm でのライブラリのパッケージ管理と cpan による perl モジュールのパッケージ管理は、XS などがある場合に完全に

perl は system perl じゃなくて perlbrew で入れて、アプリで必要な CPAN モジュールは全てアプリのディレクトリ下の extlib というディレクトリにインストールする方式は個人的にはいい感じだよなぁと思いつつ、cron とか daemontools がいつもどうやるのが正解なのか分からず困ってた。 またセットアップする機会があったので色々考えた結果、こんな感じなら割とすっきりした感じになった。 env このファイルがキモで、アプリのディレクトリに移動しつつ、いい感じに perl とか PATH とか@INC を設定して、渡されたコマンドを実行してくれる。 # perl -v This is perl, v5.8.8 built for x86_64-linux-thread-multi # ./env perl -v This is perl 5, versi

このエントリはたぶんに煽り要素を含めていますが、意図的なものです。僕は NoSQL は素晴らしいと思います。 さて、NoSQL なんて言葉に踊らされてる人は置いといて、最近 RDBMS 以外のデータストアというのが色々でてきてます。今時点で見渡す限りにおいては、安定性、耐障害性、パフォーマンス、情報量、開発者の慣れ、全体のバランスで言えば RDBMS にかなうものはないわけですが、今後どうなっていくかはまぁ分かりません。 一方で、RDBMS がどうしても苦手とする分野というのは存在します。例えば 1 サーバに収まりきらない様な大容量データに対するバッチ処理、リアルタイムなランキング、アクティビティなどのフィード情報、そして構造化されたデータの取り扱い。何でもかんでも NoSQL に置き換えればいいなんて考えは現時点では到底受け入れがたいですが、例として挙げた様なピンポイントな部分ではそれに

CPAN とか全然分かってないし、実装力も全くないけど、miyagawa さんがいらっしゃるということだったので Carton Hackathon に参加してきました。ほんと座ってただけ。。。 日本(世界)トップの Perl Mongers 達が交わすモジュールに関する会話は、聞いてるだけでホントに意味が分からない、じゃなくて勉強になることばかりでした。Hackathon という場に居合わせて、モノがどうやって生まれてくるのかを目の当たりにできて、いつも運用ばっかりやってる僕にとってはとても新鮮で刺激的でした。 その後の懇親会はいつもの通りで、笑いの絶えない楽しいものでした。とってもとっても楽しかったです。 せっかく参加させてもらったので何か貢献できないか、ということで一応取り組んだのがcarton list --treeの表示をもうちょっとかっこよくしようということでした。node.js

“the missing log collector”ということで昨今話題の fluentd ですが、日本での使用事例も増えてきたこともあり大規模なセミナーが開かれたので参加してきました。 Fluentd meetup in Japan on Zusaar 内容はとても充実していて、作者の古橋さんによる fluentd の概要から始まり、plugin の書き方、実例と続いていて 1 日で fluentd に詳しくなれるすばらしいイベントだったと思います。古橋さんのセッションで今までよくわかってなかった buffer plugin もイメージが持てましたし、@repeatedly さんのプラグイン作りの指南書のおかげで何を作れば自分のやりたいことができるのかが分かってきました。cookpad と NHN*2 の実例は非常に聴き応えのある内容だったので、もう一度資料見返しておこうと思います。

2009 年に初めてデブサミに参加してから、講演できるようになりたいなぁとずっと思ってたところ、@t_wada さんからお声が掛かり幸運にも講演の機会を頂きました。ありがとうございます！ デブサミ 2012「攻めの運用の極意」のつぶやき – Togetter セッション自体は、最初の 20 分経過予定のスライドに来たところで 10 分しか経ってなかったのでちょっと焦りましたが、次のセクションを詳細にしゃべることができて無事 10 分を取り戻すことができて良かったです。 本当に、これはあくまで一例で他にも言いたいことはたくさんあります。興味ある人は飲みましょう！ すごい疲れた。。。爆睡する。。。

丁度週末やることないなーと思ってたら、@karupanerura さんに誘われて 1 泊 2 日で群馬水上までいってハッカソンしてきました！僕は丁度この数日でやってた llenv のリニューアル作業をしてきました。最後に発表した資料はこちらです。 App::llenv 2012/01 発火村 from Ryosuke IWANAGA App::llenv とは？ 年末に思いついて一気に shell script だけで書き上げた記事がこちらです。 LL をお手軽に使う llenv というのを作りました – As a Futurist… まぁやりたいことの大体は実現できたんですが、細かい修正も大幅な修正も shell script は柔軟性がないのでやりづらいなぁと思って、perlbrew の様に perl で書いて App::FatPacker を使って必要な CPAN モジュールを 1

モダンな感じで perl でウェブアプリ作りたいなーと思ってほげほげしてます。メモ書き。 最近の流行りでは、system perl なんてもう使わないわけで、自分で perl を make して入れるもの。それを簡単に管理できるのがperlbrew。で、アプリ毎に perl を入れてもいいなぁとは思ったんですが、さすがにそこまで仰々しくしたくはない。でも、CPAN モジュールについてはアプリ毎に依存が無いようにしたい(あるアプリが変にバージョンアップしちゃって他が動かないとか嫌)。 どうするのがいいかなーと色々考えたんですが、そういえば miyagawa さんのCartonというのが、依存関係やバージョンも含めて CPAN モジュール管理できるということでこれをアプリ毎に使うのが正統だろうなと思ったので使ってみた。 まずは perlbrew でインストール これは説明の通り。 $ curl

perlbrew+carton とかとっても便利なんですが、例えばそれで作った CLI ツールとかにパスだけ通しても、carton execするためにcdしなきゃだったりなんだかんだめんどくさいなーと思って、ライブラリのパスを環境変数で渡して、実行する perl をフルパスで指定してあげる感じにしたらいいかもと思いました。 よく考えると ruby でもおんなじ感じでできるなーと思って、じゃあ python とか node.js もいんじゃね？ということで色々それぞれの言語の使い方調べて、ある程度統一的に使える様にしてみたのでひとまず公開しました。 riywo/llenv – GitHub 使い方 例えば、今使ってる perl の site_perl には何も入れたくないけど、ikachan を使いたいとします。まず ikachan 用のディレクトリを作ります。 $ llenv setup

しわっす！DBA 兼オペレーションエンジニア兼タスクマネージャやってる riywo です。何のネタを書こうかなぁと考えたのですが、正直ネタを仕込む時間もなかったので僕がいつもやってることをさらっと紹介するということで勘弁して下さい＞＜ MySQL がおかしい！ 03:14 hidek: なんかエラー出まくってるんだけど！ 03:14 zigorou: MySQL と通信してるとこっぽい 03:15 riywo: 見ます こんなやりとりは皆さん日常茶飯事ですよね？ね？ね？こんな時に、DB に責任を持つものとして真っ先に対応するのが僕らの仕事です。でも、じゃあ具体的にこのあと何をしましょう？既にサービスはエラーだらけで一刻を争う状態です。 (対応開始) まずはエラーメッセージ 今回の様な場合はアプリのエラーログにどばっと MySQL に関するエラーが出ているでしょう。まずはそれを見ることが始ま

くたびれました。。。丁度 1 年前、初めて YAPC::Asia に参加したときから発表したいなーと思っていたのですが、Perl の話じゃないにも関わらず幸運にも発表の機会を頂くことができました。運営の方々、スポンサーの方々、スピーカーの方々、参加者の方々、皆さん本当にありがとうございました。 追記:10/21 スライド公開しました YAPC::Asia2011 “Large Scale Server Operations in Mobage’s Social Games with Perl” riywo 日常溜まっているリビドーを吐き出すかのごとく、プレゼンでは言いたい放題やりましたし、懇親会では色々な方々と熱いお話ができました。こういう場に参加できることがすごい幸せだし、ペーペーな自分とお話してくれたり、絡んでくれる人がこんなにもいて本当に楽しかったです。 発表自体は自分が今やっている

すてきな女性とめぐり合うことができ、この度結婚致しました。挙式、披露宴、二次会にとたくさんの方に来て頂き、本当にありがとうございました。 この 1 年くらいは挨拶や準備などに忙しく、特に仕事の仲間には色々と助けて頂き大変ありがたく思っています。また、部活の友人達には惜しみない協力をして頂き、本当にかけがえのない一生の仲間だと確信しました。ありがとうございます。僕にはもったいないくらいの人ですが、これから二人の人生をもっともっと楽しいものにできるよう精一杯努力していきます。 僕にとってこの数年は色々な意味でまさに人生のターニングポイントでした。数年前、僕はずっと「死にたい死にたい」と言っていました。結局勇気はなくて死にませんでしたが、丁度その頃彼女と出会いました。その前後で親族や大切な友人の不幸を目にしてきました。生まれて初めて仕事を得ました。そして、プロポーズをしてから親族や友人など色んな