戻る


2013/06/30 21:20

oh、androidでwiiリモコン動かすの難しいネ。

wiiリモコンと端末をペアリングするところからしてうまくいかない。

androidはPINの入力を要求してくるんだけど、PINは不要らしい?でも空入力とかできないし。

既存のアプリのソースを見てみたかったが、なかなか見つからなかった。

幸いにも、BluezIMEというアプリはプロジェクトのページでソースが公開されていた。

ただアプリをインストールするだけでは、wiiリモコンは使えない。何やら、l2capなるものが使える端末でないと動かせないらしく、上のプロジェクトのページで配布されているHIDEnablerをインストールすることで使用可能になる。

ソースを読んでみようと思ったのだが、なんかめんどくなってきた。そんなに量が多いわけではないのだが。

端末に搭載されているペアリング機能を使わずにペアリングを行なうっぽいところからしてめんどくさい。どこに書いてあるんだろう。

とまぁソースを読むのがめんどうで一気にモチベーションが下がったので、早々にdpの方に戻ろうかなぁ。昨日色々書いたのを参考に進められるかもしれん。

でもまぁ謎のままにしときたくないというか作りたいので、暇を見つけては解読することにしよう。


2013/06/30 03:50

antroid直した。

sdkに含まれているbuild.xmlを見ていたら、なんか、lintなるツールが追加されたらしい。よく分からんが、このページによればなんか知らんがすごそう。

>これは、Androidプロジェクトのソースコードの潜在的な不具合を発見するためのものです。

なんか知らんがすごそう。上のページに色々書いてあるようだが、そこまでしか読んでないから全然分からんけど。

というわけでビルドとかできるようになったので、少しandroidアプリを作ってみようかしら。

dpの方は、pulseaudioを使った音声出力デバイスの列挙とか、接続・切断の検知をできるようにしたところで、一応一段落している。

次は音声を出力したいが、クラス名とかどうしたもんかなーとか。AudioPlayerか?とも思ったが、あまり色々な機能を提供する気がない。というか、コンストラクタでopen()して、write()で音声を出力して、デストラクタでclose()する、というのを想定している。これを指して、AudioPlayerというのは適当でない気がする。

となるとAudioWriterかなぁとも思ったが、しっくりこない不思議。ううむ。

dp::AudioWriter(仮)を作るにしても、どうしても出力デバイス管理クラス、dp::SpeakerManagerに依存しなければならない、多分。

dp::SpeakerManagerは、音声出力デバイスが接続されると一意に対応するdp::SpeakerKeyを作ってイベントハンドラを呼び出すとかするんだけど、音声を出力する場合、dp::SpeakerManagerのメンバの、pa_contextが必要になる。

できることなら、

dp::AudioWriter writer( speakerKey );

writer.write( ... );

みたいな感じでやりたいんだけど、pa_contextが必要だからdp::SpeakerManagerと関連付けないといかん気がする。

しかし私としては、デバイスの検出が済んだらdp::SpeakerManagerを破棄して、dp::AudioWriterを作る、とかいう風にもできるようにしたい。依存関係を持たせるとそれができなくなる。

pulseaudioのデータは、基本的に参照カウントで管理しているっぽいので、pa_contextのポインタだけをdp::SpeakerKeyに持たせる、とかいう方法もいけるのかなぁ。いけるなら、dp::SpeakerKey生成時に参照カウントを増やし、破棄時にカウントを減らし、dp::AudioWriter(仮)の時も同じようにすればいけるのかなぁ。

などなど。あ、そういえば非同期な音声出力をまだ試してないなぁ。pa_streamとかっぽいんだが。

などと長々書いたが、色々と考えはあるものの、あまりモチベーションが上がらない。のでandroidアプリの方を進めてみようかな。

androidどころか、javaからして久しぶりだなぁ。jdk入れてなかったし。jreも入れてなかった。

