Posts

I already posted_ about switching this blog to igawa.io. But I think it’s good to share the information about the architecture of this blog for you and especially me :) Architecture/tools GitHub Pages, CloudFlare So, currently, this blog uses GitHub Pages which can be used as a free blog system. And I also use it with my custom domain and HTTPS with CloudFlare_. Pelican And I’m using pelican_ as a blog system which is really powerful and written by python. That means I can improve and fix if I need it. And I’ve done it before. Branches Here is the repository of this blog. This has two main branches, one is master and the other is source. master branch is for managing generated contents. source branch is for managing source code such as blog post rst/md, imange, files, etc. So, the two branches are completely different. I feel this is a bit weird, but I couldn’t find a better solution so far. And It seems it works well. I don’t need to change the workflow. ...

I changed my blog to my original domain. My blogs were split to some different domains due to my laziness. So I decided to merge them. I was trying to change it to wordpress.com first. But it’s not my taste :-p So, I decided to use pelican_. I actually had two blogs on Blogger(br.0r2.info) and github pages(afterstack.net). So I needed to export br.0r2.info data to merge github pages. And I also wanted to change the domain to use igawa.io_. Firstly, I was trying to use wordpress.com, so I exported my blogger data, and imported it on wordpress. And next, I also exported the wordprss data, and I imported the data with using pelican-import_ like this. ...

I’d like to run a retrospective myself against the PTG in Denver, briefly. Positive keep to have conversation with QA and the other people got new conversation with QA and some people had a lot of fun time in a social meeting (almost) only one pub was very convenient :) got productive time got to know new QA related things like Zuul v3/o-h, OPNFV testing got a Happy hour with Parrots Negative still very poor English, conversation skill, it didn’t often go well. still poor technical skill tooooo much drunk very hectic on the last day (Saturday) in very bad jet lag days Action Learn and train English and conversation skill ...

これは、 OpenStack Advent Calendar 2016 のエントリです。 先日、OpenStack に新たなリポジトリを追加したので、そのときに感じたことや経験を共有してみたいと思います。 ナニを追加したのか？ coverage2sql Coverage.py によって生成される、単体テストなどの coverage データを、データベースに時系列な データとして保持するための小さなツールです。最終的には、 openstack-health と連携して、 単体テストの coverage 推移を表示したいと考えてます。もちろん、: 「カバレッジ100%だったら品質が良いわけじゃないよね？」 という話はあります。しかし、少なくとも、カバレッジ率が意図せず下落傾向な場合は、問題がある可能性があり、 それを知ることができるというのが重要と考えています。 このような性質のコンポーネントのため、独立したプロジェクトではなく、 Quality Assurance プログラム配下のリポジトリとして追加しました。このようなリポジトリを追加することはなかなか無いこととは 思いますが、新しいリポジトリを追加した経験は、もしかしたら誰かの役に立つかもしれないと思い、共有します。 なお、似たようなツールとして subunit2sql と言うものがあるのですが、それにインスパイアされて作りました。 新しいリポジトリの追加方法 Project Creator’s Guide をまずは読みます。ステップ・バイ・ステップで丁寧に説明された ドキュメントです。このとおりやっていれば、あまり迷うことも無いと思います。 大きな流れとしては、 Launchpad 設定 PyPI 設定 openstack-infra/project-config, openstack/governance 設定 レビュー待ち＆対応 新しいリポジトリ作成（最初でもOK） Gateジョブ実行動作確認 初期バージョンリリース … という感じになると思います。 ドキュメントに書いてないこと ドキュメントのとおりに進んでいって、特に困ったことにはならなかったので、あまりないですね。強いて言えば、 Launchpadの登録で、少しだけ記述が現状とあってない部分があった。 -> ドキュメントの修正パッチ を出しています。（まだ誰もレビューしてくれないけどｗ） Ubuntuバージョンはxenialが基本(trustyが必要でなければそのジョブは入れないほうが良い) くらいでしょうか。 感想・まとめ リポジトリ追加は比較的カンタン OpenStack Infra job設定わかりづらい。。(他のを真似してやればある程度は想像つくけど) でも、OpenStack インフラを使って自動ビルド・テストが実行できるのはとても便利 参考URL Project Creator’s Guide coverage2sql https://launchpad.net/coverage2sql openstack/governance: Add coverage2sql to Quality Assurance openstack-infra/project-config: Add coverage2sql project Happy Hacking!

