「MapReduce」を含む日記 RSS

はてなキーワード: MapReduceとは

2023-01-14

anond:20230114015744

全体的に、線で結ばれているものが親子関係なのか包含関係なのかただ近い領域のものなのか曖昧なので意味のあるグラフというよりはキーワード適当に散りばめて近い領域にあるものを線で結んだお気持ちマップに見える

なんか細かい所チクチク直しても全体がよくなる気がまるでせんので目的と線の意味定義し直して出直してくれ。

2021-07-29

anond:20210728124227

真面目に「駆け出しエンジニア」が、入力に対するパフォーマンスの不一致が原因で、勉強停止が起こる理由説明しよう。

英語が読めない。

そもそもインフルエンサーのつく「フリーランス年収千万」という主張に再現性が無いのだ。まず、Rails + React を使う教材が多いが、その手の連中の壁が英語なんだよ。まず、「ちょっと、できるようになった」エンジニアが「ググって問題解決できる知識が書いてある」ところが、英語で書いてある。別に英語を使えたら、年収千万」なんじゃなくて、日本人絶対数英語圏より少ないことから生じる事象であって、日本人解決するネタは「欧米人解決している」可能性が高いのだ。そのせいで、欧米人よりも日本人は応用性に劣るというギャップが生じる。これは、差別ではないから、今後も解決できないです。

でも、TwitterFacebook と同等なもんが作れたら、スキル証明になるのでは?

それが、間違うのよ。なんでかというと、Google や Likedin のようなサービスには MapReduce や Kafka のようなミドルウェアを生み出す原因をつくっていることがあって、後になって「似たようなものと違った」原因となる OSS として公開されるのよね。そして、我々が Rails や React として使えるようになるのであって、順序が逆なんだよ。

日本文系が強いのは根拠がある。

日本マイクロソフトでは、早慶を出た文系がたくさんいるけど、彼らは「アメリカで作ったもの日本で売る」というビジネスが成り立つからコードを書く必要ないの。だからコードを書いてないのに、年収が高い」という矛盾は、全く問題なし。日本人給与コードを書いたら、コスト馬鹿高くなるのよ。

学費の割に、リターンが少ない。

そりゃ、君の使っている教材って、日本においても無料だし、浮いた学費は「自前で問題解決するため」にクラウドでも使って勉強した人の方が評価されるよ。ジャムおじさんも「美味しいパンを作ろう」といいながら、アンパンマンを作っちゃったから、世の中そういうもんだよ。

勉強しても就職先がないです。

雇用の硬直化、および「専門学校大学」といった勉強した連中が、貴方を選ばない原因の人材となりますだって、教材は同じだもん。ちゃん勉強した人が、供給されている以上は負けますよ。

日本が悪い!

からマナブタイに行ったんじゃね?しかし「NTT DATA が SEO を頼んできた」という Tweet は本当にウケけた。今どきの SEO なんて、NTT DATA なら Google から加点するっしょ。落ちぶれても、「デー」は一流だよ。タイにいる胡散臭いアホに頼むぐらいだったら、社内の「SEOエンジニア」に勉強と社益を兼ねてやらせるよ。ちゃん利益出るし、SEO 真面目にやったかアクセシビリティも上がるからね。

フリーランス

手取り税制ギャップ以上のメリットはないよ。

2019-11-22

MapReduceに関してはSQLが得意とかでなければ

MapReduceで素直に書いたほうが無理にSQL覚えるよりはいいだろう

2012-03-03

Amazon web serviceのセミナーに行ってきた

価格はもちろん、サービス豊富さ、開発スピードの速さ、日本の他のクラウドサービスで対抗できるところがどこにあるの?

というのが正直な感想

99.999999999%の可用性、世界中にあるリージョン、エッジロケーション

MapReduce、Sで始まるサービスVPCにDirect connect

そして、セミナー講師が背筋が寒くなるほどに優秀。

amazon死角がどこにあるのでしょうか。同業他社涙目です。素晴らしすぎました。

2011-10-18

Steve Yegge の Googleプラットフォームに関するぶっちゃけ話を訳した(中編)

前編からの続き

