35歳を迎えたCTOが35歳定年説について考えた - そーだいなるらくがき帳
先月、35歳になった。 35歳定年説は「全員に一致する法則ではない」というのは一般的な認識になっている。 前職の同僚で同世代である id:motemen に聞いたところ「そんな事を意識したことなかった」という回答をもらったこともある。 しかし、実際に自分が35歳になると「自分は他人事ではない」という感覚だけがある。 そこで今日はそのことについて考えていきたい。 コードを書くということ コードを書くという行為は年齢関係なく続けていける。 しかし「仕事でコードを書き続ける」となると事情が変わる。 まず費用対効果として自分がコードを書くことが正しいのか？という問題とぶつかる。我々のプログラマーとしての仕事を奪うのはAIではない。いつの時代も 優秀な若者 だ。 そんな若者と比較した時、我々がコードを書くことが若者がコードを書くことよりも費用対効果がある場合はどんな場合だろうか？やはり経験が活かせる
Github projectsが実際に使えるレベルになっていたのでみんな使っていいと思う - そーだいなるらくがき帳
GithubのカンバンツールであるGithub Projectsはリリースされて1年以上経っている（2018/04/10現在） 僕が当時、使えるかなって思って試した感想は下記の人とほとんど同じような感想だった。 qiita.com 以下、引用。 projectページ内でissueを作成することができないことも率直に不便を感じた :thought_balloon: issueをcloseしたり、PRがmergeされたら自動でclosedのカラムへ移動してほしい。 「自分の担当issueのみ進捗管理したい」などのニーズは容易に想定できるので、projects内のフィルタリング機能がほしい 上記に対して改善しているポイントを述べていく。 Projectsの中で作ったカードをissueに登録できる 該当のカラムの中でカードを作ることが出来る。 これはissueとは別の独立した存在でissueには登
MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳
結論 何がいいたいかといいますと0000-00-00 00:00:00があるとORMも死ぬし、DBマイグレーションツールも死ぬし、そもそもMySQLからポスグレにデータを持っていくこともFDWをすることも出来なくて死ぬのじゃ。— そーだい@初代ALF (@soudai1025) 2018年4月25日 色々困るので使わない。 理由 以下に理由を述べる SQL標準ではない 正論で殴った場合。 0000-00-00 00:00:00の仕様が難しい 0000-00-00 00:00:00 はMySQLの独自な仕様で NOT NULL制約のカラムではNULLと等価であり、NULLではない という仕様がある。 "NOT NULL として宣言された DATE および DATETIME カラムでは、次のようなステートメントを使用することで、特殊な日付 '0000-00-00' を検索できます"https:
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
エンジニアの信頼を得るには良質なアウトプットが必要な話 - そーだいなるらくがき帳
先日、僕が大好きでリスペクトしてるソフトウェアエンジニアさんたちと意見交換会（呑み会）中にソフトウェアエンジニアの信用と信頼について話題になったのでメモ。 僕が「このソフトウェアエンジニアは信用できる」っていうのはどういう指標がありますか？って質問した時に出た意見としては コードに対して何らかの貢献をしている 新規プロダクトの開発など OSSのメンテナンスなど（パッチを送るなど） 自分の持つプロダクトに対する反応など が出てきた。 これらのような「良質なアウトプット」を定期的に行う頻度も大事だよねという感じ。 なるほど、確かにって思ったのだけど更にその中で良質なアウトプットとは何かという話題になった。 ソフトウェアエンジニアの属性 ソフトウェアエンジニアには得手不得手がある。 言語だったりレイヤーだったりで好き嫌いも含めて得手不得手がある。 更にもっと言えば「プロダクトの成長段階」でも得手
今こそ知りたい、2大OSSデータベースのMySQLとPostgreSQLの違いについて話をしてきた - そーだいなるらくがき帳
去年書いたSoftwareDesignを題材にお話してください！って言われたので話してきました。 下の特集記事は１年経った今も現役で読める内容なので興味がある人はぜひ読んでみてください。 またRDBアンチパターンという連載をしていますのでこちらもあわせてご確認くださいっ！ gihyo.jp そして当日の資料はこちらです。 SoftwareDesignにしっかりとMySQLとPostgreSQLの違いについては触れているのでそこでは触れていない、ハマりどころや初めて両方のDBを知ったと言う人向けのカジュアルは部分を攻めました。 またDBだけの勉強会ですので普段説明するようなところは省略し、できるだけ経験談やコアの話に注力したつもりです。 このへんは資料に含まれて居ないので当日居た人たちだけの特典ですね！！ ということで実は今月は登壇3週連続だったのですが一段落しました。 来週はAWS Sum
Javaエンジニアに知ってほしいRDBアンチパターン その3 について話して来た #jjug_ccc - そーだいなるらくがき帳
Javaの国内最大カンファレンス、JJUG CCC 2017 springで登壇してきました。 僕の中で先週のオープンセミナー岡山の熱がまだ収まらぬ中の登壇だったのですが、多くの方に聴いていただけて嬉しかったです！ その時の資料がこちら。 RDBアンチパターンについてはPHPカンファレンスやYAPC:Kansaiでも話をしましたが、今回は別バージョンです。 soudai1025.blogspot.jp soudai.hatenablog.com あのときはWeb系の人向けに話をしましたが、今回はエンタープライズな業務系の人向けです。 業務系は僕の印象では制約だったり、RDBの機能を有効活用してる印象があるのですが、逆に過剰になっていることが多い印象があります。 また論理IDなどデータ量が少なかったり、アプリの改修が少ないから死ななかっただけの設計も多く見られる印象です。 そういう点を今回お
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
