まっしろけっけ

めもてきなやーつ

Web CM に出た話

はじめに

既に公開されて一ヶ月経ってしまったのだけれど、ジョージアの Web CM にでたので、そこら辺の話を書いていく。
前職の時に TV 番組や TV CM にちょっと映ってる程度のことはあったのだけれど自分がメインで CM に出るとか初だったので色々面白かった。

そもそもなぜ出ることになったのか？

上記の経緯で社に話が来て、なんやかんやあって自分になったので出ることになった。
最初に聞いたときはコカコーラの CM かと思ったらコカコーラ社のジョージアの CM だった。

当日の様子

撮影日は 4/1 だったので実はエイプリルフール的なアレだったりするのかもしれないなどと考えていたのだけれど実はそうではなかったらしい。

社内で撮影準備が進められている中で、撮影始まる少し前にプロデューサー(？)っぽい人と話たりリハーサル的に質問に答えたりしたのだけれど下記のようなことを言われた

  • この CM をみた人がソフトウェアエンジニアっていう仕事に憧れるようなものにしたい
  • どんな流れで質問するか？みたいな奴を事前に渡してはいるけど特に気にしないで聞きたいことがあれば聞いてもらっても良いし自然な感じでやってほしい
  • 事前のリハーサルでこのタイミングで二人にこれ聞いてみましょう的な話(サーバって知ってますか？とかの逆質問)

こんな感じのことを話したような気がする。

いざ撮影開始なのだけど撮影現場に行った時に「後藤さんは入りま〜す」パチパチ(拍手)みたいなのをやってもらい TV とかでみたことあるやつや って感動した。

CM みて貰えばわかるんですが、マジで久しぶりにあんなに緊張したなというほど緊張した。(登壇とかの比じゃない)
その結果リハーサルの時に言われたことは全て頭の中から消え失せてしまっていて、今思い返すと自分でも笑える。

飯尾さんも R 指定さんもすごく優しく、また言葉のチョイスとかがマジで凄いなって思った。
撮影の合間も気を使って貰って色々話しかけてくれた。

実際の CM について

www.youtube.com

この中で話している 仕事をしているというよりは遊びに近い感覚 というのは、以前から社内で 1on1 とかやってる時にも何人かには話してたりするので本当にそういう感覚なのだけれど誤解して欲しくはないのは遊びに近い感覚だからと言って真面目にやっていないというわけではない。

最近も 5 年後の minne のエンジニア組織をどうするか？みたいな資料を作ったり、インフラのコスト削減をやったりなどを真面目にやってる。

プロとしての自覚も誇りも持っているので、自分の仕事はきっちりこなしたいと思っているし自分がやると言った仕事に関しては基本的にやりきっている(はずで)だからこそ周りからエンジニアとして信頼して貰っていて今の CTL という職位を任されていると思っている。

それにサービスが成長しなければ自分の楽しい遊び場がなくなってしまうので、より良いものをユーザに提供し多くのユーザに使ってもらうことでそこで発生する新たな問題を技術で解決していくというサイクルに入るためにも事業の成長を技術的にどう推進していけるのか？ということも考えている。

最後に

貴重な経験ができて楽しかったです。基本的にやったことないことはとりあえずやってみるかという精神で生きているので CM 出演の件もやって見てよかったなと。

普段あまり接点がない社の人と話ができたりもあったのでよかった。

公開日の午前中に友達に発見されて LINE で晒されたのでインターネットは凄いなって思いました。

EKS の pod で mackerel-container-agent を動かして監視する

kubernetes mackerel 開発

はじめに

EKS is これ

で最近 EKS を触ってアレコレしてるんだけどそのアレコレの一つで mackerel-container-agent 導入してメトリクスを収集するというのがあった。

僕が所属している GMO ペパボでは mackerel をかなり使っていて mackerel 上で一括して見られると便利なので入れた。

EKS なら CloudWatch とかでも取れるのかもしれないけれど、僕がやっている minne というサービスは OpenStack と AWS のハイブリッドなので mackerel に集約されるのが便利なのでした。

導入する

だいたい下記に書いてある。

mackerel.io

上記のマニフェスト例にあるように下記のような yaml を用意する

