2010年8月19日木曜日
2010年6月17日木曜日
スマートフォンとセンサー
Webアプリケーションに関する仕事に携わってたせいか、ケータイのイメージは「面倒くさいヤツ」でした。
Webブラウザやメーラーに限って言えば、互換性からはほど遠い仕様であったりなかったりで…。
しかし、iPhoneやAndroidで変化が見られます。
これらは、PCに限りなく近い形で標準化がなされています。
限られたメモリやCPUの中でよくぞここまで、と思うことも少なくないのです。
さらに特徴的なのは、このデバイスを「センサー」としてほぼ自由にアプリケーションを作ることができる、というもの。
しかも非常に簡単に。
iPhone4はジャイロセンサーまで搭載しているし、Androidもデバイスでの差異はあるかもしれませんが、
様々なセンサーを搭載しています。
さらに、より多くのセンサーがスマートフォンに搭載されることで、例えば体温計になったり、血圧計になったり、
いろいろ妄想も膨らむでしょう。
いずれにせよ、それらのセンサーをいかにサービスに落とし込めるか、これが今のテーマです。
ちなみに、Windows7でも比較的簡単にセンサーを扱える仕組みがあります。
2010年6月10日木曜日
Google App Engine / Python での Shift_JIS 問題
GAEでクエリ文字列やPOSTされたデータを取得する際には、下記のメソッドを使います。
self.request.get('hoge')
しかし、文字コードがShiftJISの場合、何故か取得出来ない。
UTF-8は取れるのにぃ。
こんな時は、GETの場合はQUERY_STRINGを、POSTの場合はBODYを調べる。
self.request.query_string
self.request.body
すると、ここまでは値が来ている。
文字コードがAsciiかUTF-8じゃなかったら捨ててると見た。
そこで、QUERY_STRINGまたはBODYから直接文字列を取り出す。
その文字列をunquoteして、decode('cp932')すれば無事取得できる。
まさか、ここでコケるとは思わなかったので、マジでビビった。
Google App Engine で全文検索を実装(Python)
ともかく、一応SearchableModelというクラスで全文検索らしきことができるのですが、
当然マルチバイトなんて知らないわけです。
まあ、こんな感じで使いますが。
def Hoge(SearchableModel):
id = db.IntegerProperty()
name = db.StringProperty()
q = Hoge.all().search("hoge")
問題点としては、
・スペース区切りで単語を分ける(日本語はどないすんのじゃ)
・二文字以下はインデックスしない(そりゃ英語はいいわな、それで)
・検索する単語も二文字以下はなかったことになる(絞り込みできない)
ところが、こちとら日本人な訳で、なんとかせにゃならん訳です。
GAEだと分かち書きエンジン導入も面倒だし。
で、検索対象の文字列が50文字程度なら、こうしたらいいのでは?と。
・N-Gramもどき(一文字、二文字、三文字…で文章を分割)で文字列を分割
・これで出来た文字列の二文字以下のものは、マルチバイト文字列の何かを足して三文字にする(足した文字は検索でも使う)
・これらをスペースで繋げて、インデックス用プロパティに保存
・後はSearchableModelが勝手にインデックス化
実際に実装したところ、きちんと日本語で全文検索できてます。
これで少しは役に立つかな?
2010年5月21日金曜日
Google App Engine の app.yaml でハマる
static_dir の設定ではまったので。
2010年5月10日月曜日
MD を Mac に取り込みする
特に、過去にデジタルコピーしたものを取り込むには、デジタルコピーの制限がいろいろやっかいですし。
しかし、人のCDのコピーならともかく、自分のライブ録音やデモ音源がコピーできないのはちょっと困ります。
そこで、下記の機材でデジタルコピーに取り組んでみました。
・SHARP MD-M11(ポータブルなのにデジタル出力がついている)
・Mac OS X 10.6
・Soundtrack Pro(MDからデジタルで取り込むソフト)
・WaveBurner(LogicStudioについているマスタリングソフト、取り込んだファイルを曲ごとに分割)
まず、MD-M11のデジタル出力とMacのデジタル入力を光ケーブルでつなぎます。
次に、SoundtrackProを立ち上げて、「ファイル > 新規ファイル > オーディオファイル」と選択します。
サンプリングレートは「44100」、入力は標準入力で。
SoundtrackProで録音を開始して、MDからの取り込みを始めます。
#ちなみに、MDの電源が切れると自動的にSoundtrackProの録音は停止します。
私は、取り込んだ音源をノーマライズして、必要ならコンプなどをかましています。
この音源を保存して、WaveBurnerで分割してCDに焼くなり、曲ごとにバウンスしてiTunesに移したりします。
当初は MZ-RH1 を買おうかとも考えたのですが、上記の方法で解決できましたので、メモとして残しておきます。
あくまで自分の楽曲なりライブの整理ですので、違法な行為のために実施しないでください。
これで、やっと家のMDを全て移すことができました。
2010年5月2日日曜日
HereNow! -今いる場所をメールで教える iPhone アプリ
2010年4月17日土曜日
原子力発電と核廃棄物の責任について
今日NHK総合で放送された原発特集を見て気になったこと。
内閣府原子力委員会の方から「原子力の問題は国民すべての共通の問題である。より理解していただけるよう努力しなければならない。」という旨の発言がありました。
#正確な発言と文章の前後関係がわからないため、以下正しい理解であるかどうか難しいです
政策として原子力による発電を推進してきたことは事実ですし、各電力会社が原子力発電による電力供給を今でも行っています。
我々の生活にとって、どのようなプロセスによって電力が生成されているかはともかく、必要としているから供給されていることも、また事実です。
しかしながら、核廃棄物処分場の建設となってくると、「国民の理解」というレベルではないのではないかと思うのです。
電力会社は原子力発電による利益を上げています。
電力に関する利益は会社が得て、処分場は(もしかしたら発電の恩恵にあずからない)住民が最終的に「国民の理解」ということでツケを払う形になるのは、理解されにくいのではないでしょうか?
そもそも、今後どのように処分していくべきなのか、その方策が定まらない段階で、原子力発電所を増設していくのは危険だと思います。
本当に原子力発電が必要とされているのか、もっと良い方法があるのではないか?
一度、発電のためのメリット、デメリット、総コストなどを比較した上で検討してみることが、まず必要なのではないでしょうか?
私が思う必要な項目は、
- 国内で必要な総電力量(例えば1年間で)
- 発電方法
- 各発電方法の原料調達コストとそれに対する発電量(例えば1kw発電するのに必要なコスト)
- 施設建設費用(土地取得コストなども考慮して)
- 送電に関するコスト
- 問題点(例えば原子力発電の放射能など)
これらの条件を比較検討してゼロベースで考えていくことも大きなヒントになると思います。
例えば、電気を利用する場所に限りなく近い場所で発電されれば、送電コストもかなり小さくなるのではないかと思うのです。
なんとなくですが、CO2出さないからもてはやされているような気がしてならないので、ちょっとした意見です。
#以下記述のためのメモ
ちなみに、原子力発電所の問題はいくつかあげられると思います。
- 事故(主に放射能漏れ、臨界事故など)
- 資源(原料のウランなどの輸入や輸送など)
- 処理(使用済み核燃料の処理、廃棄の原子炉など)
事故については、1986年4月のチェルノブイリ原発事故がもっとも有名かもしれません。
国内では1999年の東海村の臨界事故がありました。
処理については、六ヶ所村に建設されようとしている核燃料再処理施設の反対運動など、
今後の増え続ける核廃棄物への対応も大変難しい状況にあると言えるでしょう。
原子力発電所や再処理施設の建設などで、住民へのインセンティブとのトレードが昔からあるようですが、
その際の住民、行政、電力会社、国のそれぞれの思惑が少しずつずれて、今後も理解に対する溝が埋まるのは難しいかもしれません。
2010年4月13日火曜日
A2Q - 電話帳データからQRコード生成するiPhoneアプリ
2010年4月7日水曜日
ウィルコムWX330KからiPhone3GSへアドレス帳を移行
- Windowsマシンで、H"問屋でアドレス帳データをCSVに変換
- Macで、CSVデータを整形した後、アドレスブックに取り込む
- iTunesでiPhoneと同期する
- ShiftJISからUTF-8へ変換する(念のため)
- 「携帯: 」と「PHS: 」という文字列を取り除く
- 名前とふりがなが姓と名に分かれていないので、ここは手作業で分ける
- 単純なCSVなので、カンマで適当に区切れば整形は簡単
2010年3月3日水曜日
遅れましたが、Install Maniax 3 終わりました
2010年2月25日木曜日
Google App Engine (Python)
2010年2月24日水曜日
チームを率いること、マネージメントすること
2010年2月22日月曜日
MacOSXで一時的にバージョンを書き換える
2010年2月20日土曜日
Android 2.1 をMURASAMEで
カセットテープ
2010年2月19日金曜日
AndroidをMURASAMEで
2010年2月17日水曜日
音響を追求するといいと思う
2010年1月28日木曜日
スキルが必要なのかしら?
2010年1月27日水曜日
ソフトシンセにハマる
2010年1月22日金曜日
仮に「東京病」があるとすれば
2010年1月21日木曜日
SFって
書籍をスキャンしてデータ化する(3)
書籍をスキャンしてデータ化する(2)
書籍をスキャンしてデータ化する(1)
2010年1月18日月曜日
原子力発電と核廃棄物の責任について
今日NHK総合で放送された原発特集を見て気になったこと。
内閣府原子力委員会の方から「原子力の問題は国民すべての共通の問題である。より理解していただけるよう努力しなければならない。」という旨の発言がありました。
#正確な発言と文章の前後関係がわからないため、以下正しい理解であるかどうか難しいです
政策として原子力による発電を推進してきたことは事実ですし、各電力会社が原子力発電による電力供給を今でも行っています。
我々の生活にとって、どのようなプロセスによって電力が生成されているかはともかく、必要としているから供給されていることも、また事実です。
しかしながら、核廃棄物処分場の建設となってくると、「国民の理解」というレベルではないのではないかと思うのです。
電力会社は原子力発電による利益を上げています。
電力に関する利益は会社が得て、処分場は(もしかしたら発電の恩恵にあずからない)住民が最終的に「国民の理解」ということでツケを払う形になるのは、理解されにくいのではないでしょうか?
そもそも、今後どのように処分していくべきなのか、その方策が定まらない段階で、原子力発電所を増設していくのは危険だと思います。
本当に原子力発電が必要とされているのか、もっと良い方法があるのではないか?
一度、発電のためのメリット、デメリット、総コストなどを比較した上で検討してみることが、まず必要なのではないでしょうか?
私が思う必要な項目は、
- 国内で必要な総電力量(例えば1年間で)
- 発電方法
- 各発電方法の原料調達コストとそれに対する発電量(例えば1kw発電するのに必要なコスト)
- 施設建設費用(土地取得コストなども考慮して)
- 送電に関するコスト
- 問題点(例えば原子力発電の放射能など)
これらの条件を比較検討してゼロベースで考えていくことも大きなヒントになると思います。
例えば、電気を利用する場所に限りなく近い場所で発電されれば、送電コストもかなり小さくなるのではないかと思うのです。
なんとなくですが、CO2出さないからもてはやされているような気がしてならないので、ちょっとした意見です。
#以下記述のためのメモ
ちなみに、原子力発電所の問題はいくつかあげられると思います。
- 事故(主に放射能漏れ、臨界事故など)
- 資源(原料のウランなどの輸入や輸送など)
- 処理(使用済み核燃料の処理、廃棄の原子炉など)
事故については、1986年4月のチェルノブイリ原発事故がもっとも有名かもしれません。
国内では1999年の東海村の臨界事故がありました。
処理については、六ヶ所村に建設されようとしている核燃料再処理施設の反対運動など、
今後の増え続ける核廃棄物への対応も大変難しい状況にあると言えるでしょう。
原子力発電所や再処理施設の建設などで、住民へのインセンティブとのトレードが昔からあるようですが、
その際の住民、行政、電力会社、国のそれぞれの思惑が少しずつずれて、今後も理解に対する溝が埋まるのは難しいかもしれません。