MacでC#導入メモ

最近のゲームエンジンの流行はC#(Mono)で
Macでも使えて損はないので、Unityが内包してるとはいっても手軽に動かしたいじゃないですか

mono

Download - Mono http://www.go-mono.com/mono-downloads/download.html
MDKいれる

動かす

対話インタプリタがある

$ csharp
Mono C# Shell, type "help;" for help
Enter statements below.
csharp> var x = 3;
csharp> x
3
// hoge.cs
var s = "Hello C#";
Console.WriteLine(s);
$ csharp hoge.cs
Hello C#


ir でironrubyらしいけど動かない

$ ir
Cannot open assembly '/Library/Frameworks/Mono.framework/Versions/3.0.3/lib/ironruby/bin/ir.exe': No such file or directory.

ついでにF# もいれる

cd Downloads/FSharp-2.0.0.0 
$ wget -O mono.snk http://github.com/mono/mono/raw/master/mcs/class/mono.snk
sudo ./install-mono.sh
mono bin/fsi.exe --gui-

微妙にハマったところ

asによるキャストは例外飛ばずにnullが返る
C風のキャストは例外飛ぶ

1996年、「インターネットの兄貴達」に憧れた小学生と「調子に乗るな、背伸びをするな」と叩き続ける人達の話

今回は個人的な話が多いので、あまり理解されるとは思わずに書いた。
早い話、小学生の頃から中二病の生意気なマセガキだった。ということに尽きる話なのだけど…

関連

