for the past 10 years - Currently researching better ways to develop software スカラコンサルタントのアナトリーです。10年間Scalaに取り組み、現在はより良い ソフトウェア開発の方法を探求しています。 🌐https:/ /anatoliikmt.me 🌐https:/ /github.com/anatoliykmetyuk
Software Engineering is about Sandboxes Inside - easy Outside - hard - Everyone has their unique approach to engineering. - You can create your own sandbox... - ...by defining your principles... - ...and picking appropriate tools. ソフトウェア開発では、ツールやAPI、フレームワークなど他人 の成果と、その背後にある哲学や原則が自分の「サンドボック ス」を形作り、開発体験を決めます。 P T S
with you. Maybe you'll find inspiration to build your own! Principles Sandbox この発表では、原則がツールを生み、それがサンドボックスにつながる流れを紹介しま す。私のサンドボックスの例を共有し、皆さん自身のサンドボックス作りのヒントにな ればと思います。 P T S Tools
of Web Apps Develop & deploy an MVP of an idea as a solo developer in a reasonable time while having fun 今日紹介する私のサンドボックスの目的は、アイデアのMVPをソロ開発で素早く プロトタイピングし、短期間で楽しく形にすることです。
do one thing - They are not following the same principle - Therefore do not compose well - Leading to increased complexity 主流のフロントエンドフレームワークは、同じことを実現する方法が多く、共通の原則に 基づいていないため組み合わせにくく、結果として複雑さが増してしまいます。 S
3. Responses label themselves as cacheable or non-cacheable 4. Layered System Architecture 5. Uniform Interface 6. Code-on-demand (optional) RESTの原則は正式に定義された制約であり、本来これらに従う必要があ ります。しかし現在の多くのウェブサービスはJSON APIを提供している だけで、重要な制約を満たしておらず真のRESTとは言えません。 - Roy Fielding’s PhD Dissertation (2000) "Architectural Styles and the Design of Network-based Software Architectures" P
need for JSON 3. Front-end is Language-agnostic 4. Ability to reduce complexity via a well thought-through server language HMDAとHTMX、そしてREST的な考え方を採用すると、クライアント側の状態管理 やロジックにJSが不要になり、JSONも要らず、フロントエンドは言語非依存になり ます。また、サーバー側に適切な言語を選ぶことで全体の複雑さを下げられます。 S
a diagram of interconnected resources - Wireframes, architecture, domain model are visually displayed - Dev progress can be tracked right on the diagram with - Symbol names are easily derived from the image by both humans and AI for navigation and implementation Tools: - Obsidian - Excalidraw-obsidian plugin このスクリーンショットは語学学習用のフラッシュカードアプリの例で、私はワイヤーフレームを使ってページ同士をつなぐ「リソースのネットワーク」とし てWebアプリを視覚的に設計しています。HTTPエンドポイントで表現されたリソース名が、そのまま実装時の単一のソース・オブ・トゥルースになります。 Vocab Kanji Grammar Front: <html> Back: <html> Good Bad ✏️ ✏️ ✏️ Session ➕ Edit Records Vocab ✏️ 🗑️ Create New Deck New ➕ Key Prompt 🎴Default 🎴Back ➕ ➡️ Name Description 🚀 ⚠️ 🗑️ Vocab Session GET /decks GET /decks/{deck_id}/session GET /decks/{deck_id} GET /decks/new GET /decks/new POST /decks GET /decks/{deck_id}/session POST /cards/{card_id}/review PATCH /records/{record_id}/flag DELETE /cards/{card_id} GET /decks/{deck_id} PATCH /decks/{deck_id} // Edit name DELETE /decks/{deck_id} GET /decks/{deck_id}/session GET /records?deck={deck_id}&page=1 GET /card_types/{card_type_id} GET /card_types/new?deck=deck_id P T
2. HTTP Endpoints follow RESTful principles 3. All methods are either: endpoint, business logic or view 4. It is easy to derive one name from another ここでは、HTTPエンドポイントをソース・オブ・トゥルースとし、RESTの原則に沿 った名前付けを行い、メソッドを役割ごとに分け、名前同士が導きやすいようにすると いう命名規約をまとめています。 P
headers... _ => handler, in terms of view and implementation methods - Allows for rapid prototyping - AI can easily repeat the pattern after few examples DO Repeat Yourself Don't もう一つの原則は「コードを規則的なパターンで書 く」ことで、この画面でも実装が互いに非常に似た形 になっています。これは意図的で、AIに例を示すこと で、図と指示を与えれば同じパターンに沿って実装を 自動生成させるためです。 P
sandboxes (developer experience). - Everyone has their own style, so it's good to assemble your own sandbox according to your own principles. 人それぞれ開発のスタイルが違うので、同じ原則やツールが全員に最適とは限りません。自分 の原則に合ったツールを組み合わせ、自分だけのサンドボックスを作ることで最良の開発体験 が得られます。 🌐https:/ /anatoliikmt.me/posts/2025-10-17-effective-webapp-flow/ Extended version of this presentation is in the blog:
auna
maltzj
garrettdimon
techseoconnect
bkeepers
marcelosomers
nikkihalliwell
tessaabrams
axbom
tmiket
inesmontani
kneath
