「Introduction to Abject-Oriented Programming」という記事がありました。 オブジェクト指向プログラミングで発生しがちな事柄を皮肉っています。 かなり笑えました。 最初は気がつきませんでしたが、原文のタイトルはObject-Orientedではなく、Abject-Orientedになっています。 面白かったので訳してみました。 一部良くわからなかったので省略してしまっているのと、間違っているかもしれないので、原文もご覧下さい。 また、原文のコメントも面白かったので、もしよろしければご覧下さい。 なお、原文のコメントにはネタであることを理解していないと思われる人の書き込みがありました。 念のためここにも書いておきますが「オブジェクト指向」じゃなくて「アブジェクト指向」ですよ！！！ 仮に、 Abject: 絶望的な、悲惨な、惨めな、屈辱的な、ひどい だそ
プログラミングの世界は広大です。自分の「母語」であるプログラミング言語を極めることも大切ですが，他の言語に目を向けることで驚くほど世界が広がることがあります。他の言語からエッセンスを学ぶことで，汎用的な「プログラミング力」が格段にアップするのです。 この特集では，個々の言語から何が学べるかについて具体的に解説しています。まず，Rubyの開発者でありプログラミング言語マニアとしても知られるまつもとゆきひろ氏に「複数のプログラミング言語を学ぶ意義」について語っていただきました。まつもと氏には，プログラミングの基礎となるコードの読み方の解説もお願いしました。 注目の言語，RubyとJavaScriptについては，気鋭の若手開発者のお二人に解説していただきます。さらに，伝説のプログラミング言語Eiffelの解説を，Bertrand Meyer氏の名著「オブジェクト指向入門」の翻訳で知られる酒匂寛氏
Referer一覧の存在に気づいたので、リンクして下さっている方々の文章を今更読んでいます。ただ、おそらく浮動小数点数の扱いが拙いのをround関数のせいにしているような文章を見つけました。もしそういう誤解があれば非常に残念だと思うと同時に、これだけ注目を集めたからには浮動小数点数一般の罠について簡単に紹介してみても良いかな、と思いつきました。浮動小数点数まわりでハマった人がここに検索でやってくることがあるかもしれません。 そんなわけで、今回のテーマは啓蒙です。浮動小数点数の不思議さについて簡単な紹介記事を書いてみました。また、第1回記事中の誤っている点について、1点訂正をします。今回はイメージ先行で書いてみましたが、伝えていないことはあっても嘘は書いていないつもりです。正確な内容が知りたくなった方はWikipediaの記事「浮動小数点数」を読むと良いでしょう。または、そこからリンクされて
図1に示す(1)から(3)までの麻雀（マージャン）の手牌があります。「あがり牌」はすべて山からツモったものとし，リーチはかけていません。またドラやハイテイ＊1なども関係ないものとします。これらの役を判定して，親の場合の点数を計算するプログラムを作ってください。 「ややこしや～ややこしや～」というのは野村萬斎ですが，思わずそううなってしまうことがプログラミングをしているとよくあります。今回の麻雀の役判定は，考えれば考えていくほどややこしく，そうしたものの代表と言えるでしょう。排他処理や優先順位が複雑にからんでいて一筋縄ではいきません。 今回はややこしい組み合わせを解決する方法を考えてみます。麻雀になじみのない方も，ちょっとしたパズル気分で試してみてください。 麻雀の役を考える 麻雀を知らない方のためにルールをおおざっぱに説明しておきましょう＊2。麻雀の牌には，大きく分けて「萬子（マンズ）」「
仮想世界と現実世界を融合する技術は，拡張現実感（Augmented Reality：AR）と呼ばれています． おおげさな言い方をするとARは現実の世界に情報を「上書き」することができる技術です． アニメや映画にでてくる「電脳」を想像してみてください． 手のひらの上に3Dキャラクタを表示したり，現実の世界でデジタル・データに触れてみたり… そんな魔法のような技術です． ARToolKitは，ARアプリケーションの実装を手助けするC言語用のライブラリです． ARToolKitを使うと，紙に印刷されたパターンをカメラで読み取り， その上に3Dオブジェクトをオーバーレイ表示するアプリケーションが簡単に作れます． 本来は非常に敷居の高い技術なのですが，このライブラリは「難しい部分」の処理を 全てやってくれます． …というわけで今回はARToolKitを使って近未来の技術 「拡張現実感」 を体験してま
Ruby 手習い Ruby してみません? Ruby の便利なところ/ちょっとだけ Tips スクリプトのライセンスについて 「いつでも Ruby なんでも Ruby」 Software Design 2000/7 掲載 「いつでも Ruby なんでも Ruby/Ruby 事始め」 Software Design 2001/3 掲載 CVS で最新ソースコードの入手 ここでスクリプトを紹介している目的は、Ruby を使おうとしている人に「参考になればいいな」と思っているためです。 とり上げているスクリプトは、私が実際使っているものです。 汎用的には作られていないものもあったりするので、もしかするとすぐには要求を満たせないかもしれません。 でも、ちょっとした修正を入れれば使えることもあると思います。 ぜひ、便利なスクリプト言語(OOSL? Object Oriented Script Lan
この原稿の最新版について この原稿に加筆した最新版が書籍「プログラミングGauche」に収録されています。 引用や紹介をされる方はなるべく書籍収録版を参照してください。 他の言語のプログラマがSchemeプログラムを書くとき、 どうしても発想が手続き的(procedural)になりがちです。 LispプログラマやSchemeプログラマの発想は手続き的な発想とはどうも違うらしい、 ということは分かるのですが、具体的に何が違うのでしょうか? ここではこの謎に迫ってみましょう。 実例 例えばこんな例題があります。 1から100までの数をプリントするプログラムを書け。ただし3の倍数のときは数の代わりに「Fizz」と、5の倍数のときは「Buzz」とプリントし、3と5両方の倍数の場合には「FizzBuzz」とプリントすること。 どうしてプログラマに・・・プログラムが書けないのか? (原題: Why
今までこう書いてたのが count[key] = count[key] ? count[key] + 1 : 1; こう書けることが判明した。 count[key] = ++count[key] || 1; コメント欄への回答 count[key]がNumberまたはundefinedであるとして、個人的には count[key] = (count[key] || 0) + 1; のほうが好みです。 JavaScriptでは問題ないとはいえ、言語によってはi = ++iの動作が未定義だったりするので。 前者の書き方とこの書き方は実は問題があって、Object.prototypeに定義されてるメソッドとハッシュのキー名がかぶるとおかしくなる。なので本当はcount.hasOwnProperty(key)でチェックするのが正しいのだけれど、出現回数のカウントごときでメソッド呼び出しとかしたくな
Kathy Sierra / 青木靖 訳 2006年12月27日 (アルファ版のような)開発中のものを私たちが世間や、クライアントや、ボスに見せるときには･･･彼らの期待のレベルを設定することになる。これは3通りの方法でやることができる。磨き上げられたモックアップで幻惑するか、プロジェクトの現状に合ったものを見せるか、ほとんどできていないものを見せながら順調に進んでいるから「信用しろ」と言っていら立たせるかだ。 結論を言うなら: どれくらい「できている」ように見えるかは、実際どれくらい「できている」かに合わせるべきだ。 ソフトウェア開発者はみんなそのキャリアにおいてこのことを何度も思い知ることになる。しかしテクニカルライターもまた、デスクトップパブリッシングツールによって同様の問題に直面する——フォントやレイアウトが完璧に仕上げられたドラフトを誰かに見せるなら、その人はあなたが考えるよりも
2007年04月25日12:00 カテゴリLightweight LanguagesBlogosphere Digest - 今日にでも使うべきJavaScriptの7つのテクニック 良質の記事だけに全訳したかったのだけど、時間もないので紹介と抄録。 Digital Web Magazine - Seven JavaScript Techniques You Should Be Using Today サンプルコードは、適宜書き換えてあります。 1. Branch when possible - 分岐はなるはやで これは実例を見た方が早いでしょう。クロスブラウザー対応のaddListener()を考える。機能だけを考えれば、以下でOK。 function addListener(el, type, fn) { if ( window.addEventListener ) { el.addE
Jeff Atwood / 青木靖 訳 2007年2月26日 レジナルド・ブレイスウェイトが書いていることを読んだとき、私はそんなわけないだろうと思っていた。 私と同様、この著者は、プログラミングの仕事への応募者200人中199人はコードがまったく書けないということで苦労している。繰り返すが、彼らはどんなコードも書けないのだ。 彼が引用している著者というのはイムランのことで、彼は単純なプログラムも書けないプログラマをたくさん追い払っているということだ。 かなりの試行錯誤の末に、コードを書こうともがいている人たちというのは、単に大きな問題に対して苦労しているのではないことがわかった。やや小さな問題(連結リストを実装するというような)に対して苦労するということでさえない。彼らはまったくちっぽけな問題に苦労しているのだ。 それで、そういった類の開発者を見分けるための質問を作り始め、私が｢Fizz
2007/04/27 “twitter”がブームだ。140バイト以内の短いメッセージで“現在進行形”の自分のステータスをほかのユーザーとシェアするだけのオンラインサービスだが、本国の米国はもとより、日本でも非常な人気を集めている。Alexaでアクセス数の推移を調べると、今年に入ってから本格的にブレークしている様子が分かる。4月22日にはニューヨークタイムズもtwitterと、サンフランシスコ在住の創業者2人を記事で取り上げている。 twitterのコミュニケーションツールとしての新しさ twitterに参加してみると、チャットやメール、SNSといった、既存のコミュニケーションツールのいずれとも異なる、不思議なつながり方が新鮮で楽しい。熱心にメッセージを更新するユーザーを見ていると、CUSeeMe、ICQ、mixiなどが登場したときに人々が示した熱狂に近いものを感じる。 twitterでは、
Jeff Atwood / 青木靖 訳 2007年3月22日 以下に私の選ぶプログラミングの6大10項目リストを挙げておく。取り上げた順序には特に意味はない。このエントリを簡潔なものにしておきたいので、それぞれの項目は短い要約を引用するに留める。興味を引くものがあれば、ぜひリンクをたどってオリジナルの作者の考えについてもっと詳しく読むことをお勧めする。 [ 訳注: 要約だけで意味が取りにくいものに簡単な説明をつけた。] ジェラルド・ワインバーグの｢エゴレスプログラミングの十戒｣ 自分が誤りを犯すということを理解し、受け入れること 。 自分と自分のコードは別物である。 どんなに｢空手｣を学ぼうと、いつでもあなたよりもっと詳しい人間がいる。 相談せずにコードの書き直 しをしない。 自分より無知な人に対しても尊敬と敬意と忍耐を持って接すること。 世界で唯一変わらないのは変わるということだけ。 唯
Peter Norvig / 青木靖 訳 先週、2人の友人(ディーンとビル)がそれぞれ別個にGoogleが極めて早く正確にスペル修正できるのには驚くばかりだと私に言った。たとえば speling のような語でGoogleを検索すると、0.1秒くらいで答えが返ってきて、もしかして: spelling じゃないかと言ってくる(YahooやMicrosoftのものにも同様の機能がある)。ディーンとビルが高い実績を持ったエンジニアであり数学者であることを思えば、スペル修正のような統計的言語処理についてもっと知っていて良さそうなものなのにと私は驚いた。しかし彼らは知らなかった。よく考えてみれば、 別に彼らが知っているべき理由はないのだった。 間違っていたのは彼らの知識ではなく、私の仮定の方だ。 このことについてちゃんとした説明を書いておけば、彼らばかりでなく多くの人に有益かもしれない。Googleの
20070405コードレビュー posted by (C)フォト蔵 尾藤正人です 先日ウノウの勉強会でUNIXデーモンの作り方についてプレゼンしました。 UNIXのデーモンの仕組みはWebサービスの開発にあたって直接関係の深いトピックではないかもしれませんが、知っておいて損はないと思います。 発表資料と動画を公開しますので、よかったらご覧下さい。 普段は気にしないUNIXデーモンが裏で何をやってるのか、少しでも身近に感じていただければと思います。 発表資料の公開にはちまたで話題のScribdを使ってみました。 プレゼン資料はKeynoteで作ったのですが、PowerPoint形式に変換してアップロードする簡単にできました。 デモ用に実際に動く簡単なデーモンプログラム ccho(シコー) を作成しました。 ccho は前々回の勉強会で行ったGnu Autotoolsで作った bat プログラ
EfficientJavaScript - Dev.Opera - 効率的な JavaScript 目次 この文書について 効率的な JavaScript ECMAScript eval や Function のコンストラクタを使うのはやめよう eval を書き換えよう 関数を使いたいなら function を使おう with を使うのはやめよう 性能を決める関数で try-catch-finally を使うのはやめよう eval と with は隔離しよう グローバル変数を使うのはやめよう 暗黙のオブジェクト変換に気をつけよう 性能を決める関数で for-in を使うのはやめよう 文字列は累積スタイルで使おう プリミティブの操作は関数呼び出しより速い setTimeout() や setInterval() には文字列でなく関数を渡そう DOM 再描画と再フロー 再フローの回数をでき
404Error - Page not found ご指定のファイルが見つかりませんでした 30秒後にトップページへ移動します
2007-04-16 近況 最近の私はもっぱらサンプルからのコピペが仕事. コピペといっても Ctrl+C, Ctrl+V より少しだけインテリジェントだけれど, ライブラリが強力な上に文書の出来が良いから, 多くはサンプルの改変で済んでしまう. 面白くはないが生産性は高い. コピペ・ハイウェイの渋滞にぶつかり, サンプルのないパターンに出会うこともある. そういう時は自分でコードを書く. でもだいたい動かない. Getting Started や入門書はざっと読んである. それでもわからない. 文書化されていない不具合や common pitfall だったりする. (間抜けな間違いもあるけれど...) こんなとき Google はあまり役にたたない. 使っているライブラリやフレームワークがよほどメジャーでない限り, 解決方法はなかなかみつらない. せいぜい自分と同じところで悩んでいる人
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く