PartialFunctionのエイリアスを作って視認性up...しないかもしれない

PartialFunctionは、すべての値について定義されているとは限らない関数を示しているFunction1の特殊なケース。

val pf:PartialFunction[Int,String] = { case i if i>1000 => "Big" }

PartialFunctionそのものの話はとりあえず置いといて、Scalaってこんな書き方が出来る。型パラメータを2つとる型については中置のようにできる。

val pf:Int PartialFunction String = { case i if.... }

でもこれなんだかよくわからない。でも Int => String のように書きたいので、

type ~>[A,B] = PartialFunction[A,B]
val pf:Int ~> String = { case i if ... }

とかエイリアスを定義しておくとなんだか視認性がUP!・・・した？
まあこんな書き方が出来るScalaの素敵仕様 (

Windows7にしたら上り帯域だけ異常に狭くなったのでやっつけた

なんか最近合計帯域 384kbpsぐらいでustreamとかニコ生放送しててもガンガンパケットがdropするってんで、使ってるプロバイダをdisったりフレッツをdisったりしていたのですが、
disられるべきはWindows7か、無知な私だったようです。

まず、何が起こっているかというと定番Radishさんの測定結果でこんな感じ。

=== Radish Network Speed Testing Ver.3.2.2 - Test Report ===
測定条件
　精度:高 データタイプ:標準
下り回線
　速度:60.65Mbps (7.581MByte/sec) 測定品質:99.5
上り回線
　速度:6.204Mbps (775.5kByte/sec) 測定品質:99.0
測定者ホスト:********.dynamic.ppp.asahi-net.or.jp
測定サーバー:大阪-新町
測定時刻:2012/3/17(Sat) 18:22

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

測定サイト http://netspeed.studio-radish.com/

上り速度が下りの実に十分の一とかいう謎状態。

んで、なんでもWindows7にはRWIN値の自動チューニング機能とかいうのがついていて、そいつのせいで上り速度が出ないことがよくあるのだとか。
コマンドプロンプトを管理者権限で開いて、以下のようなコマンドを入れると制限できます。

C:\>netsh interface tcp set global autotuninglevel=highlyrestricted

あとはRWIN値を設定できるツール(nettuneなど)を使えばちゃんとXP時代までのチューニング手法が使えます。

改善後はこんな感じに！

=== Radish Network Speed Testing Ver.3.2.2 - Test Report ===
測定条件
　精度:高 データタイプ:標準
下り回線
　速度:60.94Mbps (7.617MByte/sec) 測定品質:99.6
上り回線
　速度:85.20Mbps (10.65MByte/sec) 測定品質:99.6
測定者ホスト:********.dynamic.ppp.asahi-net.or.jp
測定サーバー:大阪-新町
測定時刻:2012/3/17(Sat) 18:53

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • -

測定サイト http://netspeed.studio-radish.com/ ================================================

なんと上り速度のほうがはやくなってしまいました。別にピークスピードを求めているわけではなくustreamとかニコ生が快適に放送できればいいので今回はこれにて終了。

[OAuth][mobile][socialapp][java] Shift-JISにおける「ミ」問題、%7E問題(signatureの検証に失敗するケース)

某GR社や某De社のモバイルソーシャルアプリ開発で詰まるポイントがあるようなので、まとめ。ただし、遭遇したケースについてのみなので、網羅性はありません。

事象

クライアント端末から送信されてくるformの内容に "%7E"(半角チルダ文字"~") が含まれているとき、oauth signatureの検証に失敗する。
たとえばG社の場合、G社から送られてきているoauth signatureと、自サーバ側で生成したoauth signatureが異なってしまう、ということ。
⇒BaseStringの生成がおかしいのだろう

結論(急いでいる人のための結論)

BaseString生成時に "%7E" は "~" にunescapeしておく。
たとえば カタカナの"ミ" は Shift-JISでは "%83%7E" で送信されてくるが、この部分だけをBaseString向けにエンコードすると "%2583~" となる、ということ。

詳細

今回、これを解決できたのは (TwitterID)chrno001さんのPOSTがあったからこそです。ありがとうございました！

• http://twitter.com/chrno001/status/25110676676
• http://twitter.com/chrno001/status/25111065091

で、調べてみると、RFC5849の3.6. Percent Encodingに、

2. The values are then escaped using the [RFC3986] percent-encoding
(%XX) mechanism as follows:

* Characters in the unreserved character set as defined by
[RFC3986], Section 2.3 (ALPHA, DIGIT, "-", ".", "_", "~") MUST
NOT be encoded.

* All other characters MUST be encoded.

* The two hexadecimal characters used to represent encoded
characters MUST be uppercase.

つまり %7Eの "~" 以外にもエンコードしちゃいけない文字がある、と。注意しましょう。
RFC3986 2.3. Unreserved Charactersにも書いてあります。

RFC3986 compliantなエンコーダがあればいいのですが、今回のプロジェクトはJavaだったので、それについて少し調べてみた。

• java.net.URLEncoder はダメ (javadoc参照 ⇒ http://java.sun.com/javase/ja/6/docs/ja/api/java/net/URLEncoder.html)
• org.apache.commons.codec.net.URLCodec もダメ

そもそも、この2つのエンコーダは URL用エンコーダということで RFC3986準拠とは書いてませんね*1。

そのほか

Shift-JIS使うなよ、と言われてもG社から指定されているので仕方ありません。。。

*1:これでいくと "*" もヤバそうだが...

プログラマーズナイト 第二夜 開催します

• ATND http://atnd.org/events/8391

プログラマーズナイト　第二夜　開催します！
前回と同じ id:nagakura_eil さんとのコンビで、＠京都 cafe la siesta にて開催です！
今回は LTとかDJもバリバリ募集！　発表してくれたりした人には協賛/差し入れ/応援いただいた皆様からグッズなどを優先的に配らせていただきます! TE○GAとか！やばいですね！

ちなみに、前回の募集要項 ⇒ http://twitter.g.hatena.ne.jp/nagakura_eil/20090410/1239369170

今回のお誘い内容をATNDから転載します。

週末の晩に朝まで飲みましょう。
ほかじゃできない話でもしましょうよ。
あ、とくにこれといった崇高な目的があるわけでもないんですよ、たまには飲みながらプログラムの話とかしても楽しいと思いませんか！！！
いろんな話をしたいです！

場所:
京都 cafe la siesta
http://cafelasiesta.com/

日時:
2010年10月29日
22時〜翌朝（朽ち果てるまで）
当日、22時から貸し切りになりますが、それまでの時間は通常営業なので飲んでる人は飲んでると思います。

金額:
入場無料
飲食代は各自キャッシュオンでお願いします。

詳細は ATNDのほうで確認してね！

GDD パックマン問題がキビシイ

GDDエントリーのための関門 DevQuizをやっておるのですが・・・

しりとりはクリアできたのですが、パックマンがおおよそ検討もつかない。探索的なアルゴリズムは決定論的というか、最適解を求める方向へいってしまい、こういう設問の場合はおそらくTSP的な方法や、GAのようなアルゴリズムを使って「最適解に近い解法」を出す必要があると思うのですが、全然わかんない。

参加資格なしなのかな〜。くそう。 CodeJamでもまだ3回戦より上には勝ち上がれていないし、アルゴリズムとか、そのへんの力身につけないとダメですね。TopCoderとかやればいいのかな?

ぼくらの空気公団 / 空気公団

空気公団のベスト「ぼくらの空気公団」出てますね。
近作「青い花」までを含むかなり(時間的に)幅の広いセレクション。ただ、個人的に意外だったのは「おくりもの」から「白いリボン」が入らなかったこと。
めちゃめちゃいい曲なのに…なんだか残念な気持ちなのはなぜなんだぜ

空気公団の素晴らしさは色々あるのですが、私は作編曲にとても惹かれています。メロディセンスもさることながら、独特の進行感はとても耳に心地良いです。

ぼくらの空気公団

おくりもの

kindle DXは楽譜/音楽書ビューアとして相当イケている

会社で Amazon kindle DX を買ったのですが、kindle SDKとかいろいろ考える前に、このデバイスをふつーにいろいろ触ってみました。

その中で「これはいい」と思ったのが、楽譜や音楽書のビューアとして使う、というもの。まず、kindle DXはPDFを表示できるので、PDF形式にしておいた楽譜などを転送しておきます。

ピアノなら楽譜台ありますし、その他の楽器の人でも譜面台があればKindleは置けます。さすがに楽譜として見るには小さいのが難ですが、まず、

• 風でめくれたりしない
• 製本してある楽譜の場合、やたらと折り癖をつけるとかしなくても、バラバラッて戻ったりしない
• 音の確認や、理論を確認しながら練習するには充分
• 演奏しながらにはさすがにキツいが、ページ送りは割と十分操作できる (慣れた人のピアノの譜めくりほどではないけども実用レベル)

そして、これはシーンを選びますが"Real Book"などをなんとかうまくやれば、曲名で検索してリードシートをサッと出す、というグレイトなセッションプレイヤーになれるかもしれません。すでに iPhone用の "iRealBook"というアプリがあり、これは私も実用していますが、テーマ譜がないのが玉に瑕。kindleなら十分なサイズです。