質の高い技術文書を書く方法 - As a Futurist...
大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは？ 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体
DeNAを退職してAWSにJoinしました - As a Futurist...
タイトルの通りですが、12 月末で 6 年弱勤めた DeNA を退職して、1 月から AWS に Join してます。日本の Solution Architect です。初めての B2B のお仕事なので新卒新入社員の気持ちです。新卒入社時の予定ではもうアメリカに留学してるはずだったのに、どうしてこうなったのやら。。。 さて、DeNA にはエンジニア未経験の状態からここまで力を付けさせてもらって大変感謝しています。売上に直接貢献するような仕事はほとんどできなかったですが、起こらなかった問題に対する貢献は少しは出来たかなと思っています。そういえばここではちゃんと書いてなかったですが、最後の１年間は MYCODE という遺伝子解析サービスの開発をゼロから行っていて、何もないところからリリースまで辿り着くという産みの苦しみを味わうことができて非常にエキサイティングでした。ちょっとだけですが Sec
MyrokuというHerokuっぽいものを実装してみた - As a Futurist...
あけましておめでとうございます。SF アドベントカレンダーも書けず、2012 年のまとめとかも書けず、まぁ何をしてたかというと生きるのに精一杯だったんですが、あともう一個やってたのがアプリ書くってことでした。前から、自前で簡単につかえる Heroku っぽい PaaS があるといいなぁと思ってたのですが、やっと動くものができましたので公開します。”My Heroku”で Myroku。 riywo/myroku-cookbooks · GitHub riywo/myroku-server · GitHub どういうもの？ 基本の挙動は超シンプルです。Heroku っぽい感じ。 好きな名前のアプリを作成する(sample-app) .llenvに使いたい LL のバージョンを書く(node-0.9.3) Procfileに起動するプロセス書く(web: node app.js) 一番最初に
かっこいいスライドの作り方 #yapcasia 2012編 - As a Futurist...
さて、今回スライド結構がんばって作ってみました。どうよ、これかっこ良くない？？？ https://speakerdeck.com/riywo/ops-tool-made-by-perl-beginner-number-yapcasia-2012 どうやって作ったのか、大したことはないんですが軽く共有しておきます。 と言っても、ぶっちゃけ以下のエントリを丸パクリして Keynote でポチポチ作っただけですが。。。 Slide Design for Developers フォント Yanone – Free Font: Yanone Kaffeesatz こちらを使わせて頂きました。とてもかっこいいです。 配色 Color Trends + Palettes :: COLOURlovers こちらから自分の好みのパターンを幾つか探して、Keynote のパレットに拾っておいてあとはそれをポチ
Perlでssh tail -fして目的の行が来たら終了する - As a Futurist...
簡単だろうと思って始めてみたら意外とハマった。。。例えばネットワーク機器の設定確認とかで、ロードバランサ経由でアクセスしてみてちゃんとアクセスが来てるか確認したい時に、人力だったらターミナル開いてアクセスログをtail -fしといてcurlとかで叩いて「きたきた」ってやって終わりでいいと思うんですが、台数がべらぼうに多いときとかムリポ。 そこで、サーバにsshしつつtail -fを発行してアクセスログをフェッチしつつ、grep的なことをして目的のログが来たら終了、みたいな処理を考えてみた。方針はたぶんこの 2 種類。 sshで渡すコマンドでgrepして目的の行が出たらsshが終了するようにしておく 目的の行は perl で探して、見つけたらsshのプロセスにシグナルを送る なんでこんなめんどくさいことが必要かというと、tail -fは明示的に殺すまで基本的にはずっと動き続けるので、なんらか
「リーダブルコード」が良書すぎて胃が痛い - As a Futurist...
インフラ系のエンジニアは、あまりリファクタリングとかクラス構造といった視点でコードを読む機会が少なくて、勢い作ったスクリプトやツールはそれはそれはひどいものになりがちです(体験談)。 僕もエンジニアになって以来、まともなコードなんか書いたことなくて、従ってる原則といえば、「グローバル変数は悪」とか「短いことはいいことだ」とか「コメントは書かない方がいい」とか、なんか学生の時にたまたま目にしたよくわからない何かに従ってる程度。 少し大きい規模を書き始めると、昨日の自分と今日の自分で命名規則が全然一貫性なくて、「getHoge()」と「makeFuga()」がおんなじようなことをやってたりしていつも嫌悪感に駆られてました。 ちょうど 1000 行くらいのアプリ書いてたところだったので毎日吐き気をこらえながら「まずは動くものをつくるんだ。全てはそれからだ」と言い聞かせて汚いコードをゲロゲロしてた
netstat | grep が遅いなぁと思ったときにはgrep -m - As a Futurist...
サーバ間の通信を調査したいときに、netstatはよく使うと思います。たとえば、あるポートを使ってるプロセスを探したい時。 # netstat -taopn | grep :29324 tcp 0 0 192.168.11.11:29324 192.168.11.12:3306 ESTABLISHED 10726/perl off (0.00/0/0) ただ、すごいたくさん通信してるサーバだと、netstat自身がすごい遅くて、上記コマンドが終了するのに時間がかかります。手で見てる時はまぁどうでもいいんですが、自動化したい時とかにずっと待ってると微妙ですよね。 見つけたいのは 1 行だけだなぁと思ったので| head -1とかしてみたんですがあんまうまくいってない。 # time netstat -taopn | grep :29324 | head -1 tcp 0 0 192.168.
perlbrewとextlibなアプリのcronとかdaemontools - As a Futurist...
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
NHNテクノロジーカンファレンスでしゃべって来た #nhntech - As a Futurist...
前日に Fluentd Casual Talks を会社で開催してぐったりしたまま、NHN さん主催のテクノロジーカンファレンスで 25 分の発表をしてきました。講演者の中で 1 人だけ一般人感が滲み出ていて大変恐縮でした。 “Mobage DBA Fight against Big Data” - NHN TE from Ryosuke IWANAGA 動画もあります 感想 実は MySQL の話をこれだけちゃんとしゃべるのは内にも外にも初めてでした。雑誌の記事とかで数ページとかはありましたが、外向けにしゃべる時は運用周りの事ばっかりでしたね、実は。 自分が join する前からあった技術、入ってから使った・作った技術をおりまぜて、といいつつ別に弊社独自のものはほとんどなくてごくごく一般的な知識を紹介しているので、MySQL の大規模運用については割と網羅的にまとめて紹介できたかなぁと思
English Casualがすごい良かった - As a Futurist...
真っ黒クロスケで有名な oranie さん主催で「英語でプレゼンする経験をしてみよう！」というコンセプトの元、英語苦手な人達で集まって「資料・発表・質問は英語縛り」というレギュレーションで English Casual をやってみようという話になりました。僕は会場提供係ということで無事ヒカリエの会議室を使って開催することができました。 僕の発表資料はこちらになります。発表の内容は問わず、ともかく英語でやってみるというのが趣旨なので、内容は超適当ですすみません＞＜ English Casual 2012/05/10 やってみた感想としては、思った以上に良かったですね。やっぱりとにかく経験値が足りないわけで、場数を踏むのは大事。ただ、普通の英会話とか行っても、なかなか技術の内容について話す機会は無いわけで、こういう機会はすごい大事だなぁと思いました。英語の上手い下手とか関係なくて、伝わることが
スキーマレスについてちょっと考えてみた - As a Futurist...
このエントリはたぶんに煽り要素を含めていますが、意図的なものです。僕は NoSQL は素晴らしいと思います。 さて、NoSQL なんて言葉に踊らされてる人は置いといて、最近 RDBMS 以外のデータストアというのが色々でてきてます。今時点で見渡す限りにおいては、安定性、耐障害性、パフォーマンス、情報量、開発者の慣れ、全体のバランスで言えば RDBMS にかなうものはないわけですが、今後どうなっていくかはまぁ分かりません。 一方で、RDBMS がどうしても苦手とする分野というのは存在します。例えば 1 サーバに収まりきらない様な大容量データに対するバッチ処理、リアルタイムなランキング、アクティビティなどのフィード情報、そして構造化されたデータの取り扱い。何でもかんでも NoSQL に置き換えればいいなんて考えは現時点では到底受け入れがたいですが、例として挙げた様なピンポイントな部分ではそれに
Carton Hackathonに参加だけしてきた - As a Futurist...
CPAN とか全然分かってないし、実装力も全くないけど、miyagawa さんがいらっしゃるということだったので Carton Hackathon に参加してきました。ほんと座ってただけ。。。 日本(世界)トップの Perl Mongers 達が交わすモジュールに関する会話は、聞いてるだけでホントに意味が分からない、じゃなくて勉強になることばかりでした。Hackathon という場に居合わせて、モノがどうやって生まれてくるのかを目の当たりにできて、いつも運用ばっかりやってる僕にとってはとても新鮮で刺激的でした。 その後の懇親会はいつもの通りで、笑いの絶えない楽しいものでした。とってもとっても楽しかったです。 せっかく参加させてもらったので何か貢献できないか、ということで一応取り組んだのがcarton list --treeの表示をもうちょっとかっこよくしようということでした。node.js
「Inventing on Principle」見た感想を英語で書いた＆「パフォーマンス・マネジメント」のススメ - As a Futurist...
「Inventing on Principle」という動画がすごいというのが紹介されていて、クソみたいな英語力だけど頑張って見てみたら、すごかった。 monkey coders’ – エンジニアが信条によって生きるということ せっかくなので感想とかを頑張って英語で書いて、それから日本語もと思ったけどもう疲れきってしまったのでリンク貼るだけにします。。。 riywo weblog – Watched “Inventing on Principle” で、そのエントリの中でも紹介してるのですが、同僚のオススメを見て最近読んだ本ですばらしいものがあったのでご紹介。「パフォーマンス・マネジメント―問題解決のための行動分析学」という本。 すごい薄い本で、しかもありがちな問題に対して対話形式で書かれていて、ついでにクイズまで付いてるので、あっという間に読み切れます。なのに、得られる内容が濃い。すごい濃
若者がパッケージ管理について思うこと - As a Futurist...
App::llenvというのを書いたり、Touryoというサーバの設定管理ツールを書いたりする中で、広義な「パッケージ管理」というものにすごい興味を持っているので、思うことを書いてみる。 **【追記】**タイトルが意味不明っていっぱい言われたのでえいやと変えてみた **【追記】**結論書き忘れてたので続きを書いた: 若者がパッケージ管理について思うことの今の結論 – As a Futurist… パッケージ管理って怖くてよく分からないとか思ってる人に少しでもパッケージ管理に親しんでもらえればと思って書いてる。かく言う僕も Perl の Catalyst や Plagger のインストールに泣いたり、rpm の依存ぶっ壊して戦々恐々としたりした経験があってここにいるわけなんですが、もうみんながそういう苦労するのあほらしいよなぁと思うので、パッケージ管理ってどういうところが勘所なのか知ってもら
td-agentのレポジトリが公開されたのでちょっとカスタマイズしてみた #fluentd - As a Futurist...
最近のマイブームはfluentdなんですが、やっぱりrubyとかまでマジメにセットアップしようとするとどうしてもハードルが高いですよね。特にアプリサーバ側に入れる場合、数も多いですしなるべく簡単にインストールしたいものです。 fluent-agent-lite じゃ物足りない方へ td-agent ログをパースせずに単純にfluendに forward するだけなら先日公開された@tagomoris さんの fluent-agent-lite を使ってみるのが簡単だと思います。 #fluentd 用ログ収集専用のエージェント fluent-agent-lite 書いた – tagomoris のメモ置き場 ただ、in_tailプラグインを使ってパースして構造化した状態でfluentdの流れに乗せるのと同じことをやろうと思うと、送られた側でout_exec_filterとかする必要があって、
「ソフトウェア開発者採用ガイド」は採用される側も読んだ方がいい - As a Futurist...
会社でふと教えてもらった本だったのですが、読み始めたらすごいおもしろかったのですぐ読みきってしまった。2008 年なので僕はまだこういうことに興味なかったから全然網にかかってなかったけど、ググったりすると結構書評でてきますが、総じておもしろいって感じです。今更感ただよう書評ですいません。。。 高音域 社内外のスーパーエンジニアを見るに、本当に「できる人」と「できない人」には絶対に超えられない壁があると僕も感じる。 凡庸な歌唱は最高の歌手がいつでも出している高音域を決して出すことができない。 p. 011 会社が高音域を求めるなら、優秀なエンジニアを獲得するしかないわけですし、優秀なエンジニアとはそういうものですね、実際。高音域を求めないところなら、確かに人月の神話で凡庸なエンジニアを並べればできあがるのでしょう。 才能 とはいえ誰だって最初は「できない人」であって、それが「できる人」になる
Fluentd meetup in Japanに参加してきたのでplugin書いてみた - As a Futurist...
“the missing log collector”ということで昨今話題の fluentd ですが、日本での使用事例も増えてきたこともあり大規模なセミナーが開かれたので参加してきました。 Fluentd meetup in Japan on Zusaar 内容はとても充実していて、作者の古橋さんによる fluentd の概要から始まり、plugin の書き方、実例と続いていて 1 日で fluentd に詳しくなれるすばらしいイベントだったと思います。古橋さんのセッションで今までよくわかってなかった buffer plugin もイメージが持てましたし、@repeatedly さんのプラグイン作りの指南書のおかげで何を作れば自分のやりたいことができるのかが分かってきました。cookpad と NHN*2 の実例は非常に聴き応えのある内容だったので、もう一度資料見返しておこうと思います。
コミュニティがあって僕は生きられた - As a Futurist...
コミュニティについて、ふと振り返ってみた。 オフ会というもの コミュニティとはちょっと違うけど、多分オフ会的なのにちゃんと参加できたのは本屋オフが初めてだと思う。インターネットでしか見たことない人と会うことはすごい不安だったけど、とてもいい人ばかりだったし尊敬できる人ばかりで、おかげで 12000 円も散財した。。。 コミケ書き終わったからオフ充してきた – As a Futurist… 第 3 回本屋オフに行ってきた – As a Futurist… これがあったおかげで、オフ会というかインターネットでしか知らない人と会うことに抵抗なくなったし、むしろ積極的に会ってみた方がネットだけじゃできない話もできてものすごく有益だということを認識したんだと思う。 Tsukuba.R との出会い 僕が最初に出会ったコミュニティは Tsukuba.R。彼らとの出会いは、僕の人生にはかなり衝撃的だった。
2011年の振り返りと、2012年やること - As a Futurist...
あけましておめでとうございます。年末年始は 1 年間振り返ってみるのがいいですね。年度末年度始めのやってる気がしますが、年度始めになっちゃうともう新しい年度の仕事が始まっちゃうからなんだかんだ時間ないし。 2011 年振り返り さて、去年はこういう目標を立てました。 TOEIC の点数上げる YAPC::Asia で発表する コミケにサークル参加する 2011 年、今年やること – As a Futurist… TOEIC の点数上げる 2010 年は 595 点でした。2011 年は 690 点でした。まぁ一応上がりましたが、700 点には届かず。 何か努力できたかというと自分からやれたことはなくて、半年くらい会社の英会話を毎週 30 分やれただけです。単純に TOEIC に慣れたから上がっただけだと思います。 YAPC::Asia で発表する 無事達成できました。ご協力頂いた皆さんあり
LLをお手軽に使うllenvというのを作りました - As a Futurist...
perlbrew+carton とかとっても便利なんですが、例えばそれで作った CLI ツールとかにパスだけ通しても、carton execするためにcdしなきゃだったりなんだかんだめんどくさいなーと思って、ライブラリのパスを環境変数で渡して、実行する perl をフルパスで指定してあげる感じにしたらいいかもと思いました。 よく考えると ruby でもおんなじ感じでできるなーと思って、じゃあ python とか node.js もいんじゃね？ということで色々それぞれの言語の使い方調べて、ある程度統一的に使える様にしてみたのでひとまず公開しました。 riywo/llenv – GitHub 使い方 例えば、今使ってる perl の site_perl には何も入れたくないけど、ikachan を使いたいとします。まず ikachan 用のディレクトリを作ります。 $ llenv setup
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
