読者です 読者をやめる 読者になる 読者になる

そーだいなるらくがき帳

そーだいが自由気侭に更新します。

YAPC::Kansai で RDBアンチパターン その2 について話してベストトーカー賞を取ってきた #yapcjapan

f:id:Soudai:20170304140140p:plain

YAPC::Kansaiでトークしてきました。

yapcjapan.org

RDBアンチパターンの話してきました。
去年、PHPカンファレンスRDBアンチパターンの話をして盛り上がったのでそれの第二弾です。

b.hatena.ne.jp


speakerdeck.com

僕が伝えたい事はたったひとつ。
このブログを読んだらすぐ自分たちのサービスのバックアップとリストア手段確認してください!
お兄さんとの約束だぞ!!

このトーク応募したらGitLab.comが大事故起こしたり、S3が落ちたり世の中では大変そうでした。

www.publickey1.jp

ヒューマンエラーとかあるんですよほんと。
僕もいっぱい見てきたし、やったし(ぉぃ
なので本当にもうこれだけは絶対確認してほしいって思います。
実際に「バックアップ無いDBをバグで飛ばしたんですけどどうすればいいですか?」とか相談来ます。
ほんとサービスごと会社が無くなる話なのでみんな頼んだぞ!

YAPC::Kansaiの話

本物のやぷしーに参加したのはこれが初めてでした。
Perl書かないしって今まで参加してなかったけど結論、最高でした。
そもそもPerlの話も面白かったし、Perlじゃない話も面白かったですね!!
前夜祭からぶっ飛んだ話いっぱい聞けたし、すごい人たちとお話出来るってホント幸せでした。
なにより自分はアプリから下のレイヤー好きなんだなぁって再確認も出来たのが良かったです。
あと「はてな」って言うPerlの会社に居ることの幸せとか、Perlの人たちのUNIXに対する想いとか、色んな学びがあったイベントでした。

思い残すことがあるとすればベストトーカーになれなかったことですね…
本家ベストトーカーの称号欲しいので機会があればまた参加したいですね!!

ベストトーカー賞とったどー!!

まぁ最高なこととPerlを書くことは別なんですけどね。

地方のエンジニアこそPaaSやSaaSを利用すべきって話をしてきた

今日はブログ更新頑張るDayです。
米子にイケてるPHPのイベントがあったので参加した時の話です。

speakerdeck.com

ちょっとslideの補足書きます。

Webサービスのインフラ

地方の受託開発だとまずはレンサバ。
それを前提にレンサバの責務を超えるとVPSを借りてサービスを作るのが一般的ですよね。
でも自分たちでちゃんとVPSをメンテナンスするの大変だって話を沢山聞きます。
レンサバはよく出来たPaaSでインフラ部分を業者側がメンテしてくれます。
それと同じようにメールであったりDNSもPaaSに任せましょう。
どんどんPaaSの肩に乗って楽をしましょうってのが1章の話です。

運用と監視

受託開発だとこの2つはコスト部門だからと言って無視してませんか?
本当に良い受託開発はユーザの課題を解決し、サポートパートナーとして寄り添うことだと思います。
だからこそリリースした後の事もサポート出来る仕組みは大事ですよって話をしました。
ここでは例えばお客さんが何らかの理由でデータをぶっ飛ばした。
その時シュッと復旧できればその顧客は一生のお付き合い出来る関係が築けますよと話をしました。

そして年単位の時間が経った後に問い合わせ来ることってありますよね。
その時に歴史を残して置くことってめっちゃ大事です。
特に開発時の歴史を残すって大事だし、作業時の粒度とかも目に見える形にすることが大切です。
そういうところでGitのSaaSを使うと便利ですよって話をしました。
あとちょっとだけカンバンの話もしました。

監視については提案って何にも無いところからは出来ないですよね?
そのために毎日の変化を見ましょう。
それによって予兆に気づけるようになるんですよって話をしました。
Mackerel ってヤツがおすすめです(ステマ

mackerel.io

運用の自動化

エンジニアのリソースはどこも足りてないですよね。
だから効率化、簡略化が大事でそういうために自動化しましょうって話をしました。
まずはPHPはリリース関連を自動化するのが簡単なのでオススメですって話題をしました。
あとエンジニアとしてオススメは社内の事務作業の自動化しましょうって提案しました。
エンジニアリングでまずチームを助ける。
それって要件も工数もシンプルなのでシュッと手を付けれるし、それすらリソースが無いならチームとしてヤバイです。
なので若い人、ぜひぜひ社内の色んなバックオフィスの自動化とかしてほしい。
それが必ず仕事の受託開発にも活きてきますよって内容でした。



エモい話も多かったのですが懇親会では「良かったです」ってお声をいただけたりして嬉しかったです。
あと米子、酒も飯も上手いし最高なのでみんなも遊びに行きましょう!!

Webサービスが成長するとロックで苦労する話をしてきた

気がつけばもう3月。
毎月、ブログを書こうと思っていたのにいきなり2月で挫折しました。
でも過去を振り返っても仕方ないので気持ちを入れ替えて登壇報告です!!

第19回中国地方DB勉強会 in 米子とMySQL Casual Talkで登壇しました。

speakerdeck.com


# 第19回 中国地方DB勉強会 in 米子
dbstudychugoku.github.io

# MySQL Casual Talk
togetter.com

ロック、苦労しますよね。
しかもここでは紹介しませんでしたが粒度としてはここで話したのはHeavyweight Lockの話なのでもっと下のレイヤーも絡みだすと泥沼です。
でもハードの力を使い切ることはエンジニアの腕の見せどころでもあると思います。
このへんの話、苦労話は多いけどじゃあどうやって打開したか!?みたいな話は少ないので機会を見つけてアウトプットしたいなって思います。
次回のMySQL Casual Talkも楽しみです。


※引用元

ロック制御 - PostgreSQL Internals

  • Heavyweight Lock

- ユーザー(DBA)から見えるロック
- テーブルロックなどに使用。pg_locksビューから確認可能

  • Lightweight Lock

- ユーザー(DBA)から見えないロック
- バッファのロックなど、内部的なリソースのロックに使用

  • Spinlock

- ユーザー(DBA)から見えないロック
- CPUやメモリなどの超短時間だけ使用するロック
- CPUやメモリ操作のAtomicityやConsistencyを担保するロック

ちなみに今回の中国地方DB勉強会が自分がJPUGの中国支部長として開催する最後のイベントでした。
今後の中国支部長は @ikkitang くんが引き継いでくれます。

twitter.com

僕が先輩方から頂いたバトンを次の世代に渡して成長を促すターンになったかと感慨深い気持ちです。
新たな体制の元、今後の中国地方DB勉強会もお楽しみに!

早くチームにマッチするために気をつけてる事

新入社員として1週間が過ぎた。
ブルックスの法則的に考えても私はまだチームにとって生産性をマイナスさせる存在でしかない。

ブルックスの法則 - Wikipedia

だからいち早くチームにとって必要な存在になる必要があるし、そのために気をつけてる事をメモする。
これを見て「もっとコレした方がいいよ」ってアドバイス、逆に「それは不要だよ」ってアドバイスを期待してる。

チームやプロダクトを好きになる

これはとても大切なことだ。
嫌いな人とは仲良くできないし、嫌いなプロダクトは育てれない。
もし、コレを読んでる人が職場のチームもプロダクトも嫌いなら転職した方がいい。
ただ好きの反対は無関心なので無関心の場合は条件付きでやっていけると思う。
この辺の話は主旨が変わるのでまた別の機会があれば話したい。

コミュニケーションについて

新しいチームに合流してまず一番大事なのはコミュニケーションコスト。
自分が入ることで文化や背景を知らないと理解できないコミュニケーションが成立しない。
これによって説明であったり、言葉の置き換えによるコスト増が増える。
特に説明するコストは馬鹿にならない。
多くがユビキタス言語とか整理されてないだろうし、定例ミーティングの目的・手順なんて纏まってない。
しかしそれでもドキュメントになってたり議事録はある。
なのでまずは事前にドキュメント化されてる事は目を通すようにしている。
特に説明を受けているときに「これ、後で読んでみてください」と言われたことに関してはできるだけすぐ目を通してる。
なぜなら後にすると絶対に読まないし、そもそもそのドキュメントの存在も忘れる。
完全に暗記する必要はないと思ってて「そー言えばあそこにアレがあったな」と次回のときに確認する場所を覚えておくイメージ。
まさにインデックスみたいな。

とは言えそれでも度々ハイコンテクストなコミュニケーションによって理解できないことが発生する。
そこは素直に「わからないので教えてもらえますか?」と割り込みになっても聞くようにしてる。
これは「まぁ多分こういう意味だろうけど自信ない」みたいな温度感でも聞くようにしてる。
なぜなら自分の推測は文化も背景も共有できてない状態での推測なので確度が低いから。
幸いチームメイトは聞いたら即答してくれるし、場合によっては二歩先くらいまで説明してくれる。
この辺はチーム文化が素晴らしいなと素直に感激するところ。
あと中途採用だと期待されるポテンシャルが相応に有るだろうし「わからないと言うのが恥ずかしい」って感情はわかる。
しかし「聞くは恥だが役に立つ」って言うしマネージャの時の経験上、わからないままのほうが圧倒的にリスクが高いので聞く。
そりゃ「そーだいさん、こんな事もわからないんですか?」って思われるかもしれないしそれによって一時的に評価が下がるかもしれない。
でもそれによって将来的な生産性が上がればいいし、チームにとっても「初めての人にこの辺はわからない」という学びになる。
この学びは次の新たなチームメイトにつながる学びだし、それを自分がメモしとくとより良いと思う。
実際には先人である id:a-know さんの入社時のメモとか大変助かった。
入社の事務的な手続きがすぐに終わったのはその辺の準備のお陰だ。
これ書きながら自分はメモしてないし何も残して無いことに気付いたので後ほど残して置こうと思う。

あとは積極的にレビューを依頼するようにしてる。
例えば普段はOSS界隈で何となくやってるissuesにしても書いたらちゃんとレビュー依頼を出す。
勿論書き方や情報の過不足について指摘が貰えるし場合によっては知らなかった運用を知れたりする。
これは私がCTOのときも大切にしてて、レビュアー側の立場だったがこれによって多くの知見をお互いに共有するタイミングになったので良いと思う。
特に最初は双方にレビューに対する精神的障壁が少ないので積極的に活用すべきだ。
勿論これによってレビュアーのリソースを奪っている事は間違いない。
なので

  • 文書の推敲を怠らない
  • レビューに必要な情報も事前にまとめる
  • まとめて確認出来るように依頼すべき内容はまとめて依頼する
    • 数が多い分野はレビュー会の時間を設けさせてもらってる

文字にすると大それた事書いてるような感じになるけどまとめると

  • 事前にドキュメントを読む
    • 特に指示されたドキュメントはすぐ読む
  • わからない事はわからないと素直にすぐ聞く
  • 報連相大事

に集約される感じだ。

チームメイトをリスペクトする

当たり前の話だが歳を取った中途採用だと難しいなと思う。
例えば年下でも上司なら敬意を払いやすいだろうがチームメイトに新卒の子が居たらどうだろう?
どうしても社会人の先輩として強く出てしまいがちではなかろうか?
しかしこのプロダクト、チームに置いては新卒であっても先輩である。
むしろ弊社は新卒は例外無く超優秀で日々学びの塊のような存在である。
そんな人達をリスペクトしないのは人間関係以上に自己研鑽としても勿体無い。
またコミュニケーションというのは感情が非常に大切で好意を抱いている人の言葉というのは素直に受け止めやすいものだ。
そして不思議なことで自分が好意を抱いている人は相手も好意を抱いてくれやすい。
他者に対して敬意を表する事は立場や年齢が増えても忘れてはいけない。
増えるほど、頭を垂れる、白髪かなである。

積極的に話かける

弊社にはまかないランチがあるので積極的に知らない人に話しかける。
それこそ他チームのデザイナーや営業の人と機会なんてなかなか無い。
だからこそ交流をはかることで会社に対する理解も深まるし、他業種に対する理解も深まる。
これはコミュニケーションに活かされる事が多くて自分の領域と隣り合うインターフェイスの事は知っておくとお互いの説明コストなどが下がる。
なので逆に自分の事も積極的に覚えて貰えるようにアピールしてる。
アピールと言っても会話の中で自分の事を話だけでなく、すれ違ったときに挨拶するとか何かお願いする時やお礼を言うときに相手を褒める一言を添えるとかそんな些細な事で良いと思う。
そういう積み重ねが良好な人間関係を気付くと信じている。

あとがき

私がマネージャの時は優れたプレイヤーでも本来の力を発揮するには3ヶ月かかると見積もっていた。
なのでまだ一週間とちょっとなので焦る必要は無いと思う。
しかし人というのは欲深い生き物で出来ることならすぐにでもフルパワーを出したいし、それが楽しい仕事にも繋がる。
何よりプロダクトやチームを好きになればなるほど貢献したい気持ちが出てくる。
そういう気持ちを落ち着かせるためにもこのエントリーを書いた。

既に月曜日が待ち遠しい。

MacOSのFileVaultを利用時に複雑なパスワードを利用するとログインできない

ドハマリした上に情報が少なかったのでメモ。
MacOSに標準搭載されているディスクの暗号化機能であるFileVault。

support.apple.com

盗難事故時などのデータ流出防止のために利用することあると思います。
利用するとディスクは暗号化され、ログイン時に復号して利用するようになります。
このときにタイトルの通り、複雑なパスワードを利用しているとログインできなくなります。
具体的には

複数回記号を利用するようなパスワード

はログインできなくなります。
これが例えば

  • 業務用PCなどでAppleIDを登録していない
  • FileVaultの復号化パスワードをメモしていない

場合は完全にログインできなくなります。
また単純な再インストールもHDDが暗号化されてできなくなるため

という手順になるためデータは完全に失います。
私はクリーンインストールはこちらを参考にして行いました。

itea40.jp

MacOSについては最近色々とソフトウェアの問題が話題に上がりますが初めて私も刺さりました。
この場合は下手すると類似事案で泣く程度では済まない場合もあるので周知されてAppleが対応してくれるとうれしいですね。

Microsoft MVP for Data Platformを受賞しました

1月1日にMicrosoft Most Valuable Professional for Data Platformを初めて受賞しました。

taketomo sone (soudai)

プロフィールは画像がうまく反映できなかったり、詳細の改行がうまく反映出来てないのでちょいちょい直していきたいと思います。
そして僕のイメージとしてMSってイメージが全く無いとは思います。
正直、僕自身も驚きの受賞です。
でもそういうOSS側の人が受賞するのが近年のMSの本気を感じます。
今後は先人が築いてきたMS MVPブランドに貢献出来るように頑張っていきたいと思います。

Azureとか頑張っていこ(*´ω`*)

株式会社はてなに入社しました

f:id:Soudai:20170104185546j:plain

あけましておめでとうございます。 2017年1月1日付で株式会社はてなに入社しました。

はてなに入社するということでやっぱりはてなブログに移行しました。 そーだいなるらくがき帳は移行出来たらします。

はてなにはMackerelのセールスエンジニアとしてジョインしました。

なぜ「はてな」なのか

WebサービスのスタートアップのCTOを辞めてなぜ「はてな」なの?という疑問があると思います。 理由としては勿論前職を離れるのに良いタイミングだったってのも大きいのですが

  • PostgreSQLがそこにある
  • セールス部門でチャレンジ出来る
  • エンジニアの全体のレベルが高い

などです。 でも1番はMackerelチームに一緒に働きたい人が沢山いるって言うのが大きいです。 そして広島から東京に転居してまでチャレンジしたい価値がMackerelにはあると思っています。

初出社日の所感

初めての東京転居(まだしてないけど)も重なってかなり緊張しました。 が本当にアットホームに迎え入れてくれました。 また初日のオリエンテーションを終えた感想としては企業としての誠実さとかWeb企業としての文化とか感心する部分が沢山ありました。 初日からこれなので明日の出社も楽しみです。

どんなvalue出していくか

中途採用でジョインしたわけですからそれ相応のvalueを求めらます。 Mackerelのセールスエンジニアとして自分なりのvalueを出していきたいと思ってます。 セールスエンジニアの先輩として id:a-know さんがいます。 築いていただいた「はてなのセールスエンジニア」の型も大事にしながら自分の経験を活かしていきたいと思います。 具体的には

  • コミュニティとアウトプット
  • SREに本当に必要なモノの提案
  • レスポンスの良さ

なんかを大切にしていきたいと思っています。

まとめ

今年は自分にとっても会社にとっても飛躍の年にしたいと思っています。 これから「はてなのそーだい」としてどうぞよろしくお願いします。