http://matt-welsh.blogspot.com.au/2013/08/rewriting-large-production-system-in-go.html Go言語の4周年をテーマにしたgolang.orgのブログで紹介されていた、GoogleのMobile Web Performanceチームに所属するMatt Welshのブログです。大規模な本番システムの作り直しにGo言語を採用した経験を語っています。 1) 背景 C++のオリジナルのコードベースは問題なく作動していたが、何年も複数の目的の違うプロジェクトで共有されていたため、スピーディーに改修するのが難しくなっていた。(何のシステムなのか具体的に書いてないのは残念。。) イメージフォーマットをトランスコードするライブラリはC++で完璧に動作していたので、そのまま残し、それ以外を全てGo言語で書き直した。 元のコード
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1428548384 1・ご利益は実現できる範囲の事。 手からなんか出てアトピーを治すとか、本部の井戸水飲んで癌が治るとか言わない。薬事法に触れます。 2・奇跡はやめとく 胡座のまま空中浮遊とか、ガリラヤの湖を歩いて渡ったとか公言すると大槻教授やキッチュさんにボコボコにされます。韮沢さんしか擁護してもらえません。もう21世紀なので昔ほど簡単に民衆は騙せません。 3・年収の15%以上搾取しない。 某教祖の指針では信者の年収20%以上の搾取は組織の寿命を縮めるそうです。信者が長く活動できる事が肝要。 ※5%は優しさ。宗教に必要なのは[愛情]と[脅し] 4・「地獄」や「霊障」を武器にして壷やハンコを買わせない。 何の価値もない壷に[幸せになる]等のアホみたいな付加価値をつけて高額で
この文書はGoogleの「Introduction to Parallel Programming and MapReduce」を日本語に翻訳したものです。 原文のライセンスに従い、この文書はクリエイティブ・コモンズ 表示 2.5 一般 ライセンスの下に提供されています。 なお、誤字脱字、誤訳などありましたらぜひコメント欄などでご指摘ください。 対象読者と前提条件 このチュートリアルは並列プログラミングとMapReduceプログラミングモデルの基本をカバーします。 前提として、C++やJavaのような言語と、データ構造とアルゴリズムについての相当なプログラミング経験を必要とします。 逐次プログラミングと並列プログラミング コンピューティングの初期には、プログラムは逐次プログラムでした。 逐次プログラムとは、一続きの命令で書かれたプログラムのことで、そこでは各命令はひとつづつ順番に実行されま
技術選定のためや、俺が問題解決するぜっ!的な人向け。 順次解決されると思うので、順次更新します。 以下に上げたものも、解決策があるものが多いです。 はじめてのNode.js (2013年3月26日初版) どこか1か所CPUリソースを多く消費するような重い処理が入ると、全体のパフォーマンスが低下する マルチコア/マルチCPU環境を十分に生かすことができない コールバックを多用するためにコードが複雑になる merittyの記事 (2012年12年23日) Node.jsのメリットとデメリット | meritty [メリッティ] JavaScriptの限界、オブジェクト指向が不完全 マルチコアサーバで性能を十分に発揮できない 文法エラーが、サーバーの停止を引き起こす あるリクエストに問題があると、他のリクエストをブロックする ZEALOT社員の方 (2012年10月29日) 引用: Node.j
読みたい本のリストを作ってる(いくつかは購入済み)。 なんかおすすめあったら教えてください。 でもこういうのってリスト作って仕事した気になって満足してしまう。 並列と並行 学びはじめる前なんだから当然よくわかってはいないんでけど、並列と並行処理の違いは以下で認識してる parallel と concurrent、並列と並行の違い - 本当は怖い情報科学 parallel と concurrent 、並列と並行の覚え方 - まめめも (追記) 孫引きなんだけど「コーディングを支える技術 171P」に「プログラミング言語の概念と構造」から引用した記述があった ここでは並行→プログラミング上の概念、並列→ハードウェアレイヤーの話となっていますね。 並列処理・並行処理がプログラミングに必要な理由 マルチコアを生かしたパフォーマンスの向上 大規模なデータの処理 GUIアプリケーションのユーザビリティ
プログラムがテキストデータを読み込む時、その先頭の数バイトからそのデータがUnicodeで表現されていること、また符号化形式(エンコーディング)としてどれを使用しているかを判別できるようにしたものである。[1] Unicodeが開発された当初は、アメリカではASCII、ヨーロッパなどではISO-8859、日本ではShift_JISやEUC-JPといった他の文字コードが主流であり、使用されている符号化方式がUnicodeのものであることを明示する必要があった。また、Unicodeの符号化方式は複数あり、特にUTF-16やUTF-32にはそれぞれエンディアンが異なる2種類があるため、符号化方式同士を区別する必要があった。その方法として、先頭のデータにテキスト以外のデータを入れることが発案された。 実際にBOMを使用すべきか、あるいは使用すべきでないかは、Unicodeを利用したより上位の仕様に
最近、この話題について経営者目線の話が多かったので、エンジニアのスキル獲得戦略とその最大化という観点から話をする。 まず目下のウェブエンジニアとして一番の課題は、「35歳定年説をどう乗り切るか」、ということだろう。もちろん、みんな35歳定年説なんてのが、まやかしであるとはわかっている。若い業界だったウェブ業界も成立してからだいぶ経ち、結果として平均年齢が押し上げられ、自然と35歳以上のエンジニアも増えてきた。 問題は、人月という概念によって、できる人間とそうでない人間の区別がされていないことだ。ウェブエンジニアとしての悲哀や業界の歪みはここにあると思う。下手に謙遜したりして話をややこしくする前に言ってしまうと、自分をできる側の人間として話をする。 生産性を測る確固としたメトリクスがないのも事実だと思うが、すくなくとも熟達した人間と未経験者がおなじ1人月というのは、到底ありえない話だと思う。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く