FileMakerリレーションパターンを始めます

FileMakerのパターンについては、以前にいくつかサイトがあったようですが、fmpatterns.comだったかは応答なくなっていますし、こちらはリンク切れ気味です。まあ、オブジェクト指向の世界では90年代にパターンのブーム的なものもあったのですが、FMについては、2000年代の後半あたりにそのムーブメントがやってきて、そろそろおしまいなのでしょうか?

とは言え、パターン自体は確立した手法でもあるので、私の著書「リレーションで極めるFileMaker」(改訂版はRとの共著)にある解説内容を、パターンとして記述することを今検討中です。最近日本でも翻訳が出た「SQL Antipatterns」にも触発されました。

英語でのFileMakerに関するパターンは、誰かがWikiを立ち上げて、それにみんなが記述するという方法は取っていまして、まずはみんなの英知を集めいたいという意思は感じられます。ところが、パターン記述の定石とも言える、「決められた項目に従って記述する」ということが結局守られず、名前とやり方だけが掲載されていて、微妙に自慢大会状態になっていました。

パターンがなぜ使われるかというと、問題解決につながるからです。そのためには、開発作業に名前を付けるのはパターンの本質ではなく、発生した問題からパターンにたどり着くパスが必要なのです。そういう記述を、現状では工夫して行うということになりますが、やっていく必要があります。それを意識しながら、パターンを記述して行きたいと思っています。

ということで、これは前振りでした。

学校として成り立つには何が必要か?

私自身、ある学校でiOSの開発のことを教えており、このことを書くべきかどうか、同業者のことなのでちょっと迷ったのですが、きっかけのことがあってからやや時間が空いているので書く事にしました。自分の考えを残すのがブログの1つの役割でもあります。

ちょうど、2〜3年ほど前、複数の人からまったく同じ依頼を受けました。一部の方には個人レッスンもしました。依頼というのは「あるスクールへ通ったのだけど、まったく何も勉強できなかった」というものです。実際、個人レッスンしても、けっこう当たり前のことでつまずいていたのです。どこでどんなことを習ったのかを聞き、みなさん、同じことをおっしゃいました。もちろん、どの学校なのかはここでは伏せますが(とは言え関係者にはすぐ分かるでしょう)、その学校に行けば、「まとまった数のアプリケーションが作る事ができる」という点に実用性を感じたということなのです。また、値段的にも安いということもあったみたいです。

そういうわけで、みんな期待するのはそのスクールへ行けば、自分もアプリケーションを作れるようになるだろうということです。ところが通ってみると、テキストが配られ、アプリケーションのソースとちょっとした解説があり、その通りに入力してアプリが動いた〜というのの繰り返しだそうです。当然、動くアプリのプログラムだから、動く訳ですが、その繰り返しで、何十もアプリケーションを作った上に、さて、自分で作りたいアプリケーションがあるのだけど、プロジェクトを作った後にハタと手が止まるというわけです。

このスクールはかなりメディア露出もしたりして、そこそこ有名であり、かなり多数の受講者がいるようなことが紹介されています。だけど、同じようなことを言う人に何人にも出会い、私にとってはこのメッセージのタイトルの内容、つまりは学校とはなんぞやという考える契機になりました。

もっとも、「サンプルアプリケーションをたくさん作る」点はけっして悪くはないと思います。スクール側は期待するのは、実例から学ぶということでしょう。きちんとした実例は確かに手本ではあります。しかし、単に作業として進めてしまうと疑問に思う事なく進めてしまい、実は何も理解していない人も発生します。それは受講者の力量だろうと言ってしまうと、学校ってそこで終わるのです。学校の最終目標は、当然ながら生徒の能力を高めることに尽きるのです。ただ、100%それが達成できないだろうとか、絶対はないとか、いろいろエクスキューズはあるでしょう。しかし、学校として、全部の生徒に対する能力を高める努力をしないというのは正しいあり方ではありません。もちろん、そのスクールでは、実際にiOSのアプリをApp Storeに登録した人もたくさんいるらしく、まったくだめなわけではないようですが、一方で、私個人の周囲にも、失礼ながら落ちこぼれた人が何人もいるというのは、多分、成功者の方が少ないのじゃないかと想像できます。

