テクデップ（Techdep）

コンピュータ、プログラミング、DTP（InDesign）に関する備忘録

Windows Phone 7.5からFirefox OSへの連絡帳の移行

　題名の通り、Windows Phone 7.5からFirefox OS（Fx0 LGL25）へのアドレス移行の備忘録である。連絡帳はMicrosoft Peopleに自動同期されているのを前提とする。自動同期されていれば、Firefox OS（Fx0 LGL25）での操作だけで移行は完了する。

  1. まずは「連絡先」のメニューを開くと、「連絡先のインポート」があるのでそれを開く。
  2. 連絡先の同期元として、「SIMカード」「メモリカード」「Gmail」「Outlook」とあるが、「Outlook」を選ぶ。
  3. Microsoftアカウントのログイン画面に遷移するので、それのログインIDとパスワードとでログインする。
  4. 連携アプリ認証が求められるので認証を許可する。
  5. 許可後に連絡先が自動的に読み込まれ、読み込まれたアドレス一覧が表示される。ここで端末に保存しておきたい連絡先を選んで完了。

InDesign向けJavaScriptでの検索・置換

Adobe InDesign JavaScript

　題字の如く、InDesign向けJavaScriptにおける検索や置換のコードについて実例を示す。なお、Windows版InDesign CS6で動作を確認した。

テキスト検索

　基本的な手続きとしては、検索条件のプロパティを設定し、置換テキストを設定し、検索を実行するコードを記述する。

//プロパティの初期化
app.findTextPreferences.findWhat = NothingEnum.nothing;
app.changeTextPreferences.changeTo = NothingEnum.nothing;

//検索条件と置換後の文字列との設定
app.findTextPreferences.findWhat = "検索文字列";
app.changeTextPreferences.changeTo = "置換後文字列";
	
//現在編集中の全てのドキュメント
app.changeText();

//選択範囲
var text = app.activeDocument.selection;
for(var i = 0; i < text.length; i++) {
	text[i].changeText();
}
	
//ドキュメント全体
for (var i = 0; i < app.activeDocument.pages.length; i++) {
	var pageObject = app.activeDocument.pages[i];
	for (var j = 0; j < pageObject.textFrames.length; j++) {
		pageObject.textFrames[j].parentStory.changeText();
	}
}
	
//検索条件等の消去
app.findTextPreferences.findWhat = NothingEnum.nothing;
app.changeTextPreferences.changeTo = NothingEnum.nothing;

　app.findTextPreferencesオブジェクトのプロパティが、appオブジェクトのメソッドの挙動に影響するのみならず、selectionのメソッドやparentStoryのメソッドの挙動に影響を及ぼすことに注意。
　以下の正規表現や字形置換でも同様である。

正規表現

　簡潔に設定部分だけを示す。手続きは先と同様である。

//検索
app.findGrepPreferences.findWhat = "(\\d)";

//置換
app.changeGrepPreferences.changeTo = "$1";

　置換メソッドはchangeGrep()を使用する。検索範囲に合せて、上記のコードのchangeTextメソッドを置き換えればよい。
　

字形置換

　これも手続きは同じだが上記と比べると設定が少し厄介だ。先と同様に設定部分だけを示すが、フォント名を正しく指定しないとエラーが出る。また、フォント名とウェイトとは「タブ」で繋ぎ、GlyphIDプロパティにCID番号を指定する。

//検索条件
app.findGlyphPreferences.appliedFont = app.fonts.item("小塚明朝 Pro" + "	"+"R");
app.findGlyphPreferences.glyphID = 2051;
    
//置換設定
app.changeGlyphPreferences.appliedFont = app.fonts.item("小塚明朝 Pro" + "	"+"R");
app.changeGlyphPreferences.glyphID = 4467;


　置換メソッドはchangeGlyph()を使用する。今までと同じく検索範囲に応じて呼び出すべきメソッドが属するオブジェクトが異なることに留意する。

引用符の基本的な記法

組版

