RubyはPerl(の処理系のソースコード)より(処理系のソースコードが)綺麗なPerlです。私の手元のUbuntuで「ruby」と入力すると「Command not found.」と返ってくることからも解るとおり、多くの*NIXではOS標準でインストールされておりません。昔のgemは何故あんなにすごい時間をかけてrdocを作っていたのでしょうか。日本人が作ったのでムラ意識の強い日本人の仲間が大勢います。他の国は知りません。がんばってください

*NIX系のOSでミドルウエア的なものを作りたい → なんだそれ？何を作りたいの？

ゲームを作りたい → どんなゲームだよ…

言語 処理系を作りたい → BNF、C

これ以上言語を増やすのはやめましょう。バベルの塔で大勢の人間が不幸になったのに、それを人間が自ら引き起こしてどうするんですか。

言語処理系を作るのであれば、BNFという言語で文法を定義して、yacc・bisonというツールに食わせればひな形ができます。ぶら下がりelseとの格闘が待ってますが、がんばってください

OSを作りたい → C

1から OSを作った方もいますが、デバイスドライバの流用などを考えると、だいたいはLinuxやBSDのソースコードを改変するお仕事だと思います。

残念なことにLinuxもBSDもCです。がんばってください

ブラウザ アプリ用のサーバが作りたい → PHP、Java、C#、Go

昔はCGIと言っていました。所詮は80番ポートでlistenするだけのプログラムであり、BSDソケットをlistenできるライブラリを有する言語であれば何でもいいのですが、いくつかの宗教があります。

PHPはバンドネオンと同じくらい習得が困難な言語なのに、宣伝の仕方を間違えたために「自分はできる」と勘違いしたプログラマが暴徒と化し、イスラム教と同じくらい不当に低く評価されている言語です。きちんと勉強して使う分には、悪くない選択肢だと思います。がんばってください

Javaは、Eclipse・Netbeansといった超重量級IDEを起動して、Java EEやSpringといった超重量級ライブラリに依存したwarを、Jboss・WebSphereなどの超重量級アプリケーションサーバ上で動作させるため、メモリが貧弱な環境ではIDEとサーバを同時に起動すらできません。サーバのメモリが潤沢であれば悪くない選択肢だと思います。がんばってください

C#は、選択肢が全くないことを除けば、状況はJavaとあまり変わりません。Microsoftがお好きな方、何かの間違いでWindows サーバを使わざるを得ない方であれば、悪くない選択肢だと思います。がんばってください

Goはよくわからないですがきっといい言語です。がんばってください

ちなみに増田はcpoll_cppspの勉強中です。がんばります

Permalink | 記事への反応(0) | 10:25

2014-05-24

■Ａ丼屋でのからあげ パーティーのススメ

Ａ丼屋の話セカンドをしよう。5月29日にストがあるという。

※Ａ丼屋とは……赤と黄色をテーマカラーとし、グラデーションの末にブラックな体質を獲得した色見本に忠実な大手飲食チェーンの仮称。安いくせにうなぎがやたら美味いが、従業員は365日不味い思いをしている。

Twitterで絶賛拡散中である。専用アカウントもでき、以前Ａ丼屋と争った某組合的なアレも冬眠から醒めた甲本ヒロトのごとく動き回っている。いやまあぶっちゃけ楽しくて仕方がない。メシウマである。おかずに特製のタレで煮た肉が欲しいところだ。

消費者も行くなよと仰る方がいるが、個人的には従業員でない者はむしろ食べに行けよと思う。客がいなければ苦労がわからないだろう。

個人的なオススメは、からあげを提供する店舗でのからあげパーティーである。

からあげはある程度予測をして揚げてはいるが、大量に注文された場合はやむなく完全受注生産のような形を取る。なにか表現をミスったような気もするが、要は注文されてから冷凍のものを油にぶち込むということである。基本的には混雑に備えて揚げておき、注文が入れば二度揚げをすることになっている。つまるところ死ぬほどめんどくさいのだ。そして時間もかかる。

加えて、Ａ丼屋には主力商品用の豊富なトッピングメニューがある。そしてこちら、単品で注文も可能なのだ。実は結構融通の利くメニュー構成となっている。

明太マヨ、おろしポン酢、溶けるチーズ……などなど、からあげに合いそうなものを単品で頼みまくる。するとどうなるだろう？

からあげパーティー、はっじまーるよーーーーーーっ！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

