谷口です。

5月も恒例の旨いものの会を開催いたしました。
今月は社内（SINAPオフィス内）での開催で、お取り寄せで注文した品々や近くのお店で買ったものを美味しくいただきました！

今回取り寄せた料理はそれぞれ以下の通りです。

うなぎのちまき

• 四万十屋
• http://www.shimantoya.com/

今回のメインの料理です！･･･が量が少なかったかな･･･？
左の画像の手前ブルーの皿に盛られているのがうなぎのちまきです。
たれとうなぎともち米のハーモニー、とても美味しかったです！

惣菜いろいろ

• 明惣（【みょうそう】と読みます）
• http://mart.gnavi.co.jp/myousou_biz/

こちらは和惣菜を多く取り扱っているお店で、季節ごとに目玉商品が変わるようです。（今回はほたるいか系のお料理でした。）
思っていたより量があって非常に満足でした！

ちなみに、取り寄せた惣菜は以下。

• 切干大根煮（中画像手前の角皿）
• 鶏肉と大根の旨煮（中画像左側の丸皿）
• 牛肉と糸こんにゃくの炒め煮（中画像右側の丸皿）
• こんにゃくのピリ辛炒め（上画像白い角皿の1番左）
• ほたるいか甘露煮（上画像白い角皿の左から3番目）
• ほたるいか沖漬け
• ほたるいか甘酢漬け
• 【サービス品】滑川産小アジの南蛮漬け（上画像白い角皿の左から2番目）

その他近所モノ

• カツサンド（まい泉）
• 焼き鳥（鳥武）
• サラダ（R1/F）

定番的な。

すいーつ

• 白巻き（はらロール）（下画像）

これまた定番的な。

終わりに

参加してくださった方々ありがとうございました！
私個人はとても楽しかったです。（途中仕事で抜けたりしましたけど･･･）
次回もまた是非ご参加ください！

天方です。

それでは、アルゴリズム講座第2回をはじめたいと思います。

おかげさまで、前回の講座では、公開後、たくさんの知り合いの方から声をかけていただきました。

やはりアルゴリズムがモテるということを実感した第1回講座でした。

さて、今日は、Google App Engine(GAE)で利用を検討したアルゴリズムについて紹介したいと思います。

GAEでは、プログラムをする際に、クラウドの特性を意識する必要があるのですが、それは、アルゴリズム、特に並列アルゴリズムの知識を生かすには非常によい環境ともいえます。

はっきりいいます。GAEでアルゴリズムができるとモテます。

この講座を通じて少しでも皆様にモテをおすそ分けできたらと思います。

さて、本日も前回と同様、アルゴリズムとデータ構造に着目しています。

GAEでは、データを格納するストレージとしてRDBMSを使う代わりにBigTableという分散Key-Value Storeを使っています。

この分散Key-Value Storeは、クラウド環境で性能をスケールさせるためには非常によいデータの格納方法なのですが、RDBMSのようなリレーションを使った機能がないという問題があります。

やはり性能をスケールさせることを中心に考えているからですが、その分、プログラマーの方が余裕をもって、しっかりマメにケアしてあげることが必要になってきます。余裕のあるマメな男がモテるのと同様です。

例えば、データは複数のコンピュータにまたがって保持されているため、RDBMSのようにソートなどを効率的に行うことができません。

ではどうするのかというと、事前にソートした結果を持っておき、ソート結果を使いたいときは、その結果のデータを見ればいいのです。GAEのDatastoreではそういったソート機能があります。

今回は、Datastoreのソート機能そのものではありませんが、そういった分散環境で使えるかもしれないSkip Graphというソートアリゴリズムについて紹介したいと思います。

Skip Graphを理解するには、そのより単純なバージョンであるSkip Listについて考えるとわかりやすいです。

SkipListのデータ構造は以下のようになっています。

Ｓｋｉｐ Listのデータ構造

ところで、この図を見て何かに似ていると思いませんか？

お気づきの方もいるでしょう。普通と急行がある電車の路線図に似ています。

Skip Listはまさに、この電車の乗り換えのアナロジーで考えられます。

電車でどこかに行きたいなら、まず急行などの途中の駅を飛ばす列車に乗り、近くの駅まで来たら普通列車に乗って目的の駅に行けば、停車時間が短縮でき早くつくのです。デートの約束の時間に遅れずにつくのもモテる男としては当然ですよね。

Skip Listの図の例だとlevel2のレベルで自分の移動したいノードの近くまで、リンクをたどり、近くまできたら次にlevel1におりてリンクをたどり、最後にlevel0で目的とするノードにたどり着けばいいということです。