ちなみに、そのスクールで結果を出した人ってのは、どうやら、作業をした後に、講師をしっかり捕まえて、あれこれ質問をした人ということを聞きました。その人は、手本と自分の知識の対比を判断でき、ギャップを埋める努力をしたということです。その方は、たぶん、一般より安い受講料で高い効果を得たという意味で、得るもの多数あったでしょう。しかしながら、聞くところによると、そういう人はごく小数、特に誰かが講師をスタックしたら、結局他の受講者は質問すらできないような場合もあったりするということです。まあ、実際には常にそうではないのかもしれませんけど、そういう状況が1回でもあると、受講している人は悪い状況を印象深く記憶するものです。

ただ、残念なことに、そうしたスクールの成功事例を「アプリケーションのサンプルを作らせる」という点に集約して、それによって儲かるみたいな話に流れている傾向があります。学校もベースはビジネスです。もちろん、儲かるという点は重要です。しかし、明らかに楽に儲かる方法みたいなパターンとして理解されているのはほんとうに残念です。サンプルベースでの学習の方法についてはは、ここでは詳細は書きませんが、実際のところは運用は難しいです。本来、学習には王道はないという前提があるとします。すると、学校というのは究極的には生徒に苦労させ、また言い換えればつまずかせて、その状況を打破する手伝いをし、そこから生徒は何かを得るという状態を作るということが求められます。苦労するのは当たり前だけど、そこで手を差し伸べるのが学校の役割と考えます。サンプルベースの学習でもそれは可能ですが、すくなくとも作業として集約させれば、苦労やひっかかりはありません。その場では「至ってスムーズ」としか思わないでしょう。そうではなくて、むしろ、ひっかけ、あるいはひっかかりをうまくコースの中に入れることによって、自力で解決させるような手法を取るほうが、本来の学校の機能を満たすと思います。

別にそのスクールがある前から、私は同じような事を言ってきており、そういう手法はどうなのかときかれることも多々あり、上記のようなことをお話することも何度もありました。結果的に学校に行っても地力が身に付かなかった人が多く出てくると、市場が飽和した段階で挽回する手段はなくなります。それは、学校にとっても生徒にとっても幸福な話ではないでしょう。長らく学校にかかわっている人はその意味が分かると思います。来シーズン(つまり4月から)、こういう主張をする私をラインからはずす学校がある一方で、こういう主張が正しいということでライン拡充を依頼するところもあります。もちろん、ラインからはずされれば何もできないのではありますが、一方で、本筋を忘れないで、かつ今時の市場環境において受け入れられるテイストってのもやっぱり考えて、がんばってやろうかなと思った次第でした。

ディスプレイを追加

そういうわけで、BenQの24インチGL2450、USB to HDMI Adapterが到着して、こんな状態になりました。写真がヘタですみません。右が、AppleのLED Cinema Display 27″、左がBenQの24″、右端はMacBook Air、左端はiPad 3rdです。AppleのDisplayの下にはNexus 7とCloud Communicatorなんかもあります。アダプタのドライバは古いものしか製品にはなかったのですが、こちらから最新版がダウンロードできました。

IMG_0018

それで、大画面2台の見え方がけっこう違います。当然、Appleの方がきれいなんですが、まあ、そいういう用途ではなく、ドキュメントなどを開いておくためのものなんで、あまり気にはしていません。ただ、BenQの方はまぶしい…。輝度0にしても、まだまぶしいです。

最初、「システム情報」のシステムレポートで見てみると、2項目は見えたのだけど解像度がおかしいと思ったのですが、ここに見えるのは、MacBook Airのディスプレイチップから接続されている、内蔵の液晶パネルと、Cinema Displayだけのものでした。小さい方の解像度は内蔵ディスプレイです。

ScreenSnapz001

アダプタ+BenQは、システムレポートとしては、USBのカテゴリにしか見えません。これは、「システム情報」がUSBアダプタのディスプレイなどには対応していないということですかね。

スクリーンショット 2013-02-19 11.44.57

 

大画面が2枚欲しい

