今年、この話を何度か別々の人にすることがあってずっと纏めようと思っていたのだけど一年が終わってしまうので来年の自分のために今書いてしまう。 目新しいことは何一つ無いのだけど、大切なことだし、意外と社会人になってしまうと教えてもらえないことも多いみたいなのでここでまとめる。 表題のこと、つまりやりたいことを実現するために必要なことは、そんなに難しいことじゃなくて以下の条件を満たし、実行することが大事だ。 やりたいこと=課題をタスクに分解する タスクを実行できるだけのリソース（時間・お金・体力など）を割り当てる 実行する これだけなんだ。仕事だってなんだって一緒なんだけど、だけどこれを日常的に実現することが難しい。 だからどうやって実現していくか？って説明のために、自分がやってることを書く。 課題を整理する 仕事と作業は違うという話がある。 トヨタでは最初にそれを教わるらしい。 www.har

先日のAmazon SQSの障害には色々と肝を冷やした人も多いのではないでしょうか。 classmethod.jp 今回のようなケースとは別に障害は大小あれど、みなさん日々戦っていることだと思います。 障害対応はエンジニアの花形であるものの、サービスに対する知識やソフトウェアの知識など経験と技術の両方が必要です。 そのため、どうしてもトラブルシューティングはエースエンジニアなどの一部の人に依存してしまう…などの問題が発生しがちです。 そこで今日は私の経験から障害対応のいろはを書いて行きたいと思います。 今回のスコープの外 実際に障害時の具体的な対応、例えば障害切り分けやRDBMSのボトルネックの探し方などの話はしません。 まずissueを作ると良い 本題です。 トラブルを認知したらまずはissueを作りましょう。 issueを作るときはtemplateが事前に設定されていると便利です。 g

AWSで大きな障害が発生したこの機会に、自分がクラウドと正しく付き合っていくために必要なことを考える。 piyolog.hatenadiary.jp ちなみに稼働率 99.99% くらいを目指していくために必要な事を考える。 必要な稼働率を見極める 今回は 99.99% くらいを目指すと言ったが、実際に自分たちにとってどのくらいの稼働率を目指すか？ということはとてもとても大切だ。 幸い、今回自分は影響がなかったが、本当に完璧か？と言われるとそうではない。 まず弊社の場合、マルチリージョンではないので東京リージョンが落ちたら落ちる。 これを許容できない場合に99.99%を目指せるか？というと正直厳しい。 しかしサイトの規模はそんなに大きくないのでデータサイズも現実的に転送出来る範囲で、コンポーネントも少なく、TerraformやAnsibleによって再構築しやすい状態は整っている。 そのため

前回から更に半年経ったので振り返る。 soudai.hatenablog.com 前提 今は株式会社 オミカレって会社でCTOをしてる。 オミカレは婚活パーティーのポータルサイトで、男女問わず、幅広い年齢をカバーした婚活パーティーを取り扱っている。 party-calendar.net もうサイトとしては8年目で息の長いサービスとなっており、レガシィなところも目立ってきた。 それを払拭するためにチーム、サービス、ビジネスの3本柱をメンテナンスしてるフェーズ。 この半年は前回のまとめに書いた通り、大きな目標が2つあった。 自立型のチームとして確立する 売上をしっかり伸ばす それを踏まえて、振り返りをしていく。 10月 スマホアプリがリリースされた。 春からずっとここに標準を合わせて、アプリケーションの設計やらプロジェクト管理やらAPI作成やらしてたので無事出たことに驚きと共に、そんなに大きな

って話をPHPカンファレンス仙台でします。 そこでいつもどおり事前に資料を共有します。 ここに書いてる通り、モニタリングを始めたい人、悩んでる人は入門監視を読んでほしいです。 私がこのCfPを出す前は発売されると知らず、登壇直前に発売されるという登壇者殺しのタイミングでしたが、登壇前に買って読んで本当に良かったです。 スライドにもあるのですがパターンであったり、数値の見方だったり、私がMackerelのCREの時に学んだこと、自分たちの監視を見直す為に必要なことは書いてあります。 本当は前回からもう少し進んで登壇内容はデザインパターンだったり、アーキテクチャの監視の話だったりを話すつもりだったのだけど、それは入門監視を読めば解決するので具体例を出すことにしました。 これくらいなら自分たちも始めれるのでは？みたいな気持ちにアプリケーションエンジニアがなってくれることがゴールです。 私自身、こ