電車と同じようにSkip Listでも、上のレベルのリンクを利用することで、高速に、ソート済みのデータを検索したり、項目を追加したりできます。

と、こんなアナロジーで、新入社員にSkipListの説明をしてあげたら、この先輩の説明はクールだなとモテまくります。

この図のSkip Listのデータ構造を数式で表すと

ソートする値の集合とした場合、

のように表現できます。

ここではデータ構造を説明するためには便宜上左から右に大きくなっていくものとします。

Skip Listでは、例えば、以下のようなデータ構造で、この値を表現します。

この図では、各ソートする値をノード、レベルとして、右側へのリンクリストを、左側へのリンクリストがあります。

リンクリストは、下からレベル0, 1, 2のようにレベルがあり、レベル0では、大小関係が維持されたまま、隣同士のノードで双方向にリンクされています。

レベルが上がるほど、途中のノードを飛ばしてリンクされています。

この状態で、Skip Listはソートがされている状態であると言えます。

もし、昇順にデータがほしいなら、左の端から、Level0のリンクをたどってノードを見ていけば、ソートされている結果が得られます。

つまり、このデータ構造を作ることができれば、ソートはされているということになります。

このデータ構造をどのように作るかはひとまず置いておいて、

ある値を検索する場合の方法について考えたいと思います。

この操作の計算量はノード数をとした場合、平均です。

というのは、別の表現をすると、となります。

これは、ノード数と計算時間の対応関係を表で表すと次のようになります。

つまり、ノード数が指数的に増加しても、検索にかかる計算量は比例しては増加しないということです。

では、次にSkip Graphについて説明したいと思います。

Skip Graphは、Skip Listの拡張版だといえます。

Skip Graphではレベル1以上のノード間のリンクの仕方が違います。

Skip Listでは、スキップされたノードはそのレベルではリンクを持たないのですが、Skip Graphでは、リンクを持つ場合があります。

例えば、下記のようなデータ構造になります。

Skip Graphでは、検索をする場合には、どのノードから初めてもいいことになります。

最初のノードが決まったら、Skip Listと同じように上位のレベルから下位のレベルに向かって探したいノードに向かって移動していきます。この計算量もやはり平均です。

さて、いままでデータの検索の方法について扱ってきましたが、ではこのデータ構造をどのように作ればいいのでしょうか。

その方法について説明したいと思います。

1. まず、ノード間のリンクの仕方についてですが、ここでは、メンバーシップベクタ関数を使って確率的にリンクします。メンバーシップベクタ関数は、によって決まる2進乱数列です。このM(n)の乱数列の長さは無限に続くのですが、Skip Graphで利用するのは長さまでです。
   
   の生成方法には決まった方法がありますので、方法を考える必要があります。
   
   このを各ノードについて計算しておきます。
   
   ≒なので、メンバーシップベクタの桁数は2桁か、3桁となります。図では2桁にしています。
2. さて、計算し終えたら、リンクします。リンクするルールは次の様にします。
   
   1. まずレベル0では、すべてのノードにおいて、隣接するノードとリンクします。
   2. 次にレベル1では、メンバーシップベクタの1桁目までが一致するノード同士で、順序関係を保ってにリンクします。
   3. 次にレベル2では、メンバーシップベクタの2桁目までが一致するノード同士で、順序関係を保ってにリンクします。

これを一般化すると

レベルnでは、メンバーシップベクタのn桁目までが一致するノード同士で、順序関係を保ってにリンクします。

となります。

さて、最初にいっぺんにリンクを作る方法はわかりました。では、途中のノードを追加する場合はどうなるのでしょうか。

ご心配なく。そういったことも可能です。その場合の計算量も平均です。

1. まず、自分が追加しようとしているノードの値に近いノードを探索します。
2. 追加している値のノードか、もっとも近い値のノードを見つけたら、ソート順番が壊れないように、そのノードの隣にノードを追加します。このとき、レベル0では、左右のノードのリンクを、追加したノードにリンクします。
3. 次にレベル1では、メンバーシップベクタの1桁目が一致しているノードを左右でそれぞれ探し、リンクしなおします。
4. レベル2では、レベル1でリンクしたノードを起点に、左のノードであれば、さらに左に、右のノードであれば、さらに右に、メンバーシップベクタの2桁目までが一致するノード同士でリンクしていきます。
5. 最終的に、各レベルのノードが終端ノードになるか、リンクがされるまで続けます。（または、ノード数がわかっているなら、の値からレベル数を求めて、そのレベルまで続けます）

以上が、ノードの追加方法となります。

SkipGraphが並列アルゴリズムとして有利な点はノードを検索や追加する場合に、どのノードを基点にしても平均計算量はになるという点です。（ただし、最悪はです。）