…………

うまうま。

ストで休んだ従業員は社員に出会さないようにエリア外の店舗へ行くことをオススメする。

さて、スト記念に以前書いたものの補足もしておく。

POSくらいはあるのではないかと思う。注文はファミレスで使うような平ペったい機械で取っていて、おそらくメニューのデータくらいは本社に行っているだろう。ただ食材の在庫管理は機械に手入力した上でそのデータを印刷したものを紙に書き写してファックスするという七面倒臭いものだった。あの機械を重ねてカラテチョップをかましたい欲を太鼓の達人にぶつけていた日々ももはや懐かしい。

人時計算の概念は、なるほど当たり前にあるのだな。井戸なんて人間用に作られているのだからカエルになってしまったら内側から見る摩天楼のように感じられるだろう。例え中身が白馬の王子様でも空は丸いと思ってしまうはずだ。借り物の翼では上手く飛べず真っ逆さまに墜落していったスパイダーとは仲良くなれそうです。余談だけどもやはりカエルのジェットって昭和の子供に＊＊から息を吹き込んでもらうしかないのだろうか。なんの話だ。脱線事故を起こしても取り返しがつくのは文章くらいなものですね。

とはいえそんなところが問題なのではなく、書いた通り目標値設定の話。

当然ながら売上予測に則してシフトは組まれる。この予測が外れて入客数が少なく売上が低かった場合、｢じゃあお前らの労働、30分分無しな｣となる、このシステムがおかしいんじゃねえかと。そういうことが本旨であった。エリア担当社員にもよるのだろうが、この売上目標の達成は容易ではない。バラエティ番組が芸能人に簡単に100万円はくれてやらねえぞというあのノリ。は言い過ぎかもしれないが、ともかく遊び盛りの学生が小遣い稼ぎ程度の気持ちでやっていたのではダメだ。もはやスポーツである。夏場はアクエリアスを裏に常備。気前のいいパートタイマーの主婦の方々はポカリスエットの2Lペットを｢みんなで飲んで！｣と買ってきてくれた。全国大会を目指せるほど実力はなかったが、とても仲の良いチームであった。美人マネージャーでもいれば言うことはな……おや、何か別の(架空の)思い出と混ざってしまったようだ。とりあえずこの頃、バイトはスポーツだと思っていた。ちなみにここでは人使いの荒い偉めな社員をマネージャーと呼ぶ。青春を返せ。

時間帯が4つに分けられているとも書いた。例えば｢昼｣と｢午後｣を例に挙げる。

ある日のことだ。｢昼｣はものすごい混んだ。この時間帯は目標売上を達成することができた。

しかし、少ない人数であったため食器の片付けや洗浄、食材仕込みや集計が間に合わない。｢午後｣の時間帯に切り替わるやいなや勤務者は一人だけになってしまう。ピークは過ぎたとはいえ、｢午後｣であっても入客はある。そして｢午後｣の仕事はそのあとの夕飯時のための食材仕込みが主だ。｢昼｣に向けた仕込みが充分でも、入客が予想を上回ればそのぶん食材も消費される。弾切れ寸前てなところだ。

やることが多過ぎて手が回らない。部活帰りの青春高校生軍団が容赦なく押し寄せ、裏メニューの超絶大盛り商品を複数注文され一気に残り食材が枯渇することもたまにある。一人でそれを2食たいらげるカビゴンにも出会ったことがある。恐れ入りますがお客様、みそ汁キングはございません。あ、3杯分でよろしいですか。おしんこセットですか？こちらおしんこメガでございます。実話である。盛ったのはおしんこメガくらいである。ああ、またわりとどうでもいいほうに……

ともかく、そうでなくとも最低限の仕込みは済ませなければならないし、営業報告書も仕上げなければならないし、大量に下げられた食器も洗わなければ商品の提供に差し支える。やむなく上がる人に延長を頼み、店舗を万全な状態に整えるのだが、するとどうだろう。｢午後｣の時間の売上目標に達しないわけだ。｢お前ふざけんなよ｣と。

先の記事に書いた通り、店長も社員も常駐しない。現場にいるアルバイトだけで勤務延長などの判断はするわけだが、理由を説明しても数字だけを見られ、取り合ってくれない。挙句｢そういうことされるとワンオペの時間が長くなるだけだからな｣とまで言われるのだ。強く出れない心優しきアルバイト達は、30分～1時間程度のサービス残業など日常茶飯事だった。

