リンケージのCTOになって2年が経ったので振り返って3年目について書く。 前回 soudai.hatenablog.com やってきたこと 1年目は開発組織の立て直しと社内の新規事業の開発 2年目の前半は採用と後半は既存事業のリプレース 3年目は採用と組織の向き直りとビルドアップ 1年目 開発組織の立て直しと新規事業の開発の両方を同時にやるってことでなかなかハードだったが仲間に恵まれ無事リリースできた。 その時から開発しているFEMCLEは今もガンガン成長していて、今後はリンケージの柱となる事業の一つ。 ちゃんとローンチできて良かった。 femcle.linkage-inc.co.jp 仲間に恵まれた、という点でいえば採用がうまく行っているのがめちゃめちゃ大きい。 リンケージはPHP界隈で最強のチームだ、と言っても過言じゃないと思っている。 何よりも素晴らしいのは平均レベルの高さ、それ故に

中国地方DB勉強会 in 岡山の登壇資料です。 そのうちここで登壇動画が公開されることでしょう。 肝心なチートシートは以下のとおり。 PostgreSQL gist.github.com MySQL gist.github.com チートシートだけじゃわからない！困ってる！ Have Fun Techがバージョンアップのサポートしますのでお気軽にご相談ください。 have-fun.tech まとめ やっぱ中国地方DB勉強会は最高だぜ！