都心住まいの価値とは何か - よそ行きの妄想 http://d.hatena.ne.jp/chnpk/20130115/1358204323
地方都市という地獄 あるいは関東圏の「私が住んでるところは田舎だよ(笑」が如何に残酷かについて - mizchi log http://d.hatena.ne.jp/mizchi/20130115/1358216244
都会と田舎の比較の話が出るととりあえず絡みつく - 24時間残念営業 http://lkhjkljkljdkljl.hatenablog.com/entry/2013/01/15/143959
大阪「・・・・・。」 http://anond.hatelabo.jp/20130115193455

反響に対して

先の記事は、「田舎で受け入れられなかった人」へ向けて書いた話しであり、受け入れられた人にとっては田舎は辛い場所ではない。住めば都。住めなければ、追い出される。追い出した側は追い出された人のことを忘れる。受け入れられた側がそれを全てだと思っているのなら、その排他性は今でも僕が忌むべきものだ。


概ね田舎の閉塞感に関して同意を得られたものの、田舎育ちと出生地で育つことを混同しているという反論があった。まあそのとおりだと思う。正直「東京の異常性」というタイトルにしたほうがよかったと反省はしている。


大阪については、関西の事情には疎いので意図的に無視したところはある。ただ書きながら大阪はどうなんだろうとは考えていた。

1996年に田舎でインターネットをやるということ

色々言いたいこともあるが、今回はこれについてのみ。

PCユーザーで、かつネットから自主的に情報を拾ってこれる時点で、すでに精神的にはある程度「田舎」というものから切り離されてしまっている、とはいえる。なにしろ「知ってる」わけだ。都会がどんな場所であるか、田舎がどんな場所であるか。


これに関してはもう全くコンビニ店長の言うとおりで。


自分は6歳の時に家にインターネットが導入されて、それにどっぷりはまっていた。近所にパソコン通信とかやってたおじさんがいて、親父がその人と仲よく、親父も当時からマカーだったのでインターネットが開通した。そして主に自分がPCを専有していた。


当時のインターネット('96)は今より大分排他的で、まだパソ通ニフティ掲示板由来の人たちが幅をきかせていて、年齢を明かすと厨房・消防は出て行けと言われたものだった。僕は萎縮して一度もあめぞうには書き込めなかった。あめぞうだったか確たる記憶はないが、2chに連なるあの雰囲気はそうだったんだろう。

「インターネットの兄貴達」は排他的で、ゲスくて、コミュニケーションの取り方がどこかおかしいようには感じていた。ただ彼らはいつも正直で、だからこそ僕は彼らが楽しそうに語るものについてはある程度信用しようと思った。「建前がない大人の情報」を手に入れる手段は、インターネットしかなかった。

小学生ながらにインターネットの価値基準を導入すると、そんなもの田舎の価値観と食い違いが出るに決まってる。当時にインターネットを始めたことが、自分にとってすべてのはじまりだったと思う。

なぜ今この話をするか

僕が2008年に受験を終えてインターネットを再開し、Twitterをはじめたとき「インターネットの兄貴達」はそのままそこにいた。初期Twitterギークネットウォッチャーが大半を占めていた。あんまり自覚はなかったけれど、僕は多分、彼らに憧れてプログラムを書き始めて、そしてエンジニアになったのだと思う。


インターネットに順応しすぎたせいで、地元では生意気なガキとして疎まれた。そもそも郷土ルールとか度外視した知識量だけなら、田舎育ちの大人よりインターネットに順応した小学生のほうが多いケースだってある。そして小学生は建前を知らないから、インターネットで知った知識を使って大人に食って掛かる。アレって実はアーいうことなんでしょって。そして情報を追い求める姿勢そのものが否定される。またあの子はパソコンばかりやって。そんなんじゃマトモなおとなになれませんよ。ちょっと知った気になりやがって。


インターネットの情報を全部信じるのも危ないが、インターネット勃興期は押さえつけられた反動とも思えるような情報が一気に噴出していて、どれも少なくとも地元のオヤジたちが語る情報の100倍信憑性があった。



分別がついてきて、情報の取捨選択ができるようになり、長崎の平和教育がいかに歪であるか知る。偉そうにしてる教員が縁故で選ばれて、教師になるのが夢だった近所のお姉さんが夢を諦めたことを知る。担任の教師が日教組を批判して離島に赴任することになったことを知る。実家の宗教が外部的にどう思われているか知る。そしてその事実が知らされないことに再び怒りを覚える。

僕は知ることが大人になる道だと思っていたが、どうやら無批判になることが大人になることらしい。


たしかそんなことを、小学生のときは考えていた。目下の敵は教師、とくに体育教師だった。体育教師は目上のいうことを聞かず、うんちくを語る生徒が大嫌いなのだ。


今でもそういう怒りはある。田舎だとより身近で、都会だとそれは紛らわしくややこしく遠くなるがゆえに、距離が遠いだけというのも理解している。でも結局身の回りの以上のことに手を出すのは難しいし、僕もまた麻痺してしまったのだろう。


まあ、色々あって、最後何を言いたいかわかんなくなったけど、こういう価値観で田舎で生きていくことは難しく、僕みたいな人間は、東京ぐらいしか受け皿がない、ということだ。

地方都市という地獄 あるいは関東圏の「私が住んでるところは田舎だよ(笑」が如何に残酷かについて

都会に住む人間は、その価値を過小評価している。というのが僕の持論だ。そしてそれは東京に6年住んでより強固になった。

都心住まいの価値とは何か - よそ行きの妄想 http://d.hatena.ne.jp/chnpk/20130115/1358204323


この記事の感想としては、およそ渋谷に特徴的な衛生問題が多いという事実には同情するとしても、常になにかしらの機会が与えられていることを無自覚だ、という点が地方の人間を刺激するだろう。

子供用の自転車が買えなかったとしても、買える距離に生きているのだ。さすがに子供用の自転車ぐらいは田舎でもみつかるが、嗜好品の類はそもそも手に入るかが怪しい。
今ではインターネットで緩和されたとはいえ、それを実際に目にする機会があるかという点において、それを好きになる機会すら与えられないかもしれない。



表題は、地方出身者を最も怒らせる一言である。
僕は、18歳まで長崎県長崎市諫早市で過ごした。諫早市に12年、長崎は6年。諫早は干潟の干拓で一時期話題になった市。
僕は自分の育った街、領域を田舎だと認識している。


田舎には選択肢がない。大小の違いはあれど、大きな意味でたった一つのコミュニティしかなく、何も隠すことができず、常に監視されているともいってもいい。
大人になっても上司は中学や高校の先輩なのはザラ。高校の時にしでかした失敗は、大人になってもずっと周囲の人間が言いふらすから消えない。彼女の元カレ事情とかも聞かなくて知ることになる。誰が誰をどこでナンパした、とか明日の昼には知れ渡っている。就職も東京よりはるかに縁故で決まりやすい。長崎には造船所のせいで市民の1/10は三菱と関係があるし、ちょっと前まで三菱社員は三菱の車しか乗れなかったと聞く。Amazonが届く時間も1~2日遅れ、送料も一回り高い。


なにより学校の縦社会がいつまでも継続される地獄。

光都市だしオシャレなのでは

その都市に住んでいる人ほど、観光の欺瞞にはほとほと呆れている。
出島は本当になにもないくせに、交通の要衝を塞いでいるために邪魔でしかない。オランダ坂はレンガ造りの坂以上の価値はなく、その程度そこら中に溢れている。名前が付いているからランドマークになっているだけだ。

なにか変わった心理があるとすれば、地元の高校生は土産物の安いカステラを買って帰る修学旅行生や観光客を馬鹿にしている。地元では贈答用に福砂屋のカステラが圧倒的に主流で、それすら特別なものではなく、羽田で買えるという事実を皆知っている。

原体験

僕は基本的に自分の街を恨んでいた。その原体験は東京限定だった「ミュウの配布イベント」に行けなかったところが大きい。そのイベントにいきたいと親にねだったことがある。だが子供の駄々に東京まで連れて行ってくれる親などいない。
当時、みんなセレクトバグから生成したミュウには飽き飽きしていて、オリジナルを欲しがっていた。が、そもそもコロコロの懸賞であたる確率は低く、確実に手に入れるためにはイベント会場にいくしかなかったのだ。そもそも懸賞が当たるものだと誰も思ってなかった。
(という記憶があるので調べてみたが、ミュウを配布する、と事前に告知したイベントはなかったらしい。なにか他のイベントと混同している可能性がある)
ミュウ - Wikipedia http://ja.wikipedia.org/wiki/%E3%83%9F%E3%83%A5%E3%82%A6

田舎には選択肢がない

そもそも機会が与えられないのだ。表題の言葉が神経を逆なでするのは、それを発言している人が、都会に行こうと思えば行ける、という事実にある。機会が与えられている。そもそも都心へ一時間でアクセスできる、のに対し、こちらは駅に行くまで一時間かかったりするわけだ。

田舎では画一性を求められるし、そこからはみ出した人間は後ろ指をさされ、ああはなるなとコミュニティの存続に利用される。東京以上に綺麗にアッパーとアンダーにわかれている。


東京は例外だ。そこかしこが匿名で、まるでインターネットだ。
新しいコミュニティなど無限にあるし、いざとなれば逃げ出すこともできるだろう。田舎では「そいつは価値があるか、ないか」の二分でしかないのに対し、東京では「そいつは何の価値があるか」を問うてくる。その点でどれだけの汚点があれど十二分なのだ。


実名主義の人は、一度田舎で無価値なものと足蹴にされてみればよい。その孤独と無力感は、筆舌に尽くしがたいものだから。
僕は進学校だったから他称「変」だとしても許容されたが、そのまま大人にはなれなかっただろう。僕は除外される予定の人間だった。自分のやりたいことに忠実だし、発言をオブラートに包まない。僕ぐらいの人間はインターネットをみてればたくさん転がってて奇人というにも烏滸がましい程度だが、そういう人間ですらそうなのだ。
あるいは、大人になるために画一性を受け入れるという必要があった。それはアイデンティティの喪失であり、田舎はより小さいアイデンティティしか受け入れない。はみ出したものを容赦なく除外する。


お前の言う田舎は甘い、という意見もあるのは予想できる。長崎市は人口40万人。だが、人口40万にですらこうなのだ。より小さい都市はもっと熾烈だと容易に予想できる。

ST2の中でGitDiffを視覚化するGitGutterが死ぬほど便利だった

jisaacks/GitGutter · GitHub https://github.com/jisaacks/GitGutter
一見に如かず。


Install

Package Control: Install Package > GitGutter

ちなみに自分のST2のgit周り

git, gist, githubinator, sidebargitが入ってます

非同期呼び出しの見た目上の同期を実現するためにnode-fibers 使ってみた

laverdet/node-fibers · GitHub https://github.com/laverdet/node-fibers
ネタ元としてはRubyのFiber。

他のcontrol flow系とは経路が違って、V8を直接叩いて実装されている。よって普通のJSの直感から反した挙動を取ることが可能となっているし、nodeでしか動かない。

インストール

いつもの

npm install fibers

使い方

sleepの公式サンプル

var Fiber = require('fibers');
function sleep(ms) {
    var fiber = Fiber.current;
    setTimeout(function() {
        fiber.run();
    }, ms);
    Fiber.yield();
}

Fiber(function() {
    console.log('wait... ' + new Date);
    sleep(1000);
    console.log('ok... ' + new Date);
}).run();
console.log('back in main');

Fiberブロックの中が見た目上同期している。

特徴

他のcontrol flow系ライブラリの when ~ then ~ といったコールバックをキャッチする煩わしさから解放される。かわりに同期的に呼び出したいプロセスをFiberで囲う必要がある。

Fiber.yield が呼ばれると Fiber.current の run が呼ばれるまでは次の処理を止める。

オレオレスニペット

これぐらいラップしてしまうと意識せず使える(気がした)

Fiber = require('fibers')
Block = (main) ->
  sync = (f) ->
    fiber = Fiber.current
    f (-> fiber.run())
    Fiber.yield()
  Fiber(-> main(sync)).run()

Block (sync) ->
  console.log '1'
  sync (done) ->
    setTimeout (-> console.log '2'; done()) , 300
  sync (done) ->
    setTimeout (-> console.log '3'; done()) , 300
  console.log '4'

1,2,3,4と順番に出力される
非同期ならば 1,4, (2 or 3) となるはず

大学で時間かけてゆっくりプログラミングを独学してみた経験から汚いコードについて考えてみようとした

思いつきで色々書く回ですよっと。

を、読んで自分の経験からどう捉えるべきか色々考えてみた。

まず、自分は、無駄が多い勉強をしてきたのだけど、何をどうやって覚えたか、その話からしようとおもったけど、殆どの人はあんまり興味ない気がしたので「思ったこと」以降だけ読めばいいです。

前提

小2(1996)の頃からインターネットしていた
中学生の時にはネットで見つけた記事みて親父のPCのAdmin権限を書き換えたりしてた
プログラミングはできない。あくまでツール拾ってきて使えるだけ

~ 1年目 ~

Twitterをはじめた

エンジニアの知り合いが増えた。エンジニアって楽しそうだなと思った。

大学でJavaならった

そんで家でウェブサイト作ろうとしてTomcatで挫折

Ruby on Rails

1.2から2.0の移行期に巻き込まれ挫折した

集合知プログラミング

集合知アルゴリズムは忘れたけどPython覚えた
Pythonが手に馴染んで最低限の基礎は覚えた

あいてるマシンにUbuntuいれてみた

Linux経験。まともに動かなくて何度も再インストールを繰り返した
コピペでシェルコマンドを入力しているうちにUnixコマンドを覚えた

~ 2年目 ~

Emacs

プラギン漁ってUnix文化的なものを覚えた

Vimperartor

Firefoxいじり回せるようになって生活とプログラミングが直結した

大学のサークルのHP作成

Wordpressのテーマ作ってHTMLとCSS覚えた

~ 3年目 ~

趣味Webサービスつくってみた

Python/FlaskというSinatra系のアプリを使ってたので自前でいじることになって色々覚えた
VPS、セッション、DB、キャッシュ、ルーティング、MongoDB、XSS

某研究所でバイト

MeCab用辞書作ったりとかで自然言語処理っぽいことを少しやってた。はじめてコード書いて金を貰った経験。
周囲が優秀すぎてあんまり力にはなれなかった

Vim

小指が弱かったので覚えた

~ 4年目~

某IT企業でバイト

インターンだけでチーム開発やったんだけどお粗末すぎて破綻
チーム開発とかリファクタリングとかテスト駆動とかバージョン管理とか意識するようになった

オンラインゲーム作ってみた

就活の技術アピール用にWebSocketでネトゲ作ってみた
ちゃんとリファクタリングしてたんだけど、そもそも設計が破綻してたので爆発、メンテできず
この間、CoffeeScriptとNode.jsを使い込んだ

~ 5年目 入社 ~

最初のプロジェクト

Gitを使い込まされ、レビュー基準を叩きこまれ、ペアプロで思考フローを叩きこまれ

今のプロジェクト

クライアントサイドの設計とか、フレームワーク選定とか、見積りとか
JSで破綻しない設計をひたすら考える係

思ったこと

で、即戦力とか、綺麗なコード、汚いコードについて考えてた。


設計とか、綺麗なコードとかは、必要に迫られないと覚えない気がする。自分も自分が作ったコードの設計が破綻して考え始めたので、むしろIT企業の新入社員とかは破綻したコードをなぜ破綻したか考えるところから始めたほうがいいのかもしれない。

自分もまだ綺麗なコードを書けているとは言いづらいが、そこは会社のコードレビューでだいぶ救われてるし、あらゆるコードはレビューされるべきだと思う。

思うに、綺麗なコード、汚いコードってのは、そのタスクに掛けた時間ではなく、その人固有の体質みたいなもので、経験の賜物だから、心構えとして汚いコードでいい、って言っちゃうと後々含めてその人への悪影響が大きい。皆そこに拒否反応を示しているのだと思う。

あと、皆たぶん勘違いしているのだとおもうのだけど、優秀な人が近くにいても、彼らは別に教えてくれるわけじゃない。彼らが教えてくれるのはコードの内側に宿る文化とか、ライフスタイルだったりとか。

自分のケースの話だけど、目的を明確にしないと学習が散漫になるが、実際に必要なのはその過程で身につく周辺スキルだったりする。自分は効率が悪い勉強をしたが、その過程で得たスキルは全部血肉になっているし、無駄だとは思っていない。

初心者相手に勉強会でりゃいいやんみたいにいう人はいるけど、本当に勉強したかったら公開資料だけみてりゃいいし、本当の学習段階でモチベーション以上の理由でいく必要はあんまりない。
ググって解決できる問題解決力は必要なんだけど、ドンハマりすることあるので、そこでヘルプしてもらえるかってのは重要かもしれない。


という思いつきずらずら書いた。

JSのMVCについて考えてみた ~ その2 テンプレートエンジンの分業とパフォーマンス

この前の続き。相変わらず思いつきでつらつら書いてて図とかまともなサンプルとかない。

JSのモデルには二種類ある

フロントエンドである以上本質的にすべてビューだとも言える。
であるがゆえにあやふやにしないほうがいい。

ビューモデル

UIの状態を示す属性。選択しているタブとか、開いているダイアログとか、そういうものの状態をDOMから読むのではなく、JSとして一度確定し、その結果をビューに反映すべきだ。激しく画面を組み替える場合はビューというグローバル変数はどこからも汚染される可能性がある。

データベースのローカルキャッシュ

たとえば、a地点からb地点の距離をユークリッド距離を求めるのに、わざわざサーバーに問い合わせるのは無駄。普通に三平方の定理で計算すればいい。アクション性が高いものほど、ここの振る舞いは分厚くなる。いわゆるHTML5アプリはここを重点的にやるほどサーバーの負担が減り、サーバーレスポンスを必要としないことで、表現的な自由度も高くなる。
基本的な考え方は「サーバーで起こってるであろうことをシミュレーションする」。この場合でも、定期的にサーバーにデータを問い合わせて同期をとる必要がある。
このレイヤーは、nodeで汎用的に書いて同じコードが使えたら嬉しかったりする。

クライアントサイドにおけるテンプレートエンジン

「クライアントのテンプレートエンジンの高速化」は、サーバーサイドにおけるテンプレーティングの速度とは全く別の軸で考える必要がある。サーバーサイドでは純粋に文字列操作だが、クライアントにおけるテンプレートエンジンはDOM生成コストが絡んでくる。Mustacheであろうがhaml.jsであろうが、結局のボトルネックはDOM生成部分になる。ネットワークIOの前では動的言語と性的言語の速度差が吹き飛ぶのと同じだ。

もっとも高速なのは、JSの変数に突っ込んでキャッシュしたDOMを直接操作するパターン。だが、よっぽど注意しないとメンテナンスが不可能なコードになる。経験上、自分以外が書いた、id探してデータを突っ込む以上のDOM操作は、まともに読めた試しがない。jQueryのDOM操作が三行以上続いてると思考停止する人も多いだろう。自分もそうだ。

ビューバインド付きのMVCフレームワーク

KnockoutとかAngularとかのこと。
経験として、開発効率を優先すると大きなビューになり、パフォーマンスを求めるとビュー(テンプレート)が分割されていき管理が難しくなる。これもトレードオフ。たとえば、パラメータ一つだけを書き換えたいのに、それが大きな画面に属していた場合はその全部を再描画する必要があったりするケースがある。関連するモデル粒度だったり、ビューの粒度を適切に分割するのは至難の業で、特にプログラミング初期はとくに見積もれないケースが多い。

誰がテンプレートを書くか?

こんな定義があったとして

//ステータス画面更新規約
var Status = {
  hp: 100,
  mp: 25
}

Statusによって展開されるMustacheテンプレート

<div id='hp'>{{hp}}hp</div>
<div id='mp'>{{mp}}mp</div>

これはJSヘヴィなアプリの場合、JSエンジニアが書くべきか、マークアップが書くべきか。
iterableだったり分岐が激しいテンプレートな場合、マークアップ側に負担が大きくなる。この傾向は、Angularのようなリッチなフレームワークを使うとより顕著になる。
フロントエンドはどうしてもマークアップドリブンになりがちだが、画面設計の際に必要なパラメータの洗い出しはJSを書く人も参加しておいた方がいい。テンプレートを展開するパラメータをマークアップ側が用意できるのが理想だが、ロジックを知らないとすぐに出せるデータ、出せないデータの区別ができず、片方だけでは苦しい。うまくコミュニケーションして連携するしかない。

リスナーイベントはプロシージャルな名前であるべき


ただ、ここで問題になるのはDOMに貼られたリスナーイベントをどう扱うかだ。
id名をRPCと捉えてDOMからは極力情報を受け取らない、という方向性が望ましいと思う。
HTML5のリッチなモデルレイヤーをもったJSは、ほとんどビューモデルとモデルが使えれば現在の状態は確定できるはずだし、またそうではない場合そうなるようにする必要があると思う。

ボタンを押したから、「ここでDOM上の数値が10だから…」とjQueryでDOMを読みに行ってはいけない。簡単なDOMならいいが、DOMが情報を持つとグローバル変数のように扱われててどんどんメンテできなくなっていく。

HTML/DOMはグローバル変数だ。可能な限り状態を持つべきではない。リスナーイベントのid/class名はプロシージャルであるべきだ。

$('#button_add_hp').on 'click', => @status.add_hp()

たとえばこんな風に