とりあえずbluetoothデバイスをいじくる系のアプリを作ろう。まずはペアリングから。前に、android端末同士をペアリングして、テキストを送受信する簡単なアプリを作ったことがあったが、ソースは無くしてしまったようだ。残念。


2013/06/26 14:42

久々にandroidアプリをいじりたくなった。

今の環境にsdkやらndkやらを入れていなかったので、まずは環境構築から。sdkを入れた後に、sdkに含まれているツールを使って色々落とさないといけないのがめんどい。

前に作ったantroidが使えるかどうか試したが、プロジェクト作成は使えるもののビルドとかがうまくいかなかった。過去の環境にあるsdkと、新たに配置したsdkに用意されているbuild.xmlに差異があったので、ant周りにも変更が入っているようだ。修正が必要だ。

目的は、wiiリモコンを使えるようにする。で、wiiリモコンで遊べるゲームを作りたい。

wiiリモコンの制御自体は、すでに他の人がアプリを公開しているようだが、見た限りではどれもこれも、wiiリモコンをbluetoothキーボードとして使えるようにするとか、そんな感じ。そんなのは邪道だ。

考えているのは、アプリとwiiリモコンが直接通信し、制御する。そのアプリに対し、wiiリモコンを使いたいアプリが接続し、制御アプリを介してwiiリモコンを制御する、みたいな?wiiリモコンの鯖を作るような感じか。

鯖との通信はソケット通信かな。androidに搭載されているプロセス間通信で、他にいいのがあればそっちを使うんだけど。

まぁ、優先順位は高くない。ビルドが通らないんでantroidを修正しないといかんし、現時点でもsdkのツールを使ったダウンロードが遅すぎて終わる気配がしないし。これまた気分転換する時に進めようかと。

ぷよぷよ楽しい。


2013/06/21 17:40

無駄に疲れた。

なんとか、デバイスを列挙する方法とか、接続・切断を検知する方法は把握した。

しかし、ドキュメントが分かりにくい。これなんだけど、英語なのはまぁしゃーない。そこまで期待してない。

まずファイル名が分かりにくい。これ。あれ?それほどでもないか?ファイル名というより、どの機能がどのヘッダファイルにあるのかが分かりにくい。デバイスの列挙や接続・切断の検知関係はintrospect.hとかいうヘッダファイルに書かれてるし。なんやねんintrospectて。日本語でおk。

pavucontrolのソースを読んでpa_sink_infoとかpa_source_infoとかいう、デバイスの情報が入っている構造体があるのは分かったが、どのヘッダファイルに定義されているか分からなくていちいちgrepかけるはめになった。

で、あとはドキュメントの内容が簡潔すぎる。関数1つにつき説明は大体が1行、というか一言、引数や戻り値については説明がない。それで使えるのならいいのだが説明ないと分からんこと多いし。情報が入ってそうな構造体のポインタがnullだった時とかどうしようと思ったわ。

ドキュメントを自動生成とかで作るのは構わないが、役に立たんものを見せられても困るわ。関数の名前とかもいまいちピンと来ないし。その辺気を付けて、ドキュメントとか作らなくていいんで作り直して欲しい気さえする。

結局、役に立ったのはpavucontrolのソースだった。

あーあ、なんか無駄に疲れた。疲れたというかやる気を吸い取られた感。


2013/06/19 15:17

pulseaudioをいじっているが、うーん。

ドキュメントを読んでも、シンプルなAPIと非同期なAPIの2種類がある、ということ以外はいまいち要領を得ない。

で、シンプルなAPIを使ってWAV形式のファイルを鳴らす、というのはできた。

しかし、デバイス名を指定する箇所はあるのだけれど、何を入れたらいいのか分からん。文字列なんだけど、pavucontrolで表示されるデバイス名入れてもだめっぽいし。

というかデバイスの列挙とか検知とかどうやるんだ。pavucontrolではできてるんだから、何かはあるんだろうけど、最悪udevでやることになるのかなぁ。