店側が売上予測ミスって出た損失をバイトの給料削って埋めてるんです連中は。あ、一文で済んだ。

蛇足にすね毛を生やしてその毛を光らせてみるなんてのはレポートの文字数を埋める学生のような滑稽さで御座いますね。猿のように前かがみで手を翳しましよう。せーの、反省！！

「お前が仕事できれば問題ないんだ」と言われればそこで押し黙ってしまう人が多いのだが、いやでもやっぱり働いた分を不当に削られているよね、我々。と、思うわけである。

ちなみに近隣でお祭などのイベントがあり平常時より多くの入客が見込まれる場合でも人数を増やしてはくれない。売上ばかり伸びて使い潰さてる感は否めない。まあさすがにそういうときの残業くらいは社員によっては認めてくれたりするのだけど。

そして与えられている業務は適当だろうか。小型店舗でも20万程度になる売上金を毎朝アルバイトが銀行に入金に行くのもけっこうゾッとするものがある。

10連勤20連勤も珍しくない。ある年の8月は休日が3日しかなかった。ちなみに｢休ませて｣と言わなければ何連勤でも可能である。言っても休ませてもらえない人もいるようだが…… 末端の社員などはバイト以上に使い勝手の良い駒で、足りない店舗を縦横無尽に飛び回り、複数店舗のバイトに電話をかけヘルプを頼み、時にはヘルプ先へ車で送迎、店舗ではバイトと同じ仕事をしながらブラック精神の染み付いた上司に怒られつつ必死に働く姿を見るとチュッパチャップスにVAN HOTEN COCOAを添えてそっと枕元に置きたい気持になる。取り合わせについては不問とする。ちなみにからあげパーティーをやると最初にムンクの絵みたいになるのはこの方々。ファイトマネーでガッチリ！と言う人もいるが精神的摩耗によりコスパは良いとは言えない。

Ａ丼屋で働くためのコツがあるとすれば、会社から自分の身を守るように働くことだろう。ワンオペや入金の際にはボディガードを雇い、混雑しそうな時には適度に人祓いをお願いする。安全に生きよう。

ちなみについ最近知ったのだが、うちの店長はアルバイトだった。

それでは、スト参加者の健闘を祈る。

Permalink | 記事への反応(0) | 00:16

2014-05-04

■http://anond.hatelabo.jp/20140504105600

非表示リストのつづきのつづき

Permalink | 記事への反応(1) | 11:04

2014-04-06

■http://anond.hatelabo.jp/20140406153923

横道に逸れるけどCocoa-Javaが無くなったのはJava側が独自実装を禁止したからであってAppleの判断じゃないよ

Microsoft だってJ#無くしたんだし

Permalink | 記事への反応(1) | 16:03

2014-01-17

■http://anond.hatelabo.jp/20140117000313

元増田です。ありがとうございます。

モデルで発生するイベントが多く、複雑になるほど、ビューとの関連は密になる。
ここの所は、今回の例ではいまいち見えづらい気がする。

たしかに、そうですね…　

攻撃を支持した時点で刀をふりあげて、そのあいだに毒でモンスターが死んだら、納刀する、のような場合では、モデル・ビューの関連が密になる例になるでしょうか。

いや、そのときはModel「刀」をつくればいいのか…

Qtのsignal/slotなんかはモデル同士の通信にも使える

これは知りませんでした。基本クラスのレベルでObserver パターンがサポートされる！しかもタイプセーフ…

Mac OS X のCocoa フレームワークにも KVO という同様の仕組みがありますが、型のチェックは自分でする必要があります。

MOVEの考え方からいえば、モデルの責務が吸い出されて単なるデータになってしまう

MOVEは望まれなかった子 - the sea of fertility

を読んで、MVCを理解した(つもりになった)ので、MOVEの設計方針自体はスルーしていました。

Model から責務が吸いだされて、なくなるのが予定調和なら、OVEでよいのでは

Permalink | 記事への反応(0) | 05:51

2010-11-22

■C言語すら知らなかった云々の記事がちょっとひどい

http://www.lastday.jp/20 10/11/22/objective-c

早速Objective-Cとやらを勉強しようと思ってググってみたら、Objective-CはC言語の拡張なので先にC言語を学ぶ必要があるという驚愕の事実が発覚！

ググる前に公式ドキュメント読もうよ。