この努力は僕が Google に来る為に Amazonを離れた2005年半ばも続いていた。でももっとずっと進化していたよ。 Bezos が命令を出してから僕が離れるまでの間に、 Amazon は全てにおいてまず最初サービスを考える企業へと文化的に変化していった。外部の日の目を決して見ることの無いような、スタッフへの内部的なデザインも含めて、今ではそれがデザインというもの全てに対しての基本的アプローチになっている。

その時点では、彼らはもはや解雇の恐怖からそうしているわけではなかった。つまり、もちろんビビってはいたけれど、ドレッドヘアの海賊 Bezos 様にご奉仕するのは日常生活の一部だからね。そうじゃなく、彼らはそれが正しいことだと理解たから、サービス提供しているんだ。確かに SOAアプローチには長所短所もあるし、短所を書き出してみたら切りが無い。でも全体として、 SOAリブンのデザインというものこそが、プラットフォームを可能にする、これは正しいことだ。

これが、 Bezos が彼の指令書で企んだことだった。彼はチームの健康状態なんて興味もなかったし(今もそうかも)、使われている技術もそうだったし、結局の処のどう取りかかるかなんて結果ができあがるまで気にもしていなかった。けれど Bezos は、 Amazon 社員の大多数が理解する前に、 Amazonプラットフォームにならなければならないということを悟っていたんだ。

だって考えてもみてよ。なんで一オンライン書店が、拡張可能な、プログラマブルプラットフォームになる必要がある、なんてことを考える?。そうだろ?

ともかく、 Bezos が気づいた最初の大きなポイントは、本を売り、出荷し、色々とやる仕組みが、素晴らしいコンピューティングプラットフォーム再利用でき得るということだ。だから今、彼らには Amazon Elastic Compute Cloud があるし、 Amazon Elastic MapReduce があるし、 Amazon Relational Database Service があるし、その他たくさんの aws.amazon.com で見つけられるサービスを持っている。しかもこれらのサービス大成功した企業バックエンドを努めていたりもする。 reddit なんか僕のお気に入りだね。

もう一つ、彼が理解した大きなポイントは、常にいつでも正しい、そんなものを作ることはできないということだ。これは Larry Tesler が、ママはこのくそったれサイトを全く使えないよと言ってのけたりでもした時に、 Bezos にピンと来るものがあったんだと思う。誰のママのことを言ったのかははっきりしないし、そんなことは問題じゃ無い。問題は、誰のママだろうとそのウンコサイトを使えないってことだ(訳注アドバイス thx !)。実際、僕自身、そこで5年ほど働いていたわけだけど、あのサイトは胸がザワザワするくらいひどいと思う。でも僕はその気が散るようなサイトに慣れてしまって、トップページのど真ん中あたりの数万ピクセルに集中できるようになったんだからね。

とまあ、実際の処 Bezos がどうやってその理解、一つのプロダクトで、全ての人にとってふさわしいものを作り上げることはできないということに、たどり着いたのかは定かじゃあ無い。でもその方法問題じゃ無くて、彼は理解してるってことが重要だ。実のところこの現象には正式名前だってある。そう、それはアクセシビリティと呼ばれるものだ。コンピューティング世界で最も重要ものだ。

最も、重要な、ものだ。

君は思うかも知れないね。「はあ?つまりそれって、目が見えない人や耳が聞こえない人のあれ?あのアクセシビリティ?」ってね。まあ君だけじゃないと思う。とにかく世間には、アクセシビリティってものを正しく理解していない、君みたいな人たちがいっぱいいっぱいいるんだから。ただそこにたどり着いてない人たちがね。だからアクセシビリティ理解していないのは、目の見えない人や耳の聞こえない人や手足が不自由な人やその他障碍のある人の責任じゃないように、君の責任じゃない。ソフトウェアが(この場合アイデアウェアといった方が正しいかもしれない)何らかの理由で誰かにとってアクセシブルでないというとき、それはソフトウェア自身の、あるいはアイデアの伝え方そのもの責任があるんだ。それがアクセシビリティの失敗というやつなんだ。

人生における重要なその他もろもろと一緒でさ、アクセシビリティには邪悪双子がついている。小さいときにパパとママの偏った愛情で見捨てられて、今や同じくらいの力を持つまでに育った宿敵って奴がね(もちろんアクセシビリティには宿敵はたくさんいる)。それはセキュリティだ。一体全体こいつらが仲良くやっていること何てあるかい