pavucontrolのソースを読むのが一番手っ取り早いだろうか。

と、ここまでが昨日書いた内容。書いている途中でめんどくなってしまった。

今pavucontrolのソースを読んでいるが、pulseaudio自体にデバイス管理の機能が存在しているようでよかった。

非同期なAPIとデバイス管理、どっちを先にやるかなぁ。なんとなくシンプルなAPIでも問題なくできる気がしないこともないのだが、シンプルなAPIだと複数の音声を出力するためには同時に出力する数だけ接続を確立する必要がある。

これがalsaならなんだそんなこと、とあまり気にしないのだが、pulseaudioの場合、接続1つ1つについて、音量を調節できたりする。自前で音量調節のコードを書かずとも、pavucontrolを使えば調節できる。で、同時に鳴らす数だけ接続が存在するので、例えばBGMとSEの音量を個別に調節できる、というのは便利だろうけど、実際にはSE1つ1つ、異なる音量調節をするような感じになってしまう。多分。さすがに分けすぎである。

なので、利便性とかを考えた場合、やはり非同期なAPIは使う必要があるだろうなぁ、とか。

でもまぁ、とりあえずはデバイス管理が先かな。シンプルなAPIや非同期なAPIとは独立した機能っぽいし。


2013/06/14 16:04

昨日からまたRaspberryPiをいじくり始めている。

前に作った環境は、glibcのバージョンを上げたら戻せなくなって、それが原因で色々なところで詰んでしまって、にっちもさっちもいかなくなってしまった。

なので、環境から作り直している。無論gentooである。現在gcc4.8.1をemerge中。昨日の日付が変わった頃から始めたと思うので、多分日付が変わる頃には終わるだろう。

終わっても、更に長いemerge -e systemとかemerge -e worldが待っているわけだが。

前に作った環境はXをインストールしてデスクトップを使えるようにする、というのはやったけど、今回はとりあえずOpenGLを試したい。ModMyPiにある説明によれば、GPUの性能は×箱と同等らしいし。

今までは上のリンクにあるモデルBしかなかったんだけど、今年の4月からモデルAも発売されていて、気になるところだ。

モデルBと比較すると、LANポート削除、USBポートが2つから1つに、搭載メモリも512MBから256MBになっているなど、性能は落とされているが、その分価格も29.99ユーロから21.99ユーロになっている。

更に、必要な電力も700mAから300mAになっていて、これはUSB2.0の供給電力である500mAより少ないので、パソコンのUSB2.0ポートに接続しても安定して動作するんじゃないかな、と思っている。モデルBはパソコンのUSB2.0ポートだと安定しないからなぁ。これを使っている。

ネットワークに繋がなくてもいい時はモデルAを使って、ネットワークに繋ぐ必要がある、パッケージのアップデートとかする時はモデルBを使う、とかそういうのを思い付いた。

そういえばこれもまだ試してない。せっかく買ってあるのにもったいない。ここに導入方法が書いてあるが、ドライバモジュールはカーネルのメインラインには取り込まれていないようだ。めんどいなぁ。

dpは、とりあえずウィンドウ周りは後回し。ディスプレイの解像度変更に関連して、フルスクリーン表示にするためにタイトルバーなどの装飾なし、リサイズ不可能なウィンドウもサポートしたいけど、フルスクリーンではない、装飾ありのウィンドウも絡めた構成がまだはっきりしない。

前のプロジェクトだとウィンドウのサイズは変更できなかったけど、フルスクリーン時に解像度を変更すればそれに合わせてウィンドウサイズも変わるようにしたいし、それなら装飾ありの場合はウィンドウサイズを変更可能・不可能を選べてもいいんじゃないかなぁとか。変更可能なウィンドウを途中から不可能に変えたり、その逆とかもありかなぁとか。

それらが実際にうまく機能するかとか、そもそも実現可能かとか、色々試してから作りを決定したい。

