「Hadoop」を含む日記 RSS

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

2020-10-16

https://forest.watch.impress.co.jp/docs/news/1283097.html

つかApache Projectで今も活発に活動してる奴ってServer, Lucene-Solr, Hadoop, Sparkくらいじゃないですか

2019-11-23

Julia (プログラミング言語)なぜ僕らはJuliaを作ったか

それでも、pythonは非明示的な動的型付き言語であり、記述時のチェックも少ないので、文法さえ合っていれば、結構自由に書ける。クラスインスタンスや、数値などではなく、(その場の変数値込みの)関数なんかもただのオブジェクトに見えるので、どんどん関数引数変数に入れられる。戻り値しかり。演算子オーバーロードなどもできて、直感的な記述可能。ということで、使う側の直感に合うような運用可能になっているがゆえに、受け入れられているのだろう。

しかし、それは運用単体テストに支えられているものであって、ひとたびその集中力が途切れたりうっかり見落としていたりすると、それがどこにあるのか、というのは、それなりにレアなケースだと、発覚するのがだいぶ先になって、その解析、分析も大変になるという恐怖は常に隣り合わせである

もしかして、そういう状況がいやだったから、掲題のコンピュータ言語を開発しようとしたのか。

http://marui.hatenablog.com/entry/20120221/1329823079

ここに、原作者ブログの日本語意訳がのっていた。もう6年も前になっている。

(原文:Why We Created Julia)

2012年2月14日(火) | Viral Shah, Jeff Bezanson, Stefan Karpinski, Alan Edelman

端的に言えば、僕らは欲張りだからだ。

僕らはMatlabのパワーユーザーだ。LispハッカーPython使いやRuby使いもPythonハッカーもいる。髭が生える前からMathematicaを使っていたのもいるし、未だに髭が生えてない仲間もいる。常識的な人にはオススメしないくらい多くのグラフR言語で描いてきた。そしてC言語は僕らのユートピアだ。

いま挙げた言語は大好きだ。どれも素晴らしいしパワフルだけど、科学計算機械学習データマイニング、大規模な線形代数演算分散・並行コンピューティング、といった僕らがやるようなものにはどれも一長一短で、仕事完璧にはまる機能もあれば何とも使い物にならないものもある。どれもトレードオフなんだ。

僕らは欲張りだ。これじゃ十分じゃない。

僕らが欲しい言語はこんな感じだ。まず、ゆるいライセンスオープンソースで、Cの速度とRubyの動的さが欲しい。Lispのような真のマクロが使える同図象性のある言語で、Matlabのように分かりやす数学記述をしたい。Pythonのように汎用的に使いたいし、Rの統計処理Perl文字列処理、Matlab線形代数計算も要る。シェルのように簡単にいくつかのパーツをつなぎ合わせたい。チョー簡単に習えて、超上級ハッカーも満足する言語インタラクティブに使えて、かつコンパイルできる言語が欲しい。

(そういえば、C言語の実行速度が必要だってのは言ったっけ?)

こんなにもワガママを言った上だけど、Hadoopみたいな大規模分散コンピューティングもやりたい。もちろん、JavaXMLで何キロバイト常套句を書きたくないし、数千台のマシン分散した何ギガバイトものログファイルを読んでデバッグするなんて論外だ。幾層にも重なった複雑さを押しつけられるようなことなく、純粋なパワーが欲しい。単純なスカラーループを書いたら、一台のCPUレジスターだけをブン回す機械語コードが生成されて欲しい。A*Bと書くだけで千の計算をそれぞれ千のマシン分散して実行して、巨大な行列の積をポンと計算してもらいたい。

だって必要ないなら指定したくない。もしポリモーフィック関数必要な時には、ジェネリックプログラミングを使ってアルゴリズムを一度だけ書いて、あとは全ての型に使いたい。引数の型とかから自動的メソッド選択してくれる多重ディスパッチがあって、共通機能がまったく違った型にも提供できるようにして欲しい。これだけのパワーがありながらも、言語としてシンプルクリーンものがいい。

これって、多くを望みすぎてるとは思わないよね?

僕らがごまかしようのないほど欲張りなのは分かってるけど、それでもぜんぶ欲しいんだ。二年半ほど前、この欲にまみれた言語を作り始めた。まだ完成してないけど、そろそろ1.0のリリースの時期だ。僕らが作った言語名前はJulia。すでに僕らの無礼要求に9割方は応えてくれてるけど、ちゃんとした形になるためには僕ら以外の要求も聞かないといけない。だから、君がもし欲張りで理不尽わがままプログラマなら、ちょいとこいつを試してもらいたいんだ。

我儘な開発者を満足させるための原語、というのはなんとも意欲的な目標だろう。

そして、その我儘を言う開発者が、今はやりの機械学習でも使いやすいだろう mathematica や R の行列演算統計計算世界を使いまくった連中が入っているところが今風の要求となっているようにも思う。

ちょろっと名前を聞いただけなので、これからなのだが、開発者としては、品質生産の加速がpython の一歩先を行くような世界であればそれは大歓迎だろう。

julia 何て名前を付けているから、検索すると AV女優の方が目立って出てきてしまうのである