この文書はC言語については解説されていないため、C言語にある程度慣れていることが前提となります。しかし、それほど熟達している必要はありません。Objective-Cによるオブジェクト指向プログラミングはANSI Cの手続き型プログラミングとはかなり違っているので、熟達したCプログラマでなくても、さほど不利にはなりません。
　　
Objective-C プログラミング言語　日本語版
http://developer.apple.com/jp/devcenter/ios/library/japanese.html

Cの知識があるに越したことはないけども、どこまで必要かという話になるとごにょごにょ。

少なくとも、Objective-Cを公開している連中が、"Cの手続き型プログラミングとはかなり違う"と言っているのだから、C言語的なコードの流れには（あんまり）ならない（はず）。

それより、フレームワークの扱いに慣れることに重点を置いたほうがいいんじゃないかな。

苦Cで言うところ、文字列やら、ファイルの取り扱いあたりになってくるとかなり微妙で、出来る限り言語機能やフレームワークに任せたい。

ポインタはそりゃ、Python使いが見たら発狂するんじゃないかってぐらいポインタ演算子が出てくるけど、オブジェクトインスタンスは全部ポインタなんだから、いっそ気にしなくていいんじゃない？　それとも関数ポインタとか使いたい？　きっとデバッグが大変だよ。

YouTubeやVimeoで『Xcode tutorial』で検索すると大量のiPhone プログラミングのチュートリアルが無料で視聴可能です！
※動画は全部英語

公式の「iOS　アプリケーションチュートリアル（日本語版）」を読んだ上で言っているのであれば、どこの誰が作ったかも分からない英語の動画が、アップル公式の日本語ドキュメントより優れている点を挙げた上で、その動画のURLを示して欲しい。

英語なんて分からないよ。

初心者にオススメです。この本を読めばiPhoneアプリ自分でも作れるかもしれないと思えるようになります！

オススメってことは必読じゃないのかな？

3.初期投資
Intel Mac + iPhone or iPod Touch + 10,800円

ここから、開発者プログラムの参加費用$99（¥8000程度）を差っ引くと、一冊分しか残らないから、下の方で紹介されてる本が必読なんだろう。

たのしいCocoa プログラミング[Leopard 対応版]
初心者にわかりやすくObjective-Cの事が書かれています。必読です！

こっちが必読？

内容全く知らないで発言するけども、書評を見てみると、Snow Leopardに対応していない旨が書きこまれていて、多少不安。

流行りに乗ってMacbook Airを購入した人は、大抵Snow Leopardのはず。

記事には、"二ヶ月前"からとあるので、少なくとも記事を書いた人はMacbook Airではないのだろう。

自分のアプリの必要な部分だけを勉強すれば、それだけリリースも早くなりますしモチベーションも下がりません。全部網羅しようと思うと開発自体を頓挫しかねません。

遅延評価勉強法の考えで行くと、C言語を先に勉強する必要はなかったと思うけど、どっちなんだろう。

その辺も遅延で気付いたのかな。

英語力がなくてもアプリは作れますが、英語がわかると公式ドキュメントや先にあげたYouTubeのチュートリアル動画も理解できるので簡単な英語くらいはできる方が良いです。

日本語の公式ドキュメントがあるので、是非参照して頂きたいです。

iOS Reference Library日本語版

http://developer.apple.com/jp/devcenter/ios/library/japanese.html

Apple Developer Documentation日本語版

http://developer.apple.com/jp/documentation/japanese.html

日本語ユーザが増えたら、Xcodeのクイックヘルプとかドキュメントとかも日本語化してくれないかなあ。

それとも、実はただの調査不足で既にあったりとか…

Permalink | 記事への反応(1) | 22:49

2009-05-05

■http://anond.hatelabo.jp/20090505013325

自分はMac メインなプログラマじゃないので、ズレたこと言うかも知れませんが……。

何でも良いから動くアプリ作りたいならJavaが良いと思う。

参考書も参考サイトも無数にある。その中にはプログラミング未経験者を対象にしたものも多い。しかもJavaなら将来WindowsでもLinuxでも通じるし、Web アプリなどにも利用出来る。C++様信者の私としては悲しいけど、時代はJavaだ。

ネイティブアプリを真面目に作ろうと思ったら、Objective-Cが基本っぽい（C++ではCocoa使えず、Carbonになってしまう）。

