Kindle Paperwhite - 最高の読書体験、そのための電子書籍リーダー反射しないディスプレイ―明るい日差しの中でも読みやすい 片手で読書:一般的なタブレットより30%軽い 4GBに増えたストレージで数千冊を保存(一般的な書籍の場合) 数時間ではなく、数週間持続するバッテリー タブレットのバックライトよりも目に優しく読みやすいフロントライト搭載 新機能Word Wise対応の洋書なら、難しい単語に自動で類義語が表示されるから、英語学習にもぴったり
Kestrel:Reliable Read
メッセージングシステムで、dequeue 後に正しく処理できずに異常終了したらどうなるのか? Twitter などで利用されている Kestrel には reliable read という仕組みがあり、一度 dequeue したアイテムの処理中にエラーが発生しても、キューの先頭に enqueue できる。 この動作を実際に確認してみた。 Reliable Read Command Memcached プロトコルで reliable read をするには、キューからアイテムを取得する際に / に続けて以下のオプションを指定する。 /open : 一時的に dequeue /close : dequeue を確定 /abort : dequeue を取り消し、queue の先頭に enqueue Reliable Read Examples 以下の4パターンについて、キューの処理と peek
リアルタイム分散処理Stormの耐障害性は？ - Tech-Sketch
リアルタイム分散処理とは 「ビッグデータ」処理のためにHadoopを用いますと、「複数のマシンに大量データ処理を分散して飛躍的に性能を向上する」ことが容易に可能となります。 ところがHadoopの弱点としまして、ビッグデータをいったん蓄積し、バッチで一括処理する形態で処理が行われますので、処理データが発生してからそれに対する処理結果が得られるまで必ずタイムラグが発生します。このため、クレジットカードの不正アクセス検知、センサーデータなどでの異常値検出のようなリアルタイムなレスポンス(低レイテンシー)が要求されるビッグデータ分野へのHadoopの適用は向いておりません。 このような随時発生する大量データ（ストリーミングデータ）を、蓄積せずにリアルタイムに処理する「リアルタイム分散処理」が求められています。 今回は、リアルタイム分散処理のソリューションとしてTwitter社より公開された
Being healthy dev and ops in Cookpad
Talked at DevOpsDay Tokyo 2013 http://connpass.com/event/3052/ http://togetter.com/li/569904
はじめの言語の賞味期限 - Kato Kazuyoshi
ライブドアブログの PSGI 化の話 は良いはなしだと思う。一方で、私はあんまり Perl が好きじゃないので、10年にわたって生き続けた Perl アプリケーションが、次の10年にむけてアップをはじめているのは、ちょっとしたホラーでもある。 Twitter と Ruby と JVM ライブドアブログが、将来に向けて mod_perl から PSGI + Starlet にかえたように、将来に向けてプログラミング言語をかえる人達も存在する。最近の事例で有名なのは、Twitter の Ruby から JVM 言語群への移行だろう。 OSCON Java 2011 の Twitter: From Ruby on Rails to the JVM では、JVM への移行に至った理由として Ability to handle server workloads A real concurrency
Tumblr Architecture - 15 Billion Page Views a Month and Harder to Scale than Twitter - High Scalability -
With over 15 billion page views a month Tumblr has become an insanely popular blogging platform. Users may like Tumblr for its simplicity, its beauty, its strong focus on user experience, or its friendly and engaged community, but like it they do. Growing at over 30% a month has not been without challenges. Some reliability problems among them. It helps to realize that Tumblr operates at surprisin
へ〜たのめも:Google のソフトウェア・エンジニアリング - livedoor Blog（ブログ）
2007年06月07日 Google のソフトウェア・エンジニアリング Google Developer Day Tokyo の鵜飼さんのプレゼンより、「Google のエンジニアはどうやって開発しているのか?」 Google の研修 入社して最初の 3ヶ月は本社(Mountain View)で研修 研修中は、メンターがついて「Google での開発の仕方」を学ぶ 内部ウェブ・サイトで社内共有ライブラリの使い方などを説明する動画があるので、それで自習 Google のプロジェクト・チーム 開発拠点は米国、スイス、オーストラリア、インド、日本など 場所とプロジェクト・チームは関係なく、プロジェクト・チームが拠点をまたがることは普通。世界中の拠点全部合わせて、一つの Google エンジニアリング・チーム 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同
Dropboxは全部Pythonで信頼性の高いソフトウェアを作った（後編）～PyCon APAC 2013
Pythonユーザーが集まり、情報交換し、交流するためのカンファレンス「PyCon APAC 2013」が9月13日、14日に都内で開催されました。PyCon APACはこれまでシンガポールで開催されており、今回初めて日本で開催されました。 （本記事は「Dropboxは全部Pythonで信頼性の高いソフトウェアを作った（前編）～PyCon APAC 2013」の続きです） Pythonは遅いのか？ でもたぶん、あなたのアプリはCPUによって制約されているわけではないでしょう。ごく限られた分野、例えばゲームとか科学計算ではないのならば、多くの制約はハードディスクやネットワーク、もしくはメモリから来ているのではないでしょうか。 それにもしも本当にCPUによって制約されているのであれば、そういうアプリはだいたいCやC++で書かれているとは思うけれど、Pythonにも選択肢はあって、それはCyth
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
javatoscala.com