今の私のメインマシンは、MacBook Air 11″(2012) + Apple LED Cinema Displayです。ディスプレイは前の機材の頃から使っているのです。この数年、だいぶんと視力が悪くなってきて、画面の文字を大きめにしています。XcodeはPresentationの設定がちょうどいい。ということで、大画面でも文字を小さくすると、実質的に「狭い」わけで、ディスプレイの追加を考えました。

AppleのThunderbolt Displayだと2台接続ができるらしいけど、Apple LED Cinema Displayは2台のうちの1台になれないらしい。1台8万円超のディスプレイを2台買うと、いいお値段であり本体より高い。これがいちばん理想的なんだろうけど、ちょっとぜいたくかな。

で、MacBook Airは、Apple製品以外に外付けディスプレイを複数使う方法がないかと思ったら、USBアダプタでどうも可能なようです。まず、これが1つ選択肢。メモリをたっぷり搭載しているので、そんなに重くはならないと思われますが、メーカ保証はないというところ。

別の選択肢は、iPadでAir Displayを使って、iPadからディスプレイにつなぐこと。これを2台目の外付けにするということです。ただ、これはいいアイデアだと一瞬思ったのですが、iPadにディスプレイアダプタをつけたら充電ができない。となると、毎晩、作業が終われば充電のためにつなぎ変えないといけないってことになりますね。さらに、Air Display + Apple TVという回りくどい、けど、ノンケーブルみたいなことを一瞬考えましたがどうだろう。なお、この方法だと、解像度が1080pになるけど、ドット数的にどこまでいけるかですね。直接接続の場合はいいとして、Apple TV経由だと解像度が中途半端になりますもんね。

外付けディスプレイは、Dellの24インチが2万円を切っているけど、21〜24インチだと、量販店でも2万円前後とそんなに高いものではないです。つまり、Apple製品でなければとりわけ安い。ということで、please give me your advices.

OS X 10.8 Serverのトレーナー認定合格

Apple認定トレーナー(Server Essentials)、なんとか通りました。10.8のACT全部の資格の更新が終わりました。とりあえずキープできたぞっ! しかし、今回は試験中にサーバの応答がなくなり、再起動して、最後の方は、次の問題に行くのに1分近くかかってかなりあせりましたが、まあ、受かればなんでもいいとしましょう。

スクリーンショット 2013-02-13 16.28.56 のコピー

要注意キーワード:みたいな感じ

要注意キーワード: みたいな感じ

想定される問題:

  • 類似させたい個所と、異なる結果にしたい個所が、正しく伝わらない可能性がある。
  • 良かった点、悪かった点が何なのか明確にならない可能性がある。

用例:

  1. トップページはアマゾンみたいな感じでお願いします。
  2. この前やったプレゼン、プロみたいな感じだったね。
  3. 素人みたいな感じのデザインで、どうかな?

キーワードが発生する要因:

  • 例を示しつつも、その通りではないということをほのめかしている。
  • 的確な表現が見つからない。対象となるものを全体的に評価しているが、詳細な点についての意図や評価基準を持っていない。
  • ネガティブな用例においては、湾曲表現、あるいは、意味をやや薄めた言い方であり、受け取り様によってはなんとでも解釈できる言い方をすることで、あつれきや問題視を避けようとしている。

会話でよく使われる「みたいな感じ」は、話のきっかけとして、大枠と方向性を示すには非常に有効である。しかしながら、「○○みたいな感じ」というのが最終的な目標や要望であるとすると、○○の何を継承し、なにを変更するのかという点は不明確なままになる。そのため、この表現が出た場合、具体的なポイントとして、何を意図しているのかを詳細に問いただす必要がある。

===========

…とまあ、パターンを考えながら、パターンのパターンを探っている、みたいな感じでw

擬態音は崩壊の前兆である

以下のメッセージは、今年の1/15にFacebookに書き込んだ内容です。パターンの勉強の一貫として、「書いてみる」ということをちょっとやってみているのですが、いろいろな意見をいただきました。これも、記録としてこっちにも書いておきます。

================================

プロジェクト進行や計画ミーティング等でのパターン:

◎擬態音は崩壊の前兆である

  • 例1:この部分はささっと終わらせて
  • 例2:ボタンを押すと、ポーンと出てくるのがいいね
  • 例3:これでバーンと儲かりますよ!

 

