あー、やっとアーキテクチャ（システムの構造、の意）が完全に変わるんだ。っていう感想。 私が交通系ICカード開発の仕事に関わってたのがもう20年近く前で（正確には15〜6年前）その頃から今日まで全くアーキテクチャの基本構造が変わってなかったんですよ。 www.watch.impress.co.jp www.itmedia.co.jp 20年変わらないってのも、なかなかすごいよね。ある意味、完成された構造だったわけですけども。 とはいえ通信速度が向上したら、ネットワークの信頼性が向上したら、いずれこの形になるのは想定されてました。 逆に言うと20年経ってようやく「新しい形式に移行できるぜ！」ってなったわけで、検証もこの間に重ねられてきてたって事だと思います。 思いつきで移行なんかしないですよ、鉄道会社の方々って。 だって障害発生したらニュースになるんだものｗ 私は過去に下記のようなブログとかも
September 15, 2021 @ iCARE Dev Meetup #25
DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット（といいつつほぼ忘れかけている）なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用（採用できているとは言っていない）しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい
CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して
2. 2Copyright©2017 NTT corp. All Rights Reserved. 諸説あるが、ここでの定義は「部分的な故障を許容するシステム」の事 複数台のコンピュータを接続して信頼性を高めたり データが途中で化けても再送したり訂正したり 一部のコンピュータが突然故障しても引き継いだり 故障を設計の一部に組み込む事が必須となる 分散システムとは 3. 3Copyright©2017 NTT corp. All Rights Reserved. • 世はまさに分散システム戦国時代 • Hadoopを皮切りに次々出てくる巨大分散OSS • シリコンバレーでも分散ミドルウェアベンチャーが多数出現 • 高信頼なシステムを作ろうと思った場合には複数台のマシンによる高可用構成 が前提になる • Google、Facebook、Amazon等はもちろん • 金融、流通などのエンタープラ
Enterprise Business Rules ビジネスルールの為のデータ構造を持ったオブジェクト。 データの実態を表す場所。 Application Business Rules ビジネスルールを操作する場所。 つまりこのアプリケーションで何ができるかを実践します。 Interface Adapter 外部からの入力、データの永続化、表示を担当する場所 Frameworks & Drivers Webフレームワーク、DB操作の実際に担うソース、 フロントエンドのUIなどがここに所属しています。 外側のレイヤーの要素を直接参照してはならない 上記の図におけるこの矢印は依存を表しており、 内側のレイヤーから外側のレイヤーの要素への依存を禁じます。 ここでいう依存とは要素(構造体、変数など)への直接参照をさせないということです。 では外側のレイヤー要素を参照せざる得ないは、どうするのでしょ
電子情報学特論： Chromium のアーキテクチャを解き明かす 〜 EEIC の授業が生きるプロダクトの世界〜 Kentaro Hara 2020 April (๑>ᴗ<๑) * * * *
autoscale: true theme: Plain Jane,5 複雑なJavaScriptアプリケーションを考えながら作る話 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info #jsprimerを書いています JavaScript入門書に興味ある人はウォッチ :star: :warning: 注意 :warning: 作成するアプリケーションによって必要な構造は異なります 今回の話はある程度の規模で複雑性を持つクライアントサイド ライブラリ抜きで数万LOC >= 長期的にメンテンナンスや変更が発生するアプリケーション サーバサイドレンダリングはしないクライアントアプリケーション 3行でOK 複雑なJavaScriptアプリケーションを作るにあたりドメインモデルをどう実装するか悩んだ 色々と試行錯誤した
elm-lang.orgの2016.5.10のブログエントリ farewell-to-frp ElmクリエータのEvanによる最新版0.17のアナウンス 「Reactiveとか、非同期データストリームとかObservableとか、まあええけど、敷居上げすぎじゃね？」 「じゃあSignal外して」「脱FRPしとくか」（今回） 「WebAssembly来るかも？」 「じゃあサクッと移行できるようにJSとのインフェース最小にしとくか」 「いつでもどこでも脱AltJSできるように準備しとくか」 「クロスコンパイルとかはいいわ」 「OSS化しましたので皆様使って頂けたら。。。。」 「神頼み？それじゃあエコシステムはできんわ」 「フルタイムでElm開発できるとこに入っとく」(Preziにjoin） 「Chigaco大でFunctional Programmingの講義をElmで通してもらった」 htt
1974年東京生まれ。最近、史上初と思う「ダムライター」を名乗りはじめましたが特になにも変化はありません。著書に写真集「ダム」「車両基地」など。 （動画インタビュー） 前の記事：エレベーターで富士山の高さ分昇る ＞ 個人サイト ダムサイト 「ダムライター」などと名乗っているけれど、僕はこれまでどんなメディアでもダムの記事を書くときや話をするときに気をつけてきたことがある。 ダムの是非についての判断をしない、ということだ。 しないというか、もっと正確にはできないと思うのだ。だって、自分の家の前を流れている川だったらともかく、よその地域の川にダムが必要かどうか、つまり洪水や水不足が起きるかどうかなんて、ふつうの人には分からないでしょ？ だからそんな無責任な物言いはできないし、地域の反対が多くて中止になったらその判断を尊重する。だけどその代わり造ったものは全力で応援するし、洪水や渇水に活躍したら
スポーツを観るために、生まれてきた(挨拶) Sky on Kasumigaoka; D7000 AF-S DX Nikkor 18-55mm f/3.5-5.6G VR (18mm) f/4 1/600s ISO-400 DxO FilmPack 5.1: Kodak Ektachrome VS 100 何か、あんま建築畑とかエコノミスト畑とか納税者畑でない、一人のスポーツファンとしての視点とポジトークとして。 因みに、前提としては旧霞ヶ丘は多分解体して作り直すこと自体は妥当だった、とは思ってます。確かに、屋根が無ければ晴れた日の青空は綺麗なんだけど、突貫である程度疲弊はしてただろうし、都心の真ん中に規格の古い陸トラを置くスタジアムを延命させるのも、この大都市のインフラとしてはやや足りないものではあったろう、と考えると。 メディアとかに出回っている記事を見る限り、過去の五輪の会場と比較して
先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。 背景 データベース接続の永続化とはなにか データベース接続のオーバヘッド データベース接続の永続化手法 コネクションプーリングとはなにか コネクションプーリング: ドライバ型 コネクションプーリング: プロキシ型 コネクションプーリング全体について PostgreSQLとMySQL 参考資料 まとめ 背景 2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャの話とWebアプリケーショ
2023年03月31日追記：この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We
よく訓練されたApple信者、都元です。 以前、【AWS】VPC環境の作成ノウハウをまとめた社内向け資料を公開してみるという記事を書きましたが、そこから半年経ち、状況も変わって来ましたのでアップデートを行いたいと思います。 以前のエントリーを読んだ方は、忙しい場合は下記の「2013年10月版からのアップデート」だけを読むといいかもしません。 VPCを利用する理由 AWSは、あらゆる規模のプロジェクトに対応するインフラを提供しています。前述のサーバ数千台規模のプロジェクトしかり、1台構成しかり。大規模プロジェクトであれば当然、オンプレミスと同様にネットワークインフラについての設計を綿密に行う必要がありますが、では、中小規模のプロジェクトにおいてはネットワークの設計をする必要はないのでしょうか。 AWSでは、VPCという「ネットワーク環境」を構築するサービスを提供しています。しかもVPCの利用
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