https://qiita.com/sadayuki-matsuno/items/fc5e9ec3894a4b7bfbfb

ここからプログラムコードの断片をもってこようかとおもったが、

そのままコピーしても、今一歩な感じ。

ほらほら、

数式が数学で習った感じで書けるよね。

行列もほいほいかけるよね。

とかそういう小技が書かれているような気がした。

このあたりは、python限界を超えているので、見栄えはよいかもしれない。

2019-09-12

Hadoop懐かしいな

まだ誰か使ってるのか

2019-07-03

冷静に考えるとITエンジニアって異常だよね

私はうぇっぶな界隈で働くしがないエンジニアです。


今日牛丼を食べながらふと気がついたのですが、もしかして我々の業界は異常なのではないでしょうか?

テクニカルタームとかドメイン知識多すぎでしょ。


サービス名、技術名はスキあらば3文字って感じだし (AWS, EC2, EKS, GCP, GAE, GKE k8s, C2C, CPU, GPU, SPU...)

会社名もソフトウェア名も連想できるってものじゃないし (PostgreSQL, MySQL, Redis, etcd, Consul, HashiCorp, Vagrant, GitHub, CircleCI, FreeBSD, CentOS, Ubuntu, Linux, Couchbase, Hive, Hadoop, Vagrant...)

みんな普通にPOSIX互換コマンドをペシペシしているし (cd, cp, mv, pwd, mkdir, ls, vi を更に謎の数文字オプションも含めて覚えているわけで)



それも特に覚えようとして覚えてきたわけでもないじゃないですか

気がついたら覚えているわけで、手に身についているわけで。まるでポケモン151匹を勝手に覚えてしまったあの頃と同じようなノリで謎の英単語や謎の羅列を身に着けてしまっている訳ですよ。

何ら疑問に感じてなかったんだけど、普通にきじゃないとできないよね。




で、思ったんだけど、インターネット小話で聞く「全然興味はないけどSEなっちゃいました」みたいな人ってガチ苦痛なんじゃないだろうか…

(未だにそんな人を見たことが無いか都市伝説だと信じてるけど)

別に周りにそんな人が居るわけじゃないけど、新卒入社してくる季節ってことでふと気になりました。





おしまい

2018-02-07

最近仕事FPGAを触り始めたけど、なかなかまとまった情報を手に入れられるWebページやら本やらがない

10年ほど前にPICを触ってたのである程度(特にハードウェア)はなんとかなるが、

それでも想定通りにいかないことが多いなあ

PICと比べると、かなーり高級な感じだ。

Wregとかアドレスとか考えなくていいしね。

1年前はHadoop触ってたんだけどね。人生どうなるかわからんね。

2017-05-13

http://anond.hatelabo.jp/20170512180012

ビックデータ

嘘ビックデータ、というと言い過ぎだが、ビックデータというのはたくさんのデータを格納することとは本質的に異なる。

「ビックデータ」は「質的」に大量データを格納することだ。

製造時のデータを格納しても、「質」は低いままだ。意味内容は結局製造できたか、あるいはできないかの2つしかいからだ。

製造時のデータと天気のデータを格納したほうが、まだ「ビックデータ」になりうるかもしれない。

しかhadoopとかAWSとか、まず間違いなく地雷一直線だ。

まぁ他に選択肢はないわけだが。。

2017-05-12

製造業新卒で入って数年経過したけどもうダメかもしれない

新卒製造業に入った。

大学では工学部ではない理系だったので右も左も分からないなりにがんばってみようと思っていた。

悪く言えば自分能力絶望して夢を諦めることになり都落ちした気分での就職だったのでやぶれかぶれだったというほうが近いかもしれない。

相性というか、背景の差とか常識の差みたいなものがあって、自分から見ると無駄の多い職場だなあと感じて研修期間が終わり本配属された。

無駄が多いという感想は本配属後も変わらなかった。

本来業務はいわゆる故障解析で、歩留まりを上げていくのが使命だった。

せっかくだから色んな所に首を突っ込み改善できそうなところは提案をしたり、自動化したり、それらのドキュメンテーションを書いてみたりした。

プログラミング経験は皆無だったが、理論系卒が工学部に負けられんという謎のプライドVBAから、Rやら自社製品の解析用環境の割と珍しいタイプスクリプト言語など(特定されそうだからぼかすけど。)

とりあえず手が出せそうなものは何でも調べてみてありものを改造してみたり勝手作ってみたりして提案していた。

物怖じしない新人がぎゃーぎゃー騒いでいるぐらいのものだったと思うが、何にせよいくつかの改善が上手く実務にハマって成果として認められたりしだしたのが1年目。

この辺で気付いたことだが、製造業ITリテラシーは驚くほど低い。製造業一般化するのはフェアじゃないかもしれないから厳密に言えば弊社の、という意味だが。

なんせまともにプログラムを書いたことが無い新人半年で身に着けた程度のスキルで書いたプログラムで、1日かかってた仕事が1時間で終わったりするのだ。

ようするにMS officeの達人みたいなのがいっぱいいて、Ctrl+CとCtrl+Vが機能のすべてだと思っているということだ。

