Tech BASE Okinawa 2023 2023/09/23(土) https://codebase.connpass.com/event/285901/ https://techbaseokinawa.com/
![技術選定の審美眼(2023年版) / Understanding the Spiral of Technologies 2023 edition](https://cdn-ak-scissors.b.st-hatena.com/image/square/ac7b6c6b3f1c9622596a383179ac7e64cf32796e/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fb1e1b471e9414fb8afd7020c5b82cc1f%2Fslide_0.jpg%3F27125064)
本項は「C# Tokyo オンライン「世界一わかりやすいClean Architecture」他」による発表の登壇原稿となります。過去に発表した.NET版の記事はこちらにアーカイブしています。 本稿のサンプルコード・PPTはこちらで公開しています。 「CC BY-SA 4.0」で公開していますので、気に入っていただけたら営利目的含め、ライセンスの範囲で自由に利用していただいて問題ありません。 github.com また動画を以下で配信しています。よろしければご覧ください。 世界一わかりやすいClean Architecture はじめに まず初めに、クリーンアーキテクチャの誤解されがちな二つのことについてお話させていただきます。 その上で、クリーンアーキテクチャの本質とは何か?押さえておくべき、本当に重要だと考えている三つの事について、お話しします。 注意事項 さて本題に入る前に、少し注意
Lightweight Architecture Decision Records とは? Lightweight Architecture Decision Records とは、 重要なアーキテクチャの意思決定を背景と結果とともに記録する手法 です。 Architecture Decision Records は ADR とも呼びます。 一般にこれらは Wiki や コラボレーションツールに保存されます。 ADRにお役立ち情報 以下のリポジトリに実際に ADR を導入する際の手順などがまとまっています。 github.com と言ってもシンプルなもので、実際にやることといえば テンプレートを決める ファイル名のフォーマットを決める アーキテクチャの意思決定をする 意思決定内容をテンプレートにそって記載してバージョン管理ツールに残す このぐらいです。 ツール ADRのためのコマンドライン
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
大阪でサーバーレスの話をしてきました クラスメソッドの開発を知る!大阪勉強会 第7回 これから始めるサーバーレス!〜最新サービス使いこなし術〜で スピーカーとして登壇しました。参加率が非常に高く、多くの方にご参加いただきました。誠にありがとうございました! 本記事では、勉強会でお話しした「目的別、サーバーレスアーキテクチャの教科書!これのときはこう!」の発表資料を公開します。 発表資料 内容 本セッションでは、これからサーバーレスを始める人向けに、サーバーレスとは何か?という話から、具体的にどのようなアーキテクチャを構築するのか?というお話しをさせていただきました。 サーバーレスアーキテクチャパターン 本セッションでは、サーバーレスアーキテクチャのパターンを20種類ご紹介しました。サーバーレスと言えるアーキテクチャは20種類では語りきれないほど沢山ありますが、今回は独断と偏見で選んでみまし
この記事はJavaScript Advent Calendar 2016の記事です。 今回は、2017年、新規にJavaScriptを書くならどんな設計をするか、というテーマで書いてみようと思います。2017年といっても、しばらくはこんな感じのアーキテクチャでやってきましたので、どんな構成でJavaScriptを設計してきたかという方が正しいかもしれません。基本的にはSPAをベースとしています。 また、最新のイケてる技術バリバリ使ってやるぜ、というよりは、堅牢で、はやりが変わってもメンテができるということを意識してみました。 DOMのレンダリング Virtual DOMを代表とした、DOMのレンダリングを行うライブラリをなにか採用します。特に理由がなければReactでいいと思います。Virtual DOMではありませんが、AngularでもDOM管理においてはさほど違いはありません。この2
TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。(参考文献の一覧は記事の最後にあります) 内容的には文献[2,3]を踏
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く