んで、結局JS Girlsってキラキラしたいだけなの？
俺はLindaたちがなにをあそこまで思いつめてRailsGirlsを始めたか完璧には理解していない(し、そもそも「完璧な理解」って存在するのか?)が、ひとつ理解しているのは、RailsGirlsはべつにRailsやりたい女子じゃないという点だ。Railsはたまたまそのへんに転がってたからチョイスしただけ。本当のゴールは女性へのツールとコミュニティの提供を通じて、在野の女性のアイディアを実現する事にある。不勉強で日本の事情はよく知らんけど、本家はそういうことになってる。だから本当にRailsGrilsのRailsってのはウィキリークスのWikiくらいどーでもいいんですよ。今後たとえばRailsいけてなくねってことになったらRails捨ててexpress.jsなりに移っても、RailsGirlsのミッションはいささかも揺るがない。 RailsGirlsってのはアファーマティブアクションですよ。
Visualizing git blame
Git には git blame というコマンドがあり(他のツールでも同様の機能は提供されている)、これを使うことでソースコードのどこを書いたのが誰か、という情報がline-by-lineで取得できる。この情報は行単位なので一次元の情報だけれど、適切な空間充填曲線に乗せることで二次元にマッピングできて、それに適当に作者ごとに色をつけるということをやってみると色々楽しい。そのスクリプトはひじょうにstraight-forwardな記述だとこういった感じになる。上の絵はruby 1.8.7に対する実行結果で、ChangeLogとかのあきらかに面白くないファイルは除外してあるからまあ、そのままの結果ではないけれど、これを見ると色々な思いが去来する。 Ruby 1.8.7 は多数の開発者が手を入れており、少数の支配的な貢献者といったような存在をみいだすことができないしかしながら、全体がのっぺりと灰
#rubykaigi バイヤーズガイド '13
#rubykaigi バイヤーズガイド ‘13 あえてアマゾンのリンクは貼らないので会場で会おう たのしいRuby 第四版これを買うべき人: 全員ひとこと: ついにRuby 2.0の時代が本格的に始まったことを宣言する決定打的一冊であり、必携。今後「情報がないから2.0は不安」などとうそぶくことはこれで不可能になった。テストから見えてくるグーグルのソフトウエア開発これを買うべき人: テストを日常的に書いている人と、テストを書く習慣がない人ひとこと: これはずばり俺が読みたいので買います。こちらからは以上です。白と黒のとびらこれを買うべき人: 「記号と再帰」がおもしろかった人ひとこと: まあなんていうんですかね、形式言語とか好きな人って結局そっちに道を踏み外しちゃうきっかけってテングワールだったりするわけじゃないですか。だからこういうふうに攻めてくるのって変化球のようでいて実はど真ん中だと思
#naruhounix について
どうなんですかねえ。まあぶっちゃけ、この本にツッコミを入れることが容易な種族はいる。たとえば「プロセスがfork(2)するときにPOSIX semaphoreをsem_wait(3)してたらそのセマフォはどうなってまうの？」とかそういうの(実際書いてない)ね。けど、それって、そういうの目ざとく気がついてしまう人、はっきりいって対象読者じゃないというべきだろうなあ。LinuxとBSDのカーネルコミッターの皆さん、セプキャン講師陣の皆さん、未踏スーパークリエーターの皆さん、お疲れさまです。おまえらはお呼びじゃない。 でね。俺もどっちかというとお呼びでない側っぽいので、色々考えた。昔はCで書くしかなかったサンプルコードがRubyで書いてあるというのはよいですね。なにがよいかってCほど煩瑣じゃないから、本質的な記述(だけとは言わないまでも)の割合が大きくて、いわゆる密度が高い気がする。なのでページ
DeNAに転職します
宮川達彦さんがCOOKPADでRuby書いてるなら俺がDeNAでPerl書くのもまあありなんじゃないかと思ったので。 よくある質問とその答えQ. 一時金もらえるんでしょ? 200万? やったー! ごちそうさまです A. ねーよ。おまえはいつの話をしてるんだ。そのキャンペーンはずいぶん前に終わりました。 Q. ベイスターズファンだったの? A. 好きでも嫌いでもねーよ。野球の趣味を理由に転職するの必ずしもダメとは申しませんが、俺はそういう類の輩ではございません。 Q. モゲマス作るの? A. 作らねーよ。Mobageだからといって全部のゲームをDeNAが作っているわけでは、実はないのです。モゲマスは違います。 Q. Rubyやめちゃうの? A. やめねーよ。コミュニティ活動に関しましては、むしろ推奨されていると聞き及んでおります。あと当然、素性を隠しておりませんので、俺が何者かは分かった上で
Re: Tempfile被害者の会
http://r7kamura.hatenablog.com/entry/2012/09/05/194630 しょうがないなー。gem作ってあげたからこれでも使いな。 https://github.com/shyouhei/open-temporary使い方Gemfileに gem "open-temporary" と書く。 一時ファイルを使うところに require 'open-temporaruy' と書く。 open-uriと同様にopenが拡張されており、無引数のopen、つまり File.open # => 一時ファイル とすることで一時ファイルを作成可能。 このファイルは本物のFileなのでdupしても平気。なぜこれがRuby本体に入らないのか?移植性がないからだよ。 この実装でなぜOKかというとOSが頑張ってディスクリプタやファイル領域をリークしないように回収してくれるからに
もう少し真面目な話、中学生がどのようにすべきかということ
前回書かなかった事を追補。 年寄りの御託に耳を貸すなということ。俺自身もそうですが、年寄りが若者の人生に口を出そうとしているときというのは、まあようするに他人の人生だから気楽なわけですよ。 そりゃ、だれも悪意があるわけじゃない。親身になって言ってくれてはいるのでしょう。でも、だからといって、やっぱ他人の人生なんですよ。どこまで行っても自分の人生じゃないという気楽さがあるから、無茶な事が言えるわけですね。どうしても理想論に走りがちというか、足りない部分は根性でどうにかしろとかね。あれです、親が逃した甲子園への夢を子供に託されても子供だって迷惑なわけです。年寄りはてめーの夢くらいてめーで腹を括って他人に迷惑をかけるなという話です。 けどまあ、そういうふうに面と向かって言えれば苦労はしない上に、言ったところでなにか改善されるわけではないという。徒労感だけがたまりますね。なのでみなさんとしては、上
「来年度からプログラムを書く仕事をすることになってしまった不幸なおまえらの道標となるべき書籍十冊」みたいなエントリは読むな。
「来年度からプログラムを書く仕事をすることになってしまった不幸なおまえらの道標となるべき書籍十冊」みたいなエントリは読むな。 毎度そのようなエントリを読む度に、かつて「コンピュータの名著・古典100冊」という紙の本が出たときに一応おさえておくかと思い読んでみたら紹介されてたのが軒並み絶版で腰砕けだったことが鮮やかに思い起こされます。 ただまあ、自分もなってみて分かったのは、おっさんというのはノスタルジアに生きるものであって、したがっておっさんに過去を向いて生きるなとか言ってみたところでどうしようもないということでございまして。「コンピュータの名著・古典100冊」をやった人たちを、当時はひどい仕事をする人たちだと思いましたけれども、今となってはむしろ、しょうがないのかなあと思うようになりました。 そんで、いずれにせよ新人の皆さんはおっさんのノスタルジに付き合う必要は微塵もございませんので、俺
卜部昌平のあまりreblogしないtumblr
ちょっと昔のことを思い出したので昔話でも書くか。 どっかで書いたと思うんだけど俺アレルギー持ちなのね。子供のころからね。アレルギーというのはアレルゲンに触れると発症するので、基本、対策としては、アレルゲンに触れないということしかない。 ところが、うちの父母は、俺が鼻炎や結膜炎で辛そうにしてると、病院には連れていってくれるけど、どうしてもアレルゲンを排除するということをしてくれないのね。これは今でもね。 このまま父母との暮らしを続けていても俺の人生はロクなことにならないんじゃねーのか。 その考えが浮かんだのは、忘れもしない中一の、12月19日の、学校から帰る道すがら、郵便局の前のへんを歩いていたときさ。俺は、父母が俺を愛してくれているというのは分かっていた。べつにネグレクトされていたわけでもない。ただ、どんなに愛してくれてたとしても、父母にとって俺の辛さは他人の辛さってことだ。本当には理解で
終わることはよいことだという感覚について
三つ子の魂百までとはよく言ったもので、子供のころの強烈に印象に残ってる体験というか、まあテレビで見たわけだけども、その当時ヨーロッパのまんなかのへんで政権交代が局所的なブームだったのさ。んでまあカラフルな壁をツルハシで壊してるドイツの人たちの強烈な笑顔というのが、今でも忘れられなくてですね。もちろん、今から振り返って見れば、1989年をよいとか悪いとかいう単純な評価で切り捨てるのが大きな間違いなのは分かる。けど、当時は政治とかよくわかんない程度に子供だったから、みんな「なにかが終わって喜んでるんだ」ということしか、俺には理解できなかった。だってあの人ら喜んでたでしょ。そのくらいは俺にも分かったよ。 まあそういうわけで、たしかにそのあと色々あったし一面的な評価が誤りだということは理解していますと繰り返し申し上げたうえで、でもやっぱり、少なくともあの瞬間には、終わることはよいことだったんだよ。
Pythonでおk ─ 書評: C言語によるスーパーLinuxプログラミング
あのね、この本のAmazonの内容紹介が あまりにたわけていて ね。 Cライブラリで、効率的にプログラミング！ Webアプリの世界ではPHPやJavaが格段とポピュラーだが、ハードウェアの操作や ユーザーインタフェース、画像処理などの分野ではC言語でしか扱えないものが多く、近年、現場でのニーズは高い。 本書は、プログラミングでの複雑な処理を短時間に組むために用意されたライブラリに焦点を当て、その使い方を解説しました。 データベース・プログラミングからネットワーク、科学技術計算、コンピュータグラフィクスまで、 ライブラリの活用術を身につけ、複雑なコーディングを簡素に実現する。 LinuxのディストリビューションにはUbuntuを採用。 あれですか句読点のところで毎回「なわけねーだろ」とかツッコミ入れる視聴者参加型インタラクティブ漫才か何かですか。SBCの編集会議はよくこれを通したよね。 まあ
どうも周知徹底が不足しているようなので再度のお願いとなりますが、C死ね。
確かにCでしか書けない類のプログラムは存在する(例を挙げるならKernel)が、それはCの存在を赦す理由にはならない。確かにCに輪をかけてさらにダメな類のプログラミング言語は存在する(例を挙げるならC++)が、それはCの存在を赦す理由にはならない。確かにCでしか書けないダメプログラマは存在する(例を挙げてほしければここにおまえの名前を入れろ)が、それはCの存在を赦す理由にはならない。結論:C死ね。 そもそも計算機にできて算盤にできないことなど存在しない。存在しないんだぞ。なのに何故人はプログラムを書くのか。それはオートメーションのためなのであり、奴隷的使役から人類の尊厳を開放して、この地上に楽園を築くためである。まあそこまで大上段に振りかぶって普段から書いてる輩はいないにせよ、プログラミングとは楽をするため、豊かな人生を実現するため、誰かの幸福のために行うものだ。違うか?じゃあなぜプログラ
卜部昌平のあまりreblogしないtumblr
エゴサーチで見かけた反応とそれの感想など 速さのためにはCでないと この誤解は典型的ですねえ。今、申し訳ないんだけど、普通に書いたCのコードと普通に書いたJavaのコード走らせると、普通に書いたJavaのコードの方が速くなるケース、全部とは言わんが案外と多いですよ。なんでかというと、Javaは普通に書いたらJVMが人類の持てるテクノロジの限りを尽くして勝手に高速化してくれる1が、Cはあなたの能力以上に速くはならない。Cは速いJavaは遅いってのは10年くらい前には正しかったんでしょうけどねえ。 なお自分でベンチマークしてる暇なんかないよ!という人はshootout.alioth.debian.orgぐらいは読んでもいいんじゃないですかね。たとえばJavaとCの比較で見れば全体的にいって同じくらいのスピード、いくつかの項目でJavaのほうが速いのが分かる。 組み込み屋はCでなければ何を使うか
やります: RubyConf2011旅費出しますから行ってきて
ぢっと通帳をみた結果とりあえず一回は実行可能という結論に達したのでやります。おまえらの旅費俺で持ちますから行ってきてください。 趣意つらつらと思い返してみると俺がRubyConf参加するようになったことに関して森脇大悟さんの果たしてくれた役割はとてつもなく大きいわけですよ。やっぱ単身見知らぬ海外の土地に出かけていくっていうのは西成に物見遊山に行くのより不安な行為じゃないですか。海外とか初めてだけど連れてってくれる人がいる、これが最終的にRubyConf行く決心がついた理由なので。森脇さんにはいくら感謝しても足りません。最近ご無沙汰してしまっており失礼していますが、この場を借りて再度お礼申し上げたい。その節は大変お世話になりました。でだな、まあ森脇さんへのお礼はそれはそれとして、世の中にはcharityとかpay it forwardとかいう風習もあって、詳しくはググれなんだけど、RubyC
Rubyがそろそろ一回終わってみるべきに至る道
前田先生ほどの人がアイタタな読み間違いをしている のを発見して、すこしコンテクストを解説しておいたほうがいいと思った。 まずまつもとゆきひろは(Rubyを)100年続けると威勢がいい。が、その割に掛け声ばかりで実際どのようにして100年続くことが可能かについて何も語らない。特に本人がいなくなってからの流れを整備しようという話にならない。前の項にも書いたが、100年続けるなら一人では無理なのにだ。一方、続けないとなると無論終わるしかないわけだが、終わるというのもそれはそれでテクニカルである。大抵の言語は終わるとなると不幸な終わり方しかしない。どっちに転ぶにしろ大変難しい領域があることがわかる。 ところで最近、様々な事案について責任者不在で議論が進まない状況が多々見られるようになってきた。一例をあげるなら標準添付ライブラリのGem化の話題は、あとは責任者がGoとかStopとか言うだけのところま
Rubyがそろそろ一回終わってみるべき10の理由
いや、Rubyを取り巻く皆さんの生活まで終われとは言ってないですからね。終わってみるべきなのはRubyのコア部分の開発。 1) 百年の大計の欠如 https://twitter.com/yukihiro_matz/status/25168548474 によると、100年や200年続けるべきなんだそうだ。ふーん。100年って言ってみたいだけちゃうんか。200年後といえば本人はおろかまつもとゆきひろと面識のある人間すら死に絶えている時期なんだけどな。そこまで続けたきゃどうするればいいか真面目に考えたことあんのかね。日本国ですらこの120年で2回も憲法変わってんだぞ。惰性で200年もつわけがないだろ。 2) まつもとゆきひろがスケールしない 御存知の通りまつもとゆきひろのRuby開発に対するコミットペース(ここでいうコミットってのはソースコードをチェックインすることだけではなくて広く「関与」の意
アジャイル建築 -- 書評「ゼロから始める都市型狩猟採集生活」坂口恭平著
アジャイル建築 – 書評「ゼロから始める都市型狩猟採集生活」坂口恭平著 作者は建築家であるが、大学の建築教育に違和感を感じ、廃墟に住んでみたりルドフスキーに傾倒したりの魂の遍歴を経つつ、ついに「都市の中で自立しながら振動しつづける建築」(p.163) を、しかし隅田川河岸で発見してしまう。衝撃を受けた作者はフィールドワークを重ね、結果できたのがこの本だ。したがって本書の前半部分はゼロの状態からどのようにサヴァイヴするかに関して書かれていてそれはそれで面白いけれども、おそらく本書の白眉は後半部分、路上生活者の住環境に関する調査と考察だ。 はっきり言ってしまおう、どこからどう読んでもアジャイルである。「そもそも現代の家は大きすぎるんじゃないか」(p.43)などという主張、YAGNIと関係性がないとはにわかには信じがたいものがあるし、特に「鈴木さんの家」(5章)はダンボールハウス→竹組掘っ立て小
卜部昌平のあまりreblogしないtumblr
Rubyには公式のものだけでも30本のブランチに29,385個のチェンジセットがある(執筆時点)。ブランチの1,000倍程度のチェンジセットがあるということは、実際にはブランチとチェンジセットの関係は偏りがあるから、ともかく長いブランチは超長いということがいえる。ちなみに一番長いのはもちろんtrunkで、この枝の長さは20,992リビジョンだ。次点がruby_1_8で、3,328リビジョンある(執筆時点)。 さてこのくらいの規模になってくると、もはや全容を把握するというのは困難である。特にどのブランチがどのチェンジセットから派生したかという情報は、もちろん個別には取り出すことは可能だが、俯瞰するのが困難になってくる。実際、今回ちょっとしたことでgit rebaseしようとしたらrebase先を間違えてしまい、ものすごく太古の昔からrebaseされてしまいげんなりするという体験をした(俺が本
Ruby + ARToolKit なバインディングを書きかけています件
(画像はハメコミ合成ではありません) 事情から説明すると以前から島根で Ruby合宿 とかいうのがあって、今年は講師で呼ばれたわけだ。 んで「なにか発展的な内容を」と言われたので、それならデバイスアートで拡張現実でニコニコ技術部でしょとか思っちゃったのが運の尽きで。 いや ARToolKit はそれはそれでいいとして、お題目がRuby合宿であるがゆえにARToolKitで完結してよかったねーでは当然ダメで、なんとかしてRubyが絡まにゃいかん。 というわけでとりあえず合宿当日までに俺がARToolKitのRubyバインディングを突貫で書いて当日合宿所でいきなり使いましょうという。ここまでくると俺講師なんだか合宿参加者なんだかよくわからんよな。 ところが面白いものでというか、ARToolKit自体はよくできていて、APIデザインを悩まなければ(まあ悩むんだけど)、わりとバインディング自体は素
卜部昌平のあまりreblogしないtumblr - ■ #!/usr/bin/env _...
今さらながら、 CGIの神話と現実というエントリ。ただし内容とはまったく関係なし。スクリプト言語の shebang 行（#!）でスクリプトインタープリタを直接書かずに /usr/bin/env でラップするという悪習はいったい誰が広めたんだろうか。ruby な人に多いように思うがそれだけじゃないし。 hoge というインタープリタを使うスクリプトの1行目をたとえば #!/usr/bin/env hoge としておくと、hoge の実行バイナリが /usr/bin/hoge でも /usr/local/bin/hoge でも $HOME/bin/hoge でもどこにあってもパスが通ってさえいれば起動できる。それはメリットなんだろうか。わしにはむしろデメリットにしか思えない。 /usr/bin/env を使うというのは、PATH の値にしたがってインタプリタの場所を探すという意味である。つまり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
