少し遅くなったが、2011年のまとめを。こういうのは年末に書く人が多いみたいだが、まだ年を越してしないタイミングで書くのは今回は辞めておこうということで、いまさら。といっても、あんまり大した出来事はなかったかのように思う。内容は基本的にライフログ的な感じで使っていたtwitterを元にする。

1月〜3月

• なぜかAmazon プライムに申し込む。だが、ほとんどその価値は果たさなかった。
• 公開しているAndroidアプリの雑誌掲載依頼がくる。
• PC周りの小物の買い替え。ただ、マウスは結局使いにくくて新しいのは使っていない。
• 東日本大震災。
• 東日本大震災による本震・余震の震源地マップ(３日分)を作成。完全に人海戦術なので途中で諦めたhttp://yamablo.com/2011/03/13-223007.php
• みずほ銀行全面ストップ。
• 腰痛が再発症。
• 初めて終電なくなるまで仕事していて、タクシー帰り
• 同じ大学の友達がヨーロッパに1年間住むということで、そのまえに一緒に飲みに。
• 2011/04から東京で仕事をすることになった高校時代の友人と飲みに。かなり久しぶりに会った。

続きを読む

前回の記事の続きで, Google Developer Day 2011 Tokyoで午後に行われた個別セッションについて書いていこうかと思います.

まず午後に自分が聞いたセッションは以下の5つになります.

• デベロッパーツールのティップス アンド トリックス
• 今までにないサイトを作る：HTML5による最新ウェブアプリ
• HTML5のオフライン機能
• Googleエンジニアの日常
• Ignite

では順に感想や内容について書いていこうかと思います.

デベロッパーツールのティップス アンド トリックス

Developer Adovocateの北村氏によるセッション. このセッションでは, Google Chromeに搭載されている開発者向けツールであるDeveloper Toolに関する説明がメインになります. 似たような機能は, Google Chromeだけでなく同じWebKitベースで作られているSafariや, メジャー・ブラウザであるInternet Explorerにも搭載されており, またFirefoxに関してもアドオンFirebugで提供されています. しかし, これら他のブラウザの開発者ツールと比べて, Google Chromeの開発者ツールはいろいろな点で高機能に作られており, 他にはない機能に関しての説明がメインで行われました.

リアルタイムで編集を確認する

Developer Toolでは, HTML, JavaScript, CSSという3種類のリソースに関して, Developer Tool上で編集を行い, さらにそれをウェブブラウザ上にリアルタイムに反映させることができるようになっています. 今までであれば, エディタで編集を行い, ブラウザで開き確認し, さらにエディタに戻って修正し, ブラウザでページをリロードし, …と進めていたWeb開発が, ブラウザ上で進められるようになったので, うまく使いこなしてやれば, 開発効率が向上するのではないかと思います.

コードの最適化を進める

Developer ToolのTimelineや, Profileをうまく使うことにより, Webページのパフォーマンス上のボトムネックを探しやすくなりました. Timelineタブでは, 主にネットワーク処理の時間や, 描画(レンダリング)処理の時間をタイムライン上で閲覧することができます. また, ProfileタブではJavaScriptの実行時間や処理後との呼び出し回数や処理時間などをチェックすることができるようになっています. これらをうまく使うことでクライアント側にパフォーマンス上のボトムネックが存在する場合, そのボトムネックを特定しやすくなったようです.

続きを読む

先日横浜で開催されたGoogle Developer Day 2011 Tokyoに参加してきましたので, その感想やそこで得た情報などをブログに書き綴っていこうかと思います. 最初にGoogle Developer Day(GDD)とは, Googleが主催する開発者向けのテクニカル・カンファレンスで, Googleの提供するサービスを中心としたセッションが多く行われます. 今回のGDDでは, HTML5, Android, Google Chrome, Google+, App Engineについての話が繰り広げられていました.

10:00〜 基調講演の開始

まずは, Googleシニア・エンジニアリング・マネージャーの及川卓也氏の話から今回のGDDの開幕に関するお話などを. その後は, 登壇者が入れ替わりGoogleの注力しているAndroid, Google Chrome, Google App Engineの話へと移っていきます.

Androidのお話

Androidは現在, 137カ国で使われ, 利用台数は1日あたり50万台づつ増えているとのこと. また現時点で世界中のAndroid端末には累計で80億ものアプリケーションがインストールされるようになった. 別の指標として, App Installs Per User by OSというものも計測されているらしい. この指標は, Android OSのバージョンごとの1端末にインストールされているアプリケーションの数を意味しておりこの指標は, OSのバージョンが上がるごとに上がってきている. つまりVer1.5やVer1.6を使うユーザよりも最近のVer2.2やVer2.3を使うユーザのほうがより多くのアプリケーションをインストールしているといえる.

また, 講演の中では実際にセカイフォンと呼ばれるAndroidアプリケーションが紹介されました. このアプリケーションでは言語認識および翻訳によるコミュニケーションが行えるようです. 日本人とアメリカ人がそれぞれ母国語で通話を行うことができるように, 中間で相互翻訳を行ってくれるという機能があるようです.

さらにこの1年でのAndroid関連のトピックには以下がありました.

