そうだコンテナー データセンターを作ろう (Part1. 用地選定編) – Made in container
20 歳で Azure をさわり始めて、早いもので 6 年経ちました。新卒で日本マイクロソフトに入社してもうすぐ 4 年、クラウドの中の人なはずなのに、我が家には何故か大量の NUC 8 台 (4 台 x 2 世代) と、512 GB の RAM を積んだサーバーがベッドの下で鎮座して、年々検証機が増える一方です。 そんな私ですが、ついカッとなった結果、タイトルの通りコンテナ (物理) データセンターを建てるに至ったので、何度かに分けて書いていこうと思います。変態 (誉め言葉) の皆さんはどうか生暖かい目で見守ってくださいませ。(※なお、あくまでも趣味の話であり、所属する組織とは一切関係ございませんのでご承知おきください。) ちょっとだけ真面目な話をすると、大学のころから Show and Tell をする (目の前で実際に動くものを見せながら発表すること) 環境におかれ、MS のサポート
null安全でない言語は、もはやレガシー言語だ - Qiita
これらは、表中の「リプレース対象言語」に挙げたように、多くのメジャー言語に対する代替手段でもあります。 Java の代わりには Kotlin や Ceylon が、 JavaScript には TypeScript や Flow が、 Objective-C には Swift が、そして PHP には Hack があります。 Python は自身に null 安全 を取り込みました。 Crystal は直接 Ruby と連携して使えるわけではありませんが、 Ruby 風の null 安全 な言語です。 Rust は C++ の代替を目指して開発され、 Firefox の一部で C++ のコードを置き換えるのに使われています 2 。 null が引き起こしてきた数々の問題を考えると、僕は、 null 安全 は GC （やその他の安全なメモリ管理手法）に匹敵するプログラミング言語の進化だと考え
Systems Performanceを読んだ
Brendan Greggによる“Systems Performance: Enterprise and the Cloud”を読んだ． Linux（Solaris）のパフォーマンスの分野でBrendan Greggという名前を聞いたことがあるひとは多いと思う．名前を知らなくてもが書いているブログやカンファレンスでの発表資料を見かけたことはあると思う．また彼が開発したFlame Graphにお世話になってるひともいるのではないか（ref. GolangでFlame Graphを描く）．とにかくパフォーマンスに関して常に先端にいるひとである． そんな彼がSystems（ここでいうSystemsとはCPUやメモリといったハードウェアとKernelやOSといったソフトウェアを指す）のパフォーマンスについて内部のアーキテクチャーを含め徹底的に解説したのが本書である．面白いに決まってる． 本書の根底
Next.js - Qiita
https://zeit.co/blog/next の翻訳です。 > Naoyuki Kanezawa (@nkzawa), Guillermo Rauch (@rauchg) and Tony Kovanen (@tonykovanen) > 2016年10月26日 私たちは、サーバレンダリングされるユニバーサルなJavaScriptウェブアプリのための小さなフレームワークであり、ReactやWebpack、Babel上に構築され、このサイト（訳注: https://zeit.co ）を動作させているNext.jsをオープンソース化することをとても嬉しく思います！ (Next.jsの"Hello World") Next.jsを使い始めるには、package.jsonを含む新しいディレクトリ内で次のように実行してください。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
あなたの知らない less の世界 - Qiita