apiVersion: v1
kind: Pod
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  serviceAccouontName: sample-serviceaccount
  containers:
  # ...
  - name: mackerel-container-agent
    image: mackerel/mackerel-container-agent:latest
    imagePullPolicy: Always
    resources:
      limits:
        memory: 128Mi
    env:
      - name: MACKEREL_KUBERNETES_KUBELET_READ_ONLY_PORT
        value: "0"
      - name: MACKEREL_CONTAINER_PLATFORM
        value: kubernetes
      - name: MACKEREL_APIKEY
        value: <Mackerel APIKey>
      - name: MACKEREL_KUBERNETES_KUBELET_HOST
        valueFrom:
          fieldRef:
            fieldPath: status.hostIP
      - name: MACKEREL_KUBERNETES_NAMESPACE
        valueFrom:
          fieldRef:
            fieldPath: metadata.namespace
      - name: MACKEREL_KUBERNETES_POD_NAME
        valueFrom:
         fieldRef:
            fieldPath: metadata.name

EKS で ここ に書いてある AMI を使用すると --read-only-port が無効な状態になっているので MACKEREL_KUBERNETES_KUBELET_READ_ONLY_PORT を指定する必要がある。(他にも --read-only-port を有効にして AMI を作成することも可能で https://github.com/awslabs/amazon-eks-ami の issue を漁れば方法がわかるかと)


また、後述する serviceAccountName も設定しておく。

次に RBAC を設定する。
mackerel の document の RBACの設定例をそのまま適応した後に下記の ServiceAccount の yaml を作成し apply する

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sample-serviceaccount

これで監視ができるようになります。

最後に

RBAC も MACKEREL_KUBERNETES_KUBELET_READ_ONLY_PORT の指定もしてるのにうまく動かんので EKS に対応してないのか？と思い twitter で呟いたところ中の人から助言を頂き感謝です。



結局 deployment で serviceAccouontName を指定してなかっただけっていう落ちだったのですが...

犬をお迎えして 2 年経った

はじめに

2017/04/14 にお迎えして 2 年も経ってしまった。
4 ヶ月経って書いた以前の記事は下記

shiro-16.hatenablog.com


今でも、金曜日に有給とって空港までお迎えに行って、飛行機が遅れてて空港でワクワクしながら時間潰してたことや
その後にリムジンバスで渋谷に向かってる最中とかを鮮明に覚えてる。

何よりこの 2 年間毎日可愛いって思ってるのでヤバい。
散歩も週 3 ~ 5 回行ってるけど毎回楽しいのでヤバい。

一時期診察してもらったら先天性の病気かも？となった時もあったけど結果病気ではないとなったので幸いずっと元気で過ごしている。
今回もこの 2 年でわかったお金について知見を書いて行きます。

費用

前回の記事でもまとめましたがその後にかかった費用などを誰かの参考にまとめておきます。

まずは我が子のスペック

1 年単位でどのくらいかかるか？という感じでまとめて行きます。

食費(メイン)
  • ドックフード 2 種各 3kg 6000 円

2 種類にしているのはその方が毛並みがよくなった気がするので 2 種類を合わせて食べさせています。
この計 6kg のドックフードを 4 ヶ月で食べきるので一年だと

6000(円) / 4(ヶ月) * 12(ヶ月) = 18000 円

が 1 年でかかっています。

その他の食費(おやつ)
  • 1000(円) * 12(ヶ月) = 12000 円

おやつ代は完全に飼い主によってどの程度あげるか？が決まるので参考にならないと思いますが我が家では(たぶん)このくらい

トイレシート

800枚入りのペットシート一年半前に買ったのですが、未だに半分以上残っているという状況なので一年で半分消費したということにします。

  • 4000(円) / 2 = 2000(円)
病院代

ここ半年くらいは具合が悪くなったりも全くないので定期的に病院にいくとかはないので、必ずかかる費用のみを出します。
これは完全にお薬のみの価格なので診察料などが別途かかると思います。(1000 円くらい？)

まずは混合ワクチン(1 歳からは年 1 回)

  • 約 10000(円)

次に狂犬病ワクチン

  • 約 4000(円)

フィラリア予防薬(4 ~ 12 月くらいまで月 1 回)

  • 約 1000(円) * 9 = 9000(円)

フィラリア検査(年一回)

  • 約 3000(円)

ノミ/マダニ予防薬(4 ~ 10 月くらいまで 3 ヶ月に 1 回)

  • 約 3000(円) * 3 = 9000(円)

ということで病院代は合計で下記のようになります。

  • 10000 + 4000 + 9000 + 3000 + 9000 = 35000(円)
おもちゃ代

これもおやつ代と同じで完全に飼い主によってどの程度あげるか？が決まるので参考にならないと思いますが我が家では(たぶん) 1 年でこのくらい

  • 5000(円)
合計
  • 18000 + 12000 + 2000 + 35000 + 5000 = 72000(円)

だいたい我が家はこんな感じになっているようです。
病院代に関して上でも書きましたが診察料などは含まれていませんので実際はもう少しかかりそうです。
また、 1 年目は不妊手術などもあり 10000 円くらい(？)はかかるかと思います。

洋服とかを着せたりする人はもう少しかかるかもしれません(うちでは着せてないのでよくわからない)

その他にどうしても旅行や出張などで犬を預けないといけない場合はペットホテル代がかかって来ます。
我が家では一泊約 4000 円のホテルを利用しています。


こんな感じの費用が毎年かかります。まとめてみると意外にかかってるんだなというのがわかりました。
犬の大きさによって食費や薬代等は割高になってくるでしょう。

最後に

なにかで犬は 12 ~ 15 年くらいしか生きられないつまりは人間の 1/6 しか生きられないということで、人間の 6 倍速で一生が過ぎていくというのを見たんだけど
つまり僕が 1 時間遊んであげたら人間換算で 6 時間遊んだと同じくらいの楽しさを犬は得られるのでは？という考えになって少しの時間を割いて遊んであげても全然苦ではないなと思うようになった。(思うようになったと言っても元々苦には思っていなかったのだが)

家の壁紙を剥がされたりもしたけど、犬と生活するのは楽しいよ

ということで我が子の写真が大量にあるリンク貼っときますね
www.instagram.com

Cloud Native Meetup Tokyo #7 で登壇して来た

開発 プログラミング ツール kubernetes Telepresence

Cloud Native Meetup Tokyo とは

cloudnative.connpass.com

Cloud Native に近しい技術や CNCF がホストするプロジェクトについて共有し合う会です！

昨今はコンテナ関係のエコシステムが大量に増えてきましたが、それらの技術検証結果などを発表しあう?場として利用していきたいと思っており、仲間を募集しております。

CNCF の公式meetupに認定されました

とのこと

登壇経緯

f:id:shiro-16:20190401123821p:plain

と発言したら社で Cloud Native Meetup Tokyo の運営の手伝いをしている r_takaishi (@r_takaishi) | Twitter から下記のような誘いがあり


f:id:shiro-16:20190401123827p:plain

となった
この間約 4 分

会場

会場は前職の新オフィスの Abema Towers だったので初潜入して来た。
エレベータ乗ってたらレスラーとカメラマンが乗って来て

  • これは AbemaTV の撮影だろうな
  • 話題のラグビーっぽいな

という二つの感想が出て来てなんか大変そうって思いました。
新しいビルは綺麗だったな〜というのと 200 人以上はいる広いセミナールームはやはり良いな〜という感じ

登壇内容

speakerdeck.com

Telepresence という k8s 環境ではかなり便利なツールのお話
日本語の資料や記事がほとんどなくだいたい公式とソース読んで検証してたのでそれで得た知見を書いた。

内容は資料を読んでもらえればという感じ

とりあえず試したい人は下記のリポジトリとかで試せるようになっているはず
github.com

その他の内容

社で一緒に k8s への移行をやってるアルパカさんの内容
移行時の平行運用期は consul 連携できるのマジで便利なんですよ。

docker image 配布に関しての問題を解決する色々なツール群のお話
image size を小さくする以外のも確かにいろんなやり方あるよな〜と勉強になった。

最後に

楽しかった！！１

Rails Girls Tokyo 10th でコーチして来たお話 #railsgirlstokyo

雑談 開発 プログラミング rails

はじめに

なんでコーチやったのとかは下記を参照

shiro-16.hatenablog.com

上記の記事が初コーチの回でそれから 5 回ほどコーチをやっているので進め方とか気づきを書いておこうという気持ち

気づき

人数のお話

基本的には複数のチームに別れてワークショップが進行していきます。

  • チームの人数はコーチ/Girls合わせて最大で 10 人くらい
  • コーチ対Girls の比率は 1:2 もしくは 1:1 になるように調整されている

僕は過去 5 回で前回だけ 1:1 であとは基本 1:2 だったのですが、前回 1:1 を初めて体験した感想は圧倒的に楽というものでした。
1:2 の時は終わった後に疲れきってもうダメだ〜という感じでしたが 1:1 の時は 1:1 はこんなに楽だったのか〜という感想

最近だとそういうコーチへの負担も加味してか 1:1 になるようにコーチの人数が多くなっている気がするので良いことだと思います。

進行のお話

やる内容は Rails Girls - Japanese に沿ってやっていくのだけれど、進め方は割とチームによってバラバラになります。

大きく分けて 2 パターンあって

  • チームで一緒に進んでいく
  • 個々人が自分のスピードで進んでいく

これは良し悪しがあるかなと思っていて僕が考えるメリット/デメリットはこんな感じ

チームで一緒に進める

メリット

  • Girls 同士のコミュニケーションが取りやすい
  • チーム間が出る

一緒に進めているので Girls 同士のコミュニケーションとかもしやすくなってチーム間出るのかな？と思う(勝手な想像)

デメリット

  • 誰かが少し遅れると心理的に良くない

進めている中で誰かが詰まったりしてしまうと、その人を待つことになるのですがその場合その人は焦りが生まれてしまうだろうなと
その日にあったばかりのチームのメンバーに待ってもらうという状況は待たせている側からするとプレッシャーを感じてしまったりすると思われる。

遅れている人は誰かコーチがつきっきりで対応し、チームは先に進むという選択をしてもそれはそれでプレッシャーになるだろうな〜という気持ち

  • 質問がしづらい

学校の授業で手をあげれない人がいるようにみんなに注目されている中で話せない人もいるんでは？とか
こんな質問していいんだろうか？みたいな気持ちになることがあるかもしれない

個々人が自分のスピードで進んでいく

完全にチームで一緒に進めるの対比になるのですが

メリット

  • 個々人で進めるので他人の進捗がそこまで気にならない

他人の進捗は多少は気になるでしょうが、自分が遅れているから誰かを待たせているという感じにはならないのでプレッシャーを感じることは少なくなりそう

  • 質問しやすい

1:1 なら全員の前で何かを聞くという感じにはならないので質問しやすいのでは？

  • 理解できたかどうか？を判断しやすい

これは完全にコーチ目線なのですが、チームで一緒に進める場合は進行役の人がいてその人が説明するのですがその説明が理解できているかどうか？という反応を Girls 全員分把握するのが大変というか無理。普段から大人数に技術のことを教えている訳ではないのでそんなスキルは持ってないんですよ...
1:1 であれば相手の反応によって理解できたか？できなかったか？というのは割と会話から察することが可能だったりするので、察してもう少しわかりやすい言葉を選んで説明を行うという深堀ができると思っています。

僕としてはせっかくエンジニアに興味があって参加してくれたので、よくわからんかったのでエンジニアとか無理〜となって欲しくはないので理解できて楽しかったので次に繋げようと思って帰ってほしい。

デメリット

  • Girls 同士のコミュニケーションが取りにくい

個々人でが〜と進めているのでコミュニケーションは取りにくいのかな？(という想像)

  • チーム間が出ない

個々人で進めるのでチーム感があるのは自己紹介やお昼ご飯とか休憩の雑談くらいですね

最後に

という感じで過去 5 回くらいで感じたことをだらだら書いてみた。
僕個人としては個々人が 1:1 ないし 1:2 の状態で進めていく方が Girls がちゃんと理解できているか？というフィードバックを得られ自分自身のちゃんと教えられたという満足感も得られるので良いなと思いました。

過去 5 回で総じて感じるのは未経験、特に仕事でもエンジニアと接点がない人に技術的な説明をするのは大変で普段当たり前のように使っている言葉をそういう人たちにわかるように言語化するというのは説明することに対してしっかりとした理解が無いと出来ないのでコーチの人々は偉いな〜と思っています。
僕は(Girls の方がどう思っていたかは定かでは無いですが)前回でやっとちゃんと教えられた〜と納得いく説明ができるようになったなと感じました。(その後のアフターパーティの途中からひたすら障害対応をしてたのでやりきった感が 0 になってしまったという辛い思い出もありますが...)

あくまでメリット/デメリットとかは僕が Girls の立場だったら〜という想像でしかないので実際はわかりませんよ

第25回Elasticsearch勉強会「検索編」 #elasticsearchjp に登壇した話

Treasure Data elasticsearch mysql web 開発

はじめに

www.meetup.com

こちらのイベント

こんな適当なことをつぶやいたら Elastic 社の @johtani さんからお誘いがあって登壇する流れとなったのでした。

Elasticsearch 勉強会はスライドでも触れている solr から Elasticsearch に移行した前後で 2,3 回くらい参加したことがあったという感じ

資料はこちら

speakerdeck.com

発表者は 3 人だったのだけれど Elasticsearch で検索ということだから話す内容被らんかな...と心配だったのだけれど、全員いい感じに内容が違っていてよかった。

twitter でも盛り上がっていたようで、発表後の質問も懇親会での質問もいっぱい貰えたのでよかったよかったという感じになった。

最後に

僕は現在は検索のことに関してアレコレやっている訳ではなく、
最近は資料にある辞書管理のシステムを作ってくれた若者が頑張っているので次はその若者がなんか喋ってくれるはずです

1on1 をやってる(やる)話

雑談 開発

はじめに

minne では CTL と各エンジニアで 1on1 を月一でやってるんですが僕は少し前まで web 側の CTL をやっていたので web アプリケーションの開発を行うソフトウェアエンジニアの各位と 1on1 やっていたんですよ。

で下記のような事件があったんで web 側とかなくなってただの CTL として生き始めたのでモバイルエンジニアとの 1on1 もやり始めるぞい < イマココ

hisaichi5518.hatenablog.jp

1on1 の目的とか

だいたい下記のスライドに書いてあって新しく入社した人にも下記のスライドがやる目的です〜って共有している(ひさいちくん便利)

speakerdeck.com

これからの話

モバイルエンジニアの人々はひさいちくんと 1on1 をやっていたのでモバイルエンジニアの各位が将来に対してどんなビジョンを描いているか？とか細かいことは知らないのでとりあえず教えて貰いたいなと思って下記のような文章を用意した。


モバイルエンジニアの人々(mataku 以外)は shiro16 と 1on1 をするのは初になります。
1on1 によって皆さんがエンジニアとして成長するための手助けをしたいと考えているので、まずは皆さんがどのような目標を持っているのか？を教えて貰いたいと思います。

1on1 ではその目標に最短で辿り着くために今抱えている課題に対してどうアプローチすればいいか？という内省が出来るようにサポートできればと考えています。

【質問】(短期的/長期的どちらでも)エンジニアとしてどうなりたいか明確なビジョンがある場合はそのビジョンを明確ではない場合はざっくりとしたビジョンでもいいので書いてください

例1) shiro16 倒す
例2) シニアになる
例3) なんかよくわからんけどとりあえず凄くなる
その他...

