Aho Corasick 法 - naoyaのはてなダイアリー
適当な単語群を含む辞書があったとします。「京都の高倉二条に美味しいつけ麺のお店がある」*1という文章が入力として与えられたとき、この文章中に含まれる辞書中のキーワードを抽出したい、ということがあります。例えば辞書に「京都」「高倉二条」「つけ麺」「店」という単語が含まれていた場合には、これらの単語(と出現位置)が入力に対しての出力になります。 この類の処理は、任意の開始位置から部分一致する辞書中のキーワードをすべて取り出す処理、ということで「共通接頭辞検索 (Common Prefix Search)」などと呼ばれるそうです。形態素解析、Wikipedia やはてなキーワードのキーワードリンク処理などが代表的な応用例です。 Aho Corasick 法 任意のテキストから辞書に含まれるキーワードをすべて抽出するという処理の実現方法は色々とあります。Aho Corasick 法はその方法のひと
テストエンジニアリング、DevOps のこれから #testingcasual - naoyaのはてなダイアリー
一昨日 Testing Casual Talks #1 に参加した。名前の通り、ソフトウェアテストに関するカジュアルなカンファレンス。とても面白かった。すこし思ったところを書いていこう。 テストのエンジニアリング トップバッターの @ikasam_a さんの発表では Software Engineer in Test at DeNA ということで、氏が勤務先でテストエンジニアリング部門を立ち上げていくにあたってのいきさつや背景といったところが述べられていた。 テストは開発者の生産性を向上するためにある、生産性向上のためにテストを書くテストエンジニア、近年複雑化するテストの実行環境を構築するのもテストエンジニアの役目、"Testing Activities SHOULD be in Developments" ─ テスト活動は (従来型のQAのように開発の外ではなく) 開発の中で行われるべき
Witch - naoyaのはてなダイアリー
マック OSX のアプリケーション・ランチャでは、quicksilverが文句無く使いやすいのですが、すでに立ち上げたアプリケーションのwindow切り替えは、コマンド+TABだとイマイチ。複数のターミナルを立ち上げたり、複数のTextファイルを開いている時などに、各アプリーケションの特定のウィンドウを指定するスイッチャを探していたら、Witchというソフトが有名なよう。これは結構使いやすいですね。 Windows → MacOSX に Switch して困ることの一つが Alt + Tab のウィンドウ切り替えの挙動の違い。Commad + Tab の Mac の切り替え機能はなんか痒いところが痒いままで手が届かない! Alt + Tab 厨な僕としては是非この挙動を何とかしたいと思ってたところ Witch というやつで改善できるとのことだったので導入してみました。 アプリケーションごと
naoyaのはてなダイアリー - WebService::KakakuCom
本日、価格.com WEBサービスの第一弾として、価格.comから商品検索とアイテム情報取得用のAPIと、食べログ.comから、レストラン情報を取得するAPIを一般公開しました。 今回のリリースでは、ユーザやアプリケーション登録が必要ありません。是非気軽にお試し下さい。 なんかウェブサービスがいろいろリリースされる季節ですね。ということで気軽に試してみましたよッ! http://bloghackers.net/~naoya/lib/perlmodules/WebService-KakakuCom-0.02.tar.gz http://trac.bloghackers.net/browser/lib/perl/WebService-KakakuCom/trunk 昨日の RakuAPI のとコードが相当似てる。 NAME WebService::KakakuCom - Handle WebA
naoyaのはてなダイアリー - MySQL の負荷分散に LVS + keepalived を使う
あとで書く、と言った手前なので書くとします。 DSASの中の人がすごい勢いで LVS の話を書いてくれてます。この辺。LVS を使うと Linux と箱でロードバランサが作れちゃいます。普通に買ったら数百万とかしちゃうやつ。 DSAS の中のひとに感謝しつつ、いい機会なのでやってみよう! と思っていろいろ試して昨日あたりからはてなの中でも LVS + keepalived で動かしはじめてます。いまのところ問題なし。 そのロードバランサをどこに使ってるかですが、普通ロードバランサというとインターネットからの入り口のところに置いてウェブサーバーの負荷分散に使うイメージがあります。が、今回ははてなでは MySQL のスレーブの手前に置くという役割でとりあえず使いはじめました。 +-----------+ +-----------+ | mod_perl | | mod_perl | +----
Flickr の認証API - naoyaのはてなダイアリー
認証API をどうするか、ということで数名のスタッフであれこれ話ながらやってます。 まず、はてなの認証APIを使って何ができるといいのかというところですが、はてなラボをオープンしたときにいただいた意見などを見ると、「はてなのAPIで認証付きのをセキュアに利用するための API」というより「サードパーティのアプリケーションではてなIDでユーザーを識別できるためのAPI」の方が求められているという風に思いました。 具体的には、新規にユーザーを識別する必要のあるアプリケーション、例えば掲示板などを作るとして、その掲示板のユーザーを一意に識別する方法としてはてなIDを使いたい、そのIDが本当にその人のものであるかどうかをはてなが保証する、その保証を問い合わせるための API ですね。その掲示板でログインして何かを書き込むと id:naoya、と表示されると。 この手の認証APIを提供しているサービ
3年前の自分は別人、を他のひとにも当てはめてみる。 - naoyaのはてなダイアリー
自分の3年前を思い出すとまさに別人であり、5年後のことなんてわかるはずもない、なんてことを以前にもちょっと書きました。 はてなに入社して一年半ぐらいが経ちましたが、技術はもちろんそれ以外にもその間に得た物もの相当大きくてやっぱりその時と比較して今の自分は別人だなあと思います。 これは自分だけじゃなく、周囲を取り巻く人という人すべてがそうであって、そういう風に考えるといろんなものが見えてくる。 僕は近頃「初心者」という言葉の使い方に気をつけるようにしています。 特にウェブアプリケーションを作るなんて話で議論になると「初心者」という単語が良く出てきます。「初心者にもやさしい」とか「初心者でも扱えるように」とか。でも、初心者っていうのは3年後は初心者じゃない。上級者は3年後も上級者だろうけど。そして本当に初心者である期間はほんとに短い。だから「初心者にわかりやすい」みたいなところを中心に議論を進
naoyaのはてなダイアリー - サーバーを増やせばいいんじゃない、サーバーを増やすだけで解決できるように努力するのだ
ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増
submit ボタン disable 技の罠 - naoyaのはてなダイアリー
昨日のonsubmit で submit ボタンを disable にしてユーザビリティを良くするにはちょっとした罠があって、それに気付かずに使うとはまってしまうかもしれないので、それもちょっと書いておく、というか今日僕自身がはまったわけだが。 罠というのは、type="submit" な input 要素、つまりは submit ボタンを onsubmit ハンドラで disable するまでは良いのですが、このとき <input type="submit" name="foo" value="bar">としていて、foo=bar という値が渡ってくることを期待し、それを内部の処理に使っていると嫌な目に逢う、という話です。先のやり方では input 要素が disable になって GET なり POST なりされるので、押したボタンに対応するパラメータが渡ってこない、というわけです。一
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
