Upon Opening Hierarchy を読む

Posted on December 15th, 2014

FileMaker のソリューションを作るときに、それぞれ自分なりの Standard な作法(流儀)を持っている。
それぞれに独特の好みがあり、「どんだけ○○やねん!w」と首を傾げることがないではないが、カシコの開発者の流儀を読むことは、中級レベルの開発者にとって、もう一つ上のレベルへのスキルアップへの早道だと思う。

同様のことを自分で実現している方法や、同様のことを別々の開発者がどうやっているのか…など比較して、どういう条件であれば有用なのか、どういう場面ではかえって意味が無いのか…を考えることはためになると同時になにより楽しい。

命名規則(Name Convention)やスクリプトの使い方、もちろん、データベース構造にも、個々の開発者の流儀が出てくるわけだが、まずは、スクリプトを見ていくことにする。

ということで…本稿では、Seed Code の SeedCode SQL Explorer を例にとって、SeedCode というか… Jason Young というか…の 作法を学んでいこうと思う。
ファイルは、FMGateway のサイトからダウンロードできる。

まず、最初にファイルを開くと走るのが、Upon Opening Hierarchy というスクリプトだ。
※ 先に FileMaker Pro Advanced を立ち上げて、デバッガをオンにしてからファイルを開く

Upon Opening Hierarchy



SeedCode SQL Explorer: Housekeeping: Upon Opening Hierarchy
#
#==============================================
# Function: Startup script for file
# Parameters: none
# Notes: This script runs when the hierarchy starts up and should be called as the opening script in file options.
# Author: SeedCode
# Version: 1.0
#==============================================
#   、
#Set File Name
変数を設定 [ $$sc_HierarchyFileName; 値:Get ( ファイル名 ) ]
#
#Clear Global Values
スクリプト実行 [ 「ClearGlobals」 ]
#
#Make sure Virtual List records are there.
スクリプト実行 [ 「Create Rows」 ]
#
#Create Array of color codes used for color coding tables and their fields.
変数を設定 [ $$sc_ColorList;
値:"6802379¶11068584¶16636347¶16628667¶13358314¶16774105¶14416052¶13411788¶16770466¶129018 59¶6802379¶11068584¶16636347¶16628667¶13358314¶16774105¶14416052¶13411788¶16770466¶12901 859" ]
#
#Go To Home layout.
レイアウト切り替え [ 「Queries」 (SQLWizardHome) ]
スクリプト実行 [ 「Adjust_Window { HideStatusArea ; Lock }」; 引数: "HideStatusArea = 0" ]
#

順に見ていこう。

#Set File Name
変数を設定 [ $$sc_HierarchyFileName; 値:Get ( ファイル名 ) ]

どうやら、$$sc_HierarchyFileName というグローバル変数に 開いたファイルのファイル名を入れているようだ。

#Clear Global Values
スクリプト実行 [ 「ClearGlobals」 ]

ClearGlobals というサブスクリプトを実行している。
名前からして、グローバルな何かをクリアするのだろう。グローバルといってすぐに思い出すのは、グローバルフィールド・グローバル変数だが、たぶんグローバルフィールドではなかろうか。

ClearGlobals



SeedCode SQL Explorer: General: ClearGlobals
#
#==============================================
# Function: Utility script for clearing virtual list arrays and the global fields that set the number of rows to show in the respective portals.
# Parameters: none
# Notes:
# Author: SeedCode
# Version: 1.0
#==============================================
#
フィールド設定 [ SQLWizardHome::HierarchyGlob; "" ]
フィールド設定 [ SQLWizardHome::RowsToDisplay1; "" ]
フィールド設定 [ SQLWizardHome::RowsToDisplay2; "" ]
変数を設定 [ $$sc_Display[2]; 値:"" ]
変数を設定 [ $$sc_Display; 値:"" ]


あに図らんや、
  • SQLWizardHome::HierarchyGlob
  • SQLWizardHome::RowsToDisplay1
  • SQLWizardHome::RowsToDisplay2
というグローバルフィールドの他に、
  • $$sc_Display
というグローバル変数の繰り返し番号1と2についてもクリアしている。

グローバル変数はファイル依存なので、ファイルを開くときにキックされるスクリプトのサブスクリプトとして、「グローバル変数をクリアする」というのは釈然としないが、使い回す価値があるからサブスクリプトにしているのだろうから、他のスクリプトから呼び出される場面も考えられているからなのね。

また、(変数に複数の値を入れたい場合、改行区切りで入れることが多いが)このように変数にわざわざ繰り返しを設定しているところをみると、値自体に改行を持つものが入るのかなーと。
よくよく見ると、Function(機能)の説明に、
Utility script for clearing virtual list arrays and the global fields that set the number of rows to show in the respective portals.
とある。
なるほど、Virtual List の配列の元とするグローバル変数 をクリアしたいのね。だから、繰り返しなんだ。
VL のクリアが目的なら、たしかに、(ファイルを開いたときだけでなく)ファイルを開いた後の操作中にも、同じ VL を別用途で使う前にも、その前に使っていた VL をクリアするときにも使うものね。

さて、Upon Opening Hierarchy に戻ると、今度は、Create Rows というサブスクリプトに飛ばされる。

#Make sure Virtual List records are there.
スクリプト実行 [ 「Create Rows」 ]

Create Rows


SeedCode SQL Explorer: Housekeeping: Create Rows
#
#==============================================
# Function: Part of start-up routine to make sure virtual list display rows are populated to the specified number.
# Parameters:
# Notes:
# Author: SeedCode
# Version: 1.0
#==============================================
#
#Default Number Row Records
変数を設定 [ $sc_NumberRows; 値:1000 ]
フィールド設定 [ SQLWizardRows1::DragDrop1; " " ]
#
ウインドウの固定
#
レイアウト切り替え [ 「dev_Rows」 (SQLWizardRows1) ]
全レコードを表示
If [ Get ( 対象レコード数 ) = $sc_NumberRows ]
レイアウト切り替え [ 元のレイアウト ]
現在のスクリプト終了 [ 結果: "" ]
End If
#
対象レコード削除[ ダイアログなし ]
変数を設定 [ $sc_c; 値:1 ]
Loop
新規レコード/検索条件
フィールド設定 [ SQLWizardRows1::RowNumber ]
変数を設定 [ $sc_c; 値:$sc_c + 1 ]
Exit Loop If [ $sc_c > $sc_NumberRows ]
End Loop
#
レイアウト切り替え [ 元のレイアウト ]
現在のスクリプト終了 [ 結果: "" ]