本エントリは「 OpenStack Advent Calendar 2016 」の 12/5 分です。 先日(2ヶ月弱前)、 少々刺激的なエントリ を投下しましたが、現在の気持ちを少し述べてみたいと思います。 結論：転職は良い選択だった 今年１月に転職し、あらたな環境で働くことになりました。前職は、新卒で入社しずっと働いてきた会社で、 かれこれ17年以上勤めた事になります。そのような会社を辞めることはとても、非常に、たくさん考えましたし、 迷いました。 迷った理由は色々あります。 インターナショナルなチームで英語が標準語なのにやっていけるのか？ 外資系ってことでかんたんにクビを切られるんじゃないか？ 技術的なスキルが追いついていかないんじゃないか？ 今までのキャリア捨てるの？ 今やってること、中途半端じゃないの？ OSS「プログラマ」ってオマエ何歳だと思ってるんだ？ 主体的に動けば今いる会社でも、自分のやりたいことができるんじゃないの？受動的に動いてない？ 今はOpenStackが流行ってて良いけど、ブームが去った後どうするの？ などなど。 でも、最終的には「転職」を選びました。 その選択理由として、以下のようなことを考えてました。 英語が標準語なので、英語スキルを高められる。 あと1.5〜2年くらいはブーム(バブル)が続くだろう。 技術・英語スキルを伸ばせば、次に繋げることができる。 今いる会社でやりたいことをやるには、そのために色々と動く必要があり、自分のやりたいことをやるまでに、色々大変そう。 ヨカッタと思うこと 英語スキルが多少上がった（気がする） 視野が広がった(国内だけではなく、海外に目を向けるようになった) 社外の人との交流が増えた 「次」を考えることができるようになった ストレスが減った やりたいことに集中できる環境を手に入れた 給料(微)増 イマイチだったと思うこと 英語スキルを想定よりも向上できてない 技術スキルも想定よりも向上できてない 想定よりも早くブーム(バブル)が下火になってきた 100% upstream オープンソース開発 というのも難しくなってきた（かもしれない） まとめ 総合的には、転職して「良かった」と思っています。 確かに、想定外のことや「イマイチだったなー」と思うことはあるものの、 今の所はヨカッタと思うことの方が上回っています。 なので、以下のような場合には、転職を考えても良いと思う。 自分がやりたいと思うことが出来ていない＆社内にそういう環境を見いだせない 今よりも良い環境が他の会社にある その企業からのオファーを受け取った もっと詳しく聞きたいという方がいたら、ご連絡ください :)

本日、OpenStack-Health のパッチをいくつかApproveしました。 Add base utilities for canvas charts Add canvas line chart Add canvas scatter chart これは、グラフ描画用のJavascriptライブラリ（ユーティリティ）です。今までは、nvd3 という d3js を 使いやすくしたJavascriptライブラリを使用していましたが、パフォーマンスと細かなバグに悩まされることも多く、 独自実装に切り替えようとしています。(d3js は引き続き使っています。) まだ、全てのグラフを置き換えられたわけではありませんし、荒削りな部分が多々ありますが、良い方向に進んでいる と思います。 まぁ、最悪、クリティカルなバグがあったとしても、パッチをrevertすれば良いので、 恐る恐る進む必要もなく、むしろ、現時点では、リスクを恐れて前に進まないほうが問題と判断しました。 現時点での課題は… unit testが無い グラフが二重描画されることがある -> ブラウザリサイズ/リロードでなおる 今後も、品質改善に向けて進んでいきます :) 以下が OpenStack-Health の画面です。って、http://status.openstack.org/openstack-health/ にアクセスすれば、 誰でも見られます :) Happy Hacking!

