帰って来たプログラミング言語「DT」 : As Sloth As Possible
ゴールデンウィークを利用して久々にろくでもないものができたので晒しておく。 「ごっこじゃないよ、兄ちゃん！」「才能の無駄遣いじゃなくて、無駄そのものだよ、お兄ちゃん。」 前のと何が違うの？ そもそもの発端についてはプログラミング言語「DT」という記事を、実際の言語仕様についてはREADMEでも読んでもらうとして、何で再実装したのかという話。 3年前に作ったのは「Whitespaceのトークンを置換した処理系をインタプリタとしてRubyで実装」したものなんだけど、何を思ったかコンパイルしてみたいと思い立ってしまい、んでそれ自体はLLVMが良く分かんなかったとか、llvmruby自体がプロジェクトとして大分アレな感じになってしまっていたとか、そういう事情で挫折してたんだけど、時は流れ、なんか見返してみたら普通にLLVMアセンブリ読み書きできるようになってたし、ruby-llvmがちゃんと動くよ
UnicornとかRainbows!とかの話 : As Sloth As Possible
随分長いことブログ放置してしまったのだけどネタ見付けたので久々の記事。 UnicornはPassengerより遅かった？ なんかTwitterで「アクセス少ないときはPassengerよりUnicornのが速いのに、アクセス多くなってきたらその逆になった」って話をみかけたので、それ単にUnicornのworkerが足りないんじゃないの、と返したのだけど、どういうことかという話を少しまとめる。 まず、Unicornのworkerは1プロセスにつき1度に1リクエストしか処理しない。だから例えば、凄い大雑把な計算だけど、平均50msくらいでレスポンスを返すアプリだとすれば、1workerは20req/secくらいは返せるかなと見積もって、ピーク時に100req/secくらいアクセスがありそうだったらworkerを5個くらい立てとくかな、足んなかったらもうちょっとかな、みたいに考える。実際どんくら
#isucon で学ぶWebアプリの高速化の話 : As Sloth As Possible
あるいは、お遊びチーム2号は一体何をしていたのかについて。 ISUCONという大変白熱した楽しいお祭を開催するにあたって、その前夜祭的な環境試験のためのチューニング祭が社内の有志数名で行われていて、そのときに色々学んだことをおまけとして書いておきます。 ISUCONて何？ 下記参照。 なんでもありのWebアプリケーション高速化バトル、#isucon 開催のお知らせ 【締め切りました】Webアプリケーション高速化バトル、#isucon 詳細と参加者募集開始 ISUCON に参加してきました #isucon に参加してきました＆isuconツールを試してみました #isucon で優勝してきました isuconに参加してきた＆チーム「いんふらえんじにあー」の戦略など isuconお遊びチーム（事前社内β組）の設定あれこれ #isucon で優勝させてもらってきました #isucon に参加して
RubyでMongrel2のハンドラを書いてみる : As Sloth As Possible
こないだ、と言っても2週間くらい前の話なんだけど、社内でZeroMQとMongrel2の勉強会をやった。Mongrelと言えば、俺がRails（たしか当時1.2くらいだったと思う）で仕事してた頃にアプリケーションサーバとして使ってたけど、最近だとThinとかPassengerとかUnicornとかの人気に押されてついぞ聞かなくなったアレだよなぁ、なんでPerlの会社の勉強会でMongrelなんだろう、と思ってたんだけど、Mongrel2はもはやRailsのアプリケーションサーバじゃなくて、通信にZeroMQなるものを使った汎用的なWebサーバになってたらしい。 大分野心的なプロジェクトではあるものの、今はZeroMQもMongrel2も「とりあえず出た」って感じらしく、今年一杯くらいは地雷原を突き進む気がある人だけ触るといいんじゃないかなという話だった。プロダクションで使うようなレベルにな
Objective-Cのアクセサの話 : As Sloth As Possible
scrollView.canCancelContentTouches = NO; [scrollView setCanCancelContentTouches:NO]; って書き方があってこれみんなどういう使い分けしてるんだろうなぁ。。って思ってます。 セッター - poohtarouの日記 セッターというか、ドット記法の話かな。 ドット記法と普通のメソッドの使い分け まぁ、まずはこんなクラスがあったとします。 @interface Book : NSObject { NSObject *title; } @property (retain) NSString *title; @end このクラスのオブジェクトを作ってtitleを設定/参照するコードはこんな感じです。 Book *book = [[Book alloc] init]; // ドット記法 book.title = @"Dyn
Objective-Cのデリゲートの話 : As Sloth As Possible
「Objective-Cで、参照先のオブジェクトから参照元に通知を送る方法。」を読んてで思ったんですが、若干冗長な気がする。 プロトコルを使う プロトコルを使うんだったら、最初からそのプロトコルに適合するオブジェクトしかdelegateになれないようにしちゃった方がいいと思う。こんな感じで。 @interface Foo : NSObject { id<SampleDelegate> delegate; } @property (assign) id<SampleDelegate> delegate; @end こうしちゃえば、そもそもSampleDelegateに適合しないオブジェクトはdelegateになれないので、conformsToProtocolのチェックは必要なくなる。UIKitでも（例えばUITableViewのdelegateとか）大体そうなってますね。あと、ObjCはレシ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
