2024/11/18に、Flutterの公式ドキュメントより、Flutterの設計についての記載が公開されたので、まとめてみます。 直訳やLLMの翻訳では分かりづらい箇所をなるべく理解しやすいように噛み砕いて日本語訳しました。 初めに 以下の内容が学べます アーキテクチャの利点 一般的なアーキテクチャ原則 Flutterチームが推奨するアーキテクチャ MVVMと状態管理 依存性注入 堅牢なFlutterアプリケーションを作成するための一般的なデザインパターン アーキテクチャの利点 優れたアーキテクチャには、エンジニアとユーザーにとってに多くのメリットがあります。 保守性 - 時間の経過とともに変更、更新、問題の修正が容易になります。 スケーラビリティ - コードのコンフリクトを最小限に抑え、より多くの人が同時に同じコードを変更することを可能にします。 テスト可能性 - 入力と出力が明確に定
コンテナの話（AWSコンテナ系アーキテクチャの選択肢を最適化する）をした時にメンテナンス画面の表示についても軽く触れました。 改めて整理すると他にもいろいろあるということで、上から順に超ザックリと並べていきたいと思います。一応 AWS でを想定していますが、一般的な方法論でもあるので、どこだろうと何かしらの足しにはなるかもです。 条件 どのようなメンテナンス状態にしたいかによりますが、満たすべき条件はおそらくこのようなものがありますよ、ということで整理します。 １回の変更操作で、一括したメンテインを保証すること 管理者はメンテにならず通常アクセスする手段があること メンテ機能の仕込みによって悪影響がないこと 希望するメンテ用レスポンス内容を実現可能であること 静的 or 動的 Status Code 503 Content-Type レスポンス・サイズ 例えば DNS のレコード値を変更し
2024年7月13日の大吉祥寺.pmで発表した「古典ドメインモデル(パターン)の解脱」のスライドログです。 この2冊で書かれているドメインモデルパターンを「古典」の対象にします。 ドメインモデルパターンは「複雑さに対処するため」と述べています。が、古典では次の2点が課題となっていると考えます。 これら2点について個別に見ていきます。 まずドメインモデルパターンから。 Patterns of Enterprise Application Architecture(以降PofEAA)ではこのように定義されています。 PofEAAのドメインロジックの章で使われている「収益認識」の例を取り上げます。 ContractやProduct, RecognitionStrategyなどといったクラスが作られて、これらのインタラクションでビジネスロジックが実現されると説明されています。 では、これらのドメイ
import "./App.css"; import { Link, Route, Switch } from "wouter"; function Nav() { return ( <nav> <Link to="/">Home</Link> <br /> <Link to="/about">About</Link> </nav> ); } function Home() { return ( <div className="App"> <h2>Home</h2> <Nav /> </div> ); } function About() { return ( <div className="App"> <h2>About</h2> <Nav /> </div> ); } function App() { return ( <> <Switch> <Route path="/" compo
ソフトウェアアーキテクチャメトリクス - Forkwell Library #44 での発表資料です https://forkwell.connpass.com/event/309739/ 動画: https://www.youtube.com/watch?v=C52rYX_E9bA …
症状検索エンジン「ユビー」 では、ローンチ当初から Firebase Auth (GCP Identity Platform) を使っていましたが、OIDCに準拠した内製の認証認可基盤に移行しました。 認証認可基盤そのものは m_mizutani と nerocrux と toshi0607(退職済) が作ってくれたため、僕は移行のみを担当しました。 結果として、強制ログアウトなし・無停止でビジネス影響を出さずに、年間1000万円以上のコスト削減に成功しました[1]。その移行プロセスについて紹介します。認証認可基盤そのものの紹介はあまりしません。 移行した理由 大量の匿名アカウント ユビーでは、アクセスした全ユーザーに対して自動的に匿名アカウントを発行しています。これにより、ユーザーがアカウント登録しているかどうかに関わらず、同じID体系で透過的に履歴情報等を扱うことができます。アカウント
「マインクラフト」プレイヤーが催した「Minecraft違法建築イベント」が、現実にはあり得ないカオスな建物が生み出されて話題を呼んでいます。「違法建築」とは穏やかでないですが、要はオンラインで集まり、建物を好きなように建て増しして遊ぼうという試み。そうして出来上がった、複雑怪奇な構造が壮観です。 経過だけでワクワク 雑多なようでいて、全体像は調和したように見える 主催はマインクラフト建築コミュニティ（@mc_kenchiku_com）。海に囲まれた世界で、人々が生き抜くために高い建物を作り、ひたすら“上”を目指す――そんな世界設定の下にプレイヤーを募りました。開催に際しては、あらかじめ素朴な土台を用意。そこに大勢で気ままに増築していこうという趣向です。 基盤となったプレーンな土台。ここからああも変わるものか イベントには見学者を含め累計で168人が参加。ルールが「建築様式不問」だったこと
Twitterの内部構造を読解してみる 前口上 Twitterのようなマイクロブログサービスでは短時間で書き込みも多く、特にタイムライン周りは単にRDBのデータを出し入れるするだけではスケールしなくなります。 インターネット上に断片ながらTwitterの中の人がアーキテクチャについて解説した記事や動画がいくつか落ちていたので、Twitterがタイムラインをどうやってキャッシュしているかについてまとめてみたいと思います(推測を含みます)。 Twitterのテーブル構造 単純なTwitterのテーブル定義をRDBで定義すると以下のようになると思います。 tweets ツイート id user_id contents tweet_at followers フォロワー source_user_id destination_user_id users ユーザー id user_name timeli
古代ローマの人々は非常に高い建築技術を持っており、約2000年前に作られた道路や水道橋、港、建造物などが現代に至るまで残されています。「一体なぜ、古代ローマのコンクリートは2000年が経過しても大丈夫なほどの耐久性を誇るのか？」という謎について、マサチューセッツ工科大学(MIT)が率いる国際的な研究チームが調査したところ、「コンクリートの製造プロセス」にヒントがあることが明らかになりました。 Hot mixing: Mechanistic insights into the durability of ancient Roman concrete | Science Advances https://www.science.org/doi/10.1126/sciadv.add1602 Riddle solved: Why was Roman concrete so durable? | M
1. はじめに FAT32 ファイルシステムを実装する必要があった (趣味) ため、本記事では FAT ファイルシステム (メインはFAT32) の仕様を出来るだけ分かり易くまとめました。 なぜ FAT32 なのか？ 全てのOS (Windows, Linux, MacOS) や Raspberry Pi4 のブート用ファイルシステムでもサポートされおり、非常に使い勝手が良い 少なくともファイルのリード操作だけに限定した場合に実装がとても簡単で、Raspberry Pi4 のデバイスで SD カード上のファイルにリードアクセスする場合に便利 ただし、FAT は暗号系の機能がサポートされていなかったりするので、実際の組み込み機器の Linux 系で利用するファイルシステムだと Ext2/Ext3/Ext4 など他のファイルシステムの利用が多いとは思います。 2. FATファイルシステム概要
こんにちは、Sansanプロダクト開発部の清水です。 ある程度のアプリケーションの大きさだと当たり前に使われる事が多い「レイヤードアーキテクチャ」の自分が考える設計のポイントや、実際に運用する際のポイントについて書いてみようかと思います。 基本的な話なので「今更かよ」って感じがしますが、実際に設計、運用する際には様々な考慮事項のあるものだと思うので、知ってる人にとっても復習にでもお役に立てればと思います。 そもそもレイヤードアーキテクチャって何? 概要 一言でいうと、アプリケーションを作る際にそれを構成する部品を、それぞれ責務が定義された論理的なグループにまとめて整理し、それぞれのグループ間のやり取りの仕方を決めておこうという事です。 このグループ間のやりとりにおいて、一方向かつ隣接するグループとしかやりとりを行えないようにする事が多く、層状になるのでレイヤードアーキテクチャと呼ばれます。
はじめに Twitter、Qiita、Zenn...といろんなところから情報収集するのはいいのですが、それぞれの有益な情報をそれぞれのサイトにお気に入りとして保存しているので、必要な情報を探すだけで一苦労です。 ここで一覧にしてまとめておくことにしました。 ただし、特定の言語に依存するような記事はあえて排除しています。 皆さんにとっても有益な情報があると、この記事を公開して良かったなと思います。 また、皆さんのオススメの記事がありましたら、コメントなどで教えてください。 コミュニケーション 質問 質問は恥ではないし役に立つ https://qiita.com/seki_uk/items/4001423b3cd3db0dada7 新卒からの質問をソシャゲっぽい仕組みにしたら捗った話 https://qiita.com/ysktsuna/items/fced3a9515c8f585ca50 会
Fresh は Deno 製の Web フレームワークです。事前のビルドを必要せず、エッジでレンダリングを提供するという特徴があります。また Islands Architecture を採用しており、デフォルトではクライアントに JavaScript が配信されることがありません。 この記事では Fresh を使用して記事投稿サービスのチュートリアルを紹介します。 完成したサイトは以下のようになります。 ソースコードは以下のレポジトリから確認できます。 インストール Fresh を始めるには Deno の v1.22.3 バージョン以降が必要です。Deno をまだインストールしたことがないのならば、installation を参考に Deno をインストールしましょう。 # Shell (Mac, Linux) $ curl -fsSL https://deno.land/install.
はじめに chike0905.hatenablog.com この記事は大変楽しく拝読したが、ブロックチェーン素人ながら気になる点がいくつかあったので指摘する。要旨は以下である。 タイトルで「できない」と言ってる割には「できるけど筋が悪い」だけに見える 研究中で結論が出ていないトピックを「できない」と呼ぶのは違うのではないか 文体が学術めいている割には用語の使い方がやや雑に見える ブロックチェーンに「不可能」な事にフォーカスすべき 浮足立つ界隈に対して問題提起するならば的を絞って指摘すべきで、容易に解決可能そうに見えてしまう批判はかえって混乱を招く恐れすらある ノードの独立性 各自で検証し、他のノードに依存するプロセスは本定義のブロックチェーンの動作の中には含まれない。 従って、他のノードに何かを問い合わせる必要もなく、信頼する第三者などは存在しない。 この部分はあまり正しく理解している人が
今回はIntel Visionの話でも、と思ったのだがオンラインでの情報配信は5月18日からと発表の1週間遅れになっており、現時点では基調講演くらいしか説明する内容がないので後送りにさせていただき、AIプロセッサーの話をしよう。Linley Spring Processor Conference 2022で発表されたTetraMemのmemristor（メモリスタ）だ。 メインメモリーだけで演算処理を行なう高速化技術 In-Memory Computing AI処理の効率化、というテーマでのアーキテクチャーの提案はいろいろあることについてはこれまでいくつか紹介してきたが、その1つにIn-Memory Computingがある。 要するにメモリーと演算器が別々に置かれており、かつ演算にあたっては「メモリーからデータを取り出す」「演算結果をデータに格納する」にそれぞれ無駄に消費電力がかかる(デ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
