Amazon を退職してAutify に入りました - As a Futurist...
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
質の高い技術文書を書く方法 - As a Futurist...
大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは？ 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体
VancouverにあるAmazon S3チームのDeveloperになります - As a Futurist...
tl;dr - Amazon に入って 3 年が経ちましたが、この度転籍という形で Canada の Vancouver にある Amazon S3 開発チームに Systems Development Engineer として移ることになりました。 2010 年頃からずっとなりたいと思っていた北米での開発者の仕事(もちろん英語のみ)なので、本当に嬉しいです。AWS の Solutions Architect(SA)としてお客さんと向き合う仕事をじっくりさせてもらい、そこから実際に開発をしているチームに開発者として拠点も含めて移れるキャリアパスがあるんだよ、という一例になれましたので、SA になると自分の手を動かす機会が減ってしまうことを懸念している開発者の方の背中を押せたら幸いです。なお、2018 年 6 月頭に日本を出国予定で日本の会社も退職してしまうので、(旅行を除いて)日本に戻って
私と英語 - As a Futurist...
2016 年を振り返ると、英語力がめっちゃ上がった 1 年だった。せっかくなので自分用備忘録も兼ねて、自分の英語歴をメモしておく。あくまで僕はこうやったというだけの話なので万人が同じようにやるものではない。 なお、以下のブログの夫婦のエントリを見て触発されて書いている。 ほぼ 30 代からのスタートで TOEIC525→IELTS7、カナダ永住権取得までの道のり 夫の英語歴：TOEIC295→825！そして、海外就職までの道のり 中学 中学の授業で初めて英語を習ったわけだが、5 文型を教えられなかったので文法の根本がわからず、動詞の不規則変化にも挫折し、今後は出来る限り英語とは距離をおきたいと心に誓っていた。日本を出たいとも思ってなかったし、それで困ることはないと思ってた。 1 つ良かったことを上げるとすると、なぜか発音だけは褒められることがあって、スピーチコンテスト(スクリプト読み上げる
子育てエンジニアやってます - As a Futurist...
僕も子育てエンジニアしてるので、共有しておこうかなと思いました。 子育てありきのエンジニア業 – HDE BLOG 学生として、フリーランスエンジニアとして、1 年間子育てをして思った事 – 人間とウェブの未来 出産直後 僕は出産に完全に立ち会って catch baby もしたんですが、アメリカの病院は産まれた後は 1 日しか入院できなくて、2 日目には退院です(慣れない運転で連れて帰りました)。その後は自分たちだけで暮らしていくしかありません。僕らは実家も遠く夫婦 2 人しかいなかったので、出産直後でお母さんが一番苦しい時期を支えるのはお父さんしかいませんでした。アメリカの文化は本当に素敵で、すぐに 2 週間完全休み+1 週間 WFH(自宅勤務)にさせてもらえて、その間はお母さんしかできないこと以外はできる限りやりました。洗濯、料理とか買い出しはもちろん、おむつ交換もお母さんは授乳で疲れ
DeNAを退職してAWSにJoinしました - As a Futurist...
タイトルの通りですが、12 月末で 6 年弱勤めた DeNA を退職して、1 月から AWS に Join してます。日本の Solution Architect です。初めての B2B のお仕事なので新卒新入社員の気持ちです。新卒入社時の予定ではもうアメリカに留学してるはずだったのに、どうしてこうなったのやら。。。 さて、DeNA にはエンジニア未経験の状態からここまで力を付けさせてもらって大変感謝しています。売上に直接貢献するような仕事はほとんどできなかったですが、起こらなかった問題に対する貢献は少しは出来たかなと思っています。そういえばここではちゃんと書いてなかったですが、最後の１年間は MYCODE という遺伝子解析サービスの開発をゼロから行っていて、何もないところからリリースまで辿り着くという産みの苦しみを味わうことができて非常にエキサイティングでした。ちょっとだけですが Sec
MesosとCephのクラスタをAWSに構築するTerraformのmoduleを書いた - As a Futurist...
冬休みの宿題として、Mesos+Docker でアプリちゃんと動かしたい！→Shared Filesystem が欲しい →Ceph やりたい！→AWS の orchestration が必要 →Terraform 面白い！という yak shaving を経て、なぜかずっと Terraform をいじってました。とりあえずちゃんと動くのができたので公開。 riywo/mesos-ceph Terraform module for Mesos + Ceph cluster and Packer template – As a SW/Ops/DB Engineer 細かい話は 1 年ぶりの英語で適当に書きなぐったつもりなので、こちらにはポエムでも。 Terraform 面白い このブログとかを移行しようと考えてて、AWS を遊びじゃなくて運用しようとしたら、VPC とかサーバ以外に管理しなき
PHPカンファレンス2014でHHVM/Hackの話を聞いて感動した - As a Futurist...
使える言語の幅を広げたいと思ってPHP カンファレンス 2014に参加してきました。徳丸さんの「安全な PHP アプリケーションの作り方 2014」は改めて自分のセキュリティの知識を確かめるのに大変有意義だったのですが、何より感動したのが Facebook の Paul Tarjan による「HHVM + Hack == PHP++」のセッションでした。 すごく簡単に僕が理解した限りで HHVM/Hack を紹介すると、HHVM とは PHP の処理系の一つの実装です。その特徴は JIT コンパイルにより超高速になっていることに加え、圧倒的な魅力は PHP の Extension(C 拡張ライブラリ)の多くが実装されていて PHP のメジャーなフレームワークが問題なく動作するということです。つまりもう実践で戦えるということ。そして、Hack というのは HHVM が処理できるもう一つの言語
運用エンジニアから開発エンジニアになるためにやったこと · As a Futurist...
Web の会社でエンジニアを始めて 4 年、ずっと運用エンジニアをやってました。運用とは端的に言うと、社内外の他人が作ったソフトウェアを期待通りに動作させるためのエンジニアリングだと思ってます。アプリケーションはもちろん開発者が作ったものですし、MySQL や Apache や Linux も全部他人が作り上げたソフトウェアであり、それらの設定を変更したりパッチを当てたり運用ツールを駆使することで、協調動作させることに磨きをかけてきました。 ただ、いつまでたっても他人の作ったものの面倒を見てることには変わりないし、運用ツールを開発したところでそれはあくまで誰かが生み出す価値のサポートにすぎないのが自分的には満足できなくて、ずっとアプリケーション(ビジネスロジック)が作りたいと思ってました。 で、今年の始めからたまたまタイミングよく新規開発の部署に入ることになって、いきなり開発者をやることに
サンフランシスコ生活終わりました - As a Futurist...
1 年ちょっとサンフランシスコで生活してましたが、日本に帰任ということで 12 月末に日本に帰ります。SF でお世話になった方々ありがとうございました。今後も仲良くしてください。日本の方々、アメリカかぶれですがまたよろしくおねがいします。 英語について 英語が流暢になった、とはとても言えないですが、少なくとも行く前に持った「覚悟」に加えて「度胸」がつきました。文法めちゃくちゃだろうと発音がひどかろうと単語が聞き取れなかろうと語彙がなかろうと、伝えたい・聞きたいという思いを形にするだけの度胸は多少ついたと思います。そうしないと生活できないから。 仕事でもいわゆる日本とのブリッジみたいな仕事ではなく、こちらの会社の普通の 1 メンバーとして周りにも仕事相手にも全然日本人がいない環境で仕事ができたので、英語がわからないとか言ってられない感じでした。なんとかサバイブできてよかったです。だいぶ迷惑は
ポータブルなwebアプリケーションとそのインフラの未来の一考
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 とインタフェース仕様
最近のサーバの抽象化について - As a Futurist...
学者でもなんでもない現場のいちエンジニアの感想です。しかも、どれもちゃんと使ったことないので、聞きかじりをまとめたメモ書きなので嘘が入ってますが、興味ある方がいればどうぞ。 はじめに かつては「OS=物理サーバ」であって、その物理サーバの資源(CPU,RAM,DISK,etc.)をどのように使うかは OS がプロセスに割り振る形で決定されていました。しかし、それでは例えば以下の様な問題があります。 ファイルシステム資源をプロセスが自由にコントロールできない ProcA と ProcB で使いたい libfoo のバージョンが異なる場合面倒 CPU, RAM 資源もコントロールしにくい 同居してるプロセスがメモリ食い尽くして、みんな死亡、みたいな そもそも異なる OS を同居して使うことができない CentOS ばかり使ってるのに、使いたいライブラリが Debian でしか動かないとか 解決
「これからのWeb(バックエンド)」を自分の頭で考えてみた - As a Futurist...
ふと今更、年初のCROSS 2013の「次世代 web セッション」の動画を見て、うんうん唸ってしまった。プロトコル編の方は知識不足であんまり分からなかったですが、アーキテクチャ編の方はグサグサくるものがあった。「自分の頭でこれからの web を考えてブログに書くまでがこのセッション」という宿題が出ていたので、せっかくなので最近考えてることをつらつらと書いておこうと思った次第。特にまとまりはないですし、戯言です。 これからの Web の話をしよう。 (次世代 Web セッション @ CROSS2013) – Block Rockin’ Codes 前提 僕はコード書いてない＆サーバサイドしか見たことない＆WEB サーバはあんまり見たこと無くて、それより後ろ側ばっかり見てた人なので、ユーザ側とかアプリ開発者がどうなっていくかについて特に尖った意見はありません orz SPDY とかもまだ手を
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) 一番最初に
GrowthForecast as a Serviceみたいなもの - As a Futurist...
と思ったので、とりあえずということで誰でも自由に GrowthForecast を使える様にしただけのものは公開してみました。 http://test.gfaas.com/ 参考：GrowthForecast を Heroku で動かしてみる – As a Futurist… “GrowthForecast as a Service” = GFaaS ということで、ドメイン取ってみてます。これまで GF 使ったことがなかったという人も、適当に好き勝手にグラフ作ってみてもらって構いません(ただしいつサービス止まったりデータ消えたりしても怒らないで下さい。。。) グラフ何もないと面白くないかなと思ったので、適当に僕の Twitter の TL の件数とかをぶち込んでみました。 http://test.gfaas.com/view_graph/example/twitter/riywo_TL_n
YAPC::Asia 2012にフル参加してトークとLTもしてきた #yapcasia - As a Futurist...
今年は前夜祭〜ハッカソンまでフルコースで参加することができました。とても実り多いカンファレンスでした。 前夜祭 いろんな人とお話してたら食事食べるの忘れてて、でも無限ビールあるのでずーっと飲んでたらたいそう飲み過ぎました。。。久々に Hokkaido.pm の方々にお会いしたり、ささたつさんいじったりして楽しく過ごせました。フリークアウトさんの「50ms or die」はどう見ても「50 メートル走 or die」にしか見えませんでした！すみません！ 二次会はさくら水産でビール大ジョッキ連発しつついろんな話をできて楽しかったです。ただ、マジで飲み過ぎて何をしゃべったのかはあまり覚えておりません。。。後半、外国人の方が合流されてたので、せっかくなので英語でお話させてもらいました。 1 日目〜英語で 20 分トーク〜 完全に二日酔いで朝から本当に気持ち悪い。。。TL を見るとどうやら昨日一緒だ
今更CAP定理で分散データストアの勉強を始めてみた - As a Futurist...
長くなったので三行でまとめると CAP 定理を素人なりに調べてみた 分散データストアを CAP 定理で俯瞰してみた どのデータストア使うかの決定因子は CAP 定理的な視点の方がインタフェースとかより先 異論は認めるというか、専門知識ゼロなのでもっと正しい理解があればぜひ教えてくださいませ。 はじめに 僕は MySQL 厨なんですが、最近はやれ「MongoDB がいい」だの「HBase 最高」だのとよく聞きます。これら多種多様なデータストアを語る上で、「RDBMS VS NoSQL」みたいに問い合わせ言語の方式やデータ保存形式の違いで語るのは宗教論かなぁと僕は思ってます。単体プロセスのデータストアとしての特徴とか性能とかは正直なんでもいいかなぁと。 思うに、本質的に重要なのは MySQL の master-slave&sharding という Web で今までスタンダードに使われてきた分散
DevOpsDays Tokyo 2012に参加してきたので聞いたこととか思ったことまとめ - As a Futurist...
DevOpsDays Tokyo というイベントが行われていたので参加してきました。DevOps という単語やムーブメントを牽引する英語圏のゲストを招いての大規模なイベントでした。会場の GMO さんやスポンサー各社のご協力のおかげか、至れり尽くせりな感じですごかったです。 Tokyo 2012 – welcome セッションスピーチはほとんどが各社製品紹介みたいな感じだったので割愛しますが、その後に行われた OpenSpace が相当エキサイティングでした。これは海外のカンファレンスだとよくある形式なんですが、会場とコマだけ用意されているので、あとは話したい人が話したいテーマをその日に適当に入れてプレゼンとかディスカッションをするという感じのものです。その場で生まれる議論のダイナミズムは、普段から色々と頭を使って手を動かしているエンジニアにとってはとても刺激されるものではないかと思います
スキーマレスについてちょっと考えてみた - As a Futurist...
このエントリはたぶんに煽り要素を含めていますが、意図的なものです。僕は NoSQL は素晴らしいと思います。 さて、NoSQL なんて言葉に踊らされてる人は置いといて、最近 RDBMS 以外のデータストアというのが色々でてきてます。今時点で見渡す限りにおいては、安定性、耐障害性、パフォーマンス、情報量、開発者の慣れ、全体のバランスで言えば RDBMS にかなうものはないわけですが、今後どうなっていくかはまぁ分かりません。 一方で、RDBMS がどうしても苦手とする分野というのは存在します。例えば 1 サーバに収まりきらない様な大容量データに対するバッチ処理、リアルタイムなランキング、アクティビティなどのフィード情報、そして構造化されたデータの取り扱い。何でもかんでも NoSQL に置き換えればいいなんて考えは現時点では到底受け入れがたいですが、例として挙げた様なピンポイントな部分ではそれに
rbenv ruby-buildとunicornでもっとさくっとRedmine入れてみる - As a Futurist...
前にこういう記事書いたんですけど、Redmine プロジェクトは結構活発でついこの間 1.4.0 がリリースされてました。なんと Ruby1.9 系へ対応！Gemfile も提供されるようになってよりインストールが簡単になってたのでかっとなってやってみました。ついでにこちらもだいぶ枯れてきた rbenv+ruby-build を使い、HTTP サーバとしては unicorn を使ってみました。 rbenv+ruby-build のインストール git は入っている前提ですが、超簡単です。 $ cd $ git clone https://github.com/sstephenson/rbenv.git .rbenv $ mkdir -p ~/.rbenv/plugins $ cd ~/.rbenv/plugins $ git clone https://github.com/sstephe
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