また、データを追加する場合にも局所的な情報の更新をするだけでいいので、並列でノードの追加などもできるのではないかと思います。

ただし、このアルゴリズムをつかっていくらモテるようになったからといって、女の子たちと並列で遊んではいけませんよ！

こんにちは。木村です。

今回は4.4 File Downloadsです。

原文の単語と全く違う言葉に置きかえている場合が多々あります。原文ページと併せて、ご覧下さい。気になる箇所や間違っている箇所があれば、どうかご指摘下さい。

では、以下訳です。
私です。

ああああ

4.4 File Downloads

4.4 ファイルダウンロード

- Make sure users cannot download arbitrary files.

• ユーザが任意のファイルをダウンロードできないように確認する。

Just as you have to filter file names for uploads, you have to do so for downloads. The send_file() method sends files from the server to the client. If you use a file name, that the user entered, without filtering, any file can be downloaded:

アップロード時にファイル名にフィルターをかけなければならないように、ダウンロードの場合もフィルターをかける必要があります。send_file()メソッドはサーバからクライアントにファイルを送ります。もしユーザが入力したファイル名をフィルタなしで使用しているならば、どんなファイルもダウンロードされます。

Simply pass a file name like “../../../etc/passwd” to download the server’s login information. A simple solution against this, is to check that the requested file is in the expected directory:

“../../../etc/passwd”というようなファイル名を渡すだけでサーバのログイン情報をダウンロードできてしまいます。これに対する簡単な解決方法は、リクエストされたファイルが期待通りのディレクトリの中のファイルであるかチェックすることです。

Another (additional) approach is to store the file names in the database and name the files on the disk after the ids in the database. This is also a good approach to avoid possible code in an uploaded file to be executed. The attachment_fu plugin does this in a similar way.

もう1つの（さらなる)アプローチはファイル名をデータベースに保存して、データベースのIDでディスク上のファイル名をつけることです。これはアップロードファイル中の実行可能なコードを回避するための良いアプローチでもあります。attachment_fuプラグインは似たような方法でこれを実行します。

次回は5 Intranet and Admin Securityです。

こんにちは。木村です。

今回は4.3 Executable Code in File Uploadsです。

原文の単語と全く違う言葉に置きかえている場合が多々あります。原文ページと併せて、ご覧下さい。気になる箇所や間違っている箇所があれば、どうかご指摘下さい。

では、以下訳です。

———————-

4.3 Executable Code in File Uploads

4.3 アップロードファイル内の実行可能なコード

- Source code in uploaded files may be executed when placed in specific directories. Do not place file uploads in Rails’ /public directory if it is Apache’s home directory.

- アップロードファイル内のソースコードは特定のディレクトリに置かれている時に実行される可能性があります。もしRailsの/publicディレクトリがApacheのホームディレクトリならば、アップロードファイルを置かないでください。

The popular Apache web server has an option called DocumentRoot. This is the home directory of the web site, everything in this directory tree will be served by the web server. If there are files with a certain file name extension, the code in it will be executed when requested (might require some options to be set). Examples for this are PHP and CGI files. Now think of a situation where an attacker uploads a file “file.cgi” with code in it, which will be executed when someone downloads the file.

一般に使用されているApache WebサーバにはDocumentRootと呼ばれるオプションがあります。
これはWebサイトのホームディレクトリのことで、Webサーバはこのディレクトリツリーの中にある全てを扱います。もしある拡張子を持ったファイルがあった場合、その中のコードはリクエストされた時に実行されます(いくつかのオプションが設定されている必要があるかもしれない)。PHPやCGIファイルがそれに当たります。さて、攻撃者がコードが含まれた”file.cgi”ファイルをアップロードするシチュエーションを考えてください。誰かがそのファイルをダウンロードする(リクエストを出した)時そのファイルは実行されるでしょう。

If your Apache DocumentRoot points to Rails’ /public directory, do not put file uploads in it, store files at least one level downwards.

もしApacheのDocumentRootがRailsの/publicディレクトリになっているならば、そこにアップロードファイルを置かずに、少なくとも1階層下にファイルを保存してください。

———————-

次回は4.4 File Downloadsです。

こんにちは。木村です。

今回は4.2 File Uploadsです。

原文の単語と全く違う言葉に置きかえている場合が多々あります。原文ページと併せて、ご覧下さい。気になる箇所や間違っている箇所があれば、どうかご指摘下さい。

では、以下訳です。

—————————————————————–

4.2 File Uploads

4.2 ファイルアップロード

- Make sure file uploads don’t overwrite important files, and process media files asynchronously.