で、音声出力周りを先にやっつける。前のプロジェクトに用意したAPIは、少し大げさと言うか、ライブラリレベルなのに余計な仕組みを作ってしまった気がするので、今回作るのはもっと単純にする。

前回作ったのは、

dp::AudioPlayer player( device, []( std::vector< char > & _buffer ){ /*バッファに出力する音声データをつっこむ処理*/ } );

いい加減だけど、こんな感じ?dp::AudioPlayerのコンストラクタでスレッドが作られ、インスタンスが存在している間音声を出力する、というもの。

スレッドの中で第2引数のファンクタがバッファに出力データをセットし、第1引数の音声出力デバイスに出力する、ファンクタがデータを返さなくなったらdp::AudioPlayerを消滅できる、という感じ。ファンクタがデータを返し続けている間は、消滅させようとしてもデストラクタで処理待ちになる。

便利と言えば便利なんだけど、環境毎の差異を吸収するライブラリでやることではなかったなぁ、と。なので、今回は単純に、音声出力デバイスをopenして、出力データをまとめたバッファをwriteして音を鳴らし、終わったらcloseする、とか、そういうのでいいんじゃないかなとか。より便利なのは、上位のライブラリに作ればいい。

そうなると、前のプロジェクトじゃ使えなかったXAudio2とか使えるんかな?どういうAPIだったか忘れてしまったので調べ直す必要はあるが、WASAPIはサンプリングレートの変換処理とか必要だったからなぁ。そういうめんどい処理が省けて、問題なく利用できるなら使いたいところだ。


2013/06/13 05:20

疲れた。

なんとか、本登録画面のURL(仮)を書いたメールを送出するところまで出来たっぽいんだけど、疲れた。

ソースはpushしといたけど、続きはまたの機会にしようと思った。起きたらdpの方進める。

何を作ればいいのかも分かっているし進められないことはないのだが、作業量が膨大になりそうだけどその割にできるもののスケールがそれに見合ってない気もするし、なによりなんかつまらん。やはりwebアプリは性に合わんらしい。

またやりたくなったら進めることにする。

Goはおもしろかったんで、たまにちょこちょこいじろう。


2013/06/12 04:58

データストア苦戦中。

大体分かってきた。もうちょいでなんとかなりそうな気がする。

初期の認識では、リレーショナルデータベースに例えると、テーブル1つに1つしか主キーを持てず、トランザクション内では同時に1テーブルの1レコードにしかアクセスできない、と思っていたので、こんなんどうやりゃいいんだと思っていたが。

リレーショナルデータベースとはまた別物なので、リレーショナルデータベースには存在しない部分を知っていったら、なんとかなりそうな気がしてきている。

確かに、リレーショナルデータベースで言うところの主キー、重複不可なキーデータは1つのデータ集合につき1項目しか持てないんだけど、というより強制的に持たされるが、キーデータ自体の参照を項目に加えられるので、専用のデータ集合を別に定義すれば解決できる。

トランザクション内では同時に1データしかアクセスできないが、データ1つにつき1つだけ、親キーを指定することができ、親子関係にあるデータならアクセスできる。

とか書いても、実際にやってみないと大体理解できないのだけど。

リレーショナルデータベースは扱ったことあるけど、その経験が逆に引っかかってしまって、うまく理解できていなかった気がする。

あと、GAE/Goのドキュメントが英語しかないのも理解が進みにくい1つなんじゃないかなと思っている。機能を把握しきれていない。

トランザクション内じゃデータ検索クエリを実行できないんじゃないかなとか思ってたし。親キーを指定してフィルタリングかける関数とかあるんじゃないの。まだ使ってないが、クエリ投げた時に出たエラーメッセージからしてうまくいきそうな香りがぷんぷんしてるわ。

明日中には、まとまった形になればいいのだけれど。把握できていなかったことを知れば知るほど、よりよいアイデアが湧いてくるからまとまらなくて困る。


2013/06/11 13:52

