トーク

目の前に立ちはだかる削除フラグ......
削除フラグがアンチパターンであることは知っていても、目の前の削除フラグと付き合っていくしか無い...
そう思って諦めていませんか？

削除フラグを既存のアプリケーションに影響をできるだけ閉じて無くすことはできます。
テーブルから状態や属性を別のテーブルに移し、アプリケーションを壊すことなくリファクタリングしていくために必要なことを説明します。

• 削除フラグがあるテーブルをどうやって分割するか
• 既存のコードの振る舞いを維持しながら如何にリファクタリングするか
• リファクタリングをやりきる ために必要なステップ

レガシィコードと向き合い、リファクタリングして、目の前のプロダクトを改善している現場のテクニック、余すこと無くお話します！

生涯エンジニアを続けたい。
しかしインターネットを見渡せば凄腕のエンジニアばかり。
このまま、自分は生き残れるのだろうか...

私も今年、38歳を越え、職場ではCTOとして決断を迫られる中、それでも新しい技術を理解し、向き合って行かねばなりません。 もちろん一日は有限ですから勉強する時間も限られます。

そんな中、私がどうやって新しい技術を理解し、未来の技術を予測し、今の技術を選定しているか。
そのために日々をどう過ごしているか。そんな "エンジニアとして生き残るためのhack" を皆さんにお伝えします。

ピカソは言った。「優れた芸術家は模倣し、偉大な芸術家は盗む。」

先人の言葉を例に上げながら、課題を解決するエンジニアになるためのロードマップをお話します。

多くのWebサイトではメールアドレスをIDとしてユーザーを管理しています。この設計はフレームワークの機能として用意されることもあります。

しかし実際のサービス運用のためには、いくつかの考慮事項があります。

• ユーザーのメールアドレスの入力ミスによる機会逸失を防ぐ
• 特定の条件のユーザーからの登録を阻止する

要約するとたった二点ですが、実要件は運用形態や提供したいサービスによって様々です。たとえば、同じユーザーからの複数登録を許容しない、特定のドメインからの登録を禁止するなどです。
一見明確でも、単純に実装できない要素がいくつもあります。メールアドレスや関連仕様、DB製品とCollation、メール配信サービスプロバイダ、ユーザー認証プロバイダなども影響します。

メールバリデーションライブラリの実装を通じて、アカウント管理に必要な観点をみつめなおしましょう。