Microservices - Not a free lunch! - High Scalability -
« Paper: Scalable Atomic Visibility with RAMP Transactions - Scale Linearly to 100 Servers | Main | Google Finds: Centralized Control, Distributed Data Architectures Work Better than Fully Decentralized Architectures » This is a guest post by Benjamin Wootton, CTO of Contino, a London based consultancy specialising in applying DevOps and Continuous Delivery to software delivery projects. Microserv
Doing Business In Japan | Kalzumeus Software
[A quick note for readers of Japanese who may be looking for a translation which was here previously: 残念ながら、以前リンクされていた本文の和訳が翻訳者のサイトの更新により、アクセスできなくなりました。ご了承ください。] I’ve been in Japan for ten years now and often get asked about how business works here, sometimes by folks in the industry wondering about the Japanese startup culture, sometimes by folks wishing to sell their software in Japan, and somet
How to be a great software developer
CEO of Coca-Cola funded, Copyin.com. Rails/Angular developer, Entrepreneur & YC alum. Previously built and sold Clickpass. Disclaimer: This is a very long piece, much longer than I would normally write on any subject. I have edited it back but on sending it to friends to read they agreed that there was no one bit that should be cut. I hope that you feel the same. If there’s one thing that software
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
0から1を作ってみて - As a Futurist...
またしてもすばらしい記事を見かけたので思うところを書いておこうかと。 どんな分野であれ、ゼロから何かを生み出す経験をした人は、あとは事例を見るほどに、自身の経験が増していく。 0 から 1 を作った経験 – レジデント初期研修用資料 運用エンジニア 僕は一応曲がりなりにも「Software Engineer」であると思う/言うようにしている。だが、働き始めてこの方ずっといわゆる「運用」をしている。SWE でありながら、世の中に価値を生み出す・利益をもたらすようなアプリケーションは書いたことなく、そのアプリケーションの運用ばかりをやっているという状況。 ともすれば、アプリケーションをゼロから書ける必要性はなくて、むしろ誰かが書いたアプリケーション、もしくは OSS なミドルウェアとかフレームワークをきちんと読みこなして理解できる力の方が重要だから、実際コード読んだり使ってみたりすることに多く
サッカーのフロントが絶対すべきでないこと PART I - pal-9999のサッカーレポート
ちなみに例によって例のごとく、part２はありませんので、あしからず。 えー、今日は、ちょっとおもう所があって、お題の通りの話をしようと思う。ちなみに、この話をしようと思ったのは、 はてなは「絶対すべきでないこと」をやらかしたのか？ という記事を読んだのと、J1が開幕したんで、Jリーグの幾つかのチームの試合みた後だからである。インスパイアというか、これを読んでから、色々と昔の事を思い出したり、当時の記録を探したりして、記事かこうとしてグダグダやってた訳だ。書こうと思ったきっかけは、浦和の試合をみたからでもあるんだけどね。 上記の記事内にあるが、『Joel on Software』という有名な本な本があって、その中に、「あなたが絶対すべきでないこと PART I」というのがある。こいつは、プログラマの話なんだけど 私たちはプログラマだ。プログラマというのは、心の中では建築家なのだ。建築家が建
Firefoxが無駄に消費しているメモリの正体が突き止められる | スラド
Firefoxに長らく存在していた用途不明なヒープメモリ、通称「ダークマター」の発生原因のひとつが突き止められたらしい（マイコミジャーナルの記事）。このダークマターはFirefoxが使うメモリのうち結構な比率を占めているそうで、この問題が解消されるとメモリ使用量の大幅な減少が期待できるとのこと。 Nicholas Nethercote氏によってなされた報告によると、jemallocのメモリアロケート時に発生する未使用領域がダークマターの原因のひとつとなっているそうだ。jemallocでは確保したメモリを開放するときにフラグメンテーションが発生しにくくなるように、特定のサイズに区切ってメモリの確保を実施している。Nicholas Nethercote氏はこの領域を「スロップ」と呼んでおり、このスロップがメモリ食いの原因とのこと。スロップを完全に排除するには、jemallocの確保するメモリサ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【KAIZEN platform】性善説で成り立つストラクチャードカオス | geechs magazine