oss-programmer-part1 の続き 前回: 次回は仕事内容、コミュニケーションの様子などを書きたいと思います。 と、書いておいてしばらく経ってしまいました。 気になってる人がいないとも限らないので、書いてみたいと思います。 コミュニケーションの様子 HPEは外資系の会社なので、社内のシステムやメールなどは英語が主ですが、日本にいる社員の大半は日本人なので、 日本オフィスは、日本語が共通語になっているようです。 ただし、私の仕事内容はOpenStackというオープンソースのクラウド基盤ソフトウェアを、コミュニティの中で開発 することです。また、会社のチームはインターナショナルチームなのでチームメンバー・上司が英語が母国語の 人たちが大多数で共通語は英語という状況。そのため、英語が必須な状況ですが、10ヶ月近く経った今も、 英語スキルは以前とあまり変わりがありません orz… もちろん「前から英語ができてた」わけではなく「今もあまりできません」という有様です。 気心知れた人との１対１での会話ならなんとかなります(「あ、こいつ英語苦手なんだね」と相手がある程度手加減 してくれることが多いのです)が、ネイティブあるいはそれに近い同士が議論をし始めると、なかなか入っていけません。 また、もともと人見知り(!)でコミュニケーションは苦手な部分があるので、なかなか会話に入っていけません。 それでも、どうにかなってるのは、テキストでの会話（IRC, E-mail）のお陰かなと思います。 この辺は、自分の中の要改善項目です。 テキスト というわけで私はテキストでの会話が主です。タイムゾーン問題、英語力、などのことを考慮すると、 テキストでの会話が便利です。 E-mail テキストでのコミュニケーションというとコレが思い浮かぶと思います。ただ、あまり使ってないです。 正式な通知とか、後述のものでは伝えにくいもの（言うことがたくさんあったり、添付ファイルとか）で 使う感じ。 IRC E-mailはリアルタイム性が低いので、結構やりやすいですが、どうしても時間がかかってしまいがちです。 IRCはリアルタイム性が高いので、やり取りがけっこう大変ですが、くだけた会話でもどうにかなります。 一長一短ありますが、IRCの方が気楽なことが多いと思います。 今だと、SlackやHipChatなどのツールもありますが、私のチームではできるだけ「オープン」なものが 好まれる印象です。 Face to Face Face to Faceのやり取りがないのかというと、そうでもありません。 Google Hangouts, Skype これらのツールを使う機会もあって、 Happy Hour 重要な通知 といったタイミングで使ってきました。 「Happy Hour」はチーム内のコミュニケーションを活性化して、風通しを良くするような効果があったと思います。 その名の通り、就業時間後のバーチャル飲み会風な感じなのですが、日本時間だと朝９時とかなので、 こちらはさすがにお酒を飲むわけにはいかないのがつらいところでしたｗ また、雑談が高速で行われるので、あんまりついていけない感じなのも残念でした＞自分 「重要な通知」は、メールやIRCだけで伝えるべき内容ではないものですね。チームの行く末とか。 こちらについてはまた別途。 各種イベント OpenStack Summit等、各種イベントで各国に散らばってるメンバーが集まることもあるので、 一緒にお昼ごはんに行ったり、夜飲んだりとかありました。 仕事内容について 体制 チームには日本人は私しかおらず、日本で作業しているのも私のみです。 直属のマネージャはオーストラリアにおり、タイムゾーンが近いこともあって、IRCなどで会話をすることが多いです。 さらにその上の上司は、 Allison Randal (Wikipedia JA, Wikipedia EN) さんで、 やはりIRCで会話をすることが多いです。(タイムゾーンが違うこともあり、なかなか会話はないですが) さらに上の方になってくると、HPE のクラウドを統括している人になってきますが、なかなか話をする機会はない ですね。ただ、IRCのミーティングに参加したりすることもあり、非常に上下の風通しは良いんじゃないかと感じます。 変な上下意識が見えないのが心地よく感じます。（もちろん、役割はしっかり意識されています。） 外資系企業について 当初思っていたよりも、ずっと個人を重視してくれているように思います。 (身の回りの10ヶ月弱くらいの感想です。) 外資系企業に対する私の印象は、 「キミ、最近パフォーマンスが良くないから、改善策を検討して実施するように。特になければこの改善策を実施 して、1ヶ月で改善されないようならクビね。」 くらい厳しいものだったのですが、少なくとも今いるチームではそのようなことはありません。 この辺は、上司に依存するところが大きいと思います。 (でも、時にはパフォーマンスに関係なくバッサリクビを斬られることがわかりました。。 が、それはまた別途書きたいと思います。) 作業内容 基本的にはOpenStack関連コードの読み書き・レビューしてます。 イベントでの発表などがあれば、その準備も。 最近はopenstack-healthというコンポーネントに注力して作業してます。フロントエンドがAngularJSなので、 かなり刺激的。悪戦苦闘の日々です。 作業場所 大島 日本法人本社８階 食堂で作業してます。景色がいいし、比較的静か（心地よいノイズ）があるのでいい感じで 作業できてます。 参考URL: http://www.lifehacker.jp/2013/03/130313hp_staff_canteen.html http://www.shashoku.com/shashoku/012.html http://www.pc-ninki.net/about/hp-oshima.html https://job.career-tasu.jp/2017/guide/study/shashoku/01.html Happy Hacking!

