日付の入力・選択にはDateFieldが便利 (formatStringで日付の書式を設定できる。

DateオブジェクトがselectedDateプロパティに格納される) 。

Validator - 必須項目のバリデーションは、以下のようなMXMLで記述できる。

<mx:StringValidator id="firstNameValidator"
    source="{firstNameTextInput}"
    property="text">

requiredFieldErrorでエラーメッセージを指定する。

n文字以上のバリデーションは、required="false" (デフォルトはfalse) とし、

minLengthで文字数, tooShortErrorでエラーメッセージを記述する

<mx:StringValidator id="lastNameValidator"
    source="{lastNameTextInput}"
    property="text"
    required="false"
    minLength="2"
    tooShortError="What kind of last name is that?"/>

EmailValidator, PhoneNumberValidator, ZipCodeValidator等も使用できる。

バリデーションのタイミングはtriggerEventで、どのコントロールのイベントを

モニタするかはtriggerプロパティで指定できる。

Flex Builderのデフォルトだが、Panel等のコンテナの中は相対配置で指定するのが

一般的。

相対配置 - 他のコンポーネントの位置やサイズを考慮して位置を決定する。

layout="vertical", layout="horizontal"がよく使われる。

コンテナ - MXMLでは子要素として記述、またはASでaddChild()を使うことで、

任意の数のコンポーネントを含めることができる。

<mx:Panel>
 <mx:TextInput/>
</mx:Panel>

Panel, HBox, VBox, Divided Box, Tile, Grid, Form等。

各子要素は0からインデックス番号がつけられ、getChildAt(1)でアクセスできる。

また、removeChild()で削除、swapChildren()で置換ができる。

サイズ - width, heightプロパティで、ピクセル数またはパーセントで指定できる。

ただし、ASではパーセント指定は、percentWidth, percentHeightで0-100の数値に

より行う。minWidth, maxWidth, minHeight, maxHeightで最小、最大サイズも指定

できる。

レイアウト - paddingLeft, paddingRight, paddingTop, paddingBottomで余白を

設定できる。また、horizontalGap, verticalGapで子要素間のギャップを指定する

方法もある。内部ではレイアウトは、以下の順に行われる。

- コンポーネントのデフォルトサイズの設定

- 最深の要素から順にサイズの算出

- 上位のコンテナから順にサイズと位置の決定

レイアウトのコントロール - Spacer, HRule, VRule等。

<mx:HBox width="250">
 <mx:Button label="Left"/>
 <mx:Spacer width="100%"/>
 <mx:Button label="Right"/>
</mx:HBox>

<mx:TextInput id="helloTextInput" text="Hello, World"/>
<mx:Label text="{ helloTextInput.text }"/>
<mx:String id="firstName">Alaric</mx:String>
<mx:Label id="nameLabel" text="{'Hello, ' + firstName}"/>

また、mx:Bindingタグでバインディングだけ切り出すこともできる。

<mx:String id="firstName">Alaric</mx:String>
<mx:Label id="nameLabel"/>
<mx:Binding source="firstName" destination="nameLabel.text"/>

双方向 (互いにバインディング) することも可能。

データが変更される度にトリガされるので、使い方によっては重くなるケースがある。

データモデルを使ったバインディング -

<mx:Model id="model">
 <info>
...

http://livedocs.adobe.com/flex/3/langref/index.html

MXMLでのイベントの定義方法 - タグの中の属性としてActionScriptを書く。

<mx:Label id="myLabel" text="The Button will change my text" />

<mx:Button id="myButton" label="Change it!" click="myLabel.text = 'Some new text'"/>

代表的なイベント - ActionScript内ではEvent.CHANGEなどの定数を使って指定する。

change : Event.CHANGE

click : MouseEvent.CLICK

creationComplete : FlexEvent.CREATION_COMPLETE

mouseDown : MouseEvent.MOUSE_DOWN

mouseUp : MouseEvent.MOUSE_UP

resize : Event.RESIZE

rollOut : MouseEvent.ROLL_OUT

rollOver : MouseEvent.ROLL_OVER

型について - 例えばNumericStepperは数値を保持するコントロールなので、その

数値はtextではなくvalueで取得する。valueの型はNumberで、'ageNS.value + 10'の

ように数値の演算に使える他、'"some string" + ageNS.value'のように書くと

文字列として連結できる (暗黙に文字列に変換して連結する)。NumberからStringへの

変換の明示的な指定には、以下のような方法がある。

fullNameTextInput.text = String(ageNS.value)

fullNameTextInput.text = ageNS.value as String

fullNameTextInput.text = ageNS.value.toString()

