React / Remix への依存を最小にするフロントエンド設計 - 一休.com Developers Blog
CTO 室の恩田(@takashi_onda)です。 一休レストランのフロントエンドアーキテクトを担当しています。 Intro 一休レストランでは、以前ご紹介したようにフロントエンドで React / Remix を利用しています。 user-first.ikyu.co.jp 一方、設計方針としては、React / Remix への依存が最小になるように心掛けています。 今日は、そんな一見矛盾するような設計方針について、ご紹介したいと思います。 この記事を読んでいただき Remix に興味をもたれたら、明後日 2024/8/7(水) 19:00〜 のオンラインイベント offers-jp.connpass.com にもご参加いただけると嬉しいです。 この記事でご紹介している疎結合なフロントエンドアーキテクチャを実現する Remix の魅力についてお話します。 なぜ依存を最小にするのか？ R
スケールする要求を支える仕様の「意図」と「直交性」 - Qiita
はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の
リアーキテクトと開発生産性について
2023/10/31 @ Barフロントえんどう で発表した「リアーキテクトと開発生産性について」です。
継続的ドキュメンテーション: Github DiscussionsとADRのすすめ - LIFULL Creators Blog
こんにちは。テクノロジー本部のyoshikawaです。好きなW3C Recommendation は RDF 1.1 Concepts and Abstract Syntax です。 会議やチャットでのやり取りの決定事項・議事録、アプリケーションや機能の設計書・仕様書、READMEなどなど... LIFULLの開発現場においては、ソースコード以外にもこのように様々な文書の管理・蓄積(=ドキュメンテーション)を実施しています。 多くの開発者・メンバーがドキュメンテーションの重要性やその恩恵は理解はしているものの、なかなかうまく情報の蓄積・管理ができない、 その結果、本質的ではない調査に時間を取られてしまいDeveloper Experienceが下落してしまう。 このような課題を抱えているプロジェクトやチームは世の開発現場において少なからず存在すると思います。 LIFULLの開発現場にもこの
メルカリShops のフロントエンド | メルカリエンジニアリング
こんにちは。ソウゾウの Software Engineer の hiroppy です。「連載：「メルカリ Shops」プレオープンまでの開発の裏側」 の最後は、Web フロントエンドの紹介をしたいと思います。メルカリ Shops は既存のメルカリアプリの中に独立した Web アプリケーションとして動いています。本記事では、どのようなライブラリを選定し、どのようにアーキテクチャを設計してきたかを解説します。 なぜ Web なのか？ アプリの上で動いているのであれば、WebView ではなくても良いと感じる人はいると思います。今回採用した 1 つの理由としては、リリースが柔軟な点が挙げられます。iOS/Android の両方に対して開発サイクルを早めることが可能であり、また機能追加やバグ修正が容易です。どのように WebView で動いているかについては、6 日目のメルカリ Shops のため
CSSのユーティリティクラスと「関心の分離」——いかにしてユーティリティファーストにたどり着いたか（翻訳） - yuhei blog
Tailwind CSS作者のAdam Wathan氏による「CSS Utility Classes and "Separation of Concerns"」の日本語訳です。翻訳に当たって原著者の許諾を得ています。 2021年10月29日に全文再翻訳しました。 この数年の間で、私のCSSの書き方は、非常に「セマンティック」なアプローチから「ファクショナルCSS」と呼ばれるものに変わりました。 この書き方でCSSを書くと、多くの開発者からかなりの反感を買うことがあります。そのため、私がいかにしてここまでたどり着いたかを説明することで、その過程で得た教訓や洞察について共有したいと思います。 第1段階 「セマンティック」なCSS よいCSSのためのベストプラクティスとして、耳にするであろうことのひとつは「関心の分離」です。 考え方としては、HTMLにはコンテンツについての知識のみを含めるべきで
CSS Utility Classes and "Separation of Concerns"
Software developer, author, and host of Full Stack Radio. August 7, 2017 Over the last several years, the way I write CSS has transitioned from a very "semantic" approach to something much more like what is often called "functional CSS." Writing CSS this way can evoke a pretty visceral reaction from a lot of developers, so I'd like to explain how I got to this point and share some of the lessons a
CSSとコンポーネント設計に対する考察 - uhyo/blog
近年のフロントエンド開発にはコンポーネントという概念が付いて回ります。React・Vue・AngularといったViewライブラリでは、コンポーネントを定義してそれを組み合わせてアプリを作ります。また、いわゆるWeb Componentsとして知られる仕様群により、ライブラリに依存せずに“コンポーネント”を作ることもできるようになってきています。 コンポーネントは、何らかの機能（あるいは責務）を持った部品です。また、コンポーネントによっては再利用される（アプリ内の複数の箇所から利用される）ことを意図しているものや、そもそもライブラリとして配布されているようなものもあります。アプリの機能の一部分を抜き出したものという見方をすれば、コンポーネントというのは関数にとても類似した概念であることが分かります。 コンポーネント設計によって、言い換えればアプリがどのような機能を持ったコンポーネントたちに
CSS設計における、すべてがコンポーネントであるという誤謬
後日追記: WEB+DB PRESS Vol.133でさらに詳しく書いた。 BEMによってもたらされた、コンポーネントベースのアプローチでは、「ページはコンポーネントの集合によって表現されるべきであり、ページに含まれるのはすべてがコンポーネントである」と考える。しかしこれまでCSSを書いてきた経験から、これではデザイン意図をまともに表現することができないと感じ始めた。なぜなら、普通デザイナーはページのすべてがコンポーネントであるとは考えないからだ。 もちろんページの構成要素のなかには、明らかにそれが「コンポーネント」であると意識して作られたものもある。ただしそれは一部であり、全部ではない。「コンポーネントもあれば、コンポーネントではないものもある」という感覚のほうが普通なのだ。 典型的なUIライブラリにある、「ザ・コンポーネント」みたいなものだけではページは完成しない。例として、一貫してB
Active Recordから考える次の10年を見据えた技術選定 / Architecture decision for the next 10 years at PIXTA
September 15, 2021 @ iCARE Dev Meetup #25
Amazon ECS と AWS Fargate を利用した Twelve-Factor Apps の開発 | Amazon Web Services
Amazon Web Services ブログ Amazon ECS と AWS Fargate を利用した Twelve-Factor Apps の開発 この記事は、Developing Twelve-Factor Apps using Amazon ECS and AWS Fargate を翻訳したものです。 本投稿は、Solutions Architect の Sushanth Mangalore と Chance Lee により寄稿されました。 はじめに The Twelve-Aactor App と呼ばれる方法論は、モダンでスケーラブル、かつメンテナンス性に優れた Software-as-a-Service アプリケーションの構築に役立ちます。この方法論はテクノロジーにとらわれず、クラウドネイティブアプリケーションを開発するためのアプローチとして広く採用されています。 AWS で
ユーティリティーファーストとTailwind CSSのススメ - Qiita
Tailwind CSSは結構いいんでないの？というポエムです ユーティリティーファーストって考え方について まず、 ユーティリティークラスが何かということ ユーティリティークラスを使ってHTMLを書いていくということってどういうことか これは、ある程度CSSを書いている人であれば想像できることであろうと思う。 こんな風に、あらかじめユーティリティー的なクラスを用意しーの .align-left { text-align: left; } .align-center { text-align: center; } .align-right { text-align: right; } .align-top { vertical-align: top; } .align-middle { vertical-align: middle; } .align-bottom { vertical-a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
作りすぎない技術 - API時代の開発努力の在り方について考える / Thinking about the state of development efforts in the API era
技術的負債と向き合う
フロントエンドリアーキテクトの話
実践ADR - kawasima
アーキテクトに求められるマインドとは / mindset for an architect
電子情報学特論：Chromiumのアーキテクチャを解き明かす
Continuous Architecting and Rails: From rails new to Your Own Architecture
Developing Twelve-Factor Apps using Amazon ECS and AWS Fargate | Amazon Web Services