- ファイルアップロードで重要なファイルを上書きしないように、また、メディアファイルを非同期的に処理するようにしてください。

Many web applications allow users to upload files. File names, which the user may choose (partly), should always be filtered as an attacker could use a malicious file name to overwrite any file on the server. If you store file uploads at /var/www/uploads, and the user enters a file name like “../../../etc/passwd”, it may overwrite an important file. Of course, the Ruby interpreter would need the appropriate permissions to do so – one more reason to run web servers, database servers and other programs as a less privileged Unix user.

多くのWebアプリケーションはユーザにファイルアップロードを許可しています。ユーザが(部分的に)指定できるファイル名を、攻撃者がサーバ上のファイルを上書きするために悪意のあるファイル名を使用するかもしれないとして、常にフィルタするべきです。もし/var/www/uploadsにアップロードファイルを保存していて、ユーザが../../../etc/passwdのようなファイル名を入力したならば、重要なファイルが上書きされるかもしれません。もちろん、Rubyインタプリタがそのように実行する許可を割り当てられている必要があります。これがWebサーバやデータベースサーバやその他のプログラムをより少ない権限のUnixユーザとして実行する理由の一つです。

When filtering user input file names, don’t try to remove malicious parts. Think of a situation where the web application removes all “../” in a file name and an attacker uses a string such as “..‭..//” ? the result will be “../”. It is best to use a whitelist approach, which checks for the validity of a file name with a set of accepted characters. This is opposed to a blacklist approach which attempts to remove not allowed characters. In case it isn’t a valid file name, reject it (or replace not accepted characters), but don’t remove them. Here is the file name sanitizer from the attachment_fu plugin:

ユーザが入力したファイル名をフィルタする時、悪意のある部分を削除しようとしないでください。Webアプリケーション上でファイル名にある全ての「../」を削除し、攻撃者が「..‭..//」というような文字列を(ファイル名の一部に)使用する状況を考えてみてください。結果、「../」という文字列になります。ホワイトリストアプローチを使用することが最良の方法です。ホワイトリストアプローチは許可された文字のセットを用いてファイル名の有効性をチェックします。これは許可されない文字を削除しようと試みるブラックリストアプローチとは反対の方法です。有効でないファイル名であった場合、拒否してください(または許可されない文字を置換する)、しかし文字を削除しないでください。attachment_fu pluginのファイル名をサニタイズする部分を次に挙げます。

A significant disadvantage of synchronous processing of file uploads (as the attachment_fu plugin may do with images), is its vulnerability to denial-of-service attacks. An attacker can synchronously start image file uploads from many computers which increases the server load and may eventually crash or stall the server.

アップロードファイルの同期的な処理(attachment_fuプラグインは同期的にイメージを処理します)の著しく不利な点ははDoS攻撃への脆弱性です。
攻撃者は多くのコンピュータからイメージファイルアップロードを同期的に開始し、サーバの負荷を増大させ、最終的にはサーバをクラッシュまたは麻痺させることができます。

The solution to this is best to process media files asynchronously: Save the media file and schedule a processing request in the database. A second process will handle the processing of the file in the background.

この解決方法はメディアファイルを非同期的に処理することが最良の方法です。メディアファイルを保存して、データベースで処理リクエストをスケジューリングしてください。
セカンドプロセスがバックグラウンドでファイルの処理を担当します。

—————————————————————–

次回は4.3 Executable Code in File Uploadsです。

谷口です。

2/26(Fri)・27(Sat)でオープンソースカンファレンス2010 Tokyo/Springが開催されました。
26日は仕事で行けなかったのですが、27日は眠いのをこらえつつ行ってきました！

今回は残念ながらZenCart.JPは展示がなかったのですが、その分色々見て回ることができました。

今回は前回の2009 Tokyo/Fallより人口密度が高かったように感じました。（展示ブースのスペースが狭かったからかも？）
こんな感じです。

KBMJブースへ

さて、今回私が一番気になっていたのは株式会社KBMJのエレコマです。というわけで、真っ先にKBMJのブースへ･･･やはりZen CartをやっているとECサイト構築パッケージは気になります。

で、元々はECサイト構築案件がきっかけだったとか、そのときはEC-CUBEを使おうという話も出てたとか、EC Riderとの関係が･･･とか、根堀葉堀余計なことまで聞いてしまいました。
かなり失礼な質問もあったと思いますが、真摯に答えてくださったKBMJのスタッフさんありがとうございました！

エレコマはRuby on Railsで開発されているので、Railsのモジュールがそのまま使えそうですので、機能拡張のしやすさが魅力的ですね。
パッケージとしては今はまだ機能面で物足りない部分もあるなぁという印象ですが、今後の機能アップに非常に期待しています！