決めごとの中に擬態音が混在すると、そのゴールは人に寄って異なる解釈となる場合が多い。つまり、具体的な方針には成り得ないことが多く、後から問題が発生する場合が多い。あるいは、具体的になにをすべきか分かっていない、あるいは検討されていない場合のその場しのぎで発せられる場合もあり、対処すらできない場合もある。

バリエーション1:濁音>半濁音>それ以外、の順に不吉な予感は高まる。
バリエーション2:関西弁の擬態音は、ほとんど省略可能として無視できる。

解決策:
擬態音の部分を具体化するか、非機能要件として定義できれば、崩壊を免れることができる。擬態音が発生した段階で、その擬態音を具体的な要件、あるいは形容詞などで置き換えることを試みる。置き換えができないものは、要件ではないと判断し、検討を重ねる。
また、擬態音を省略した場合、意味が通じるかについて判定する。つまり、コミュニュケーションの手段としてより強調したり、印象づけるために使われている擬態音については要件と分離できるため、無視することも可能である。しかしながら、無視できるかどうかについては、さらにコミュニケーションを深める必要がある。

ここでBlogを再スタートします

最近までOS X Serverでブログをやっていましたが、OSのアップデートである意味うまくデータは移行できず、どうするか考えていたのですが、OS X Serverを離れてこういう手段を取る事にしました。ここは、NTC Hostingというところのサイトで、Moodleでのサービス提供用に確保したところですが、WordPressを数秒でレディにしてくれるというので、ここでWPで運用することにしました。古いブログは特に移行はしないつもりですが、OS X Serverのページはおそらく検索エンジンは取り出さないでしょうから、今後意味のありそうな情報は適時転送することにします。

ということで、どうしようか考えたのですが、「プロバイダでWord Press」です。Word Pressの人気と意味は良く分かっていますが、人が群がっているものを自分も食うのは好きではないので、ずっと避けていました。まあ、でも、どうでもいいことですので、手軽かつスピーディーであれば問題ないでしょう。はてなとか、アメーバとか、日本のみんなが使っているところっていうのもなんかなぁと思うし、わざわざマイナーなサービスを探すのもあほみたいですから、順当な線に落ち着きました。ということで、まずはバックアップの算段からやるかな(苦笑)。だけど、このWPって日本語化されていないってことですかねぇ…日本語のブラウザで見ているのにメッセージ全部英語です。まあ、いいんですが、海外のプロバイダだとこういうこともあるんですねえ。

ということで、全然不定期になると思いますが、更新したらFacebookに紹介するというオペレーションでやっていきたいと思います。

OME never die! と言いたいけれど…

<a href=”http://msyk.net/ome”>OME</a>を一生懸命やっていたのは、1999〜2004年くらいかな。ちょうど、<a href=”http://msyk.net/cserver/mdo.html”>MDOnline</a>の頃に重なります。その後も、だましだましOMEを使ってきました。相当だましたので、OS X Lionでも使えてはいますが…。ちょっとかなりきつくなってきました。それでも、never dieと言いたいのですが、かなり苦しいかも(苦笑)。

まず、「再開」の機能により、ウインドウの残り方が今ひとつよくないのか、落ちることしょっちゅうです。まあ、データを書き込んでいないし、所詮テキストファイルなので悪影響はまったくありませんが、あまりいい感じではなく、特に、command+Wでアプリが落ちるのはちょっと面倒です。コンパイルしなおそうとしているのですが、これがなかなかやっかいで、まだうまく行っていません。そこはだましだましなところですね。

そして、ついにというか、やっと気づいたというか、11月11日を境にiCloudのメールの受信ができなくなっていました。できないのをやっと気づいたというのは、iPadでもメールを読んでいるからです。fetchmailコマンドでme.comのメールってなんでだめなんだろうか? 認証のエラーが発生します。

仕方ないので、Mail.appでiCloudメールを受けるようにしました。

そこでふと考えたのは、Mail.appをfetchmail代わりに使うことです。メールソースをAppleScriptで書き出して、メールの整理はOME側でやればいいじゃん!ってことで、近々に取り組むつもりです。