デバッグ - trace関数でコンソールにデバッグ出力できる。Flex Builderではブレーク

ポイントの設定、変数パネルなどが使える。

また、<mx:Script>の中に書くこともできる。

<mx:Button id="myButton" click="someComponent.someProperty = 'something'" />

<mx:Script>

<![CDATA[

// ActionScript

>

</mx:Script>

Dot Notation - ".プロパティ名"で、コンポーネントのプロパティを読み書きできる。

<mx:TextInput id="fullNameTextInput" text="John Smith"/>

fullNameTextInput.text // => John Smith

fullNameTextInput.text = "John Smith";

関数の定義 - public, privateの指定子や、引数の省略と省略時の値、戻り値の型を

指定できる。

public function setForm(txt = "John Smith", sel = true):void

変数の定義 - "var"で定義する。

public var username = "Tom";

データ型 - 基本的な組み込み型は以下の通り。

String: 文字列。初期値はnull

Number: 小数を含む数値。初期値はNaN

uint: 0 ～ 4,294,967,295の整数。初期値は0

int: -2,147,483,648 ～ 2,147,483,647の整数。初期値は0

Boolean: true/false。初期値はfalse

void: undefinedのみを取る型。

Object型 - 任意のプロパティを持つことができるコンテナ

var car:Object = new Object();

car.color = "red";

Class - Objectをベースとして、プロパティやメソッドを規定したもの。

public class Car

{

var color:uint;

}

var car:Car = new Car();

car.color = 0xFF0000;

MXMLとの関係 - MXMLは内部的にはActionScriptに変換されてコンパイルされる。各タグは

対応するクラスのオブジェクトに、各属性はプロパティやスタイル、イベントリスナに

変換される。

コメント - ActionScriptは"//"または"/* ～ */", MXMLは"<!-- ～ -->"

MXML - XMLフォーマットの構造の紹介等 (省略) 。

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">

のxmlnsの部分は、"http://www.adobe.com/2006/mxml"を指すネームスペースmxを作成するという意味。

("MX"の意味は不明。"Maximum eXperience"という説もある)

ファイルに反映される。

Flex Builderの使い方 - コンポーネントパネルの使い方やコンポーネントの種類、配置等 (省略) 。

http://examples.adobe.com/flex3/componentexplorer/explorer.html

Flex Property Panel - Flex Property panelからコンポーネントのプロパティを直接編集できる。

代表的なプロパティの紹介等 (省略) 。

<mx:Button label="Two" visible="false"/>

<mx:Button label="Two" visible="false" includeInLayout="false"/>

では両方とも表示されないが、前者はレイアウトにそのサイズが考慮され、後者では考慮されない

<mx:TextArea alpha="0.5" text="..."/>

alphaプロパティで半透明にできる。

- Flex Builder : 一番お勧めだが有料

- Eclipse : XMLエディタ有り。コンパイルできるよう設定することもできる。

- FlashDevelop : オープンソースのActionScript用IDE。Windowsのみ。

- TextMate : ActionScriptやFlexのサポート有り。Macのみ。有償。

- その他のテキストエディタ

コマンドラインからコンパイルする方法の情報は、http://livedocs.adobe.com/flex/3/html/compilers_01.html

Flex Builder - EclipseベースのAdobe純正IDE。スタンドアロン版とEclipse plug-in版の両方があるが、

スタンドアロン版がお勧め。

Flex Builderでのプロジェクト - アプリケーションはプロジェクト単位で扱う。具体的な操作方法の

説明等 (省略) 。プロジェクト下のフォルダ構成は、

- bin-debug : コンパイル済みファイル (.swf) や、テンプレートから生成したHTMLや補助ファイル等

- html-template : テンプレートHTMLファイル

- libs : 追加のコンパイル済みライブラリ群

- src : ソースコード。.mxml, .as。AIRの場合は Application Descriptor File も

マークアップとJavaScriptライクなスクリプト言語で、簡単にアプリケーションを作ることができる。

Flash Playerの普及率は約99%。Flex SDKはコンパイラとライブラリとツール群で構成される。

複雑なアプリケーションには、アニメーションツールとして進化したFlash IDEよりも向いている。

AIRとは - Adobe Integrated Runtime (AIR) は、Flashやウェブコンテンツをデスクトップアプリと

して動かすソリューション。AIRの実行環境さえあれば動作する (OSに依存しない)。

なぜFlexなのか? - 綺麗に素早く書けて、リッチで動作も速く、オープンソースでフリーだから。

他との比較 - Flash IDEやAjax等との比較の説明。MXMLやAjaxよりも素直に書ける点が利点。 (Ajax

よりも"hackery"ではない)。タイムラインベースのアニメーションはFlash IDEの方が、テキストの

動的ロードや単純なインタラクションにはHTML/Ajaxの方が向いている。

Learning Flex 3: Getting Up to Speed With Rich Internet Applications (Adobe Developer Library)

二冊目はこれを。Adobe Flexの入門書のような本で、FlexのインストールからAIRアプリの作成までをカバーしているようです。

サンプルコードはこちら。 http://greenlike.com/

どのような摩擦が生じているのかを、平易な言葉でまとめたような本でした。

ほとんど全てアメリカの状況だけを語った内容ですが、日本の感覚とそれほど隔たりは無いように

感じます。普段目にする海外のニュースやブログの記事から、アメリカの現状がどうなっているか

分かっていたつもりですが、どのような裁判や立法を経て今こうなっているかの部分が、この本で

幾分か分かった気がします。

英語は比較的平易だと思いますが、所々の法文の引用が単語、文章ともに意味が取りにくかった

ので、Google検索に助けてもらいました。これもまさにデジタルの恩恵ですね。

なくなるだろう。また、スクリーン越しのコミュニケーションにより、旧来のアイデンティティの

意味が薄れ、別のアイデンティティの概念が生まれるかも知れない。

デジタル技術により、より簡単に意見を表明したり、誰かと通信できるようになった。だが、それら

の発言を収集したり、盗聴して解析する技術も進化している。通信技術の驚異的な発達に対して、

法的に言論の自由がどのような水準で守られるべきか、まだ明確になっていない。

クリエーターと消費者を仲介する業者は、デジタル世代になって、ますます法的な力と保護を強めて

いる。ラジオやテレビの業界でも、既存の会社が新技術と新規参入を閉め出している。アメリカが

今後向かうのは、情報の自由化なのか、それとも情報の寡占だろうか？

世界の通信量の多くは欧米間だが、これらは今後も急速に増えるだろうし、他の地域も同じだろう。

ビットの爆発的普及はまだ途中だ。ビットが世界を照らすか、歪めるかが人類の未来を形作るだろう。

参考: http://www.chrisharrison.net/projects/InternetMap/high/worldBlack.png

(FRC, 後のFCC) が設立され、免許制となった。FRC, FCCは検閲はしないと制定されているが、無線の

帯域が限られているため、明らかに低俗なものや詐欺的なものは免許の更新を拒否する権限を有した。

現代のテレビ局も、罰金等を恐れてFCCが定める規制に合わせている

デジタル化を含む無線技術の発達により、当時より遙かに効率良く大量の情報を通信可能となった。

だが、旧来から使われている帯域の方式はそのままであり、最新技術の見地からはほとんどの帯域で

アイドル状態となっている。無線技術の未来はこれらの有効活用にあるが、旧来の方式で帯域を保有

する会社は現状維持を望んでおり、FCCからの天下りやロビー活動等の抵抗を行っている。

テレビやラジオは政府によってその内容を規制されているが、デジタル技術によってもっと多くの

コンテンツが流通するメディアでは書籍等のレベルまで規制を緩められるべきである。デジタルの

普及により、社会はどの情報が公開され、どの情報が規制され、どの情報が禁止されるかといった

問題に直面するだろう。

参考: http://www.ntia.doc.gov/osmhome/allochrt.pdf

責任を問わない旨の条項を含んでいた。CDA以前に、責任の追及を恐れてAOLが投稿の削除しなかった

ために個人に実害が及んだ例もある。CDA以後は、議会の想定以上にISPの保護にその条項が使われた。

より内容を限定した Child Online Protection Act (COPA、1998年) が成立し、未成年に対する

わいせつコンテンツの視聴の制限を求めた (リアルな書店でのポルノ雑誌販売と同じような想定) が、

年齢の特定は技術的に難しく、クレジットカードを必ず要求する等の方法はユーザーを萎縮させると

して、裁判所は退けた。

ネット上で名前や住所を晒され、現実にストーキングやハラスメントにつながるケースについて。

それらを取り締まるための対サイバーストーキング法の制定も進んでいる。

匿名で脅迫や迷惑行為の意図で電話や通信を行い得る機器やソフトを違法とする条項を含んだ法律が

現れた (2006年)。注意を引くことなく通過した法律だったが、何を迷惑行為とするかが不明瞭だった

ために議論を呼んだ。

アメリカは言論の自由を重んじるが、他の国ではそうとは限らない。yahoo.frがオークションでナチス

関連商品の出品があったことでフランスで問題になり、Yahoo!はyahoo.frから取り下げたが、米国内の

サイトにそのまま残っていたことを理由にフランスから訴えられた。この件について、米国の裁判所は
Yahoo!を指示しなかった。

規制強化と自由の維持との間で、法律の天秤が揺れている。技術的およびプライバシーの面で難しい。

ユーザーが法律を違反した際に、掲示板運営者などのサービス提供者を単なる配信者とみなして

責を負わないか、あるいは出版社として責を負うかどうかの裁判が行われた。その結果、

検閲や編集を伴わない場合は配信者、伴う場合は出版社とみなして、後者の場合の賠償責任を認めた。

アメリカの裁判所がわいせつ物として見なす基準 (ミラーテスト、1973年) :

1. コミュニティの規範と照らし合わせて、好色な興味を引くものであるか

2. 法律で定義された性行為を明らかに下品に描いているか

3. 文化的、芸術的、政治的、科学的な価値に欠けているか

だが、1のコミュニティは州によって異なるので、ある州では適法だったアダルト系の掲示板が、

別の州から摘発されて有罪になったケースがある。

未成年に対するわいせつ物を規制する Communications Decency Act (CDA、1996年) が成立したが、

インターネットはテレビやラジオのようなもので規制が必要とする政府に対し、裁判所は、

インターネットは会話のようなものであり、規制すべきでないと退けた。

P2Pが広まった。それに対して、RIAAは威圧的な訴訟で対抗しようとしている。確実な証拠が無くても、

1曲あたりの侵害に750～150000ドルの訴訟を起こすと持ちかけ、和解案 (4000ドル) をちらつかせる等。

侵害に対する量刑 - 以前は金銭的利益に関する侵害のみが犯罪で、刑期も軽かったが、1994年に改訂

されて利益に関わらず犯罪とされるようになり、今後も厳罰化に向かっている。

P2Pの出現 - Napsterにより世界中のユーザー間でコンテンツが不法に共有される現象が始まった。

Napster自身はコンテンツを仲介しているだけだったが、RIAAが訴訟を起こし、2000年に停止が命じられた。

NapsterはP2Pやインターネットでのコンテンツ流通の可能性を示したが、業界は反発を続けた。

そのうちにアップルがiTunes Storeを開始し、商用ダウンロードサービスとして成功を収める。

中央サーバーのないP2P - Napsterと異なり、コンテンツ情報を集める中央サーバーの無い形のP2Pも現れた。

Grokster等のそれらのサービスをRIAAは訴えたが、違法ファイルの共有以外にも利用できることから、

明確に侵害を助長する異図で配布した機器やソフトのみが違法となった。だが、罰金があまりにも高い

ことから、新技術の開発を萎縮させる効果はあった。

DRMについて - コンテンツを販売する際に、複製や配布を防ぐために、DRM付きで売る会社が現れた。

DRMによって、従来の本やCDでできた友人に貸したり、中古に売るといったことができなくなった。

また、DRMの多くが特定の会社の製品に依存することから、DRMによる囲い込みも懸念される。

一方、DRMを回避して複製する方法や、アナログ的に写真やビデオを撮って再デジタル化する方法も

現れた (ハリー・ポッターの最終巻は販売前に全ページを撮影したものが広まった) 。

禁じられた技術 - DRMを回避する技術の開発自体は違法ではなかったが、DVDのDRMが破られて広まった

のを受けて、それらも違法とされた (DMCA)。iPhoneをアンロックすること自体は違法ではないが、

その方法を開発して広めることはDMCAに抵触する。デジタルコンテンツの周辺技術に対する制限や

訴訟リスクは、技術革新を萎縮させる効果がある。

著作権のバランス - 1790年当時、アメリカの著作権の期限は28年だったが、現在は著者の死後70年まで

伸びている。デジタル技術により、消費者側はコピーを行い、著作者側はDRMや訴訟で対抗したため、

著作権と消費者のバランスが崩れた。だが、DRMフリーの楽曲販売や楽曲配信の包括契約など、

対立以外の傾向も見られるようになってきた。

所有権について - コンテンツの権利者の権利がどこまで及ぶべきかは、公共の利益との兼ね合いもあり、

均衡点が探られている。Googleの書籍インデックス化計画など。また、クリエイティブコモンズのように

作品を共有する思想も登場している。

元々は主に軍事用で、FBIや当局が規制や解読用バックドアの設置を試みたこともあった。

過去の暗号化手法:

- 暗号表での文字の置き換え: 空白と再頻出文字の傾向から解読される

- 複数の暗号表を切り替えて使う方法: 上の手法の拡張で解読される。

暗号表の規模によっては解読が難しいが、そのため暗号表の使い回し等が起こった

良い暗号化のシステムがあっても、不便なもの、高価なもの、普及していないものは使われない。

暗号化のアルゴリズムを秘密にしていても、普及すれば暴かれる (例: DVDのCSS) 。

アルゴリズムそのものは公開されていても破れないものにすべき。

公開鍵による暗号化: 暗号化通信の根本を変えた画期的な手法が発見され、RSA等が作られた。

本人確認のためのデジタル署名、証明書発行局による本人証明の手法にもつながった。

暗号化の普及: デジタル機器の進化と普及により、日常的に暗号が使われるようになった。

当局は規制や盗聴をしたがり、RSAのコントロールも行っていたが、関係者の一人がPGPとして

米国外にも流したため、結果として世界中に広まった。

ほとんどの人はメールを暗号化しない: 危険性に気づいていない、隠すほどのものではないと

考えている、システムにデフォルトで組み込まれていないから。

雑多なバザールになっていった。その中から求める情報を見つけ出すブローカーとして、検索エンジンが現れた。

不都合な情報 (WikiLeaksなど) にも簡単にアクセスでき、インターネットから完全に消すことは不可能となった。

情報階層化の失敗 - Gopher、Yahoo! のディレクトリなど。情報量の増大についていけなかた。

Yahoo! = "Yet Another Hierarchical Officious Oracle"

検索エンジンの動作:

1. 情報を集める

2. ページのコピーを取っておく

3. 索引を作る

4. 検索リクエストを解釈する

5. 関連ページを決定する

6. 検索結果を順位付けする

7. 検索結果を表示する

検索エンジンのビジネスモデル - 初めは検索結果の順位を売っていた (Overtureなど。競合する場合は

オークションも)。FTCの警告もあり、後に廃れた。それらの方式の一部を取り入れ、検索結果に並べて

広告を表示する Google AdWords が登場した。

検索エンジンの権力 - ほとんどのユーザーは検索結果の先頭しか見ないので、検索エンジンが重要となった。

検索エンジンのアルゴリズムはそれぞれ異なり、検索結果の偏りや操作が生じ得る。

Google China では検索結果の操作による一種のマインドコントロールが行われている。

検索キーワードの履歴の保存: プライバシーの懸念はあるが、検索エンジンの改善やマーケティングに有効。

検索エンジンによる支配への懸念から、規制や代替を求める声もある。ヨーロッパの官製検索エンジン Quaero など。

- アメリカ当局が機密情報をPDFのハイライトツールで黒塗りしただけで公開してしまったケース

- ワシントンポストがWORDの更新履歴を残したまま文書を公開してしまったケースなど

- テキストを画像化してスパムフィルターをすり抜けようとするスパムメールの手口

- テキストの中に別の情報を隠すテロリストの手口など

電子的に何かを表すのに、アナログ情報を省略、エンコードなどによってデジタル変換している。

そのデジタル的に格納する仕様がフォーマットで、フォーマットによる支配や規制の争いなどもある。

中古のハードディスクの危険性 - 単純にフォーマットしただけではデータを復旧可能

(実験では158個中42個からカード番号らしきものを抽出) 。

データの寿命 - メディア自体の寿命は短いので、データの移し替えが必要。

インターネット上の情報は複製とバックアップによって永続的に残り続けるかも？

デジタル社会で人々がばらまいている足跡と指紋について。GPS, RFID, ブラックボックス、プリンタが紙にこっそり印刷している情報、ライセンスプレートを撮影・識別してチェックに使っている駐車場、情報漏洩事件、個人情報がなくても行動履歴からプロフィールを推定できる技術など。

なぜ人々は個人情報を企業に渡すのか:

1. Saving Time - RFIDの活用や毎月の自動引き落としは時間の節約になる

2. Saving Money - メンバーズカードによる割引など

3. Convenience of the Customer - 閲覧履歴によるリコメンデーション機能など

4. It's Just Fun to Be Exposed - ブログやSNSで自分を晒したい

5. Because You Can't Live Any Other Way - アメリカではクレジットカード無しでは生きていけない

Little Brother - 公開データからも個人情報をある程度辿れる。グーグルやSNSでの実名検索や、複数の情報を組み合わせる手法など。

Big Brother - 政府による盗聴や、外見から個人を特定する技術、データマイニングを専門とする企業の話など。

テクノロジーとともに生活スタイルも変わり、個人がデジタルデータに流す情報量も増大している

1. クレジットカード

2. Eメール - "Email is as public as postcards, unless it is encrypted, which it usually is not."

3. ウェブ - サービス会社はユーザーの利用状況を逐一記録している