でも、僕は主張したい。アクセシビリティは実際の処セキュリティより重要だということを。だってアクセシビリティを0にダイアルするってことは、何のプロダクトも持たないってことさ。セキュリティを0にダイアルしたって、そこそこのプロダクトを持つことはできるだろう? Playstation Network みたいにさ。

まあつまりですね、僕はみんなが分かってくれないんだったら一冊丸々この話題で本を書くことだってできるよ。分厚くて、僕が働いてた会社のありんことピコピコハンマーエピソードで一杯の面白いやつをね。でも僕がこの話を公開しなかったら、みんなが目にすることも無いだろう。そろそろまとめに入らなきゃ。

Google がうまくやれていない最後の一つは、プラットフォームだ。僕らはプラットフォーム理解していない。僕らはプラットフォーム自分のものにしていない。みんなの中にできている人はいるだろう。でも、そんな君はマイノリティだ。辛いことだけれど、これはこの6年で僕にはっきりと感じられた。僕は競争相手プレッシャーMicrosoftAmazon最近じゃ Facebook なんかが、僕らを一斉に目覚めさせて、ユニバーサルサービスを始めるのを期待したりもした。アドホックな、中途半端なやり方じゃなくて、多かれ少なかれ Amazon がやったようにだ。一度に全てを。マジで。偽りなしに。今その瞬間から最優先事項として扱うというように。

でも、そうはなっていない。10番やら11めくらいのプライオリティだね。いや15番かも?。知らないけど、とにかく低い。真剣に取り組んでいるチームもいくつかあるけど、多くのチームは考えてもいない。一度もだ。ごく一部の人々がちょっとした規模でやっているだけだ。