電子メールというきわめてレガシーな仕組みが今だ、同じように残ると同時に混沌さは年々増す感じもします。昔から、電話をいちいち録音していないのと同じように、メールだって、しばらくすると「捨て」でいいとも思ったりもしますが、なぜ、テキストファイルで残したいのかというモチベーションを思い出し、もうひと頑張りしようと思います。つまり、OMEはメールの整理・ストレージに移行するということです。

さて、どうなることやら。

[IM]RSAを使って、JavaScriptで暗号化し、PHPで復号する

表題の通りの仕組みを、INTER-Mediatorに組み込もうとして、2日ほどもがきました。RSAつまり秘密鍵と公開鍵を使った暗号化をフレームワークに組み込み、クライアントで入力したパスワードを、暗号化してサーバに送るという仕組みを組み込んでいます。普通パスワードはハッシュだろうと思われるかもしれませんが、フレームワークが認証するパスワードではなく、パスワードをデータベースエンジンへのアクセスに使うべく、クライアントで入力したものをバックエンドまで安全に到達させるための暗号化なのです。

RSAやハッシュ関連のことは、ネイティブな開発ならOpenSSLを使えばおおむねOKなので、同じようにライブラリを集めれば楽勝だろうと思っていました。また、PHPにはopensslライブラリがあるので、まあ、なんとかなるだろうと思いました。要件としては、キーの指定を簡単にするということ。つまり、公開鍵と秘密鍵が1つもPEM形式で得られれば、それを設定ファイルに書き込むことでキーの指定ができるということです。もちろん、生成は「openssl rsagen 1024」みたいなコマンドで簡単に済ませたいわけです。

JavaScriptの世界では、Dave Shapiroさんが作っているライブラリがあり、後々のいくつかのライブラリの多くはこれを改良しています。DaveさんのはPEM形式でキーを与えられないので、Tom WoさんのCrypticoが作られたようで、さらに別の人が署名までできるようにしています。Crypticoでいろいろやっていたのですが、うまくいかない…というか、単純にこのライブラリの問題ではなく、PHPのライブラリとの組み合わせの問題があったのです。

それで、PHPの方はというと、openssl関連関数があるので大丈夫かと思っていたら、これがなかなかうまくいかいないのです。まず、PEMでキーを与えるのが原則とすれば、Crypticoを使ってクライアント側で暗号化するのが手軽です。それを、PHPのopensslの関数で復号するのがどうしてもうまくいかないのです。そのあたりのドキュメントが今ひとつ詳しく書いておらず、コメントには「マニュアルは正しくない…」などと書いてある始末で、あれこれやってもだめでした。

ただし、PHPのopensslの関数を使えば、PEMの鍵データから、RSAの本来の鍵というか、計算式に出てくる鍵の数値をそのまま得られる事がわかりました。さらに、RSA: Encrypting in JavaScript and Decrypting in PHPというドンピシャなものがあったのですが、それはDave Shapiroさんのライブラリを使っていて、RSAの本来の鍵を使う方法が記載されています。ところが、このサイトに書いてあるPHPのライブラリはpearにあるCrypt_RSAで、説明に使っているものはすでのメンテナンスがなされていません。それを使う手もありますが、メンテナンスされているライブラリの方がいいかと思い新しいサイトへのリンクを見ると、なんとこれが、以前このblogでも紹介したPHPだけで作られたSSHのライブラリを含むphpseclib:に移行していたのです。SSHのライブラリはきわめて順調に動いたので期待をして、こちらのRSAを使って復号しようとしました。しかしながら、どんなにこねくり回してもだめなのです。このライブラリのサポートのBBSにあるこの書き込みと同じ場所でエラーが出ているようです。Macだとだめで、debianだと動くようなことが書かれているのが気になるところですが、この方法でうまく流すには簡単には行きそうにありません。

Dave Shapiroさんのライブラリで暗号復号するのはできます。また、phpseclib:で暗号復号はできます。つまり、異なるライブラリをまたいでの暗号復号がうまくいかないのです。Dave Shapiroさんのライブラリで暗号化したものを、opensslコマンドで復号してみると、パディングに関するエラーが出て復号できません。データ形式の微妙な違いがあるのでしょうか? ドキュメンテーションの薄いライブラリや、あまりカスタマイズできないライブラリということで、これ以上手を下すことができず、ここで行き詰まってしまいました。