さて、Function(機能)の説明にこうある。
# Function: Part of start-up routine to make sure virtual list display rows are populated to the specified number.
「スタートアップルーチンの一部として、Virtual List を表示するための row を特定の数、確実に生成しておく」
のが目的らしい。

#Default Number Row Records
変数を設定 [ $sc_NumberRows; 値:1000 ]
フィールド設定 [ SQLWizardRows1::DragDrop1; " " ]
#
ウインドウの固定
#
レイアウト切り替え [ 「dev_Rows」 (SQLWizardRows1) ]

VL用のレコードを、予めいくつ作っておくのかという数字が、$sc_NumberRows にセットされた 1000 ちうことね。
SQLWizardRows1::DragDrop1 というフィールドに、半角スペースをセット。
これ何でしょう?現時点ではわかりません。

SQLWizardRows1 という TO がコンテキストであるレイアウト「dev_Rows」に移動。
そのまえに、ウインドウの固定が入れて、余計な画面遷移を出したくないのね。

全レコードを表示
If [ Get ( 対象レコード数 ) = $sc_NumberRows ]
レイアウト切り替え [ 元のレイアウト ]
現在のスクリプト終了 [ 結果: "" ]
End If

TO「SQLWizardRows1」のすべてのレコードを表示した後の条件が…
Get ( 対象レコード数 ) = $sc_NumberRows
$sc_NumberRows は、さっき 1000 をセットした。
SQLWizardRows1というTOのレコードも現在 1000 なので、この条件式は真。
真だと、元のレイアウトに戻ってスクリプト終了。

なるほど、SQLWizardRows1 ってのが VL のテーブルなのね。
そこに、予め 1000 のレコードを作っておくためのスクリプトだもんね。
ちうことは、現在の VL のレコード数が1000 レコードじゃない場合の処理が次に来るわけね。

対象レコード削除[ ダイアログなし ]
変数を設定 [ $sc_c; 値:1 ]
Loop
新規レコード/検索条件
フィールド設定 [ SQLWizardRows1::RowNumber ]
変数を設定 [ $sc_c; 値:$sc_c + 1 ]
Exit Loop If [ $sc_c > $sc_NumberRows ]
End Loop
#
レイアウト切り替え [ 元のレイアウト ]
現在のスクリプト終了 [ 結果: "" ]

やっぱり。
全レコード削除して、$sc_c ちうカウンタを上げながら、新規レコードを $sc_NumberRows の数(1000)作るっちうことね。

んで、また、最初の Upon Opening Hierarchy に戻る。

#Create Array of color codes used for color coding tables and their fields.
変数を設定 [ $$sc_ColorList;
値:"6802379¶11068584¶16636347¶16628667¶13358314¶16774105¶14416052¶13411788¶16770466¶129018 59¶6802379¶11068584¶16636347¶16628667¶13358314¶16774105¶14416052¶13411788¶16770466¶12901 859" ]
#
#Go To Home layout.
レイアウト切り替え [ 「Queries」 (SQLWizardHome) ]

テーブルやフィールドの文字列用のカラーコーディングに使うカラーコードの配列を作るわけですね。
そして、このファイルのホームレイアウトである SQLWizardHome へ。

スクリプト実行 [ 「Adjust_Window { HideStatusArea ; Lock }」; 引数: "HideStatusArea = 0" ]

最後に、HideStatusArea = 0 という引数で、Adjust_Window { HideStatusArea ; Lock } というスクリプトを実行。

Adjust_Window { HideStatusArea ; Lock }


SeedCode SQL Explorer: General: Adjust_Window { HideStatusArea ; Lock }
#
#==============================================
# Function: Utility script for adjusting current window (to fit)
# Parameters: Hide Status Area ( Yes or No ) ; Lock
# Notes:
# Author: SeedCode
# Version: 1.0
#==============================================
#
#
#Evaluate Patameters
スクリプト実行 [ 「Parameters to Local Variables」; 引数: Get ( スクリプト引数 ) ]
変数を設定 [ $parameters; 値:Evaluate ( Get ( スクリプトの結果 ) ) ]
#
#Hide and Lock if specified with parameters.
If [ $sc_HideStatusArea = "Yes" ]
If [ $sc_Lock ]
ツールバーの表示切り替え[ ロック; 隠す ]
Else
ツールバーの表示切り替え[ 隠す ]
End If
Else If [ $sc_HideStatusArea = 0 ]
ツールバーの表示切り替え[ 表示する ]
End If
#
#Adjust window
ウインドウの調整[ 収まるようにサイズ変更 ]
#

カレントウインドウを調整するスクリプトね。

はじまってすぐにParameters to Local Variables というスクリプトに飛ばされる。
コメントに “Evaluate Parameters" とあるから、スクリプト「Adjust_Window { HideStatusArea ; Lock }」に渡されたスクリプト引数( “HideStatusArea = 0" )を Evaluate するスクリプトに飛ばされるわけね。

Parameters to Local Variables


