テキストを日本語的に傍点（圏点）で強調するJavascript
ふと思いついてテキストに傍点をつけるためのスクリプトを作りましたので、ご紹介。（ソースはGitHubに置いてます）
「傍点」は「圏点」ともいうらしいのですが初耳でした。この文書では以降「傍点」で通します。
「傍点によるテキストの強調」は、CSS3のtext-emphasisスタイルで定義されていますが、ブラウザによって対応状況が大きく分かれているようなので、このスクリプトを作った次第。
Safari、Chrome等、Webkit系の「傍点対応ブラウザ」では素直にそのままCSSで表現しますが、IEやFirefoxなどの未対応のブラウザでは「ルビ（RUBYタグ）」を利用して、なんとかしました。
ウェブ上で傍点は、あまり使用することがありませんが、強調というよりも単語の区切りをはっきり示すために使いたい事があります。特に、句読点を入れると、文章のリズムに違和感を感じるような場合などですね。
※ ルビに未対応のブラウザでは、かなりおかしな表示になってしまいますが、傍点よりは対応状況が良いようです。2015年11月の時点で、IE、Firefoxの最新版は、全てRUBYに対応してます。Operaはプラグインで対応できると聞きましたが、使用していないので詳しく分かりません。
ゲームで学ぶJavaScript入門 HTML5&CSSも身に付く!
posted with amazlet at 15.11.28
傍点のスタイル
CSSのtext-emphasis-styleで指定するのと同じ表現が可能です。
| style | filled | open |
|---|---|---|
| dot | 横転 | 好転 |
| circle | 争点 | 当店 |
| double-circle | 脳天 | 法典 |
| sesame | 盲点 | ０点 |
| triangle | 栄転 | 経典 |
簡単な適用
class='bauten-text-emphasis'となった要素に傍点をつけるのなら、bauten.jsを読み込むだけです。この場合は、黒丸(filled dot)付けられます。
要素とスタイルを指定する
傍点を適用する要素や、そのスタイルを指定するには、bauten.jsを読み込んだ後のSCRIPTで、bauten関数を呼び出します。
引数は以下のキーを持つオブジェクトです。
| キー | 説明 |
|---|---|
| className | 傍点を打つ要素のクラスを指定します。複数のクラス名をスペースで区切って指定できます。この場合は全てのクラス名を持つ要素が対象になります。 |
| tagName | 傍点を打つ要素のタグ名を指定します。 |
| style | 傍点のスタイルを指定します。CSSのtext-emphasis-style と同様の指定方法です。 |
| color | 傍点の色を指定します。 |
※ classNameとtagNameのどちらかは指定されなくてはなりません。styleは必須。colorが省略されるとベースの文字色に従います。
※ bauten関数を呼び出した場合、既定の動作は抑制されます。
例：クラス名による指定
例：タグ名による指定
任意の文字を傍点にする
任意の文字を傍点にできます。これもtext-emphasis-styleと同様の機能です。
- たとえばーきみがいるだーけで
- にわにはにわのにわとりがいる。
例
傍点の色を指定する
傍点には色を付けられます。これもtext-emphasis-colorと同等。
ブルー・ノート・スケール（ブルース・スケール、blue note scale）は、ジャズやブルースなどで使われる、メジャー・スケール（長音階）に、その第3音、第5音、第7音を半音下げた音を加えて用いるもの、もしくはマイナー・ペンタトニック・スケールに♭5の音を加えたものである。特に、♭5の音をブルー・ノートと呼ぶ。近代対斜の一種でもある。
例
リポジトリ
SQLiteのSQLのパラメータ化できる箇所
SQLiteのSQLiteDatabase.rawQueryで、SQLのパラメタライズが、できる場所とできない場所がありまして、調査結果を記しておきます。
「単なる文字列置換」では無いようです（よくよく考えれば当たり前ですね）。
SQLiteDatabase.rawQuery
概要
単純にSQLをそのまま実行するメソッド。SQLのパラメタライズも可能です。
プロトタイプ
Cursor SQLiteDatabase.rawQuery(String sql, String[] paramValues);
引数
使い方例
ざっくり以下のような使い方です。
// android.database.
// Cursor
// sqlite.
// SQLiteOpenHelper
// SQLiteDatabase
SQLiteDatabase db = openHelper.getWritableDatabase();
Cursor cursor = db.rawQuery(
"SELECT id, description, amount, date"
+ "FROM t_wallet " /* v v */
+ "WHERE description like ? AND amount >= ?",
new String[] { "'ポテト%'", "100" });
while(cursor.moveToNext()) {
int id = cursor.getInt(0);
String description = cursor.getString(1);
int amount = cursor.getInt(2);
byte[] blobDate = cursor.getBlob(3);
// ・
// ・
// ・
}
WHERE句の条件にある?を置き換えています。
条件式などの値を置換できます。
しかし単に文字列置換をしているのではなさそうでして、
【できない】文字列リテラルの中身は置換されない
たとえば、description like ?の部分を、description like '%?'とはできません。
あくまでもシングルコーテーションで囲まれている部分は、文字列リテラルとして扱われるので、その中の?は置換されず、単に?で終わっているdescriptionを見つけてきます。ただ、第二引数の要素数が合わない場合は例外が投入されます。
【できる】式の一部の置換はOK
以下のように、式の一部は、置換できます。
rawQuery(
"SELECT id FROM t_wallet " +
"WHERE amount >= ? + 30", /* OK */
new String[] { "100" })`
※ これ、当初「できない」としていましたが、できました。別の要因で例外が出ていたのかも。すみません。
また、以下のように、単独の値でなくてもOKです。
rawQuery(
"SELECT id FROM t_wallet " +
"WHERE amount >= ? + 30", /* OK */
new String[] { "(80 + 20)" })`
ところが、次のは駄目でした。「構文エラー」になります。
rawQuery(
"SELECT id FROM t_wallet " +
"WHERE amount >= ? ) + 30", /* NG */
new String[] { "(80 + 20" })`
?を式として扱って、第1引数のSQL単独で構文エラーになるのは駄目っぽいですね。
【できる】カラム名もOKです
以下のようにSELECT句やWHERE句、ORDER BY句の、カラム名は置換可能でした。
db.rawQuery(
"SELECT ? FROM t_wallet " +
"WHERE ? <= ? ORDER BY ? DESC",/* OK */
new String[] { "description",
"amount", "100", "amount"})`
しかし、
【できない】FROM句のテーブル名はダメでした
予想に反して、テーブル名は置換できないようです。
rawQuery(
"SELECT description FROM ? " + /* NG */
"WHERE amount <= 100 " +
"ORDER BY amount",
new String[] {"t_wallet"})
そして、
【できない】ORDER BY の DESCもダメですね
これ、できても良い気がしましたが、しっかり例外が投入されました。
rawQuery(
"SELECT description FROM t_wallet " +
"WHERE amount <= 100 " +
"ORDER BY id ?", /* NG */
new String[] {"DESC"})`
まとめ
結果をまとめると、以下のようになりました。
置換可能
- カラム名
- 値
置換できない
カラム名も構文的には式ですから、?は式を置換できるということで良いのかな。
キャリブレーションしてステレオマッチングやってみた
例によって、百均で購入した2台のWEBカメラをステレオキャリブレーションして、ステレオマッチングをやってみました。
低価格＆低品質のウェブカメラで、マジメにキャリブレーションする意味なんてあるのかどうかわかりませんが、今後とも頑張ってやっていきます。いくつになってお勉強です。
高級ステレオカメラシステム（笑）紹介
今回から以下のように、カメラをキチンと固定しました。位置がずれたらキャリブレーション取り直しですからね。
押入れから引っ張り出してきた金属製のブックエンドに、そこらに転がっていたマスキングテープで固定しました。有り合わせ感たっぷりですが、これで充分機能してます。 カメラの後ろのはキャリブレーション用のチェスボードです。
大人の科学マガジン Vol.14 ( ステレオピンホールカメラ ) (Gakken Mook)
posted with amazlet at 15.10.13
ソフトウェア
全てGitHubに置いています。
利用している画像処理ライブラリについては以下を参照してください。
キャリブレーション機能
ステレオキャリブレーション
ステレオキャリブレーションには、位置関係が固定された2つのカメラと、チェスボードが必要です。 2つのカメラで同時にチェスボードを撮影した複数の画像からキャリブレーションするのです。
stereoShot - ステレオキャリブレーション画像保存ツール
位置関係が固定されているのに、毎回、キャリブレーション画像を撮影しなおすのは無駄ですから、事前に保存した画像を実行時に読み込んで、キャリブレーションするようにしています。
この画像を保存するツールが、stereoShotです。
stereoShotを実行すると左右のカメラ画像が表示されます。各カメラが11x9のチェスボードの内部の交点を検出したら、それぞれ画面に描画します。スペースバーを押せば、両方の画像をファイルへ保存します。
ステレオキャリブレーションのためには、両方のカメラでチェスボードの交点を検出している必要があることに注意してください__
画像ファイルの保存先
画像ファイルの保存先は、既定ではカレントディレクトリとなっています。画像ファイルは、cal_という名前で始まります。これを変更するには-C オプションを使用します。このオプションでサブフォルダに出力することも可能です。たとえば、stereoShot -C sub/cal とすれば、サブディレクトリ sub にcal_で始まるファイルが保存されます。
画像は数10枚必要とのことですが、今のところ15セット（左右あわせて30枚）でなんとかなっているようです。
StereoBlockMatchでキャリブレーションを有効にする
stereoShotで保存したキャリブレーション画像を読み込んで、ステレオマッチングを行うには、StereoBlockMatchに、stereoShotと同様の-Cオプションを指定します。-Cを指定しない場合は、従来通りキャリブレーションなしでマッチングします。
パラメータ表示・変更機能
ステレオブロックマッチに使用するパラメータの多くを、実行中に変更できるようにしました。
変更可能なパラメータは画面の左上に表示されており、左端の一文字をキーボードから入力して、[+]と[-]で変更できます。変更は即時反映されます。
詳解 OpenCV ―コンピュータビジョンライブラリを使った画像処理・認識
posted with amazlet at 15.10.13
実行結果
以下は、キャリブレーションなしとありの結果です。パラメータは同一で、「あり」は各々のカメラ画像をキャリブレーション結果でremapしてるかどうかの違いだけです。 ウィンドウの左上が右側カメラで、右上が左側。交差法（より目）で見れば立体的に見えるはず。左下はStereoSGBMで得られた視差画像。右下は視差画像の15回の移動平均画像です。
若干細かい部分の精度が改善しているように思いますが、実際のところ、その差は微妙。
カメラの品質によるところが大きいと思いますが、撮影環境やパラメータの調整でも大きく結果が異なります。
あと、キャリブレーションの有無で出力画像のピクセルが反転していますね。
今後の課題
- ステレオマッチングのパラメータの理解
- キャリブレーションの正当性チェック
- 3次元画像の可視化コードのチェック
(1)パラメータは適当に決めているので、細かく調整しながら様子を見てみます。各々のパラメータの意味も、キチンと理解していません。 また、(2)キャリブレーションのやり方によると思うのですが、補正後の画像が大きく回転したりずれていたりすることがあり、その機序を理解していません。 それから、(3)視差画像の可視化についても、なんとなく適当にやっていますので、このあたりのチェックが必要かと思います。
所感など
キャリブレーションの有無で、あまり差が出なかったので、かなり動揺（笑）。
品質の安定したWEBカメラを買うかどうか思案中。百均は限界かな。
参考サイト
TAKARA TOMY 3D ショットカム ホワイト 3D トイデジ W
posted with amazlet at 15.10.13
OpenCVステレオキャリブレーション用チェスボードコーナー検出ツール
ステレオカメラのキャリブレーションのために必要になる簡単なツール stereoShot を作りましたので、ご紹介。
stereoShotは、2台のカメラで同時にチェスボードをキャプチャーして、コーナー検出の情報を表示し、複数の画像ファイルを保存します。 複数の画像は、キャリブレーションに使用します。
stereoShot - ステレオキャリブレーション用画像保存ツール
実行中の画面
ちょっと見にくいですが、例によって100均カメラ（笑）。 見ての通り、左右の品質に差がありすぎて、向かって右の品質が悪すぎて検出精度がダメダメです。 ちゃんとしたWEBカメラを使えば問題ないと思います。
OpenCV 3 プログラミングブック
posted with amazlet at 15.10.08
使い方
実行すると、2台のカメラのキャプチャー画像が横に並んで表示されます。
カメラデバイスインデックス
それぞれのカメラの、キャプチャーデバイスインデックスは、右が1、左が2となっていますが、コマンドラインオプションで変更可能。 以下の例では、右を2、左を1に変更しています。
$ ./stereoShot -R2 -L1
専用チェスボード
キャリブレーションには11x9のチェスボードが必要です。GitHubのリポジトリからダウンロードできますので、印刷して使ってください。
チェスボードの認識
各カメラがチェスボードを認識すると、そのコーナー（チェスボード内部の交点）を検出して画面に描画します。（検出時点でフレームレートが低下します）
画像の保存
画像ファイルの保存は、スペースバーを押して実行します。左右のカメラのキャプチャ画像がカレントディレクトリに保存します。ファイル名はcap_<連番>_<L or R>.jpgというようになっています。保存される画像に、画面表示されている検出されたコーナーは描画されません。
この画像を読み込んで、キャリブレーションしステレオマッチングするところは、以下のエントリーで説明しています。
ビルド方法
メイン関数は stereoShot.cpp。 その他、詳細はREADMEを参照してください。
当初チェスボードを8×8にしていたのですが、コーナーの検出順序が安定しませんでした。縦と横が同じだと縦横の判別がつかなくなるようです。 そこで、11x9に変更したら、問題は完全に解消しました。
制限事項
- チェスボードは 11×9に固定しています。
- 今のところ、Windows の Visual Studio 2015でしかビルドが通らない状態です。
関連エントリ
参考サイト
ほぼ初めてのPLCで感じたラダーの勘所
photo credit: Ladder via photopin (license)
この夏、ラダーが熱かった。7月半ばに、初めて本格的なPLC案件を担当してから、もう2ヶ月か･･･。
本来パソコン側のソフトウェア担当です。PLCと通信して機器設定情報を編集したり、生産実績を収集するよなソフトウェアの経験こそありますが、PLCのソフト（ラダー）の経験はごくわずか。それも組み込みシステムのデバッグ用に接点信号を一定周期でON/OFFするような簡単なものしか作ったことがありません。まあ、ほとんど素人ですね。
7月当初の案件は予定通りのアサインでした。 慣れない作業ですが、盆明けにはなんとか完了。 しかし、その間、隣でくすぶりつづけていた案件が（匂いはしてたw）、ニッチもサッチも行かなくなってドッカンドッカン大炎上。 急遽、消火活動のため、ネコの手よりは役に立つだろう…とアサインされて、半径30km範囲のイッサイガッサイ巻き込んで、ワッショイワッショイの3週間。なんとか鎮火した次第です。
てなことで、今回、本気でPLCに取り組んで経験値が少し上がりましたけど、そのうち忘れてしまいそうだし、もったいないから自分のためにも書き残しておこうと思います。
【ASTARTE】 トレーニング ラダー 5M 7M 収納袋 ＋タオル セット アジリティラダー ブルー イエロー レッド (ブルー, 7m 13枚)
posted with amazlet at 15.09.13
ASTARTE
目次
- ところで「ラダー図」知ってますか？
- 「逆よ、全く逆よ。見えてくるわよ、本当のラダーが」もしくは「今考えている事の逆が正解だ」あるいは「右から左へ受け流す」― 解析やデバッグは、出力側から逆向きに追いかける
- 「直接操作は最後の手段。おいらはここで自己保持る」（安易にコイルをセット・リセットしないで出来れば自己保持しましょうね）
- 「ラダーは開発室で動いているんじゃあない実機で動いているんだっ」(四の五の言わずにモニターする）
- 「もう無茶苦茶でござりまするがな（泣」(手動マージで疲労困憊。PLCにはVCSの概念が丸ごと無い)
ところで「ラダー図」知ってますか？
プログラマブルコントローラ原理と設計法 (設計技術シリーズ)
posted with amazlet at 15.09.13
いや、ラマーズじゃなくて「ラダー図」です。
「ラダー＝ハシゴ」ですね。回路図がハシゴのように見えるからです。
こんな感じ↓
「ラダー回路」と言ったりもしますね。 本質的にはリレー回路を指すのかもしれませんが、ここでは、PLCにプログラムする回路（ソフトウェア）を指しています。
以下、本題に入る前に、ラダーに関する基本事項を箇条書きにしておきます。詳細は調べてみてください。
ラダーの基本
- リレー - 電磁石でスイッチをON/OFFする電気部品。PLCの中の仮想的なリレーを意味することもあります。また、それを補助リレーとも言います。
- リレー回路 - 複数のリレーとPLC外部と入出力する信号を目的に応じて接続して、全体で自動的な制御を行うようにする論理回路です。
- PLC - 「プログラマブル・ロジック・コントローラー（Programmable Logic Controller）」の略。リレー回路をコンピューターでシミュレートしているような機器です。現物は、だいたい小さめのタッパーからお弁当箱くらいまでの大きさの箱です。電気信号の入出力機能を備えた制御用のコンピュータです。
- コイル - リレーとほぼ同じ意味で使います。通電しているときと通電していないときで、接点の状態が変わります。
- 接点 - リレーでON/OFFされるスイッチみたいなものです。つながっているか切断しているかという2つの状態があります。接点を1つ以上つないで論理回路を構成します。
- 論理回路 - 真か偽かを入力して真か偽かを出力する回路ですね。A接点、B接点、論理積（AND）、論理和（OR）を組み合わせて構成します。
- A接点 - コイルに通電するとつながる接点。
- B接点 - コイルに通電すると切断される接点。
- 論理積（AND） - 接点を直列につなげたものです。電池と2つのスイッチと豆電球をつないで、両方のスイッチを押して始めて豆電球が点灯するような回路。
- 論理和（OR）- 接点を並列につなげたもの。電池と2つのスイッチと豆電球をつないで、どちらか片方を押せば点灯するような回路。
- 自己保持 - コイルのA接点が、それ自身の条件にORで入っていると、入力接点が一瞬ONになっただけで、その後の入力状態に関わらず、コイルのA接点がつながっている状態を保つ状態。
↓↓↓さてさて、ここからが本題です↓↓↓
「逆よ、全く逆よ。見えてくるわよ、本当のラダーが」もしくは「今考えている事の逆が正解だ」あるいは「右から左へ受け流す」― 解析やデバッグは、出力側から逆向きに追いかける
MOOMIN ムーミン カオ マグカップ ミイ MM622-11
posted with amazlet at 15.09.13
山加商店
売り上げランキング: 10,979
売り上げランキング: 10,979
ラダーには、左側に複数の接点、右側に出力コイルが記述されます。接点がつながったら、コイルに通電されるのです。
ところが、これを通常の文書と同じように、左から右へ順に見ても、いまいち理解が進まないと思います。
逆に、コイルの意味を理解した上で「これが出力される条件とはなんなのだ？」という気持ちで、左側の論理回路を見れば、すんなり理解できると思います。
たとえば、自動販売機でコーヒーを買うときの動作は、
「お金を入れて、このボタンを押せば、このコーヒーが出てきます」
ではなく、
「このコーヒーが出てくるのは、このボタンを押したときだな」と。さらに「このボタンを押せるようになるのは、お金を入れた後で、どのボタンも押されていないときなんだな」
と、読み替えるような感じです。
「直接操作は最後の手段。おいらはここで自己保持る」（安易にコイルをセット・リセットしないで出来れば自己保持しましょうね）
マ・マー 早ゆで3分スパゲティ1.6mm チャック付結束タイプ 500g×4個
posted with amazlet at 15.09.13
PLCでは、コイルへの出力（OUT）命令とは別に、SETやRSTといったコイルの状態を直接指定する命令があります。 これはそのコイルの自己保持と、その解除に相当する命令です。
二重コイル（複数回、同じコイルに対するOUT命令がある状態）はご法度ですが、SETとRSTはいくらでも好きなだけ書けます。 しかし、広い範囲に渡って安易にこれらを使用すると、どこで何が行われているのかわかりにくくなってしまいます。
また、SETとRSTは、処理内容がその順序に依存してしまい、ややこしいことになりやすい。 ラダーは「回路」なので、基本的には順序に関わらないのですが、SET/RSTの使用で、この前提が崩れるからです。
自己保持の為に補助リレーを追加する必要があっても、できる限りOUT命令で構成するほうが望ましいと思います。 その箇所だけでコイルの状態が替わり、全てが、そこに記述されているので、理解しやすく、デバッグも楽になるはず。
「ラダーは開発室で動いているんじゃあない実機で動いているんだっ」(四の五の言わずにモニターする）
![踊る大捜査線 THE MOVIE~湾岸署史上最悪の3日間!~(特別版) [DVD]](http://ecx.images-amazon.com/images/I/51m%2BgJOUxAL._SL160_.jpg)
踊る大捜査線 THE MOVIE~湾岸署史上最悪の3日間!~(特別版) [DVD]
posted with amazlet at 15.09.13
デバッグ時など、机上であれこれ考えるより、実際にラダーを動かして接点の状態をモニターするのが一番です。PC持って実機の前へ陣取りましょう。
思ったとおりの出力が得られていないなら、左の論理回路が想定通りになっていないはず。
論理回路が間違っていれば修正しますが、接点の状態が想定と違うなら、その接点の出力部分をモニターして、繰り返しです。
自己保持回路では、自己保持される時に確認する必要があるかもしれません。
このようにタイミングが限られていたり、SET/RSTで状態が変化している場合は、確認用のロジックを追加するといった、ひと工夫が必要かもしれません。
「もう無茶苦茶でござりまするがな（泣」(手動マージで疲労困憊。PLCにはVCSの概念が丸ごと無い)
今回の消火活動で一番困ったのがこの問題です（未解決）。
この炎上案件、当初担当していた業者さんが、無茶苦茶なラダーを残して納品日を前に逃げちゃったので、複数人でラダーを修正しないと間に合わないという状況でした。
ところがここで、まさかの手動マージ。ラダーのプログラムがバイナリーファイルなんですよ。コンフリクトしたら終わりですから、もう仕方が無いです。
どうやらこのPLCの世界では、バージョンコントロールシステムという概念が無いようです。
複数の人が同時に編集作業を行うのは想定外。必要なら後で慎重に手マージするしかないという風潮（？）でした。
ちなみに「マージ」や「ブランチ」といったVCS語が通じないだけでなく、作業手順的なセオリーとして、コミットをなるべく小さい単位で刻んだり、他の作業者とコンフリクトが発生しにくいように声をかけるといったこともあまり理解されていないようでした。担当者の経験年数によるものかも知れませんが。
普段Gitでなれている私たちにとってはいろんな面で衝撃でした。なので、ラダー用のVCSがあれば、PLCの開発風景がドラスティックに変わる気もします。 というか、PLCプロジェクトの統合環境がテキストファイルを吐いてくれたら全て解決するのですが・・・。
photo credit: Dezomeshiki via photopin (license)