(そして彼らの口癖は「忙しい」だ、会議中も左手はCtrl+CとCtrl+Vを叩き続けている。)

2年目に気付いたのは、弊社エンジニアITリテラシーが低くとどまっている要員のひとつに、実はITインフラチームがことのほかマトモだということがある、ということだ。

製造中のセンサーデータやらテストデータやらETL的にはおそらくえげつない部分で、かなり優秀な人間が居て上手くぶん回し切っている様子だった。

無骨だが使いやすイントラ上のwebページが用意されて、グロテスクな部分を気にせずクリックだけで上述のデータを整ったものとして引っ張ることができた。

から逆に言えば下々の人間コピペでなんとか恰好を整えられるのだった。

彼らはモダンな発想があって、あるいはお偉いさんが「ビッグデータ」とか言い出したのかもしれないが、ともかく、HadoopやらAWSやらそういったものを導入しようと試みているらしかった。

私はそれに感動した。なんせWebスクレイピングみたいな方法他人が社内プラットフォーム社内WIKIに上げた報告をまとめたり、製造データと紐づけたり、それからグラフ描いたりみたいな業務が増えていたからだ。

それっぽく表現すればデータ分析屋さんということになるのだろうが、どぶをさらっているという表現のほうが近かったかもしれない。

何にせよそういったもの一気通貫自動化できるポテンシャルがあると感じられた。

SQLjavaも書いたことなんて無かったが、1年前やっていたことを考えれば同じことだ。何にせよ歓迎だった。しか管理IT持ちだ。餅は餅屋に頼むべきだ。それもできれば美味い餅屋に。

ところがその「ビッグデータプロジェクト人手不足か、資金不足か、あるいは生みの苦しみか、ことのほか時間がかかっていた。(あとで聞いた話、外部コンサルで外れを引いたらしい)

自分ドメイン知識からの助言とか想定される使い方についての意見を伝えていったし(有難迷惑だった可能性は否定できないが)、もう少し待てばモノになると信じていたし、実際そうなった。

具体的な話ができないのだが、客先で起こった不良の原因をつきとめ、その改善効果確認の為に数十億行のデータ活用された。彼らの力が無ければ常識的時間では終わらなかった仕事だった。

残念だったのは彼らの優秀さの割に一般エンジニアスキルがあまりに低かったということだ。つまりそのプラットフォームを使いこなせる人間が著しく少なかったのだ。

そして上述の足踏みをしていた期間に心象を悪くしていたという問題もあった。とっかかりが難しい割に不安定だというレッテルを張られてしまっていた。

このころ私は入社3年目に突入していたが、

もうすこし悪いことに、同時期に企業買収が起こった。我々は黒字を出していたが同業他社(厳密にはその親会社に)に買われることになった。

そういう時に起ることは不要冗長性の削減だ。子会社として存続する場合は知らないが、競合他社に吸収合併ということは、多くの部署にとってそのカウンターとなる部署相手側にも存在するということだ。

まりどちらにもある部署統合するか一方を無くすかという戦争が始まるのだ。IT例外ではない。(ITインフラ部署の無い会社はさすがに無いはずだ)

一方で製造業の本懐である製品を作り、売る」という部分は比較的守られる。それこそが根源的な資源であり、利益を生む仕組みであり、既存顧客への説明必要からだ。

そして私の仕事は歩留まり改善であり、故障解析であり、データ分析だ。何が起こったか

(ここで簡単のために旧弊社を(旧)A社、買収した側の競合他社を(旧)B社と呼ぶことにする。)

今の旧A社から引き続いている業務をB社のプラットフォームで行えるように転換せよという下命である

旧B社の製造データに対するアプローチはA社とまったく異なっていた。Web UIは美しく整っており、それっぽいグラフ簡単に表示され、A社側のお偉いさんからも好評を得ていた。

だがそのバックエンドは控えめに言って酷いモノだった。いくつもの情報を正常に保存できておらず、「それっぽい何か」を素早く返答することを第一義としているように見えた。

そして上述のように器用貧乏街道を歩んできた私に投げられたのは次の言葉

増田くん、B社のプラットフォーム使うことは決定事項だから、君が自動化してたやつ全部そっちで動くようにしといて。よくわかんないけどプログラムとかてきとうにできるでしょ?」

もちろんhtmljavascriptphpRoRも一行も書いたことが無いのが当時の私である

果たして旧A社のプラットフォームはB社のプラットフォームデータソースのような扱いを受ける羽目になり、私はjavascript本格入門を片手にB社の事業所に出向くことになった。

そこで散々「旧A社のプラットフォームは遅い・使いづらい・不安定」と貶されながらチマチマとグラフを表示するページを書いている。

クオリティの低いバックエンドを作る集団が書いているサーバーサイドphpの酷さは素人目にも分かるレベル筆舌に尽くしがたいものがあるが、

反面教師だと思って耐える日々だ。

最近分かったことは旧B社のバックエンドスクリプトデータを引っ張るついでに意図的に旧A社のプラットフォーム攻撃しているということだ。DDoSとまでは言わないが、悪意100%である

いわく旧A社のプラットフォームを畳むためには旧B社のプラットフォームが優秀であることを示す必要があるとのことである。(つまり旧A社プラットフォーム不安定かつ重くなることを意図しているらしい)

