聖誕祭(順延)

今年もやってまいりました私と息子の聖誕祭でしたが、私は先週から喉をやられてしまい、息子は前日に39度の発熱という状況で、イベントは来週に順延となりました。

とはいえ、何もしないもなんなので、夕方に買い物に出てケーキを買ってみんなで食べておしまい。

去年の誕生日に奥さんからもらったバッグが数ヶ月前に壊れてしまったので、しばらくはYAPCでもらったトート(?)で生活していたのですが、さすがに厳しい感じになってきたので、変わりのバッグをアマゾンさんにお願いしていたのが届きました。前回はファスナーが壊れてしまったので、ためしにファスナーが少ないやつにしてみました。

そんなこんなで、もう33歳になったようです…定年まであと2年かーという気分ですね。あと、そろそろアラサーと言えない年になってまいりました。

というわけで、いつものやつはここにおいておきますね! https://amzn.to/kenchan-wl

あとあと、もちろん何か送っていただくのもすごくすごく嬉しいのですが、私達と一緒にペパボをバーンとしていく仲間になってもらえるのが一番嬉しいので↓もぜひぜひよろしくおねがいします!

技術基盤整備エンジニア(正社員/東京) | エンジニア | 職種詳細 | GMOペパボ株式会社

風邪をひいて1回休み

昨日あたりから体調が悪かったんだけど、今朝はまったく起きられなかったので1回休み。

少しよくなってきたので明日からまたがんばろ。

PhantomJS 2.0.0 はファイルアップロードがうまくいかないことがある

YAPCに応募したトークの通り、今私はcapybara(& poltergeist)でE2Eテストを書いてるわけですが、 attach_file を利用したファイルアップロードがうまくいかないなーと悩んでいたらドンピシャなissue Webpage.uploadFile not working in phantomjs 2.0 · Issue #12506 · ariya/phantomjs があったので諦めてバージョンを下げたものを使うようにしました。

homebrewでインストールしている場合は以下の方法でバージョンを下げられます。

$ brew tap install homebrew/versions # ここにphantomjs198がある
$ brew install phantomjs198
$ brew link phantomjs198

このバージョンだと、今度はJavaScriptの警告が出るようになってしまったのですが、テスト自体はうまくいっているのでこちらで進もうと思います。

POとPOじゃない人の勉強会 第06回

プロダクトオーナーシップ勉強会という名前がよくないな、と思ったので、今回から「POとPOじゃない人の勉強会」というタイトルにしたのでした。

意味わかんないかもしれないけど、そういう勉強会なんですよ。

本書は結構古い本なので、コレは最近でいうアレだよね、とかそういう話をしながら1時間みっちり。

今回は議事録に参加者の声を載せてみたので(下にも転載しておきます)、次回からは参加者倍増するはず!!1この勉強会は他人事ではない!!1

参加者の声

  • この後勉強会があることだけが心の安らぎかもしれない、、、(A事業部Tさん)
  • 心の拠り所になっている (B事業部Tさん)
  • 今日も学びが多かった!! (A事業部Wさん)

YAPC 2015 のトークに応募しました

ペパボに来てからもう少しで1年だけど、なんかバーン感ないし、うーん…と思っていたのですが、自分のバックグランドと得意なところがマッチしたお仕事をはじめたので、まだ結果は出てないですが、その結果報告ができればなーと思って応募しました。

10年動き続けているブログサービスのエンドツーエンドを書いた記録 - YAPC::Asia Tokyo 2015

発表が通るか、仕事はうまくいくのか、両方たのしみですね。

みんなのバースデイ

GMOグループでは「みんなのバースデイ」という誕生月の人を祝うイベントが月1で行われており、誕生月の人はゲームで勝つ(?)と豪華賞品が貰えるという話を聞いて参加してきました。

結果は聞くまでもないかんじでしたが、普段は話せない役員の方々とお話ができたりと、いい取り組みだなーと思いました。

また来年も参加しよう。

