はてなブックマーク

こんにちは。 株式会社CHILLNNという京都のスタートアップにてCTOを担っております永田と申します。 多くのソフトウェアエンジニアは、習熟の過程で、DRY（Don't Repeat Yourself）原則の過剰な適用がむしろコードを難読化させる経験をします。 自分自身も例に漏れず、後から考えれば不必要な関数の抽象化により、コードが複雑化していくということを痛みを伴って体験してきました。 自分はよくコードレビューの中で、不必要な抽象化を行なっているコードに対して「過剰なDRYになってしまっているよ！」と表現をしてきました。（スーパードライですね。） 本記事では、うまく扱わないとむしろコードを難読化させてしまうDRY原則について、自分の経験を踏まえ、この原則の適用範囲を説明することを目指します。 はじめに DRYとは、Andy HuntとDave Thomasが書籍「達人プログラマー―シス

こんにちは。 株式会社 CHILLNN という京都のスタートアップにて CTO を担っております永田と申します。 本記事では、GraphQL を活用した、規模が拡大しても崩壊しづらいソフトウェアアーキテクチャについて考察していきます。 自分は普段はバックエンドを書いているのですが、先週は少し React を書いていて、その中で考えたアーキテクチャについて紹介させていただきます。 はじめに 弊社では API として GraphQL を利用しています。 API レスポンスの型をフロントエンドと共有できるため、API 設計を行う際に UI の構成を強く意識することができます。 弊社でのバックエンドの開発フローはざっくり以下のような流れになっています。 UI デザイナーが Figma で UI を作成する UI の構造を反映させた ViewModel（GraphQL Schema）を定義する Vi

こんばんは。 株式会社CHILLNNという京都のスタートアップでフルサイクルエンジニアをしております大島と申します。 弊社では現在アプリケーションのリプレイスを行っているのですが、そのリプレイスと並行してフロントエンド側のリアーキテクチャを行っています。 リプレイス後のフロントエンドでは、React, TypeScriptで実装しており、特定の境界で「関数型ドメインモデリング」に影響を受け、DDDのパラダイムを導入しています。 導入するに至るまで、数多くの試行錯誤を重ねてきた中でいくつかの知見を獲得しました。 それらの知見を本記事にて具体例を用いて紹介出来ればと思っております。 何か少しでもみなさまのお役に立てれば幸いです。 はじめに 本記事で紹介する開発手法では、 設計と実装を分離し、保守性・可読性の高いReactComponentを目指しています。 背景 弊社では主に以下のような課題が

こんにちは。 株式会社 CHILLNN という京都のスタートアップにて CTO を担っております永田と申します。 弊社では、バックエンドを typescript で実装しており、「宣言的プログラミング」と「関数型ドメインモデリング」のパラダイムを導入しています。 この構成は、一休 CTO である伊藤さんによる宣言的バックエンド開発の発信に大きく影響を受けており、よく言及されている「関数型ドメインモデリング」も拝読しました。 どれも非常に興味深く拝見させていただいたのですが、どうしても概念として理解することと、実装に落とし込むことの間には大きなギャップがありました。多くの試行錯誤を繰り返す中で、かなりこれらのパラダイムのメリットを実際に享受できるようになってきました。本記事では、我々の現時点での具体的実装上の tips を紹介します。 これらのパラダイムの導入を検討している方々にとって、少し

はじめに Vue3系をReactでBridgeする必要はあるのか？と思った、そこのあなた。大正解です。 筆者自身もニーズが不確かなまま執筆しています。ぜひ、箸休め程度に見て頂けると嬉しいです。 イメージ GifのようにReact(Next.js)上で、Vue3系のFormComponentを呼び出しています。 リポジトリ Vue Next.js React(Next.js)でVueComponentをBridgeする Vue componentの定義 先ほどのGifにあったFormComponentは以下のように定義しています。 特筆するようなことはありませんが、検証の為に分かりやすく姓・名に対応する更新用のcallbackを渡しています。 詳細は割愛させて頂きますが、onamae-formという名前でnpm packageとしてライブラリ化を行います。 <script setup lan

関数に渡す引数はどんなふうに設計されるべきでしょうか。 引数に関するベストプラクティスを少し調べてみると、引数の命名や引数の順序についての記述を見つけることができました。一方で、引数で渡すべき変数それ自体についての記述はあまり見当たりませんでした。 このトピックについてちょうど最近考えていたところだったので、記事を書くことにしました。 はじめに この記事ではソフトウェアはデータと関数で構成されていると考えます。 データはしばしば DB やストレージといったハードウェアに束縛されており、ソフトウェアがソフトでありつづけるためには、関数によってデータを柔軟に取り扱うことができる必要があります。 関数の分類 関数には 3 つの役割が存在します。 データの変換 データの定義 副作用の処理 1. データの変換 データは関数によって、他のデータと組み合わされたり、ビジネスロジックを実行することによって

