「第一回真の闇プログラマ認定プログラミングコンテスト」開催 52
ストーリー by soara
あるAnonymous Coward 曰く、
12月25日から来年2月1日にかけて、「第一回真の闇プログラマ認定プログラミングコンテスト」なるものが開催されるらしい(ATNDでの告知、コンテストページ)。
概要は下記のとおり。
近年、C++闇の軍団というC++0x原理主義者が地下活動から私のテリトリーであるグラフ理論のUStream配信を行っているという情報を得た。
(中略)
よって、どっかの中二病者がのたまっている闇プログラマーではなく、C++闇の軍団に抵抗しうる真の闇プログラマを養成し、ゆくゆくはC++闇の軍団の対抗勢力となりうる真の闇プログラマの部隊を創設する予定である。
その部隊の志願者や適合者を選別するのが今回のプログラミングコンテストの真意である。奮って参加をして欲しい。
なお、優秀な成績を収めたものには豪華景品が提供されるとのこと。 希望される豪華景品の投票、支援のための寄付も受付中だそうだ。
名前が表に出てくるような奴らを、闇プログラマと呼んでよいのか？ (スコア:3, すばらしい洞察)
fj.jokes出身:
Re:名前が表に出てくるような奴らを、闇プログラマと呼んでよいのか？ (スコア:3, おもしろおかしい)
http://srad.jp/it/comments.pl?sid=507244&cid=1826363 [srad.jp]
光あるところに影がある
まこと栄光の影に数知れぬプログラマの姿があった
命をかけて歴史をつくった影の男たち
だが人よ 名を問うなかれ
闇にうまれ 闇に消える
それがプログラマのさだめなのだ
プログラマＡ、お前（のクビ）を斬る！
＃プロマネ忍法、雲隠れ！
Re:名前が表に出てくるような奴らを、闇プログラマと呼んでよいのか？ (スコア:3, おもしろおかしい)
一人月で受けた案件が二人月に
三人四人に五人十人
忍法デスマーチ
Re: (スコア:0)
>忍法デスマーチ
それじゃサスケじゃなくて「オタスケ」じゃねぇか！
Re:名前が表に出てくるような奴らを、闇プログラマと呼んでよいのか？ (スコア:1, おもしろおかしい)
海の彼方からやってくる 序盤にだけ現れる
会議室から声がする 仕様変更の声が
熱く熱くプロジェクト燃やす あれはコン猿タント
Re: (スコア:0)
むしろオタスケどころか邪魔になってるケースも･･･
Re: (スコア:0)
＃ 空目しちゃったよ orz
Re: (スコア:0)
Re:名前が表に出てくるような奴らを、闇プログラマと呼んでよいのか？ (スコア:3, おもしろおかしい)
Re: (スコア:0)
その昔、派遣先から派遣されるのを繰り返して、気がつくと元の会社に派遣されていたというネタがあったな。
Re:名前が表に出てくるような奴らを、闇プログラマと呼んでよいのか？ (スコア:2, すばらしい洞察)
闇に隠れて生きているはずの妖怪人間でさえ、毎週テレビに出てきたり、
悪の秘密結社の詳細が、児童向け図書に掲載されていたりするぐらいですから、
名前バレ、身バレぐらいはいいんじゃないでしょうか。
Re:名前が表に出てくるような奴らを、闇プログラマと呼んでよいのか？ (スコア:1)
出る名前は芸名じゃね？
会場が「冥王星」なんだけど・・・・ (スコア:2)
概要などに書いている内容は半分は本当であり、半分はネタである (スコア:2, 興味深い)
DxLib Fan Wiki(只今、プログラミングコンテスト開催中) - 第一回真の闇プログラマ認定プログラミングコンテストのお約束 [flnet.org]
マジなのか
モデレータは基本役立たずなの気にしてないよ
Re:会場が「冥王星」なんだけど・・・・ (スコア:1)
Re: (スコア:0)
景品も「おっぱい」だしなぁ。
てか、C++(あるいはC++0x)を使って実装したらどうなるの？
あと、WikipediaのBase64 [wikipedia.org]を見て思ったんだが、"/"と"="を使わないbase64をさっさと標準化して欲しいな。
景品 (スコア:0)
闇ちゃんの？
「えっちぃのはキライです」と怒られるのもまたよし。
# 矢吹先生に敬意を表しつつAC
Re: (スコア:0)
Re: (スコア:0)
「ボイジャーか何かにrlogin して参加しろ」ってことじゃないの？
＃ばとるぷろぐらまーの世界だ。
重要条件 (スコア:2, すばらしい洞察)
エディタはviのみ
その他は認められない
Re:重要条件 (スコア:1)
え～エディタと言えばcatでしょう.
もしや、あいつが闇プログラマだったのか？ (スコア:1)
エディタはviのみ
その他は認められない
マジヤメｔ
頑としてIDEに移らず：
・「面倒だ」とユニットテストも殆ど書いてくれず、たまに書いても実行しないままコミット＆リリースする。
・リファクタリングもできないので、やたら抽象度を上げて過剰な柔軟性を作りこむ。
…という頑固一徹なvi使いが残したスーパー・バギーなプログラム30万行
（ドキュメントは独自用語満載で仕様もよくわからない）を
来年からリライトする羽目になりそうなんだからッ！
…もちろんviは単なるテキスト・エディタであって、それ自身が悪いわけじゃなく、
適したツールと今時のテクノロジをちゃんと利用しないそいつが悪いってのはわかる。
けどまぁ、単なるエディタでしかないviだと…。
ユニット・テスト書く手間と本体コードを書く手間が正味ダブって面倒な上に、
エディタと別にコマンド打って一々テスト実行しないといけないわけで
テスト駆動開発なんかやってられないくらい面倒だ。
リファクタリングできないので
後からクラスの構造や継承関係を変更するのが面倒だからつい作りこみすぎる。
だから近頃、単なるエディタでは面倒でツライってのもまたわかってること。
だからこそIDEの利用を何度も理由を言ってオススメしてたんだが、
ついに異動の日までヤツはvi＆コマンドラインな環境で書き続けてたな。
＃プロジェクト・マネージャもどきだったが、
＃所詮もどきで実際には単に同僚でしかないから「命令」はできなかった。
Re:もしや、あいつが闇プログラマだったのか？ (スコア:1)
IDE をまともに使ったことが無いのでぜひ教えて下さい。
> ユニット・テスト書く手間と本体コードを書く手間が正味ダブって面倒な上に、
IDE 使うとユニットテストと本体コードを書く手間がダブらないの？
> エディタと別にコマンド打って一々テスト実行しないといけないわけで
コードを書いたり、変更したりする度に IDE が自動でコードをテストして結果を評価してくれるのかな？
> リファクタリングできないので後からクラスの構造や継承関係を変更するのが面倒だからつい作りこみすぎる。
IDE を使わないとリファクタリングできない、っていうが良くわからないんだけど、IDE が勝手にコード最適化をしてくれる、ってこと？
ううむ、そんなに便利なら IDE 勉強してみようかな。
# 職業プログラマじゃないけど C++ のコードを読まなくちゃならんのよ～
IDE (スコア:1)
まず最初にIDEは銀の弾丸ではもちろんないのでなんでも自動でやってくれるわけではないです。
各種の細々とした手間を削減して、実際にはちゃんと計測しないとわからないけれど、
体感0.7倍くらいにはしてくれる感じ。
コンテストの切り替えが減って作業の流れがスムーズになると思考の中断が減ります。
* テストを書く手間とIDE
テストをちょっとしたユースケース代わりに書いておいて
コンプリーション（補完）を使うと型宣言、定型コメント、import文等の決まり文句/おまじない部分を書く手間ガッツリ減ります。
メソッドの中身を書く必要はあるから完全に半分とは言わないけれど、
大したことない内容のメソッドって結構数あるので意外と効果は大きいです。
極端な例だけどgetter/setterの類や等値演算のメソッドなら多くの場合本体より型宣言とかの決まり文句部分の方が多いわけだし。
* テストの実行とIDE
保存した時の自動ビルド＆テストはやって欲しくない時もあるから、私はそういう設定は外すけど、
テスト実行のボタン一発でビルドはしてくれますね。
別の端末開けておいて、あるいは一旦終了・中断して別途makeとかする必要はありませんし、
IDEがある程度ファイルをロックするのでうっかり参照中のファイルを書き換えるミスも減ります。
ユニットテスト・フレームワークとIDEが連携しているとテスト結果とテストのメソッドはワンクリックで移動できるし、
そのままデバッガでテストをデバッグできる。
＃あと意外とユニットテストの進捗バーは癖になるｗ
* リファクタリングとIDE
リファクタリングは手作業や汎用の置換とかでやるとミスもあるので
リファクタリングのありがたみががっつり減る。
IDEから独立したツールもあるかもしれないけど
改名やメソッドや変数の括りだしとかコード書いてる途中で思い立つことが多いわけで
エディタと一体化しててくれた方が思考は途切れない。
＃IDE…あとは翻訳と辞書を統合してくれると英語の識別子を考えたり英文コメント書いたりするのにいいのだがｗ
＃最近TeXもIDE上で書いてたりするから英語論文書くにもよさそうだ…。
Re:IDE (スコア:2, 興味深い)
＞コンプリーション（補完）を使うと型宣言、定型コメント、import文等の決まり文句/おまじない部分を書く手間ガッツリ減ります。
逆に言うと、テストを作る手間のうち、一番簡単なひな形を各部分が
チョット減るだけです。
＞リファクタリングは手作業や汎用の置換とかでやるとミスもあるので
＞リファクタリングのありがたみががっつり減る。
要するにJava用のEclipseやNetBeansあたりに限定の話でしょ？
Javaは静的な型付けが強力だから、初歩的なリファクタリングが
自動的にできるだけ。IDE一般の話ではない。
変数名がi,i1,tp,tp1,tp2,ni,ntpみたいな意味不明な時に、変数名を
変更しながら読む時は、この機能はむっちゃ便利。
しかしその問題はviでもIDEを使わないからでも言語の種類でもなく、
プログラマーのスキルが低いだけです。
＞＞# 職業プログラマじゃないけど C++ のコードを読まなくちゃならんのよ～
C++とかその他大半の言語では、言語仕様的にそんなことはできません。
Javaしか知らない人だと、その辺を知らないんですよね～。
Re:IDE (スコア:1)
そのちょっとの手間を惜しんで必要なことをしなかったり、
ちょっとしたスキルの差でマズい設計をするのが問題なので
そういうことがちょっと減ったことでやってくれるようになるなら万々歳ｗ
モラルもスキルも満点の開発者を数揃えられるようなら最初から何の問題もないわけで、現実はそうはいかない。
そこらが多少欠けていてもツールが支援してくれて多少なりとも埋められるなら喜んで採用するね。
＃ウチの場合だと研究所だから応用分野の知識と数学の基礎知識くらいは期待できても、
＃プログラミングとソフトウェア開発の知識・スキルは多くを期待できない
まぁプログラマに技能と十分な能力があればなんでもOK的な極論が通るなら
アセンブリ言語（可搬性ならVM）で書けばいいわけでIDEどころかプログラミング言語だっていらないって話にｗ
ひな形 (スコア:1)
昔は私も「ひな形」バカにしてたけど中々どうして結構違う。
補助的な小さなメソッド/関数を沢山書くスタイルだとコードのロジックに対して
決まり文句（コメントや型宣言やインポート）の量も馬鹿にならない。
元コメでは決まり文句の方が長くなることが多い例としてsetter/getterや等値演算を上げたけども。
決まり文句の冗長性は検証や人間が読むときに役立つので、書かない言語がいいとばかりは言えないし。
静的な型付け (スコア:1)
そもそも静的な型付けがない言語であんまり大きなものを書く気にはならないなぁ。
＃型推論にしたって陽に書く量が少ないだけで静的に型付けはするしなぁ…。
ライブラリ設計するときに値の集合とその上での演算、他の型との対応関係考えるからどうせ型の構造は考えるわけだし、
読むときにもそう考えながら読みたいし…。
もちろん動的に決定される部分があってもいいけど、静的にある程度は限定されててくれないと却って面倒…。
Re:静的な型付け (スコア:1)
ちなみにクダンの彼は動的型付けと動的ロードとデータを文字列にコードするのが大好きで
静的に型が決定できるところ、データ型を作った方がよいところで過剰にその技法が取り入れられており、
彼のコードの読みにくさはそこに起因する分もある。
彼が元々はライトウェイト系というかスクリプト系の言語（Rubyだった）で
文字列の置換処理でC言語のフロントエンド・プロセッサを書くところから仕事を始めたことを考えれば
この性向もわからなくはない所はある。
＃私も17年くらい前にFORTRANのソースを処理をして
＃C++から呼び出すためのヘッダファイルを生成するプログラムを
＃sedとシェルスクリプトでお手軽に書いた経験はあるわけで…。
ただまぁ開発対象が置換で片がつくプリプロセッサ的なものから本格的なコンパイラの最適化モジュールへと変化し、
規模も大きくなったところで諦めて移行してくれればよかったのだが、
そういう考え方の変更が必要になった経験が恐らくそれまでの彼のキャリアにはなかったのだろうと思う。
＃こっちはこっちでもう少し彼がプログラミングとソフトウェアについて「わかってる」ものだと思っていたしね。
＃そのあたりは、そのチームに来たのは私の方が3年も後だったってのもあるし、彼が基本的に自信たっぷりキャラだったってのもある。
Re: (スコア:0)
素のviはともかくvimならコーディングのサポートは結構やってくれるし。
#「ユニットテストを書くけど実行しない、さらにそれをコミット」なんてのはネタと信じたい。
Re: (スコア:0)
Re:もしや、あいつが闇プログラマだったのか？ (スコア:1)
＞IDE を使わないとリファクタリングできない、っていうが良くわからないんだけど、IDE が勝手にコード最適化をしてくれる、ってこと？
JavaとEclipseの話限定で考えて欲しいけど、たとえば
「 i,t,p,aみたいな一文字の変数名がメソッド内で大量に使われていて、読みにくいし
検索もしにくいので、意味のある xxxStartTime などに変更したい。」
みたいな場合は、Eclipseが一発変換してくれます。(もちろん変数名は自分で入力ですよ。)
たまたま"t"という文字／文字列が他で使われてなければエディタ等の置換でもできますが、
そうでない場合はほとんど手作業ですし、間違いの発生する確率も高くなります。
＞# 職業プログラマじゃないけど C++ のコードを読まなくちゃならんのよ～
ですがこれはCやC++では、まず不可能です。
ポインタとか(void *)への型キャストが入ると、自動解析なんて無理でしょ。
＞コードを書いたり、変更したりする度に IDE が自動でコードをテストして結果を評価してくれるのかな？
変更／セーブする度にテストを実行されると、さすがにウザイような。。。
Eclipseあたりだと書き換え途中でもコンパイルエラーを出してくれるけど、
これでさえも鬱陶しいと感じることはあります。
＃IMEでも「。」や「、」を打つたびに自動変換してくれる機能があったりするけど、
＃自分の思ったとおりのタイミングで変換できないのでかえって不便。ある意味でそんな感じ。
普通は一定間隔で手動実行でしょうね。だったらコマンドで実行しても大差ない。
そもそもjunitもcppunitも、本来はコマンドラインから使うツールでしょ？
Re: (スコア:0)
二極分化 (スコア:2, 興味深い)
不景気って大概人材配分の不均衡を伴うので
エラい忙しい人と失業に二極分化した状態になっていると思っています。
過労と失業、どっちもタイプの違う人材の無駄遣いになってる可能性は高い。
私の場合は今は仕事がありますが、仕事はあるが資金はない状態であり、
今のお給料の原資は雇用促進事業の補助金だし、契約は年単位なので
ちょっと仕分けされれば一気に失業側に倒れる可能性はあります。
実際昨年の4月は雇用主が切り替わる谷間で1ヶ月失業してました。
＃失業中は無給のボランティア研究員/プログラマ化してました…。
＃当然その状況では失業認定されないので雇用保険の失業給付がないという…。
Re: (スコア:0)
それJavaでしょ？
言語が悪いんです。
Re:もしや、あいつが闇プログラマだったのか？ (スコア:1)
ほう。原因は言語であるとな？貴殿のオススメ言語は何だと？
ちなみにオススメが関数型言語族だと私はサンプル程度の物を読み書きしたことはあるが
実際に使うものを書いたことはない初心者で、チームメンバは多分存在も知らないだろう。
自分が初心者な言語で未経験なチーム・メンバの相談に乗りながらってのはちょっとキツイ。
＃私のこれまでの経験だとC++でテンプレート・メタプログラミングやった時が一番関数型っぽいプログラムだったかも。
現実的にはチームの皆がまぁまぁ書けて（たまに私が相談に乗ればいい程度で）
そこそこ処理系が普及しててライブラリもそこそこあってな言語を選択する必要がある。
その中ではJavaは比較的ツールの支援があってそこそこ良くできてる言語だったからね。
とはいえ実際のところは、我々、リライトを機に今度はC++に移るかもと言う流れなんだけどねｗ
（コンパイラ・フレームワークをCOINSからclang+LLVMに変えるかもという話があってね…。）
＃今は異動していない闇疑惑の彼が作ってた1個前の版でC++で書いてたが、
＃あのときにはもっとヒドイコードを書いていた。Javaで書かれたコードの方が幾らかマシ。
ぶっちゃけ言語の理想は私だってある…というかその言語はまだ生まれていないと思っているｗ
Re: (スコア:0)
たとえば、
>大したことない内容のメソッドって結構数あるので意外と効果は大きいです。
>極端な例だけどgetter/setterの類や等値演算のメソッドなら多くの場合
>本体より型宣言とかの決まり文句部分の方が多いわけだし。
このへんとか、
Java系の人だと、必要無用にかかわらずとりあえずで作る人が多いように思います。
とくに、getter/setterがひどい。 人によってはすべてのメンバについて定義していたりしました。
それじゃ隠蔽している意味ないのに。。。
そもそも
Re:もしや、あいつが闇プログラマだったのか？ (スコア:2)
＞＞別人ですが、Javaがわるいというよりも、Javaの習慣的なコーディングにわるいところが多いといった感じですかね。
＞ava系の人だと、必要無用にかかわらずとりあえずで作る人が多いように思います。
＞とくに、getter/setterがひどい。 人によってはすべてのメンバについて定義していたりしました。
それ違う。
そのプログラマーのスキルが低いだけで、全然Javaの一般的なコーディングスタイルじゃねえよ。
＞Java系の人は過剰にやりすぎる感じがあります。。
＞コードが似ているという理由だけで全く別の目的(機能)の部分までリファクタリングされていたりしました。
それも初心者が良くする失敗の一つで、Javaとは関係ない。
これらは結局はプログラマーのスキルの低さが原因ってだけなんだよね。
それはJavaだろうとPHPだろうとVBだろうとC++だろうと、言語に関係なく存在する。
Re:もしや、あいつが闇プログラマだったのか？ (スコア:1, 興味深い)
>それも初心者が良くする失敗の一つで、Javaとは関係ない。
Java屋さんにわりと低スキルな人がいっぱいいるのが悪いのよね（一時期の流行の所為なのだけど偏りがすごいよね）
っていうかできる人は高いのでハズされてるというか(デスマになってからヘルプでよばれるとか酷い扱いだ)
はい、言われるとおただの偏見だと思いました (スコア:1)
上げられた例は例えばC++でも書く人によっては普通に発生させそうな…。
リファクタリング・ツール使わないリファクタリング的書き替えは昔からあるわけだし。
手段の目的化と濫用の危険はあらゆる「手段」にある危険。
もちろんリファクタリング・ツールも例外じゃないというだけのこと。
リファクタリングと同様濫用されやすいデザインパターンについての本：
パターン指向リファクタリング入門 ～ ソフトウエア設計を改善する27の作法 [amazon.co.jp]
ジョシュア・ケリーエブスキー 著、
小黒 直樹、村上 歴、高橋 一成、越智 典子 訳
日経BP社 (2005/8/4) 刊
ISBN: 978-4822282387
…はやりすぎたデザインパターンの採用を打ち消すリファクタリングとかの例があって中々示唆的だった。
私の場合は
「リファクタリングがあるから、最初から勢い込んで『やり過ぎた設計』にしなさんなよ…。」
という方向だしね。実際、クダンの彼のコードは作りこみ過ぎて読みにくいコードになっている。
柔軟性も必要に応じて後から追加可能になったというところがリファクタリング・ツールのいいところ。
Re: (スコア:0)
Re:重要条件 (スコア:1)
Re: (スコア:0)
タイポ (スコア:0)
闇鍋の間違いだよ。きっと。
Re:タイポ (スコア:1)
成果物は大差ない様にも思う。
どこかで聞いたような (スコア:0)
バトルプログラマーはやせ？
優勝するともれなく近所に住む親戚の幼女が頻繁に尋ねてきてくれるようになるのでしょうか？
Re:どこかで聞いたような (スコア:1)
秋月って名前のおじさんも付いてきます。
by rti.
それだと (スコア:1)
アメリカ王率いるキャラテック社の方がそれっぽいかなと
Re: (スコア:0)
「しらせ」じゃなかったっけ。
＞優勝するともれなく近所に住む親戚の幼女が頻繁に尋ねてきてくれるようになるのでしょうか？
「もっとちゃんとした仕事に就いた方が良いよ」と、
至極真っ当で、心臓をえぐるような指摘をしてくれるんですね、分かります。orz
＃「へ～お兄ちゃんでも大人の女の友達がいるんだ。」orz
それって (スコア:0)
周りを暗闇に落としている人じゃないよな？
# 今までちゃんと教育を受けてきたはずなのに
# 目を疑うようなプログラミングする人いるよね。
# 特に、何も考えないコピペ系の人に多いんだけど。