旧A社から継続されてる業務はまだそこ使ってるんですけど・・・

それはもちろん旧A社の上司に報告したが「見て見ぬふりをしろ」とのことだった。旧A社のITで何度もお世話になったひとに伝えると「知ってるけどね・・・」と悲しい目をして苦笑いしていた。

旧A社ITはその優秀さでそれらの攻撃をいなしつつあるようにも見える(私も素人に毛が生えたレベルだが、ソフトウェアエンジニアリングレベルが二回りぐらい違うように見える)

この不毛な戦いはいつ終わるのだろう・・・つらい・・・

そして私はいつまでソフトウェアエンジニアの真似事を続けてキャリアを消費していけばいいのか、もうダメかもしれない。

そもそも私はエンジニアなのだろうか・・・少なくとも職位にはそう書いてあるけど・・・

2017-02-17

今、スタバでルネラジを聴きながらコレを書いてます

さっき、テックブログRSSと一緒にホットエントリRSSを外して、アプリを削除したよ。何年の付き合いだろう?サービス開始からから・・・悲しくなるから確認せずに行くよ。

最初ダイアリーに書いて、反応なんて全然なくて、広告コメントばかりだったな。いまでもはてなの知り合いはいないんじゃないかな。

ネットコミュ障なんだ。Twitterとか色々やってるけどやりとりする相手なんて誰もいないよ。

僕は君になにもできなかったね。本当に君の事が好きだったのかな?本当に村民になりたかったのかな?多分、違う。本当はブクマされて、スターつけられて、承認欲求を満たしたかったんだ。

意識高い系を笑えないよね。何年も異性にお金を注ぎ込む人を笑えないね。僕もずっとホットエントリを見て、色んなものを買ったりしたんだ。

====

どうしてこうなったか?聞きたくもないだろうけど、最後から言わせてくれよ。

初めて君を見たとき天国に見えたよ。最新の技術トレンドがここにあってさ。自分理想郷はここなんだって技術力をつけて、認められる人間になって、ここの住人になる事が幸せなんだって思ったんだ。

そうやってさ、次々流れてくるトレンドに耳だけが年増になっていって、それを知らない周りの人たちをバカにしてたな。

でもさ、肝心の技術力は全然つかなくてさ、大学生になれば、就職すれば、東京に出れば、新しいマシンがあれば、お金があれば、時間があれば、やる気があればって制約条件がなくなる度に新しい言い訳を考えてたな。

結局、生半可な知識じゃ参加できないってチンケなプライドのせいで勉強会に参加せず、ブログも書かず、なれたのは一番軽蔑するExcelとにらめっこしてるSIer。おいおい、Web系のベンチャーテックブログ書くんじゃなかったのかよ(笑)

耳年増で、周りをバカにしてたクセに仕事全然できない自分とのギャップ10年耐えてきたけど、年末休職したんだ。自律神経失調症

眠れるんだよ?ごはん食べられるんだよ?ただ、会社の人みんなが怖くなってさ、朝だるくってさ、すげー疲れてさ。苦しくて。仕方ないから受け入れて。っていうか、甘やかして。つまるところ、ズル休みなんだよ。

時間が出来たから、ずっと積ん読になってた技術に正面きって立ち向かってみたんだ。すぐ投げ出したね。理由は分からないけどただ苦痛だった。

作りたいものなんかなかったし。多分、技術を使いこなしてスゴいって言われたかったんだね。

部屋にはPerlRoRSQLitejQuerynode.jsAWSHaskellHadoopDockerRaspberry Pi、R、Reactのホコリを被った本がある。彼らはブックオフ行きかな。

最近時間はあるからさ、はてブばっかやってたんだ。見るのがホットエントリから新着エントリーになったな。いつもみたいに100文字制限ギリギリコメントだけじゃなくて、10文字くらいの一言コメントも書くようになったんだ。その10文字コメントのうちひとつ100スターくらいもらえてさ。

そのとき分かったんだ、これはずっと片思いなんだって。叶わない恋なんだって自分が住める世界じゃないんだっておかしいよね、小学校の頃のプロ野球選手の夢だって中学生の頃の小説家の夢だって高校の頃のパンクロックスターの夢だってすぐ諦められたのに、この夢は35歳の今だって諦めきれないんだ。

応用情報取った時も、ネスペ取ったときも、オラクルブロンズ取った時もLPIC 2取った時も全く達成感なかったよ。コレ取るのに何年かかってんだってさ。村民は1ヶ月あれば取れるぞ。同期のアイツだって3ヶ月で取ってるぞ。何が言えるんだってさ。

銃・病原菌・鉄読んだ時もそうだった。で、お前はそこから何かアウトプット出来るのか?ってさ。読むだけなら幼女でも出来るんですけどwって。

伝わる?伝わらないだろうな。みんな高IQですぐに色んな技術理解出来るじゃない?すごいよ。自分二浪駅弁大学しか行けないくらいのバカで、リアルでもネットでも知り合いを作れないコミュ障自己承認全然出来ないんだ。

ADHDって言葉を知った時、これだーって思ったけど違ったね。IT勉強してても過集中が全然ないんだ。