ただ、Objective-Cの参考書・サイトは、C/C++やJavaなんかと比べて絶望的に少ない上、ざっと見た感じCocoaな部分やXCodeの機能とごっちゃに記述されているものが多く、初心者にはとっつきにくい（理解しづらく、書かれている通りに打って動かす以上のことを行いにくい）点が多々あると思うので、まずはCでプログラミング（コンソールアプリ製作）を知っておくのが良いかも知れないです。

何にせよ、プログラミング言語というものは何か一つやっておくのが重要なので、（もの凄ーく悔しいですが）Javaが無難なんじゃないかなーと思います。

Permalink | 記事への反応(0) | 02:25

2008-07-27

■ブラウザオタが非オタの彼女にブラウザ 世界を軽く紹介するための10本

アニオタが非オタの彼女にアニメ世界を軽く紹介するための10本

まあ、どのくらいの数のブラウザオタがそういう彼女をゲットできるかは別にして、

「オタではまったくないんだが、しかし自分のオタ趣味を肯定的に黙認してくれて、

　その上で全く知らないブラウザの世界とはなんなのか、ちょっとだけ好奇心持ってる」

ような、ヲタの都合のいい妄想の中に出てきそうな彼女に、ブラウザのことを紹介するために

見せるべき10本を選んでみたいのだけれど。

（要は「脱オタクファッションガイド」の正反対版だな。彼女にブラウザを布教するのではなく

　相互のコミュニケーションの入口として）

あくまで「入口」なので、インストールに過大な負担を伴うCUI用、音声出力のブラウザは避けたい。

できればプリインストール、入ってなくてもGUI インストーラ付きのブラウザにとどめたい。

あと、いくらブラウザ的に基礎といっても古びを感じすぎるものは避けたい。

Sun好きが『HotJava』は外せないと言っても、それはちょっとさすがになあ、と思う。

そういう感じ。

彼女の設定は

ブラウザ知識はいわゆる「青いE」的なものを除けば、フォクすけ程度は見ている
サブカル度も低いが、頭はけっこう良い

という条件で。

まずは俺的に。出した順番は実質的には意味がない。

Internet Explorer 4（Microsoft）

まあ、いきなりここかよとも思うけれど、「ブラウザ戦争以前」を濃縮しきっていて、「ブラウザ戦争以後」を決定づけたという点では

外せないんだよなあ。機能もOSと一体だし。

ただ、ここでオタトーク全開にしてしまうと、彼女との関係が崩れるかも。

この情報過多な作品について、どれだけさらりと、嫌味にならず濃すぎず、それでいて必要最小限の情報を彼女に

伝えられるかということは、オタ側の「真のコミュニケーション能力」の試験としてはいいタスクだろうと思う。

iCab 3（Alexander Clauss）、OmniWeb 4（Omni Group）

アレって典型的な「オタクが考える一般人に受け入れられそうなブラウザ（そうオタクが思い込んでいるだけ。実際は全然受け入れられない）」そのもの

という意見には半分賛成・半分反対なのだけれど、それを彼女にぶつけて確かめてみるには

一番よさそうな素材なんじゃないのかな。

「ブラウザオタとしてはこの二つは“独自エンジン”としていいと思うんだけど、率直に言ってどう？」って。

Camino 1.6（Camino Project）

ある種のMac OS Xオタが持ってるCocoaへの憧憬と、元Dave Hyatt監修のオタ的な考証へのこだわりを

彼女に紹介するという意味ではいいなと思うのと、それに加えていかにもMac OS Xな

「容量的なださカッコよさ」を体現するユニバーサルバイナリ

「視覚的に好みなソフト」を体現するAqua インターフェース

の二つをはじめとして、オタ好きのする機能を世界にちりばめているのが、紹介してみたい理由。

Mac OS X版Firefox 3（Mozilla Foundation）

たぶんこれを見た彼女は「Safariだよね」と言ってくれるかもしれないが、そこが狙いといえば狙い。

この系譜のUIがその後続くかわからないこと、これがアメリカでは大人気になったこと、

日本ならFlash上でIMが使えなくて、それがブログで非難されてもおかしくはなさそうなのに、

アメリカでそういうのが後回しにされること、なんかを非オタ彼女と話してみたいかな、という妄想的願望。

Safari RSS（Apple Inc.）

「やっぱりブラウザはWeb サーフィンのためのものだよね」という話になったときに、そこで選ぶのは「Konqueror」

