開発プロジェクトに新しく加わった時は、まずプロジェクトの理解が第一。しかし、全体像を把握できるようなドキュメントがなく、コードから断片的な情報をかき集めるしかない場合もあります。新参の開発者がスムーズにプロジェクトを理解できるよう、大規模なプロジェクトでは「プロジェクト全体のアーキテクチャ」を示した「ARCHITECTURE.md」を添えた方がよいと、エンジニアのAleksey Kladov氏が指摘しています。 ARCHITECTURE.md https://matklad.github.io//2021/02/06/ARCHITECTURE.md.html Kladov氏はオープンソースプロジェクトの開発に携わる中で、「プロジェクトのアーキテクチャに対する知識量」によって開発スピードに大きな差が生じると気づいたとのこと。アーキテクチャに関する知識がない開発者にとって、大量のコードは「バラ
Home InfiniBand C＃ Docker Linux Raspberry Pi RouterOS Windows Mkdocs プライバシー・ポリシー WSLのアーキテクチャ WSLで実現できること Windows Subsystem for Linux(WSL)は少ないオーバーヘッドでGNU/LinuxのCLIプログラムを実行できる環境を提供する機能です。 Windowsでは「Portable Executable」という形式の実行ファイルのみを動作させることができます。 しかし、Linuxなどで利用されている実行ファイルは「Executable and Linkable Format(ELF)」と呼ばれる形式であるため、通常はWindows上で動作させることはできません。 Linuxのプログラム(ELFバイナリ)を実行するには LinuxのCLIプログラムを利用できる環境を用
Firefox Browser Architecture Mission Change Mozilla. Investigate big technical challenges and produce engineering programs to address them. Our Conclusions This is a list of our findings that we’re reasonably happy with so far. Documenting our output looks at how we’re going to communicate with the rest of Mozilla. Extracting Necko considers whether it’s feasible or worthwhile to extract Necko — G
このブラウザ バージョンのサポートは終了しました。サポートされているブラウザにアップグレードしてください。
原文 Give me back my monolith - Craig Kerstiens (English) 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket 原著者への翻訳報告 2620日前 Twitterで報告済み 2620日前 原著者承諾済み 編集 どうやら、マイクロサービスの話題の盛り上がりはピークを過ぎ始めているように感じます。「モノリスを150個のサービスへ移行した話」みたいなブログ記事を、週に何度も見かけるようなことはなくなりました。最近よく聞くのは、むしろ「モノリスが嫌なわけなんじゃなくて、性能をいい感じに保ちたいだけなんだ」といった話です。実際に、マイクロサービスをモノリスに戻す移行事例も見たことがあります。 大きな一つのアプリケーションをいくつもの小さなサービス群へ持っていくためには、たくさんの新しいことに取り組まなければなりませんし、かつてはシ
Joel Spolsky / Fujimoto訳 2008年3月1日 木曜 誰もがMicrosoftのHailstormに関する誇張たっぷりの発表に興奮していたのは七年前の今日のことだった。そこでMicrosoftは「Hailstormは日々の生活のテクノロジーを、ユーザーに代わって、そのユーザーの管理の下で互いに連携して動くようにいたします」と約束していた。 それで、Hailstormって一体何だったの？ これは、未来のOSはネット上に(つまりMicrosoftのクラウド上に)あるとして、Windows Passportを使えばどんなものにもログオンできるようにし、そこにユーザーのあらゆるデータを置いておけるようにするというものだった。しかし、ふたを開けてみれば、こんなあらゆるデータを置いておける場所なんて誰も必要としていなかったし、自分のデータを全部預けるほどMicrosoftを信頼し
* この投稿は米国時間 5 月 12 日に投稿されたもの（投稿はこちら）の抄訳です。 Posted by 佐藤一憲, Staff Developer Advocate, Google Cloud Cliff Young, Software Engineer, Google Brain David Patterson, Distinguished Engineer, Google Brain Google 検索、ストリートビュー、Google フォト、そしてGoogle 翻訳。これらのサービスに共通するのは、いずれもニューラルネットワーク（NN）の計算処理の高速化のために Google の第一世代の Tensor Processing Unit (TPU) が用いられている点です。 Google の第一世代 TPU は、昨年の Google I/O で初めて紹介され、今年 4 月にはその性能
ネットワークレイテンシ縮めるにはどうすればいいか考えてたときにひょっとしたら「CBEならできんじゃね？」とか思って、つまり、NICから直接SPEのLSに入れて、SPEからNICのレジスタ叩けば、DRAMのレイテンシも存在しないTCP/IPアプリケーションが作れるのではないかと思ったんですよね。 まあ、実験環境ないのでそう思った以上のことは無いけど… そのついでに、どのぐらいCBEがよく考えられていたか書いてもいいかなと思ったので書いておく。 (個人的に、Cellという表記/呼びかたはなんかあまり好きではなくて、Cell/B.E.もしくは、CBEと呼ぶので、以下、CBEはそういう意味で読んでほしい) はじめに CBEがあんまり普及しなかったとか、半導体業界の背景とか色々あって、多分新規アーキテクチャで世界制覇目指すとかやるのはCBEが最後になる可能性があるし(狭い部分では新規アーキテクチャと
Google エンジニアの Steve Yegge 氏、Google+ への懸念を漏らす http://japan.internet.com/busnews/20111013/8.html で記事になってたけど、原文とちょっと要旨が変わっちゃってサービスへの警鐘みたいになってしまってたので、全文訳してみた。くそ長い。お暇な方どうぞ。 （2011/10/19 08:14）ありがたい誤訳の指摘をいただいたので3カ所修正。 Stevey の Google プラットフォームぶっちゃけ話 僕は6年半ばかり Amazon にいて、今はそれと同じくらい Google にいる。この二つの会社について強く感じることは（しかもその印象は日々強まるのだけれど）、 Amazon は全てにおいて間違っていて、 Google は全てにおいて正しいということだ。そう、やりすぎな一般化だけど、驚くほど正確だと思う。いやも
Wikipediaといえば世界で第5位の訪問者数を誇る巨大サイトですが、システム運営に携わる人間は世界でわずか6人、しかもこれはボランティア込みという恐るべき少人数で、第4位のFacebookのサーバ数が3万台を超えているのに対して、Wikipediaはわずか350台で運用している……などというような感じで、知られざる今のWikipediaの実態が「KOF2010」にて本日行われた講演「Wikipedia / MediaWiki におけるシステム運用」で明かされました。 登壇したのはWikipediaを運営するWikimedia財団のエンジニアであるRyan Lane氏で、100席ある座席は満席になり、隣の中継の部屋まで人があふれているほどの盛況っぷりで、語られる内容もなかなか参考になることが多く、今後のGIGAZINEサーバにも活かせそうな内容でした。 というわけで、「Wikipedia
● DCIが面白い件 DCI凄い！ヤバイ！ 「DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien」(翻訳) http://d.hatena.ne.jp/digitalsoul/20100131/1264925022 前に読んだときは難しすぎて(長すぎて)途中で挫折したけど、今改めて読んだらDCIは凄いと気付いた。以下、まとめ。 今回、内容理解の決め手となったのは「前半部分を読まない」ことだった。 そんな無謀な読み方(読んでないのだけれど)をした私の理解なので、 もちろん間違いはあるはず。 という前提で、 ツッコミを入れる気満々なテンションでどうぞ。 古来からプログラムの中心は＜データ＞であった なぜなら、それが設計の中で一番変化しにくい要素(箇所)であるから そして、＜データ構造＞とそれに対する＜処理＞の2つで考えるようになった (手続き型
もっと詳しい方のフォロー募集です アプリケーションがマルチスレッドになってもネットワーク処理が分散されなければマルチコアを活かせない典型的な例です。id:viverの古橋さんがs100kpsとしてあげていた件にも近いかも。 memcachedで現象を確認します。最近のmemcachedはマルチスレッドで動くようになっているので、まずはそれを確認します。 $ memcached-tool localhost stats|grep threads threads 4 スレッドが4つで起動しています。 負荷がそれなりにある状態(8000req/sec程度)で、コマンドラインでtopを開き、「1」キーを押して、CPUごとの使用率を表示します。(例はFedora8 kernel-2.6.23) Tasks: 77 total, 1 running, 76 sleeping, 0 stopped, 0
suicaのサーバーはみんなの知らないところで、実はたまに落ちているそうだ。 だがシステムが止まることはない、計算上センターは3日ぐらいは止まっていても大丈夫だそうだ。 だからサーバーが落ちたなどとニュース沙汰になることは殆ど無い。 suica開発陣頭指揮をされていたかたが、その実績をまとめてと頼まれ、博士論文にしたそうだ。 suicaの実例を述べるだけだと技術論文になってしまうので、一般化して論文を書きあげたそうなのだが、審査に携わった専門家の人達はそんなものが動くわけないだろうといったらしい。しかし現実問題としてsuicaは動いてしまっている。 本人いわく、だってそれで動いちゃってるんだもん。だそうだ。 実装は時として奇妙に見えるかもしれない。 フィールドには神がいる。 …その意や、なんで落ちても大丈夫かなどはまた後ほど。 スイカのセミナー 昨日はスイカのセミナーだった。 JR東でスイ
これを書こうと思ったキッカケは、奥一穂さんの「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」っていう、最近モヤモヤと感じていたことをうまく説明してくれてる記事をみたこと。 年始からちょくちょくサーバの運用環境を物色しながら考えていたことと見事にシンクロした。だいたいの要旨はTwitterのほうでも書いたのだけれど。 ムーアの法則でどんどん向上する技術にくらべ、人間のキャパシティは変化しない定数項として考えていい。だとすれば、そうやって向上する性能を、人間の労力を削減する方向で使えてはじめて、「技術が競争優位性を生む」といえるだけの破壊的な価値がでてくるということになる。 では、現在の技術トレンドを活用することで減らせる「人間の労力」とは何か。 それは、過去10年あまりで定着した、これまでの（そして今なお）Webアプリケーションの定番構成である、「ロードバランサ、ア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
%26utm_content%3Dlivedoor)
http://yebo-blog.blogspot.com/2010/11/android_25.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogspot%2FdtWw+%28yebo+blog%29&utm_content=livedoor