話が逸れたね。認知療法してて、気づいたんだよ。何をしてても自分を認められないんだよ。はてなに受け入れられる事を成し遂げられてないからね。

から自分を認めるために、君のことを自分から切り離さなきゃいけない。自分世界を作らないと。一方的なっちゃうけど、さようなら勝手だけど、今にも泣きそうだよ。

これからどうしようかな。匿名で好きな事書けるのはココだけなんだ。自信のない間違ってるかもしれない事を書いてもいいのはココだけなんだよね。ここなら見たくないコメントを見なくてすむんだ。

新聞も取ってないかチラシの裏にも書けないよ。

でも、前に進まなきゃ。夢の世界への憧れは終わりだ。目の前の現実世界適応しなきゃ。また逃げ戻ってくるかもしれないけど、いまはさようならしなきゃ。

最後に何か残せるとしたら・・・スタバハチミツ、あれ何に使うと思う?あれ、ワッフルを食べるときに使うんだよ。

・・・スベったね。

さようなら。このエントリも2時間すれば次のページ行きだ。そうすると、誰かの目にも触れなくなる。単なるはてな磁気データになる。

最後ブコメとかつくんじゃないかって浅はかな期待を持ちながらこの内容を登録するボタンを押します。じゃあね。

P.S. 認知療法について書いてくれたこの増田には本当に感謝しています。まだまだ自分について書く事が苦しいけど、正しい道を向いてると信じています

http://anond.hatelabo.jp/20150213215921

2014-05-16

ウンコード

イラッとしたので増田に書く。

最近辞めていった奴のウンコードが酷い。

エラー処理とか一応書いているが機能してない。

今日トラップに引っかかった。

ウンコ過ぎて困る。

昨年一年の奴の行動は酷かったよ。

会社利益無視して、自分スキルになることだけ強引に進めた。

どこか知らんが、上場企業に務めたらしいので、

今月か来月あたりに入社する奴で、『PythonできますAWShadoopやってました。』と言う奴は要注意。

2014-04-28

辞めてくれてありがとう

本日の作業は旧〇〇軍が残した地雷(クソコード)の確認作業。

技術屋ぶって偉そうにしているが、まるっきり分かっていなかった。

こんなウンコ残して、偉そうにしている理由が良くわからない。

でも、そんなことに怒ってはいないよ。

なによりも、今月末で顔を見なくてよくなるのが嬉しい。

とにかく、この一年の作業は、君が転職活動するためのことで振り回された一年だった。

AWSとかHadoopとか履歴書に書くためだけに色々頑張ったね。

退職すると報告があった時、

転職先決まって良かったね。』

と、心のそこから思ってたよ。

辞めてくれてありがとう

転職先は上場企業らしいけど、引き取ってくれた会社感謝したい。

すぐにボロを出すのか、3年ぐらい我慢するのか分からないけど、年齢的にもこの先転職するのは厳しいだろうから転職先で末永く働けると良いね

あなた性格が治ってくれることを祈るよ。

2013-12-21

http://akiradeveloper.hatenadiary.com/entry/2013/12/21/184119

> Githubアクセス出来ないと言ってもイマドキのエンジニアは誰も信じないだろう

え、事業部は数年前からはてダアクセス禁止だったし、yumapt-getとかもっての他でパッケージ一つ毎に上司承認必要でしたが?

横浜研究所がなんなのかあんま把握してない(元シ研かな?)けど、Linuxストレージ関係部門とは・・

自分は優秀じゃなくて落ちこぼれで外に出ていきましたが、ほんと所員に外見てきてほしいとは思う。

ところで自分がやめるとき周りの人全然Hadoopとか知らなかったんだけど、ビッグデータ周りの推進は研究所主体ということで合ってます

(高速独自DBの可能性もあるけど)

2013-08-29

http://anond.hatelabo.jp/20130829140653

そんなあなたに Hadoop

つか、

技術を見つけようという気持ちと、それを流行らせようという気持ちは全く別物。

 

そもそも、それが流行して、新技術として認識されるためには レベルが低い必要がある。

携帯電話でもスマホでも最新技術の塊だけど、そもそも、新技術が使われてることすら知らずに組み込まれてる部品なんていくらでもあるんじゃね?

 

俺達は、俺達が理解できる技術しか認識できない。でも、実際には使われてる。

そして、そのレベル技術を中高年のオッサンがえーとえーと なんて言うことはないから問題ない。 

それだけのこと。

2013-03-07

なぜ国内Perlが急速に萎んだのか

2005年 Railsの襲来

2005年に突如現れたRailsによって国内Ruby利用者が急増したのがPerl滅亡への第一歩となった。書きやすさに作者がとことんこだわって作られたRubyの魅力を一度知ってしまうとPerlの古くさく読み辛く書き辛い文法に誰もがうんざりし始める。

2007年 JavaScriptブーム

Ajaxで再発見されたJavaScriptのブームもPerl終焉に若干ながら貢献している。ブラウザというPerlが全く手を出せないジャンル王者JavaScriptの持つ華やかさに誰もが憧れ、そして手元のPerlの古くささに反吐が出始める。不器用で不細工なところも含めて愛していた女房とつつましく送っていた人生に、突然ぴちぴちボイン女子大生が転がり込んで来たようなものである

