プログラマが気をつけるべき５つの人種

1 名前:以下、はてなにかわりまして元増田がお送りします。 投稿日:2012/05/08 03:24:36

一口にIT業界と言いましてもその意味するところは実に幅広く、今日もそこかしこでITパーソンを自覚する人々の人生模様が織り成されております。そんなIT業界にはプログラミング楽しす！コード書きたす！革新大好き！なんていうイノセントなプログラマが特に気をつけるべき人種というカテゴリが存在します。なんとなく想像がつきますかね？想像のついたあなたもつかなかったあなたもしばしお付き合いのほどを。

1. 俺SEなんだけど仕事で何億って予算動かしてんだぜ？（すごいって言って！）

こういう人種は、素人の書いた落書きのような絵に大金を積んでそのことを自慢したがるような人たちです。彼らには美しさというものが理解できず、金額の大小でしか物事の価値を判別できません。それだけならまだしも人の価値まで動かしている金額で決まると思い込んでいるフシがあります。彼らはSEと名乗っていてもその実態は普通のサラリーマンと大差なく、コードを書くのは下っ端の作業員の仕事だと思っています。彼らのいる場所は大企業の中とかその周辺です。大企業の所属なようなフリをしていて、よくよく知ってみると下請け会社の人だったりします。そして何の疑いもなく、ウォーターフォールの頂上から幾人ものプログラマーを滝壺に落として溺死させるのです。このような人種には近づかないのが賢明でしょう。
お金に困った時を除いて。

2. プログラミングが楽しい？？なに言ってんだこいつ・・・ちょっとあたまおかし（ｒｙ

大学の情報学部などを出たばっかりにIT業界への就職を余儀なくされたかわいそうな人たちです。この人達もプログラミングはただの作業で、プログラマがクラスアップするとSEになると思っています。仕事は仕事と割り切っている人が多く、コードの出来や開発プロセスにはほとんど注意を払いません。企業で順調に出世するのは実はこういうタイプだったりします。
しかし、忘れてはならないのは今日のITの基盤を築いた人々はいずれもプログラミングが好きで、それゆえに突き抜けたプログラマたちであったということです。このような人種とは付き合い方を工夫することでうまくやっていくこともできます。

3. Emacs? Vim? なにそれ美味しいの？（ポカーン

この人達はプログラムを書きそれで仕事をしていますが、コードのクオリティーやより良い方法に無頓着です。使っているエディタを選んだ理由も周りの人が使っているからとかそういう理由で、Eclipseみたいな画面が何個にも分割されたIDEを使うのが一流のエンジニアだと思っています。多分それはIDEが飛行機のコクピットのように複雑で一見何をしているのかわからないからで、実際本人にも何のために有るのか分からないようなスペースで画面の半分が埋まっています。彼らはEmacsやVimなどの拡張可能なエディタを聞いたことがありそれで生産性をあげているプログラマが多数いることを知っているかもしれませんが、実際に試したことはありません。
このような人種は特に害を及ぼしませんが、学ぶことも少ないでしょう。

4. 関数型言語ってなに？Javaにも関数あるよ？

3 に上げた人と同じようですが、この人達は技術の発展というものに無頓着です。プログラミング言語はJavaが全てで、その他の言語を頭のおかしいヒゲもじゃが作った訳分かんない新興宗教のように思っています。彼らは関数を書き、クラスの中にそれを集めてまとめるだけがオブジェクト指向だと思っています(c.f. staticおじさん)。彼らは新しい言語を学ぼうとせず、それ故、ほかの言語の優れた点を知りません。そして、今日も１０００行あるような関数を作って何も疑わないのです。
このような人種は3の人種のように特に害を及ぼしませんが、注意すべきは彼らが自分のやり方を強制してきた時です。そんな時は「λ！」と唱えて追い払ってやりましょう。

