 
|
はてなキーワード: プログラマとは
うん、別に「知られて困らない」なら、普通に意識せずに確定申告すればいい。
会社に副業禁止規定があっても、本業に支障がない副業まで禁止するのは無理 （って判例があったはず）。
親から不動産相続したとかなら、会社がよっぽど理不尽ブラックでないかぎり正々堂々と確定申告すればいいと思う．
ただ、例えばIT企業のプログラマが趣味でWebサイト作って、業務で得た知識活かしてバリバリSEOとかしてアフィリエイトで稼ぐとかだと、
会社にばれたくないってケースはけっこうある。
「人数増やすと…」について補足。
http://ja.wikipedia.org/wiki/%E4%BA%BA%E6%9C%88%E3%81%AE%E7%A5%9E%E8%A9%B1
スケジュールが遅れているソフトウェア開発プロジェクトにさらにプログラマを追加すると、そのプロジェクトはさらに大幅に遅れる。これを「ブルックスの法則」という。この大幅に遅れることの原因は、新しく参加するプログラマがプロジェクトについて学ぶ時間が必要となること、およびプログラマが増えることでコミュニケーションのオーバーヘッドが増えることである。N 人の人々が自分たちの間でコミュニケーションをとる場合 (階層的な組織を構成していないものと考える) 、N が増加すると、彼らの生産量 M は減少する。生産量 M が負の量になることさえ起こりうる (例えば、ある日の終業時点における全ての残務作業量が、その日の始業時点における全ての残務作業量よりも大きい場合——たくさんのバグを作りこんでしまった場合など) 。
今回のケースでは、60人が1300人になったので、コミュニケーション量は約477倍になるわけだ。
http://www.asahi.com/business/update/0124/TKY201201240616.html 24日のニュース
http://www.meti.go.jp/press/20100820003/20100820003-2.pdf その発端ともいえる二年前の報告書
始まりは、ありがちな汚職だと思えた･･･その巨大プロジェクトの実体は！
1部～2部で内容が重複してるから、ストーリーだけ知りたい人は3部から読むのをお勧めする。図表もあるのでわかりやすい。
これについてのブコメやTwitterを見ていると不祥事を叩いたり、やめた事を批判して55億賠償しろって人も結構いるのだけど、なんかもうそういう問題よりも気になる点が山ほどある。自分の感想をまとめておく。不祥事そのものより、その裏にあるプロジェクト全体や日本の開発にありがちな問題にもっと注目されて欲しいのでそういう視点で書く。
入札前の情報漏れにしても、その後のNTTDとのやりとりにしても、情報漏洩やそれにまつわる金銭の動きは犯罪だ。けどもそれが行われた動機が私利私欲のためだけとは思えない。
共有されるべき情報が共有できるようにされていない。やりとりできるべき情報ができるようにされていない。必要な情報がちゃんと流れていないから、イレギュラーな方法で流れている。特許庁, NTTD, TSOL この三社間のコミュニケーションがどこも投げやり丸投げ気味で、慢性的に情報不足だった感が伺える。ここを改善する必要があるよね。
極秘情報は必要最小限にして、より情報の共有を図るべき、入札前に必要な情報は公開できるようにすべきって報告書でも書かれている。
入札での評価が金額偏重で、マネージメント力を評価してなかったって問題。マネージメント力を評価してないのマジやばい。あ、でもマネージメント力を評価するには、全体を理解できる人材が必要だよね。で、次の問題に繋がるんだけど。
報告書だと、上流の話しか出てこない。だから、｢設計もろくにできないで55億無駄にしたのか！｣って話になるけど、ちょっと待って。設計しかできない人間が山ほどいても捗るわけがないってことなんだよ。特に、このプロジェクトは既存システムを0から作り直すのだから、既存システムをよく理解して、また既存システムにかかわる技術者とよくコミュニケーションが取れて、それを設計に正しく咀嚼できるスキルの持ち主が必要で、設計しかできない人材ではなく全体を理解できる人材が必要だったはず。
既存システムをちゃんと理解できてない人間だらけになったということが報告書でも繰り返し指摘されてるけど、その根底には設計しかできない人間が山ほどいても捗るわけがないという問題があると思うんだ。
6年？そもそも設計に数年ってのが、もうそういうの無理が来てるって感じ？6年経つ間に色々変わっちゃう。
どうしても、がちがちのウォーターフォールでやるなら、もっと受注も小分けにして、まずは既存システムの仕様まとめプロジェクトから開始するのが良かったんじゃないかな。
6年まとめてどん！だと中断の決断もなかなかできないよね。
これだけプロジェクトが炎上していたのに、汚職がきっかけで調査が入るまで炎上がちゃんと認知されていなかったというのがやばくね？もし汚職が見つからなかったら、炎上のまま･･･
これは国のプロジェクトだから汚職で厳しい調査が入って、プロジェクト炎上まで色々赤裸になったという見方もあるかも。民間だったらもっとなし崩し的に炎上プロジェクトを続行するケースが多いように思う。
もうね、
ＴＳＯＬによる設計作業は ，平成１８年当初６０人体制でプロジェクトをスタートさせたが，翌年初めには遅延が 始まったため，順次増員を行い，同１９年３月には２００人，同年５月には４５０人体制とした。
(((( ；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
ＴＳＯＬは ，工程の遅れの解消に向けて，大幅な人員の増強でこれに対処しようとし，平成２０年１１月以降に は １３００人もの体制を整えたが
(((( ；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
あたりまえのこと。TSOLでも仕様をしっかり理解してる人は少数だったのに、増員の9割は下請けだったのだから、さらに破滅の様相が想像できるってものだよ。
大量の下請け同士の連携や情報共有がされていなかった。経験やノウハウの共有がなされていなかった。と報告書にある。なんでこうなっちゃうんだろうな。何のためのプロジェクト管理なんだろ。ノウハウの管理はもっと意識されるべきだよ。
人数増やしてプロジェクトが炎上するというのは、お約束すぎる。規模の大小や分野にかかわらず、開発をやった事のある人ならわかると思う。
開発や設計って？という人にもわかりやすいように説明する。
例えば、優れた売れっ子のマンガ家がいて、老練な担当者がついていて、名アシスタントがいて、才能ある若手アシスタントがいて、10人のチームでマンガを描いていたとしよう。一方、大して技術もない凡人を100人集めて、前出のチームと同じマンガができるとかと聞かれたらどう思うだろう？殆どの人はそれは無理じゃない？と思うだろう。1000人でも無理かもしれない。
開発も同じなんだよ、本質的にはね。
でもそう思われにくいのはなんでだろう？それは多分、開発に従事する人にはマンガ家のような才能や際立った技術は必要ないと思われてるからだ。言われた所を言われたようにベタを塗るだけがプログラマの仕事だと思われているからだ。実際それをプログラマなのだと定義している会社もある。技術はお金にならない低俗なものだという偏ったイメージもこの世界には蔓延している。それが上流偏重の問題なんだ。
売れっ子のマンガ家のような設計(マンガで言えばネームや原作)からプログラミングまでこなせる技術者、老練な担当者のようなプロジェクトマネージャ、名アシスタントのような匠のプログラマ、勉強熱心な技術者は実際に存在してる。並以下の人材を倍集めたって100人集めたって彼らと同じものができるわけじゃない。
でも、どんなプロジェクトにもそんなスター的な人材が確保できるとはいえないし、単純な増員で対応できるようにする必要が、日本の大きな会社や大きなプロジェクトではあった。それを可能にするのが分業化だ。工程を徹底的に分業化することで、末端のセクションの習得コストを出来る限り低くし、品質の維持も図る。言い方を変えれば、創作を出来る限り製造にするということ。
それによるデメリットは明確だよね。新しいアイデアが実現されにくくなる。時代の流れの速さに追いついていけない。個々の持っているスキルが生かされない、技術が評価されない。技術者のモチベーションが下がる。なにより、正しい分業化とマネージメントが行われずに盲目的に人数を増やすと、ただただ炎上にしかならないってこと。お金だけが莫大にかかっていくということ。
これは間違いない。
このまま続けていたら、沢山の技術者の尊い人生がデスマに捧げられただろう。数年間のどろどろの煮詰まった成果物は、黒歴史を語るまいとひた隠しに、更なる問題を生み出しながら使われ続けただろう。考えただけで悪夢だ。
このプロジェクトのやりなおしに、どれだけ前回の経験が生かされるのか、そこにこそ注目していきたいと思う。
時間ができたら後で読む
http://www.jpo.go.jp/torikumi/system/system_optimize_re.htm
実際の業務の内容がある
http://myatsumoto.hatenablog.com/entry/2012/01/26/082554 良いまとめ
今までもてなかったわけじゃない。
何人か付き合ったこともあった。
でも、本当は好きじゃなかった。何となく付き合った。そして別れた。
もちろん、プロもない。純潔だ。
その女性は今までと違う。
めちゃくちゃタイプだ。いや、好きだ。
85kgらしい。うん、まぁデブだな。俺より重い。
もちろん体だけじゃない。性格も最高だ。
そのくせ打たれ弱いのにプライドが高い。我ながら面倒な人間だ。
でも彼女はそんな俺に、とにかく優しくておっとりしてて言葉が温かい。
独立の夢も応援してくれている。毎朝メールもくれる。５分で返事が来る。
丸くておしゃれで可愛い。めちゃ可愛い。ピアノも上手いし料理も上手い。
たぶん、俺のことが好きなんだと思う。分かる。これは間違いない。
でも正直言えば、体が一番好きだ。
っていうかやりたい。やりまくりたい。出来るか分からんがぎゅーしたい。
居ても立ってもいられなくて、毎日オナニーしまくってる。異常だと思う。
だから、一生一緒にいてほしいって言うことにした。
っていうか彼女は俺を幸せにできる。間違いない。そして俺は絶対浮気しない。
デートは再来週だけど、服買って部屋を片付けなきゃ。
なんだか緊張する。完全に浮かれてるな、俺。これが恋か。
とりあえずここで宣言しておく。
俺は生まれて初めて告白する。
中には凄まじく優秀な人達もいるんだけど、今じゃ就職でとりあえず大手だからと
理由で入ったのが半数以上だし技術なんてものが簡単に生まれるわけがない。
今となっちゃ神領域の技術者はどの会社も社員の2%ぐらいだろうね。
ところでWeb(笑)企業で努めてる人にはIT技術以外に精通している業務や知識ってあるの？
低能の人からどうやって金を巻き上げるかを考えるのって面白そうだね！！
DeNAが「ソースは公開するが勝手な改変禁止、用途限定」の極めてユニークなライセンスを打ち出して数時間後に撤回した。
https://github.com/DeNADev/Arctic.js/commit/b92eea0a83b9b01c53eb3f6fb65fdb8af6bc0aab#diff-1
さて、「内容は公開するが、内容の改変は許諾が必要」というオリジナリティ溢れるライセンスを、この記事では「DeNAスタイルライセンス」と呼ぶ事としたい。さて、DeNAライセンスの内容から、DeNAのたくらみが幾つか想像できる。
「ウチのソースを侵害しとるやんけワレぇ、出るトコ出てもらおかい」と中小ソフトハウスを牽制恫喝し、囲い込むために敢えてソースを公開し、他社プロダクトの類似動作やモバゲー参加ベンダーへの牽制に利用したかった、と読むことは難しくあるまい。それはDeNAスタイルライセンスの指針はOSSのそれではなく、明らかに特許指向であるからも伺い知れる。MicrosoftやAppleに範を取り、知財戦争における兵器兼防衛機構としてDeNAスタイルライセンスで守られたコードを行使したかったであろう事は想像に難くない。
多くの日本企業が製品のOSS化に踏み切れないのは、正に上記の一点に尽きる。
というのがエンタープライズエグゼグティブ様の本音であることを考えると、DeNAスタイルライセンスは、日本企業の欲望を満たす厚顔無恥なジャパニーズスタイルライセンスとして社畜や下請けの皆様の献身を一身に集めたであろう。仕事のない下請けソフトハウスが、DeNAスタイルライセンスの大手SIer謹製フレームワークを必死にカイゼンしてコネ作りに励む美しい光景が、数年後には見られたかも知れない。
DeNAスタイルライセンスの隆盛が、日本のIT企業に利益を齎したかもしれないのに。DeNAスタイルライセンスが、日本のIT企業を更に強固にガラパゴス化して守る鉄壁のゾウガメの甲羅になれたかもしれないのに。「Googleっぽいからいいよね」みたいなノリでMITライセンスに安易に逃げたDeNAの及び腰が残念でなりませんでした。まる。
Pythonをかれこれ5年ほど使っているけれど、いい加減頭にきた。
大体頭に来るような内容というのは限られていて大体は
http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm
本当にPythonを殺し、メインのスクリプト言語となる望みを、あるいは何であれメインの言語となる望みを絶ったのは、永久凍土の問題なのだ。人々はいまだ埋め込みインタプリタにTclを使っている。どのような面から見てもTclよりPythonの方が遥かに優れているというのに——ただし永久凍土の問題を別にすれば。
これに尽きる。
よく言われるが、インデントに縛りがあるのもselfが付くのも慣れてしまえばさほど気にならないし、むしろ魅力的とも感じる。
しかし、Pythonを本当の意味で糞たらしめて居るのはその言語を使っているコミュニティがあまりにも思考停止しているからだ。
インデントやselfが気に入らないなんて些細な問題を他の言語使いから散々文句を言われたがために、本当の意味で言語の弱点になっている部分が指摘された時にも「それは言語仕様が悪いんじゃない。言語仕様に沿って考えられないお前の頭が悪いだけだ」と言ってくる。
実際のところ、Pythonの仕様には言い逃れのできない仕様の穴は幾つもある。もちろんよく引き合いに出されるRubyやPerlにも仕様の落とし穴は山ほどある。仕様の穴そのものは実はそんなに深刻な問題ではない。
真に問題なのは、Pythonコミュニティはその仕様の穴を断じて穴と認めない事だ。
言語同士でdisり合いになったとき、何かその穴をつつかれた場合の各人の反応はおよそこんな感じだ。
Perl使い「そうだよね、そこの仕様は頭悪いよね。でもPerl6のこの機能使えばこんなに短く綺麗に書けるんだぜ(と全く読めないコードを出す)」
Ruby使い「うんうん、仕様の話題でもそこは殺人現場とか呼ばれてるね。コミュニティ的にはこっちの機能を使うことを推奨しててそっちはobsolatedだね」
PHP使い「それ言い出したらこっちにこんなに大きな地雷あるし、この地雷なんてもっと大きいぜ。ほんとPHPは地獄だぜ」
Python使い「お前の思考通りに言語が動くんじゃなくてお前の思考を言語に添わせるんだよ、言語の挙動すら理解せずに使おうとするんじゃねえ」
こんな感じに、まず最初に質問者へ人格攻撃を行う。インデント言語であることやselfの問題について未熟なプログラマからのどうでもいい指摘を散々受け流してきたPythonコミュニティは、言語仕様について文句を言われる事に慣れているためまず相手を攻撃する。初心者を寒波が洗礼するのだ。
言語仕様が汚くなっている事まではどの言語も一緒なのだけれど、Pythonコミュニティだけは欠点を認めず必死に(∩ ﾟдﾟ)アーアーきこえないという態度を取る。
これこそがPythonを糞言語たらしめる最大の弱点である永久凍土の問題。コミュニティが凍れば言語の進歩も凍る。
Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ
端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに
PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？
けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか
数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ…
Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとして大成功していたはずなのに、
Railsなんかが登場したおかげで、すっかり影が薄くなってしまいますた....
ってか、railsにインスパイアされたフレームワークって今じゃ幾らでもあるよね
djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、
pythonやPHPの方がユーザー数は圧倒的に多いと思うんだけど
本家のrailsって、他を遥かに越えるほど良いものなんだっけ？
44
Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい
djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）
だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている
C a k e P H P は う ん こ
CakePHP使ってんの？
可哀そうにw
でもやっぱりいつもの使い慣れたLL(Python/Ruby)で
Webサービスを書きたいってのがある
求人数は
Ruby on Rails＞＞＞＞＞＞＞＞Django
http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=
どういうことなの？
求人数が多いのはそのためだと思うよ
なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・
Pythonのほうが使いやすいと思うのだがフレームワークはRailsが優位なんだろうか
Djangoは周辺ライブラリが微妙だし本体も鈍くさい感じがする。
でも、FlaskはSinatraより好きだから、Pythonが嫌いってわけではない。むしろ好き。
ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。
同感だ
同じように思っている人が他にもいて安心した
PHPはフレームワークが乱立しすぎているから、RailsをPHPで実装してみようというやつが出てきた。
それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、
ただ、どうやってもRailsもどきがRailsを超えることはできないのは間違いない。
パクリはオリジナルを超えられない(ｷﾘｯ って定型句だけど、
これってｷﾘｯって言いたいだけだと思う。
D言語って超えたって？
B言語って超えたって？
PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない
まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ
そういう理由じゃなくてRailsのほうが単純に情報もプラグインも多いからでしょ
linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
わざわざ不合理で不完全な言語を使うなんて
もしも
＞linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
真実であるのなら、今頃はdjangoの情報とプラグインが溢れかえっているはず
yumや、gdbとgnomeの拡張がpythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。
ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。
というか、世界中のPythonプログラマが Remeber Zope!! を合い言葉に
打倒RailsたるWebフレームワークを開発しているはずだけど、
Railsも登場してから、かなりの年月が経過しているんだけどなぁ....
その間にもRailsはRails 3が登場して、REST/AJAXの強化等の進化が継続しているよ
Ruby では
ary.map {|x| x**2}
map(lambda x: x**2, ary)
となり、lambda の本体が1つの式では表現しきれなくなると
.....
と書き換える必要があります。
f = lambda x:(x and f(x-1)*x)or 1
RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから、
f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}
または
f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}
と書けます。lambda内でreturnが使えますから、書きたければ
f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}
でもOKです。
348
これはPythonをdisっているように見せかけてRubyをdisっているのか？ と一瞬思ってしまったｗ
だってRubyのほうが長くない？CLのfuncallみたいなcall()がちょっとうざいし…
そしてどっちもlambda式の中で束縛変数の名前で再帰可能、と
print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]
暗号のように見える。
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}
思考の流れと、コードの流れが一致しているので書きやすい。
map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))
pythonて可読性が高いのをうたってる割にはそこいまいちだよね
Rubyの場合には、左から右へと無名関数がデータフローあるいは
関数型プログラミングに不慣れな初心者でも、参照透明性のあるコードが自然に書ける
プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby
それと比較すると、Pythonのコードは、関数型プログラミングというものが
いかに高度で難解なものであるかという事をもったいぶってプログラマに押し付ける
もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう
階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す
result_list = source_list.map { |elem|
x = foo(elem.x) # ここが局所宣言を書く部分
x + y # 最後に評価された式の値が、無名関数のリターン値になる
}
Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから、
x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける
このポイントは、実用的なプログラムを関数型風で書こうとした時に、威力を発揮する
余計分かりづらくなった
高卒ドカタなんだろうなぁと可哀想になる
集合の表記に似せてることが分かるから
355
＞map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。
関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね
Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ
[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')
Pythonだと読みにくい。
'-'.join(map(str, reversed(sorted([1,4,3,2]))))
Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....
カッコだらけのコードを分かりやすくする基本的な方法は静的単一代入じゃないか
Rubyのやり方は基本ではなく玄人のやり方だろ
Pythonでは組み込みの型でメソッドチェインはやって欲しくないな
似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。
372
外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてますね
Rubyユーザーは列挙可能なものはmapやselectできて当然だろって思ってる気がします
Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる
得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない
Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い
「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く
無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
自分で調べた範囲で
http://real-seo.net/my-seo/seovo3.html
・はてなダイアリーは携帯向けのアフィリエイトには向かないっぽい
携帯からアクセスすると、リンク先が強制的にはてなMobileGatewayを通してモバイル用に
「はてなMobileGatewayについて」（はてなMobileGateway）
「変換されないプレーンなリンクを貼る方法ってありますでしょうか？？」（人力検索はてな）
http://q.hatena.ne.jp/1255754183
→http://d.hatena.ne.jp/はてなID/mobile
「モバイルサイトをPCで見るためのツールやFirefoxアドオン」（NHN Japanディレクターブログ）
http://blog.livedoor.jp/ld_directors/archives/51079649.html
・amazonアソシエイトにGmailのメールアドレスで登録して紹介料をAmazonギフト券で受け取る人は要注意
「Amazon ギフト券が Gmail の迷惑メールに振り分けられて困る」（新電波）
http://denpa-shinbun.com/computer/amazon-gift-gmail.html
amazonは紹介料3.5％〜、でも有効期限が24時間で短い
「楽天とアマゾンの比較 アフィリエイト報酬が決まるクッキー有効期限が30倍近く違う」
http://iopower.info/wordpress/archives/167
「楽天アフィリエイトとアマゾンアソシエイトどっちが有利なのか?」（アフィリエイトで稼ぐ方法）
http://affiliate.nufufu.com/archives/283
http://www.hatena.ne.jp/info/affiliate
「はてなの書けない「はてなダイアリーでアフィリエイトをはじめよう」（ぼくははまちゃん！）
http://d.hatena.ne.jp/Hamachiya2/20080624/affiliate
「はてなダイアリーへの無料アクセス解析設置まとめ」（ 元デザイナーのプログラマン）
http://d.hatena.ne.jp/ccoo_nick/20100626/1277566529
「Amazonアソシエイトの紹介料を寄付する」と書いてはいけないようです（頭ん中）
http://www.msng.info/archives/2011/04/i-dont-say-i-donate.php
他になにかあれば追記お願い
近年、有名人などが亡くなった際に、亡くなった方の属する宗教・宗派が分からないのに、気軽に「ご冥福をお祈りいたします」というフレーズを掲示板やコメント欄などに書き込む人が多い。
ぶっちゃけ、よく怖くないな、と思う。「ご冥福」というのは、単純に考えれば「冥土での幸福」ということなのだから、「冥土」が定義されていない宗教では未定義になる。あるいは、「冥福」より広く解釈して「死後の幸福」という意味で使ったとしても、「死後は必ず幸せになれる」という教義の宗教の場合は、心配しなくてもいいことを祈っていることになる。空文と同じだ。
というわけで、未定義エラーまたは空文になる可能性の高い「ご冥福をお祈りいたします」という言葉は、慎重なプログラマなら避けるべき言葉である。「ご冥福」などという教義依存（環境依存）な言葉を持ちださなくとも、「謹んでお悔やみ申し上げます。」に言い換えれば良いだけの話だ。
JavaScript って生き物っぽいって思ったのがきっかけだった。
なんか菌？に遺伝子いれてたんぱく質を生産させるやつ？ Function は菌の細胞膜で prototype は遺伝子で、だから prototype に全然関係ない違う生物の遺伝子を生きてる菌に入れちゃったり。そうすると全然ちがうたんぱく質が生産されたり。prototype にべべーっとコピーして追加するのなんてまさしくそれっぽい。
だってプロトタイプベースって、生き物しかいない世界じゃない？基本的に。インスタンスってのは生き物じゃない設計図があってそれにしたがって出来た生き物がインスタンスってイメージあんだけど。プロトタイプベースの世界にはそんな設計図も生き物じゃないものもないよね？なのにわざわざインスタンスっていうのに何か違和感？ご都合主義的なもの感じる。クラスは型で、インスタンスを実体だとかなんとかって氾濫してるせいかな。多分この辺の用語が JavaScript をわかりにくくさせてる気がする。
僕の感覚では、オブジェクトってのは生き物で、クラスベースってのは神が設計図に基づいて生き物を生産してる世界で、インスタンスベースってのは生き物が生き物を複製してる世界のイメージだ。多分、原始の生物はインスタンスベースみたいな世界で、海の中にうようよしてたんだろうな、とか。
オブジェクトじゃないものは、生き物じゃない死んでるたんぱく質や RNA の破片みたいな。それだけじゃなにもできないみたいな。それだけじゃ命がないから、生き物の殻に詰めるってのが JavaScript のコンストラクタのイメージ。
Perl の bless したらこれはもう命入ったよ生き物だからねっあとは勝手にしてねってのも、Python の名前空間さえあればなんとかなるよねってのも、JavaScript のハッシュさえあれば世界作れるよねってのも、みんなどこか似ている。ちゃんと OOP を理解できてるかは別としてもこの三つはわりとすぐやりたいことができた。昔 Java の本を買ってきて挫折したのにくらべたら、なぜかずっとわかりやすかった。（bless という命名はすごく洒落てる）
全然関係ないけど、Django の日本語リファレンスは何か萌える。ラクダ本の日本語訳はむかつくのに。
プログラミングを始めたばっかりの時は、なんだか難しい用語の意味を理解しないと OOP がわからないと思ってた。それは僕らの住んでる世界とは全然関係のないプログラミングの技術ってやつだと思ってた。
でも多分違う。
世界が動く仕組みさえあれば、あとは作り手に世界の成り立ちを抽象化する表現力さえあれば、世界は勝手に表現されていくし、動き出してく。たまたま僕らの世界はオブジェクトなもので溢れていて、プログラミング言語が進化すれば世界に似るのも当然だろう。いや逆か。プログラミング言語が世界に似てきたから、オブジェクトなんていう世界に似た概念が出てきたってことか。なんだか難しい用語ってのは、その表現の一部分の技術に名前をつけてるだけなんだな、と。例えば何とか歌唱法や何々画法とか何とかレトリックとかパースの取り方みたいなのと同じ。それは表現を理解する手助けにはなるけど、その意味を知る事がイコール表現力をあげることにはならないんだよね。これに気づくのに遠回りしすぎたなあ。
（知識を得るだけで、100% 還元される人もいるかもしれないけど、そんなのは一部の天才だけだと思う。殆どの凡人はそうはいかない。とはいえ、元の錬度が低ければ、コツをいくつか教わるだけでいきなりうまくいくこともある。ただ、それをまるまんま実力だと思うのは、どんな分野でも危険だ。恋愛テクニックやらを必死に読んでる連中が男女間の深い人間関係を上手くやれてるとはちょっと想像できない！）
プログラミングで表現力を上げるにはどうすればいいんだろう。きっと他と同じだろうな。いい表現を沢山味わって、世界をよく観察して、どう成り立ってるかどう動いてるか、私達はそれをどう認知しているのか、考えることかもしれない。漫画家を志す人が美術解剖学を学んだり、優れた画家が絵筆で世界を生々しく描写するように、優れたプログラマは世界のなりたちをプログラムに写し取ったり、世界の仕組みを作る事が出来るのだと思う。
いやだから、苦労しろってことなんでしょ。
英語のできないプログラマは、UIが洗礼されて情報量の多い英語サイトは使えません。
その差がありますよ。
stackoverflowみてて思ったんですが（英語さっぱりできないので本当に使えるのかわかりませんが）
UI洗練されてるし情報量多いし。しかも似たようなサイトがいっぱいあるんでしょ。
それに比べて日本語のQAサイトはokwave、人力検索はてな、2ch。
だめじゃん。
なんか、誰の役に立つのか分からんけど、私が高校生の頃にこういう説明があったら良かったなぁ……とふと思ったので書いてみた。
さて、大学の工学部機械工学科に入学するとしよう。基本的に機械工学科に含まれる研究分野は多い。もちろんそれには理由があるのだが、それでもほぼすべての学生が学ぶ共通の内容があり、機械工学科を卒業した学生に企業が期待するのはそれらの基礎知識である。そういう意味で機械工学は非常に実学に近いと言っても良い。
機械工学科の教員は本当に口を酸っぱくして「四力を身につけろ」と何度も何度も授業の度に言ってくる。古いタイプの教員ほどその傾向は強い。いわく、「専門分野の基礎がわかっている人間が社会では強い」、「四力が身についていなければ学科長が許しても俺が卒業させない」、云々。で、その四力というのは以下の４つの「力学」のことを指す。
機械力学というのはいわゆるニュートンの力学でいう「剛体の力学」で、弾性・塑性変形しない対象がどのように運動するかを扱う。振動工学とか解析力学とかはだいたいこの延長線上で学ぶ。高校の力学に微分積分を足した感じだと思えばいい。
熱力学はマクロで見た気体や液体の持つエネルギーを対象にする。これも微分積分やエンタルピー・エントロピーの概念を除けば高校で学べる物理とそう大差はない。次の流体力学と合わせて熱流体力学というジャンルを構成していることもある。統計力学は熱力学の延長線上で学ぶことが多いが、量子力学とともに挫折する学生が非常に多い。
流体力学はその名の通り気体と液体を合わせた流体の運動について学ぶ。航空関係の仕事がやりたいなら必須。多くの近似法を学ぶが現実にはコンピュータ・シミュレーションが用いられるのであまり細かく勉強しても役に立つ場面は少ないかもしれない。下の材料力学とは連続体力学という共通の基礎理論を持つ遠い親戚。
最後の材料力学は、弾性をもつ（＝フックの法則に従う）固体の変形が対象。建築学科とか土木工学科だと構造力学という名前で開講されているが、内容はだいたい一緒。これも多くの近似が含まれる体系で、実際にはコンピュータを使った有限要素法でシミュレーションする場面が多い。とはいえ基本を大学学部時代に学んでおくことは非常に重要。
で、これら４つの科目がどう生きてくるかというと、たとえば２０世紀における機械工学の結晶であるところのエンジンの設計なんかにはこれら全部が関わってくる。機械にかかる荷重や振動を解析し（機械力学）、エネルギー効率の高いサイクルを実現し（熱力学）、吸気と排気がスムーズに行える仕組みを作り（流体力学）、これらの条件に耐えうる材料を選ぶ（材料力学）。もちろん就職したあとにこれらすべてに関わることはないし、実際に使える高度な知識を教員が授けるわけではないが、機械の設計に際しては必須の基礎知識ばかり。とはいえ後のように四力から直接発展した研究をしているところはまれで、院試のために勉強したのに後はもう使わなくなった、なんてこともままあるわけだが……。
なお高専からの編入生が入ってくるのは２～３回生なのだが、彼らはすでに四力を身につけていることが多く、運が良ければ通常の学部生からは羨望と尊敬のまなざしを勝ち得ることができる（しかし英語ができないので研究室に入ってから苦労することが多いようだ）。
高度な数学や電磁気学であったり、機械加工や金属材料や設計に関する専門的な知識もカリキュラムに含まれることが多い。みんな大好きロボットは制御工学の範疇で、これは四力とは別に学ぶことになる。ロボット＝メカトロのもう一つの必須分野である電気電子系の講義はほとんどないので独学で学ぶ羽目になるが、微分方程式が解ければ理解にはさして問題はない。プログラミングや数値計算などの授業は開講されていることもあるしされていないこともある。とはいえ機械工学科を出てガチガチのプログラマになることはほとんどないし、教えてくれてもFORTRANか、せいぜいＣが限界である。さすがにBasicを教えているところはない。……ないと信じたい。
実習や実験がドカドカと入ってくるのは理系の宿命なのだが、特徴的なのはＣＡＤの実習。おそらく就職したら即使う（可能性がある）ので、研究室に入る前に一度経験しておくといい。もちろん実際にＣＡＤで製図するのは専門や工業高校卒だったりするのだが、そいつらをチェックしてダメ出しするのは大卒なり院卒なりの仕事になる。
四力を身につけたらいよいよ研究室に配属されることになるのだが、基本的に四力を応用した分野ならなんでも含まれるので本当に各研究室でやっていることがバラバラ。隣の研究室が何をやっているのかは全くわからない（もちろんこれは機械工学科だけではないとは思うが……）。そのため学科のイメージを統一することが難しく、どうしてもわかりやすいロボットなんかをアピールすることが多くなってしまう。とはいえそういう「わかりやすい」ことをやっている研究室は少数派で、実際は地味なシミュレーションや材料のサンプルをいじくりまわしているところが多数派である。最近は医療工学系の研究をしているところが増えたらしいが、光計測だったり材料物性だったり航空工学だったり、あるいは全然関係ないシステム工学だとか原子力工学の教員が居座っていることもあるようだ。こういう教員を食わすために機械工学第二学科（夜間向けの第二部ではない）が設立されたり、環境とかエネルギーとかが名前につく専攻が設立されたりすることがままある（昔は学科内に新しく講座を作るにはいろいろと制限があったらしい）。そういうところは（上位大学なら）ロンダ先として利用されるのが常で、そうした研究室を選んでしまった学部生はマスターの外部生の多さに面食らうことになる。
とはいえいろいろ選べるならまだマシな方で、大学によっては計測か材料かしか選べなかったり、工業高校ばりの金属加工実験を延々とやらされたりすることもある（ようだ）。やりたいことがあるならそれをやっている大学に行け、とは機械工学科志望の高校生のためにある言葉かもしれない。
そう、就職は非常にいいのだ。「学内推薦が余る」という噂を聞いたことがある人がいるかもしれないが、まぎれもない事実である（とはいえ最近は上位校の推薦でもガンガン落としまくる企業が増えたようで就職担当も頭を抱えているようだが）。機電系なる言葉が広まったのはネットが登場して以降らしいが、機電系＝機械工学系と電気電子工学系、というぜんぜん関係ない２つの学科をまとめてこう呼ぶのは、それだけこの国の製造業でこの２学科出身者が必要とされているということだろう。我らが機械工学科の後輩たちのために、これからも経済産業省には「モノづくり立国」なるわかったようでよくわからないスローガンを推進していただきたい。
inspierd by http://anond.hatelabo.jp/20110929232831
追記：あえて上位と下位の大学の事情をごっちゃにして書いているので、受験生諸君はあまり鵜呑みにせず自分でリサーチするようにお勧めする
プログラミングが異常に得意な非プログラマなんてたくさんいるよ。
ていうか理系の学問とか専門分野って、独学が基本なんだよね(プログラミングが「理系」かどうかはさておき)。
大学の授業は基本的に独学してることが前提で行われるし。
（それにしたって、過去問ちょろっとやっとけば余裕で受かるような資格のためにわざわざ学校行って授業受けるなんてむしろ効率悪いと思うけど）