おわりに

今回の開催場所は多くの人にとっては行きづらい場所だったと思いますが、全体的に盛況な印象でした。
今回出展されていたエレコマ以外にも、Live CommerceやEC-RiderなどオープンソースのECサイト構築パッケージが続々と出始めていますので、
Zen Cartもうかうかしてられないですなぁ・・・。

こんにちは。木村です。

今回は4 Redirection and Filesから
4.1 Redirectionです。

原文の単語と全く違う言葉に置きかえている場合が多々あります。原文ページと併せて、ご覧下さい。気になる箇所や間違っている箇所があれば、どうかご指摘下さい。

では、以下訳です。

4 Redirection and Files

4 リダイレクトとファイル

Another class of security vulnerabilities surrounds the use of redirection and files in web applications.

もう1つの種類のセキュリティ脆弱性はリダイレクトの使用とウェブアプリケーションのファイルの周辺に存在します。

4.1 Redirection

4.1 リダイレクト

- Redirection in a web application is an underestimated cracker tool: Not only can the attacker forward the user to a trap web site, he may also create a self-contained attack.

- webアプリケーションのリダイレクトはクラッカーツールとして甘く見られています。攻撃者は罠のあるwebサイトにユーザを転送できるだけでなく、内包型の攻撃を作り出すこともできます。

Whenever the user is allowed to pass (parts of) the URL for redirection, it is possibly vulnerable. The most obvious attack would be to redirect users to a fake web application which looks and feels exactly as the original one.
This so-called phishing attack works by sending an unsuspicious link in an email to the users, injecting the link by XSS in the web application or putting the link into an external site. It is unsuspicious, because the link starts with the URL to the web application and the URL to the malicious site is hidden in the redirection parameter: http://www.example.com/site/redirect?to= www.attacker.com. Here is an example of a legacy action:

ユーザが(部分的な)リダイレクトURLの通過を許可されるときはいつでも、攻撃を受けやすい可能性があります。最も分かりやすい攻撃は、オリジナルサイトと勘違いするような偽者のwebアプリケーションにユーザをリダイレクトすることでしょう。いわゆるフィッシング攻撃はユーザへのメールで不審に思われないリンクを送りつけるか、webアプリケーションのXSSをリンクに入れるか、外部サイトへのリンクを設置します。フィッシング攻撃は不審に思われません。なぜなら、リンクはwebアプリケーションへのURLで始まり、悪意のあるサイトへのURLはリダイレクトパラメータに隠されているからです。http://www.example.com/site/redirect?to= www.attacker.com. あるlegacyアクションの例が次の通りです。

def

  legacy redirect_to(params.update(:action=>'main'))

end

This will redirect the user to the main action if he tried to access a legacy action. THowever, it can exploited by an attacker if he includes a host key in the URL:he intention was to preserve the URL parameters to the legacy action and pass them to the main action.

これはユーザがlegacyアクションにアクセスしようととするとmainアクションにリダイレクトします。legacyアクションへのURLパラメータをmainアクションに移動する時に保持することが目的です。しかしながら、URLにホストキーを含めることで攻撃者に悪用される可能性があります。

http://www.example.com/site/legacy?param1=xy&param2=23&host=www.attacker.com

If it is at the end of the URL it will hardly be noticed and redirects the user to the attacker.com host. A simple countermeasure would be to include only the expected parameters in a legacy action (again a whitelist approach, as opposed to removing unexpected parameters). And if you redirect to an URL, check it with a whitelist or a regular expression.

URLの終わりがこのようになっていれば、ほぼ気づかれずにユーザをattacker.comホストにリダイレクトします。簡単な対策方法はlegacyアクションに期待されるパラメータだけ含めることでしょう。(また一方で期待されないパラメータを削除するのとは対照的なホワイトリストという方法があります)もしリダイレクトするときは、ホワイトリストか正規表現でURLをチェックしてください。

4.1.1 Self-contained XSS

4.1.1 内包型のXSS

Another redirection and self-contained XSS attack works in Firefox and Opera by the use of the data protocol. This protocol displays its contents directly in the browser and can be anything from HTML or JavaScript to entire images:

もう1つのリダイレクトと内包型のXSSによる攻撃はデータプロトコルを使うことでFirefoxとOperaで動作します。このプロトコルはそのコンテンツをブラウザで直接表示し、HTMLやJavaScriptから完全な画像まで何にでもなれます。

data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K