SeedCode SQL Explorer: General: Parameters to Local Variables
#
#==============================================
# Function: Neat little utility to transform script parameters into local variables of the same names.
# Parameters: The script parameter you wish to transform, sent as Get ( ScriptParameter )
# Notes: After calling this script, call the following in your script to instantiate the variables:
: SerVariable [$parameters ; Value:Evaluate ( Get ( ScriptResult ) )]
: Note that this script namespaces your variables with $sc_
: Script parameters sent in here must follow the format: name = value ; name2 = value 2 with even spaces around =s and ;s.
# Author: SeedCode
# Version: 5.23.1
#==============================================
#
#> > make semicolon = safe?
#
If [ IsEmpty ( Get ( スクリプト引数 ) ) ]
変数を設定 [ $parameters; 値:"empty" ]
Else
変数を設定 [ $parameters; 値:
Let ( [
n = Substitute ( Get ( スクリプト引数 ) ; "¶" ; "\¶" ); prefix = "$sc_" ;
e = PatternCount ( n ; " = " ) = 0 ;
string = Substitute ( n ;
[ " ; " ; "\" ; " & prefix ] ;
[ " = " ; " = \"" ] )
];
"Let ( [ " & prefix & string & "\" ] ; \"\" )"
)]
End If
現在のスクリプト終了 [ 結果: $parameters ]
#

なにやら楽しそうだぞ!

「スクリプト引数を、同名のローカル変数に変身させる」だと。
Note を見ると…
このスクリプトをコールした後で、あんたのスクリプト内で、変数のインスタンス生成するために以下をコールしなさいな…と。

変数を設定 [ $parameters; Value:Evaluate ( Get ( ScriptResult ) ) ]

Get ( ScriptResult ) を Evaluate したものを $parameters という変数にセット…ね。
$sc_ ってのを(頭につけて)、名前空間とする(ローカル変数名のネームコンフリクトをさける)
このスクリプトに送られるスクリプト引数は以下の形でなければならない。
name = value ; name2 = value 2( = や ; の前後がスペースでも)

にゃるほど。

#> > make semicolon = safe?
#
If [ IsEmpty ( Get ( スクリプト引数 ) ) ]
変数を設定 [ $parameters; 値:"empty" ]
Else
変数を設定 [ $parameters; 値:
Let ( [
n = Substitute ( Get ( スクリプト引数 ) ; "¶" ; "\¶" );
prefix = "$sc_" ;
e = PatternCount ( n ; " = " ) = 0 ;
string = Substitute ( n ;
[ " ; " ; "\" ; " & prefix ] ;
[ " = " ; " = \"" ] )
];
"Let ( [ " & prefix & string & "\" ] ; \"\" )"
)]
End If

セミコロンが安全かどうか?
スクリプト引数が空値の場合、$parameters には、"empty" というテキストをセットする。
スクリプト引数になにがしかの文字が入っていれば、$parameters に以下の式の結果をセットする。

Let 式の内部を確認していく。
(仮に、スクリプト引数が "hoge = ほげ¶ほげ ; nan = なんちゃら" だったとき)
n は…

hoge = ほげ¶ほげ ; nan = なんちゃら

あれ?一緒じゃん…と思うなかれ。
じっさいには、スクリプト引数は…

hoge = ほげ
ほげ ; nan = なんちゃら

なのである。このスクリプト引数内の¶をいったんエスケープして、Value(xxx = yyy ; xxx2 = yyy2 のようなときの、yyy や yyy2 にあたる部分)自体が改行を含む場合も破綻しないように、後に続く式内でも使えるようにしているわけだ。

e は、n に “=“ が無ければ 1(True)…ということだから、0(False)。

string の結果は…

hoge = "ほげ¶ほげ" ; $sc_nan = "なんちゃら

$sc_ という文字が片方(後方)にのみついていて、後方のダブルクォーテーションも欠けているが、この後、
"Let ( [ " & prefix & string & "\" ] ; \"\" )"
と整形してやると…

Let ( [ $sc_hoge = "ほげ¶ほげ" ; $sc_nan = "なんちゃら" ] ; "" )

という Let から始まる Let計算式 が生成される。

現在のスクリプト終了 [ 結果: $parameters ]

このスクリプトが終わって、このスクリプトをコールしたスクリプトに戻ったときに、Get ( ScriptResult ) で呼び出せるように、スクリプトの結果に $parameters を入れて終了。

そして、Adjust_Window { HideStatusArea ; Lock } に戻ってくる。

変数を設定 [ $parameters; 値:Evaluate ( Get ( スクリプトの結果 ) ) ]

Get ( ScriptResult ) を Evaluate したものを、$parameters にセット…と見えるが、結果をデータビューアで見ても、$parameters という変数は存在しない。
直前にコールされた Parameters to Local Variables の説明にもあったように、Parameters to Local Variables というスクリプトでは Let で始まる『式テキスト』を生成する。
Parameters to Local Variables が終わると、Get ( ScriptResult ) として、Adjust_Window { HideStatusArea ; Lock } 内で使用するローカル変数を作成する。

通常、変数をセットするには、スクリプトステップ「変数を設定」でシンプルに使いたい変数名をセットする。
しかし、ここでは、変数を設定スクリプトステップで、$parameters という変数を設定する…フリをしながら、実際には…

Get ( ScriptResult ) …つまり、Let ( [ $sc_HideStatusArea = "0" ] ; "" ) という式を Evaluate することで、
$sc_HideStatusArea という変数 に 0 を設定している。

この Let ( [ $sc_HideStatusArea = "0" ] ; "" ) というテキストは、直前のスクリプトステップでコールした外部スクリプト「Parameters to Local Variables」によって生成された。
そして、Parameters to Local Variables の実行時に予め渡された

HideStatusArea = 0

というスクリプト引数が元になっているが、その元を辿ってみよう。
遡ると、このテキストは、大元のスクリプト「Upon Opening Hierarchy」によって、Adjust_Window { HideStatusArea ; Lock } にスクリプト引数として渡されたものなのだ。

大元の Upon Opening Hierarchy スクリプト内で、ウインドウの調整をさせるスクリプト「Adjust_Window { HideStatusArea ; Lock }」を呼び出す際に、スクリプト引数で、HideStatusArea = 0 と渡せば、「ステータスエリアを隠さない」というオプションを指定して実行することができる。
よく見れば、スクリプト名「Adjust_Window { HideStatusArea ; Lock }」は、Adjust_Windows というスクリプトの内容を表すテキストの後に中括弧で括られて、{ HideStatusArea ; Lock } とある。
ウインドウの調整をさせるスクリプトに「ステータスエリアは隠すの/隠さないの?」「ロックするの?/しないの?」というふたつのオプションが指定可能である…ということが、スクリプト名を見ればわかるようになっている!

