PHPカンファレンス関西懇親会で若者に「俺だってソフトウェアエンジニアの才能が無いかも…と悩んだことあるよ」って話をした。 そんな悩みを持っていたのは自分が25 ~ 26歳くらいの頃で自分はエンジニアとしてスタートが遅かった（異業種転職組）から、技術力の無さを痛感しながらも、それを才能の理由にしようとしていた。 続けるために必要なのは才能ではない 悩んでいるとき、飲み会で当時の同僚で先輩の @maepon さんに相談した*1ところ、次のことを言われた。 自分が「才能ないかも」と言ったあとに帰ってきた言葉は「もし、お前に才能が無かったとして、じゃあお前はどうするんの？そのifの中に実装があるの？何も無いんだったらそのifについて考える時間は無駄じゃん。必要なくない？」って感じ。 確かに才能が無かったとして、じゃあソフトウェアエンジニアを辞めて別の仕事したいってのがあるなら考えればいいけど、当

私は登壇芸人と呼ばれる程度にはそれなりの数を登壇している。 そーだいなる2017年のアウトプットを振り返る - そーだいなるらくがき帳 そーだいなる2018年のアウトプットを振り返る - そーだいなるらくがき帳 2019登壇とか主催とか.md · GitHub そんな私も最初から出来たわけでは無く、数多くの失敗の結果、今のスタイルになった。 そこでその失敗を共有し、誰かの参考になれば良いと考え、筆を取った。 失敗談 人間は失敗して良いし、再挑戦すれば良い 資料は余裕を持って作成する 資料に余計なネタや卑下は不要 自分なりの考えや学びを織り込む フィードバックを恐れない 良い図面は言葉に勝る まとめ 失敗談 その昔、私はTDDあかんやつ() *1 と呼ばれる下ネタ満載のLTを勉強会の懇親会で行ってめちゃめちゃ怒られたこともある。 他にも 山羊発言 や15分の持ち時間で30分喋るなど、多くの失

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