って話をPHPカンファレンス2018でしてきます（1時間後に過去形になります って話をPHPカンファレンス2018でしてきました。 2018/12/16時点で動画とFAQの内容を追記しています。 phpcon.php.gr.jp 当日の登壇資料はこちら。 当日の動画です www.youtube.com ※ 5:41:20 くらいからが僕の動画です。 ※3ヶ月以内を目処にセッション毎に割ってくれるみたいです 内容補足 Webサービスは成長と共に変化していくので、つまりは変化に強いチームというのは重要になります。 では変化に強いチームとはどうやってつくるのか？って話が今回のテーマです。 チームビルディングってとても重要なのは周知の事実だけど、じゃあどうやって？って言うHow toは意外と語られません。 それは「答えが無い」ってのもありますが、プレイヤー目線とマネージャ目線（経営者も含む）で大き

4月からオミカレに戻ってきて半年たった。 ちょうど今月が期末だしこの半年を振り返る。 soudai.hatenablog.com party-calendar.net 4月 CTOになった（1年と3ヶ月ぶり 2度目) オミカレを離れている間の事をキャッチアップするのに心血を注ぐ感じだった。 1年ぶりに読んだプロダクトコードは機能もコードも1年で随分育つというか驚きのレベルだった。 「男子三日会わざれば刮目して見よ」というがプロダクトコードも同じである。 変更点と新たに生まれた課題点の整理をするためにかなり時間を使った。 それと並行して運用フローの見直しであったり、体制変更に伴うツールの選定、移行などをやった一ヶ月だった。 その結果、課題はかなり整理できてこの半年～1年で何をやるかを整理できた。 前職でJOIN直後はやりたい放題するチャンスと学んだので4月の後半からはドラスティックな運用フロ

って話をbuilderscon 2018でします。 builderscon.io 当日利用する資料はこちら。 speakerdeck.com 私のセッションはbuildersconの最終セッション。 皆さん素晴らしいセッションが並ぶ中で選択肢に迷ってる方も居ると思います。 だから先に公開しておきますのでこれをご覧になって、他のセッションに行くというのも有りだと思います。 あと事前に去年のトークを見てくれると当日はより理解が深まると思います。 同じ話を2回しても皆さんにとって勿体無いのでリファクタリングの細かい前提の話は当日はしません。 soudai.hatenablog.com 動画はこちら。 www.youtube.com これを見て、面白そうだなって思ったらぜひ、遊びに来てください。 僕が知ってるRDB設計、そしてRDBの歩み方を全てお伝えします。 あなたの新しい道の一歩目をご用意しま

新しいキーボードきた pic.twitter.com/2lS5LtOENr— そーだい@初代ALF (@soudai1025) June 18, 2018 REALFORCE R2 「PFU Limited Edition」 | PFU 元々5年くらい、functionキーを結構使う＋カーソルキーじゃないとvimが使えない軟弱者なのでHHKBでは無くRealforceをずっと使っていた。 なんの不満も無く、壊れることなく使い続けていたのだけど周囲から「うるさい」とクレームが入ることが多々あった。 そんなに打鍵強くはないと思っているのだけど、Realforceは結構カタカタ言う。 ミーティング中とかに議事録とったり内職したりするとかなり目立つ。 なので静音のRealforceを試してみたのでそのレビューを書く 静音は本当に静か 自分で聴く分にはカタカタという音はリズムを生むしすごく好きなんだ

