Meteor.js - naoyaのはてなダイアリー
http://www.meteor.com/ で公開された Meteor.js を少し触ってみました。TechCrunch なんかでも話題になっていましたね。 Meteor.js は JavaScript によるウェブアプリケーションフレームワークですが、クライアントサイドでもサーバーサイドでもない、"Isomorphic" なフレームワークです。 コンセプトとしていくつか特徴があるのですが、その最たるものは "Reactive Programming" で、モデルやセッションなどのストレージを更新するとその更新内容がリアルタイムに、そのアプリケーションを開いている全クライアントに伝わるようなアプリケーションを簡単に作ることができます。 この辺は実例を見るのが早いです。 http://www.meteor.com/examples/leaderboard ここにある動画では、あるブラウザで
Titanium Mobile についての勉強会資料 - naoyaのはてなダイアリー
昨日は gumiStudy#5 でした。何か Tech Talk を、ということだったので最近いじっていた Titanium Mobile について整理して、紹介してきました。 Titanium MobileView more presentations from Naoya Ito. (フォントがひどいですね・・・すみません。http://www.slideshare.net/naoya1977/titanium-mobile/download からダウンロードできます) 先日書いたエントリ (http://d.hatena.ne.jp/naoya/20101011/1286799669) のとおり、Titanium Mobile を使うと JavaScript でネイティブアプリを開発することができます。しかも iPhone/Android マルチプラットフォーム対応。最近は Blac
Scripting Layer for Android で Perl x Android - naoyaのはてなダイアリー
Shibuya Perl Mongers テクニカルトーク#14 に行ってきました。諸々面白かったですがパネルディスカッション、LT ともに id:kazuhooku さんの発表が良かったですね。 さて、Scripting Layer for Android (SL4A) を使って、Perl で Android を hack する話をしてきました。SL4A は jRuby、Perl、Python、PHP などの言語を Android で使えるようにするアプリ。それぞれの言語からは AndroidFacade API と呼ばれる API で、Android のUIやカメラを操作できるというものです。 発表資料は以下です。 Scripting Layer for Android + Perl (SlideShare) http://www.slideshare.net/naoya1977/sc
あるプロセスが利用しているメモリサイズを procfs 経由で調べる - naoyaのはてなダイアリー
お題は「あるプロセスがどの程度の物理メモリを利用したかを知りたい」です。 手っとりばやく知りたいときは top や ps などで調べると良いでしょうか。例えば手元の coLinux で top して M キーでソートすると emacs のプロセスが最もメモリを使っているようです。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1923 naoya 18 0 23120 19m 3096 S 0.0 2.0 0:55.40 emacsメモリサイズは VIRT と RES がありますが、VIRT は Virtual の略で仮想メモリ領域のサイズ、RES が Resident の略で、実際に使用している物理メモリ領域のサイズ。19MB ほど使っているようです。この emacs のプロセスが利用するメモリ領域はざっくり 20MB 程度と
10分で完了、mod_perl 2.0 で Hello, World! - naoyaのはてなダイアリー
10分で、といいながらたぶん mod_perl と Apache2 をビルドするのに 10 分以上かかるという罠。まあいいや。以下のやり方で Linux、MacOSX どちらでもちゃんと動くと思われます。 まず、mod_perl 2.0 のインストール。DSO でもいいけど、ここでは Apache にスタティックに組み込みます。 インストールディレクトリは /usr/local/httpd_mp2 に。 MPM は prefork。perl を thread 有効でビルドしてるなら mpm=worker でもいいと思います。 $ wget http://perl.apache.org/dist/mod_perl-2.0-current.tar.gz $ wget http://www.apache.org/dist/httpd/httpd-2.0.55.tar.gz $ tar zxvf
2006-04-26
朝起きてみたらすげー回答数だよ･･･! 開いてる時間がない･･･！ 健康診断いってきます･･･！お昼までには全部開くからね･･･! http://d.hatena.ne.jp/mkusunok/20060426/hr を読んでいろいろ考えた。 最近はてなブックマークとか見てて、優秀な人は自分がすごいことをやってるとか、努力してることに気づかないみたいな話がありましたね。例えば僕なんかはゲームがすごい好きで、ある程度つまらないゲームでも結構ずーっとやってられるみたいな感じがありますが。んなゲームするのが好きでどうすんだよ! ってそういう話じゃなくて。この感覚をときどき、プログラミングをしてたりコンピュータを触ってるとき、新しい技術について調べてるときに感じることがあるよという話。 その一方で、読みづらくて分かりづらい本を読んだり、ひたすらバグを叩いてるときとか、同じプログラミングに関すること
物を選んでから何かをさせる - オブジェクト指向のお話 - naoyaのはてなダイアリー
ときどき「オブジェクト指向でプログラミングをするというのはどういうことなの?」と聞かれるときがあります。そんなときにうーん、オブジェクト指向ってどう説明したらいいものか...犬がワンって吼えるでしょ...ああ、これじゃわからん、などと頭を悩ませるのですが、ふと 憂鬱なプログラマのためのオブジェクト指向開発講座 (DDJ Selection) から学んだ、Windows の UI の話が分かりやすいと思いました。 Macintosh や Windows の GUI はオブジェクト指向だ、というのが書籍の中にある説明です。(P.300 ぐらいから解説されています。) ファイルの削除、という動作を思い浮かべてみましょう。このとき行う操作は、 まずファイルをマウスで選択する 右クリックして操作一覧を出す 削除する という動作になります。(ドラッグ&ドロップでごみ箱に入れる、というのもありますね。)
続・オブジェクト指向の話 - naoyaのはてなダイアリー
オブジェクト指向設計の初期段階では、まずユースケースを自然言語で書いて、そこから名詞となるものを抽出して、各名詞がお互いにどういう関係にあるかという分析をしていきます。クラス導出の初期段階です。 最初、この手法を学んだときに「なんで名詞だけ抜き出してほげほげ」なんてことをやるんだろうとかなり疑問というか、手法は正しいのかもしれないけど、なぜそれをしなければいけないかが理解できませんでした。自然言語の中から名詞を抽出する作業と、コーディング作業というのが、頭の中でリンクしていなかったからです。 これも、先日書いた物を選んでからほげる、の法則から考えるようになってから理解できるようになったことのひとつです。 宮川さんは、「最初にメインプログラムの中にオブジェクトと、そのオブジェクトに何をさせるかを書くそう」と書きました。これは結城さん風に言うと、"インタフェースでプログラミングしている"という
naoyaのはてなダイアリー - MyISAM vs InnoDB
あくまで憶測で仮説でしかないんですが。 MySQL のストレージエンジンのうち代表的な二つ、MyISAM と InnoDB はよく MyISAM: Read は速いけどテーブルロックのため並行性が低い。運用が簡単。 InnoDB: MyISAM より Read は遅いけど並行性が高い 。行レベルロックなので。あとトランザクションや外部キー制約。運用が MyISAM よりちょっとめんどくさい。 という区別がされます。ここから転じて、 MyISAM は参照系クエリが大部分を占める場合に適用すると良い。例えば blog アプリケーションとか。 InnoDB は更新系クエリが多い場合に適用すると良い。 と言わたりします。実践ハイパフォーマンスMySQL でも第2章 ストレージエンジン(テーブル型) P.30 に アプリケーションでトランザクションを使用する必要がなく、主に SELECT または I
Unicode::RecursiveDowngrade - naoyaのはてなダイアリー
UTF-8 フラグがどうもウザいという人向けにこんな CPAN モジュールがあるそうな。 「あるそうな」というか作ったのあなたでしょと軽くツッコミつつ、これはいいものです。Perl 5.8 における悩ましい問題であるところの UTF-8 フラグを、データ構造を再帰的に下って全部 off にしてくれるモジュールです。 http://search.cpan.org/dist/Unicode-RecursiveDowngrade/ なにげにフラグを落とす処理を pack('C0A*', shift)と pack な魔法でやってるところも素敵。Encode や unicode を必要としないので Perl 5.6 とかでも使えます。pack な方法はおそらく竹迫さんのパワポから得たヒントかな。 これまで、TT で utf8off なんてフィルタを書いて [% item.title | utf8of
Test::Class - naoyaのはてなダイアリー
最近 Perl でテストを書くときに Test::Class を使ってます。(もしかして常識?) これまでは *.t で Test::More をそのまま使ってたけど、テストが大きくなってくるとコードが分かりにくくなったり、自分であれこれしなきゃいけないことが多くてめんどくさい。 Test::Class は xUnit スタイルで Perl のテストを書けるフレームワークです。xUnit な Perl 実装といえば Test::Unit もあるんですが、テスト用の関数も Test::Unit の流儀に従う必要があってちょっと嫌。Test::Class は Test::More と Test::Harness とか、普段使い慣れてる Perl らしいテストスタイルを使いつつ xUnit できるという点が良いです。 使い方ですが、 Test::Class を継承したテストクラスを作り テスト用
naoyaのはてなダイアリー - YouTube の負荷
なんつったって動画ですよ。 ブログとかmixi日記のようなテキストレベルのコンテンツに比べて、はるかにサーバーにかかる負荷は高いはずです。 YouTube と mixi を比較して "負荷" の話をしていて、「動画配信だから負荷が高い」と断定していますが、これは何を"負荷"とするかにもよるかなと思います。 "負荷" というと CPU load や I/O などリソースの消費っぷりを指す言葉というイメージがありますが。(一般的には違うものでしょうか?) そういう意味での負荷で言ったら、「YouTube = 動画 / mixi = テキストだから YouTube の方が負荷が高い」という断定はやや微妙です。負荷の種類が違うのです。 YouTube のシステムを見たときにその焦点になるのは、まず第一にネットワーク帯域。第二にストレージをどうしているかというところじゃないかなと思います。動画配信に
naoyaのはてなダイアリー - Perl の話をまとめた
use strict がどうのこうのという話があって、そういえば昔自分もそんなこと書いたなあと思っていろいろ自分の書いた Perl の話を見返してて、せっかくだから拙作のまとめでも作っておくかと思いました。とりあえず文章量がそれなりにあって、まとまりのあるものだけを見繕ってみます。 今見ると、当時の理解が不十分で微妙なところもあったりしますが、そのあたりはご愛嬌。 いま読んでもまだ陳腐化はしてなさそうな話 お薦めの Perl 本をいくつか紹介 : NDO::Weblog Perlおすすめの書籍や情報。今ならここにPerl救命病棟とWEB+DB PRESS総集編を入れるかな。 Perlプログラマのレベル10 - Perlプログラミング救命病棟より - naoyaのはてなダイアリー Perlプログラマのレベル10。なんか他言語にも飛び火した。 Perl の変数に関するちょっとした誤解と、動的な
naoyaのはてなダイアリー - Inside Hatena Bookmark's Backend の資料
以下に置いておきました。遅くなってすいません。 http://bloghackers.net/~naoya/pdf/050404inside_hatena_bookmark.pdf 会場で前置きしたように、はてなブックマークは、はてなで一番大きなシステムであるはてなダイアリーあるいは同じ YAPC で発表のあった mixi に比べると、まだそこまで大きな規模ではありません。月間の PV はだいたい 4,000 万 PV 〜 というところです。 ただ、日本でのトラフィックが上から 5 番目みたいな怪物サイトよりも、月間の PV が 1,000 万クラスのサービスの情報の方が、より現実的で役に立つのではないかと思い、はてなブックマークの裏側に絞って話しをしてみました。 ...という前提で見ていただけると嬉しいです。 はてなブックマークのデータのサイズもかなり大きくなってきたので、ぼちぼちパーテ
naoyaのはてなダイアリー - 似たようなことをやってるけど実は違うことをやってる人たち
梅田さんより10歳前後若いブロガーたちが急激な変化を予想する一方、44歳の梅田さんは一貫して、「変化は起きるが、みんなが思っているほど急激ではないだろう」という立場で語った。 僕もこのイベントにはちょこっと顔を出してみました。 なんかパネラーの人たちがはてなブックマークの話をたくさんしてて、開発者がここにいるって言うのに開発者そっちのけで色々話してて、まあ最後に開発者から一言とかで呼ばれるだろうと思ったらそんなこともなくって。おまえらいい加減にしろと憤慨しました。いや、冗談です。 個人的には第二部の SNS の話で id:umedamochio にいじられる山岸さんが面白くてしょうがなかったんですが、ここは敢えて第一部の話に触れてみよう。 この ITmedia の記事の冒頭の一文にあるように、「ネットがマスメディアを飲み込むんだ」という見方に対して梅田さんが「いやいや、そんなに簡単にはいか
naoyaのはてなダイアリー - サーバーを増やせばいいんじゃない、サーバーを増やすだけで解決できるように努力するのだ
ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増
TinyMCE JavaScript Content Editor - naoyaのはてなダイアリー:
とある友人に教えても経ったTinyMCEという WYSYWIGWYSIWYG な HTML エディタライブラリがやばそう。 JavaScript で記述された LGPL でオープンソースな クロスプラットフォームの 多言語対応もしてて 簡単に使える ライブラリ。似たようなものに htmlArea というのがあって結構昔に話題になってたんですが、導入がめんどくさかったりブラウザによってはまともに動かなかったりとか色々面倒な感がありました。TinyMCE の方はと言いますと、Installation instructions にもあるとおり、 <html> <head> <title>TinyMCE Test</title> <script type="text/javascript" src="/js/tiny_mce/tiny_mce.js"></script> <script type=
GNU screen いろいろまとめ。 - naoyaのはてなダイアリー:
先日人力検索で GNU screen の設定TIPSについて質問してみたところ、かなーり役立つ設定とかをたくさん教えてもらうことができました。みなさん感謝。 そんで、教えていただいた通りにカスタマイズした結果、こんな感じのスクリーンショットが撮れました。MacOSX のターミナルです。 おかげさまでかなり便利になって作業効率が上がったと思います。いろいろ教えてもらったお礼とまではいきませんが、やった設定とかをはまりどころとかも交えて紹介してみます。名付けてリバースNDOメソッド。ちなみに、知ってる人にはごく当然のことが当たり前のように書いてるので、あんまり役に立たないかもしれません。 hardstatus alwayslastline で最終行にウィンドウ一覧を表示 これは今回の質問とは直接関係ないのですが、やるとやらないとでかなり使い勝手が違うので。 hardstatus alwaysl
naoyaのはてなダイアリー - 大規模サービスを展開する企業が陥るジレンマ
このところ大きなサービスを持ってる大きな企業が運用するウェブサイトについて考えることが多かったので、ちょっと書き殴ってみるとします。 一見すると大企業ってのは人もたくさんいるし資金もたくさんあるし、小さな企業と競争になっても、簡単にそれを踏みつぶしてしまえるような印象を受けます。いやいや、そんなに簡単じゃないんだよっていうのがイノベーションのジレンマであり、大企業病のジレンマであり。で、ウェブの企業にもう一つ当てはまるジレンマがあるなあと最近思います。 はてなダイアリーのキーワードページに、Yahoo! ニュースのトピックページからリンクされることがあります。そのニュースが Yahoo! Japan のトップページに載ってたりするものだと、キーワードページへの瞬間最大トラフィックが恐ろしいことになります。最近は対策を練ったので問題ないのですが、一時期は Yahoo! トップに載ってるニュー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
naoyaのはてなダイアリー - ライブドアのテクノロジーセミナーでしゃべってきました。