データストアで詰まっている。

これからまた色々試すけど、データストアへの理解がいまひとつ。

GoのデータストアにアクセスするAPIは、GQLとかないっぽい?なんか、全部関数で提供されているような。

それはともかくとして、データストアを扱えないことにはGAEにデータを保存できないわけなので、がんばらんと。できるだけ早く。


2013/06/10 01:11

画面が1つできた。

なんとなくローペースな気がするが、webアプリは経験が浅いので仕方がない面もあるのだろう。焦らずやろう。

画面ができただけで、鯖側は完全に未実装。起きたら作る。

作ったのは、サイトに記事を追加したりするアカウントを追加するための、招待メール送信画面。招待メールに一定時間有効なURLが記載されていて、そこにアクセスすると対応するアカウントが作られるとか、そこらによくあるあれだ。といっても記事を追加するのは私だけなんで、この画面を使うのも私だけ。

なので、シンプル&手抜きな画面になった。こんな感じ。この画面にアクセスするためには、サイトの管理者としてログインしなければならない。その仕組みはGoogleが用意してくれているのでらくちん。その上、この画面は私がアカウントを追加する時に有効にして、以降は無効化、アプリに処理を含めすらしないので、セキュリティ的にも問題はないと思う。

サイトの管理者を乗っ取った上、私がアカウントを追加するために、この画面を有効にした時を狙えば、私以外のアカウントが作られたり、ということは可能だろうけど、まぁ不可能だろう。

私しか使わないので、入力したメールアドレスが正しいかどうかなんてチェックしていない。めんどいし。一応、招待メール無効機能とか付けてるけど、多分完全に死に機能。

あと、この画面はJavaScriptが有効じゃないと機能しない。JavaScriptを使わない版も、作れなくはないだろうけどめんどいしなぁ。私が使わんだろうし、多分作らない。

とまぁ、私しか使わないのをいいことに手抜きしまくりだけど、他の人も見る画面についてはそんなことする予定はないので安心するといい。シンプルなのは多分直らんだろうけど。めんどいし。

ちなみに、今日作った画面はtekuto.netのものではない。記事とかなんやらのデータはRESTfulなAPIを提供する他の鯖アプリで管理し、tekuto.netはそのAPIを利用するだけのクライアントアプリにする、とかそういう想定。妄想。

やろうとすれば、例えばAndroidアプリとしてクライアントアプリを作って、そこから鯖アプリにアクセスしてどうのこうの、とかもできるようにする感じ。やらんだろうけども。やったとしても私専用。他の人がわざわざ専用アプリで閲覧するメリットが感じられん。

RSSリーダ使えよ。RSSの存在自体知らない人向けなの?

私もRSSくらい配信すると思うんで、ヲチしたい奇特な人はそれ利用するといいと思う。

ちなみにRESTfulなAPIを提供する鯖アプリのリポジトリはここなんだけど、内部の処理もできてからpushする予定なのでまだ空っぽ。予定通りにいけば明日中にはpushできるんじゃないかな。


2013/06/09 20:12

Goをやっている。

日本語情報はこっちで、wikipediaはこっち。以前から興味があったし、GAEで使えるんだし、ということで使うことにした。Pythonでもよかったんだけど、せっかくなので新しい物にチャレンジ。

文の末尾にセミコロンがいらない、というところで若干つまずいた。厳密にはいらないのではなく、コンパイラが勝手に付けて解釈しているらしく、まずいところで改行すると文の途中なのにセミコロンが入ってしまうような感じになって、コンパイルエラーになっちゃったりしてた。

でもまぁ、その辺理解したら、いつも書いているような、関数の宣言や呼び出しで、引数1つに1行使う形式で書くことができた。推奨はされなさそうだけど、diff取った時に変更点が一目で分かって便利なので仕方がない。

変数への値の代入演算子(=)とは別に、初期化演算子(:=)が用意されていて、初期化演算子を使えば