追記 以下は、あくまで私が所属しているチーム(OpenStack, OSSをアップストリームで開発)についてのみ言及しています。 それ以外のHelion開発その他については言及していません。誤解のなきよう。 オリジナル oss-programmer-part2 にて: (でも、時にはパフォーマンスに関係なくバッサリクビを斬られることがわかりました。。 が、それはまた別途書きたいと思います。) と書きました。が、それについて書きたいと思います。 連投になってしまって申し訳ないです。もう少し気を静めてから書こうかとも思ったのですが、 今の気持ちも含めて記録しておきたいなと思い。 まずは、関連Tweetをいくつか。 Today I laid off my entire team. I'm completely gutted. They're the best w/whom I've ever worked. They humble me daily. Hire them, please. — VM Brasseur (@vmbrasseur) October 17, 2016 Today I was notified that my position at HPE is affected by layoffs so I am looking for a new role — https://t.co/A9XLekuX25 Please share! — Donald Stufft (@dstufft) October 17, 2016 I'm seeking a new ops or evangelist role! Must haves: Open source, travel for speaking and work from home. Details: https://t.co/PDD6HGPsuz — Elizabeth K. Joseph (@pleia2) October 17, 2016 All of my US-based team-mates got laid off today. Each and every one would be a stellar hire. Hire them. ...

