タグ

ブックマーク / shyouhei.tumblr.com (13)

  • '10年代のRubyコア用語集

    IRC (あいあーるしー) 「教養チャンネル」とも「衒学チャンネル」とも呼ばれる。ほとんどのタイミングで日史か中欧史か仏教史か英語史の話をしている。たまにRubyの話題になると逆に違和感が… ISeq (あいせく) RubyVM::InstructionSequence のこと。長いので誰も正式名称で呼ぼうとしない。 rubyスクリプトのいくつかある表現型の中でもっとも低レベルな表現。現在、rubyスクリプトからISeqを生成する機能は公開されているが、そのようにして生成したISeqを実行する機能はセキュリティ上の懸念から(作られてはいるが)封印されている。→ AST ID (あいでぃー) 型。rubyレベルでいうSymbolにほぼ相当するもの(ちょっとだけ違う)。objcプログラマーはこれを見てVALUEと混乱しないように。 assn (あさしん) IRCで彼らがアサシンと呼んでいるも

    '10年代のRubyコア用語集
  • #rubykaigi バイヤーズガイド '13

    #rubykaigi バイヤーズガイド ‘13 あえてアマゾンのリンクは貼らないので会場で会おう たのしいRuby 第四版これを買うべき人: 全員ひとこと: ついにRuby 2.0の時代が格的に始まったことを宣言する決定打的一冊であり、必携。今後「情報がないから2.0は不安」などとうそぶくことはこれで不可能になった。テストから見えてくるグーグルのソフトウエア開発これを買うべき人: テストを日常的に書いている人と、テストを書く習慣がない人ひとこと: これはずばり俺が読みたいので買います。こちらからは以上です。白と黒のとびらこれを買うべき人: 「記号と再帰」がおもしろかった人ひとこと: まあなんていうんですかね、形式言語とか好きな人って結局そっちに道を踏み外しちゃうきっかけってテングワールだったりするわけじゃないですか。だからこういうふうに攻めてくるのって変化球のようでいて実はど真ん中だと思

    #rubykaigi バイヤーズガイド '13
  • DeNAに転職します

    宮川達彦さんがCOOKPADでRuby書いてるなら俺がDeNAでPerl書くのもまあありなんじゃないかと思ったので。 よくある質問とその答えQ. 一時金もらえるんでしょ? 200万? やったー! ごちそうさまです A. ねーよ。おまえはいつの話をしてるんだ。そのキャンペーンはずいぶん前に終わりました。 Q. ベイスターズファンだったの? A. 好きでも嫌いでもねーよ。野球の趣味を理由に転職するの必ずしもダメとは申しませんが、俺はそういう類の輩ではございません。 Q. モゲマス作るの? A. 作らねーよ。Mobageだからといって全部のゲームをDeNAが作っているわけでは、実はないのです。モゲマスは違います。 Q. Rubyやめちゃうの? A. やめねーよ。コミュニティ活動に関しましては、むしろ推奨されていると聞き及んでおります。あと当然、素性を隠しておりませんので、俺が何者かは分かった上で

    DeNAに転職します
  • Pythonでおk ─ 書評: C言語によるスーパーLinuxプログラミング

    あのね、このAmazonの内容紹介が あまりにたわけていて ね。 Cライブラリで、効率的にプログラミング! Webアプリの世界ではPHPJavaが格段とポピュラーだが、ハードウェアの操作や ユーザーインタフェース、画像処理などの分野ではC言語でしか扱えないものが多く、近年、現場でのニーズは高い。 書は、プログラミングでの複雑な処理を短時間に組むために用意されたライブラリに焦点を当て、その使い方を解説しました。 データベース・プログラミングからネットワーク、科学技術計算、コンピュータグラフィクスまで、 ライブラリの活用術を身につけ、複雑なコーディングを簡素に実現する。 LinuxのディストリビューションにはUbuntuを採用。 あれですか句読点のところで毎回「なわけねーだろ」とかツッコミ入れる視聴者参加型インタラクティブ漫才か何かですか。SBCの編集会議はよくこれを通したよね。 まあ

    Pythonでおk ─ 書評: C言語によるスーパーLinuxプログラミング
    yokochie
    yokochie 2011/06/21
    扱う範囲広いな
  • 卜部昌平のあまりreblogしないtumblr

    エゴサーチで見かけた反応とそれの感想など 速さのためにはCでないと この誤解は典型的ですねえ。今、申し訳ないんだけど、普通に書いたCのコードと普通に書いたJavaのコード走らせると、普通に書いたJavaのコードの方が速くなるケース、全部とは言わんが案外と多いですよ。なんでかというと、Javaは普通に書いたらJVMが人類の持てるテクノロジの限りを尽くして勝手に高速化してくれる1が、Cはあなたの能力以上に速くはならない。Cは速いJavaは遅いってのは10年くらい前には正しかったんでしょうけどねえ。 なお自分でベンチマークしてる暇なんかないよ!という人はshootout.alioth.debian.orgぐらいは読んでもいいんじゃないですかね。たとえばJavaとCの比較で見れば全体的にいって同じくらいのスピード、いくつかの項目でJavaのほうが速いのが分かる。 組み込み屋はCでなければ何を使うか

    卜部昌平のあまりreblogしないtumblr
  • どうも周知徹底が不足しているようなので再度のお願いとなりますが、C死ね。

    確かにCでしか書けない類のプログラムは存在する(例を挙げるならKernel)が、それはCの存在を赦す理由にはならない。確かにCに輪をかけてさらにダメな類のプログラミング言語は存在する(例を挙げるならC++)が、それはCの存在を赦す理由にはならない。確かにCでしか書けないダメプログラマは存在する(例を挙げてほしければここにおまえの名前を入れろ)が、それはCの存在を赦す理由にはならない。結論:C死ね。 そもそも計算機にできて算盤にできないことなど存在しない。存在しないんだぞ。なのに何故人はプログラムを書くのか。それはオートメーションのためなのであり、奴隷的使役から人類の尊厳を開放して、この地上に楽園を築くためである。まあそこまで大上段に振りかぶって普段から書いてる輩はいないにせよ、プログラミングとは楽をするため、豊かな人生を実現するため、誰かの幸福のために行うものだ。違うか?じゃあなぜプログラ

    どうも周知徹底が不足しているようなので再度のお願いとなりますが、C死ね。
  • 卜部昌平のあまりreblogしないtumblr - 最速の memset64 を求めて 今回のお題は char 幅じゃなくて word 幅の...

    今回のお題は char 幅じゃなくて word 幅の memset 、つまりプロトタイプだと void* memset64(void* destination, uint64_t image, int num_words); をどれだけ高速に行うかという話。なぜ高速化するかというと、塗りつぶす領域がけっこうでかいから。 候補 1: REP STOSvoid* memset64(void* d, uint64_t i, int n) { asm("cld; rep stosq;" :: "D"(d), "a"(i), "c"(n) : "memory"); return d; } 最近の CPU はクソ賢い。そのため、下手に手で loop unrolling するよりも、逆に CPU に「ここはループなんだぞおおお~」というのを明示的に指示してあげたほうが CPU 側が勝手かつ不気味に最適な

    卜部昌平のあまりreblogしないtumblr - 最速の memset64 を求めて 今回のお題は char 幅じゃなくて word 幅の...
  • 卜部昌平のあまりreblogしないtumblr

    Rubyには公式のものだけでも30のブランチに29,385個のチェンジセットがある(執筆時点)。ブランチの1,000倍程度のチェンジセットがあるということは、実際にはブランチとチェンジセットの関係は偏りがあるから、ともかく長いブランチは超長いということがいえる。ちなみに一番長いのはもちろんtrunkで、この枝の長さは20,992リビジョンだ。次点がruby_1_8で、3,328リビジョンある(執筆時点)。 さてこのくらいの規模になってくると、もはや全容を把握するというのは困難である。特にどのブランチがどのチェンジセットから派生したかという情報は、もちろん個別には取り出すことは可能だが、俯瞰するのが困難になってくる。実際、今回ちょっとしたことでgit rebaseしようとしたらrebase先を間違えてしまい、ものすごく太古の昔からrebaseされてしまいげんなりするという体験をした(俺が

    卜部昌平のあまりreblogしないtumblr
  • Ruby + ARToolKit なバインディングを書きかけています件

    (画像はハメコミ合成ではありません) 事情から説明すると以前から島根で Ruby合宿 とかいうのがあって、今年は講師で呼ばれたわけだ。 んで「なにか発展的な内容を」と言われたので、それならデバイスアートで拡張現実でニコニコ技術部でしょとか思っちゃったのが運の尽きで。 いや ARToolKit はそれはそれでいいとして、お題目がRuby合宿であるがゆえにARToolKitで完結してよかったねーでは当然ダメで、なんとかしてRubyが絡まにゃいかん。 というわけでとりあえず合宿当日までに俺がARToolKitRubyバインディングを突貫で書いて当日合宿所でいきなり使いましょうという。ここまでくると俺講師なんだか合宿参加者なんだかよくわからんよな。 ところが面白いものでというか、ARToolKit自体はよくできていて、APIデザインを悩まなければ(まあ悩むんだけど)、わりとバインディング自体は素

    Ruby + ARToolKit なバインディングを書きかけています件
  • Ruby 1.8.7 リリース方針まとめ

    そろそろリリースするから今の方針をまとめておくよ 無保証の大前提音と建前を華麗に使い分けるおまえらのためにこれは建前だとあらかじめ宣言しておくけれど、 Ruby 体がなんらかの保証を行ったことは過去にもないし将来の予定もない。おまえらの用途にあうかも (fitness for a particular purpose)、商用利用の可能性についても (merchantability)、明確に COPYING で保証しないことを記しているし、それ以外のあらゆる保証もやはりない。だから社会的責任(笑)とかも、ない。 ともかく少なくとも表面上は俺がやってるのはただのおせっかいに過ぎないことをおまえらは注意しておく必要がある。たとえば最近の俺はかなり注意深く「サポート」という単語を回避する傾向にあるけど、それはなぜかというと COPYING の範囲を逸脱する状況に陥ると俺の手に余るからだ。Rub

    Ruby 1.8.7 リリース方針まとめ
  • 今回のiPhoneの件は要するにAtariショックを避けようとしてるんだと思うと色々と腑に落ちてくるものがある

    今回のiPhoneの件は要するにAtariショックを避けようとしてるんだと思うと色々と腑に落ちてくるものがある つまりAppleがやってるのは露骨な任天堂の猿真似ってわけね。DSでFlashが動くかよって話。 いやもちろん、我等が偉大なる任天堂様のなさる審査とAppleの杜撰な検閲を一緒にしないで頂戴、とかの質的な議論はありうると思うんだけども、じゃあといってDS向け同人ゲーをコミケで頒布させろとかの声がマジョリティとかには絶対ならないというのは、やっぱゲーム業界は痛い目見た経験を生かしてるからなんじゃないの。 だからさ、実はAppleはおまえらプログラマを切り捨てているように見えるけど、当は逆で、あれはおまえらを保護しようとしてるんじゃないか? クソゲーとかから。そう思うとあながち逆噴射な発想じゃないとおもうんだよなー 以上まったく根拠のないチラシの裏でした。

    今回のiPhoneの件は要するにAtariショックを避けようとしてるんだと思うと色々と腑に落ちてくるものがある
  • [ruby][howto]クラスを生成するクラスの作り方

    Rubyな話。 「とあるオブジェクト群はそのなかでクラスタに分かれていて、クラスタごとに振る舞いが違うんだけど、そのクラスタの数が不定」という状況がたまぁ〜にある。Ruby なおまえらがよく知っている例としては Active Record パターンとかはそう。Active Record パターンだとオブジェクトは DB の行で、したがって振る舞いは DB のテーブル(かビュー)によって決まるんだけど、Active Record の基底クラスを設計している段階ではどんなテーブルがあるかなんてのは当然すべてのパターンを網羅的に作成しておく事はできない。 んで、Rails についてくる ActiveRecord::Base だと、そのへんはかつては「クラスが継承されたときにそこにフックして派生クラスに実装を注入」というインド人もびっくりの力技で解決されていて(今見たら今はそこまでじゃないが)、ま

    [ruby][howto]クラスを生成するクラスの作り方
  • 俺の .screenrc が火を吹くぜ

    たまにはこういう生産性のない話題もいいよね! さて、まあおまえらも GNU Screen くらいは使ってるとおもうわけだが。こいつがまたひどいバッドノウハウでさあ。ほとんどの人が他人の .screenrc をコピペしてきて済ませちゃうんだよね。俺くらいカスタマイズして使ってるやつとか見かけないわけよ。当に。CodeRepos 見ても俺に比肩する規模の .screenrc 書いてる奴はいないもん。で、たまーにプロジェクタに表示して見せたりすると「それどうなってるんですか」とか。まあ一般人のおまえらは info なんか読まないよね。そうだよね。 でも今日は気が向いたから line-by-line で何が起こってるか解説しちゃうよ。 .screenrc の前にスクリーンショットの解説をちょっとだけ これが普段俺が使ってるノート PC の画面である。これで全画面。OS は普通の Ubuntu で

    俺の .screenrc が火を吹くぜ
  • 1