Upon Opening Hierarchy では、ステータスエリアの表示について「隠す」というオプションを指定しているだけだが、別のスクリプトから呼ばれたときに、「ウインドウをロックする」というオプションを指定することも、もちろん可能だ。

HideStatusArea = 0 ; Lock = 1

をスクリプト引数に入れて、Adjust_Window { HideStatusArea ; Lock } に渡せば、Adjust_Window { HideStatusArea ; Lock } は、まず、今 Upon Opening Hierarchy からもらったばかりのスクリプト引数と共に、Parameters to Local Variables をコールする。
Parameters to Local Variables は結果、

Let ( [ $sc_HideStatusArea = "0" ; $sc_Lock = "1" ] ; "" )

という計算式を生成し、Adjust_Window { HideStatusArea ; Lock } に、Get ( ScriptResult ) として返す。
Adjust_Window { HideStatusArea ; Lock } は、それを、 変数を設定スクリプトステップを使って、$parameters をセットするのだが、
その計算式で、Let ( [ $sc_HideStatusArea = "0" ; $sc_Lock = "1" ] ; "" ) を Evaluate することで結果として…

  • $sc_HideStatusArea という変数が 0、
  • $sc_Lock という変数が 1で、セットされる。

Dictionary関数と比べてみる

Dictionary関数 と呼んでいる 連想配列を作る関数群をよく使うが、Dictionary関数に頼らずとも、Parameters to Local Variables という汎用の D.R.Y. なスクリプトに、Label1 = Value1 ; Label2 = Value2 というスクリプト引数を投げてやることで、同様のことを実行しているわけか…どう違うのか…。

Dictionary関数使用の場合

投げるスクリプト引数は…

SetProperty ( "Label1" ; Value1 ) & SetProperty ( "Label2" ; Value2 )

結果を引き出すときは…

変数を設定 [ $Label1; 値:GetProperty ( Get ( ScriptResult ) ; "Label1" )]
変数を設定 [ $Label2; 値:GetProperty ( Get ( ScriptResult ) ; "Label2" )]


…もしくは、
GetScriptResult ( "Label" ) := GetProperty ( Get ( ScriptResult ) ; "Label" ) をカスタム関数に追加登録して、

変数を設定 [ $Label1; 値:GetScriptResult ( "Label1" )]
変数を設定 [ $Label2; 値:GetScriptResult ( "Label2" )]

Parameters to Local Variables でLet計算式を生成して、あとでEvaluateという手法なら…

投げるスクリプト引数は…

"Label1 = Value1 ; Label2 = Value2"
まあ、こっちの方が読みやすいっちゃ読みやすいね。

結果を引き出して使うときは…複数の変数を設定するにも一挙に1ステップ

