タグ

アーキテクチャに関するWackyのブックマーク (6)

  • ソフトウェアアーキテクチャの歴史 - tasuwo's notes

    改めて ソフトウェアアーキテクチャ GUI のアーキテクチャの歴史を調べてみたくなった。来の MVC とは何か?何が正しくて何が間違っているか?も重要なのだが、それよりは、なぜそれが生まれたのか?何を解決しようとしたのか?どのような問題点が生まれて、それをどう工夫して解決・発展してきたのか?を知りたい。しかし、そういうことがまとまっている日語の情報が少ないので、自分で色々かいつまんでメモしておく。 MVC の原点は 70 年代にまで遡り、実装としては Smalltalk-80 のクラスライブラリとして実装されたのが最初だと思われる。しかし、後世に大きな影響を及ぼしたポイントをいくつか持ちつつも、当時のアーキテクチャが現代においてそのまま利用されているケースはほぼないといっていい。したがって、単に MVC といった時には大抵最初期の MVC を指すことは少なく、区別するために最初期の M

    ソフトウェアアーキテクチャの歴史 - tasuwo's notes
  • 変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita

    この記事は、設計・アーキテクチャ Advent Calendar 2018 の第7日目の記事である。 はじめに この記事では、IT業界19年目の僕が実践している変更に強いアーキテクチャについて、出来るだけ難しい表現を避け、教科書的なありきたりな内容ではなく現場の肌感覚に近い切り口で「超ザックリ」な解説を試みてみようと思う。 普段自分がよく用いている実装パターンの紹介ともいうべきかも知れない。 この記事で説明すること いざ「変更に強いアーキテクチャとは」とズバリ訊かれても、一概に「これだ!」という答えはない。 プログラミング言語や、フレームワークによっても条件が異なるし、利用可能な技術や開発チームの特性、業務要件や運用要件の特性によっても様々であるし、インフラや開発プロセスまで含めて考えると考慮すべきことは無限にある。 ここでは主にソフトウェアの構造という観点から、"変更に強い" ということ

    変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita
  • 巨大企業のサーバー構成や内部ツールを覗く - 発明のための再発明

    はじめに この記事は設計・アーキテクチャ Advent Calendar 2018の1日目の記事です。 大きなサービスを支えるのは一筋縄では行かず、考えることは多くあります。しかし、ありがたいことに巨大な企業の中にも自社のサーバー構成やそれを支えるツールを公開している企業があります。 この記事では、彼らの叡智に触れるため、有名企業の事例を取り上げ要約をします。 各事例には元記事へのリンクを書いているので、興味があればリンク先も覗いてみてください。 ※新しいものばかりではないので、古くなっていたり既に別の方法に移行している可能性があることに注意してください。 LINE: 25k/secのスパイクをさばくアーキテクチャ 元記事: 25K request/secをさばいた「LINEのお年玉」のアーキテクチャの裏側 最初に紹介するのは、LINEが2018年に実施した、「LINEのお年玉」というイベ

    巨大企業のサーバー構成や内部ツールを覗く - 発明のための再発明
  • なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita

    このエントリーは、Engineering Manager Advent Calendarの25日目、最終日の記事です。 はじめに 拙著「エンジニアリング組織論への招待」では、ソフトウェア自体の構造とソフトウェアを作り上げる組織の構造が似てしまうという「コンウェイの法則」についてたびたび引用しました。 この「コンウェイの法則」は、ある一定規模の組織で働いたことのあるエンジニアであれば、実感を持って捉えることができるのでしょう。 しかし、何故、どのような力が働いて、「組織構造」と「ソフトウェアの構造」が似通ってきてしまうのかと問われると説明の難しいものです。 拙著においては、ロナルド・コースの取引コスト理論をベースに、社内取引においても取引コストが存在し、その取引コストがソフトウェアの構造をも変えていくという説明を行いました。 記事は、さらに踏み込んで、組織やビジネスに働く力学と、システムで

    なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita
    Wacky
    Wacky 2018/12/25
    “組織の構造とシステムの構造が相似形になってしまうのであれば、プラスの価値のある組織からは優れたアーキテクチャが生まれ、逆にマイナスの価値を持った組織からは技術的負債が生まれるようになるということが導
  • 最近のアプリ界隈での「設計」の違和感 - なるようになるかも

    アプリ界隈で「設計」の話をするときに MVC / MVP / MVVM のような「設計パターン」だけが語られるようになった気がする。 往々にして、「アプリの規模によってどれを採択すべきかは変わる」みたいなお茶を濁すような結論で終わることが多い。 私的な結論 「設計」と、「設計パターン」は別物だと思う。 「設計」のレベルを上げたい。 アーキテクチャシンドロームから抜け出して、価値のあるものを作りたい。 以下、思うところのメモ。 MVC は古い / 劣ったやり方か? MVC は Model をどう構築するかについてとくに規定していない。 MVC への批判をするときに、FatVC が持ち出されることが多いのですが、FatVC を実装してしまうのは単に実装者の能力不足だと考えていて、MVVM を採用しても FatVM を作るだけだと思っている。 また、比較的新しめの Flux アーキテクチャは、良

    最近のアプリ界隈での「設計」の違和感 - なるようになるかも
    Wacky
    Wacky 2018/06/14
    “作ったことも触ったこともないものに対して、どれが最適かなどという判断を下すことなど不可能なので。”
  • Meltdown, Spectre で学ぶ高性能コンピュータアーキテクチャ - FPGA開発日記

    巷ではIntel, AMD, ARMを巻き込んだCPUのバグ "Meltdown", "Spectre" が話題です。 これらの問題、内容を読み進めていくと、コンピュータアーキテクチャにおける重要な要素を多く含んでいることが分かって来ました。 つまり、このCPUセキュリティ問題を読み解いていくと現代のマイクロプロセッサが持つ、性能向上のためのあくなき機能追加の一端が見えてくるのではないかと思い、Google, Intelの文献を読み解いてみることにしました。 が、私はセキュリティの専門家ではありませんし、過去にデスクトップPC向けのような大規模なCPU設計に参加したこともありません。 あくまでコンピュータアーキテクチャに比較的近い場所にいる人間として、この問題の質はどこにあるのか、可能な限り読み解いていき、現代のマイクロプロセッサが持つ高性能かつ高機能な内部実装について解き明かしていき

    Meltdown, Spectre で学ぶ高性能コンピュータアーキテクチャ - FPGA開発日記
  • 1