 
|
はてなキーワード: デバッグとは
先日、TBSの番組「夢の扉＋」を見ていた。TBSの中で視ているのはこの番組だけだが。先日のテーマは「小さな町工場から日本の製造業を支える！」というもので、職人集団「チーム等々力」の免震テーブルの開発について綴られていた。
確かに、各職人の技術はすごい。ああいう職人技が日本を縁の下の力持ちとして支えているのも事実だと思う。例えば、新幹線の先頭ノーズはあれは職人手作業じゃなかっただろうか？
違和感を感じたのは、「職人が大学教授の求めているモノを理解出来ない」という点だった。結局番組では理系大学出身の技術者が、大学教授の要求（要件定義）を職人に分かるように図面に起こした事になっている。
それでいいんだっけ？ 図面になっている物は作れるが、図面を起こす事が出来ないということだろうか？
我々IT技術者は、顧客のまだ具体的になっていない要求をヒヤリングするところから始まり、要件定義をし、設計し、実装し、テストし、納入し、運用・保守をする。だから、顧客の専門用語や技術も分からなければならないし、情報技術も分かっていなければならないし、運用・保守コストも考えなければならない。それに情報技術は進歩が早いにもかかわらず、分野によっては製品寿命が20年とかいうのもあるから、新技術だけ知っていても話にならない。
「チーム等々力」の方々は、いい製品を作るかもしれないけれど、IT業界的に言えば、コーディングだけ、という事に。否、それでも範囲が広い。コーディングは一種の「設計」でもあるから、範囲はもっと狭い。
そういえば、ITで「制作・製造」ってどの部分を指すんでしょうね。もしかして、コンパイル・リンクしている時間だけかも。なにしろ、コーディングも設計の一部であるから。
自分は、顧客の要求をヒヤリングするところから、運用・保守まで全てに関わっている。ヒヤリングしている時点でどう実装すれば良いか、どう保守するか、保守のための実装はどうするか、を考えながら顧客と接している（ここでいう実装とは、ハードウェアも含む）。
かなりゼネコン化されているので、元請けが仕事を取ってきて、こちらに仕事を発注する事になる。その時点で、かなりの情報が欠落している。元請けの方は、顧客（この場合エンドユーザー）の専門が分からないまま受注している事が多い。その上、実装を分からずに発注してくるから、かなり困る。結局、元請けに対し、かなりの懸案事項が発生する事態となる。顧客に対してこの設計では足りないとか、設計に対し実装不可能とか。それをいちいち指摘しないとならないが、これが時間がかかる。
こういう案件がたくさん来ると、今度は実装出来る人間に限界が出てくる。なので、実装するのをさらに下層の外注ソフトハウスに出すの事になるのだが、今度はこれが、エンドユーザーの事が分からないため、なんだかよく分からないブツが上がってくる。その上、金の切れ目は縁の切れ目だから、運用保守に関しては全く考慮されていないブツ。もちろん、中には優秀な外注さんもいて、すばらしいコーディングのブツが出来上がってくる事もあるが、そういう人に出会える確率は万分の一程度か。
そこへ追い打ちをかけるように、コスト低減要求と短納期要求、仕様変更。人月の神話。
顧客の頭の中を覗く人、顧客の要求を情報技術者向けに翻訳する人、翻訳されたものを実装する人、実装されたモノをテストする人、テストし終えたモノを納入・設置する人、運用・保守する人、がそれぞれ分業・連携取れていないのが、現日本のIT産業の姿です。
最近は自社の社員も質が下がってきていて、Windowsしかいじれないとか、統合開発環境内でしかブツが作れないとか、コンピュータがどう動いているかイメージ出来ないとか、果ては、顧客の専門用語が分からない、というのもいる。ソフトハウスに至っては、作ったはいいが、作ったモノに対してデバッグ出来ないとか言い出す始末。
というわけで、就活生には、ITはお勧めしない。もし、プログラミングだけしていたいというのであれば、メーカーではなく、小さなソフトハウスに就職した方が良い。でなければ、顧客と対等（同等）の（製品）知識と、新旧情報技術に対応出来るだけの能力が必要とされるのである。
上っ面じゃなくてちゃんとわかっている人教えてください。
▼モバイル版「Flash Player」の開発中止をどう見る？
http://japan.cnet.com/panel/35010348/300015677/
▼Adobeはなぜ失敗したか, Flash-Playerの敗退は歴史の必然だった
http://jp.techcrunch.com/archives/20111109why-adobe-failed/
今後来るhtml5をもてはやす必要もなく、
で“既に代替されている”
html5厨の中にはこのあたりごっちゃにして歓迎してるやつが多数いる
くどいけど、その他の機能はjsとかcssとかhtml5周辺の独自仕様で
解決してることが多いからな！
普通にhtml5が覇権取るにはオーサリングツールがいるんだぞ。
全部含んでるんだ。
html5が現状見えてるのは、
までだ。
「描画系の機能でflash(flex sdk)同等の仕様を用意することになるだろう」
ってだけじゃ劣化flashすぎんだろ。
あとadobe終わったっていってるやつ、
それを一社じゃなくブラウザつくってる各社が実装するんだからな・・・
お前らがflash嫌ってるのと同じ問題が発生して、
flash殺すのはいいけど、html5を中心とした代替環境できんのに何年かかるんだよ。
あと、リッチインターフェース作るのに、いつまでもなんのサポートも受けれないような
jsライブラリ組み合わせて、必死にカスタマイズとデバッグしなきゃいけないのかよ！
業務系のuxデザインつくっていくのに、flex使おうか、html&css中心で行こうか悩んでんだ。
誰か何かアドバイスくれよ…
flexは良いところが多くて工数も減るし、どこかでadobeの5オーサリングツールに乗り換えられるだろうから
普通のweb屋としては、htmlとjsで苦戦しながらも自己責任でスクリプトチマチマいじってる方が、
他にもこの中途半端な状況に困ってる奴いるだろ！
２ｃｈでは私がぼろくそ言われた( スレのＵＲＬ探しに行ったら、２ｃｈ書き込み情報があり、性格はそれなりにそれなりらしい事がわかった )
http://hibari.2ch.net/test/read.cgi/tech/1317639700/365-
つるんでるは、その方が見る人が多くなるかと思って書いたので、一緒にブクマしてたりとか、リツイートされたりとか、はてなブックマークのお気に入られに、ドワンゴ社員でギークハウス在住の奴が入ってたりとか
まあ、こんなところか
365 ：デフォルトの名無しさん：2011/10/28(金) 15:54:08.91
まつもとゆきひろさんの連絡先知ってる人いませんか？
あなたは化け物を作った と言いたい
こんなに素晴らしい人権意識をお持ちのsora_hさんは、最年少ruby開発者だった。。。orz
光り輝く id:kabiy さんを応援してあげて id:kabiyさんは、新しいおもちゃが手に入って大変お喜びのようです。
そして、私を応援してくれる大変素晴らしい方です。 ギークハウス万歳 応援していただいたので、私も応援のお返しのエールを送りたいと思います。
光り輝くkabiyさんに、shine
366 ：デフォルトの名無しさん：2011/10/28(金) 16:00:01.19
これは人災じゃないんでしょうか？この人は地震の震災の時の何かの１００人ボランティアを使う開発に関わったそうですが
支援や協力をお願いしている部分は関知せず、こちらからしたら嫌がらせにも取れるようなツイートだけして、開き直ってきた
ネットだし事実確認が、ネットを見ただけでは判断できないから、躊躇する人というのもいるかもしれないし
関わりたくないと思う人もいるだろう。みんなそれぞれの事情や都合で生きているのだから
だからと言って、ないがしろにしたり、からかって良いわけはないと思う。
こんなかかわり方は無い
367 ：デフォルトの名無しさん：2011/10/28(金) 16:08:25.51
はてなブックマークというもので、わざわざ私のツイートに対し、「warota」と言っています。
ゲームのデバッグのバイトの例を出したから、ruby開発者の自分に何を言っているんだ という笑いだったのかと思いますが
技術の事ではなく、コミュニケーションの取り方というか、それ以前のような気がしますが、
そのような傲慢すぎる関わり方を言っていました。
こんな人 いくら技術力が能力があっても、人間として破綻してないですか？
こういうのは、匿名でしかものが言えない未来がないような人が、する事かと思ってました。
実名で前途有望なはずの人がする事でしょうか？
本当に２ｃｈねららしい目撃情報も
376 ：uy：2011/10/28(金) 18:00:01.89
可愛そうに ああ可愛そうに ひたすら可愛そうに
そいつは悪くないよｗ 中学生なんてそんなもんだし、何言うかわからないのが中二病、人それぞれ発病の仕方が違うだけ
むしろ中学生程度を天才だ！ っとかいって祭り上げた大人が悪い
そろそろ気づき始めるんだろ
「あれ？自分って天才って言われるほどすごくなくね？あいつのほうがすごくね･･･？うわあああああああああああああ！！！！！！！！！！！！！！！！！１」こうなる。
995 : uy : 2011/10/03(月) 18:35:47.45
初修正報告…ども…
俺みたいな中3でRuby開発に参加してる腐れ野郎、他に、いますかっていねーか、はは
Groovyかっこいい とか Haskell総合IDEほしい とか
かたや俺はRubyコミッター、メーリングリストでBUG報告を見て、呟くんすわ
it'a true Bug．再現率低い？それ、もう仕様でいいんじゃね。
なんつってる間に10時っすよ(笑) あ～あ、義務教育の辛いとこね、これ
377 ：デフォルトの名無しさん：2011/10/28(金) 19:47:25.39
uyにだけは言われたくないだろうな
でも、増田は技術系の人が多いから、rubyはrubyってかんじなのかな。日本人が作った軽いプログラム言語？ ってことくらいしかしらないけど、私だって名前を知ってるくらいに有名なものに、中学生で携わってるのに、名にこの人格の歪み・・・
今のうちなら治るかもしれないのに
あれ、見ても思ったけど、現実とネットの境目がわかってないんじゃないかな
ああいう人、あそこまでじゃなくても、見た事ある
なんとも言えないと思うのは、ヤンキー、不良のどうしようもなさじゃないんだけど、どこか本当にどうしようもない部分があるというか (表面的には似てないんだけどなんか同じ物を感じる)
役に立ちたくないという気持ちが人一倍いや人１００倍くらい強い人という印象を受ける人もいた
過去のまとめ
Google エンジニアの Steve Yegge 氏、Google+ への懸念を漏らす
http://japan.internet.com/busnews/20111013/8.html
で記事になってたけど、原文とちょっと要旨が変わっちゃってサービスへの警鐘みたいになってしまってたので、全文訳してみた。くそ長い。お暇な方どうぞ。
（2011/10/19 08:14）ありがたい誤訳の指摘をいただいたので3カ所修正。
Stevey の Google プラットフォームぶっちゃけ話
僕は6年半ばかり Amazon にいて、それから今はそれと同じくらい Google にいる。この二つの会社について強く感じることは（しかもその印象は日々強まるのだけれど）、 Amazon は全てにおいて間違っていて、 Google は全てにおいて正しいということだ。そう、やりすぎな一般化だけど、驚くほど正確だと思う。いやもうとにかくね。百、いや二百のポイントで二つの会社を比較することが出来るだろうけど、僕が正しく覚えていれば、 Google はそのうち三つを除いて優れている。実にある一点に関してはスプレッドシートを書いたんだけど、法務部が外に出すなって言うんだ。リクルーティングは惚れ込んだみたいだけどね。
つまり、まあ簡単に言えば、 Amazon の人事採用プロセスってのは基本的に欠陥品なんだ。だって、チームがチーム毎に、自分達のために人を採用するんだぜ。だから、色々平均化の努力はしてるみたいだけど、採用基準はチームによって信じられないくらいバラバラさ。そんでもって作業工程ってのも腐ってる。ソフトウェア信頼性工学なんてお呼びじゃないし、エンジニアに何でもやらせようとするんだ。コーディングする時間もないくらい。もちろんこれもチーム毎にバラバラで、要するに、運次第ってところ。施しやら困った人を助けるのやら、コミュニティに貢献するのやら、そんなのはもってのほか。ばかにしに行くんじゃなけりゃ、近寄るべきじゃないね。それにまた施設も染みだらけの壁に囲まれた箱みたいな家畜場で、装飾やらミーティングエリアなんてものには一銭も使ってない。給料やら福利厚生なんてのも最悪だ。まして最近じゃあ Google やら Facebook っていうライバルがいるのにね。社員特典なんてものも見たこと無かったな。採用通知の番号を照合して、ハイ終わり。コードベースも悲惨そのもの。エンジニアリング基準ってものがないんだから。チームによっては個別にがんばっていたくらいかな。
公平に言えば、彼らは良いバージョン管理ライブラリシステムを持っていた。これは僕らもまねるべきだし、僕らのところには同様のものが無い、良い pubsub システムもあった。でも多くの部分で彼らが使っていたのは、ステートマシンの情報を RDBMS に突っ込んだり読み出したりするだけのくそみたいなツールの塊だった。僕らならただでも欲しくないようなね。
僕が思うにその pubsub システムとライブラリ管理システムが、まさに Amazon が Google より優れている三つのうちの二つだ。
早期にリリースして、狂ったようにイテレートするってのも彼らのうまいところじゃないかって言うかも知れない。けど逆もまたしかり。彼らは早期にリリースすることを何にもまして優先する。品質保持やらエンジニアリング規則、その他長い目で見たら重要になってきそうなものはみんな後回し。そんなだからたとえ市場で競争相手よりアドバンテージがあったとしても、結局ちょっとしたことをやるのにも問題を起こしちゃうよね。
でも、一つ、そんな政治的な、思想的な、技術的なへまを補うだけの、彼らが本当に本当にうまくやってることがある。
Jeff Bezos は悪名高きマイクロマネージャーだ。彼は Amazon の小売りサイトの1ピクセルまで管理する。彼は以前 Larry Tesler を雇った。 Apple の主任科学者で、たぶん世界で最も有名で尊敬される HCI エキスパートさ。そんでもって、 Jeff は Larry が言ったことを、 Larry が辞めるまで3年間無視し続けた。 Larry は大規模なユーザビリティ研究もやっただろうし、少しの疑いの余地も無く誰もそのひどいサイトを理解できないってことをデモしたに違いない。けれど、 Jeff は1ピクセルたりとも動かさせはしなかった。トップページにぎっちりつまった内容の1ピクセルたりともね。それらはまるで何百万という彼の貴重な子供達なのさ。けれど Larry はそうじゃなかった。
マイクロマネジメントが Amazon が僕らよりうまくやっている三つ目ってわけじゃあない。つまり、まあ、彼らはうまくマイクロマネジメントをやっていたと思うけど、それを強みって言いたいわけじゃ無い。まずは何が起こっているかみんなに理解してもらうための文脈を準備しているだけさ。僕らはこれから、公衆の面前で、 Amazon で働きたけりゃ私に金を払えと言ってのける男について話すわけだからね。誰かが彼に反対したときは、彼は彼の名前入りの小さな黄色いポストイットを手渡して、誰が会社を動かしているかを常に忘れさせまいとする。思うに彼は全くの… Steve Jobs なのさ。ファッションとデザインセンス抜きのね。 Bezos はとんでもなく頭が切れる。誤解しないで欲しい。彼の前じゃ、普通のコントロールフリークなんてヤクが極まったヒッピーみたいなもんだよ。
それである日 Jeff Bezos が指令を出した。まあ彼がいつもやってることなんだけど。その度にみんなはピコピコハンマーで叩かれるありんこみたいに走り回るんだ。でもそのある一度、2002年かそのくらいのことだったと思うけれど、彼は指令を出した。とんでもなく巨大で、目の玉が飛び出るほど重たいやつを。普段の指令が頼んでも無いボーナスに思えるようなやつを。
彼の巨大な指令はこんな感じだった。
1)この時点より、全てのチームはサービスインターフェースを通じて全てのデータと機能を公開すること。
2)各チームは各々そのインターフェースを通じて通信しなければならない。
3)その他の全てのプロセス間通信は許可されない。ダイレクトリンク、他のチームのデータソースから直接データを読むこと、メモリ共有モデル、バックドア、全てを禁じる。ネットワーク越しのサービスインターフェースを経由した通信だけが許可される。
4)使用する技術は問わない。 HTTP 、 Corba 、 Pubsub 、 カスタムプロトコル、何でも良い。 Bezos は気にしない。
5)全てのサービスインターフェースは、例外なく、外部に公開可能なようにゼロから設計されなければならない。すなわち、チームは全世界のデベロッパに向けてインターフェースを公開することができるよう、設計し、計画しなければならない。例外は無い。
6)そうしない者は解雇される。
7)ありがとう！良い一日を！
ハハ！。ここにいる君たち150人ちょっとの元 Amazon 社員ならもちろんすぐにおわかりの通り、7番は僕が付け加えたジョーク。 Bezos は間違いなく君たちの一日なんかに興味ないからね。
それでも、6番は、本当だった。だからみんな一生懸命会社に行った。 Bezos は、さらに上級のチーフ熊ブルドッグであるところの Rick Dalzell に率いられた数人のチーフブルドッグを雇って、成果と進行を監視させた。 Rick は元レンジャーで、陸軍士官学校出身で、元ボクサーで、元 Wal（ごにょごにょ）Mart で拷問のような削減をやってのけた人物で、デカくて愛想の良い、「堅牢なインターフェース」という言葉を連呼する男だった。 Rick は歩き回り、「堅牢なインターフェース」について語り回り、そして言うまでも無く、みんなはいっぱいの進展をし、 Rick にそれを知らせた。
それからの数年間、 Amazon 内部はサービス指向アーキテクチャに姿を変えていった。その変化を形にしている間に、彼らは非常に多くのことを学んだ。 SOA に関する学問や論文は当時もいくつかあったけれど、 Amazon のとんでもない規模からすれば、そんなもの、インディ・ジョーンズに向かって「通りを渡るときは左右をよく見るんだよ」って言うくらいの意味しかない。 Amazon の開発スタッフはその途上でとにかくたくさんの発見をした。そのほんの一部をちょっぴり挙げると、こんな感じだった。
とまあこれらがほんの一例。他にもたくさんの、おそらく何百の、 Amazon が見つけた個別の発見や教訓があった。外部サービスにはおかしなところがいくつもあったけれど、君たちが考えるほどじゃあない。サービスに対して組織するってことは、外部のデベロッパを信用できないのと同じように、お互いを信用することなんてできないんだということを、チームに教えてくれたんだ。
↓
馴染むための登竜門って意味で言えば、VisualStudioなどのGUIでデバッグが出来る環境をもった言語が良いし、VB,C#などのサンプルが豊富で結果を確認しやすい言語が良いと思う。
グラフィカルに窓とかボタンとか出てきて、ボタンを押すなどのアクションに対してリアクションをコーディングできる、VBマジお勧め。
イベントドリブンの処理とか、タスク管理とか、環境に関する基本的なコーディングを一切書かずに、ロジック部分だけ書けるしね。
プログラミングは静的言語(C/C++,Java,C#など)と動的言語(rubyとかpythonとかperlとかいわゆるスクリプト言語)と関数型(lispとかF#とかhaskellとか)を一つずつくらい眺めた方がいいと思う。
どれか一個くらい自分に合ってるのが見つかるかも。
やりたいことにどの実装系が一番適しているかを考えるべきで、実装系を目的に合わせるべきじゃない。
そういう考えでいると、PHPで何でもやる奴とか出てきて迷惑なんだ。
そもそものロジック構築などは、ターゲットには依存しても、言語にはほとんど依存しない。
馴染むための登竜門って意味で言えば、VisualStudioなどのGUIでデバッグが出来る環境をもった言語が良いし、VB,C#などのサンプルが豊富で結果を確認しやすい言語が良いと思う。
Windows 7 64bit 版上で winpcap を使ったサービスプロセスを制作。
こちらのページを参考にさせてもらった。
「WinPcapを使用したパケットモニターの作成」CodeZine 古谷誠進さん
http://codezine.jp/article/detail/126?p=2
・アダプタ一覧（アダプタ名およびIPアドレス）を取得する
の箇所
処理は、while(d)ループの外でやらなくちゃいけない。
デバッグきつかったっす、サービスだとデバッグできないこともあって。
・俺のマシンが64bitだから、winpcap.dllやlibと合わない?
(PCAPSDKのLibにx64というサブフォルダがあって、こっちのものを指定しなきゃだめ?)
・WIDECHARとMULTIBYTE の扱いの問題?
と、いろいろ迂回してしまった。
解消したら、無事動き出した。
士業や人月単価で食ってる業種は、
販売原価が高いってことは、それだけ多くの他社の人を食べさせていることにもなるわけなんだがな。
ここに似たこと書かれているお。
http://anond.hatelabo.jp/20110922023854
世の中には、デバッグ作業してはいけない業界もあるんだなと思った事を思い出した。
例えば、法曹界とか
弁護士が必要な事があって、関わって思った。弁護士だけじゃなく調停委員や簡易裁判所やその他諸々を見て思った。
バグってバグってバグ有りまくりに見えて、それが業界外部にも少しは悟られだし、それで少し儲けようとしてるライターもチラホラいるような状況 (儲けが目的かどうかはわからないけど、本出て生活費稼げてる人もいる)
業界自体が立ち行かなくなるようなバグ、業界自体を破壊するような致命的なバグだけは、何とか対処しようとしてるものの、ちょっとだけ黒い腹が見えようが、先生具が見えかかってますYO、近頃の愚民はうるさい奴もいるから、早く見えないようにしまってください、という注意が行くだけのシステム
法曹界に限らず、他にもあるのだろう。
最近ブログも作って、指摘しようと思ったのも、それに近いのだが
この場合は、よく考えてみたら、バグで食って行こうとしてるようなものだから、これはさすがにやりすぎだろ！！と思ったからブログまで書こうと思ったのかもしれない。
技術系の職場だって、いろいろあるのかもしれない。自分は詳しく知らない。
なぜ、デスマという言葉があるか、なんで何次か請けまで行ってしまうのか
詳しくは全然知らない、外から見てるだけだけど、専門的な知識がある人と無い人で取引する場合、圧倒的に情報量に差ができるから、それを利用してごにょごにょというのは、どこの世界でもあるという事に通じてるのかなと思うので、技術系の世界も綺麗なだけとは行かない部分もあるんだろうなぁと思ったりした
弁護士でも医者でも、情報量が圧倒的に依頼者や患者と違う。 そこにお金が介在してしまうと、非常に不平等な取引が発生してしまう。 弁護士の場合、取引として考えると、一般の人からの依頼は経済合理性に欠く場合もある。 しかし、今はそれさえ経済的な理由から、拾いに着ているやつ(弁護士)がいる事から、余計ややこしく問題が起こりやすい状態になっていると思う。
２ｃｈでだから、違うかもしれないが、若手弁護士が月にせめて１０万収入があったらなぁ・・・と嘆いていた。ウソみたいな話だけど、その前の書き込みからも、精神的にもまいって神経科の薬を服用してるという書き込みもあり大変なんだなあと思った。それくらい困窮してる若手を作ったのは誰の責任だろう
自分の馬鹿息子のために医者並みに馬鹿も入れる仕組みにしたいというニーズと天下り先の確保というニーズが合致したのと、アメリカからの要望書でも圧力かけられこんな事になってしまっている
駄目なプログラマはとにかく人に親切でない。この程度のデバッグならと思えるようなこともしない。金銭的な面だけじゃなくて、「ずっと担当しているプログラムに対してこの程度の手間なのに」と驚くようなことすら断ったり。
これはおそらく、デバッグをして見つかる不具合修正の費用対効果を計算できず、自分のメンツを重視するからだと思う。とあるプログラマにお願いを断られたこと（だいたいプログラマ個人の作業として30分もかからないこと）で、私は落胆し、数万円くらいのバイトを紹介するのをやめたことがある。数万円は曲がりなりにも派遣でプログラミングをしているプログラマにしてはたいしたことがない数字かもしれないが、それでも30分くらいの手間で、数万円のバイトを紹介してもらえるなら、悪くない投資のはずだが。
駄目なプログラマはとにかく無駄遣いをする。プリミティブな定数で済むところでも、かまわずにオブジェクトを生成する。メモリ少ないのにいいのか、と私が思うようなことでも、無駄なものに考えなしにメモリを使う。
駄目なプログラマはメモリを使わない。無駄遣いはするが、メモリは使わない。
うまくいえないが、メモリを使う勘所を意識していないのではないか。キャッシュを作ってメモリ上に保持すべき所で毎回 DB にアクセスし、効率的なキャッシュで DB アクセスを減らして高速化を行う事に気が回らない。
いわゆる memchached もそうだが、実績のあるライブラリなどを利用するための準備には時間とお金を惜しむ。そのことでより開発が楽になることを知らないからだ。
駄目なプログラマは周りを大切にしない。エンバグばかりする代わりに、同僚のテストは手伝わないし、私のようなプログラマにバグのパッチを送ったりは決してしない。
これは、その行為を無駄遣いだと思ってるのかな、と思ってたのだけど、そこまで合理的ではない。ただ周りの好きな人間を大切にしなくてもかまわないという気持ちのようだ。
駄目なプログラマは勉強をしない。とにかく本を読まない。講演を聴かない。人から教えてもらわない。
勉強したことが無駄にならないことをわかっていないからかもしれない。
駄目なプログラマは書くより語る。末端で参加しただけのプロジェクトの自慢話をしたりはしょっちゅうだ。そして自分のプログラムを書こうとしない。
プログラムを書いて学ぶメリットより、自分の話をするメリットのほうがでかいと思っているわけだ。ペラペラ自分の話ばっかりする駄目なプログラマは多い。
駄目なプログラマは挑戦をしない。やったことない言語や、苦手なことをあえてやってみようとしない。たとえば、勉強会なんかにいかない人たちだが、たまたまいったら流行っている言語をやってみようなどということはない。普通の人が面倒になって見てるだけだったりするのに加わるだけで、積極的に挑戦をしようと思わないことが多い。
失敗するリスクの低さと、経験のリターンの大きさを知らないのだろう。
駄目なプログラマは短期的にポジティブ、長期的にネガティブである。よく駄目なプログラマはネガティブな人が多いと言われるが、実際には、そうでもない。短期的には楽観的だったり不安に思わなかったりすることが多い。避けられるバグをなるべく避けようとする気持ちが少ない。
一方で、将来的に自分がどうなるか、などに関しては驚くほどネガティブである。長期的に悲観になっても無駄だということを知らない。逆に、短期的に「まあいいか」と楽観的になると、のちのちバグが発覚するのを知らないので、目の前のことに対しては真剣に考えない。
私が知っていることをまとめてみたが、実際にまとめてみると驚くほどシンプルである。だがこれを全部できてる人はなかなかいない。
駄目なプログラマになりたいと思っている人は、マネしてみるといいことがあるかもしれない。
※「貧乏人に大量に触れて初めて気づいた8の共通点」http://anond.hatelabo.jp/20110825204218 のプログラマ版です。
http://anond.hatelabo.jp/20110816010530
全てのブラック企業にあてはまるわけじゃないけど、以前劣悪な会社に勤めてた経験からすぐ思うことを書いてみる。
ものすごい端的にいえば、人件費は同じで人を減らさないといけないんだから、仕事できないやつにはやめてもらわないといけない。すべてのブラックがそうだとは言わないけど、そういうのがいなくなるだけで随分よくなるはず。いなくならないからよくならないんだけどね。
あるデータのチェックをするのにフォーマットもうまく統一されてない手書きのものをバイト3人で読み上げて人力で数日かけてチェックしてる。そのあとキーパンチャーに外注して入力。そのあとスクリプトでチェック。読み上げチェックに一番時間かかってるので、こう言う風にしたらチェックも要らないしスクリプトももっとよくできると言ったら｢～さんの仕事がなくなる。それにスクリプトはなんとなく信用できない｣自分の扱えない技術は信用できないんだもんな。クソい。
ある設計でバイトの子が寸法をあわせるのに苦心してる。｢○○CADを使えば一発で自動であわせられるし、Tさんに計算の方法を教えてもらってもいいのでは｣｢Tさんの仕事がなくなるといって教えてくれない。○○CAD使えば数分でできるのを手調整で一日かけてやらされてる。どうにかして・・・｣
効率化するマクロを作ったら、うちだけズルするわけにはいかない、使えない人がいるから不公平だなどといって使わせてもらえない。
新しいやり方やツールを導入しても、教えるのにコストがかかる等といった理由で一部の社員だけだったりして、結局それにあわせて仕事を効率化できない。常にレガシーな残骸を考慮しなければいけないので、いつまでたっても大幅な効率アップができない。
社内サーバーにバグトラッキングシステムを入れて、今まで個々のPCでエクセルにまとめてやりとりしていたデバッグ情報をバグトラッキングシステムに一括してもらうことになった。がしかし、使い方がわからないなどで相変わらずローカルでエクセルに纏める人がいてかまわずエクセルのデータでなんでもかんでもやりとりするのでバグトラッキングシステムのDBからエクセルのデータを作成しなおしている。意味ねえｗｗｗ
上二つともかぶるけど、できる人がベストのやり方やれたとしても、それを許さないブラックがあるんですよ。あんただけずるするわけにはいかないよって見るわけです。バカバカしい、まじバカバカしい！
導入したら大幅に効率うｐするのわかってるのに、なにかと理由つけて古いものを使いつづけるんだよな。大して金のかからないものでも。金のかけるところおかしいんだよ。
でもそれを許さない雰囲気がブラックにはある。仕事を減らす仕事で困る人がいるからな。それがどうにかならないかぎり、ブラックでひいひいいってる人の食い扶持が薄くなるのは避けられない。
仕事が多いのが苦労してる証拠、仕事してる証拠っていう宗教があるからタチが悪い。仕事を減らす仕事、すっげーあたりまえのことなのに、それができない。
http://anond.hatelabo.jp/20110713154506
先ほどの事象はWindows7上のVB.NETデバッグで発生。
これを「管理者として実行」により起動させたところ、懸案部分は例外発生せずにうまく通過。
該当箇所は「イベントソース登録がなかったらソースを登録する」という処理で
その後の(一般ユーザ？で動かす)デバッグでSouceExists()の例外は出なくなり、うまく通過するようになりました。
System.Diagnostics.EventLog.SouceExists()の戻り値
・WindowsXP, 2003
True か False
・WindowsVista以降, 2008以降
True か False か SecurityException
どうも俺の仕事は質が高すぎるらしい。結果自分にも相手にも良くないと思われる。
結論、相手の規模や能力に合わせて適当に質を下げた結果を返すようにした。独立して仕事来るのかやる前は不安だったが、逆の悩みを抱えることになるとは。
「素性の良い言語」に求められる性質は色々あるけど、一つは、モジュール同士を疎結合に保つための機能が備わっていることが挙げられる。つまり、「理解していない人」がエンバグしても、その影響範囲を最小限に留められるということ。これが、機能追加やデバッグ時にどれだけありがたい性質であるかは、多くのプログラマに同意してもらえると思う。
大規模なコードになるほど、一人の開発者から見てブラックボックスになる部分が増えるのは避けられないこ。Javaの言語機能を適切に使えば、手に負えないバグを埋め込むことを回避しやすくなる。
1. あえて2～3世代前のインタプリタを使う
あえて2～3世代前のインタプリタを使うようにしましょう。そして飲み会の場で好みの男がいたら話しかけ、わざとらしくパソコンを出していじってみましょう。そして「あ～ん！ このインタプリタ本当にマジでチョームカつくんですけどぉぉお～！」と言って、男に「どうしたの？」と言わせましょう。言わせたらもう大成功。「LiLFeSとか詳しくなくてぇ～！ ずっとコレ使ってるんですけどぉ～！ すぐセグフォるんですぅ～！ ぷんぷくり～ん（怒）」と言いましょう。だいたいの男は新しいインタプリタを持ちたがる習性があるので、古かったとしても1世代前のインタプリタを使っているはずです。
そこで男が「新しいインタプリタにしないの？」と言ってくるはず（言ってこない空気が読めない男はその時点でガン無視OK）。そう言われたらあなたは「なんかなんかぁ～！ 最近LiLFeS1.4.0が人気なんでしょー!? あれってどうなんですかぁ？ 新しいの欲しいんですけどわかんなぁぁああい!! 私かわいそーなコ★」と返します。すると男は「LiLFeS1.3.9でしょ？ 1.4.0はまだ出てないよ。本当に良くわからないみたいだね。どんなコード書いたの？」という話になって、次の休みの日にふたりでLiLFeS課題デートができるというわけです。あなたの女子力が高ければ、男がデバッグしてくれるかも!?
「大きい！」とか「小さい！」などを表現する「＞＜」をコードに入れると、Javaの男性ユーザーは「なんかこの子カワイイなぁ」や「Basicっぽいよね」「＜＞が正しいよね」、「ってか!=だよね」と思ってくれます。インターネット上では現実世界よりもイメージが増幅されて相手に伝わるので 「＞＜」 を多用することによって、男性はあなたを可憐で女の子らしいと勘違いしてくれるのです。そういうコードを書くと絶対にコンパイルエラーになりますが気にしないようにしましょう。
3. とりあえず男には「えー！ なにそれ!? 知りたい知りたーい♪」と言っておく
飲み会などで男が女性に話すことといえばEmacsやvimの話ばかり。よって、女性にとってどうでもいい話ばかりです。でもそこで適当に「へぇーそうなんですかぁ～？」とか「よくわかんないですけどすごいんですねぇ」と返してしまうと、さすがの男も「この女本当に情報屋か？」と気がついてしまいます。ダメ女だとバレたら終わりです。そこは無意味にテンションをあげて、「えー！ なにそれ!? 知りたい知りたーい♪」と言っておくのが正解。たとえ興味がない話題でも、テンションと積極性でその場を乗り切りましょう。積極的に話を聞いてくれる女性に男は弱いのです。
いろいろと話を聞いたあと、「〇〇は〇〇で、〇〇が〇〇なんですね！ 覚えたぞぉ！ メモメモ！」とコメントすればパーフェクト。続けて頭に指をさしてくるくる回しつつ「キュンキュンキュン！ キュンキュンキュン！」と言って、「どうしたの？」と男に言わせるのもアリ。そこで「私のハードディスクに記録しているのでありますっ☆」と言えば女子力アップ！ そこでまた男は「この子おもしろくてカワイイかも!?」と思ってくれます。私は学歴も知識もありませんしブスですが、こういうテクニックを使えば知識がない私のようなバカ女のほうがモテたりするのです。男は優越感に浸りたいですからね。
4. aptitudeではプロプラをインストール出来ない女をアピールせよ
男とパソコンを起動したら、真っ先にFlashなどのプロプラなソフトを探して「あーん！ 私これインストールできないんですよねぇ～（悲）」と言いましょう。するとほぼ100パーセント「どうして？ 嫌いなの？」と聞かれるので、「嫌いじゃないしインストールしたいんですけどできないんですっ＞＜」と返答しましょう。ここでまた100パーセント「嫌いじゃないのにどうしてインストールできないの？」と聞かれるので、うつむいて3～5秒ほど間をおいてからボソッとこう言います。「……だって、……だって、プロプラって中で何するか分からないじゃないですかぁっ！ 個人情報かわいそうですぅ！ まだ流出してないのにぃぃ～（悲）。図書券すらもらえないんですよ……」と身を震わせて言うのです。
その瞬間、あなたの情報科学系女子力がアップします。きっと男は「なんて分かっているコなんだろう！ 絶対にゲットしてやるぞ！ コイツは俺の女だ！」と心のなかで誓い、あなたに惚れ込むはずです。意中の男と付き合うことになったら、そんなことは忘れて好きなだけインストールして大丈夫です。「インストールできないんじゃなかったっけ？」と言われたら「大丈夫になった」とか「慣れた」、「GPLウザい」と言っておけばOKです。
http://anond.hatelabo.jp/20110308212302
元エントリーは｢よくない｣ばっかりで、｢悩んでる人はそんなこととっくにしってるよ！それができないから悩んでるんじゃないかお！｣だと思うので、できるだけ｢それをどうすればつまらなくならないのか｣を具体的に書いてみる。
この考え方は、誰にでも合うわけじゃないと思う。エニアグラムで言えば、5（研究者）のタイプに向いてる考え方で、5の得意なことを生かしながら、7（楽天家）の要素を取り入れていい感じにしようって事かも。エニアグラムはツリー読んでてさっき知ったばっかりだけど、自分で診断したら 5と7が突出してるタイプだったので参考までに。追記: 指摘を頂きました。エニアグラムでは5に7が合わさると良くないらしいです。書き終わってからエニアグラムというものがツリーにあるのを気づいて診断したので、以下の内容にエニアグラムは一切関係ありません。内容が心理学的に崩壊してるのかは俺には判断できません。安易に心理学の用語を使ったことをお詫びします。あくまで俺の経験に基づくやり方であって、心理学等の体系的な学問に基づくものではないということを念頭において読んで下さい。
元ネタに合わせてタイトルつけたけどいまいちだった。あなたの人生はつまらないって言い方、それこそだるい。考えてるときも、やってしまってからそれを見直してるときも、つまらないなんて感じた事は無いし。本心としては｢沢山考えて生きる人の考え方｣にしたい。
これはあらゆることを、自分の経験や知識にしようとすることなんだ。
一つの事実に対して、様々な角度から思考実験をし、客観性の高い見方や自分自身にあった見方に繋がる可能性が深い思考にはある。ステレオタイプな見方や決めつけにはまらず、リテラシーや認識力を育てるために深い思考は役立つ。
一つの見方に固執して深く掘り下げるのではなく、一つの事実に対して様々な角度から掘り下げるられるようになればいい。そうすれば、一見関係ない事実の裏にも他の経験とリンクする部分があることに気づき、経験や知識の応用が利くようになる。物事の共通点を見出せるのは大きな武器になる。これは、物事の表面だけ見て思考停止しているのでは得られないことだ。
大体、深読み思考という呼び名が｢だからネガティブッ｣って感じで命名がよくないと思う。思考してる=ネガティブ=よくない、なんて短絡だ。深読み思考の良い呼び名を考えたかったんだけどスーパー認識タイムとか変なのしか思いつかない。
極度の反省で悪循環に陥らないために必要なのは、｢自分が良いのか悪いのか｣に拘らない事。｢自分がそのとき良いと思ってやったこと｣についてあとから｢良いと思ったこと自体｣に対して反省してもたいして得るものはないよ。それどころか周りから見ると、被害妄想や自己中やかまってちゃんに見られてしまうから注意だ。(追記: 反省とお詫びをしっかりわけてやろう)
例えばバグのあるプログラムを作ってしまったとしよう。バグを作ってしまったことを悪い悪いと反省していても何の解決にもならないし、経験にもならないよね。まずはデバッグしないといけないし、そこからバグの出にくいプログラミングを学ばなければならない。
反省が生きるのは、｢自分が何をしたか｣｢それによってどんな影響がまわりにあったか｣｢そしてどういう結果になったか｣を自分だけの視点でなく、様々な角度から再体験したときだ。それは経験のデバッグとも言える行為だ。デバッグを繰り返すことで、バグの出にくいプログラミングが身についていく。
反省は、過去の過ちを許してもらう為にするんじゃない。成長する余地があるからすることなんだ。沢山反省してしまうのは、沢山成長したいことの裏返しなんだよ。だから、これからの為に反省すればいい。
実際よくあることだけど、
これ真に受けてたら、思考×反省タイプの人は前に進めない。だからネガティブだと言われても真に受けるな。
反省してると｢あんたってほんとネガティブだよね！｣→反省は経験を無駄にしないために、次にいくために、成長するために必要なこと。上でも書いた通り、｢自分が悪い悪い｣の反省にはたいした意味はないけど、ちゃんと経験を検証する反省なら次に繋がる。先の為に反省してんだよ。過去を無駄にしないために反省してんだよ。これのどこがネガティブだっていうんだ。
諦めて見直してやり直そうとしてると、｢あんたってほんとネガティブだよね！なんですぐ諦めるの！｣→先に行くために諦め=決断と効率の良い見直し=反省は必要なんだよ。途中で諦めてもちゃんと見直し=反省して次に生かすつもりなんだから、ネガティブじゃないよ。むしろ、失敗を認めず、まずいまずい無理だーと思いつつやり直せないでぐだぐだに成長せず続ける方がネガティブかもしれない。まあそれを世間では頑張りなんて言うので、そこはうまく結果出して認めさせるしかない。
先の反省と繋がるんだけど、反省を前向きにできるようになるとリスキーな選択でも決断できるようになるから、同時に優柔不断さは収まっていくのだと思う。
優柔不断を改善するのに必要なのは、生きてる時間は有限なんだって考えること。すっごい単純だけど、人があれこれ考えて途中で思考を打ち切る時って、殆どが｢考える時間と見合わせて結果でペイできないから｣なんだよ。生きてる時間も考える精神力も有限だし、真の答えではなく、近似的な答えでどっかで計算を打ち切らないといけないなんてことはしょっちゅうある。
｢考える時間と見合わせて結果でペイできないから｣をもうちょっと説明してみる。
ずっと考えてる→いつまでたっても実行できない→実行されないから反省の機会がない→反省(デバッグ)の経験値があがらない→経験値があがらないから思考精度があがらない→思考精度があがらないからずっと考えてる→ループ
時間が勿体無いから思考を途中で切り上げてとりあえずやってみる→実行→反省(デバッグ)の経験値があがる→経験値があがるから思考精度があがる→思考精度があがるから、少ない時間で思考を切り上げて実行に移せるようになる→ループ
投げやりですまないけど、時間は有限だからとりあえずやってみるというのがとにかく必要だってことだよ。
成功体験。成功の味を知ること。逆からいうと負け癖をつけないってことなんだけど、そういう言い方すると反省するのがいけないとか失敗がいけないって思う人いるからそう考えないで。とにかく、成功の味を一度は知らないと、人はそのためにリスキーな選択や冒険をしようとはなかなか思えないんだ。
自分で、成功の味を味わうのが難しかったら、だれかからおすそ分けしてもらうのでもいい。成功する人の応援をする、手伝うとかで、少しずつでも成功するということがどんなに気持ちいいことなのか味わえばいい。
だいたいこんな感じだと思うんだけど、
4つの思考のうち、先の二つを磨くことで、あとの二つを変化できるってことになったよ。ってことは、もともと二つが軸なのかもしれないね。
そしてそれは"直す"ようなものでもなく、生かせるように磨いていけばいいんじゃないかな。
（ちょっと上級者向け: もっと言えば、深読み思考は事実の認識、反省は経験の認識でどちらも認識をどうするかという一つの問題になるんだ。そして、そのどちらも｢一つの事実に対して様々な角度から掘り下げる｣という所を磨けばいい。深読み思考の所に書いたことも、反省の所に書いたことも、結局同じ事な気がするよ）
http://www.4gamer.net/games/006/G000612/20070906049/
こんな有様で世界最大の参加者数を誇るWOWをライバルだとのたまう某ゲームメーカーが、この国にはあるのです。
ほんと「クオリティなんか二の次」な会社に落ちぶれたよなあスクエニは。そんなにゲーム作るのが嫌なら洋ゲーメーカーの国内代理店にでも鞍替えしちまえばいいのに。