スマホ/ソーシャルゲームバブル

iPhone市場が本格的に立ち上がり、Perlとは全くの無関係であるスマホアプリ全盛期がやってきていよいよPerl滅亡へのカウントダウンが始まった。そして極めつけはソーシャルゲームバブルである。ここでもPerlかい言語は全くの蚊帳の外で大絶賛凋落中。

2012年 ビッグデータ/Hadoopブーム

Perlなんぞ全くお呼びでない世界の話。段々とwebテクノロジー世界に高度な数学的知識を持ったアカデミック層が跋扈しはじめ、専門学校プログラミング言語を学んだだけの人間ハッカーなどと名乗ると恥ずかしい時代になってきてきた。

2013年 Pythonの本格的な浸透

遂にPerlにとどめを刺したのはPythonである守備範囲は当然ながらPerl駄々被りで読みやすく書きやす世界的なシェアうなぎ上り。完全にPerlが不必要な世の中になってしまった。

結論

2005年までのPerlはまさに我が世の春を謳歌していたが今や目も当てられない惨状でプログラミング言語シーラカンス・COBOLとすら比較され出す始末。昔Perlの人として売り出していたハッカーも、いつのまにかPythonの人になっているケースも海外では多い。10年でここまで時代は変わる。今のメインテクノロジー明日は我が身だ。小手先技術に乗っかってモダンだのハッカーだの聞こえのいい言葉を汚い口でまき散らして消えて行ったPerlエンジニア達の死を無駄にしてはいけない。変化の速い時代に生きる我々に必要なのは本質を学ぶ事だ。コードの書き方とかどうでもいいんだ。もっと1020年たっても色あせない情報工学を身につけなければならない。

2013-02-28

バズワードの異常な乱用 または私は如何にしてバズるのをやめてイライラするようになったか

これを読んで思ったこと、またはその反応に対して思ったこと。

http://d.hatena.ne.jp/yomoyomo/20130228/bigdataisdead

Web2.0からクラウドビッグデータまで、様々なバズワードが生まれ、おっさんたちを虜にし、また一部から揶揄される状況が繰り返されている。当然ビジネスの上でも、これらのバズワードは多用され、一部では本質的意味のある事業が進んでおり、また一部では知的ゴロツキの餌となっているのが現状だろう。

このようなバズワードに対し、一般的な反応は大きく分けて2つだ。「我が社もビッグデータ事業だ。その方が時代に乗っていて格好いいだろう、ぐはははは」と「またバズワードか。食傷気味だ…一年で何回聞くことになるんだろう…」である

ここで、問題にしたいのはバズワードの対象自体が有用有用でないかではない。基本的に正しく捉えればクラウドビッグデータ有用だ(だからこそ、バズっているともいえる)。では、なぜこれらのバズワードが飛び交う時に、嫌な気分になったり、攻撃的になったりする人たち(自分含む)がいるのだろうか。

考えてみたのだが、バズワード言葉自体がもつ情報量が圧倒的に少ないことに起因するのではないか?ということだ。これはバズワード定義曖昧ということとは異なる。そうではなくて単語が発言されるときにその単語がもつ情報量の問題だ。通常の会話ではある単語が発言されたときに、その人の知識量やバックグラウンドを示す単語があればその人の能力をある程度推測することができる。

卑近な例だが「Excelだと100万行以上あると開けないですよね」という発言があると少なくともこの人は100万行のデータを扱ったことはあるんだなという情報受け手は得られる。技術的会話とは本来そういうもので、その人の発言する技術用語である程度の技術力を推測するものだろう。いや、コード書かせてみないとわからないだろ、というツッコミはおいてください。あくまで最低限の推測、例えばこれまで付き合いのない企業間での打ち合わせのような場合でのスクリーニングの状況を想定してほしい。

このときバズワードによって、なんかよくわかってない人も「ハドゥープでノーエスキューエルでアレですよ」みたいな発言をするようになると、これまでどちらかというとマイナー技術者かどうかを識別する単語につかえていたHadoop統計手法名をまた一から考え直さなきゃいけなくなる。一番最初スクリーニングの仕方をこちらが変える必要がある。それが激しくめんどい。だからバズワードは嫌いだ、という思考を自分がしていることに気がついた。

というわけで、ビッグデータうんぬんにイライラしている方々、この仮説は如何でしょうか?

蛇足だが、なんでこの思考に辿り着いたのかというと、あまり親しくない他社との打ち合わせ時に相手がビッグデータビッグデータ連呼するので、ほんとに技術力があるのか(またはほんとにビッグデータに関心があるのか)よくわからなかった。そこで、関心あるならそれなりにビッグデータに関する情報フォローしているはずだという仮説のもとでユバタスについて話題を振ってみたところ、ユバタスどころかPFIも知らなかった。世の中そんなもんである

2012-07-28

シェル操作課題 SQLによる解答例

シェル操作課題 (cut, sort, uniq などで集計を行う) 設問編 - Yamashiro0217の日記の解答例です。MySQL 5.5です。

