ドメイン駆動設計(DDD)を整理
またクラスを利用していないため、オブジェクト指向の特性「継承」「カプセル化」「ポリモーフィズム」は利用していません。この部分が厳密なドメイン駆動設計(DDD)のニュアンスと異なるので「風味」という言葉を使っています。 全体概要と用語の整理 まず初めにドメイン駆動設計の全体の概要と出てくる用語について紹介します。 自分は言葉を理解しないとコードの理解に落とし込めなかったので詳しく解説をしていきます。 各用語の具体的な実装は後の章で紹介します。 すべての用語において理解しやすいように「ユーザー管理システムを実装する」例を用いて解説を入れています。(解説の都合で書籍とは異なる例を採用しています) ドメイン駆動設計とは ドメイン駆動設計はその名の通り、「ドメインの知識」に焦点をあてた設計方法 「ドメイン」とは、ソフトウェア開発におけるプログラムを適応する対象となる領域 ドメインについて ドメイン駆
Pythonコードを35000倍に高速化したい
はじめに Pythonは世界的にも人気のあるプログラミング言語ですが、実行速度については課題があります。Pythonの実行速度を高速化したい、という要求は根強く、これまでにも様々な処理系が開発されています。 この記事はPythonで書かれたコードを35000倍に高速化するにはどのような方法があるかについてまとめたものです。 この記事は： Pythonで書かれたアルゴリズムを35000倍に高速化する 事前コンパイル、並列化、SIMD演算を駆使する 最終的に44000倍まで高速化できた なぜ35000倍？ 2023年5月2日にModular社よりPythonの使いやすさとC言語の性能を兼ね備える新しいプログラミング言語、Mojoの開発について発表がありました。低レベルのハードウェア向けにコンパイル可能なこと、文法的にはPythonを踏襲しており、既存のPythonライブラリを利用可能であること
一言で理解するReact Server Components
この記事はReact公式の内容を翻訳・紹介するものではありません。筆者の解釈や理解を伝えるものであり、Reactの公式見解と一致しているとは限りません。あらかじめご了承ください。 皆さんこんにちは。最近Next.js 13.4がリリースされ、App Routerがstable扱いになりました。App RouterはReact Server Component (RSC) をふんだんに用いて構築されています。 React本体でServer Componentがずっとalpha版なのにNext.jsでbetaとかstableとか言ってるのは何で？ という問題も、React Canaryのアナウンスにより無事に解消されました。 React Canaryってなに？ 先日React公式ブログでアナウンスされた、新しいリリースチャネルです。 筆者の理解による概要をお伝えすると、Canary版のReac
useEffectをやめて、Suspenseを使おう
Reactコンポーネントの開発時、データフェッチは欠かせません。 SPAで開発を行う時、あなたも含めてuseEffect()を使ったことがあるはずです。 あなたがSWRやReact Queryの代わりにuseEffect()を使う理由は、いくつかあるのでしょう。 そんな方のために、Reactが提供する<Suspense>を使ってデータフェッチを行う方法を紹介します。 追記: Suspenseではウォーターフォール問題を解決できないとの指摘について 「Suspenseの実装」に記載のコードを見た限り、ウォーターフォール問題を解決できないとの指摘がありました。 実装の章では問題を解決することではなく、<Suspense>をどのように使うかに焦点を当てました。 具体的な実装方法に踏み込むとテーマから大きく外れてしまう可能性があったためです。 読みやすさを優先した結果、解決のための実装については割
アーキテクトがチェックすべきオープンソースのWebサービス一覧
実装の参考の当たり 前口上: オープンソースの実装を読もう 普段Web開発をしているとこの書き方は普通か、実装の方向性はよさそうか不安になることがあります。そういった際、同じリポジトリの既存実装や会社の他のリポジトリ、技術ブログや本、過去の経験、他のメンバーの意見などを参考にしつつ当たりをつけるわけですが、リファレンスが増えるに越したことはないです。 有名な言語、フレームワークではオープンソースのWebサービスがGitHub、GitLab上などにあがっていることがあり、参考になります。 それぞれライセンスがあり、とりわけGPL汚染などは要注意ですが、収集した一覧が溜まってきたのでまとめておきます。ある程度有名なものメインでスクリプト言語+Go。 Ruby Ruby on Railsは有名なので採用しているWebサービスが多数あります。 Redmine イシュー、プロジェクト管理ソフトのRe
過激派が教える！ useEffectの正しい使い方
ReactのuseEffectは、フックの中でも使い方が難しいものの一つです。そこで、この記事では筆者が考えるuseEffectの望ましい使い方を皆さんに伝授します。 基本原則 技術やその要素の使い方を考えるにあたって、筆者が好んでいるのは基本原則を置いてそれに基づいて判断することです。ということで、この記事ではまず筆者が考えるReactの基本原則を紹介します。 筆者がもっとも重要視する原則は、ReactはUIライブラリであるということです。つまり、ReactにはUIの管理をさせるべきであって、その他のことはReactの役目ではないということです。Reactが難しいと思う人がいる場合、何でもかんでもReactにやらせようとするから余計に難しくなっているのだと思います。 例えばアプリケーションのロジックの管理やそれに付随するステートの管理はReactの役目ではないので、Reactの外部で処理
データベースのロックの基礎からデッドロックまで
データベースのロックについて、資料を読んだり実際に試してみたので、学んだことを整理してみようと思います。はじめにロックについての基本的な知識を整理して、最終的にはデッドロックとその対策について説明します。 使用したソフトウェアのバージョン MySQL 8.0.31 この記事ではMySQLを使用しています。その他のデータベースについては、基本的な部分は共通していると思いますが、異なる点があることをご了承ください。 ロックとは何か（概要） ロックはデータの更新を正しく行うための仕組みの一つで、あるデータに対する更新処理を制御するためのものです。ここで、データを正しく更新するとはどういうことかを説明するために、口座への振込を例に考えてみます。 例えば、口座Aから口座Bに1万円の振込を行うとします。このとき、口座Aの出金処理と口座Bの入金処理は、必ず両方が成功しなければなりません。このための仕組み
新入社員「DNSってなんですか？」→ これ、どこまで答えられますか？？？？？？？？？
はじめに 「DNSって何ですか？」 エンジニア・プログラマの皆さんは会社の同僚や後輩などにこの質問をされたらどこまで回答できますか？ 大体の人は、「Domain Name System(ドメイン・ネーム・システム)の略称で、IPアドレスとドメインの紐付けをおこn.....」 みたいな回答になってしまうと思います。 特に自分のような、フロントエンド周りが主領域のエンジニアにとってはDNSの理解はかなり後回しになってしまうかなと思います。 今回は、そんなあまり業務でDNSに携わらない方々に向けて、DNSの最低限知っておきたい基礎知識をやさしくお届けできたらなと思います。 ※タイトルではめちゃくちゃ煽りましたが、本記事は割と基礎的な内容になっています。ご安心を。 DNSとは まずは、DNSとはなんぞやというところから入っていきたいと思います。 DNSとは、冒頭にも登場しましたが、Domain N
Webフロントエンドにおける網羅的テストパターンガイド
こんにちは、テストが好きなsilverbirderと申します。Webフロントエンドのテストは実施していますか？ユニットテストやビジュアルリグレッションテストは広く知られていると思います。しかし、パフォーマンステストのためのテストコードはありますか？また、カオスエンジニアリングテストやアクセシビリティテストはありますか？ 今回、私はWebフロントエンドにおける網羅的なテストパターンを調査し、その結果をここで紹介したいと思います。これらを理解することで、読者の皆さんが適切なテスト戦略を策定する際の参考になれば幸いです。 前提 今回、テスト対象として取り上げる題材は、TodoMVCというTODOアプリです。フレームワークとしてReactを使用しますが、紹介するテストパターンはフレームワークに依存しないものです。ただし、使用するライブラリはReactに関連しているため、その点についてはご了承くださ
改めて見直すGoの特徴
極力Goならではな特徴をいくつか挙げていく。 依存解決が必要最低限で互換性を考慮しつつ決定的 モジュール単位で依存をダウンロード。コンパイル対象はサブパッケージ単位。 依存の明示方法はコードに埋め込まれ、かつ未参照のインポートはコンパイルエラー。 つまり動作するコードのすべては正確な依存ツリーが明示されていて余計な依存は引き込まれない。 そして持ち前のコンパイルの速さを含め、相当深い依存ツリーでも依存解決にかかる時間は既知の処理系の中でも最速レベル。（唯一勝てるのはプリビルドバイナリが配布されている場合くらい） また、コンパイルやリンクに必要な処理量そのものが比較的少ないため、開発環境負荷も小さい。 かなり巨大なプロジェクトであってもメモリ8GBで困るようなことが無い。つまり、CI環境の維持にもローコストで済む。 ライブラリの提供側では後方互換性が破壊されるような変更はV1->V2というよ
chatGPTにアドバイスをもらったらデータサイエンスを知って1週間の友人がコンペで上位6.5%に入った話
先日、データ解析のセミナーを開催しました。 未経験の方でも、2時間で予測モデルを作成することができるハンズオンセミナーでした。 好評だったので、その内容をYouTubeにまとめたのでご興味ある方はご覧ください。 このハンズオンセミナーで予測モデルの作り方を知った友人がchatGPTにアドバイスをもらって、データサイエンスのコンペティションサイトに応募したところ、上位6.5%に入ることができたという報告を受け、驚愕しました。 chatGPTを上手く使えば素人がプロに勝つことも十分できるのだなと実感しました。 友人が参加したデータサイエンスのコンペは、SIGNATEの糖尿病予測問題でした。 以下のような進め方をしたとのことでした。 まず、問題の概要を説明して、どのように進めていけば良いかを確認したそうです。 そうすると、chatGPTからデータサイエンスの問題を解くための手順を一覧化してくれて
趣味でOSS活動をしていたらDeno Land Inc.にジョインすることになった話
で、GitHub Sponsorsを始めたところ多数のご支援をいただくことができたことを書きました。 その後、OSS活動を細々と続けていたところ、JavaScript/TypeScript ランタイムであるDenoの開発を行っている Deno Land Inc.にジョインすることになりました。 ジョインまでの流れ 上記の記事で書いたように、deno_lint などのDeno関連のプロジェクトにコントリビュートをしていました。定期的にコントリビュートしていると、他の人からのPull Requestのレビューなどもお願いされるようになります。Approveをすることはできますが、mergeの権限はありませんでした。その他にも、issueをクローズするための権限もなく、整理のためにクローズしたいissueがあっても、メンテナに依頼をする必要がありました。 大した手間ではなかったものの、メンテナ権
httpとhttpsの違い
TLSの有無 言うまでもないことですが、httpsでは通信路をTLSを使って保護することが想定されています。[1][2] デフォルポート httpは80、httpsは443です。[3][4] 権威性 以降の説明に入る前に前提を確認します。本稿は「httpとhttpsの違い」と題されていますが、これはURLのスキーム部分のことを指しています。URLはリソースの所在を指すものであり、通信方法はそこから二次的に決まるものです。このことを前提に置きつつ権威性について説明します。 Webにおいて、所望のリソースにアクセスする方法はひとつではありません。このような方法のうち、リソースの所有者の制御下にある(第三者による加工などが行われていないと期待される)方法で取得することを権威的アクセスと呼びます。[5] どのようなアクセス方法が権威的とみなせるかについて100%客観的で統一的な指標があるわけではな
PNGファイル爆発しろ！
まえがき Web上で広く利用されるPNG(Portable Network Graphics)フォーマットは、デジタル画像を変化させずに小さいデータサイズへ変換する圧縮技術の一種です。PNGフォーマットはオリジナル画像を完全復元可能な可逆(lossless)圧縮ですから、JPEGフォーマットのように画像を歪めてしまう非可逆(lossy)圧縮ほどは小さくできません。それでもオリジナルのデジタル画像データの半分程度まではサイズ削減可能な画像圧縮アルゴリズムと言われています。[1] そげぶ いいぜ てめえが何でも思い通りに圧縮出来るってなら まずはそのふざけた幻想をぶち壊す!! （スペース都合によりAA省略） 本記事では、PNGフォーマットを画像データ圧縮(compress)用途で利用するのではなく、オリジナル画像データよりも遥かに巨大なPNGファイル を生成します。 PNGフォーマットでは任意
エンジニアが開発しやすい環境作りをする
はじめに 自分は渋谷のWeb系開発会社にて執行役員兼エンジニアをやっています。(新卒入社3年目) 直近では6~8名程のエンジニアがいるプロジェクトで、ディレクトリ設計やissue作成、コードレビュー、スケジュール管理、PMへのUI/UX及び機能提案などを行なっています。 その中で自分が「エンジニアチームにとって開発しやすい環境整備」を色々試し、実践してきたので整理していきます。 この記事の主な対象者 エンジニアチームの開発モチベーションを上げたい人 エンジニアにとって開発しやすい環境の作り方 おことわり 今回紹介するのは自分が実践してきた一例であり、必ずしも正解というわけではありません 「こうしなさい」ではなく「こうするとより良くなるかも」といったモチベで書いています 具体的な開発の設計を紹介するものではありません エンジニアが開発しやすい環境作り 5つのセクションに分けて紹介していきます
Mac の Docker の x86-64 エミュにプッツンした勢いで、余ったパソコンをリモート Docker サーバーにした
Mac の Docker の x86-64 エミュにプッツンした勢いで、余ったパソコンをリモート Docker サーバーにした ARM Mac で Docker Desktop や Lima を使っていて、 docker build --platform x86-64 .... や docker run --platform x86-64 .... が、いきなりクラッシュしたり、途中まで進むけど特定の箇所でコケたりで困ったことはありませんか。 私はしょっちゅう困ってます。いよいよ我慢の限界になり、部屋でホコリを被ってた x86-64 なパソコンを使ってどうにかすることにしました。 これはホコリをはたいてキッティング中の様子です。 前準備 x86-64 なCPUを搭載したパソコンを調達する Intel でも AMD でもどっちでもいいです。私は手元に転がってた Lenovo M75q-1 を
GitHub を使うなら通知くらいまともに設定してくれ
4 月から新入社員となって本格的にエンジニアとして生活し始めた方も多いかと思います．いままであまり GitHub を使っておらず，会社から要求されてはじめてまともに使い始めた方もいるかもしれません． そんな方々にお願いがあります． GitHub を使うなら通知くらいまともに設定してくれ あなたがこのタイトルを読んでピンときていないのであれば，あなたの通知設定はおそらく間違っています．GitHub は初期設定だと非常に多くの通知を送信します．それは GitHub 自身が通知ページで述べているくらいです． 通知はあなたが思う以上に大切な存在です．必要とする通知は人によって様々であり，それを見逃してはいけないため，ときに GitHub は必要以上の通知を送信しています．しかし，必要以上な通知を受け取ると，人は通知を見ないようになってしまいます． 個人開発ならそれでもよいかもしれません．しかし，あ
「こうしてスクラムが終わってしまう」前にすべきこと
こうしてふりかえりは終わってしまった / A Demise of a retrospective ふりかえりカンファレンスで一番面白かった発表資料です。 資料をざっくり要約すると ふりかえりは最初は順調に機能するがある段階で停滞し、次第に「効果が出ていないもの」と判断されて廃止されてしまう、という話です。 理由として最初は低コスト高リターンの課題を倒していけるが、それらをすべて解決すると残るのは「リターンはあるが、コストが高すぎて解決できない課題」と「コストは低いがリターンもほぼない課題」だけになります。 開発チームは前者を「コストが高すぎて解決できない」と忌避し、後者だけに打ち込んだ結果、リターンが出ずに振り返り事態を無価値を判断してしまうからです。 ふりかえりを廃止することでチームの成長は停止してしまうでしょう。 これを防ぐために「コストが高すぎて解決できない」課題を解決する方向に頑張
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【新機能】Vercel Postgres + Next.js + PrismaでフルスタックWebアプリケーションを作ってみた
ドッカー入門
