ワンセグTVのデバッグは効率が悪い
今、仕事でワンセグTVのソフト開発を行っているが、字幕表示がらみのバグがなかなか現象再現せず、苦労している。
操作して、字幕を眺めて、ということを延々とやらなくてはならない。
おもしろい番組だとそっちの方見入っちゃったりすることもあるし...
Rails勉強会に参加(9/16)
約二ヶ月ぶりの参加となった。
参加したセッションは、以下の2つ。
-
- 初心者セッション(悩み相談室)
- Scaffoldの次へ
今回、ポジションペーパーのお題として「好きなプラグイン」が提示されていました。
自分は、今までプラグインなどあまり使ったことが無かったので、特に回答のしようがなかったが、参加者のみなさんが使っているプラグインをちゃっかりメモしておいた。(後で調べてみる)
前回もそうだったのだが、プラグインって結構話題にのぼることが多いので、Railsの世界ではプラグインとかを活用して、(自分でゴリゴリ書くのではなく)さっさと動くものを作ってしまうのが文化なのかな?と思ったりした。
後半セッションは、Railsの環境を前提としてScaffoldを実際に実行してアプリケーションを動かすというものだったが、告知情報をよく見ていなかったのでNote PCも持たずに参加してしまいました。申し訳ないです...
でも、話の合間でRuby/Railsのデバッグの仕方が聞けたのは収穫でした。今までいわゆる"printfデバッグ"しか知らなかったもので...
今回2回目だったが、やっぱり社外の人といろいろ情報交換するのは刺激になるな〜と思った。
これからもできるだけ参加していこう。
本日のハマりメモ
同じ過ちを繰り返さないようにメモっておこう。
指定秒数処理を遅らせたい時に安易にsleep使わない
Javaでプログラムしてた時は、あんまりマルチスレッドなプログラムに触れる機会がなかったので、処理を遅らせたい時はsleepをよく使っていたが、組込みシステムだとバックグラウンドで動いているタスクがたくさんある。
sleep*1は「OSに制御を返すんだ」と言うことを肝に銘じておこう。
sleepしている間は他の処理が動く。画像などを指定秒数表示するためにsleepなんか使っても、他のタスクで消されちゃったりすることもある。
戻り値の定義された関数は必ず値を戻す
あたり前だけど。JavaはエラーになるけどCではエラーにならないみたい。
今日のはポインタを返す関数だったので、呼び出し側でメモリ開放とかしていてエライことになっていた。
助かったのは、最近tracのチケットとあわせ、細かくコミットするよう心がけているため、正しく動いたバージョンとの差分をチェックしてあたりをつけられたことだ。単純にトレースしてたらもっと時間がかかっていただろう。
こう書いてみると、まだまだ初心者がするようなミスをしてしまうなぁ。
恥ずかしい．．．
*1:実際は環境によって違う関数名だったりするけど
RailsでTinyMCEを使う
自分で作っているアプリケーションにリッチテキストなエディタを使いたいと思い、TinyMCEを使うことにした。
通常使う分にはTinyMCEをインクルードして初期化するだけでよいみたいだけど、Ajaxで動的にフォームをロードしているような状況だと、いろいろ問題が出て苦労した。
以下、今回対処した手順をメモ。
フォーム生成時にtinyMCE初期化を行う
通常は、HTMLのロード時にTinyMCEが対象のtextareaを見つけてリッチテキスト化するけど、動的にロードする場合は自分で初期化してやらなければいけない。
以下の記述はlink_to_remoteタグでフォームをロードするという前提。
設定のポイント:
- synchronousにする (synchronousにしないと、次項afterオプションのJavaScript実行時に、tinyMCEが対象のtextareaを見つけられない)
- afterオプションで以下のJavaScriptを実行
tinyMCE.idCounter=0; // "this.getDoc() has no properties"というエラーがやたらと出る対策のため → *1 tinyMCE.execCommand("mceAddControl",true,"targetid"); // targetidはリッチテキスト化するtextareaのid
-
- *1 - エラーの内容と対処はこちらのリンクに示してある 参照
入力したリッチテキストの更新
リッチテキストの実体は、対象のtextareaを隠し、その直下(nextSibling)に挿入されているみたい。
従って、フォームをsubmitする前にエディタに入力されたテキストを本来のtextareaに戻してやらなければならないが、動的ロードした場合だとどうもうまく動かないので、自分で移送してやることにする。
設定のポイント:
- form_remote_tag の beforeオプションに以下のJavaScriptを実行するように設定
copyMCE2TextArea("targetid"); // targetidは対象フォームのID
- copyMCE2TextAreaは以下のようなスクリプト
function copyMce2TextArea(id) { var form = $(id); var areas = form.getElementsByTagName('textarea'); for (var i = 0; i < areas.length; i++) { var area = areas[i]; var frame = area.nextSibling.getElementsByTagName('iframe')[0]; area.value = frame.contentDocument.body.innerHTML; } }
-
- リッチテキストはiframeで挿入されるようだ。数が多くなるとなんか重そう。
- iframeのコンテンツはcontentDocumentプロパティで取得できる。
木構造のデータを扱ういつもと違うアプローチ
アイデア自体はかなり昔にどこかのコラムで見たことがあり、頭の隅に置いていたのだが、上記リンクではかなり詳しく説明されていたのでまじめに読んでみた。
今まで、ここでいう「隣接リストモデル」でしか木構造データを扱う術を知らなかったのだが、
-
- データに対し多様なクエリーを発行する必要がある
- データに対する更新操作があまり発生しない
のような特性を持つシステムでは、ここで紹介された方法を使うメリットがあるのではないかと思った。
要約すると以下のような感じ。
データの表現
- 広く使われている「親項目へのポインタを保持する」方法で木構造を表す方式を「隣接リストモデル」と呼ぶ。
- ここで紹介する方法は「入れ子集合モデル」と呼び、要素の包含関係で木構造を表す。
- 各要素は left, right の項目を持ち、right > left の関係を持つ。
- ある要素に着目したとき、left, right の範囲を包含する要素が親に相当する。
→ 親.left < 子.left < 子.right < 親.right の関係が成立する