それで、改めてググって必死に探した結果、見つけたのがbi2phpというライブラリで、しかもMIT Licenseです。JavaScriptのライブラリは、Daveさんのものに独自に改良したものだそうです。それと互換でPHPのクラスを作ったというところでしょうか。いずれも、RSAの本来の鍵を指定するのですが、「データは全部HEX」というように、ある意味非常にわかりやすく、さくっとうまく行きました。

ということで、わかった事をまとめておきます。RSAの秘密鍵、公開鍵という仕組みはもういいとして、そこで使う鍵は、たとえば「openssl genrsa 1024」というコマンド入力で作られます。そのデータはPEMという1つのテキスト列であり、いわば、そこに秘密鍵と公開鍵などなど、RSA暗号処理に必要なデータがPKCSのルールに従ってパックされたものです。

$ openssl genrsa 1024
Generating RSA private key, 1024 bit long modulus ...................++++++ ............++++++ e is 65537 (0x10001) -----BEGIN RSA PRIVATE KEY----- MIICXwIBAAKBgQC/BlONnPUfSc95YmrcOUV0IbmeBZvibbAssetKBXAG0DGeKzc7        : 2MgfcIZ3C7lf0+yx3/RhXwJBAIYHkht7UPSpPeTvPzc4v89yBlkkGeN9xLbdONT3 uzINAQkGvVmDhNLYqxkgDysBUy/Q2f41DenUZJfEFLQBs5w= -----END RSA PRIVATE KEY-----

PHP側では、このPEM形式の文字列を使って、以下のプログラムで、RSAの計算に使うキーを求めることができます。$generatedPrivateKeyにはPEM形式のキーの文字列、圧縮アルゴリズムがAESの場合はパスフレーズを入れるので、その場合は$passPhraseに指定しますが、パスフレーズが設定されていない鍵は2つ目の引数は適当に無視します。

$res = openssl_pkey_get_private( $generatedPrivateKey, $passPhrase );
$keyArray = openssl_pkey_get_details($res);

この、$keyArrayの配列にいろいろなものが入っていて、公開鍵だけを取り出すには、$keyArray[‘key’]とします。

Daveさんのライブラリを使うには、鍵のオブジェクトを作成しますが、当然、自分で生成するのではなく、このPEMを鍵としてオブジェクトを初期化します。初期化関数部分は、次のように定義されています。biRSAKeyPairが鍵のクラス名と考えていいでしょう。

function biRSAKeyPair(encryptionExponent, decryptionExponent, modulus)

ここで、encryptionExponentは$keyArray[‘rsa’][‘e’]、decryptionExponentは$keyArray[‘rsa’][‘d’]、modulusは$keyArray[‘rsa’][‘n’]から得られます。生成した鍵からopensslのコマンドを使って出力(例えば、openssl rsa -text -in gen.key)した結果を見ながら、対応付けを確認しました。配列から得られた結果はバイナリなので、PHPの場合、bin2hex関数を使って16進文字列にして、JavaScript側の引数に指定をします。2次元目のeとdは、encrypt、decryptなんでしょうね。

なお、INTER-Mediatorでは、JavaScript側では暗号化しかしないので、2番目の引数は指定しません。というか、指定してクライアント側で見えたらいけません。なぜなら、$keyArray[‘rsa’][‘d’]は秘密鍵であり、暗号化には使わないからです。いずれにしても、JavaScriptのプログラムをサーバ側のPHPで生成してクライアントに送り込むという部分がこうした処理を組み合わせて作る事ができます。

bi2phpのPHP側のクラスは、JavaScriptとほぼ同様なプログラムでいいようになっており、サンプルのHTMLを見ればプログラムの作り方はすぐにわかると思います。非常に紆余曲折がありましたが、JavaScriptとPHPの双方で暗号復号をするには、bi2phpというライブラリでOKということです。ただし、PHPのopenssl関数を使って、PEMから鍵の値を得たりということは処理として必要になるということです。このライブラリをまとめたAndrey Ovcharenkoさんに感謝するともに、ライブラリをここまで育て上げたみなさんに感謝します。