　文章を書くと多かれ少なかれカギ括弧の類を使う。その用途は台詞を示すものであったり文意の強調であったりと様々であるが、開き括弧と閉じ括弧とを対応させるというのはカギ括弧の使い方の基本（作文の基本）として認識されているだろう。
　それでは“引用符”の類はどうだろうか。カギ括弧の使い方を間違える人はまず居ないだろうが、引用符になると普段使わない人も多いから途端に使い方に誤りが見られる。今回は引用符（和文限定）についてあれこれ書いておきたい。

※ここでは引用符をシングルクォーテーション、ダブルクォーテーション、ダブルミニュートと定義する。
※書かれた原稿が最終的には印刷物もしくは電子書籍などの様にある程度体裁が整えられた状態に編集されるとする。

続きを読む

疑問符や感嘆符の後ろは必ずあける？

組版

疑問符や感嘆符の直後にはスペ－スを入れる

　小説に限らず、それなりに文章を書いた経験がある人ならば、上記のルールはよく知っているだろう。一般に以下の様な表現は妥当でない。
　

アイエエエエ！エクセル方眼紙！？エクセル方眼紙ナンデ！？

　校正者や編集者の手によって、上記の文章は次の様に直されるだろう。
　

アイエエエエ！　エクセル方眼紙！？　エクセル方眼紙ナンデ！？

　何故スペースを入れるのかというと、これらの疑問符や感嘆符は「句点と同じ役割」で使用しているからである。すなわち、文章の区切りを明示させるため、スペースを入れているのである。
　

三種類の例外

　もちろん上記の原則には例外がある。この例外は三つあるとされ*1、

  1. 直後に終り括弧類が来る場合
  2. 直後にダーシや三点リーダが来る場合
  3. 文脈上、アキを入れると不自然な場合

の何れかに該当するとき、スペースの挿入は不要であるとされる。
　さて、一番最後にあげた例外は認知度が低いため誤解をよく招く。本稿では各例外を説明しつつ、認知度が低い例外についてどう対処すべきか考えたい。

*1:『文字の組方ルールブック　縦組み編』（日本エディタースクール出版部）

続きを読む

Webアプリケーションのアンチパターン

Web

　業務で、Webアプリケーション（.NET化以前のaspとそれに連携するVB6.0という化石）を弄る日々だが、不幸なことにそれらはアンチパターンの集積である。今日は筆者が今まで見てきたWebアプリケーションのアンチパターンについて列挙したい。

モノシリックなファイル、関数

　引数取得、制御、DBクエリの発行と取得、データ加工、HTML出力まで全部が一つのファイル（もしくは関数）に詰め込まれたもの。所謂MVCパターンで言うところのコントローラ、モデル、ビューが渾然一体となったものか。見栄え、制御、処理が一箇所に記述されているわけだから、改修をするときにどこを改修すべきなのかが判別できない。
　もちろん、極めて小さなWebアプリケーションであれば、分割せず一つにしたほうがいいかもしれない。
　

不明瞭なレイヤー分割

　長くなったコードを適当に分割するとこれに陥りやすい。上記と同様に改修時に地獄を見る。
　

データベースクエリの乱発

　データベース廻りは注意深く設計しても、改修を重ねるうちに混沌としやすい。フレームワークなるハイカラなものを利用すれば結構抽象化できるが、そうでない環境で何も考えずにデータベースクエリを乱発すると、当然見通しが悪くなる。データベースから取るべきデータ項目や取得条件が変ったら、該当する箇所を全て洗い出して修正する必要が出てくる。
　筆者がいじっている化石は、機能モジュールごとにそれが使用するDBアクセス関数（実体はクエリのベタ書き）を集めたファイルが十数個もあるので、状況は上記と似た様なもの。むしろ、もっとひどい。当然、誰もDB周りを把握できていない。

参考：DAOの悪夢

引数が多すぎる関数

　引数がたくさんある関数は使用する側にとっては相当面倒な代物。その様な関数がたくさんあると……。十個以上の引数の並び順や型なんぞ誰も覚えられない。さらに関数ごとに引数の並び順に規則がない場合、ますます大変なことになる。