This example is a Base64 encoded JavaScript which displays a simple message box. In a redirection URL, an attacker could redirect to this URL with the malicious code in it. As a countermeasure, do not allow the user to supply (parts of) the URL to be redirected to.

この例は簡単なメッセージボックスを表示するJavaScriptをBase64エンコードしたものです。リダイレクトURLで使用する場合は、攻撃者は悪意のあるコードをデータプロトコルに含めることでリダイレクトすることができます。対策方法としては、(部分的な)リダイレクトURLをユーザに使わせないことです。

次回は4.2 File Uploadsです。

天方です。

今日からモテるアルゴリズム講座を始めたいと思います。

それでは、第1回グラフでモテたいの講義を始めようと思います。
なんといってもアルゴリズムができるとかいうと、いろいろモテます。
この講座を通じて、皆さんもアルゴリズムをマスターしてモテてください。

本日は、モテるアルゴリズムを考える上で重要な
グラフのデータ構造について話をしたいと思います。

グラフというと、普通思い浮かべるのは棒グラフとか円グラフとかかもしれませんが、今回は違います。そんな反応をしていると婚期を逃します。

グラフというのは、点と枝かつながってできるものをグラフと言います。

グラフの例

グラフはいろいろな分野で使われていると思いますが、
あのGoogleも検索エンジンのページの順位付けのためにグラフの概念を利用していたいりします。

さて、グラフをコンピュータ上で扱おうとすると、そのデータ構造の持たせ方に悩みます。
グラフ用のライブラリを使えばそれほど大変でもないのですが、やはり自分で書いた方がモテます。

グラフをデータとして表現するにはいくつか方法があります。
では、上記の図で示したグラフをさまざまなデータ構造で表現してみようと思います。

まず、上の図の点と枝を数学的な表現を使って次のように表現することにします。

点の集合

枝の集合

その場合、点と枝の接続関係は次のようになります。

枝, 始点, 終点

ちなみに、向きがある枝でできたグラフを有向グラフと呼びます。
向きがない枝でできたグラフを無向グラフと呼びます。

こういったグラフを表現するデータ構造としては、枝の始点と終点の番号の組を持たせることでグラフを表現する方法があります。

それではこのグラフのデータ構造をRubyをつかって表現してみましょう。

例えば、上記の視点と終点をRubyの配列で表現すると下記のようになります。

start_vertex = [1,2,3,4,5,6,1,5,3,1]
end_vertex = [2,4,4,5,6,1,3,2,6,1]

これは、さきほど示した数学的な表現だと下記のような表現になります。
… ①

配列の添え字が、枝の添え字 – 1になります。

頂点間に枝があるかどうかを調べるには
頂点数をnとするとの計算量(時間的)がかかります。
また、計算量(空間的)は枝数をとするとです。

そこで、各頂点毎に、出入りする枝を持つという手があります。

たとえば、下記の様な図のように一つの頂点に出入りする枝に注目します。

頂点v1に入る枝と出る枝の例

これはRubyで表現すると下記のようになります。

start_edge = [[1, 7, 10], [2], [3, 9], [4], [5, 8], [6]]
end_edge = [[6, 10], [1, 8], [7], [2, 3], [4], [5, 9]]

数学的な表現では下記のようになります。
… ②

これで、頂点と枝の両方から検索ができるデータ構造ができました。ここモテます。
でも、もうすこしハイクラスのモテを期待したい場合は、クラスを利用したほうがいいと思います。

さて、配列でグラフを表現できるとからモテモテだと思っていい気になってはいけません。
やはりグラフを表現する場合にもTPOがあります。
例えば、他のラフの表現方法としては、接続行列を使う方法もあります。

接続行列 … ③

縦の座標が頂点の添え字、横の座標が枝の添え字に対応し、
要素が1であれば、その頂点を始点、要素が-1であれば、その頂点を終点とすることを表現しています。
この場合、計算量(空間的)はです。頂点間に枝があるかを調べる計算量(時間的)はです。
ちなみに、接続行列だと、自己ループしている枝を表すことができません。
そういえば、さきほどの配列を用いた、枝の始点と終点の番号の組のデータ構造だと、枝がない頂点を表現できません。
そこらへんについて、「ちょっときみ、そのデータ構造だと、自己ループが表現できないので、今回の案件には使わない方がいいと思うよ」と
それとなく耳打ちできるとそれとなくモテます。

他に隣接行列で表現する方法もあります。

隣接行列 … ④

これは、縦の座標を始点の頂点の添え字に対応させ、横の座標を終点の頂点の添え字に対応させて表現したもので、1なら接続している、0なら接続していないという表現です。この場合、計算量(空間的)はです。頂点間に枝があるかを調べる計算量(時間的)はです。
みなさん、もうお気づきとは思いますが、隣接行列では、同じ始点、終点をもつ複数の枝を表すことができなくなります。