モバイルエンジニア向けの文章になっているけど、web の人々も同じようなことをもう一度問う予定

なぜこのようなやり方をやろうと思ったか？

ペパボにはエンジニア職位制度というものがあり上位の職位には誰でも立候補が出来たりするんですが、ちょうどその時期でシニアエンジニアとして相応しいかどうか？は CTL みんなと面談して決めると言うことになっておりその面談を通して思うことがあってという感じ。

思うことというのは 1on1 をやっている中でエンジニアとして明確な目標を持って 1on1 に望む人はその目標に近づくためにどうすべきか？ということに悩んでいたりするんだけれど、僕が少しサポートをするだけでこんなに変わるのかと思うくらい振る舞いがとてもよくなったという経験があったのでビジョンを持ってそこを目指してもらおうと思った。

ぼんやりとしたビジョンしかないという人に関しては 1on1 を通してぼんやりとしたビジョンをより明確にするサポートをしていければと思っている

最後に

1on1 の話とは関係ないんだけど僕自身も上の職位を目指す上で現シニアプリンシパルの人々とは専門とする領域が違っていてその領域が好きだからもっとやっていきたいと思っているのだけれど、
その領域の違いの明確な言語化とその上でその違いを伸ばす努力をせんとな〜といい刺激を受けた期間だった。