メモリモデル入門（Sequential ConsistencyとTotal Store Orderを理解する）
L1: r1 = y;L2: r2 = x; 並列プログラムには非決定性があるので、結果はひとつには決まりません。いくつかパターンを考えてみると、 r1, r2 = (NEW, NEW), (0, NEW), (NEW, 0) の可能性があることがわかります: S1 < S2 < L1 < L2 → (NEW, NEW)S1 < L1 < S2 < L2 → (0, NEW)S2 < L2 < S1 < L1 → (NEW, 0) では r1, r2 = (0, 0) という結果はありうるでしょうか？ 少し考えてみるとこれはなさそうに思えます： r1 = 0を仮定するこのときL1 < S2である各コアのプログラムの順序よりS1 < L1, S2 < L2である2と3よりS1 < L1 < S2 < L2という順序が決定されるS1 < L2よりr2 = NEWである 以上の「素朴な推論」は正
技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL
技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL はじめに 新たに書きました。 MySQLを使っても会社は潰れない 久々に記事を書いたのでどうぞお手柔らかに... 私が過去2年間で行った技術選定の成功と失敗を振り返り、その学びを共有したいと思います。 文才無いので淡々と箇条書きでいきます Twitterエンジニア垢作りました。エンジニアのお友達がいません。 @uncode_jp 注意 意見を押し付けるものではありません。ただ建設的な議論は大事だと思う。 自分の意見は明確に、歯切れのよい表現を意識している。人それぞれだよねみたいな感じに逃げたくない。技術選定に結論はある（過激）。 ただし技術選定にはコンテキストがあり、例えばプロダクトのフェーズや組織の事情によって当然結論は変わる可能性がある。 OSSの開発者さん達は偉大ですごい。あ
注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools
公開日 2024/05/28更新日 2024/12/02注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 現代のITサービスは、ユーザーに高品質で安定した体験を提供するために、より効率的で柔軟な技術選定が不可欠です。 本特集では、注目企業のシステムアーキテクチャ設計に携わるエンジニアの方々より、それぞれの技術選定における工夫と、未来を見据えた展望についてご寄稿いただいています。 各企業がどのように課題を乗り越え、開発生産性や品質を向上させるためにどのようなアプローチを採用しているのか ー この記事を通じて、実際の現場で活用される最先端の技術や戦略を学び、皆さんのプロジェクトに役立つ洞察を得ていただければ幸いです。 ※ご紹介はサービス名のアルファベット順となっております airCloset - 株式会社エアークローゼット会員限定コンテンツ無料登録してアーキテクチャ
ネットワーク越しリトライ考 - その手の平は尻もつかめるさ
ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン
Webフロントエンドの開発効率を高く保つための考え方
これまでいろんな現場でWebフロントエンド開発をしてきて、メンテナンスしやすく効率の高いWebフロントエンド開発をする上で重要になる考えが自分なりにまとまってきたので記事にしてみます。 Worse is Betterという考え方 自分が見てきた中でWebフロントエンドの開発効率が落ちてしまう一番の要因は、きれいで理論的には優れているアーキテクチャを構築しようとしてそれ自体がもたらす複雑性を支えきれないというパターンです。 少し前にフロントエンドにClean Architecture（以下CA、あの同心円の図を指すのは誤用に近いですがここではそれに乗ります）を導入する記事が流行ったと思いますがあんな感じです。ああいったクラスベースでDIが重要となる設計手法はサーバーサイドのJavaでSpringを使うのとは違ってReactがサポートしているものではないため、CAの実現自体に高い設計スキルが必
RESTに対する７つの誤解
海外に行くと、既に REST対SOAPの決着は付いている[1]（エンタープライズでもコンシューマでも）ように見えるのだが、日本国内で話していると、まだまだ混乱しているようだ。さながら2009年ごろの状況を見るようだ。そこで、今日は RESTに関わる誤解について、幾つか書いてみたいと思う。（殴り書きだが、あんまり聞かれるのでFAQとして。なお、以下の多くは、[2] サービスステーション：RESTの詳細でより詳細に書かれている。） 誤解1. RESTはマッシュアップ用のプロトコルで、サーバ間通信には適さないのではないか？ どこからこのような誤解が来ているのか理解に苦しむ。ひょっとすると、RESTはHTTPベースということが、ブラウザとWebサーバのやり取りという風に誤って捉えられているのかもしれない。 もちろん間違いである。 ブラウザとWebサーバとの間同様、サーバからサーバへの通信にもHTT
～師範、サウンドまわりがよく分かりません！～ (1/5)
編集S：ということで今回はサウンドまわりで。 さかもっちー：サウンドー。 あわしろいくや：オーディオとか音楽制作とかやりましたが、言われてみれば「フツーのサウンド」部分、やってなかったんですな。 瀬尾浩史：何で音が出てるのか分からない人、多そうなのペン。 hito：Flashまわりとかまで含めると魔境ですからねぇ。 編集S：魔境なの？ ミズノ：わりと大変ですねぇ。 あわしろいくや：ときどきワケわかんなくなりますな。 編集S：ワケわかんないのは自分だけじゃなかったのか……。 さかもっちー：大丈夫ですよ、整理していけばそこそこ何とかなりますよ！ 編集S：それでもそこそこなのか。 hito：ふふふ、今回は解説役をすべてさかもっちーさんにお願いする、という手が使える予感……。 さかもっちー：お、お手柔らかに……。 やまね：まあ、Linuxのサウンドまわりは、Windowsのサウンドまわりをきちんと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: Star Schema The Complete Reference: ADAMSON, Christopher: 本
公共R不動産