• アプリごとのパーマリングが用意された
• キャリアからの直接課金が可能になった
• In-App Billing(アプリ内課金)が可能になった

さらに今話題に上っているAndroid4.0(Icecream Sandwich)の紹介も行われました. Icecream SandwichではさらにさまざまなAPIが用意され, NFCによる情報共有やカメラAPIを元にした顔認証によるロック解除などが行えるようになったようです.

続きを読む

先日, 新宿の紀伊国屋に行ったときに見つけてしまった本, 「円周率 1000000桁表」. 値段はさすが円周率の本だけあって314円.出版者は, 怪しげな名前だが, 「暗黒通信団」だとか. かなり気になる本ですが, 中身は, 3.1415926535・・・と円周率がずらっと100万桁並んでいるだけの本のようです. しかし, 本の定価であったり, 刷数も3.1415刷とかでいたるところに円周率が使われているようです.

Amazonのレビュー

数学が大好きな息子のために買いました。 何の意味があるのか考えてしまう真面目な人には勧められません。 意味があるとか無いとかではなくて、そのものが美しいと感じられる人にお勧めします。

確かにこの本の意味とかを考えだしたら, 価値が一気に減ってしまいそうですよね.

某大型書店で見つけ、これはもう買うしかない！と思い衝動買いをしてしまいました。 値段もびっくりです。税抜きだと314円。素敵です。 私が購入したのは3.1415刷発行でした。

税込みでも1円あたり3,030桁以上が得られるコストパフォーマンスの良さ。 それにも関わらず表紙や中の紙に手を抜いておらず、 見るだけでなく触れるだけでも癒されます。 円周率が正規数なのかは未だ証明されていなかったかと思いますが、 100ページをパラパラとめくってゆくと、そんな些細な事はどうでもよくなってしまいます。

1000000桁もあるので十分に乱数として利用出来ます。 互いにこの本を持ち寄り、適当なルールを決めて使えば ワンタイムパッドとして極めて強力な暗号手段を創り上げる事が出来るでしょう。

一家に一冊、一人に一冊持っておいても損はしません。

ネイピア数のほうe―自然対数の底100万桁表も是非購入したいと思います。

1円あたり3,030桁以上のコストパフォーマンス・・・こんな考え方予想していなかった. たしかにこれはコストパフォーマンスはいいんだろうな. 一家に一冊, 一人に一冊は・・・損はしないのかもしれませんね.

続きを読む

Google Developer DayのDev Quizに関して, 既に締め切りからかなり経ってしまい今更な感じはありますが, どうせだしということで, 自分がどのようにスライドパズルに挑んだかを書いてみようかと思います.

問題文

幅が 3 マスから 6 マスで、高さが 3 マスから 6 マスのボードが与えられます。 各マスは、パネルが置かれているか、壁があるか、空白であるかのいずれかです。 パネルには 1 から 9 あるいは A から Z のいずれかの文字が書かれており、同じ文字の書かれたパネルは存在しません。 壁は 0 個以上存在し、空白のマスはただ 1 つだけ存在します。

空白は、上下左右のマスのパネルと入れ替えることができます。上のマスのパネルと入れ替えることを U とよび、同様に、下左右のマスのパネルと入れ替えることをそれぞれ D, L, R とよぶものとします。壁を空白やパネルと入れ替えることはできません。

パズルを解くというのは、与えられたボードの各マスを操作して、ゴール状態に持っていくことです。

ゴール状態とは、上の行から各行順番に、左から右に 1, 2, 3, 4, …, 9, A, …, Z という順にパネルが並び、最も右下のマスに空白が配置された状態のことです。壁のあるマスに対応するパネルは存在しません。例えば、左上のマスが壁であれば、ボード上に 1 のパネルは存在しません。

いま、使うことができる L, R, U, D それぞれの総数があたえられます。 この総数は全パズルで共有されています。 例えばあるパズルを解くために L を使い切ってしまった場合、 他のパズルでは L を使うことはできません。 この総数を超えないようにしながら、なるべくたくさんのパズルを解いてください。

実際に与えられた問題は合計で5,000問あり, かなりの量の問題を解く必要があります。

自分の書いたプログラムの概略

まずは用いたプログラミング言語はC++になります. ほかの問題なんかでは, プログラムの書きやすさなどからPHPを使ったりしたものもあるのですが, こういったプログラムの書きやすさより, アルゴリズムやデータ構造部分が変更しやすかったり, 実行速度そのものが早かったり, メモリの確保できる容量に制限のないC++のほうが向いているという判断です.

パズルの局面探索ということで, おおまかなアルゴリズムとしては, 幅優先探索を採用. ただし, 幅優先探索で素直に実装してしまうと, 探索空間の大きさが半端なく大きいことから, メモリが足りなくなってしまったり, 計算時間が膨大になってしまうことから, いろいろな工夫が必要になります.

まずは深さに制限を与えることから

メモリが足りなくなってしまう点を打開するために, まずはある程度の深さまで探索を行い, 解を得られなければその問題に関しては解を得ることを諦めて次の問題にいくようにします. また問題を与えられた時点で, 問題のサイズが大きければその時点で解の探索すら行わないようにすることで, 50問くらいを解くことができたようです.

続きを読む