さて、４種類ほど表現方法を扱いましたが、それぞれの表現では、表現できるパターンの制約や、グラフを参照、更新する場合の計算量（時間的、空間的）などが違います。
シチュエーションや、相手の好みによって、表現方法を変えるとモテまくります。

みなさんもグラフでモテてみませんか？

久末です。

先日(2月22日)、プログラマーズカフェナイト@原宿というイベントを弊社で行いました。

今回はLTをメインに行いました。

プログラマーズカフェナイトの様子 Photo by 三鷹PGカフェ

さて、今回のLT発表者は以下の方々です。

プログラマーズカフェナイト – 紅茶屋くいっぱのあれこれ日記

webプログラマが楽にiPhoneアプリを開発する方法
@jishiha

3分でできるGoogle App Engine
@bluerabbit777jp

ExtJS & HTML5
@Tommy1969

お手軽 GoogleAppEngine / Java + slim3
404 shin1のつぶやき ないわー Not Found: 第１回プログラマーズカフェナイト＠原宿に参加した #pgcafe
@shin1ogawa

ギークハウスの話
@youchan

月曜日にもかかわらず40名募集のところに47名ほどの応募があり、最終的には30名程度、Ustreamの試聴が30名を超えるイベントになりました。

LT発表者のみなさん、参加者のみなさん、お手伝いのみなさん、ありがとうございます。

三鷹プログラマーズカフェとは？

プログラマーズカフェナイトは三鷹プログラマーズカフェの派生イベントと述べましたが、
三鷹プログラマーズカフェをご存じない方のために簡単にご紹介を。

三鷹プログラマーズカフェは、毎週木曜日、15〜18時に、三鷹産業プラザ地下1階で開催しているイベントです。
プログラマ(とは限らないのですが)が集まって話ができる「場」を提供しています。

プログラマーズカフェは会話が主体で、勉強会やセミナーと違って特定の目的がありません。
ですから、

• 自分で作ったプログラムやサービス
• 最近近話題になっている技術やサービス
• 仕事のこと
• 三鷹のこと
• プログラマーズカフェ自体のこと
• 世間話

といった話だけでなく、ちょっと公開できないようなこぼれ話や、プログラムなどとは全く関係のない話など、話題はあらぬ方向へ散らばっていきます。
それが面白いかどうか、役に立つかどうかはその人次第ですが、よくわからないものに積極的に興味を持てる人ならおもしろさを感じられるかもしれません。

三鷹プログラマーズカフェの主催は以下の三方です。

• @kuippa
• @kclab
• @ysakaki

時間があったらこちらにも是非参加してください。

三鷹プログラマーズカフェと私

私(久末)は、昨年まで弊社が三鷹駅付近にあった関係で、三鷹プログラマーズカフェの最初のイベントから参加することができました。
以来、できるだけ毎回参加しています。何が参ｌ

なぜプログラマーズカフェナイト＠原宿なのか

三鷹プログラマーズカフェは公式には15時〜18時なのですが、実際は、18時以降も
三鷹産業プラザ内のCafe Hi Famigliaさんで、話が盛り上がったりしています。

とはいえ、公式には、平日の午後に開催ということで一般の会社務めの方には現実的に難しいのも事実。
そこで、たまたま弊社が三鷹から原宿に引っ越し、イベントができるスペースがあるということで、
夜のカフェをやろうという話をプログラマーズカフェの方々に持ちかけました。
すると主催のkuippaさんをはじめ、プログラマーズカフェに参加している数名に賛同していただき開催に至りました。
以下が今回の実行委員会的なメンバー。

• @2celeb
• @jishiha
• @kohyama
• @kuippa
• @naoranger
• @THashidate
• @hisasue

次回

さて、実は、次回については、既に話を始めています。
興味のある方は是非参加してください。
告知は

三鷹プログラマーズカフェ (pgcafe) on Twitter
http://twitter.com/pgcafe

で行いますので、気になる方はフォローしてください。

最後に、弊社で開催と言っていますが、ここのオフィスはそもそも株式会社シナップさんのオフィスで弊社がオフィスシェアをさせていただいている場所です。
この素敵なオフィス空間を無償でイベントに使わせてくださったシナップさんにも感謝します。

久末です。

Google Buzz(以下、Buzz)は今のところカオスです。
そしてBuzzの中ではBuzzについての話が多く、何かに利用しようと思っている人には全く使えないかも知れません。