でもいいのだけれど、そこでこっちを選んだのは、この作品にかけるAppleの思いが好きだから。

断腸の思いで削りに削ってそれでも「RSS」を付ける、っていうネーミングセンスが、どうしても俺の心をつかんでしまうのは、

その「捨てる」ということへの諦めきれなさがいかにもオタ的だなあと思えてしまうから。

Safari RSSという名前を俺自身は冗長とは思わないし、もう削れないだろうとは思うけれど、一方でこれが

MozillaやOperaだったらきっちりSafari 2と名付けてしまうだろうとも思う。

なのに、各所に頭下げて迷惑かけて「RSS」を名前に付けてしまう、というあたり、どうしても

「自分のソフトウェアを形作ってきたものが捨てられないオタク」としては、たとえAppleがそういうキャラでなかったとしても、

親近感を禁じ得ない。作品自体の高評価と合わせて、そんなことを彼女に話してみたい。

Netscape Navigator 2（Netscape Communications）

今の若年層でNN2見たことのある人はそんなにいないと思うのだけれど、だから紹介してみたい。

NN4よりも前の段階で、ネスケの哲学とか独自拡張路線とかはこの作品で頂点に達していたとも言えて、

こういうクオリティの作品がパッケージでこの時代に売っていたんだよ、というのは、

別に俺自身がなんらそこに貢献してなくとも、なんとなくブラウザ好きとしては不思議に誇らしいし、

いわゆる火狐でしかMozillaを知らない彼女には見せてあげたいなと思う。

Opera 7 Bork Edition（Opera Software）

Operaの「タブ」あるいは「マウスジェスチャ」をオタとして教えたい、というお節介焼きから見せる、ということではなくて。

「終わらない標準議論を毎日続ける」的な感覚がオタには共通してあるのかなということを感じていて、

だからこそもじら組版『和ジラ』最終リリースは日本語パック抜き以外ではあり得なかったとも思う。

「祝祭化したIE専用サイトをdisる」というオタの感覚が今日さらに強まっているとするなら、その「オタクの気分」の

源はBork Editionにあったんじゃないか、という、そんな理屈はかけらも口にせずに、

単純に楽しんでもらえるかどうかを見てみたい。

Amaya 10（World Wide Web Consortium）

これは地雷だよなあ。地雷が火を噴くか否か、そこのスリルを味わってみたいなあ。

こういうTim Berners-Lee風味の妄想をこういうかたちでブラウザ化して、それが非オタに受け入れられるか

気持ち悪さを誘発するか、というのを見てみたい。

lolifox（Altimit Development）

9本まではあっさり決まったんだけど10本目は空白でもいいかな、などと思いつつ、便宜的にロリ狐を選んだ。

IE4から始まってロリ狐で終わるのもそれなりに収まりはいいだろうし、ふぉくす子以降のブラウザ擬人化キャラの影響を

受けた作品でもあるし、紹介する価値はあるのだろうけど、もっと他にいい作品がありそうな気もする。

というわけで、俺のこういう意図にそって、もっといい10本目はこんなのどうよ、というのがあったら

教えてください。

「駄目だこの増田は。俺がちゃんとしたリストを作ってやる」というのは大歓迎。

こういう試みそのものに関する意見も聞けたら嬉しい。

Permalink | 記事への反応(1) | 12:31

「CocoA」を含む日記

■はてブの非表示ユーザが1000超えてた

■b:id:CocoAの安倍晋三を擁護するデマにスターをつけた連中に質問する

■OS X向けアプリケーション（Cocoa Application）制作の情報が少ない

Windowsだけでしか動かなくてもいいからスタンドアロンプログラムが作りたい → (簡単なことだけでいいなら)C#、(メモリ効率が求められるなら)C++

Macのプログラムが作りたい → Objective-C

ブラウザアプリが作りたい → クライアントはJavaScript、サーバは後述

iOSネイティブアプリが作りたい → Objective-C、Swift

Androidネイティブアプリが作りたい → Java

*NIX用の補助スクリプトを作りたい → Perl、Python2、Ruby

*NIX系のOSでミドルウエア的なものを作りたい → なんだそれ？何を作りたいの？

ゲームを作りたい → どんなゲームだよ…

言語処理系を作りたい → BNF、C

OSを作りたい → C

ブラウザアプリ用のサーバが作りたい → PHP、Java、C#、Go

■Ａ丼屋でのからあげパーティーのススメ