準備
mysql> CREATE TABLE log (
    ->   id          BIGINT PRIMARY KEY AUTO_INCREMENT,
    ->   server_host VARCHAR(30),
    ->   access_time DATETIME,
    ->   user_id     INT,
    ->   access_url  VARCHAR(191)
    -> );
Query OK, 0 rows affected (0.00 sec)

mysql> LOAD DATA LOCAL INFILE 'log.csv'
    -> INTO TABLE log
    -> FIELDS TERMINATED BY ','
    -> (server_host, @unixtime, user_id, access_url)
    -> SET access_time = FROM_UNIXTIME(@unixtime);
Query OK, 9 rows affected (0.01 sec)
Records: 9  Deleted: 0  Skipped: 0  Warnings: 0
問1 このファイルを表示しろ
mysqlSELECT server_host, access_time, user_id, access_url
    -> FROM log;
+-------------+---------------------+---------+--------------+
| server_host | access_time         | user_id | access_url   |
+-------------+---------------------+---------+--------------+
| server1     | 2012-07-27 13:25:24 |      30 | /video.php   |
| server2     | 2012-07-27 13:25:10 |      20 | /profile.php |
| server3     | 2012-07-27 13:25:15 |       7 | /login.php   |
| server1     | 2012-07-27 13:25:05 |       8 | /profile.php |
| server2     | 2012-07-27 13:26:45 |      35 | /profile.php |
| server2     | 2012-07-27 13:25:10 |      20 | /profile.php |
| server3     | 2012-07-27 13:26:45 |      30 | /login.php   |
| server4     | 2012-07-27 13:27:05 |      12 | /video.php   |
| server1     | 2012-07-27 13:27:45 |       7 | /video.php   |
+-------------+---------------------+---------+--------------+
9 rows in set (0.00 sec)
問2 このファイルからサーバー名とアクセス先だけ表示しろ
mysqlSELECT server_host, access_url
    -> FROM log;
+-------------+--------------+
| server_host | access_url   |
+-------------+--------------+
| server1     | /video.php   |
| server2     | /profile.php |
| server3     | /login.php   |
| server1     | /profile.php |
| server2     | /profile.php |
| server2     | /profile.php |
| server3     | /login.php   |
| server4     | /video.php   |
| server1     | /video.php   |
+-------------+--------------+
9 rows in set (0.00 sec)
問3 このファイルからserver4の行だけ表示しろ
mysql> CREATE INDEX log_ix1 ON log (server_host);
Query OK, 0 rows affected (0.01 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysqlSELECT server_host, access_time, user_id, access_url
    -> FROM log
    -> WHERE server_host = 'server4';
+-------------+---------------------+---------+------------+
| server_host | access_time         | user_id | access_url |
+-------------+---------------------+---------+------------+
| server4     | 2012-07-27 13:27:05 |      12 | /video.php |
+-------------+---------------------+---------+------------+
1 row in set (0.00 sec)

インデックスを作らなかった場合は減点します。

問4 このファイルの行数を表示しろ
mysqlSELECT COUNT(*)
    -> FROM log;
+----------+
| COUNT(*) |
+----------+
|        9 |
+----------+
1 row in set (0.00 sec)
問5 このファイルサーバー名、ユーザーIDの昇順で5行だけ表示しろ
mysqlSELECT server_host, access_time, user_id, access_url
    -> FROM log
    -> ORDER BY server_host, user_id
    -> LIMIT 5;
+-------------+---------------------+---------+--------------+
| server_host | access_time         | user_id | access_url   |
+-------------+---------------------+---------+--------------+
| server1     | 2012-07-27 13:27:45 |       7 | /video.php   |
| server1     | 2012-07-27 13:25:05 |       8 | /profile.php |
| server1     | 2012-07-27 13:25:24 |      30 | /video.php   |
| server2     | 2012-07-27 13:25:10 |      20 | /profile.php |
| server2     | 2012-07-27 13:25:10 |      20 | /profile.php |
+-------------+---------------------+---------+--------------+
5 rows in set (0.00 sec)
問6 このファイルには重複行がある。重複行はまとめて数え行数を表示しろ
mysqlSELECT COUNT(DISTINCT server_host, access_time, user_id, access_url)
    -> FROM log;
+---------------------------------------------------------------+
| COUNT(DISTINCT server_host, access_time, user_id, access_url) |
+---------------------------------------------------------------+
|                                                             8 |
+---------------------------------------------------------------+
1 row in set (0.00 sec)

COUNT関数の中にDISTINCTを書けるのは覚えておくと便利です。

問7 このログのUU(ユニークユーザー)数を表示しろ
mysqlSELECT COUNT(DISTINCT user_id)
    -> FROM log;
+-------------------------+
| COUNT(DISTINCT user_id) |
+-------------------------+
|                       6 |
+-------------------------+
1 row in set (0.00 sec)
問8 このログアクセス先ごとにアクセス数を数え上位1つを表示しろ
mysqlSELECT access_url, COUNT(*)
    -> FROM log
    -> GROUP BY access_url
    -> ORDER BY COUNT(*) DESC
    -> LIMIT 1;
+--------------+----------+
| access_url   | COUNT(*) |
+--------------+----------+
| /profile.php |        4 |
+--------------+----------+
1 row in set (0.00 sec)
問9 このログのserverという文字列をxxxという文字列に変え、サーバー毎のアクセス数を表示しろ
mysqlSELECT REPLACE(server_host, 'server', 'xxx'), COUNT(*)
    -> FROM log
    -> GROUP BY server_host;
+---------------------------------------+----------+
| REPLACE(server_host, 'server', 'xxx') | COUNT(*) |
+---------------------------------------+----------+
| xxx1                                  |        3 |
| xxx2                                  |        3 |
| xxx3                                  |        2 |
| xxx4                                  |        1 |
+---------------------------------------+----------+
4 rows in set (0.00 sec)
10 このログユーザーID10以上の人のユニークユーザーIDユーザーIDソートして表示しろ
mysqlSELECT DISTINCT user_id
    -> FROM log
    -> WHERE user_id >= 10
    -> ORDER BY user_id;
+---------+
| user_id |
+---------+
|      12 |
|      20 |
|      30 |
|      35 |
+---------+
4 rows in set (0.00 sec)
個人的な感触

2012-04-24

Microsoft Kinect

http://www.tekwind.co.jp/information/entry_29.php

これを使って、たくさんの人間からサンプルをとって

大量のデータHADOOP 環境で動くDWHにつっこめば、

ある成人病の人は、動きや骨の相対位置や声などにどういう相関が高いとか

ニートの歩き方はどんな傾向だとか、抜け出すとどんな風になるかとか統計処理すれば

検診とかする前に予防などできるようになるだろう。

しか

ただ測って分類しただけじゃ、能がないぜ。おれらは家畜じゃないからよ。

会社の人事は、入社面接とか人事考課で導入したがるかもしれんが)

