  |
はてなキーワード: Cobolとは
社内SEとして2社ほど経験したけれど、社内SEで必要なのは技術力よりも社内政治力だとつくづく思う。
感じたことをつらつらと書いてみる。新しいことをするには立場と権力がないと何もできないということをつくづく感じた。
社内SEになりたいと思う人は、ちゃんと考えて入った方がいいと思う。
大きな声では言わないが、自衛隊を合憲とした例の判決は連中にとっては「屈辱の極み」という事になってるらしい
あと個人的に思うが、憲法学者ってのはぶっちゃけ「後から発見されたり発掘されたりした物によって定説が覆る心配が絶対にない考古学」みたいなもんで、数年で業界のルールがガラリと変わるような世界の人間には完全に異次元の世界だよ
プログラマーに分かりやすく例えるなら、「COBOLだけが業界唯一のプログラム言語として誕生当初からずーっと存在し続けている世界」みたいな感じ
改憲を志向する安倍はさしずめ、「COBOLなんて古くさい言語捨ててC言語にしようぜ」と言ってるようなもの
どうもスーツです。
http://b.hatena.ne.jp/entry/d.hatena.ne.jp/NOV1975/20150512/p1
これのはてブと元記事見て血圧上がったので、チマチマ反論するよ。
記録を軽視するな。
業績が個人について回ったら、誰も保守しないだろ。
金を生むのかそのドキュメントレビュー。リファクタリングでいくら稼げますか？
ロボットアニメの博士みたいにな、空中から予算が湧いて出たりしないんですよ。
誤解があるみたいだから言っとくが、評価には減点も加点もある。
ただ、スケジュール前倒しで予算が浮くようなシステム作ったりしてないだろ。
何故ならばスケジュールは常にキチキチで、間に合わなきゃ減点されて当たり前だ。
そこは同情する。
見積は常に過少で、調整は過小評価され、日程だけが評価軸になりがちだ。
オマエらが椅子を滑らせて隣の同僚と１分会話して実施した内容は、キサマが風邪引くと誰にも共用されない。
コードレビューした。仕様書レビューした。まあギークが言うなら内容に間違いはないんだろう。
だが、その部分は三年前に転職した同僚がやったはずです？それじゃダメなのは判るよな？
オマエ独りで完結するプロダクトをオマエがケツもって仕事するなら文句は言わないが、違うよな？
本来は「指摘事項ゼロ」「問題がないか再精査しろ」「再精査したが無い」「一筆書け」「書いたから通せ」をやるのが正しいというのは判る。
やって欲しいのか。
ギークが不要だと思ってるレビューに、さらにチェックリストが加わったり、書類が増えたりするぞ。
正しい数字で出せ。
恐らく上から順番に怒られた上にいらん書類を書かされた上に再発防止策を延々と書いた挙句、本業であるコードを書く仕事が遅延して、さらに同じことがループするが。
政治的に正しいんじゃ無いんだよ。
そうした方が、ギークの遅延が少なくなると思うから、スーツが知恵絞ってんだ。
ギークが一度遅延したが最後、遅延が無くなるまで延々と再発防止策（しかも一度着手しているのでスケジュール見積もりについて以外でだ）書かされるぞ。
その「どんなに正しくても」は、どこの誰が担保してるんだ。
ギークの勘か？
オマエが言えよ。
言えないならその立場に無いってことだ。
「常識で考えればこうする」というのは、何時の時点の誰の判断だ。
たった30年前までメインフレーム全盛だったが、常識的に今後はオープンシステムだと断言できたか？
違うだろ。
オマエの書いたソースが間違ってて、コンピュータはソース通りに正しく動くんだよ。
バッドノウハウなのは認めるが、誰も幸せにならない正しさを貫くことはギークとしての職責の一部か？
もしそう思うならそうしろ。
責任は取られてるんだよ。
はんこの数だけな。
機械学習の重み付けと同じでな、それがスーツの出世パラメータに影響してんだよ。
記録を軽視するな。
証拠を残せ。
「なんでバグが無いのが判ってるのに単体テストするんだよ」とか言って、テスターがサボったら困るのは誰だ。
ただ、監視システムにタイムレコード追加するより、カメラ範囲内に時計を置くのがハックなんだろ？
コードスニペットは溜め込むくせに、口頭で言った内容をメールで送れないのは何故だ？
ギークなら可読性を上げろコメントを残せソースを引き継げるようにしておけ。
JavaコンパイラにC++のソース突っ込んだってエラー吐くだけだ。
まあ、見通しが悪いと思うなら、オマエが新言語作ってくれても良いんだぜ？
就職支援を得ていくつかのIT企業を紹介され、業界未経験であるにも関わらず前職とほぼ同じ給料で雇ってくれた会社が今の会社で
入社したのが２０１３年の７月。
最初の転職時点で子供までいたのにこんなボンヤリした感じで決めたってのが理解不能すぎる。
俺が26歳の時に初めて転職した時ですらこれの100倍は考えたぞマジで。
質問に対する答えもちょっと書くと、今の会社が特殊な業務の既得権を押さえてない限り将来は厳しいだろう。
webに行ったら（行けたとして）安泰かというと、当然そんなわけない。そもそも安泰とか考える人間には向いてない可能性が高い。
安泰とか考える場合は技術で食ってくとか考えるのはやめて人間力（笑）で食ってくことを考えるべきだろう。
具体的にはセールスエンジニアとかのマネージャになる方向だ。純粋なセールスになったほうがより安泰だし、会社の行く末への依存度合いを減らせるが、心理的に難しいだろう。
マネージャとして生きていくには潰れない会社を選ぶことが重要だ。webの会社はすべて潰れる可能性が十分あるからダメ。
COBOLは将来にわたって現役、現行の開発環境やシステム連携が使える
http://itpro.nikkeibp.co.jp/article/Active/20140520/558095/
http://anond.hatelabo.jp/20140620015633
多種多様なフレームワークやライブラリの使い方を覚えたりする必要ないから「言語を使えるようになる」ってのははっきり言って簡単だと思うよ。
でもCOBOLは色々大変だぜ？
以下の条件でプログラム作ってみ？ウンCOBOLの片鱗は味わえるかもね。
要件
入力ファイルA及びBのレコードのマッチングを行い、一致した場合はA又はBで持つコードに対応した値をマスタC、D及びEから取得して集計結果をファイルFに出力し、マスタから値を取得出来なかったレコードはファイルGに出力せよ。
作成上の制約
他にも色々あったけどもう忘れちった。思い出したくもねーけど。
ゆーすけべーさんが以前に作ってたimeeroみたいな感じです。画像Blogをスクレイピングしてエロ画像を効率的に見るサイトです。
なお、先程解約手続きを済ませたので4月末くらいに見れなくなります。エロサイト自体にあまり興味がなく、ローンチしたらやる気が無くなったのです。
テスト駆動開発がやりたく、DSLに強いロック魂を感じたRSpec。
はやりに乗ってBootstrap。
特にCapistranoは名前がキュートでやっていることがカッコイイのでどうしてもやりたい技術でした。
あと、メインとなるRailsはこの記事に書いているスキルの中で唯一経験が無かったというのが一番の理由です。Rubyが好きなのもありますけどね。
いやぁ、退職しようとすると会議室で8時間説教されるって都市伝説じゃないんですね〜。
ところで転職活動をした感覚だと、今より給与が2倍出るところでも簡単に内定が出ることが分かりました。
転職活動やエロサイト作成を通して精神的な余裕も出ましたので、もう少しSIerそのものの問題、仕事の進め方などを熟考した上で、本当に正しいSIerのあり方を考えたいと思います。無理そうなら逃げます。
以上、よろしくお願いいたします。
今日から新卒研修の技術研修が始まりました。初日はCOBOLをMacにインストールして、簡単なプログラムを書くことから始めます。
さて、なんでCOBOLなのかと感じるかもしれません。Webに限らずスマートフォンのマルチプラットフォーム開発にもJavaScriptが浸透し、RubyやPythonは学生の間で人気があります。
逆説的ですが個人的には、COBOLを研修に選びながらも「COBOLを覚えてほしいわけじゃないだよね」って思っています。
習得して欲しいのはCOBOLそのものではなく、どこまで言語の深いところまで掘り下げたのか。つまり「深さを探った経験」を得てほしいからです。
COBOLが新卒研修に適しているのは、適度な深さと広がりがあるから。（特定言語に良くない印象を与える記載がありましたので、この箇所は削除しました。大変失礼しました。）
この「言語を深く探った経験」は、まとまった時間がないとなかなか掘り下げられなかったりします。配属されて仕事や成果を求められるようになると経験しづらい。興味本位でアプリを作ることに没頭する学生時代にも経験しづらい。教授に多くのタスクをふられがちな院生時代にも経験しづらかったりします。
プログラミング言語を、深いところまで掘り下げる機会は、新卒研修の時期に適していると僕は思います。成果や責務に追われずに、プログラミング言語に没頭することが許されているからです。
COBOLのもうひとつの側面は、個性があらわれやすい言語だと僕は感じます。きれいに書けば人間性が感じられるほど美しく書けます。逆に雑に書けば、プログラマとしての伸びしろが良い感じに見えるくらい、未熟に書けます。
COBOLが新卒研修に適しているのは、適度に思考の深みを表現できるから。（特定言語に良くない印象を与える記載がありましたので、この箇所は削除しました。大変失礼しました。）
ここは賛否両論ありますが、いずれにせよCOBOLで何ができるのかではなく、COBOLを通してその人の可能性の何が見えるのかが大事になります。アプリを開発する新卒側と、人材を開発する人事側の、視点の違いもありましょうが。
だからこそ、COBOLというプログラミング言語を通して、深く掘り下げる機会を大切にしてほしいと思います。それから、COBOLを通して何を表現できるのか。プログラム設計という点から、いろいろチャレンジしてほしいなって思います。
そうすれば、掘り下げた分だけ他の言語も、もっと深く短時間で掘り下げられるでしょう。
そうして、自分の思想や仕事に対する人間性を、プログラミングで伝えられるようになったら、きっと一人前のプログラマになるでしょうね。
〉〉ただただ命令通りにコードを書いてくだけな
これよく言われるけどフリーランスでやってきてそんな場面見たこと無いんだけど。。
そんなのどこにあるの?cobol限定の話?
コボル限定なら先にそういえよ
私は大規模・小規模、それこそものすごい人数でのチームや、自分一人のプロジェクトまで経験してきた。化石のような連邦事務局でもクールなシリコンバレーの会社でも働いたことがある。私は１２種類以上のプログラミング言語を学び使っていた。私の時代には ウォーターフォール/BDUF (big design up front), 構造化プログラミング, トップダウン, ボトムアップ, モジュラーデザイン, コンポーネント, アジャイル, スクラム, エクストリーム, TDD, OOP, ラピッドプロトタイピング, RAD, その他思い出せない様々な手法が生まれた。 でもそれらで上手くいってると思えるものは一つもなかった。
（ 注：ここで書いてある「ソフトウェア開発手法が上手くかない」の意味について説明させてほしい。それらはソフトウェア開発のプロセスや、ソフトウェア開発そのものについて予測性や再現性を提供していないという意味だ。ほとんどのソフトウェア開発手法はプログラミングに工学風のプロセスを提供してくれる。しかし、上記の理由でそれだけでは不十分だ ）
チーム生産性・幸福度・メンバーのつながり・１日あたりのコード量・人月・コードの品質・製造された成果物、、、そういったもの以外でソフトウェア開発手法が上手くいってるか、いってないかを図るものはあるのだろうか？
もちろんどんな手法論だって、それに合わせた正しい指標を使えば上手くいってるか・いってないかが計測できる。しかし一番肝心の問題 ーー予算と期限内で要求を満たす事ーー について定常的に結果を図れる開発手法を見たことがない。
上記は私の経験則だけど、僕の知ってる殆どのプログラマは同じような事を経験している。それらの話から言えるのは「ソフトウェア開発手法について厳密な研究は存在しない。なぜならソフトウェア開発上のすべての要素をコントロール事が出来ないからだ」
こんな思考実験をしてみよう、
２つのプログラマのチームがある。どちらも要求・期間・予算はしっかり確定していて、同じ開発環境・プログラミング言語・開発ツールを使うとする。一つのチームはウォーターフォール/BDUFをつかう。もう一つのチームはアジャイルテクニックを使う。
この思考実験にはもちろん意味がない。メンバー一人ひとりのスキルや性格、お互いにどんなコミュニケーションを取るか、そういったことの方が開発手法よりも大きな影響を与えるのは明らかだ。
アリスター・コッバーンが２００３年に"People and methodologies in software development" (http://alistair.cockburn.us/People+and+methodologies+in+software+development) という記事でまとめている。
" 人と人の間で、更には刻々と経過する時間の中で変化するメンバーのキャラクターこそがチームの振る舞い、結果に影響する最初の要因だ。 "
私がプログラミングを始めた1970年当時、開発体制はプロジェクトマネージャー・ビジネスアナリスト・シニアプログラマと言った階層構造でガッチリと管理されていた。開発言語やツールを選ぶことは許されていなかった。私はいくつかの大きく複雑なプロジェクトに関わっていたが大体上記の様な働き方だった。成功したプロジェクトもあれば上手くいかないものもあった。
今は開発言語やツールに合わせて、開発手法・働き方をプログラマが選ぶのが当たり前になっている。アナリストやらがプログラマを監査することは殆どなくなった。プロジェクトマネージャーは"リーダー"・"スクラムマスター"という形で矮小化され、管理職の権限は無力化され「チームの意見をまとめる事」以外は何も出来なくなっている。
ガントチャート・スケジュール・ドキュメントを使った「厳格なマネジメント」は"ユーザー"や"ステークホルダー"の関与を省かせて、"ユーザーストーリー"を要約していた。今や私の周りではまともな大人が監督してるとは思えないプロジェクトばかりだ。プログラマのカウボーイスタイルのコーディングを放っておいてるのに、彼らは自分好きな手法を適用するか作るかさせて、１９８０年代以上に決め事・儀式だらけだ。
実際、今のプログラマは１９７０年代のCOBOLの現場以上に手法論について厳格で、盲信している。実際私が最近関わるプロジェクトは、大体の場合何も価値を生み出さないのに一人か二人のメンバーが開発したプロセスや"ベストプラクティス"を背負わされてるものばかりだ。
プログラミングチームが手法論を採用する（多くの場合チームの数名か、一人のいじめっ子が決めるのだが）と、やがて厳格に従うように要求を始め、やがてそれは宗教になる。そうなることではじまる無自覚な攻撃が、手法論やテクノロジーが生産性を高めるより早く、チームの生産性を下げてしまう。
私の経験から言わせると、アリスター・コッバーンの論文やフレデリック・ブロックスの「銀の弾丸はない」http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html で述べられているように、プロジェクトを成功させるにはチームメンバーが共通のビジョンを共有する事（その本では「コンセプトの統合」と呼ばれている）が必要だ。特に何かの手法論を指しているのではなく、これと言ったプロセスがない場合でも同じだ。私はプロジェクト管理ツールの「完了」ボタンをクリックするだけのチームで働いことがあるが、何故か分からないがBDUFやアナリストの監査の元で働いていた昔よりも気分が悪いものだった。
私はプログラマは様式やツールにこだわるより、同僚の話にもっと耳を傾け、もっと一緒に働くことに注力したほうが良いとおもう。そしてプログラマは手法論やプロセスについてもっと疑って掛かった方が良いと思う。そうすればみんな魔法の様に生産性が上がる、間違いない。多分プログラマが社交的なスキルを高めるのは他の職業より大変な事だと思う。（私は必ずしもそうだと思っていないが。）でもそういったスキルを鍛える事は、手法論を試すより事よりはるかに元が取れる、間違いない。
これの翻訳です。
http://typicalprogrammer.com/why-dont-software-development-methodologies-work/
注1 '14/02/11 まだ半分しか翻訳してません。（明日完成予定）
http://getlife.hateblo.jp/entry/2014/02/06/030300
こういう無知なおっさんが居るから、日本のIT業には魅力がないのだよなぁ、という印象
自分はプログラマというよりは、どちらかというと研究で飯を食ってる非SIのエンジニア
このブログの著者のおっさんが言うところの、プラスアルファは手に入れてる側ではあるんでしょう
普通のプログラマであることでは、差別化が出来ないと考えたからこそ様々な挑戦を繰り返し
基本的には、実装スキルのない人間の設計などはものの役に立たない、という所は同意して貰えるだろうけど
逆に、コーディング以外の技術、例えば無知なおっさんが例にだしてるデータサイエンティストであれば
統計だの機械学習の学術的な知識、体系だって勉強してきた数学力がなければ、まともな設計はできない。
各アルゴリズムがどんな計算をしていて、どの程度の計算量を要求し、どの程度の資源を求めるか、誤差はどうか、
負荷はスケールアウト出来るのか、他にいい手法は存在しないか、といった知識は一朝一夕には手に入らない
実際のコードをイメージしながら、各モジュール群を適切に設計し運用するには、どちらかでは不足がある
つまりコーディングスキルを含めた言語などの道具への理解と、それを使った技術力、そして経験は不可分のもので
揃ってやっと1人前の”プログラマ”と呼べる。そういう人間だからこそ、高給取りになれる。
プログラマ＝コーダという認識は、プログラマという職業や技術を軽視しすぎている人間に見られる
結局のところ、プログラムを書く人（＝コーダ）ではなく、プログラムを使ってビジネスが出来る人（≠コーダ）が生き残るって面では日米大差ありません。
ちっちゃい商売で食えてることがこの人の自慢なんだろうけど、これこそが日本のSierがゴミな理由だ
世の中にどんな技術があり、どんな研究が進んでいて、何が出来て、何が出来ていないのか？
それを知らない人間が良くこういうことを言う、顧客のニーズを汲み取れるだけでビジネス（笑）が生まれるとかないでしょ
例をあげると、海外ではCADのソフトの研究開発は盛んだけど、もう国内では殆ど生き残ってない。
国内には世界的な自動車メーカーがあれほどあるにも関わらず、CADソフトは国内には著名なソフトがない
こういう例には枚挙にいとまがない。日本のゲーム企業は世界的だがそこで使われている、ツールやらレンダラは海外製だし
SIerお得意のビジネス（笑）を生み出す、クラウド、分散コンピューティング関係でも、OpenMPIなど海外製だ
GitもMercurialも海外で生まれているし、OpenCVを初めとした画像認識ソフトやその技術も海外で生まれている
カメラによる画像認識で車や人を判断してブレーキする車は日本で作られるが、その根幹を為すアルゴリズムは
海外の研究者やらエンジニアが作っている訳だ。広大の栗田先生など一部例外はあるけれど。
それぞれ、SIerが言うビジネス（笑）なんか比較にならないほどの市場規模を持っているのに、それらを無視してビジネスとはなんだろうか？ｗ
電機・機械系では、研究開発が盛んで、技術と儲けることは不可分なのに、IT業界だけはどういうわけか
ビジネスとは技術を何一つしらない無知なおっさんが作るものであるらしい
本物のプログラマにとっては、全く魅力がない、そんな業界な訳だ
お客からしたら技術の中身なんかぶっちゃけどうでもいいんです。JAVA で書こうが、Cで書こうが、COBOLで書こうが、そこに価値の本質はないから。
道具というのは、それを適切に選択して使ってこそ価値がある。
フランスではOCAMLが普及しているが、なぜだか考えたことがあるか？
何を選択すればコストが抑えられるかをすら考えたことすらない
言語なんかなんでも一緒？ｗ
なるほど、鋸でなくともノミでも木は切れるだろうなｗ
切断面の美しさやかかった時間などは客には関係ない、切れてさえいればいいかｗ
お客にとっては技術などは確かにどうでもいい、しかし、それを上回る製品がないという前提だ
どうやって世界と伍して戦う？
どうやって他の製品を上回る？
微々たる使い勝手の差などは、技術力の差の前では圧倒的に無力だということは
データベースはオラクルだのSQLに依存し、製品ではSAPなどに完敗を喫し続けているSIerこそ理解すべきだろう
本当にビジネスを作る、というのが、技術と不可分なのは言うまでもない。
もちろん、その技術にはコーディングスキルも含まれている、という当たり前の話です。
オッサン論法でいけば、SIerがサービスとして提供するものと、同一の機能を持った製品との間の明確な区分など
客には存在しない。どっちのほうが凄くて安いか、だ。
そんで、もう、そういう勝負に負けまくってるのがSIer、技術で勝てないから安さで勝負するために
オフショアに必死になったり、ブラック企業化してプログラマを潰しては、ますます技術力とサヨナラしていってるね
http://anond.hatelabo.jp/20140206172641
普通は「IT系」って企業の一部門だし実際日本でも自動車メーカーやら電機メーカーやらゲーム会社やら内部でプログラマーを雇用して国際的な成果も上げてる企業なんていくらでもあるんですよね。
全くだな。
技術力をもった企業やエンジニアがフィーチャーされるべきなんだが、例えばゲーム屋だと
プロデューサーだのディレクターだのが表に出て学生のあこがれの対象になるし、
他もプロマネが表に出てくる事が多いので、文系職の比重の高さが問題なんでは・・・みたいな方向になるよな
大手でもホンダ、ソニー、日立など、研究部門が成果を上げている、中規模でもデンソーとか良い企業もあるし
小さい会社だと、先日googleに買われたシャフトとか、CADのラティスとか、モーションポートレイトなど、固有技術で食ってる会社もある
しかし、そういった会社への就職は一般には要求水準が高くて難しい、
あ、まず前提として、
はたして貴女を幸福にするかどうか、それはまた別問題だけれど。
ＩＴ系の超かしこい男なども多く、
多くっつーかIT系でないのにプログラミング大好き男っていうのは超かしこい学生（まぁこれは有望株）か研究者系なんか、
あとはまったくかしこくもないクセに頭いいつもりして「Lispやってます（ｷﾘｯ ハローワールドくらいですが」とか言っちゃうアホしかいないわけで、
したがって、釣り師たる女たちにとっては、
なかなかあなどれない釣り場です。
では、プログラミング大好き男に「どの言語が好き？」と訊ねられたとき、
まず最初に、その男がCOBOLのようなタイプのレガシーコードと
あとはC/C++、そして（TechEdに参加するほどではないけれど）VisualBasicが大好きな、
貴女はかれの目を見て、微笑みとともに質問など無視して、こう言いましょう、
「わたしが、仕様書を作ってあげる♪」
これこそまさに必殺の答えです。
そこでプログラミング大好き男が、えへへ、とやにさがったならば、
貴女は、ひそかに、「コピペ量産しやすい技術的ポイントを抑えた仕様書」あたりを
ひそかに練習しておきましょう。これで成功まちがいなしです。
しかし、ここでは、もう少しハイブロウな（？）いわゆるプログラミング好きの男の
落とし方をお伝えしましょう。
「わたしは、JVM上のScalaが好き。
型推論もあるしラムダ式やクロージャもスクリプト言語みたいに書けるの、豊富な組み込みのコレクションメソッドはいつも便利だし、
XMLリテラルもCaseクラスによるパターンマッチもTraitベースのMixi-inも、大好き♪」
もしも貴女がそう答えたならば、
かれの貴女への恋心は、
２０％増量になるでしょう。
なぜって、Scalaは、
コンパイルは遅いながらも、そこがまた
ちょっぴりメモリを多く積めばいい富豪プログラミングみたいなふんいきをかもしだしていて。
質高くふるまっていて、なおかつ、
JVM上で動くくせにJavaが「やるやる」と言ったまま実装してなかったラムダ式と仮想拡張メソッド、型推論を実装した功績もあって。
したがってScalaこそは、
本来なんの接点もないまったく縁もゆかりもない別々の世界に生きている、
インタプリタ言語大好きな綺麗系ＯＬと、玉もあれば石も混じっている、そんなプログラミング大好き男たちが、
この世界で唯一（いいえ、JVM系列のJRuby、Clojure と並んで唯三）遭遇しうる場所です。
●
では、参考までに、危険な回答を挙げておきましょう。
プログラミング大好き男に「どの言語が好き？」と訊ねられたとき、
「MicrosoftのVisual Basic for Applicationが好き♪ 週３回は Excelでコーディングするの。」
特にOfficeは平凡ながら、ま、無難にまとめてあるものの、
しかし、「新UIのリボンUI！」「メトロUI対応！」とかなんとか無意味な自慢を吹聴し、
VBAはさらにプログラミングについての謬見を撒き散らした罪がありますから、プログラミング大好き男にとっては天敵なんです。
ティーガー戦車乗りのオットー・カリウスは「ティーガー乗りなら誰でも片側の履帯がはずれ僚車に牽引されて帰ってきた経験を持つはずだ」 って言ったけど
社内SEかSIerなら誰でもクソみたいな前任者が書いたクソみたいなExcel-VBAコードを直した経験があるはずなんです。
また、もしも貴女が「PHPが大好き♪ あたしが書いたPHPのWebサイトが、さくらサーバに７件あるよ♪」
と答えたとしても、同様の効果をもたらすでしょう、
なぜって、PHPは、１９９０年代にはWeb系を目指す人にとっては簡単で要件を満たすWebサイトが簡単に作れる輝きの道だったものの、
しかし２０００年代そうそうから、セキュリティ関係の問題で転落し、
いまや、あの貧弱な言語能力では、Rubyの魅力に遥かに及びません。
（注１）
「わたし、.NET FrameworkのC#が好き、フォームアプリでも書くけど、
最高に好きなのはASP.net♪ SQLServer連携も、ajax control toolkitもすっごくおいしいの。」
と、答えたとしたらどうでしょう？
なるほど、貴女の趣味は高く、
たしかに.NET Frameworkは、C# が cool であるのみならず、
.NET Framework上で動く F# や IronPythonやIronRuby、マネージJScriptも最高においしいんですけれど、
しかし、貴女の答えを聞いて、プログラミング大好き男はきっとおもうでしょう、
（なんだよ、MS信者な女だな、カネかかりそう）って。
（注２）
貴女が、プログラミングが大好きで、言語の名を挙げるにしても、
たとえば、JavaScript(node.js)ならば安心でしょう、
なぜならば、JavaScriptは、かけだしのプログラミング初心者にもマニアにもともに愛されるめずらしい言語で、
貴女がその名前を挙げても必ずしも、(jQueryがやっとの初心者と思われることはあっても)あなたがプログラミング言語おた宣言をしているとは受け取られないでしょう。
むしろ「へぇ。ちゃんとprototypeは使ってる？」と聞かれたら「当たり前じゃない。むしろnode.jsでいいMVCフレームワークが分からないんだけど…」と話を振ってみましょう。
男は嬉々として、３０個くらいのnode.jsのフレームワークを教えてくれることでしょう。（まぁどれもどれで帯に短し襷に長しなんですが）
あるいはRighno上で動かしたコードをnodeへ移植する話とか、CoffeeScript、甚だしきはClojureScriptを振ってみてもいいかもしれません。
しかし、たとえば、世界が（つーか竹内先生とポール・グレアムが）誇る超絶関数型言語の名作、Common Lispにせよ、
selfと書きまくることと海外で使われてることに定評のあるPythonにせよ、
バージョンアップごとに言語仕様が変わり、かなり素敵なものではあるもののobsolatedな罠にはまりやすいRubyにせよ、
まったく読めない$_だらけで頭悪い仕様をリセットしてPerl6にする（そしてまた全く読めない）Perlにせよ、
気さくなクジラ飛行机さんがふるまう素敵においしい日本語プログラミング言語のひまわり・なでしこにせよ、
基地外トリッキー言語の代表BrainFxck・Glass・Missa・WhiteSpaceにせよ、
ましてや貴女が、「Haskellが大好き♪ わたし、プロジェクト・オイラーの問題もうほとんどHaskellで、解いちゃった♪」
と答えたならば、どうでしょう？
これはかなり博打な答え方で、
なるほど、Haskellは、純粋関数型でありつつも副作用のある操作が行える超絶名言語ゆえ、
あなたがそう答えた瞬間、プログラミング大好き男がいきなり超笑顔になって、
「へぇ、やっぱりHaskellなら大抵の問題は４行以内くらいで解いちゃった？」とか言いながら
鼻の下がだら～んと伸びちゃう可能性もあるにはありますが、
しかし、逆に、（なんだよ、この女、プログラミングおたくかよ）とおもわれて、どん引きされる可能性もまた大です、
なぜって、必ずしもプログラミング大好き男がプログラミング大好き女を好きになるとは、限らないですから。
男たちは、女を導き高みへ引き上げてあげることが大好きゆえ、
もしも貴女が、「Haskellが大好き♪」なんて言ってしまうと、
そこにはもはや、男が貴女に圏論のモナドを教育する余地がまったく残されていません、
したがって貴女のその答えは、
プログラミング大好き男の貴女への夢を潰してしまうことに他なりません。
ま、ざっとそんな感じです、貴女の目にはプログラマーたちはバカでスケベで鈍感に見えるでしょうが、
しかし、ああ見せて、プログラマーはプログラマーで繊細で、おざなりに扱われると傷つきやすく、ローカル変数の名前一つにも気を使い、女と自分の将来に夢を持っています、
貴女の答え方ひとつで、プログラマーの貴女への夢は大きくふくらみもすれば、
一瞬で、しぼんでしまいもするでしょう。
●
では、スキットを繰り返しましょう。
「わたしは、JVM上のScalaが好き。
型推論もあるしラムダ式やクロージャもスクリプト言語みたいに書けるの、豊富な組み込みのコレクションメソッドはいつも便利だし、
XMLリテラルもCaseクラスによるパターンマッチもTraitベースのMixi-inも、大好き♪」
そして、その瞬間、プログラミング大好き男の目がらんらんと輝いたなら、
貴女はこう重ねましょう、
「それからね、いま、わたしが使ってみたいWebアーキテクチャは、
Play Framework、素敵なリアルタイム嗜好のアーキテクチャって噂を聞いたから。
あなたのお暇なときがあったら、わたしをPlayへ連れてって♪」
これでもう完璧です。
PlayFrameworkと、Play（遊ぶ・じゃれる）のダブルミーニングでかれの股間も刺激しちゃえます。
そうなったらこっちのもの、
デートの日には、ペアプロ用に Happy Hacking Keyboard をばっちり決めて、かわいい下着をつけて（注３）、
github.comの通販で売ってるoctcatのTシャツか、facebookの「いいね！」ボタンがムネのところにあるTシャツ、 あるいは初音ミク（ないし彼のお気に入りのアニメキャラ。北米ならMyLittlePonyで鉄板なんだけど）のコスプレを着てゆきましょう。
その日から、プログラミング大好き男は貴女の虜になるでしょう。
注１：
（と、書いたもののPHPの現状をよく知りません。グローバル変数だらけになるのとか旧ASPみたいなもんなのかなぁ。count($array); とか書くのアホと思うがpythonも同じだった）
（あと、マジで単機能とかTwitter連携とか診断メーカー的なのでもPHPで７つも作ってる女子居たら付き合いたい）
注２：
もっとも。objective-Cなんていう言語をやることに比べれば個人で行う程度なら金のかからない手法もなくはないのですが。
注３：
プログラマーにとっての「かわいい下着」と、女性にとっての「かわいい下着」の定義にずれがあるので注意。
半数くらいのプログラマーはしましまぱんつが可愛いと思ってる気がするので、妙齢の女性が着用するには抵抗あると思うが、ボーダー柄のコットンショーツ（ただしキャラ絵のは除く）とか、
過度でないていどにフリルがついたものがオススメ。また、色は、レッドだとプログラミング大好き男は引いてしまう（だってそれはコンパイルエラーのときの色だ）ので、薄ピンクかホワイト、薄ブルー、せめて黒（に差し色でピンクとか）あたりに留めたい。
補記：
元ネタ： http://tabelog.com/tokyo/A1301/A130101/13002457/dtlrvwlst/3464106/
補記２：
「プログラマー」か「プログラマ」かの問題については、特に意味は無いが前者を採用した。
補記３：
言うまでも無いけど、ネタです。
