アップル厨の俺が2013年に買って良かったものまとめ - naoyaのはてなダイアリー
自他共に認めるアップル厨の俺が2013年に買って良かったもの、それは･･･ アップルピーラー。これはすごい なんと皮が3秒で剥ける!! 本当に3秒です。軸に挿してレバーを回すだけ!! 過去何百個もナイフで皮を剥いてきた自分も、これにはびっくりです。でも、お高いんでしょう? いいえ! Amazon.co.jp ならなんと 1,399円。 さて、この季節と言えばやはりサンふじですね。サンふじと言えば長野県産、青森産などが定番だと思いますが東北出身の私としてはぜひ青森県産のものをオススメしたいところです。ちょっと気が早って11月上旬くらいに 5kg を注文したのですが、さすがに11月上旬ではまだピークに到達しておらず、甘さは十分なもののサンふじのあのシャキシャキ感が不足していました。 が、今月12月に入ってからは万全です。シャキシャキ感と甘みが高次元で両立しています。本当に美味しい。私も朝晩毎日
AWSブログを3行でまとめる試み : Route53 にDNSフェイルオーバー機能が追加 - naoyaのはてなダイアリー
DNSフロントエンドサービスのRoute53でフェイルオーバー機能が使えるようになったぞ Route53に参照先へのHTTP/TCPヘルスチェックがついて、ダウンしたとき用のレコードを登録できるぞ S3 で静的ページ作ってバックアップサイトにしとくといいかもね。ヘルスチェックの詳細は Route 53 Developer Guide をチェケラッ cf: http://aws.typepad.com/aws_japan/2013/02/create-a-backup-website-using-route-53-dns-failover-and-s3-website-hosting-.html コメント ヘルスチェックもついてるので EC2 インスタンスを2台作って冗長性を持たせるというのにも使えるだろうけど、それなら ELB を使えば良いので、解説にもある通り S3 で静的ページが現実的
【今北産業】3分で分かるLTSV業界のまとめ【LTSV】 - naoyaのはてなダイアリー
id:stanaka がはてなで使って居るログフォーマットが LTSV だよーとブログに書く Labeled Tab Separated Values (LTSV) ノススメ - stanaka's blog Web界隈のエンジニアたち、特にログとか、#fluentd 関係者がざわつく 「ざわ・・・ざわ・・・」 @t_wada 「Unix 哲学の大事な点が形になっていると思う。素晴らしい。」 @hotchpotch 「cool」 六本木、渋谷、白金台方面から京都へ熱い視線が送られる id:naoya がただ vagrant + chef を使いたいがために LTSV に乗っかる GrowthForecast を使っていたため GF の中の人が反応する @kazeburo 「[growthforecast]」 id:naoya が勢いで Text::LTSV を作る あまり反応がないのでしょ
RubyMotion で AWS iOS SDK を使う (もしくは Objective-C ライブラリの使い方、あるいはドラクエ10について) - naoyaのはてなダイアリー
ポロン「右手からRuby･･･」 ポロン「左手からiOS SDK･･･」 ポロン「合体!!!」 ポロン「魔力解放 RubyMotion!!!!」 ･･･いやぁロト紋、懐かしいですね。こんにちは。みなさんドラクエ10やってますか！ぼくは全職カンストなのでやってません！あと数日で公開のパッチ1.2を待ち焦がれています。次のアップデートに期待してるのはなんといっても魔法戦士ですよね。以前にみたところによると魔法戦士にはMPを他のプレイヤーに分け与えるMPパサーという職業スキルがあって、パラディンのHPパサーが専用じゃなかったようにこれも非専用スキルのようです。と、いうことは！余ったMPを武闘家なり盗賊なりに分けて無限タイガークローなんてことが可能そう。これは熱い･･･当初予定のMPパサーの仕様に修正が入らなければ、ですけど。スティック100に振ってる自分としてはスーパースターがスティック装備可能
書籍『「超」入門 失敗の本質』を批判する - naoyaのはてなダイアリー
先日『「超」入門 失敗の本質』(鈴木博毅、ダイヤモンド社、http://www.diamond.co.jp/book/9784478016879.html) という書籍を読みました。こちら、ダイヤモンド社の今週の週間ランキングでも一位のようですし、都内の複数書店でも平積み特設コーナーで扱われておりビジネス書として注目を集めているのでしょう。 内容としては、"累計５２万部突破、今もっとも注目される組織論の名著を、若手戦略コンサルタントが２３のポイントからダイジェストで読む。" とある通り位置づけとしては第二次世界大戦前後の旧日本軍の組織分析について書かれた『失敗の本質―日本軍の組織論的研究 (中公文庫)』に対する入門書という位置づけです。 結論から言いますと、この本には幾つかの点で個人的に首をかしげざるを得ないところがあると感じました。原典がある書籍である以上、そこは比較した上、原典の側に立
ダイアリーのデザイン変更 / Meteor.js でスタイル変更作業 - naoyaのはてなダイアリー
この頃このダイアリーを時折更新していますが、改めて見てみるとデザインが野暮ったかったので、変更しました。Readability を通して読んだときのスタイルが非常に読みやすいので、そのスタイルをパ･･･参考にしました。 ちょっとまだ一部スタイルが当たってないところもありますが、基本はこの路線で。Chrome、Firefox、Safari では確認済み。Windows と Opera では見ていないのでどうなるかわかりません。 どうやって変更したか ダイアリーの管理画面にスタイルを入力してプレビューで･･･とちまちま変更していくのは流石に大変なので、やり方を少し工夫しました。先日触った Meteor.js を使って先に簡単なアプリを作って、そのアプリ上で変更してできあがった CSS を管理画面に貼り付ける、というもの。 以下、そのソース。 https://github.com/naoya/m
グリー株式会社に入社しました - naoyaのはてなダイアリー
昨日は退職の挨拶にブックマークや Twitter などで多数のコメントをいただきました。改めて、自分がたくさんの人に支えられていることを実感し、自分は幸せ者だなと感じました。本当にありがとうございます。 いただいたコメントで「次はどこへ」というご質問を多数いただきましたので、報告させてください。 本日より、グリー株式会社で働きます。 グリーのサービスのビジョンは「インターネットを通じて、世界をより良くする。」というメッセージに集約されています。 インターネットが本格的に世の中に普及してすでに10年以上の年月が立ちますが、まだまだ、それが秘める体験は世の中の人々に届いていないと感じます。ここ何年かの間に、ブログや SNS、ソーシャルゲーム、ソーシャルメディアなどの大きなトレンドがあって、その中で各サービスがその体験を補完する形で立ち上がってきました。 これから10年20年、自分がやるべきこと
退職のお知らせ - naoyaのはてなダイアリー
本日8月31日をもって、はてなを退職しました。 入社は2004年9月1日でしたから、今日でちょうど6年です。6年間の間に、はてなブックマークをはじめとする各種サービスの企画開発やディレクション、インフラの構築、技術チームのマネジメント等々、色々な経験を積むことができました。その一方で、なかなか自分の思うようにはサービスを成長させる、会社を伸ばすことができず自分の力量不足を感じる毎日でもありました。その足りない能力と経験を埋め合わせる日々が、成長を促してくれたとは思います。 この6年は、はてなという会社が、個人あるいは家族のような繋がりから組織に変っていく過程でした。会社というものが何なのかを全然知らなかった自分が、Webサービスの開発と運営に、組織がなぜ必要かというのを体で知ることになりました。なかなかに得難い経験でした。 遠回りもありましたが、はてなは組織になりました。新サービスは日々ユ
「Web開発者のための大規模サービス技術入門」という本を書きました - naoyaのはてなダイアリー
自分が作ったWebサービス、将来大きくなってもシステムは大丈夫なんだろうか? そんな不安を抱きながらWebサービス開発に携わっている方も多いでしょう。あるいは、毎日毎日システムが悲鳴を上げる、どうしたらこの状況を看破できるんだろう? 成長したWebサービスを前に、困っている技術者の方もいるかもしれません。 筆者も、まったく同じ経験をしてきました。 月間1,500万人が訪れる、はてなというサイト。その大規模システムの開発と運用に、筆者らは取り組んでいます。1,000台のホストが、その負荷を捌きます。100万人以上のユーザによってブログやソーシャルブックマークに投稿され続けるデータは日々大きくなっていき、サーバリソースを逼迫させます。ギガバイト、テラバイト単位のデータ量が技術者たちを悩ませます。それでもトラフィックの波は収まることを知りません。 (中略) どうしたらこの怪物、大規模サービスを抑
はてなブックマーク経由でTwitterに投稿、の新機能 - naoyaのはてなダイアリー
Twitter に URL を投稿するとはてなブックマークにもポストされる Twitter 連携機能。以前からありました。便利だけど･･･ はてなブックマーク側に「asahi.com: うんたらかんたら」というタイトルだけのコメントが流れるのがやだな Twitter 側に [twitter][bookmark] とかタグが流れるのは微妙だなー。設定でオフにできるのは知ってるけど 今回の URL ははてなブックマーク側に流したくないんだけど、それを回避する方法が欲しいなあ Twitter に投稿してからはてなブックマーク側に同期されるまで結構タイムラグがあるのが気になるんだよなあ。せっかく1getしてるのにー こんなところが気になる、という方も多かったんではないでしょうか。 まるっと解決 本日リリースしました、Twitter連携機能強化がこの辺のお悩みを、まるっと解決します。これまでは Tw
BWT と PPM - naoyaのはてなダイアリー
Burrows Wheeler Transform (BWT, Block-sorting) と Prediction by partial matching (PPM) は本質的に同じ事をやっている、というお話です。 先日 Managing Gigabytes を読んでいたところ、P.69 で "block sorting is very closely related to the PPM* method, which is a variant of PPM that allows arbitrary-length contexts." という記述があり、どうにも気になったので調べてみました。 サマリとしては、BWT と PPM の一種である PPM* はいずれも文脈から次の1文字を一意に決定するという概念で見ると本質的に同じことをやっていると言える、というところです。 BWT のあら
Canonical Huffman Codes での符号長の効率的な計算 - naoyaのはてなダイアリー
週末に参加した Managing Gigabytes の読書会で第2章のハフマン符号を担当しました。この中で Canonical Huffman Codes の解説がありますが、そこにハフマン符号の符号長を効率的に求める手法の説明が含まれています。 輪講では時間切れのためこのアルゴリズムの解説が駆け足になってしまいましたので、改めて解説資料を作ってみました。2009 年の今に Managing Gigabytes を読んでいるという方はあまり多くないかもしれませんが、参考になれば幸いです。 https://www.dropbox.com/s/539fhyc7rf6b9ik/090518computing_huffman_code_length.ppt?dl=0 (PPT, 258K) 先日 Canonical Huffman Codes の習作を Python で実装しましたが、このコード
Logarithmic merging - naoyaのはてなダイアリー
IIR の第4章 Dynamic indexing では検索用のインデックスにおいて対象とする文書に頻繁に更新が発生する場合にどうそれを扱うべきかという話題を扱っています。ここで "Logarithmic merging" という話が出てきます。以前に読んだ際に良く理解できなかったので、改めて復習してみました。 Dynamic indexing 頻繁に検索対象の文書群に更新が発生する場合の問題点は、(postings ファイルはディスク上にあるので) 転置インデックスをその都度構築し直すコストが高くなってしまうというところです。かといって更新をしないと、検索結果が古いままでヒットすべきものがヒットしなくなってしまいます。そこで Dynamic indexing の戦略を採ります。ディスク上の大きなインデックスであるメインのインデックスに加えて、インメモリの小さな補助インデックスを用意し、更
Canonical Huffman Codes - naoyaのはてなダイアリー
1999年出版と少し古い書籍ですが Managing Gigabytes を読んでいます。理解のために 2.3 で出て来る Canonical Huffman Codes の習作を作りました。 ハフマン符号は情報圧縮で利用される古典的なアルゴリズムで、圧縮対象データに出現するシンボルの出現確率が分かっているときに、その各シンボルに最適な符号長の接頭語符号を求めるものです。 通常のハフマン符号はポインタで結ばれたハフマン木を構築して、ツリーを辿りながら各シンボルに対する接頭語符号を計算します。このハフマン木には曖昧な箇所が残されています。ハフマン木は木の辺を右に辿るか左に辿るかで符号のビットが決まりますが、右が 0 で左が 1 などというのはどちらでも良いという点です。(曖昧だから駄目、という話ではありません。) 従って、ハフマン木から生成される符号は一意には決まりません。 ここで各シンボル
Aho Corasick 法 - naoyaのはてなダイアリー
適当な単語群を含む辞書があったとします。「京都の高倉二条に美味しいつけ麺のお店がある」*1という文章が入力として与えられたとき、この文章中に含まれる辞書中のキーワードを抽出したい、ということがあります。例えば辞書に「京都」「高倉二条」「つけ麺」「店」という単語が含まれていた場合には、これらの単語(と出現位置)が入力に対しての出力になります。 この類の処理は、任意の開始位置から部分一致する辞書中のキーワードをすべて取り出す処理、ということで「共通接頭辞検索 (Common Prefix Search)」などと呼ばれるそうです。形態素解析、Wikipedia やはてなキーワードのキーワードリンク処理などが代表的な応用例です。 Aho Corasick 法 任意のテキストから辞書に含まれるキーワードをすべて抽出するという処理の実現方法は色々とあります。Aho Corasick 法はその方法のひと
HITS, 主成分分析, SVD - naoyaのはてなダイアリー
ウェブグラフのリンク解析によるページの評価と言えば PageRank が著名ですが、もうひとつ Jon Kleinberg による HITS (Hyperlink-induced topic search)も有名です。最初の論文 Authoritative Sources in a Hyperlinked Environment は 1999年です。IIR の 21章で、この PageRank と HITS についての解説がありました。 HITS HITS はウェブページの評価に二つの軸を用います。一つが authority スコア、もう一つが hub スコアです。 例えば「Perl の情報が欲しい」という検索要求に対しては CPAN や 開発者である Larry Wall のホームページなどが重要度の高いページかと思います。これらのページは「Perl に関して信頼できる情報源」ということ
Latent Semantic Indexing - naoyaのはてなダイアリー
情報検索におけるベクトル空間モデルでは、文書をベクトルとみなして線形空間でそれを扱います。この文書ベクトルは、文書に含まれる単語の出現頻度などを成分に取ります。結果、以下のような単語文書行列 (term document matrix) が得られます。 d1 d2 d3 d4 Apple 3 0 0 0 Linux 0 1 0 1 MacOSX 2 0 0 0 Perl 0 1 0 0 Ruby 0 1 0 3 この単語文書行列に対して内積による類似度などの計算を行って、情報要求に適合する文書を探すのがベクトル空間モデルによる検索モデルです。 見ての通り、単語文書行列の次元数は索引語の総数です。文書が増えれば増えるほど次元は増加する傾向にあります。例えば索引語が100万語あって検索対象の文書が 1,000万件あると、100万次元 * 1,000万という大きさの行列を扱うことになりますが、単
CodeZine にて KOF 2008 の記事と補足 - naoyaのはてなダイアリー
大阪南港ATCで開催された「関西オープンソース2008」の2日目（11月8日）午前中のセッションで、株式会社はてなCTOの伊藤直也氏が「はてな流大規模データ処理」と題した発表を行った。 CodeZine で先日の KOF 2008 (あらかじめ言っておきますが King of Fighters ではないですよ、関西オープンフォーラムです) の発表を記事にしていただきました。ありがとうございます。 発表資料は以下のエントリーにありますので一緒にご覧いただければと思います。 http://d.hatena.ne.jp/naoya/20081111/1226395400 さて、記事内容について少し補足をしておきたいと思います。 メモリとディスクの速度比較について 「メモリはディスクの 150 倍」という話ですが、その後知人と話して検索のインデックスをシークする場合などは ms 対 ns くらい違
Burrows Wheeler Transform と Suffix Array - naoyaのはてなダイアリー
,. -‐'''''""¨¨¨ヽ (.＿＿_,,,... -ｧァﾌ| あ…ありのまま 今日 起こった事を話すぜ！ |i i| }! }} /／| |l､{ j} /,,ｨ//｜ 『BWT について調べていたら Suffix Array のライブラリができていた』 i|:!ヾ､_ﾉ／ u {:}//ﾍ |ﾘ u' } ,ﾉ _,!V,ﾊ | ／´fト､_{ﾙ{,ィ'ｅﾗ , ﾀ人 な… 何を言ってるのか わからねーと思うが /' ヾ|宀| {´,)⌒`/ |<ヽﾄiゝ おれも何をされたのかわからなかった… ,ﾞ ／ )ヽ iLﾚ u' | | ヾｌﾄﾊ〉 |／_／ ﾊ !ニ⊇ '／:} V:::::ヽ 頭がどうにかなりそうだった… /／ 二二二7'T'' ／u' __ /:::::::/｀ヽ /'
Integer::Elias - Elias gamma/delta coder - naoyaのはてなダイアリー
Perl でγ符号、δ符号で整数を符号化するためのモジュールを作りました。(ω符号はまだサポートしていませんが) Elias 整数符号のモジュールなので Integer::Elias という名前にしています。 http://github.com/naoya/perl-integer-elias/tree/master γ符号、δ符号は整数の可変長符号です。バイト単位での可変長符号は ASN.1 BER (id:naoya:20080906:1220685978 参照) がありますが、γ符号、δ符号はビット単位での可変長符号で、より短いビット数で小さな整数を符号化することができます。 例えば 6 という数字があったとします。 6 の二進数での表現は 110 で 3 ビットです。110 の先頭ビットを除いたビット 10 で 2ビットあります。このビット数 2 を α符号 (Unary code
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