文脈、背景や問題点の説明 マルチテナントを実装するうえで企業情報（以下company）単位で最小限の情報を扱うようにしたいがcompany単位にTableを作ったりDatabaseを作るのはALTERなどの運用が大変。 そこでRLSを採用するために実際の技術検証をした上での注意点と実際の運用について必要な情報をまとめる。 PostgreSQL 14を前提としている 公式ドキュメント CREATE POLICY 必ず一読はすること。 困ったとき、わからないときはまずは公式ドキュメントを都度見ること。 このドキュメントのゴール RLSの概要をつかめる RLSの最低限の注意点を理解し、実装時に罠を踏まない 自分たちでRLSのポリシー自体をメンテナンスすることができ、デバッグできる テーブル構成 create table if not exists company ( id uuid defaul

クライアント先の社内ポエムだけど必要になることがあったので転記した。 @nekoya さんにお願いしたらそちらも公開してくれた。:圧倒的感謝: @nekoya さんの話がとても良かったので僕もポエムを書いてみる。 zenn.dev 僕もその昔はもちろん駆け出しのエンジニアで自信が無くて自分を低く見積もったり、ある程度自信があっても 謙虚であることが美徳 と思って自分を敢えて卑下するなんてことをよくやっていた。 脳ある鷹は爪を隠す、なんていうけど確かに周囲に低能力だと思われていたほうが便利なシーンもあるにはある。 しかし少なくとも社会で働く上で 自分の能力を適切に評価する ことは自分にとっても会社にとっても重要なことだ。 その前提の上で、自分を過小に評価することは、あなたの仕事の成果に対して高評価し、認めてくれている人たちにとっては裏切り行為と言える。 例えばとても良い仕事をしたのにも関わら

最近、この説明を複数回したので記事にする。 要約 普段は 今北産業 派なのだが、3行考えるのが面倒なため、今後は大人の表現を使う。 「今北産業」をスタートアップ語にすると「マジ価値サマリー」になるらしい ちなみにここだけの話ですが、大人語にすると「要約」になります pic.twitter.com/Q8SflvBX7c— ところてん (@tokoroten) 2022年1月24日 画面に表示したい順(以下、表示順）は振る舞いの属性なので分ける 似たような振る舞いに関わる属性は別テーブルにわけると良い 普通に正規化しましょうって話。 表示順をカラムを追加して表現する よくあるテーブルは画面情報と合わせて表示順カラムがあるパターン。 こういうテーブルを作って SELECT * FROM items ORDER BY display_order_number; で表示順に取り出すパターン。 表示順

判断と決断の話の違いはこのツイートの通り。 判断の話で言うとぼくはそーだいさんがしてくれた「判断と決断は違う」という話がだいぶ実になっていて、「情報を集めれば理屈で答えが出せるのが判断、今は情報を集めることができない中で答えを出さないといけないのが決断、リーダーがやらなければならないのは決断」という話をかなり大事にしている— しんぺいくんさん (@shinpei0213) 2021年12月10日 決断のコツ 結論から言えば、決断のコツは失敗できるようにすることだ。 失敗できる状態なら決断することができる。 そして素早くアクションして、失敗のフィードバックを受け取ることで新しい決断をすることができる。 そーだいさんがぼくに教えてくれた二大大事なこと「判断と決断は違う」と「ロールバック可能なことはどんどん試せばいい、ロールバックが難しいことは慎重に」です— しんぺいくんさん (@shinpei

ついに始まりました。Mackerel プラグインアドベントカレンダー(全部CRE） の1日目です。 qiita.com soudai.hatenablog.com それでは早速1日目は mackerel-plugin-linux です。 mackerel-plugin-linuxはLinux専用のプラグインであり、Linux使いの方は必須とも言えるプラグインのご紹介です。 github.com インストールと設定手順 名前の通り、Linux専用のプラグインですので他のOSについては今回は考慮に入れません。 mackerel-plugin-linuxはプラグイン集として提供しているパッケージの mackerel-agent-plugins に含まれています。 そのため公式の手順で簡単にインストール出来ます。 mackerel.io インストール先は /usr/bin/mackerel-plu

とある企業の内部ポエムとして空き時間で書いたのだけど、「これは公開してほしいです！」って強い声が読者からあったので公開します。 ほぼ、そのまま転記です。 前提：自分について 36歳 Webアプリケーションエンジニア枠でZaffiで業務委託してます 既婚で子供が3人居ます 広島出身です 大学生ですが休学しようか迷ってます おっさんに人気者、そーだいです。 ここでいうおっさんというのは概念であり、実年齢に相関はありません 若者からは何デキる人がわからんが、怖いおっさんおるなと思われてるのかな～と危惧しています 若手だった当時の思い出 若手向けってことでそーだいさんの事知らないだろうし、昔話するのはダメな大人ってわかっているけど、我慢して聞いてくれｗ 自分は公務員からの転職組、つまり中途採用組なので新卒時代がなかった。 つまり、誰から研修などないし、教えてもらうという経験がほとんどなかった。 そ

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

はてなからの依頼により、新リリースのタグ機能をさっそく使ってみる。 今回のテーマは「エンジニアのキャリア」ということで、以前にも書いたが、考えてみると自分のキャリアはコミュニティと共にある。 特にデータベース界隈のコミュニティで存在感を示したことが、その後のキャリアアップにつながった。 じゃあコミュニティでどうやって存在感を出してきたんだっけ？と考えると、それは表題につながるのだが、やはり登壇だ。 YAP(achimon)C::Asia 2016とYAPC::Kansai 2017でベストトーク賞、Builderscon 2017ではベストスピーカー賞をいただいたし、PostgreSQLカンファレンスやPHPカンファレンスには何度も登壇している。 大きなカンファレンス以外にもOSCで地方を巡業したり、自分で勉強会を開催したり、とにかく登壇量が多く、その内容で評価してもらった結果、自分の存在

書籍「Engineers in VOYAGE 事業をエンジニアリングする技術者たち」が発売された。 まだ読んでいない人がいるなら兎に角オススメなので読んでほしい。 先日も少し話題にした業務委託でお手伝いしている会社、VOYAGE GROUPの主要な各事業を作ってきたエンジニアたちにフォーカスしたインタビュー集だ。 「そーだいさんはVGの人と仲が良いから底上げ評価でしょ？」と思う人がいるかもしれない。 もしあなたがレガシィコードと戦う現場で悩んでいるなら、大小関わらずプロダクトを作り、事業と共に歩む人なら自信を持ってオススメできる。 また今からエンジニアを生業として生きていこうと思っている人たち*1にも自信を持ってオススメできる。 そして、ソフトウェアを軸とした事業を作っていきたい人、関わっているエンジニア以外の人たちもぜひ読んでほしい。 ソフトウェアでサービスを作る際に大事なことが沢山読み

オミカレを退職して独立し、そして半年が経った。 2月に独立したが、新型コロナによっていろんなことが変わった影響も踏まえつつ、振り返りをする。 前回 何やってるの？ VOYAGE GROUPとの関わり Classiとの関わり サブスレッドとの関わり ユースタイルラボラトリーとの関わり 残りの会社は？ ウィルポートとの関わり 半年経ってわかったこと やはり働き過ぎる オフィスは必要 リモートワークで上手くいくには信頼貯金が必要 休息は大事 次の半年へ 前回 soudai.hatenablog.com 何やってるの？ 多くの人の疑問に答える形でいうとWeb系事業会社のお手伝いをしてる。 具体的な仕事は以下のようなタスク。 チームメンバーとして実際の開発の関わる アーキテクチャの設計やレビュワー チームビルディングや改善のフォロー 何でも相談役 受託開発 これらを常時でいうと5社くらいでやってて、

リモートワーク、テレワークが本格的に始まって1ヶ月以上経った人も多いのでは無いでしょうか。 自分は2月から独立してほとんどをリモートワークで過ごしてきましたが、その中で大事だなと学んだ知見を共有していこうと思います。 作業環境は大事 そーだいなる環境 静音キーボードがオススメ ネットワークは本当に大事 会社は積極的に支援すべき 買ってよかったリスト フットレストがあると疲れが違う ペンタブがあるとテレカンが捗る 毛づくろいの会話が大事 雑談するトリガーを増やす 気軽に雑談出来る場所を増やす リモートワーク交流会の開催 オンラインだと繋がりが偏る 関係する線を増やす 進捗は全てを解决する 適切な問題設定が大切 まとめ 合わせて読んでほしい 作業環境は大事 まず一番大事なのは作業環境です。 どこまで投資するか難しい…って気持ちもわかります。 しかし緊急事態宣言は延長され、会社のリモートワークも

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

突然だが、私はコミュニティが好きだ。 その中でも地方コミュニティが大好きだ。 昨日、今日と地方コミュニティ主催のイベントで登壇してきた。 www.sakurajima-house.tech osh-web.github.io オープンセミナー広島では表題のこと、前エントリーのこと*1について話をしたのでそのスライドも見てほしい。 コミュニティは新しい出会いを与えてくれるし、成長するため環境を用意してくれる。 そのコミュニティというエコシステムの中で成長するということはどういうことだろうか。 それについて少しだけ、想いを綴りたい。 地方のコミュニティで成長できる 私はコミュニティに育てられた。 それなりにデータベース界隈、Webエンジニア界隈では知名度がある方だと思うし、エンジニアとしての問題解決能力も高い方だと思う。 その上でもう少し補足すると私は 地方のコミュニティ で育った。 今は確か

2020年も始まりました。 2019年、色んなチャレンジを通じて成長を感じる反面、 35歳定年説を考えたりする程度には 心技体の限界を感じたりもしました。 しかし周囲の叱咤激励や自分自身を振り返ってみる *1 と、結果的に小さくまとまってしまい、爆発的な成長に必要な大きなチャレンジが出来てないという結論になりました。 これは弊社の恵まれた環境や東京と言う立地、コミュニティの方々の多くの支援を受けている現状の縁によるものが大きく、感謝しても感謝しきれないほどありがたいことなのだけど、そこに甘えるにはまだ早いなと考えています。 だからこそ2020年は自分自身の積み重ねたモノを一度リセットするくらいの覚悟で大きなチャレンジをして行きます。 そこで今日はその大きなチャレンジを抱負として明記し、宣言の力によって前に進む覚悟を決めたいと思います。 今北産業で頼む そうだ、大学に行こう オミカレを退職

先月、35歳になった。 35歳定年説は「全員に一致する法則ではない」というのは一般的な認識になっている。 前職の同僚で同世代である id:motemen に聞いたところ「そんな事を意識したことなかった」という回答をもらったこともある。 しかし、実際に自分が35歳になると「自分は他人事ではない」という感覚だけがある。 そこで今日はそのことについて考えていきたい。 コードを書くということ コードを書くという行為は年齢関係なく続けていける。 しかし「仕事でコードを書き続ける」となると事情が変わる。 まず費用対効果として自分がコードを書くことが正しいのか？という問題とぶつかる。我々のプログラマーとしての仕事を奪うのはAIではない。いつの時代も 優秀な若者 だ。 そんな若者と比較した時、我々がコードを書くことが若者がコードを書くことよりも費用対効果がある場合はどんな場合だろうか？やはり経験が活かせる

34位でフィニッシュ。 isucon.net 棄権を合わせると予選突破に200イスコインちょっと足りなかった。 ハイスコアは9850だっただけにあと1つなにかできれば予選を突破できてたことになる。 当日の流れは id:sugyan さんが用意してくれてるのでそっちを読んでほしい。 memo.sugyan.com ここからはただただ、自分に対する反省をまとめる。 主な担当であるインフラについての反省 準備したつもりでも準備不足だった。 複数台構成、普段RDSやALBに甘えている弊害が出て、Nginxやアプリケーションの複数台構成のやり方を知っているが普段していないので詰まったって感じ。具体的にはMySQLに接続できなくて時間をかけた。 あとnginxのチューニング、特にルーティングで配信をまとめるみたいなところもかなり時間をかけてしまった。 普段、S3とCFにURLをすれば良いって感じで生き

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

かっちゃん（id:katzchang） の記事を読んで思ったことをつらつらと書く。 medium.com 前提 今はオミカレという婚活パーティーのポータルサイトのWebサービスをメインにしている会社でCTOをしている。 CTOといっても会社の人数は15人未満でエンジニアは自分を入れても8名しかいない。 だから厳密なマネージャ職はおらず、CTOと名が付いているけども自分がCode書くなどのプレイヤーの仕事をしながらエンジニアやプロジェクトのマネージメントを兼任してる。 オミカレ party-calendar.net 婚活パーティーやお見合いパーティー、街コン、趣味コンといったイベントのポータルサイト。 自社でイベントなどは行わずに、主催されている方々からの情報提供を受けてサイトに掲載している。 そもそもプレイングマネージャーはアンチパターンでは？ これは常日頃から思う。 何をマネージメントす