5. オープンソース怖いお（´・ω・） 保証のあるベンダー製がいいお（`・ω・）

この人達はベンダーには神のようなエンジニアがいて自分たちの抱える課題をすべて解決してくれると考えています。また、GPLとMITライセンスの区別もつかない割に、ライセンス違反をおかしてしまうことを非常に恐れています。彼らは保証を重視します。たとえ、その保証が実際にシステムの正常動作を約束するものでなかったとしてもかまいません。保証があるということが大切なのです。

以上、いかがでしょうか。まあかなり誇張してますが、こういう人いるわーっていうのも多いのではないかと思います。しかしかなしいかな、現実はこういう人たちのほうが多数派だったりするのですな。

この記事を読む

もしもプログラミング言語がアイドルグループだったら

1 名前:以下、はてなにかわりまして元増田がお送りします。 投稿日:2010/07/27 22:47:44

もしもプログラミング言語がアイドルグループだったら
誇張や事実と異なる表現がございます。ネタとしてお読みください。
特に関数型言語は全く触ったことが無いため誤っている可能性があることをご了承下さい。

while(i＜10000)++i;

COBOL	バブル時代に銀行のCMにも出演したことがあるが現在はほぼ引退している。
BASIC	一時期は誰もが知っている国民的アイドルだったが、現在はほぼ引退している。しかし昔からの根強いファンによって現在も一部で活躍中。
FORTRAN	インテリ層に大人気のアイドルグループ。
Brainfuck	アイドルの定義を逆手に取った誰も得をしない名ばかりアイドル。
PERL	もともとは活字メディアでの活動を主軸にと結成されたが、現在はネットで活動することが多い。
RUBY	PERLを真似た純国産のアイドルグループ。こちらも最近はネットでの活動が多い。
C	今も現役で活躍する言わずと知れた国民的アイドル。しかし最近はJAVAなど後進のアイドルたちに仕事を奪われつつある。
C++	Cのメンバーに加え、あらゆる属性の女の子を集めた超大型アイドルグループ。しかしあまりにマニアックなため、一部のファン以外はついて行けていない。
JAVA	C++の失敗を反省し一部のマニアックな属性を削った正統派アイドルグループ、初心者はJAVAから入ることを進められる。
C#	まっくろ社がJAVAのパクリユニットとして一度デビューさせたが太陽社に訴えられたため名称を変えた。しかし後進だけあり、女の子の質は高いと好評。
GO	新進気鋭のぐぐるからデビューした新人アイドル、デビュー時は大きな注目を集めたがその後は期待ほど売れていない。
D	他のアイドル達のいいとこ取りをした最強ユニットのはずが、未だメジャーになりきれないマイナーアイドル。
Objective-C	Cに新たなメンバーを加えたユニット。しかしC++ほどメジャーになれずそのまま消えるかと思われたが、出演した林檎の映画が大ヒットし延命した。
JAVA SCRIPT	身近がモットーのネットアイドル。あなたも気付いていないだけで、いろいろなところでお世話になっています。
PHP	ネットアイドルとしてデビュー、物珍しさも手伝って人気になったが、女の子が明らかに寄せ集めと批判も多い。
LISP	81が新人声優を売り込むために作ったスフィアのパクリユニット。おっぱいが大きい。

この記事を読む

凍ったニシキヘビと凍えた番人

1 名前:以下、はてなにかわりまして元増田がお送りします。 投稿日:2012/01/22 21:15:37

言語disりが流行ってるようなので一つ
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だと
Perl使い「そうだよね、そこの仕様は頭悪いよね。でもPerl6のこの機能使えばこんなに短く綺麗に書けるんだぜ(と全く読めないコードを出す)」
比較的柔軟な仕様とコミュニティのあるRubyは
Ruby使い「うんうん、仕様の話題でもそこは殺人現場とか呼ばれてるね。コミュニティ的にはこっちの機能を使うことを推奨しててそっちはobsolatedだね」
酷い言語仕様に調教されつくしたPHPは
PHP使い「それ言い出したらこっちにこんなに大きな地雷あるし、この地雷なんてもっと大きいぜ。ほんとPHPは地獄だぜ」
永久凍土のPythonは
Python使い「お前の思考通りに言語が動くんじゃなくてお前の思考を言語に添わせるんだよ、言語の挙動すら理解せずに使おうとするんじゃねえ」


こんな感じに、まず最初に質問者へ人格攻撃を行う。インデント言語であることやselfの問題について未熟なプログラマからのどうでもいい指摘を散々受け流してきたPythonコミュニティは、言語仕様について文句を言われる事に慣れているためまず相手を攻撃する。初心者を寒波が洗礼するのだ。
言語仕様が汚くなっている事まではどの言語も一緒なのだけれど、Pythonコミュニティだけは欠点を認めず必死に(∩ ﾟдﾟ)アーアーきこえないという態度を取る。
これこそがPythonを糞言語たらしめる最大の弱点である永久凍土の問題。コミュニティが凍れば言語の進歩も凍る。

Pythonそのものは一人で使う分には手軽な言語なだけに、使用者が思考停止しているが故の機会損失の多さが残念である。

この記事を読む

明暗くっきり、オライリーと技術評論社

1 名前:以下、はてなにかわりまして元増田がお送りします。 投稿日:2011/12/30 05:21:16

オライリー本の値段は高いが、質も高い。
自分の専門分野のオライリー本は必ず一冊は持っているのが当たり前だった。「サイ本」とか本にニックネームが付けられてそれで通用するぐらいに、とにかくオライリーの本はwebエンジニアにとって特別な本であった。そして時代は変わる。
　
オライリー自体は変わっていないが、時代が変わってしまった。
日本語で出版されるオライリー本の価値がゆっくりと毀損する間に、技術評論社の書籍の評価はうなぎ上りだ。
　
うん、ここ最近ではHadoop本は秀逸だった。トレンド技術を捉えてうえで数年は価値が落ちない網羅っぷり。
まだ枯れきっていない分野で日本語オライリー本が存在感を示した最後の例になるかもしれない。
　
乱立するKVS分野において日本語オライリー本は無力極まりなしで目も当てられない。
cassandraがようやく出たがversion0.8だ。外人さんが書いた原本を数ヶ月から一年かかって日本語に訳し終わる頃には技術自体が進化してしまって日本語版が出版される頃には賞味期限切れ間近という切なさ。時代にそぐわないとしか言いようが無い。以前のように大型技術が確立されたら五年十年それで食えます！ってな時代じゃないんよ。PerlとかMySQLのような大型で枯れきった技術はなかなか出ない。ああそうだいまだにMongoDBの日本語オラ本は出ていない。英語ではもう4冊か5冊は出ているというのにだ。乱立KVSの先頭を走っているMongoDBについて紙媒体の情報がほとんど無い切ない状況はいつになったら変わるのだろう。
　
この手の話題になるとすぐ「紙が悪い！電子書籍わっふるわっふる！」と叫ぶ人がいるが問題はそこではない。英語を日本語に訳しているタイムラグが問題なのだ。そこに日本語オラ本の致命的な欠陥がある。
　
一昔前のように大型OSS技術が出て枯れきる、なんてことは滅多になくなってしまった。英語原本を訳してる間にも日々技術トレンドが変わってしまうんだ。なぜ日本人のほとんどは英語が読めないんだろう。文科省のせいにしたって何も解決しないけれど、webエンジニアなら英語ぐらい読めるようになれやお前ら。
　
おっと話がそれた。そろそろ技術評論社について語ろう。面倒なので三行で語る。
　
日本人のスタープレイヤーが書いた原稿を元に出版される技術評論社の書籍の評価が最近うなぎ上りだ。
特にWEB+DB PRESS plusシリーズはどれも凄まじい出来で恐れ入る。
公式サイト　http://gihyo.jp/book/list?series=WEB%2BDB%20PRESS%20plus
　
ますます技術トレンドの移り変わりが激しくなった今、翻訳という形態の技術書の価値が無くなろうとしている。オライリーとて例外ではない。
オラの功績はすさまじいものがあるし、足を向けて眠れないぐらいなのだが、それでも俺はこのエントリを書かざるをえないぐらいに最近の日本語オラ本にはガッカリせざるを得ないのだ。
　
日本語の本は日本人が書けばいい。訳なんていらない。それが当たり前の時代がそのうち来るだろう。
あとwebエンジニアならいい加減英語読めるようになろう。努力すればすぐに読めるようになるさ、来年はそういう年にしよう。
じゃあおやすみお前ら。
よいお年を。

この記事を読む

基金訓練の講師

1 名前:以下、はてなにかわりまして元増田がお送りします。 投稿日:2011/11/13 01:00:22

基金訓練の講師をやめました。

基金訓練、今は求職者支援制度に名前が変わったみたいですけど、そこの講師をやめたというか、会社ごとやめて転職しました。
何の講師をやっていたかというと、今をときめく(?)Androidの講師です。
転職先にも少しなれてきて、今までのことを振り返って書き留めてみたのですが、せっかくなので発表することにしました。もともと僕だけが読むメモのつもりで書いたので、読みやすい文書ではないですがご容赦のほど。

Androidの講師になるまで

Androidの講師になるまでは、Javaのサーバーサイドのエンジニアをやっていました。
お客様のところに常駐し、システムの一部ではあるけど、自社メンバーだけで上流行程から担当し、僕はそのチームリーダーでした。
でも、このご時世なので、仕事がどんどんなくなっていきます。
プロパーの方でも仕事がないような状況で、それでも僕らのチームは半年ほどは細々とメンテなどの作業をやっていたのですが、最終的には契約終了になってしまいました。
自社に戻って、何をするのだろうと思っていたら、Androidの講師をやれ、といわれました。
Androidは、暇だった時期に少し動かしてみて、簡単なアプリなら組めるようになっていたのですが、人に教えるほどの技術はありません。しかも準備期間は1週間ほどしかありませんでした。
ビデオ教材と教科書が用意されていて、それに従っていれば最低限の講義はできるのと、最初のうちは純粋なJavaの講義だったので、前半をやっている間に講師はAndroidの勉強をしよう、という、何とも乱暴な計画を立てたのでした。

基金訓練をはじめて

ほぼ定員いっぱい近い受講者の方が集まったのですが、スキルが全くバラバラです。
JavaやC#,C,C++の経験者がいるかと思えば、人差し指だけでキーボードを打っている方もいます。
講義の最初のうちはコマンドプロンプトを使うのですが、教材には説明がなく、最近の人は知らないだろうと思って説明書を作っていたのですが、まさかコピーペーストのやり方から説明することになるとは思っていませんでした。
それでもやる気のある方はまだましで、どうみても給付金目当てとしか思えない、やる気のない方が何人もいます。
こちらも準備不足の中、生まれて初めて「先生」と呼ばれる仕事を始めることになりました。

問題だらけの講義

基金訓練を始める前は「きちんと技術を教えられるかな」ということばかり気にしていたのですが、講義の運営の方が問題続出でした。
いかにもやる気のない方々は講義中もトイレだ電話だといって抜けてしまう、講義中に当てても「わかりません」しかいわない、かといって質問もしない。当然課題も期限までに出さないので0点しか付けようがません。
そういう方でも、こちらから無理にやめさせたりすることはできないので、何とか講義だけはでてもらっていました。
けど、それがよくなかったようです。
まじめに受講されている方々から「金をもらって受講しているのにあの態度は何だ」「入校条件（キーボード入力）すら満たしていないのではないか」「講義のペースが遅すぎて時間が余る」などの苦情があがり、まじめな方から「就職が決まった」などの理由で辞めていってしまいました。
後に残った、やる気のない方々と、講義を続けていくしかありませんでした。

2回目の講義

１度目の皆さんが修了し、2回目の講義を行うに当たって、前回の反省点を改善すべく、いろんな手を打ちました。

• ビデオ教材の品質がよくなく、経験者の方にあきれられる場面が多かったので、自作の教材やサンプルプログラムを大幅に増やした。コンピュータの動く仕組み、オブジェクト指向設計やアルゴリズムに関する講義など、オリジナルの教材に入っていない内容を講師独自の教材を作成して講義を行った。
  
• 講師2人の役割をきっちり分けた。講義は基本的に僕だけで行い、もう一人（以前から一緒に仕事をしていた仲間です）は受講生のフォロー、サポート役に徹してもらった。
  
• 受講生の方の国語力を伸ばしていただくために、受講日記を付けていただいたり、毎朝5分程度の発表を行うなど、読む・書く・話すの時間を設けた。
  
• 講義終了後のわずかな時間（昼夜間連続講義なので）でも自習時間として教室を開けるようにした。本当は開始時間をずらして時間を拡大したかったのですが、そちらは会社に認められませんでした。
  
• あまり出来すぎる方は、出来るだけとらないように会社に依頼した。すでにJavaを知っている方はAndroidは独習で学べるはずです。iPhoneの経験者なら、仕事がずっとないのは不自然です。
  
• やる気のない方や自己中心的な方は共同作業を嫌うのを利用し、チームで行う作業を増やし、そういう方が自然に辞めていくようにした。

最後の手は、会社に怒られるのではないかと正直不安でした。実際辞めていく方が増えたのですが、こういう方は「家業が忙しくなったので手伝う」「体調が悪くなったので療養する」といったもっともらしい（？）理由で辞めていったので会社から怒られるようなことはありませんでした。
むしろ受講生の方の中から、積極的に他の方にアドバイスする方が増えたため、スキルの低い方からも「質問をしにいける人が(講師以外にも)大勢いたのでよかった」といってもらえるようになりました。
今回は、終了後の受講生の方どおしの打ち上げ会に呼んでいただきました。おおむね好評だったのだろうと思います。

本気でプログラマになりたい方へ

未経験だけど、求職者支援制度を利用してプログラマになりたい方向けに、こういう人がプログラマに向いている、こうした方がいい、という条件を挙げてみます。

• 作りたいアプリの具体的なアイディアがある。

プログラムの勉強ははっきり言って辛いです。やりたいことが明確になっていないと、なかなか続かないです。

• コンピュータの操作が苦にならない。

僕は「写経」と呼んでいるのですが、サンプルプログラムを実際に打ち込んでみて、エラーがあれば自分で修正する
という「訓練」をやらないと基礎が身に付かないです。そもそもキーを打つのが苦手、という人はきっぱりあきらめましょう。エラーの原因を自分でぐぐって調べられないような人も、この業界には向いていないです。

• 計画的に作業できる。

いき当たりばったりではなく、最初に手順・段取りを考えてから作業を始める方が向いています。
講義でも、課題作成に何日もかかる課題があるので、何も考えずに適当にやっていると期限までに終わりません。

• 共通点を見つけるのが得意。抽象的な考え方ができる。

僕がプログラマにもっとも必要な能力と考えています。
「きりん、うさぎ、あひる、かば、4つの動物で仲間外れは？」みたいな問題が苦手な人は、向いていないと思います。

• 課題を理解できる。

単に「読める」ではなく、課題を理解し、既知の技術で解けるものと未知のものに分けたり、繰り返し処理や、複数の似たような処理を一つにまとめるといった作業ができるかどうかです。
さっきの抽象的な考えもそうですが、今までそういうことを意識してやっていない、という方が多いと思います。そういう人は、しんどい思いをすると思います。

• 習ったこと以外にもいろいろ自分で試してみる。

「ＡとＢという方法がありますが、ここではＡについて説明します」と講師がいったら、Ｂは自分で調べましょう。習ったプログラムを少し変えてみてどうなるか試してみましょう。それがうまくいかなかったとしても、経験というプラスが残ります。

• 自分で問題を考え、解く。

講師の言うことが理解できたと思ったら、自分で応用問題を考えて、プログラムを書いてみましょう。もしそれが期待した結果にならなければ、どこかで理解が間違っている可能性が高いです。
先ほどの「試してみる」もそうですが、BLOGで実施すると、それをみた方からコメントやアドバイスをもらえることもあります。

• ちょっとずつ試す。

いきなり何十行もプログラムを書いて動かなかったとしても初心者はまず動かせるようになりません。少し書いて、動かして動作を確認し、また動かして、を繰り返す方が結局早く完成します。
ちゃんと動く「プログラムの断片」を増やすことは、後で同じようなプログラムを書くときに、「断片」をそのままコピーして使えるようになると言うことです。

• 動くものを書くのが先、きれいに書くのは後。

一度プログラムを書き始めたら、まずやることはプログラムを完成させて動かしてみることです。プログラムを書いている途中で、同じような処理があるからforで書きたいとか、メソッド化したいとか、思うかもしれませんが、プログラムの初心者はまず動くプログラムを書いて、それができてからきれいに書き直しをした方がいいです。

• 頭の中で考えてまとまらないときは、それを文書や図にして書き表せる。

すぐに解けない課題は、書いて残しておきましょう。書いて整理することで、解けることがあります。今は解けなくても、後で見返して解けることがあります。
特に図に書く、という作業は意識的にやった方がいいです。講師に質問するときも、口で説明するより、図に書いた方がずっと通じやすいことがあります。

• 困っている人を助ける

自分ができたことで他の人が詰まっていれば、アドバイスしてあげましょう。助けてあげると言うだけでなく、他人に説明すると言う作業は、自分自身の理解をより深める作業でもあります。
もちろん自力で最後まで解くことが重要な課題もありますが、そういうときは講師がそれとなく言ってくれるはずです。

• 環境を味方にする

とりあえずアプリを書いたら、同じ講義を受けている人や講師に見せて感想をもらいましょう。
アイコンを書くのが苦手なら、イラストが上手そうな人を見つけて、書いてもらったり、書き方を教わったりしましょう。
講師以外にも味方を増やしましょう。
訓練を受けているのは同じような環境の方ばかりなので、相手だって同じことを考えているはずです。

• ノートに書いたことは理解できるようになるまで何回でも書き直す。

紙のノートに講義内容を書いたり、テキストの余白にメモしている人がいますが、それは講義の内容を聞いて即理解できる人が、聞いたことを忘れないためのやり方です。
わからない人は、わかるようになるまで、何回でもノートを書き直した方がいいです。わかったことを継ぎ足して、表現を見直して、時には冗長な表現を削って、自分だけのオリジナルのテキストを作るつもりで書きましょう。当然書くのは紙のノートではなくパソコンをつかいます。

• 羞恥心を上回る発表力を持つ

プログラミング以外の世界でもプロや、プロ顔負けの技術を持つセミプロ、ハイアマチュアといった方は自分の作品を世に出すときに恥ずかしがったりしません。不安はあっても、それを上回る意欲を持って、どんどんアプリを書いて、マーケットに載せましょう。

• この業界のことをきっちり勉強して、業界の習慣にあわせるように努力しましょう。

ひょっとすると業界の習慣よりあなたの意見の方が正しいこともあるかもしれませんが、未経験の人が言っても周囲はたぶん聞いてくれません。「私はずっとこのやり方でやってきたしこれからもやる」という意見はひとまずおいておいて、まずは周囲に認めてもらうようにしましょう。

• 自分より優秀な人のいる世界に飛び込む

余りに差がありすぎて自信をなくすと逆効果ですが、技術を身につけたければ自分より優れた人から学ぶのが一番です。コミュニティーや勉強会にも積極的に参加しましょう。

最後のが理由で、僕は講師を辞めたんですけどね。
訓練されている方から学んだことも多いですが、僕は、僕自身が技術を磨ける環境に身を置きたかったのです。

この記事を読む