一方、Buzzの中ではBuzzに対して良好なコメントが見受けられます。
中にはTwitterやFacebookをやめてBuzzに移ったという発言もあるほどで、何らかの中毒的な要素はあるようです。
例えば、多くのユーザをフォローすれば多くのユーザからフォローされ、投稿すると、早ければ1分〜数分で複数のコメントが付きます。
反応しやすいBuzzには数百のコメントが付くこともあります。

他方、Buzzの外ではBuzzに対して批判的な意見も少なくありません。
リリースされたばかりのサービスではありがちなので、無視しましょう。
Twitterだってはじめはそんなもんでした。

さて、ここで私が投下したものをご紹介します。

http://www.google.com/buzz/hisasue/NL4j1MqWKMx/フォローの数のわりに新しい

フォローの数のわりに新しい投稿があんまりないのかな？
代わりにスレッドにコメントする投稿が多いとかなのかな？

とBuzzった内容には38のコメントがつきました。
ここでは、Buzzは(Twitter)より会話的だというコメントが多く見られました。
会話の連続性を妨げるようなTwitter雪崩(Twitterと連携しているユーザのつぶやきが
Buzzの画面に一気に流れる現象)のようなものは敬遠され、
コメントしやすいネタを提供といったものには好反応を得られるということでしょうか。

次。

http://www.google.com/buzz/hisasue/g9t46SShA9a/Buzzるほどでもないスレですが

Buzzるほどでもないスレですが？
テキトーな会話とか独り言とか歓迎

という私の投稿では現在のところ70のコメントが付いています。
これは数日間にわたって、ゆるい雰囲気のなか、コメントが続いている状態で、
2ちゃんねるのまったりとしたスレッドのようです。

また、Buzzは現在フォロー数の制限がありませんので、
数十〜数百のフォローは当たり前で、数千から数万人をフォローしている強者もいます。
そのフォロー数を可能にしているのは様々な言語圏のユーザです。
翻訳サイトの力を借りるなどして、積極的に異言語ユーザのBuzzにもコメントするユーザも珍しくありません。

私も中国語のBuzzに「日本人」という発言を見てコメントしてみました。

http://www.google.com/buzz/113897357861978367159/1yTZ95D8niZ/好多日本人FOLLOW-我-怎么回事

Edward Huang       　好多日本人FOLLOW 我，怎么回事？
(日本人はなぜ私をフォローするんだ？)
Takahiro HISASUE   It’s not problem for them that following person is Japanese or not
(日本人とか関係ないんだよ)
Edward Huang       　Yes,indeed,I am just curious. What a pity,I don’t speak Japanese
(まったく。不思議だよ。残念ながら私は日本語分からないしね)
Takahiro HISASUE   Im a Japanese. But talking with you in English. It’s so fun.
(私は日本人だよ。でも英語で話せるから結構面白い)
jan zx             　　　　　ますます面白くなったね！
(※中国語圏と思われる人が日本語でコメントしたもの)

(()は私が翻訳したもの)

こんな感じです。

もちろん、まじめな議論もあったりします。
以下のBuzzはBuzzにFacebookにあるようなゲームは必要だろうか？という話です。
200以上のコメントが付いているようです。

http://www.google.com/buzz/BuzzUsers/VoXtjjD9xrw/Social-Games-like-Farmville-on-Google-Buzz

Social Games like Farmville on Google Buzz?

Social Games Like Farmville and Google Buzz?
This is one of the biggest issues I have been hearing discussed about the future of Google Buzz. There are two ends of the argument for whether Google should allow social games like Farmville, and Mafia Wars to be allowed on Buzz. One thing is almost certain. We will see apps being developed specifically for Google Buzz in the near future. Just like you can use apps in Google Wave, I fully expect to have the same features in Buzz. Social gaming would surely make buzz even more attractive

というわけで、

「で？」「だから？」「なんなの？」「Googleがマイクロソフト化するの？」

と感じる方も多いと思います。

「○○でいいじゃん」

と思えるサービスもあるでしょう。
私もこんなにフォローして意味あるのかなと思いながらが、
ちょっと多めにフォローを繰り返し、Buzzの画面をPCや携帯から覗いています。

しかし、積極的にやってみるとBuzzにはBuzzの味わいがあります。
デジタルなものに味わいがあるのかかどうか分かりませんが、何となくそういう感じなので、しかたがありません。
というわけで、Buzzを上手く説明できる気がしなかったので、今回は私が実際に使ってみたことを、かいつまんでご紹介してみました。
まとめるべきところをまとめず、適当に何となく終わってみるのもBuzz的かなぁ、なーんて。

お粗末様でした。

P.S.
よかったら、フォローしてください。
http://www.google.com/profiles/hisasue#buzz