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
Software engineerが日本から北米に移住すること - As a Futurist...
自分は日本からアメリカとカナダの北米 2 カ国に、労働許可を持って移住した経験があります。そういった移住/働いてみたいという方の相談にのる機会も多いのですが、共通して持っておいた方が良いなと思った情報がいくつかあるので、まとめておきます。 その前に注意事項として、以下をご確認ください。 就労に関する状況は日々変化しています。ここの情報はあくまで参考として、最新の正しい情報はご自身が行かれる際に改めて然るべきルートでご確認ください。 なぜ北米に行くのか？という問いにはこのエントリでは答えません。あくまでも移住したいというモチベーションを持っている方向けの情報になります。 自分と同じ様に日本国籍のみ有していて、ずっと日本で生まれ育った方に向けて書いています。細かい状況の違いは読み手側で吸収してください。 これは個人の意見であり、私が所属するいかなる組織の意見を代表するものでもありません。 認識
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 つ良かったことを上げるとすると、なぜか発音だけは褒められることがあって、スピーチコンテスト(スクリプト読み上げる
DeNAを退職してAWSにJoinしました - As a Futurist...
タイトルの通りですが、12 月末で 6 年弱勤めた DeNA を退職して、1 月から AWS に Join してます。日本の Solution Architect です。初めての B2B のお仕事なので新卒新入社員の気持ちです。新卒入社時の予定ではもうアメリカに留学してるはずだったのに、どうしてこうなったのやら。。。 さて、DeNA にはエンジニア未経験の状態からここまで力を付けさせてもらって大変感謝しています。売上に直接貢献するような仕事はほとんどできなかったですが、起こらなかった問題に対する貢献は少しは出来たかなと思っています。そういえばここではちゃんと書いてなかったですが、最後の１年間は MYCODE という遺伝子解析サービスの開発をゼロから行っていて、何もないところからリリースまで辿り着くという産みの苦しみを味わうことができて非常にエキサイティングでした。ちょっとだけですが Sec
リアリティを持つ・持たせる - As a Futurist...
すごくいい記事を見つけたので自分も思うところをしたためておこうかと。著者はかの有名な ryopeko ワイフさんの旦那さんです。 悪いのはその事実から目を背けることだ。 なんで目を背けられているかというと、将来のエンジニアとしての自分と社会のエンジニア像にギャップがありすぎるからだ。 (なあなあでエンジニアを目指して勉強するしかない) この状態を実際の生きたエンジニアをもっと学生の前に晒すことで解決したい。 それぐらい学生側からすると社会っていうのはリアリティが無い。 高専カンファレンスに来ないような人達に思う – ryopeko の日記 気づけばよかった 僕もまったくそのとおりな生活をしていました。自分が将来どうなるのかについて全くリアリティを持つこと無く 20 年以上過ごしてしまったわけです。22 になる頃にようやくどうしたもんかというところで思ったのは「もっと早く”気づいて”いれば。
サンフランシスコ生活始めました - As a Futurist...
サンフランシスコからこんにちは。今日からひとまず 1 年間、アメリカのサンフランシスコで仕事をすることになりました。だいぶ前から言っていた夢がひとまず叶ってとてもハッピーです。 今回、日本の会社からの出向という形でアメリカの会社で働くことになりましたが、アメリカで働くというのがこんなにも大変で面倒なことなのかと思い知らされました。ビザの取得に始まり、日本で住んでいるところの処理やアメリカでの住宅探し、銀行や携帯電話など今まで当たり前に持ってたものがないこと、仕事の引継ぎ(業務自体や評価)、保険や税金などの違い、などなど。今回は会社にたくさんサポートをしてもらえて本当に助かりました。 また、諸事情あって 10 月頭という当初の予定から 1 ヶ月遅れてしまったのですが、9 月からの 2 ヶ月間に本当に色々な方から「いってらっしゃい！がんばれよ！」と言って頂けて大変ありがたかったです。イクイク詐
GrowthForecastをHerokuで動かしてみる - As a Futurist...
Heroku といえば PaaS では一番有名かなぁと思います。オフィシャルには perl はサポートされてないんですが、buildpack というスクリプト群を準備してあげると perl も使えます。miyagawa さんが公開されているものを少しだけ改造して、それを利用して GrowthForecast を Heroku で動かしてみました。 riywo/heroku-buildpack-perl riywo/GrowthForecast at heroku-dev 当然鬼門は RRDtool GrowthForecast を動かすにあたって、一番の鬼門はご存知 RRDtool になります。依存ライブラリが多く、入っていない場合にはそのインストールが必要になります。gfx さん作のAlien::RRDtoolが Makefile.PL の依存に書かれているので、もし必要なライブラリが一
かっこいいスライドの作り方 #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 のパレットに拾っておいてあとはそれをポチ
初めてのオレオレbash補完 - As a Futurist...
さて、ひとつ前のエントリは釣りだったわけですが、本題の bash 補完を初めてやってみました。ちょっとした物だったら割と簡単に書けたので、共有。 目標 自作コマンド(仮にsugyanとします)はこんな感じの I/F だとします。 sugyan subcommand [args] いくつかの subcommand は次にくる引数が限られる 例えばsugyan momocloの後にはkanako renichan shiorin ahrin momoka sugyan listでそういう補完の一覧が色々出せる sugyan list commandで subcommand の一覧 sugyan list momocloでももクロ一覧 一応sugyan listでcommand momocloが返る あとはいつもの bash のままにファイルとかを補完して欲しい 実際叩くと、 $ sugyan
今更CAP定理で分散データストアの勉強を始めてみた - As a Futurist...
長くなったので三行でまとめると CAP 定理を素人なりに調べてみた 分散データストアを CAP 定理で俯瞰してみた どのデータストア使うかの決定因子は CAP 定理的な視点の方がインタフェースとかより先 異論は認めるというか、専門知識ゼロなのでもっと正しい理解があればぜひ教えてくださいませ。 はじめに 僕は MySQL 厨なんですが、最近はやれ「MongoDB がいい」だの「HBase 最高」だのとよく聞きます。これら多種多様なデータストアを語る上で、「RDBMS VS NoSQL」みたいに問い合わせ言語の方式やデータ保存形式の違いで語るのは宗教論かなぁと僕は思ってます。単体プロセスのデータストアとしての特徴とか性能とかは正直なんでもいいかなぁと。 思うに、本質的に重要なのは MySQL の master-slave&sharding という Web で今までスタンダードに使われてきた分散
「リーダブルコード」が良書すぎて胃が痛い - 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
英語で数字が聞き取れないので練習スクリプト書いた - As a Futurist...
ビジネス英語で一番最初につまづくのが、数字が全然聞き取れないこと。3 桁ずつに区切ってるのは頭では理解してるんですが、そもそも 3 桁の数字が全然把握できない。。。 そういえば Mac にはsayコマンドというしゃべらせるコマンドがあったなぁというわけで、超やっつけですがそれを使ってひたすら延々と数字を聞きとっては答えるスクリプト作りました。 使い方はこんな感じ。以下では分からないですがターミナルでは正解だと緑、間違ってると赤色になります。 $ perl practice.pl What is the number?[NUM|r|e] : 201 [0.986 sec] Right! (201) What is the number?[NUM|r|e] : 241 [1.060 sec] Right! (241) What is the number?[NUM|r|e] : 865 [2.
English Casualがすごい良かった - As a Futurist...
真っ黒クロスケで有名な oranie さん主催で「英語でプレゼンする経験をしてみよう！」というコンセプトの元、英語苦手な人達で集まって「資料・発表・質問は英語縛り」というレギュレーションで English Casual をやってみようという話になりました。僕は会場提供係ということで無事ヒカリエの会議室を使って開催することができました。 僕の発表資料はこちらになります。発表の内容は問わず、ともかく英語でやってみるというのが趣旨なので、内容は超適当ですすみません＞＜ English Casual 2012/05/10 やってみた感想としては、思った以上に良かったですね。やっぱりとにかく経験値が足りないわけで、場数を踏むのは大事。ただ、普通の英会話とか行っても、なかなか技術の内容について話す機会は無いわけで、こういう機会はすごい大事だなぁと思いました。英語の上手い下手とか関係なくて、伝わることが
スキーマレスについてちょっと考えてみた - 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
英語アカウントのつぶやきを日本語に翻訳してTwitterに投稿するスクリプト - As a Futurist...
そろそろ国際人になろうということで、英語ブログと Twitter の英語アカウントを準備してます。よろしく。 riywo weblog riywo@SF(hopefully) (riywo_en) on Twitter で、perl の練習ついでに英語アカウントでのつぶやきを翻訳 API 使って日本語にして日本語アカウントにつぶやくスクリプトを試作してみました。こんな感じで reply としてつぶやいてくれます。 riywo/TwitterTranslate · GitHub "これは、自動翻訳のためのテストです。" (@riywo_en) — Ryosuke Iwanaga (@riywo) April 7, 2012 自分のつぶやき取得は AnyEvent::Twitter::Stream で stream api を使って取得してます。filter メソッドで follow に自分の
若者がパッケージ管理について思うこと - As a Futurist...
App::llenvというのを書いたり、Touryoというサーバの設定管理ツールを書いたりする中で、広義な「パッケージ管理」というものにすごい興味を持っているので、思うことを書いてみる。 **【追記】**タイトルが意味不明っていっぱい言われたのでえいやと変えてみた **【追記】**結論書き忘れてたので続きを書いた: 若者がパッケージ管理について思うことの今の結論 – As a Futurist… パッケージ管理って怖くてよく分からないとか思ってる人に少しでもパッケージ管理に親しんでもらえればと思って書いてる。かく言う僕も Perl の Catalyst や Plagger のインストールに泣いたり、rpm の依存ぶっ壊して戦々恐々としたりした経験があってここにいるわけなんですが、もうみんながそういう苦労するのあほらしいよなぁと思うので、パッケージ管理ってどういうところが勘所なのか知ってもら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