プロダクトオーナーシップ勉強会 05

第5回。9章から11章まで。

参加している方々から、実際にこういうことをやってみたとか、そういう話が聞こえるようになってきた!!1

毎回耳が痛い感じなんですが、それ相応の成果は出てきてるんじゃないかと思えてきました。

新卒研修の導入としてワークショップをしました

ペパボの新卒研修については、昨年CTOがLL Diverで発表しましたが( GMOペパボのエンジニア新人研修 #lldiver - delirious thoughts ) 今年はさらにパワーアップして様々な取り組みを行っています。その詳細についてしかるべき時にしかるべき人が発表すると思いますので乞ご期待という感じなのですが、その中の一環として、見積りと計画づくりの話をしてほしいと言われたのでワークショップ形式でやってきました。

ざっくりと見積りや計画づくりについて説明しながら実際にやってみるという流れで打ち合わせをしていたのですが、話をしていくうちに「チームビルディングがいるな!」と思ったのが先週の金曜日。最終的な成果物や、特定の方法論に価値を見出すのではなく、大事なのは「チームづくり」「計画づくり」という活動なんだというのを強調しようと、「1つの型」という表現にしたのも先週金曜日。さらに、今朝は歯医者で虫歯の治療をして、ひょっとして始まるまでに麻酔が切れなくて変なしゃべりかたになってしまうのではないかとドキドキしながら本番を迎えたのですが、なんとかそれなりのかたちにはなったのではないでしょうか。

ちなみに、見積りと計画づくりの題材は Ruby on Rails Tutorial で、これは数年前に同じような状況で一度失敗している(とまでは言わないけど上手くできたとは言えない感じだった)ので、そのときの経験も活きたのは間違いないですね。

自分としては及第点は取れたと思っていますが、受講者からしたらそんなことなかったかもしれないので、そのあたりのフィードバックが得られてからまた詳細を整理しようかと思います。

こういう依頼が来たのも 第1回ペパボテックカンファレンスで見積りと計画づくりについて発表しました - けんちゃんくんさんのWeb日記 の発表があってのことなので、こういう方向性で押していっていいのかという葛藤はありますが、アウトプットのフィードバックが回っていていい気分です。

Android M Developer Preview

スパイダーモデルのNexus5にAndroid Mのプレビュー版を入れて数日経過しましたが、Twitter公式アプリがとにかくよく落ちるという点を除いて不自由なく生活できています。

前回の障害だったヤマダ電機アプリも元気に動いています。

たしかにバッテリーの持ちは良くなったかな?という印象がありますので、ローカルのデータがふっとんでもいい人は試してみるといいのではないでしょうか。

2FAの解除やバックアップコードの確認は忘れずに。(Herokuのバックアップコードを紛失してログインできない状態になっています…)

プロダクトオーナーシップ勉強会 04

完全に書くのを忘れてたけど第4回があった模様。6章から8章まで。

GH:Eの社内勉強会リポジトリを見たらこの日からログを取るようになったみたい。

cloud-initのper-xxxまとめ

cloud-initのper-xxxについて調べたのでまとめておきます。

per-xxx について

cloud-initは /var/lib/cloud/scripts 内にあるスクリプトを、cloud-init起動時(インスタンスの起動時)に実行します。この中には以下の3つのディレクトリがあります。

  • per-once
  • per-instance
  • per-boot

これらのディレクトリに 実行権限のついたファイルを置いておくと それぞれのタイミングで実行されます。

per-once

per-onceは、マシンイメージに対して1度だけ実行されるスクリプトを置いておきます。実行されたかどうかは /var/lib/cloud/sem の下にファイルがあるかどうかで判断されます。

ポイントは、/var/lib/cloud/scripts/per-once にファイルがあったかどうかや、新しいファイルがあるかどうかといった点は 考慮されない ということです。

cloud-init入りのベースイメージから、packerでちょっとした細工をするといったケースの場合、このpackerでマシンイメージを作成したタイミングでper-onceが実行したことになってしまうので注意が必要です。

実際の使いどころは…今の私には思いつかないので誰か教えてください…

per-instance

per-instanceは、インスタンスに対して一度だけ実行されるスクリプトを置いておきます。実行されたかどうかは /var/lib/cloud/instance/sem 以下のファイルで判断されます。

/var/lib/cloud/instance というディレクトリは /var/lib/cloud/instances/#{instance-id} というディレクトリのsymlinkになっています。インスタンスからスナップショットをとってそこから新しいインスタンスを起動した場合などは、instance-idが別になるので再実行されるという仕組みになっています。

なお、EC2だとスナップショットから上手く動かないという記事をいくつか見たのですがOpenStackでは問題なく動きました。「per-onceのsemファイルを削除して再実行する」といった類のハックは必要なさそうです。

実際の用途としては、社内のOpenStack基盤だと各々云々の事情で初回のインスタンス起動時にネットワーク関連の再起動が必要になっているので、そのスクリプトを置いておく場所によさそうです。

per-boot

per-bootは、インスタンスの起動の度に実行されるスクリプトを置いておきます。

監視に仕組みやクラスタに入るためのブートストラップなど、そういうのに使う感じでしょうか。

まとめ

per-onceの具体的なユースケースをお待ちしています。

歓迎会

お手伝いしてるサービスに新しい方が来たので歓迎会でした。今週は2庄屋でフィニッシュです。

AEP読書会に参加しました

藤村さんの地道なリクルーティングのおかげか、急に人がたくさん来て買い出し班は大変でした…

本編では、有識者がPOとSMになっての寸劇などもあり、みんな楽しめたんじゃないでしょうか。

寸劇の内容は、「チームがここまでできると言ったところまでできなかったことに不満を感じたPOに対してSMはどう対応すればよいか」ということがテーマだったのですが、やっとむの迫真のPOと、お酒がはいっているけど真面目に対応するSMという構図がこの会をよく表わしているなーと感じました。

プロダクトオーナーシップ勉強会 第03回

社内の有志で行っているプロダクトオーナーシップ勉強会の第3回でした。

3章から5章で資料は公開されてないっぽいのでおしまい。

飲み会

会社の飲み会で1回休み。

Testing Casual Talks #2 で負荷テストについて発表しました

負荷テストそのものの詳細はペパボテックカンファレンスでおいちゃんが発表した資料 EC performance testing // Speaker Deck を見てもらうとして、そのテストの裏側というか、負荷テストすると言ってもそれなりに準備しないと上手くいかないし結果を活用できないよね、という普通の話をしたくて発表してきました。

テスト計画とかシナリオの作成とか、それぞれのトピックで話したいことはあったんですが、1つに絞るとしたらやっぱり実際のデータをちょっとでも見せられて視覚的にも派手な分析と考察のところかなーと思って、そこに絞った内容にしてみました。

恐らく一定の規模のアプリケーションを運用しているところは何らかの方法で負荷テストって実施してると思うんですよ。けど、なかなか表に出てこない部分のように感じているので、少しずつオープンにしていけるといいなと思っています。

同じような悩みを持っている人、知見を共有しましょう!

Testing Casual Talks #2 : ATND

チームで合意を取ること

大事なんだけど、合意をとる「何か」はちゃんと誰かが自信と責任をもって考えてほしいんだよな。それが正しい必要はないけど、状況の整理とそれに基づいた判断の根拠くらいは。

決められないからチームに相談することが適切な場合はあるけど、状況の整理が足りなかったり、単なる責任逃れだったりすることもあるんじゃないかな。

そんなことを Inspired を読みながら考えてた。

細竹

実家から送られてきた細竹をそろそろ処理せねばと思って一気にやりました。

1ロット目の新聞紙を開けたときに土みたいなのが入っていたのですがとくに気にしないで処理をはじめたら、最初の一本の一番外側の皮をむいたら芋虫状の何か(まだ生きてる)が出現し、気持ちを落ち着けるために暫く休憩をしました。

そこで気付いたんですよ。土みたいなやつは糞だったんですね…で、量的に1匹じゃないだろうなと思って念入りに調べながら皮をむいていたのですが、結果としてもう2本ほど穴の空いたあやしいやつがあったのでそのままゴミ箱行きにしました…

2ロット目はだいぶ上手に、しかも早くやれるようになったのですが、このスキルが有効なのはおそらく年1回程度なんですよね…

で、さすがに自動化されてるだと思ったらやっぱりあったので共有いたします。めっちゃやりたい。

社内プロダクトオーナーシップ勉強会02を開催しました

今回は、私がまとめ資料をつくってそれを30分くらいでざーっと見ながら気になったところをコメントしていく、後半で社内のコンテキストも含めたディスカッションをする、というような形で進めてみました。

自分含めて8人のプロダクトマネージャーっぽいロールの人やそういう動きが期待されている人があつまってわいわいできたのでよかったです。

デザインを変更しました

前のデザインは モバイル フレンドリー テスト でモバイルフレンドリーではないと言われ続けていたので、Githubの Primer を使ってちょっとだけデザインを変更しました。

モバイルフレンドリー認定されたので満足です。ただ、Adsenseの広告が大変残念な感じになっているのでまた後日なんとかします…

ヒューマンエラーを仕組みで防ぐこと

仕事でそういう話をしていて、もやもやしたので考えを整理しておく。

リスクとコストを正しく評価する

ヒューマンエラーをシステムや仕組みによって防ぐといっても、全てのエラーが起きないようにするのは、網羅性とコストの面から不可能ではないかと思う。

つまり、ヒューマンエラーのリスク(原因となる作業の頻度と発生した場合の影響)と、それを仕組み化するコスト(構築と維持)を正しく評価した上で、費用対効果のよいものから対応していくことになる。

このあたりは 自動化するときに考えること - HsbtDiary(2015-05-03) で述べられている考え方にも繋がる。

ただ、これとは少し違うポイントとして「普通はそういうことはやらない」とか「注意すればいい」という思考があると考えている。

仕組みでヒューマンを守る

そういった考え方は、そっくりそのままそれを仕組み化すべき理由になる。

これらの思考はリスクとコストを正しく評価することを放棄しているのと、それが起きてしまったときにその言葉がそっくりそのまま「発生させた人」に返ってしまうのが問題である。

つまり、その人は「普通はやらないことをやってしまう」「注意力がない」というラベルづけされるかもしれないし、そうでなくても本人は罪悪感に苛まれてしまう。(もちろんチームメンバーはフォローするだろうが、仕組み化されてないのが悪くて私はまったく悪くないと言いきれる人はそうはいないのではないと思う)

つまり、仕組み化はデータやシステムを守るだけではなくて、ヒューマンを守るという目的もあるように感じる。

ヒューマンエラーを仕組み化で防ぐことを考えるときは、リスクとコストを客観的でかつ定量的に評価するのが重要で、そこに「普通は」とか「注意すれば」といった主観的で定性的な評価を含めるべきではないのではないだろうか。

在宅勤務訓練デー

災害発生時など在宅勤務せざるおえない状況でもスムーズに業務ができるように訓練する日でした。

いつもの通勤時間の間に洗濯したり布団干したりできるのは便利なので、通勤時間短くしたい欲が高まることに。

プロダクトオーナーシップに関する社内勉強会をはじめました

社内のとあるPOの人から「PO力高めたいんです!手伝ってください!」と言われたので、世間一般で言われているようなPOの経験なんて微塵もない私がなぜか勉強会をセッティングすることになりました。

POStudy 〜プロダクトオーナーシップ勉強会〜 のサイトや参加者の方々のブログとかを見て、まずは Inspired日本語版 | How To Create Products Customers Love を読みましょうということで、初回の今日は「はじめに」と1章の途中までを読みました。

本書では沢山のマネージャや責任者のようなロールが紹介されるのですが、自分達の組織だとその役割は誰がやっているんだろうという疑問や、必要だと思っているけど足りてない面などが明らかになってきて、開発チームの人と話しているだけでは見えないことが見えてくるのは面白いですね。

ただ、だいぶふんわりした感じになってしまったので、次回からは章毎に担当を決めて、まとめ資料をみながらディスカッションしていくというかんじで進めていこうと思っています。

電車に忘れた携帯電話が戻ってきたので知見を共有します

2週間前に割れたNexus5を総武線に置き忘れたところ、本日無事回収できましたので知見を共有いたします。

紛失する前にしておくべきこと

ロックは当然のことながら、必要であれば端末の暗号化やリモートでデータを消去できる仕組みを入れておきましょう。

ロックについては、古い記事ではありますが Androidのロックパターンの解読にFBIが投了!Googleに素直にアカウントとパスワードを聞く | あんどろいどスマート という話もあるので、利便性と強度を考えるとパターンロックが無難じゃないかなと思います。

紛失したらすること

Android デバイス マネージャー にアクセスして、端末の状態を確認しましょう。ネットワークに繋っていれば現在地がわかります。

Android Devise Manager

ロックと消去は実際に行うかどうかは迷うところです。とくにロックは

  • パスワードでのロックに変更される
  • メッセージや連絡先を表示できる

という一長一短の機能ですので、実際に使うかどうかは迷うところではないでしょうか。

当然ですが、ロックや消去はネットワークに繋っていないと効果がありません。デバイスマネージャに甘えずに、十分な強度のロックと暗号化はしておいたほうがいいでしょう。

また、利用しているWebサービスの2FAをかたっぱしからOFFにして、重要なアプリケーションはパスワードの変更やセッションの切断などをやっておくとよいでしょう。

もちろん、会社にも忘れずに連絡しておきましょう。

警察に届けられた携帯はどうなるのか

グーグル先生や教えてgoo、知恵袋などによると、犯罪や悪用の恐れから、紛失した携帯電話を直接受けとるのは多少難易度が高いようです。

私の場合は忘れたのが電車の中とわかっていたので、JRの方に何度か連絡してみましたが当日中には見付からず、翌日以降は何回か電話してみましたが落とし物センターが混んでいてまったく繋がらなくて諦めムードでした。

そんななか、事件が起こりました。

これはどういうことかというと

  • JRから警察に届けられる
  • 警察からキャリアに問い合わせがいく
  • キャリアから契約者に連絡がくる

というルートで、SIMがささっている携帯電話が届けられた場合はほぼ確実に契約者に連絡がくるという仕組みらしいです。(電話だったりメールだったり書面だったりするようです)

ちなみに、Nexus 5には IIJmio のSIMを差していたのですが、IIJからメールが来たので3キャリアじゃなくても大丈夫なようです。

あとは、その連絡の中に保管されている場所と受取番号が記載されているので、そこに行けばOKです。電車に忘れた場合は飯田橋にある遺失物センターに集められるようですが、13時過ぎに行ったところ5人待ちで15分くらいで終わりました。

オチ

私の場合、最初にJRに電話して見付かってないことがわかった時点で、デバイスマネージャの位置情報がとれなくなっていたのでリモートで消去を実行していました。しかし、実は電源が切れていただけで、受け取ってから電源を入れてネットワークに繋がったタイミングで、持ち主の目の前で消去が始まるという衝撃的な結末が待っていました。

2015/04に読み終えた本

今月は諸事情により通勤中の意識が極めて低い状態にあったのでvimの本を再読したり、去年セールでの価格設定ミス(?)で運よく購入できたスレイヤーズ全巻を読んだりしていた。

shucreamの本棚 - 2015年04月 (2作品)
実践Vim 思考のスピードで編集しよう!
Drew Neil
読了日:04月30日

【全巻セット】スレイヤーズ 全15巻セット〈豪華特典版〉
神坂一
読了日:04月30日

powered by booklog