長すぎるGetパラメータ

　RFC上*1、Getパラメータに限度はないそうだが、ブラウザで制限を設けていることもある。現にInternet Explorerは約2000字が限度だ*2。何でもかんでもGetパラメータに渡してしまって制限長を超えると、データ送信は不完全になる。
　

ファイル名をパラメータとして渡す

　パラメータ名をそのままファイル名として開く処理があると特に危険である。情報漏洩の原因になりやすい。全く対策をしていなければ、ディレクトリトラバーサル攻撃も可能。

グローバル変数の多用

　説明不要だろう。オブジェクト指向でいうところのstaticおじさん。そもそも、グローバル変数を多用するおじさんがstaticおじさんに変貌したわけだが。

ファイルのロック処理がない

　Webアプリケーションというのは複数人で利用されるものである。複数人が共有するファイルを読み書きするときにロックは必ず掛けること。

URLエンコード（あるいはデコード）をしない

　日本語が入力されないから不要？　空白や特殊記号類もURLエンコードの対象である。特殊文字が入ったデータをエンコードせずにURLクエリとして渡すと、データの取得が思った様にできなくなる。
　

特殊文字処理をしない

　論外。外部公開されるシステムであると、コマンドインジェクション、SQLインジェクションの練習場になってしまう。フレームワークに特殊文字処理が組み込まれているのであれば、それに任せる方向が無難。いちいち自前で書いていたら漏れが起きる。
　
　大体、このようなものだろうか。実装上のアンチパターンの一部は放置するとセキュリティ上の重大な危機を招きうる。設計上のものは後々の改修時で大変なことになる。Webアプリケーションを作った結果、上記の様な状態になってしまったら、設計なり実装なりを見直そう。

参考リンク

webアプリケーションの常識集
コーディングのアンチパターンを自分なりにまとめてみた
SQLアンチパターン

*1:HTTP/1.1 RFC2616の3.2.1 General Syntaxを参照

*2:Internet Explorer では URL に最大 2,083 文字が使用可能

Perlで配列の重複要素の取出しと削除

Perl

　Perlにおける配列値の重複や削除といった操作をするにはgrep関数を利用すれば良いけれども、書いては忘れ調べ直しを繰り返している。いい加減覚えるために、メモ書きとして以下に残す。

　ある配列の重複する要素を排除するには以下の様に書く。

my %tmp;
my @uniq = grep { $tmp{$_}++ < 1; } (@array);

　逆に配列の重複した要素だけを取り出すには、grep関数を二回通す。

my (%tmp, %tmp2);
my @not_uniq = grep { $tmp2{$_}++ < 1; } (grep { $tmp{$_}++ >= 1; } (@array));

　foreachを利用しても上記処理が実現できるけれども、grepを使ったほうが簡潔に記述できる。

参考リンク

原稿で字下げ？　InDesignで字下げ？

InDesign 組版

　以前のエントリ（InDesignの文字組アキ量と行頭における始め括弧類の組方 - 無銘書房）に関連して、InDesignの行頭における始め括弧類の組方について。
　行頭における始め括弧類の組方は三種類ある。「段落行頭／折返行頭」の二種類の行頭に分けて考えると、具体的には

  1. 小説に多い「二分下げ／ベタ」
  2. 一般書籍に多い「全角下げ／ベタ」
  3. 新聞や雑誌に多い「全角二分下げ／二分下げ」

がある。
　これらの組方を実現するには、

  1. 原稿段階で段落行頭に「全角スペース」を挿入して段落字下げをする
  2. 原稿段階では全角スペースを入れず、InDesignの文字組アキ量設定で全て調整する

の二通りが考えられる。（1）の原稿例を示すと、

□これが本文。
□「括弧類で括られた文章」

の様になる（□は全角スペース）。一方として、（2）の例を示すと、

これが本文。
「括弧類で括られた文章」

の様になり、段落冒頭であっても全角スペースはない。
　つまり、二通りの入力が想定されて、三通りの中から何れかの組方をしたい。このためにInDesignをどう設定すればいいのだろうか？

続きを読む