多くのチームに、彼らのデータと処理に対してプログラマティックにアクセスできるような、ちょっとしたサービス提供させるのだって大変だ。彼らのほとんどは、俺達はプロダクトを作っているんだ、って思っているからね。そんでもってそのちょっとしたサービスなんてのはみじめなもんさ。 Amazon の教訓に戻ってリストを見てくれよ。そんで今すぐ使えるサービスを持ってきて見てくれ。僕が知る限りでは、そんなものはない。小ビンってのは便利かもしれないけどさ、そんなの車がいる時だけだろ?(訳注:この人、 Stubby という小瓶のビールと、 stubby という「ちょっとした・不格好な」という形容詞をひっかけてしゃべってます

プラットフォームが無ければ、プロダクトなんて使い物にならない。いやもっと正確に言うならば、プラットフォームの無いプロダクトは、いずれ同等の機能を持ったプラットフォーム化されたプロダクトに、取って代わられる。

Google+ ってのはまったくまさに、エグゼクティブリーダーシップのとても高いレベルから(やあ Larry 、 Sergey 、 Eric 、 Vic 、やあやあ)枝葉の使いっ走りまで(やあ、君だよ)、全くプラットフォーム理解していないっていう良い例だ。そう、僕らはみんな、全く理解できていない。プラットフォームの黄金律ってのは、自分ドッグフードを食えってことだ。 Google+ プラットフォームってのは惨めなまでに後知恵だ。ローンチ時には一つたりとも API が無かった。そんで最後にチェックしたときには、僕らが提供してたのはわずかばかりのほんのちっぽけな API さ。ローンチの時、あるチームのメンバーが行進してきて僕にそれを説明してくれた。だから僕は訊いたんだ「でさ、これはストーカーAPI?」って。彼女はむすっとして、「ええ」ってだけ言った。いやジョークなんだよ…いや…ジョークじゃ無いんだ…僕らが提供する唯一の API は、誰かのストリームを読み出すだけ…。うーん、僕が間違ってたのか?

Microsoft はこの20年間ドッグフードルールで知られてる。この時代の彼らにとっての文化の一つなのさ。デベロッパドッグフードを食わせて、僕らだけ人間のご飯を食べようってわけにはいかない。それは単に短期の成功のために長期のプラットフォーム価値を損なう行為だ。プラットフォームってのはまったく長期的な視点必要なんだよ。

Google+脊髄反射の代物さ。 Facebook成功したのは、彼らがすばらしいプロダクトを作ったかだって言う、まあ実に近視眼的なもの見方の結果として生まれものだ。でももちろん彼らが成功したのはそんな理由じゃ無い。 Facebook は他の人たちにも何かをさせてあげられる、プロダクトの美しい集合全体を作り上げたから、成功したんだ。だから Facebook はみんなにとってそれぞれ違うものだ。 Mafia Wars に全ての時間を費やす人もいれば、 Farmville で遊ぶ人もいる。何百の、いや何千の、質の高い、暇つぶしができるってわけさ。つまり、みんなのためにふさわしい何かが必ずあるんだよ。

僕らの Google+ チームは、プロダクトを出した後のマーケットを見てこう思った。「おっとっと、我々もいくつかゲーム必要みたいだな。さっそくどこかと契約して、我々のために作ってもらおう」。これが信じられないくらい間違った考え方だってことが、君にもわかってきたかい?。問題なのは、僕らが、人々がほしい物を予測して、それを提供しようとしているということだ。

そんなことは出来ないんだよ。現実的にはね。確実にやる方法なんてない。もちろんコンピューティング歴史全体を見渡せば、それを確実に信頼性を持ってできる人間ってのがごく数人いることにはいる。 Steve Jobs がそうだろう。でも、僕らの処には Steve Jobs はいない。悪いけど、いないんだよ。

Larry Tesler は、 Bezos が Steve Jobs じゃないってことを口説たかもしれない。でも Bezos には分かっていた。全ての人にふさわしいプロダクトを提供する為に、彼が Steve Jobs になる必要はないっていうことを。インターフェースワークフローこそが、人々が気に入り、安心感を得るものなんだっていうことを。彼はサードパーティ開発者にそれを可能にするだけで良かった。そうすれば、後の事は自動で進んでいく。

僕の言っていることが、あまりにも明白なことだろって感じているみんな(多かったらいいな)には申し訳ない。とにかくもうびっくりするほど自明ことなんだ。ただ、僕らがそれをやってないってことを除いてはね。僕らはプラットフォーム理解していない。プラットフォームを持っていない。アクセシビリティ理解していない。アクセシビリティを持っていない。これらは基本的には同じことだ。なぜならプラットフォームアクセシビリティを解決するからだ。プラットフォームアクセシビリティなんだよ。

後編に続く

2009-11-29

http://anond.hatelabo.jp/20091129213350

分散コンピューティンググリッドコンピューティング計算が出来るからスーパーコンピュータが不要だという発言が、実際に計算を行っていない人からなされています。であれば世界中で一カ所に集めたスーパーコンピュータがるのはなぜか?分割した計算を最終的に集めて同期を取らないといけないから。

一方で、ウェブ分野では、分散コンピューティングによる並列計算や、それをサポートする技術に注目が集まっているのも事実。基本的には、PCで使ってるCPUコア単体での性能向上が見込めなくなってきたのが大きな原因ではあるけど、それだけじゃない。

早い話がGoogleMapReduceで、全体の処理を部分に分割できるタイプ計算なら、並列計算を非常に簡単にプログラミングできるフレームワークが出てきている。この間同社がリリースした「Go」もそうだね。

Googleがこうしたアーキテクチャを用いるのは、基本的にはコストの問題。Googleバックエンドは、新しいマシンを投入すれば投入しただけ規模を拡大できる「スケールアウト」型のアーキテクチャになっている。マシン自体もコモディティパソコンベースになっているので、新規導入コストが非常に安い。この辺は、典型的な「スケールアップ」であるスパコンとは対照的(例えば地球シミュレータは、アップグレードのために200億円近くのコストがかかったりしている)。

また、ランニングコストも非常に安くできる。壊れたマシン自動的にシステムからパージされるので、後からそのマシンだけ取り替えればいい。省電力の意味でも結構有効らしい。

このシステムが苦手なのは、元増田引用したように、まさに計算の同期が頻繁に必要なタイプ計算。ただ、そうでないタイプ計算に有効なのはもちろん、コスト面で総合的に上回ったりとか、アルゴリズムの改良で分散システムでも扱えるようになるとか、そういう可能性はないのかなぁ、ということは思っている。

というわけで、詳しい人突っ込んでくれ。

 
ログイン ユーザー登録
ようこそ ゲスト さん