var 変数名 型 = 値

とか

var 変数名 = 値

とか書かなければならないところを

変数名 := 値

にできるところとか、地味にうれしい。:=で既に存在している変数を初期化しようとしたり、=で存在しない変数に代入しようとしたりするとコンパイルエラーになる。

なので、PHPやPerlなどのような明示的な変数の宣言が不要な関数でありがちな、変数に値をセットしようとして、変数名間違えちゃって新しい変数が作られちゃった、値をセットしようとした変数の値は変わってないので動くんだけど動作がおかしい、とかいうびみょうに問題箇所を見つけにくいバグが起こらず、それでいてそれらと同等の簡素な記述ができる。いいことだ。

例外処理は存在しないんだけど、関数を抜けた時に処理を行うようにするdeferというものがあり、これでRAIIと同じようなことができるので大して困らなそう。

スレッドは存在しないみたいだけど、ゴルーチンというものがあって、それで処理の並列化ができる。チャネルというものを使えば、同期を取ることもできる。らしい。どっちもまだ使ってない。deferもだけど。

パッケージ外へ提供するもの、しないものの設定方法がちょっとユニーク。先頭文字が大文字ならパッケージ外からアクセスできる、小文字ならできない。らしいんだけど、小文字のものでもアクセスできる場合があるんだけどいいのかなぁ。

名前によって外部からアクセスできるかどうか決める、というのはちょっとPythonぽいな、とか思った。あっちはほとんどただのコーディング規約だけど。

構造体とかインターフェース周りもまだ触っていないんだけど、JavaやC++のクラスとかとはまた違った空気がしていて興味深い。

dpをGoで書くのもありかもしんないなぁとか思った。


2013/06/07 00:18

おはようございます。

諸事情によりサーバを移転しました。現在はサーバというか、Google App Engineの1アプリとしてサイトを稼働させています。

ある日、レンタルスペースに配置したMovable Typeにログインしても、ページ遷移したらすぐログアウトしちゃうようになってて、困っていた。

原因はDBの容量がいっぱいになっちゃてて、セッション情報すら持てないような状況だった、ってことなんだけど。

サイトのコントロールパネルから、DBの全テーブルに最適化をかければいくらか容量空くだろう、と思って最適化しようとするも、insertできません><権限ないんで><とかわけのわからんこと言われるし。

deleteは通るし、とりあえずスパムコメントのレコードだけでも消しておくか、なんか変わるかもしれんし、とかやって放置していた。

で、今日になって、dpにまた1つ機能ができたので、それについて記事書くかーとMovable Typeにログインしようとしたら404。サイトのコントロールパネルにログインしたら、アカウントはブロックされていますだって。

私だってなんとかしたかったがどうしようもなかったからしょうがないじゃないの。どうすりゃよかったと言うのだ。問い合わせ?英語むり。

そんなわけで、以前から考えていたGoogle App Engineへの移転に踏み切ったわけです。DBの容量10MBとか最初から無茶だったんだ。アカウントはブロックされていますのページに可能な対応と思われることが色々書かれていたが英語とか読めねぇしもうたくさんだ。海外の鯖なせいかレスポンス性能もよろしくないというか稀によく落ちてるし。

Google App EngineはGoogle先生が運営してるんで、レスポンス性能は前よりずっといいと思う、多分。稀によく落ちることもないんじゃないかな、多分。

Google App Engineに移転したといっても、現時点では見ての通りタグ打ちの静的なページだけ。staticの中ね。

そのうち、タグ打ちしなくてもブラウザ上から投稿だとか、投稿に対してコメントだとか、そういうのできるようにする予定は一応あるんで。

でもめんどいんでしばらくお待ち下さいと思ったが、dpがちょうどいいところだし、進めてみようかなぁ。

飽きたらすぐdpの開発に戻るが。

とまぁ、しばらくはこんな感じで、昔みたいな1ページ運用になるのでよろしくお願いします。


戻る