概要 「OSS」も「プログラマ」も知っている方が多いと思いますが、それを専門にやっている人のことは知らない人が 多いかなと思い、こんなブログを書いてみました。 想定読者 オープンソース開発で飯食っていけるの！？と思っている人 なんとなく、OSSとかプログラマに興味がある 「外資系」ってどういうところなのか知りたい 結論 技術力だけじゃない ４０歳でも（転職）初体験できる 英語大事 自己紹介 現在Hewlett Packard Enterprise/日本ヒューレット・パッカード所属です。OpenStack開発者で、 主にQAを担当しています。日本で作業していますが、日本人は私一人です。他のメンバーは全て海外にいます。 （正確な人数は把握してませんが、多分2-30人弱くらいかと思います。） インターナショナルで分散チームで、大半は、アメリカ・欧州・オーストラリアにいて、アジア人は中国人1名と 私の合計2名です。チームの中にマネージャが数名おり、１マネージャあたり、数名を管理するような体制です。 なお、私のマネージャはオーストラリアに在住していますが、私は英語はそれほどしゃべれません。TOEIC最高点は (ほぼマグレで)800点でした。最近は受けてませんが、そんなに大きな違いは無いかと思います。 （TOEICをある程度知っている方はどの程度なのか想像がつくのではないでしょうか…） 技術力だけじゃない まずはじめに。私はスーパー(ハカー|プログラマ|デベロッパ)と呼ばれるほどの技術は持ってません。技術力は 「並」くらいはあるとは思いたいですが、突出しているわけではありません。周りのOpenStack開発者をざっと 見回しても「あいつには勝てないな・・・」と思うことが多々あります。 そんな状況なのに「プログラマとして転職してやっていけるだろうか・・・」と自問自答している日々ではあります が、最近は「技術力だけではない」と思うようにしています。自分の役割としては… OpenStack開発 -> もちろん、これが一番重要。早い・遅いはそれほど重視されていない様に感じる。知らないことがあれば、 どうやって解決していくのかが重要。 自分の持っている知識・技術・経験を使って、ほかの人に伝える・手伝う/助ける。 あまり他の人がやっていない分野に貢献する。 盛り上げ役（苦手ダケド） などなど、色々貢献できる領域があると思うようになってきました。逆に、技術力だけ非常に高くても、 コミュニケーション能力が圧倒的に低いと厳しいだろうなと思います。（という意味でも英語大事） また、転職するときに今のチームメンバーの一人から、 「人から言われて動くようだと、今のチームではうまくやっていけないと思う。だから、自分でやるべきことを 考え・ 探してやっていくようにしたほうが良いよ。」 というようなことを言われました。 実際、今のマネージャやその上の上司などからは「アレやれ、コレやれ」という指示は無く、週1のマネージャと のミーティングも、IRCでチャットしてるだけで、特にノルマ（ｘ件/月パッチマージとか）もありません。情報共 有しておきたいこと、困ってることなどを相談する場になっています。もちろん、社内の必須教育、事務処理フォロ ーなどはありますが、それほど多いとは感じません。 ４０歳でも（転職）初体験できる 私、今、４０歳です。日本のIT業界一般常識から考えると頭の良いキャリア選択ではなかったかなとも思っていま す。日本のIT業界的には、 「マネージャになって、デカイプロジェクトをガンガンさばいて、コンサル系に転職してウハウハ」 みたいなのを思い描いている人もいると思いますが、私は、そういうところに「楽しみ」を見いだせませんでした。 なので、「技術者」として生きていく道をずっと考えていたので、今回、縁があって転職することになりました。 転職した先では、比較的長く「技術者」として働ける環境ができているとは思います。 今、思っていることなどを以下に列挙してみます。 見極めはもっと早くすべき。年齢を重ねて、地位が上がるにつれ、関係各所に色々と迷惑をかけることが増えて きて、身動きが取りづらくなる。 記憶力、スピードなどはどうしても年々衰えてくるのでそういう意味でも若いうちにやれることはどんどん やっておくべき。 とは言え、それなりのオファーがないと転職は難しいので、私としては最速に近いくらいのタイミングだった。 自分のキャリアパスはきちんと考えて、流されずに主張しよう。 思い描いたキャリアパスが今の会社に無いのなら、それがあるところに移ることも考えよう。 もちろん「自分の道を作っていく」という選択肢もあり、それをやりたい人ならそこで頑張るのが良いと思い ます。私の場合はそうではありませんでした。 自分が「面白そう」と思う分野に進んだほうが、全体最適化から考えても有意義。 自らやる気になって動く時が一番力を発揮できると思います。個々人が「面白そう」と思ったことに 全力を傾けるのが、結果、全体最適になるはず。 実は、数年前にも転職活動していた時期があります。その時はいくつか面接まで行きましたが、ことごとく 敗退。自己主張、アピールが足りなかったんだろうなと思う。 英語大事 学生のうちから本気で取り組むべき。 と、後悔だけしても意味が無いので、これから頑張ることにします。 まだまだ英語苦手なので、コミュニケーションに日本語の3倍以上の時間と労力がかかりますが、この労力をなんとか 小さくしていくべく、トレーニングの毎日です。 次回予告 次回は仕事内容、コミュニケーションの様子などを書きたいと思います。 Happy Hacking!

https://gist.github.com/masayukig/3ab6c18ace33eb01f9d1.js