BigQuery と Google の Big Data Stack 2.0 - naoyaのはてなダイアリー
先日、有志で集まって「BigQuery Analytics」という書籍の読書会をやった。その名の通り Google BigQuery について書かれた洋書。 BigQuery を最近仕事で使い始めたのだが、BigQuery が開発された背景とかアーキテクチャーとかあまり調べもせずに使い始めたので今更ながらその辺のインプットを増やして以降と思った次第。 それで、読書会の第1回目は書籍の中でも Overview に相当するところを中心に読み合わせていった。それだけでもなかなかに面白かったので少しブログにでも書いてみようかなと思う。 BigQuery の話そのものも面白いが、個人的には Google のインフラが書籍『Google を支える技術』で解説されたものが "Big Data Stack 1.0" だとして、BigQuery は Big Data Stack 2.0 の上に構築されており
些末なコードレビュー - naoyaのはてなダイアリー
朝起きて布団から出るのがつらいので、HBFav をつらつらと眺めていた。 あるサービスの JavaScript が重いとか、そのコードが難読化されてないとか、担当者とおぼしき人間が書いたコメントがそのまま残ってるから消しましょうよとか、そんなことが書かれていた。JavaScript が重い、という話は結局そのサービスの JavaScript が重かったのではなく、ユーザーが自分で導入した広告が重いというだけの話だった。 コードが難読化されていない、趣味の製品ではなく会社の製品なのでコメントそのまま残ってるから消しましょう･･･実にくだらない。 ところで話は変わってコードレビューについて。 コードレビューに慣れないチームが、何の考えもナシにコードレビューを始めるととにかく気になったこと大小様々な指摘が行われることになる。一見、いろいろな指摘が出て議論が活発になっているように見えるが、だいたい
テストエンジニアリング、DevOps のこれから #testingcasual - naoyaのはてなダイアリー
一昨日 Testing Casual Talks #1 に参加した。名前の通り、ソフトウェアテストに関するカジュアルなカンファレンス。とても面白かった。すこし思ったところを書いていこう。 テストのエンジニアリング トップバッターの @ikasam_a さんの発表では Software Engineer in Test at DeNA ということで、氏が勤務先でテストエンジニアリング部門を立ち上げていくにあたってのいきさつや背景といったところが述べられていた。 テストは開発者の生産性を向上するためにある、生産性向上のためにテストを書くテストエンジニア、近年複雑化するテストの実行環境を構築するのもテストエンジニアの役目、"Testing Activities SHOULD be in Developments" ─ テスト活動は (従来型のQAのように開発の外ではなく) 開発の中で行われるべき
AWS Summit Tokyo 2013 - naoyaのはてなダイアリー
一昨日、昨日と東京は品川で開催された AWS Summit Tokyo 2013 に行ってきた。 全般的な印象としてはエンタープライズトラックがたくさんあったし来場者もスーツを着た人も多くて、AWS を取り巻くステージは去年一年くらいで完全にエンタープライズ側に移行しきったんだなあ、というものだった。もちろんテクノロジートラックやコンシューマートラックもあって、技術的な実装やテクニックにフォーカスしたような話も方々でなされていたんだけど、多くの来場者の関心事は如何にしてクラウドをエンタープライズに導入するか、あるいはそれによってビジネスの課題を解決するかというところにあった、というのが肌感覚としてあった。 自分は AWS、というか IaaS はハードウェアを抽象化してソフトウェアでそれ全体を扱えるようにしたというところが本質的で、自動化、DevOps、あるいはプログラミングのための道具とし
Backbone.jsガイドブック - naoyaのはてなダイアリー
Backbone.jsガイドブックposted with amazlet at 13.05.07高橋 侑久 ラトルズ 売り上げランキング: 2,459 Amazon.co.jpで詳細を見る Backbone.js ガイドブックを一通り読みました。言及するか少し迷ったけど、まだあまり話題になっていないようなので書いておこうと思います。 Backbone.js あるいはこれによく似たようなフレームワークは今後、Webアプリケーション開発でよく使う道具になっていくと思う。というか、すでになっているでしょう。 Backbone.js は「クライアントサイドMVCフレームワーク」と呼ぶと良くわからない。クライアントサイドMVCフレームワークが注目される以前から、ある程度以上の規模の JavaScript アプリケーションになるとちゃんとしてるものは構造化が行われていた。イベントを集約するオブジェクト
Zopfli - naoyaのはてなダイアリー
Googleが今日（米国時間2/28）、オープンソースの新しい圧縮アルゴリズムZopfliをローンチした。今の標準圧縮技術であるzlibライブラリに比べて5〜8%圧縮率が高いといわれ、また解凍アルゴリズムは今のWebブラウザが現用しているもので間に合うため、Webサーバがこれを採用すれば、データの伝送速度が上がり、Webをやや速くすることができるだろう。 Google が出力が deflate 互換の圧縮アルゴリズムをオープンソースにしたというので、ちょっとタイムラインで話題になっていた。圧縮アルゴリズム周りにはまってた頃から結構時間が経ってしまって色々忘れてしまったけど、少しニュースを捕捉してみようと思う。 Zopfli は deflate 互換なので、deflate アルゴリズムを解釈できる実装なら伸張できる。当然ブラウザが持ってる deflate 実装で伸張できるので、エンドユーザー
Dash - naoyaのはてなダイアリー
Twitter で知人に紹介したら周囲から「これは便利」という声が結構聞こえてきたので、ブログでも紹介しておこう。Dash というドキュメントビューワー。 iOS や RubyMotion、あるいは node や ruby そのほかのマニュアルをまとめてインクリメンタルサーチして API を調べる、ということができる。メジャーな色んな言語に対応している。 本来 Dash は "Snippet Manager" ということで、コードスニペットを管理するためのアプリケーションのようだけど自分は単なるドキュメントビューワーとしてしか使っていない。RubyMotion の勉強会に行ったときに、これが便利というのを教えてもらってその後愛用しています。主に iOS の開発のときに利用していた。 http://satococoa.github.com/blog/2013/01/22/view-rdoc-
LTSV FAQ - LTSV って何? どういうところが良いの? - naoyaのはてなダイアリー
LTSV って何? Labeled Tab-Separated Values という、テキストのフォーマットの仕様です。CSV や TSV や JSON そのほかと同じ、テキストデータのフォーマット名。主にログ、特に httpd のアクセスログなどに適用すると便利です。 仕様は http://ltsv.org にまとまっています。随時更新中です。 LTSV は単なるログのフォーマットであって、それ以上でもそれ以下でもありません。 LTSV ってタブ区切りで値に名前を付けただけのもの? はい、そうです。 これが 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (
Vagrant - naoyaのはてなダイアリー
先日 Vagrant を触ってみたら便利すぎて鼻血が出ました。しばらく見ないうちに色々進んでるもんですねえ、いやはや参っちゃいました。 Vagrant は仮想マシンの VirtualBox のフロントエンドに相当する、ruby で書かれたツールです。vagrant コマンドなどを使ってコマンドラインから簡単に新しい VM を作れる。 % gem install vagrant % vagrant box add centos http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.3-x86_64-v20130101.box % vagrant init centos % vagrant upこれだけで CentOS の Linux box をローカルマシン内に立ち上げることができる。*1 *2 なにこれすごい。 % vagra
権限委譲、リーダーシップ、チーム - naoyaのはてなダイアリー
いいか、覚えておけ。おれにしてもお前にしても、それなりに成功するってことは、なにかは得意なんだ。でも大体のことは不得意極まりない。全部自分でやろうとするな。自分よりも何かで優れている人たちが、その何かでお前のためにチカラを貸したいと思うような人間になれ。 それがリーダーってもんだよ。 この記事が話題になってた。リーダーシップというのは力を貸してやろうと相手に思われることだという、いい話。 この手の話は、誰もが否応なしに社会で経験することだから、みんなそれぞれ自分の考えを述べたくなる･･･という話題でもありますね。例に漏れず、自分も少し経験から感じることを書いてみよう。 「権限」を「委譲」する? 「上司が何かを部下に任せる」という文脈でいくと、このストーリーは「権限委譲」の話にもみえる。確かにテーマとしてはそうなのだが、自分は一般で言う「権限を委譲する」という考え方そのものにちょっとした落と
Firefox OS - naoyaのはてなダイアリー
Firefox OS が面白そう、というので少し触ってみました。 Firefox OS はWeb 標準ベースの開発を基礎としたモバイル端末用プラットフォーム、要は HTML と JavaScript と CSS でアプリケーション開発できるモバイル端末用の OS。間もなく Developer Preview Phone な実機が発売されるというのでにわかに盛り上がりを見せているみたいです。 Firefox OS が目指すところは Web 標準による、開発者がロックインされないオープンなプラットフォーム。iOS や Android の昨今の状況を見れば、そのアンチテーゼになるプラットフォーム構想があってもおかしくないわけで、まさにそれを目指しているようですね。 いったいどんなものかという概観は dynamis さんによるスライドが分かりやすい。 Firefox OS from dynamis
Webはインターネットになった - naoyaのはてなダイアリー
先週金曜日にエンジニアサポートCROSS2013に行ってきた。目当ては @Jxck_ さんホストによる次世代Webセッション。セッション自体は前後半に分かれていて 前半はプロトコル編。SPDY (wikipedia) や HTTP/2.0 の動向やその課題点など 後半はアーキテクチャ編。プロトコルが変わった上で、その上で動くソフトウェアのアーキテクチャが云々 という内容でした。前半がより技術寄り、後半はテーマ的にもより広範の話題を扱うという感じでどちらも面白かった。 CROSS 2013レポート(2) - mad-pの日記 こちらに細かいログがあります。 話の前提になる SPDY や HTTP/2.0 周りの昨今については 【HTTP 2.0の最新動向】 第1回：HTTP/2.0の策定、ついに始まる - INTERNET Watch Watch 【HTTP 2.0の最新動向】 第2回：HT
エンジニアだからなんとか - naoyaのはてなダイアリー
昔から「エンジニアは営業が苦手」とか「エンジニアはデザインが苦手」とか、あるいは「エンジニアはコミュニケーションが苦手」というような言われ方が嫌いだった。 実際、営業が苦手なエンジニアというのはいると思う。でもそれはエンジニアだから苦手なのではなくて、単にその人が営業が苦手なだけだ。同じように、デザインに関してもコミュニケーションに関してもそうだ。 おおまかにそういう傾向があるということまでは否定はしない。例えばプログラミングのカンファレンスに行くとそこでは男性率が非常に高いし、全体としては、まあなんというかリア充とはちょっと違う雰囲気を醸し出している･･･というようなところがあってそれは誰もが感じることだろう。集団を集めて一般化してみるとそういう何かしらの傾向が現れる、ということまでは否定はしない。 でもやっぱり、その「エンジニアだから○○」という型にはめたような話を自分自身にあてがって
Titanium Mobile 2.0 対応など - naoyaのはてなダイアリー
Titanium Mobile がメジャーバージョンアップして SDK が 1.8 から 2.0.1 になりました。HBFav を SDK 2.0.1 に対応させる作業をひとまず終えたので、以下雑感など。 Titanium Mobile 2.0.1 で何が変わったか Release Notes http://docs.appcelerator.com/titanium/release-notes/?version=2.0.1.GA 大きな変更点はレイアウトシステムの更新です。加えていろいろとバグフィックス。ほかにも Appcelerator Cloud Services (ACS) という BaaS 連携が発表されていますが、純粋に SDK のアップデートというとレイアウトシステムとバグ修正が主なところ。Andorid位置情報対応の強化、Module API のアップデートもありますが、こ
Meteor.js - naoyaのはてなダイアリー
http://www.meteor.com/ で公開された Meteor.js を少し触ってみました。TechCrunch なんかでも話題になっていましたね。 Meteor.js は JavaScript によるウェブアプリケーションフレームワークですが、クライアントサイドでもサーバーサイドでもない、"Isomorphic" なフレームワークです。 コンセプトとしていくつか特徴があるのですが、その最たるものは "Reactive Programming" で、モデルやセッションなどのストレージを更新するとその更新内容がリアルタイムに、そのアプリケーションを開いている全クライアントに伝わるようなアプリケーションを簡単に作ることができます。 この辺は実例を見るのが早いです。 http://www.meteor.com/examples/leaderboard ここにある動画では、あるブラウザで
B木 - naoyaのはてなダイアリー
昨年から続いているアルゴリズムイントロダクション輪講も、早いもので次は18章です。18章のテーマはB木(B Tree, Bツリー) です。B木はマルチウェイ平衡木(多分木による平衡木)で、データベースやファイルシステムなどでも良く使われる重要なデータ構造です。B木は一つの木の頂点にぶら下がる枝の本数の下限と上限を設けた上、常に平衡木であることを制約としたデータ構造になります。 輪講の予習がてら、B木を Python で実装してみました。ソースコードを最後に掲載します。以下は B木に関する考察です。 B木がなぜ重要なのか B木が重要なのは、B木(の変種であるB+木*1など)が二次記憶装置上で効率良く操作できるように設計されたデータ構造だからです。データベースを利用するウェブアプリケーションなど、二次記憶(ハードディスク)上の大量のデータを扱うソフトウェアを運用した経験がある方なら、いかにディ
PDL で PageRank - naoyaのはてなダイアリー
id:smly さんが PageRank や HITS を Python で実装 されているのに触発されて、自分も PageRank を Perl で実装してみました。 PageRank の計算の中心になるのは Power Method (べき乗法) です。べき乗法では行列とベクトルの積を計算しますので、手軽に使える行列演算ライブラリがあると楽でしょう。 色々調べてみたところ、PDL (The Perl Data Language) が良く使われているようでしたので、これを選択しました。PDL では各種行列演算が簡単に行える他、文字列評価をオーバーライドして行列の文字列出力を良い具合で定義してくれていたりと、なかなかに便利です。PDL は行列計算以外にも色々な科学技術計算やグラフ描写などの操作をサポートしているようです。 さて、PDL を使った PageRank 計算のコードは以下のように
Introduction to Information Retrieval #9 の復習資料 - naoyaのはてなダイアリー
Introduction to Information Retrieval 輪読会 9章の復習資料を以下にアップロードしました。 http://bloghackers.net/~naoya/iir/ppt/iir_09.ppt 9章は、検索結果の適合性を改善するするための二つのアプローチ、Relevance Feedback (RF) とクエリ拡張についての話です。 検索結果のドキュメントに対してユーザーから追加の入力 (Relevant か Non-relevant か) を受け取るのが RF です。受け取ったフィードバックは、ベクトル空間でベクトルの重心を使ってクエリベクトルを最適化することに利用できます。最適化のアルゴリズムとして Rocchio アルゴリズムを利用します。ただし、特に Web 検索などにおいては、ユーザーは明示的なフィードバックを好みません。そこで、ユーザーからの入
Introduction to Information Retrieval #10 の復習資料 - naoyaのはてなダイアリー
Introduction to Information Retrieval 輪読会 10章の復習資料を以下にアップロードしました。 http://bloghackers.net/~naoya/iir/ppt/iir_10.ppt 10章は、は "XML retrieval" です。XML が題材になっては居ますが、実際には XML がどうこうというよりも、構造化されたドキュメント (structured document) に対して IR システムを拡張しようとすると、どのような困難があるか、それをどのように解決すべきか、拡張された IR システムはどう評価されるべきか、という話が主だったところです。 対象が structured な物である場合「その構造の中のどの部分を検索結果として返却すれば良いか」など、自明でない点が出てきます。XML retrieval であれば、XML docum
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
YAPC::Asia 2日目 「はてなブックマークのシステムについて」 - naoyaのはてなダイアリー
