Twitter の 3 パーセントは悪意でできてます - kなんとかの日記
以前、Matz日記が更新されないのはまつもとさんがTwitterを始めたからと聞いて「matz twitter」でぐぐったときから「そうじゃないかなー」と思ってたけど、あるいはひがさんからありがたいお言葉を頂戴したときも「そうじゃないかなー」と思ったけど、やっぱりTwitterって本人のいないところで気軽に陰口をたたきやすよね。 Twitterは、ちょうど会社のタバコ部屋みたいなもの。あるいは女子社員が集まる給湯室。仲間内が集まって、情報交換という名のうわさ話や他人の陰口をする場所。 以前、えらい粘着してきた彼が、Twitterでもネチネチやってた。 『kなんとかの人』！ これは新しい呼び方！ わざわざ検索されにくいような言葉を使うところに工夫を感じる。 しかし『shootoutのベンチマークも一応アプリケーション』か・・・。その感覚は世間と乖離しているんじゃね？あと『スクリプト言語に有利
Java屋さんのコメントがレベル高すぎて困る - kなんとかの日記
Velocity/JSPが遅い件について、Java屋さんからびっくりするようなコメントをもらった。 最初のコメントは、よく意味がわからなかった。 はなこ 2010/06/04 14:37 JSP 勘違いしてない？ JSP を初めて読み込むと、開発サーバーによって Java ソース コードに変換され、その Java ソースが Java バイトコードにコンパイルされます。Java ソースとコンパイル済みのクラスは、一時ディレクトリに保存されます。元の JSP ファイルに変更を加えると、JSP が自動的に再生成されてコンパイルされます。 JSP の使用 - Google App Engine - Google Code http://code.google.com/intl/ja/appengine/docs/java/gettingstarted/usingjsps.html JSPが遅い理由
JSPが遅い理由をJava屋さんはまるでわかってないらしい - kなんとかの日記
なんかVelocityもJSPもスクリプト言語より遅いという事実は、Java屋さんはあんまり知らなかったみたいだね。しかも、遅い原因の考察が的外ればかりで笑ってしまう。 「Javaの文字列操作は遅いから」とか「UTF-16の変換に時間がかかるから」とか、そんなのまるで関係ないですから。Javaの文字列操作は十分速いし、UTF-16の変換も主要因ではない。 ＃つうかさ、「Javaの文字列操作は遅い」とか、Javaに対して失礼だろ。 VeocityやJSPが遅いのは、単に動的な独自言語を導入したから。はっきりいって、これはアーキテクチャ上の間違った選択。せっかくJavaが静的であるのにその特性を利用せず、わざわざ動的言語を導入しているのだから、何考えてんだろうと思う。いつもJava屋さんが主張しているような、「コンパイル時にエラーを発見できる」「IDEでの補完が効きやすい」「リファクタリングが
高速なプログラミング言語が生み出す本当の価値 - kなんとかの日記
なんか、はてなブックマークとか見てると残念なコメントが多いよなー。『こんな比較は意味ない』とか『できることがまったく異なるテンプレートを並べて比較されても』とかいうやつ、何なの？「言語の速度 != アプリの速度」という主張を示したベンチマークなんだから別におかしくないじゃん。主旨がまるで分かってもらえてない。ネットワークやデータベースの処理まで含めて計測したら、「言語の速度 != アプリの速度」という主張がより鮮明になるだけじゃね？ 反論する人があまりに残念な反論しかできないようなので、かわりに自分で「高速な言語を使う理由」を説明する (一人マッチポンプ状態じゃねーか)。 ・ ・ ・ ・ 言語が速いことによる本当の利点は、採用可能なアーキテクチャが広がることだと思う。新しいアーキテクチャを思いついたので採用したいが、スクリプト言語ではどうやっても満足な速度が出せなかったのが、Java
ひがさんからのありがたいお言葉 - kなんとかの日記
ひがさんから、ありがたいお言葉を頂戴しましたので紹介させていただきます。 ＃釣り認定されちゃった。わーい。 んー、「言語の速度 != アプリの速度」という主張を示すにはあれで十分だと思いますけど。データベースやネットワークまで含めて計測したら、それこそ言語の速度に関係ない部分が増えるわけですから、先の主張がもっと強調されるだけです。そういった、明らかに言語に関係のない部分を含めなくても「言語の速度 != アプリの速度」というのがよくわかるという点で、あのベンチマークは十分意味があると思いますが、いかがでしょうか。 『テンプレートの処理の全体に対する時間の割合が出てない』とおっしゃってますけど、それこそ採用するテンプレートエンジンやアプリケーションの内容で大きく違うんだから、出してもあんまり意味ないと思いますよ。出したところで「言語の速度 != アプリの速度」は変わりませんし。それでもデータ
プログラミング言語の速度とアプリケーションの速度がいかに関係ないかがわかるグラフ - kなんとかの日記
まずは次の表をご覧あれ。これはプログラミング言語のベンチマークとして有名な Computer Language Benchmarks Game のベンチマーク結果。上にいくほど高速で、下に行くほど遅い言語になる。 これを見れば、最速な言語は C/C++ であり、Java や Haskell や OCaml といった静的な言語は軒並み上位に登場する。これに対し、Ruby や Python や PHP といったスクリプトは全部下のほう (つまり遅い)。その速度差は非常に大きく、このベンチマークで見ると Python3 や Ruby1.9 は C/C++ の約50倍から60倍遅く、Perl は約90倍、PHP にいたっては約130倍遅いことになる。 (ちなみに JIT つきの Lua が驚異的に高速なのが目をひく。この結果が本当だとしたら、言語の速度に大きく関係するのは動的か静的かではなく、どれ
『使いやすいのは動的な言語だから』というのは間違い - kなんとかの日記
いやー、おまいらがスクリプト言語大好きというのはよくわかった。よくわかったけど、信者はもっと落ち着いたほうがいい。 mikihoshi 「スクリプト言語の使いやすさ」のかなりの部分はスクリプト言語(動的言語)であることが担保してるんだから、「スクリプト言語並みに使いやすい静的な言語」って命題が無理筋ではなかろうか 2010/04/27 はてなブックマーク - スクリプト言語の息の根を止めるのは案外 SSD かもな - kwatchの日記 ちげーよ。動的か静的かということと、使いやすいかどうかはさほど関係ない (多少はある)。 確かに、使いやすさに定評のある Ruby や Python は動的言語で、その逆に Java は静的な言語だけど、それは Ruby や Python が使いやすさを最大限考慮して作られたが Java はそうじゃなかった (あるいは Matz や Guido のセンスは
Facebook はなぜ HipHop を開発したかを考える - kなんとかの日記
もとのエントリでも触れたけど、Facebook は PHP を C++ に変換して実行する仕組みを開発し、これを HipHop for PHP という名前で公開している。 知っての通り、Facebook は世界最大の SNS であり、PHP を中心に構築されている。サーバの数も膨大で、その数約 3 万台。詳しくは Publickey の記事を参照のこと。 Facebookが大規模スケーラビリティへの挑戦で学んだこと（前編）〜800億枚の写真データとPHPのスケーラビリティ問題 Facebookが大規模スケーラビリティへの挑戦で学んだこと（後編）〜キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性 世界最大の SNS である Facebook が、スクリプト言語である PHP を使って構築されているという事実は、スクリプト言語でも超巨大なシステムが構築可能であることを証
スクリプト言語の息の根を止めるのは案外 SSD かもな - kwatchの日記
大変たいへん興味深い記事。全プログラマーにとって。 HDDの代わりにSSDを利用したら、リレーショナルデータベースの性能はどれだけ向上するのでしょうか？ オラクルと富士通が共同検証を行い、その結果をホワイトペーパーとして先週発表しました ...(snip)... HDDは200スレッドで性能が頭打ちなのに対し、SSDは200スレッドから300スレッドになってもまだ性能は上昇。ただし、300スレッド時にはCPU利用率が100％に近づいており、先にCPU性能の方がボトルネックとなってしまったようです。 HDDをSSDにしたらデータベースはどれだけ速くなるか？ オラクルと富士通が実験 － Publickey 動的なスクリプト言語 (Ruby や Python など) と静的なコンパイル型言語 (C++ や Java など) では、だいたい 5 倍から 10 倍ぐらいの速度差がある。それでもスクリ
DI コンテナの起動が遅いなら、起動が速いのを作ればいいじゃない - kなんとかの日記
自分で書いたコメントなんだけど、今見るといいこと書いてあるように思うので、エントリにしてみる。3行でまとめると： Spring の起動が遅いことと、DI コンテナの起動が遅い/速いというのは、別の話。 DI コンテナの起動が遅いなら、起動の速い DI コンテナを作ればいいだけであり、あれだけ推していたものを起動の遅さを理由に使わないのはおかしい。 DI の有用性は、App Engine に関係しない。App Engine で必要ないなら一般のアプリでも必要ないはず (でもそうじゃないよね)。 > DIを使うとspin-upが遅くなってしまうから使わない方が良いみたいです。Springとかはそれでかなり苦労してるらしいです。 うーん、どうでしょう？ 「Spring の起動が遅い」ことと「DI コンテナの起動が遅い」ことは別の話ですよね？spin up time が問題なら起動の速い DI コ
VCS において Git が革新的な点 - kなんとかの日記
はっきりいって、Git の CUI は使いづらくてわかりにくい。サブコマンド名やオプションが開発者目線で決められており、ユーザからどう見えるかという視点が欠けている。その点、Subversion はよく考えられて洗練されていたし、それを受け継いだ Mercurial も使いやすい。Linus は Subversion をこき下ろす前に Git のコマンド体系を整理すべき。 ただ、Mercurial などと比べて Git が革新的にすごい点がひとつある。それは、バージョン管理システムに Garbage Collection (GC) の概念を持ち込んだことだ。みんなあまり注目してないと思うけど、こいつはほんとうに kool な機能だ。 GC はもちろんプログラミング言語の分野での概念だけど、そのプログラミング言語の世界では、GC が一般的に使えるようになることでプログラミングスタイルが大きく
Google が CPU 開発に乗り出す可能性 - kなんとかの日記
なんの裏付けもない、まったくの個人的な妄想だけど、Google はそう遠くない未来に、CPU 開発に乗り出すという予想をしてみる。いやいや汎用品を使うからこその Google なんだと言われるだろうけど、それなりに根拠はある。 Google にとっては、CPU の単体性能よりも電力あたりの性能 (もっといえばデータセンターあたりの全体性能) のほうが重要。たとえば、性能は Intel CPU の半分しかないけど消費電力が 1/10 であるような CPU を 10 個使えば、(単純計算だけど) 同じ消費電力で 5 倍の性能が手に入る。 オープンソースにより、バイナリ互換性の重要性が下がってる。特にサーバサイドなら Windows が動かなくて構わないので、x86 である必要性が少ない。 言語やコンパイラや VM を作れるエンジニアが自社にたくさんいる。Chrome は JIT を搭載している
App Engine で DI を使うメリットはない？ - kなんとかの日記
DIの主なメリットは、テストのしやすさと宣言的トランザクションだと思いますが、AppEngineではモックなしで簡単にテストができ、Bigtableの仕様的に宣言的トランザクションはほとんど使えないので、AppEngineでDIを使うメリットは余りないんじゃないかと思います。単に複雑になるだけ。 これが、Slim3でDIをはずした理由です。 2009-11-15 - yvsu pron. yas うーん、どうだろ。DI のメリットって、システムを疎結合にできることだと思うんだけど。疎結合にできるから、たとえばテストがしやすくなったりするわけで。疎結合にできるメリットは App Engine でもうれしいと思うけど、違うのかな。なんか他の意図があるような気もする。 それより、『単に複雑になるだけ』という言葉が気になる。やはり Java 屋さんにとっても、DI コンテナを使うのは複雑さが増すと
Rails の routes.rb がわかりにくい - kなんとかの日記
Rails の routes.rb と格闘中なんだけど、なんで Rails の routing はこんなにわかりにくいのだろうか。 ## named route は省略 map.with_options(:controller=>'books') do |x| x.connect '/books', :action=>'index', :conditions=>{:method=>:get} x.connect '/books', :action=>'create', :conditions=>{:method=>:post} x.connect '/books/new', :action=>'new', :conditions=>{:method=>:get} x.connect '/books/:title', :action=>'show', :conditions=>{:metho
はじめての Kay Framework 体験記 - kなんとかの日記
Google App Engine 専用フレームワークというふれこみの『Kay』を試してみる。 なお環境は Mac OS X 10.6、Python 2.6.2 (自前コンパイル)、GAE SDK 1.3.2。 ダウンロードと解凍 プロジェクトの Web サイトからダウンロードして解凍。 $ cd /tmp $ wget http://kay-framework.googlecode.com/files/kay-0.8.0.tar.gz $ tar xzf kay-0.8.0.tar.gz $ ls -F Kay-0.8.0 .hg_archival.txt RELEASE_NOTES kay/ .hgignore TODO manage.py .hgtags app.yaml settings.py AUTHORS cron.yaml.sample urls.py LICENSE doc
developerWorks の記事にある Python コードを修正してみた - kなんとかの日記
IBM が運営している技術サイト developerWorks には Python の記事がちょくちょく載っているんだけど、Python コードのインデントが崩れていて大変悲しい (最初は日本語版だけかなと思ったら、もとの原文からしてインデントが崩れまくってた)。 そこで、勝手ながら崩れたインデントを修復してみた。今回のターゲットは次の記事。 魅力的なPython: ステート・マシンの使い方 (developerWorks Japan) 元記事のインデントがどのくらい崩れているかというと、こんな感じ。ひどいでしょ？ ところで、この記事は2000年に書かれており、Python コードとしては古い書き方をしていた。そこでインデントを修復するだけでなく、より新しい書き方に変更してみた。具体的には、以下のような変更を行っている。 1/0 ではなく True/False を使う 親クラスを省略せずに
日本語基礎文法最速マスター - kなんとかの日記
もう何番煎じか知らんけど、日本語の文法についてさらっと説明してみる。 日本語といっても、技巧的になる詩や小説とかじゃなく、説明的な文章を対象とする。 （追記: 2010-02-06: 全体的に文章を見直し、細部を修正） 主語はおまけ、述語こそ主役 英語では「主語＋動詞」のペアが文法の主役だけど、日本語では「主語」はおまけであり、「述語」だけが主役である。日本語では、主語はあくまで述語を修飾する存在でしかない。 たとえば： I love you. # 主語 + 動詞 + 目的語英語では「主語＋動詞」というのは欠かせない存在であり、かつ登場する順番も決まっている（特殊な構文は除く）。 これに対し： - 俺は おまえのことが 好きだよ。 # 主語＋目的語＋述語 - おまえのことが 俺は 好きだよ。 # 目的語＋主語＋述語日本語では、述語さえ最後に来ていれば、「阿部×三橋」でも「三橋×阿部」でもど
RubyがPHPに勝つにはメソッド呼び出しのための新しい演算子が必要 - kなんとかの日記
PHPerがRubyを触り始めて最初に不機嫌になるのは、空文字列が偽ではないことだ。つまり、PHPなら「if ($var)」で済むのが、Rubyだと「if !var.empty?」と書かなければならない。これでPHPerは不機嫌になる (まあ気持ちは分かる)。 if ($var) ... # PHP if !var.empty? ... # Rubyそれだけならいい。もし値がnilである可能性があるなら、Rubyでは「if var && !var.empty?」と書かなければいけない。この時点でPHPerは不機嫌どころかブチ切れる。なんでこんなに書かなきゃいけないんだ!? PHPなら「if ($var)」で済むのに!! SHIIIIT!! if ($var) ... # PHP if var && !var.empty? ... # Rubyここで、「空文字列が偽になるような言語仕様こそク
Javaは『end of life』なのか？ - kなんとかの日記
一方で、バージョン管理ツールのSubversionが後退し、それと入れ替わるように分散バージョン管理（Distributed version control）が前進しています。ホワイトペーパーでも「GitやMercurialといった分散バージョン管理はこの数年で大きな注目を集め始めており、地域的に分散した環境でのバージョン管理を求めるエンタープライズ市場での推進役となっている」と書いています。 JavaScriptが第一級のプログラミング言語へ、分散バージョン管理にも注目が集まる － Publickey "エンタープライズ" ではまだSubversionじゃないかなあ。GitもMercurialも、リポジトリの一部だけをcheckoutしたり、ディレクトリ別にアクセス制御ができたりしないよね？孫請けの末端開発者には担当部分のコードだけアクセスできるようにしておかないとだめなんじゃないだろう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPがほかの言語より道具として優れている点 - kなんとかの日記