言語の勉強会でその言語の話をしない人ランキング堂々の第一位、そーだいです（当社比 控えめに言っても最高な毎度おなじみ #kichijojipm で今日LTする話の補足です。 kichijojipm.connpass.com speakerdeck.com タイトルは出落ちです。 全然最強じゃなくて頑張ってやってるよって話です。 資料がかなり薄いので補足します。 DBリファクタリングについて 26Pは現状です。 MySQLって書いてますが本番はAurora1を使っています。 以降、このDBを 現行DB と呼びます。 ここではオミカレとみんなの婚活はWebサービス名です。 つまり2つのサービスから現行DBを見ていますし、機能によっては現行DBの同じテーブルを参照・更新・削除などを行います。 この2つ以外にも社内システムなどでこの現行DBは利用されており、メインのテーブルを変更すると影響範囲が広

はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録

GithubのカンバンツールであるGithub Projectsはリリースされて1年以上経っている（2018/04/10現在） 僕が当時、使えるかなって思って試した感想は下記の人とほとんど同じような感想だった。 qiita.com 以下、引用。 projectページ内でissueを作成することができないことも率直に不便を感じた :thought_balloon: issueをcloseしたり、PRがmergeされたら自動でclosedのカラムへ移動してほしい。 「自分の担当issueのみ進捗管理したい」などのニーズは容易に想定できるので、projects内のフィルタリング機能がほしい 上記に対して改善しているポイントを述べていく。 Projectsの中で作ったカードをissueに登録できる 該当のカラムの中でカードを作ることが出来る。 これはissueとは別の独立した存在でissueには登

PHPerKaigi 2018でタイトルの登壇をしてきました。 phperkaigi.jp 登壇内容は下記の通りです。 speakerdeck.com 伝えたいことはスライドに大体あるし、勘所については過去のブログでもまとめています。 soudai.hatenablog.com 昨今のWebサービスは外部のサービスと連携し合うのは当たり前ですし、自分たちのサービスが違うサービスによって影響を受けたり、影響を与えたりすることも当たり前になっています。更にサービスは常に機能を追加・変更・削除することで進化しているのですからモニタリングの対象も常に変化しているはずです。ですのでWebサービスとしてどのようにあるべきかというところがモニタリングの勘所となります。もう少し説明するとサービスはServerに紐付いていないがシステム全体に影響するメトリックもありますよね？それも勿論モニタリングしましょう

manabusakai さんの下記の記事を読んだ感想。 blog.manabusakai.com Twitterにも書いたけど僕は信頼されるエンジニアをずっと目指してきたし、そのために僕に必要なことがここには詰まっていた。 ほんとみんなに読んでほしい。 このエントリーの中の信頼を得ているエンジニアの姿を引用する。 有言実行である 仕事の納期をきっちり守る どんな仕事でもムラがない 困ったときに快く相談に乗ってくれる 皆がやりたがらないタスクを拾ってくれる チームの雰囲気を良い方向に導いてくれる etc... まさに。 ではソフトウェアエンジニアとしてこの他に当たり前にやるべき事って何があるだろう？ ソフトウェアエンジニアとしてやるべき事 僕らは技術で問題を解決することで価値を高めたり、対価を頂いている。 例えば使っているOSSにバグがあったらどうだろう？ これは自戒をかなり含むが不満をSN

Geeks Who DrinkとPostgreSQL Conference Japan 2017での資料です。 nulab.connpass.com PostgreSQL Conference Japan 2017 (2017-11-03) | 日本PostgreSQLユーザ会 詳しく知りたい人は下記の本がおすすめです。 ただし注意点は9.3相当なのでプロセスの仕組みがちょっと違います。 待望の新刊出ました！10系ベースなのでぜひ読んでみてください。 ※2018/10/07 追記 読み応えのある内容になったかなと思います。レベル感で言えばOSS DB Goldの試験出る範囲です。特に内部構造は覚えて置いて損は無いでしょう。 speakerdeck.com 内部構造の中で取り扱っていないところにAUTOVACUUM、TOASTとレプリケーションがあります。AUTOVACUUMはPostgre