こんにちは。 株式会社CHILLNNという京都のスタートアップにてCTOを務めております永田と申します。 弊社では宿泊施設様向けに宿泊施設の予約管理用のSaaSを提供しており、現時点で1000近くの施設様にご利用いただいています。 現在、これまでに溜め込んだ日本最大級の宿泊コンテンツの検索エンジンを構築しており、その過程でさまざまなデータベースを探索しています。 本記事では、AWSのKVSであるDynamoDBを題材に、公式ドキュメントに書かれているキー設計のベストプラクティスの背景を理解することを目的とします。 なお、本記事の執筆にあたって、こちらの動画を大変参考にさせていただきました。 DynamoDBとは DynamoDBとは、AWSで利用できる、あらゆる規模に対応する高速で柔軟なNoSQLデータベースサービスです。 DynamoDBが登場した背景は、アプリケーションの大規模化です。

はじめに こんにちは。 株式会社CHILLNNという京都のスタートアップにてCTOを務めております永田と申します。 2021年に書かれたこちらの記事で、現代のソフトウェア開発の主流は宣言的プログラミングだと言及されています。 上記の記事では、宣言的プログラミングの代表例としてReactとk8sが紹介されています。 実際、宣言的プログラミングといえば、Reactを用いた宣言的UIでのフロントエンド実装をイメージする方も多いかと思います。 仮にフレームワークを想定しなかったとして、宣言的プログラミングを行うとはどういうことでしょうか？ 私はこの問いに対する実践的な回答を持ち合わせておらず、自分が上記の記事を正しく実用的に理解できているとは思えなかったため、宣言的プログラミングをより深く理解する必要があると感じ、本記事を執筆することにしました。 本記事では、宣言的プログラミングを実用的に捉え、フ

はじめに 株式会社CHILLNNという京都のスタートアップにてCTOを務めております永田と申します。 昨夜、「依存性逆転の原則に従う抽象と実装のディレクトリ構成を考える」という記事を公開しました。 この記事を読んでくれた弊社のエンジニアから「FrontEndのGraphQLのAPI呼び出しのベストプラクティスとしてページごとに呼び出しを定義するパターンが用いられていて、これは依存性逆転の原則に従っていないがそれはなぜなのか？」という質問がありました。 本記事では、この観点に関する考えを深掘って解説していきます。 システムに境界を設ける理由 優れたソフトウェアアーキテクチャは、優れた境界を定義します。 では、そもそもなぜシステムに境界を設ける必要があるのでしょうか？ 一般に普及しているアーキテクチャでは、アプリケーションをそれを構成する複数のコンポーネントに切り分け、それぞれに特定の名前をつ

TL;DR データ指向プログラミング(DOP) とは、データとコードを分割してアプリケーションを設計・実装するプログラミングパラダイムのこと。 DOPの実装は、以下の原則に従う。 コードとデータを分離する 汎用的なデータ構造でデータを表現する データをイミュータブルなものとして扱う データスキーマとデータ表現を分離する 個人的にDOPは、バックエンドを宣言的プログラミングっぽく書くための現実的な解だと捉えています。実装の詳細は翔泳社より出版されている「データ指向プログラミング」をご覧ください。 はじめに こんにちは、株式会社CHILLNNという京都のスタートアップにてCTOを務めております永田と申します。 最近、エンジニアコミュニティでオブジェクト指向の定義に関する議論が行われているのを見かけます。Java育ちの自分にとって、オブジェクト指向の権威性を揺るがすような議論はかなり衝撃的だった

上記は、idとnameそしてroomをプロパティとして持つ、Hotelの型です。 nameが文字列型の必須のプロパティであり、roomというオブジェクトを複数持つことが簡潔に定義できます。 ちなみに、Roomの型は以下のように表現できます。 SDLは非常にシンプルで簡潔であるため、どのような言語を扱う技術者や非技術者でも理解しやすく、チームの枠を超えて、組織のデータモデルを定義するためのドキュメントとして機能します。 一方、欠点として、SDLにはfieldの値を計算して返すResolverの実装が含まれていません。 GraphQLを機能させるためには、何らかの言語でResolverの実装を追加で行わなくてはならず、GraphQLのみをSingle Source of Truthとすることはできません。 Code First Code Fistは、開発者はResolverだけを書くのみでよく

はじめに 京都のスタートアップでエンジニアをしている、KIOといいます。 昨日（10月20日）、Tailwind CSSのv3.2が正式にリリースされました。 この記事では新たに追加された主な機能についてざっくりとまとめます。 初めての技術記事投稿なので、読みづらい箇所が多々存在するかと思いますがご了承ください🙇‍♂️ いいね・コメント・指摘は大歓迎です！よろしくお願いします！ v3.2の記事を読んでいて、ヘッダーの右側にShowcaseの項目が増えているのを発見しました👀 誰もが知るサービスや、個性的なデザインのウェブサイトなど、Tailwind CSSで構築された色々なウェブサイトがまとめられていたので気になる方は是非ご覧ください！ この記事について この記事は👇の簡単なまとめ記事です。 より厳密な情報・詳細については以下サイトをご確認ください。 v3.2で追加された機能 追加さ