人間環境努力傾向などでいくらでも良く(悪くも)なるわけで

結果から因果関係を掘り下げたり、

希望する本人にあるべき方向性フィードバックいかなきゃならん。

2012-03-29

http://anond.hatelabo.jp/20120329142241

そういう人もいるだろうけど、俺が言ってるのはどっちかというと、大規模分散処理環境を作ることそのもの情熱を燃やしてる人たち。

応用先はどうでもいいという風なのがよくわからんのだよなあ。hadoopコマンド叩いてるだけで気持ちよくてたまんないって感じなんだろうか。

2011-12-07

http://anond.hatelabo.jp/20111207191239

これは規模じゃなくて難易度の話だろ

難易度の話をするならCで言うポインタの理解なりの例えがあるんじゃないか

javaだとなんだ、、、オブジェクト指向コード書けることか?

元増田に話しとくとjavaで開発するにもHadoopstrutsやらのフレームワーク

jspなどなど色々ある

Androidアプリはその中じゃそんなに難しい部類ではないと思う

別の言語使ってもAPIやらフレームワークやらOSやら言語以外の知識と理解は山ほど必要だ

別の稼ぎ口があってプログラマが向いていないと思うなら、今なら遅くないか

引き返したほうがいいな

自分は他に稼ぎ口がないからコレで生きていくしか無い

似たように苦しむ事が多いが腹をくくってる

2011-02-11

http://anond.hatelabo.jp/20110211004212

元記事にも100人1000人のユーザーならSQLでも問題ないって話をしたと思うが 1万人ユーザーって簡単なの?そもそも。って話だよね。

そしてその時のサービスは本当にツイッターたいな大量データサービスなの?と。(それってツイッターのコンペでサービスとして成り立たなそう。違えばいいけど)

 

ORACLでハイエンドサーバーグリッド使うのと 自分MYSQL分散書くのと HADOOPにするのと どれが得かはやってみないと分からん

ダウンタイムを短くしようとすると、2011年現在では組めるならばオラクルな気はする。すくなくとも簡易的にベンチとらないとわからん

 

Hadoopの怖いところは所詮Apache.orgということで、Apache.httpdのように急激な開発が流行から外れて止まってるかのようになることがあることなんだよねぇ。

Apache.httpdって、MPMいまだpreforkとか あってWorkerで event とかって、しばらく前は、いま不安定とかそういう開発状況だと思ってるんだけど。

event MPMってもう安定化したの?event MPMのコア概念である

 『Workerですら遅いから カーネルコールバックを使おうっていう流れ』自体はもう10年近く昔の概念だと思ってるんだけど・・・

 

現在 一番イケてるのはHADOOPだとは思うけど。 Rubyが一時期ほどには勢いがないのと一緒で(いちおうRoRから知っているみとしては、RoRによる隆盛が奇跡のようなものだが

まだ、怖いよね。 障害復旧の実装もまだ、弱いし。個人的にはZookeeperがもっとちゃんとなったら、もう1度 調査する! という感じで塩漬け状態なのがHadoop.

少なくとも単一障害点のフェールーバー周りが本家でどうなるかとかだねー。

 

どうでもいいけどPHPの方が好きなので PHP for apache event MPMを安定化希望・・・ まぁ、Perlもいいよね。

 

だがRubyPASCAL だけは無理だ。BEGINとか書いてあるソースを高速に読みこむのは無理。()ぐらいならいけるけど、BEGINってなんだよ。図形認識できないから読みづらいよ。

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