前書き エンジニアを始めて１４年、独立して９年経つ。 この仕事を始めた時に「さすがに眼が悪くなるかな」と思ったが、４０過ぎていまだに裸眼1.5／2.0だ。（昨年はどっちも2.0。） ↓今年の検査結果(右列が昨年) これはなんなら、始めた時より眼が良くなっている。（始めたころは1.2／1.5だった。） 先日知人のエンジニアと話していると、彼は２００人規模のエンジニアを抱える会社でリーダーをしているが「メガネをしてないエンジニアなんて会った事ない」と驚かれた。 実はそこに秘訣があるのでシェアしたい。 ちなみに妻はこの方法で片目だけだが0.9 → 1.2になった。 結論 「平行法を覚えろ」 これに尽きる。 遺伝の影響か ちなみに自分の親族・家族は実は須らく眼が悪い。 逸話的にも、若くして眼鏡を掛けていた父が、母をお見合いで最初に見た時に、「こいつも眼鏡掛けてる。」「もし子どもが出来ても全員目が悪

ジムの会員管理システムを作った僕に「エニタイムフィットネスみたいなことがしたい」とジムを家族経営するお客さんから相談された。 「えっ！？会員管理を作ったついでにエニタイムフィットネスみたいな仕組みをやりたい！？予算は無い！？不正防止のため、入退室時の写真も撮りたい？！ログもとりたい！？」 さすが筋トレに明け暮れてるオーナーさんの要望はマッチョだと思った。 普通にやれば電子錠の仕組みや工事やらで一店舗あたり数百万から一千万掛かるような仕組みだろう。 そんな予算無いみたいだし、既存の店舗をそんな大々的に工事もできない。そもそも自分にそんな工事の知識もない。 結果Raspberrypiを使い、それを一店舗予算10万円代で実現、会員カードを他店舗と共有した24時間営業にできた。 その詳しい技術的な内訳を共有する。 （なお執筆時点では２０２４年だが、これ自体は５年前、２０１９年の仕事である。） 前提

前書き WordPressで稼働しているリニューアル案件で、Astroを使って実装を行った。 ライブラリにサイトが完全に依存するデメリットもあるものの、 Astroを使用した理由としては、コンポーネント指向による保守性拡張性の観点からと、サイトの最適化の観点から採用した。 結果普通のレンタルサーバーでPageSpeedInsightsでほぼ100点満点。 SPの点数 PCの点数 使用感と感想 正直これまでのタスクランナーやモジュールバンドラーなどを使ったHTML開発は若干レガシー化している感があった。 そんな中、まさに現時点でのWeb開発ベストプラクティスを詰め込み、ほぼ何も考えずに最適化されたサイトを実装できる非常にすぐれたライブラリだと感じる。 また、これまでPageSpeedInsigthsの点数を上げようと思ったら、構築後、PageSpeedInsightsの助言に一つ一つ従いなが

GoでバックエンドをDDDで実装を行った。 DDD的に「エラーハンドリングこうしたらいいんちゃうの？」と思って書いたのが結構よかったので共有する。 まず復習。 何度も思いだしたい有名な図 出典：ドメイン駆動 + オニオンアーキテクチャ概略 エラーの種類 ここからすると、エラーの種類も自ずと決まってくる。 簡単に言えばドメイン層で起きるエラーはロジックに起因するエラーでありユーザーフィードバックが必要なものとなり、インフラストラクチャ層で起きるエラーはロジックではなくシステム起因によるものであるため、httpレスポンスであれば500サーバーエラーのような、ユーザーフィードバックはするべきではないが、システムのエラーログに残すべきエラーとなる。 もう少し実例を元にブレイクダウンする ドメイン層で起きるエラー これはいわゆる「ビジネスロジック」に起因するエラーとなる。 基本的にビジネスロジックを

GoでバックエンドをDDDで実装を行った。 DDDで悩むのは内側であるドメインサービス層から外側のインフラ層に当たるレポジトリに対してどのようにトランザクションを行うか、ということである。 何度も思いだしたい有名な図 出典：ドメイン駆動 + オニオンアーキテクチャ概略 UnitOfWorkパターンなど様々なソリューションがあるが、Goだとポインターの存在とContextによって、TransactionのInterfaceを作り、DIでサービス層からうまくトランザクション操作することが出来たので、共有したいと思う。 （GoやDDDの知見がある方でもし下記に指摘する箇所があればアドバイス頂ければと思う。） 前書き Javaの前提の言葉だがDDDの実装はPOJO(Plan Old Java Object)であるべき、という考えがあり、基本ライブラリに依存しないことが良いとされる。 そういった意味