変数を設定 [ $parameters; 値; Evaluate ( Get ( ScriptResult ) )

Evaluate はコスト高だし、予期せぬ動きにならないとも限らないという面もなきにしもあらず。
なので、これだけならさして違いはないというか、どっちでも、お好きな方で…なのだが、

以下のような条件の場面では、「Let計算式を作って Evaluate する」という SeedCode 方式がすこぶる便利だろう。

  • 変数名もスクリプト引数で渡すLabel名も同じでOKの場合
  • やたらと膨大な変数を一気に100とか登録したい場合
  • 変数名は Label1、Label2… のように Loop で作りたい…という場合

変数名もスクリプト引数で渡すLabel名も同じでOKの場合

まず、スクリプト引数を作る段階ですでに、後で使うときの変数名は、自動的にスクリプト引数のラベル名になるように作るので、変数を作る際に、変数名を「なんだっけかな?」と悩む必要が無い。
※ スクリプトごとに、スクリプト引数内で使うラベル名をスクリプト名の命名規則(中括弧で括り、デリミタはセミコロンとか)にすれば「このスクリプトをコールするときどんなスクリプト引数つけるんだっけ?」というのがわかりやすくなる。

やたらと膨大な変数を一気に100とか登録したい場合

個人的には、スクリプト引数で指定するときの式は、さほど変わらないように思うが、Get ( ScriptResult ) を使って、山ほどの変数をセットするときには、Evaluate 一発で設定できた方がどう考えても楽チン。

変数名は Label1、Label2… のように Loop で作りたい…という場合

Loop で回して…(Virtual List を使うとき、VLの元となる変数を作成する場合など、ラベル名は、特定の文字列に続けて繰り返し番号だけをインクリメントしたいとかは「あるある」な話)という場合、「スクリプト引数を作る」ためだけのスクリプトが明らかに著しく作りやすい。

さて、残りをやっつけるか…w

#Hide and Lock if specified with parameters.
If [ $sc_HideStatusArea = "Yes" ]
If [ $sc_Lock ]
ツールバーの表示切り替え[ ロック; 隠す ]
Else
ツールバーの表示切り替え[ 隠す ]
End If
Else If [ $sc_HideStatusArea = 0 ]
ツールバーの表示切り替え[ 表示する ]
End If
#
#Adjust window
ウインドウの調整[ 収まるようにサイズ変更 ]

思った通りなので、何も言うことはない。










Amazon Route 53 で Postach.io のカスタムドメインを設定

Posted on November 5th, 2014

Facebook に書いたように

"DNS は Amazon Route53 で無問題かちら?
自分用/顧問先用含め、そこいらにとっちらかって使っているホスティング/レンタルサーバを、可用性、機密性、完全性、コストパフォーマンス、共に優秀などこかのクラウド上に集約すっぺかな…と考え中。まずは、DNS から…。"
…てなことで、Route53 を使ってみた。

ま、Amazon Route53 を知らない人も数字を見て明らかなように、DNS サービスだす。

せっかくなので、意味のある実験をすべぇと…
Postach.io (※)内の自分ちのブログ別館を、つい登録した mylog.jp で開けるように設定してみる。

Postach.io
Evernote で、 “postach.io" というノートブックにあって、"published" というタグが付いているエントリの内容をそのままBlog のように公開してしまうちう便利なサービス ※ 最近、有料コースも出てきた。$50/年で SSL / マルチユーザー / マルチブログ なのが有料コースのベネフィット



Postach.io でやること

1. Postach.io にログインして、対象のサイト名横の鉛筆マークをクリック

2. 使いたいドメイン名を入力し UPDATE SITE DETAILS をクリック
※ Learn how to configure custom domains をクリックした先のページ(下図)で、Postach.io サイトのIPアドレスが表示されるので、メモしておく。

3. これを Route 53 で作成する Aレコードの Value に指定するべくメモしておく。



Amazon Route 53 でやること

1. Route 53 をクリック



2. DNS Magagement の Get Started Now をクリック


3. Create Hosted Zone をクリック



4. Create Hosted Zone をクリック


5. Doman Name に使用するドメインを、Comment に適切なコメントをそれぞれ入力し、Create ボタンをクリック


6. Go to Record Sets をクリック


7. Create Record Set をクリック


8. Value に対象のドメイン名(ネイキッドドメイン)で飛ばしたい先の IPアドレス(『Postach.io でやること』でメモしておいた IPアドレス)を入れて、Create をクリック。



お名前.COM でやること



1. 表から、対象の [ドメイン] の [ネームサーバー] > [変更する]



2. [他のネームサーバーを使用] タブ > [ネームサーバー情報を入力] 欄に、Amazon Route53 のNSのValue欄の IPアドレス群をプライマリネームサーバー(セカンダリネームサーバー)にそれぞれ入力し、[確認画面へ進む] をクリック
※ このとき、末尾に ".(ピリオド)" が入っていないことを確認します。
※ Amazon Route 53 からコピーしたときに、DNSレコードの内容からコピーした場合、ピリオドが入っている場合があります。



3. [設定する] をクリック



完了

FileMaker の計算式を見やすく変換(Formatting Calculations In Place )

Posted on March 13th, 2014

TextMate 用の FileMaker.tmbundle の GitHubリポジトリの中で、なかなか便利なツールを発見。

Formatting Calculations In Place :記事FileMaker の計算式ダイアログで、適当に書き殴った計算式の体裁を整えてくれるツール。

使い方

↓こんな計算式を選択して、
ショートカットキーコンビネーションで、

↑こんな感じに、Tidy してくれる。

仕込み方

Formatting Calculations In Place で、Format_Calc.zip をダウンロード。
解凍してできる
Format_Calc/Service/FileMaker: Format Calc.service
$HOME/Library/Services/FileMaker:\ Format\ Calc.service
に入れて、念のため、システム環境設定 > キーボード > キーボードショートカット > サービスから
FileMaker: Format Calc に適当にショートカットを与える。
TextMate の FileMaker.tmbundle における Tidy と同様の動き。
# 同じpearlスクリプト(tidy.pl)使ってるんだから、そらそーだ。w

Mavericks Server 環境構築 01(TextMate と FileMaker .tmbundle)

Posted on March 13th, 2014

川井さんちからやってきた Mac mini 2011、XCode と OS X Server 3(Mac OS X Server Mavericks)のインスコだけは済んだ。
ついでに、アンインストール時に関連ファイルを捨ててくれる、AppCleaner (Donation Ware) 、自動実行ユーティリティ Hazel も入れた。
※ Hazel は、設定によって、アプリケーションをゴミ箱に捨てる動作を感知して、AppCleaner で感知しない関連ファイルも捨ててくれる(機能がある)が、過敏すぎる傾向があるので、都度チェックが必要。

さて、何はともあれ、エディタである。

TextMate 2 のダウンロードとインストール

Mac OS X のエディタでのオススメと言えば、やはり、TextMate。
(単なるエディタというより、Code Project Manager)
ずっと、日本語の問題で気持ち悪かった TextMate だけれど、2012年に オープンソース化されて、alpha版とは言え、TextMate 2 では日本語が問題なく使える。
前回 Mac Pro に入れたときには、パッケージ版がなかった(探せなかった?)ので、ソースからビルドしたのだけれど、どうやら、パッケージdmg がダウンロードできるらしい。
色々調べたら、Macromates のダウンロードページのものが最新(2.0-alpha.9515)みたい(2014/03/13 14:48:46)

TextMate 2.0 alpha Mac OS X 10.7 (i386)


FileMaker tmbundle のダウンロードとインストール

次に、Text Mate で FileMaker を使うときに便利な FileMaker.tmbundle をダウンロードする

GitHub の FileMaker.tmbundle ページから、zipファイルをダウンロード。


解凍して、"FileMaker.tmbundle-master"フォルダを "FileMaker.tmbundle" にリネームする。

FileMaker.tmbundle をダブルクリックすると、「FileMaker bundle インスコすんの?」と訊かれるのでインスコ。


FileMaker.tmbundle がインストールされるパス(細かい話なので読み流してもOK)

以前は、
$HOME/Library/Application\ Support/TextMate/Bundles
に入ってたと思うのだけれど、見当たらない。探してみると…
$HOME/Library/Application\ Support/Avian/Pristine\ Copy/Bundles
にあった。このあたりの情報は Webにないものかと探すと…
にあった。曰く…

Bundles フォルダは4箇所あって…公式のBundles は、GitHub のレポジトリから自動アップデートされて、
$HOME/Library/Application\ Support/TextMate/Managed/Bundle
にインストールされ、サードパーティの Bundles は、
$HOME/Library/Application\ Support/Avian/Pristine\ Copy/Bundles
にインストールされ、
$HOME/Library/Application\ Support/Avian/Bundles
は、公式やサードパーティの Bundles をカスタマイズした差分や自作の Bundles の場所だとのこと。

Syntax Color Highlighting 以外の機能

これでとりあえず、Syntax Color Highlighting などいくつかの機能は問題なく効くが、他のいくつかの機能については(環境によって)問題がある。
これはおそらく、TextMate1 の Bundles なので、TextMate 2 との Bundles の(Plugins 部分の)コンパチビリティの問題だと思う。
…ということで、現在調査中。←イマココ(2014/03/13 17:38:50)






自己愛こそがすべてだとしたら…それも悪くない

Posted on December 16th, 2013

天才とはなにか?一知半解が露わになるのを怖れずに言うなら、なんだか知らんが小さな努力で大きな結果を得ることのできる脳みそを持つ人間のことだ。反論は許さない…というよりむしろ反論はナンセンスだ。錆び付いただけのネジなら頭を叩けば回せもするが、私のネジは錆びのみでできている。槌で叩けば砂塵に帰す。
そもそも、凡人サンプルとも言うべき、「絵に描いた凡人」たる私が言うことである。反証して頂いたところで、それをそれと解するほどの脳みそが私にはない。
したがって、黙ってこの先を読み進めるか、さっさと読み飛ばすかどちらかにして欲しい。

脳みそ…入力された情報群を処理して、出力として異なる(進化した/退行した)答えを出すための、入力と出力の間に位置する処理機関である。(ここで「スケトウダラの白子のような…あのブツ…を指しているのではなく、概念としての脳みその話だ」…などと冗長に言いたがるのも、私の脳みそが凡庸な証左である)

偶さかみつけた少しの知識の切れ端を、己が発明発見に取り違えて、ご機嫌にスキップを披露するほどの脳天気。
果ては、その『偶さか』を『必然必至なルールに基づいた自らの能力の証』であるかのような妄想的自己愛に囚われて信じ込む。

自己愛…自分を愛さずに誰を愛せるというのだ…わかったように聞こえる物言いで、端(はな)からシニカルなニヒリストを気取り言を続けよう。

「人は自分を愛すること」のみをエネルギーの源として生きていく生き物である。

女性が言う「優しい人が好き」の『優しい人』とは「自分を認めてくれる人」である。
我が子ができて子供嫌いが直った気になる勘違いも、その小猿のようなシワクチャの顔に、自分を見つけるからである。

自分を愛することそれ自体をどうこう言いたいのではない。自分を愛する故に自らの中に自然発生的に最初に湧き起こる「自己愛の力学」に知らんフリして、なんとなくのボンヤリした思い込みを、髪の毛一本の疑いもなく信じ込むというのは恥ずかしくはないのか…と言っているのである。

床の間の掛け軸に書いた未来永劫変わることのない宇宙の真理のように思っている君の中のその真実が、自己愛で汚れているとしたら震えないか?

もし君が嫌煙論者なのであれば、自分を疑ってみて欲しい。タバコが身体に良くないことが真実でも、愛煙家が悪なのではない。
もし君が愛煙家なのであれば、自分を疑ってみて欲しい。君は、タバコを愛しているのではなく、タバコを吸うときの安らかなあのひとときの自分が好きなだけなのだ。自分や他人の健康よりも。

自己愛の他所に、なにかルールや真理めいた美しい法則が原始の掟のように先に在って、世の中はすべてその法則に従って回っていると決めつけていないだろうか。真ん中にあるその法則は見つけ出せる類の真実であり、人は古来ずっと、その真実の周りで湖畔を周回するミツバチのようにグルグル回っているが、いずれその法則はだれかが必ず見つけ出せるのだと…そんな妄想に皆で囚われていないだろうか。

全ての尺度の基本となり、それさえ知れば、善悪・優劣・老若・男女・高低・軽重…すべての判断が可能になる…そんな『メートル原器』のような普遍的真実…それが何かはわからないけれど、それがあることだけは誰もが信じている…そんな気になってはいるが、よくよく考えてもみたまえ。だれかとその存在を確認し合ったことがあるのか?
まるで、見てもいないものを見てきたかのように終生「あの世」の話をしながらあの世に行ったGメンの親分の話のように滑稽だ。

締め付け固定工具のような名前の大阪の女流マンガ家集団の作品の台詞で「世の中に偶然なんてないわ。あるのは必然だけ。」というのがあるが、こう仮定してみて欲しい。

実は世の中に必然なんてない。あるのは偶然だけ。
あえて言うなら、自己愛だけが、産まれた途端にそこに在るものすべてだと付け加えよう。

どうだろう。すべての強欲や無欲・あらゆる慈善と略奪…それらの一見相容れないカップルが据わりよく仲睦まじく暮らしている桃源郷が見えはしないだろうか。

Bitcasa の料金体系大幅変更!

Posted on November 21st, 2013

てーへんだ!Bitcasa がてーへんだ!料金体系が無茶苦茶変更!
(免責:以下、僕の理解が正しければ…)
僕の記憶では、従来は、年額$99程度(Dropboxのプロプランとかと同じ、業界標準金額)だった容量制限無しな有料コース(Infinite)が、$999に!


ただし!従来の Infinite つまり無制限で契約しているヒトについては、明示的に新しい料金体系に変更すると申し込まない限り、従来通りの料金で、無制限を継続!という話(Anual有料コース申し込んどいて良かった!)

※ Freeコースは、5GBスタートの友達誘うことで、20GB(25GB)まで容量アップ可能。従来と同じ金額($99/Year)だと、1TB(Premium)。真ん中の$499で5TB(Pro)。

間違ってとっているとヤバイので、一応、原文と、引用先を書いておきまする!

・新しい料金体系表
 https://www.bitcasa.com/pricing
・上述の話が書かれている Bitcasa のブログ
 http://blog.bitcasa.com/2013/11/19/our-new-pricing-and-the-evolution-of-bitcasa/

具体的に「こんなヒトはこの扱い」ちうのの記述部分
Commitment to Customers

For our existing customers here’s a breakdown of how the changes apply to you:
既存のお客さまにとって、この変更がどう適用されるかの詳細

Customers who have already signed up and paid for our Infinite plan (monthly or annual) will remain on that pricing plan.
すでに Infinite プラン(月々もしくは毎年)のサインアップをして支払いがすんでいるお客さまは、その料金プランのままとなります。

Customers on the free plan will keep their 10GB quota and can also invite friends to get an extra 15GB extra space (25GB total!).
既存のフリープランのお客さまは、10GBの割当てを維持し、お友だちを誘うことで、さらに15GB(計25GB)のボーナス容量を獲得できます。

If you’re currently a free user and wish to upgrade, you will need to choose a plan that suits your needs on the new pricing plans.
現在フリーユーザーでアップグレードなさりたいお客さまは、新料金体系プランから適したモノを選ぶ必要があります。

If you want to cancel or change your plan from monthly to annual, etc. you will need to transition to the new pricing plans.
キャンセルしたいかもしくは、月々プランから年額プランへの変更を希望するお客さまは、新料金体系への移行が必要となります。

Any new offerings, such as our upcoming Linux client, will also be on the new pricing plans.
新たな商品、たとえば、次期Linuxクライアントなどは、新料金体系プランになります。

ペースメーカーと携帯電話 in 満員電車

Posted on November 20th, 2013

★ 距離指針22cm


平成9年の協議会の指針を受けて、総務省が平成17年に策定された指針として、影響を受けない距離『22cm』が謳われた。
(この指針は医療機関、関係省庁、植込み型医療機器業界、携帯電話業界等を通じて幅広く周知されており、現在まで国内において携帯電話を含め電波利用機器による植込み型医療機器における電磁干渉問題は発生していない。 )


これは、満員電車、欧米と異なる携帯電話方式 などの日本独自の状況に鑑みての実験が元になっている。
※ 最大の影響が確認された 1.5 GHz 帯のPDC 方式(第 2 世代携帯電話方式の1 つ)を利用する国は世界において日本のみ


ただし、この実験は、所謂第2世代と呼ばれる電話と、当時の植込み型医療機器(ペースメーカーなど…と呼ばれるが、 植込み型心臓ペースメーカと、植込み型除細動器などが含まれる)との実験である。


★ 国際規格制定と第2世代携帯サービスの終了


この実験の後、欧米で植え込み型医療機器の世界標準となる規格が制定される。
この規格の中には、『電磁妨害(EMI)』に対する耐性『電磁両立性(EMC)』の基準があり、これが、6インチ(約15cm)の距離で、EMI耐性が担保されることという項目がある。(この規格に適合しないと、商品として流通できない)
日本では、すべてから欧米からの輸入に頼っている。
したがって、日本の30-40万人と言われる植え込み型医療機器装着者のほとんどが、この規格適合のものを使用している。


また、平成24年7月25日をもって、第2世代携帯のサービスは終了ということになり、第3世代以降の携帯については、(第2世代と比べて)電磁影響が小さくなっている。


以上の事実に鑑みて、EMI耐性が大きく改善した世界標準規格の適合品の植え込み型医療機器と、第3世代以降(LTEを含む)の携帯電話機 を対象にした実験を新たに(去年?or一昨年)行った。


★ 実験の結果


CDMA2000 1xEV-DO Rev. A方式の携帯電話端末実機から電波を発射した場合の影響は、植込み型心臓ペースメーカ 40 機種のうち 5 機種で発生し、総試験数に対する影響発生試験数の割合は 3.8 %であった。また、最も遠く離れた位置で影響が発生した機種の距離は 1 cm 未満であり、その影響度合いはレベル 2であった。


(レベル2 の影響:持続的な動悸、めまい等の原因になりうるが、その場から離れる等、患者自身の行動で現状を回復できるもの)


スクリーニングのための試験として、半波長ダイポールアンテナから電波を発射した場合の影響は、植込み型心臓ペースメーカ 40 機種のうち6 機種で発生し、総試験数に対する影響発生試験数の割合は 5.8 %であった。また、最も遠く離れた位置で影響が発生した機種の距離は 3 cmであり、その影響度合いはレベル 2 だった。


(電波の医療機器等への影響に関する 調査研究報告書 平成24年3月 P31-32)


最大で3cm以内に近づけなければ有意な影響は認められない…と要約できる。


★ 新しい指針策定への道


とはいえ、今後の携帯電話の新方式、周波数、および端末がどうなるかはわからないので慎重に(マージンをとって)検討すべき。(同 P39)
※ 携帯電話米国規格のANSI/AAMI PC69 の第2 版(ANSI/AAMI PC69: 2007)では電波発射源である半波長ダイポールアンテナの入力電力の値が 40 mWから120 mWに引き上げられている(同 P58)


諸外国の距離指針は総じて 15cm(6インチ)である。
従って、植え込み型医療機器を欧米からの輸入に頼る日本も距離指針を15cmにとるということは合理性がある。(同 P39)


一方、国内の植え込み型医療機器装着者は増加傾向(30-40万人と推計)(同 P58)
社会全体で装着者が安心して生活できる環境を作っていくことが求められる。(同 P42)


★ さまざまな検討案とその却下理由


「距離指針を記載しない」という検討案は…


安全側に振った試験であるとはいえ、実際に試験では影響が発生している国際規格が定める試験によって、15cm 相当の距離では携帯電話の影響を受けないことが確認されている。したがって、指針の中に距離を明記しないことは影響の防止策としては不十分…故に却下。(同 P40)


「現世代(第3世代)以降の携帯電話方式における最大干渉距離に安全マージンをとった値とする」という検討案は…


そうするには、追加実験を行い、現在の最大干渉距離を出す必要があるので却下。(同 P40)


「今までそれで問題が起きなかったという事実を評価して、従来通りの 22cm でいく」という検討案は…


22cm という距離指針の根拠になってきた携帯電話サービスが終了する中で、世界でも最も厳しい日本の距離指針を維持する根拠がみつからない。
だからやはり現状に合わせた新しい指針は必要…却下。(同 P41)


★ 結論


新たな指針の具体案では、現行指針の「近接した状態となる可能性がある場所(例:満員電車等)では」という表現を「密着した状態となる可能性がある場合(例:満員電車等)」に置きかえた。(同 P42)
(下の句は、「その携帯電話端末等の電源を切るよう配慮することが望ましい。」)


※ 『近接』が『密着』に、『場所』が『場合』にそれぞれ変化している。
つまり、満員電車であっても、「他人と(携帯が15cm以上の距離がとれないほど)密着する可能性がない場合」においては、携帯の電源を切る配慮は必要ない…と読み取れる。


携帯電話端末及び PHS端末の電波が植込み型医療機器へ及ぼす影響を防止する ための指針


     ア 植込み型医療機器の装着者は、携帯電話端末の使用及び携行に当たっては、携帯電話端末を植込み型医療機器の装着部位から 15 cm程度以上離すこと。
また、混雑した場所では付近で携帯電話端末が使用されている可能性があるため、十分に注意を払うこと。


     イ 植込み型医療機器の装着者は、PHS 端末の使用に当たっては、アの携帯電話端末と同様に取り扱うこと。
PHS 端末を植込み型医療機器へ近づけた場合に全く影響を受けないわけではなく、また、PHS端末と携帯電話端末が外見上容易に区別がつきにくく、慎重に取り扱うという意味で、携帯電話端末と同様に取り扱うことが望ましい。


     ウ 携帯電話端末及び PHS 端末の所持者は、植込み型医療機器の装着者と密着した状態となる可能性がある場合(例:満員電車等)、その携帯電話端末等の電源を切るよう配慮することが望ましい。


※ ここで今更だが注目すべきなのは…
アおよびイは、植え込み型医療機器の装着者本人にたいしての指針であり、本人以外の携帯電話端末所持者についての言及は、ウのみであるという点。

FileMaker Webビューアで、Safari の Webインスペクタを利用する方法

Posted on November 2nd, 2013

元ネタ:Enable Webviewer Inspector in any app using WebKit

Safari で開発メニューをオンにする

Safari > 環境設定… > 詳細 で
[メニューバーに”開発”メニューを表示] をオンに

WebKitDeveloperExtras を true に

Terminal.app で以下のコマンドを打つ

FileMaker Pro 11 Advanced の場合
defaults write com.filemaker.client.advanced WebKitDeveloperExtras -bool true

FileMaker Pro 12 Advanced の場合
defaults write com.filemaker.client.advanced12 WebKitDeveloperExtras -bool true

FileMaker Pro 11 の場合
defaults write com.filemaker.client.pro WebKitDeveloperExtras -bool true

FileMaker Pro 12 の場合
defaults write com.filemaker.client.pro12 WebKitDeveloperExtras -bool true


使い方


FileMaker で、対象にしたい Webビューアの設定で
[Webビューア内容とのインタラクションを許可] をオンになっていることを確認


FileMaker で、対象にしたい Webビューア上で右クリック、"要素の詳細を表示” を選択
※ 右クリックで 要素詳細を表示が出てこなければ、FileMaker を再起動



蛇足

Safari の WebKit を使っているアプリであればほとんどすべてこのパターンでできるっぽい。

WebKit を使っているアプリの .plist ファイルを
~/Library/Preferences/ 下で探す。
そのファイル名が当該アプリのドメイン名。
※ 項目名は WebKitDeveloperExtras

defaults write [ドメイン名] WebKitDeveloperExtras -bool true

新聞を読まない人はダメなのか?

Posted on October 16th, 2013

ネタに困ったブロガーはいまさら新聞を読め --- 永江一石のITマーケティング日記」 を読んで…

この方、いまだに「情報源は多い方がいいに決まっている」と断言してる。

なんだかなー…

情報は広い方が良い…つーのはある意味納得できるけれど、「情報は多い方が良い」ってのは違うでしょ?

あ「情報は…」じゃなくて「情報源は…」か。

「新聞でなければ得られない」という類の情報があるのであれば「新聞」という情報源は意味を持つでしょうね。

僕には見いだせませんけど。

まず、想起されることは…

絶対に失念しては鳴らない情報・必ず拾うべき情報…を決定するときには、忘却すべき情報・捨てるべき情報という補集合が存在します。

一方、情報を理解して、脳内処理の材料にして、自分の考えを決める…という処理には、時間というリソースが必要です。

だから…捨ててしかり…という類の情報は、はじめっから拾わないのが合理的。

(新聞の情報が、すべて、はじめから拾う価値がないと言っているのではありませんよ。念のため。)

一口に「情報」つったって…

世事もあれば、自分の専門分野のソフトウェアがアップデートしてえらく方向性が変わる…というような「世間の人には意味が無くても自分には重要な情報」もあります。

自分の嗜好としてのベクトルは、世事よりむしろ、自分にとって重要な情報に向かう…それは自然なことです。

そして重要なことです。

新聞に載るような情報で、自分にとって重要な情報が、新聞からでなければ入手できないとは思わないのです。

重ねて言いますが、新聞に載っている情報なんて無意味であると言っているのはありません。

「新聞を読んで吸い上げよう」という方向にハンドルを切るのは、無意味だと思うだけです。

もう「吸い上げよう」「取り込もう」としなければ、情報が入ってこなかった時代でありません。

情報のシャワーを浴び続けることを余儀なくされる時代に生きているのです。

ひとりの社会人としてオトナとして知っておいた方が良い…という全てのオトナにとって必要な情報は、勝手に必要分入ってくる環境さえ作ればいいだけです。

それは、SNSでもいいし、ニュースサイトのRSSでもいい。

そもそも完全なシャットアウトなんてできないのだから、「新聞を読むこと」それ自体が「褒められるべき行為」だと盲信することに違和感を禁じ得ません。


EyeTribe --- 視線の移動をポインティングデバイスに

Posted on September 9th, 2013


http://theeyetribe.com/

Leap は、思いの外、肩が凝ることに気付き、同時に、思った以上に、自分の、(マウスやトラックパッドなどの)従来型ポインティングデバイスの扱い能力の高さに気付いたことから、Mac Pro から取り外してしまっているが…
視線…ですか…。
良さ気…ですね…。

bison

ICT Consultant, Solutions Developer, StudioBISON