AndroidによるJava APIの使用は著作権侵害に該当するという判決

Java

詳しくないので間違いがあったらすみません。

米控訴裁判所が、Java APIの使用に関するOracleとGoogleの争いに新しい決定を下したようです。Oracleによる「GoogleのAndroidによるJava APIの使用はフェアユースには当たらず、同社の著作権を侵害している」という主張を認め、地方裁判所に損害賠償の裁判を差し戻すという判決が出されました。
Oracle wins appeal against Google in copyright case – TechCrunch

今回の判決

判決文は以下にあります。
http://www.cafc.uscourts.gov/sites/default/files/opinions-orders/17-1118.Opinion.3-26-2018.1.PDF

最後のConclusionに次のように書かれています。

For the foregoing reasons, we conclude that Google’s use of the 37 Java API packages was not fair as a matter
of law. We therefore reverse the district court’s decisions denying Oracle’s motions for JMOL and remand for a trial on damages. The district court may determine the appropriate vehicle for consideration of infringement allegations regarding additional uses of Android. We dismiss Google’s cross-appeal.

私たちは、Googleの37のJava APIパッケージの使用は、法律上のフェアユースではないと結論づける。したがって、JMOLに関するオラクルの申し立てを棄却した地方裁判所の決定を取り消し、損害賠償の裁判を差し戻す。（後略）

言葉通り、フェアユースではないということは著作権侵害にあたるということなので、最初の損害賠償請求の裁判に戻すよ、ということです。

これまでの経緯

OracleとGoogleの争いに関するこれまでの経緯は、2016年7月のJJUGナイトセミナーの様子をレポートした次の記事に詳しくまとめられています。
Google対OracleのJava API訴訟。歴史的経緯とIT業界への影響を考える（その１）。JJUGナイトセミナー － Publickey

重要な部分のみ抜粋すると、

  1. GoogleによるJava使用は特許侵害ではないという判決がでる（2012年5月）
  2. APIは著作権法で保護されるという判決がでる（2015年6月）
  3. GoogleのAndroidにおけるJava API使用はフェアユースにあたるという評決がでる（2016年6月）

最初の2つは、すでに判決が出てしまっているので確定事項です。また、2のAPIが著作権法で保護されるというのはJava APIに限定されたものではないので、非常に広範囲に影響するということで大きな話題になりました。

APIに著作権があるとしても、Androidにおける使用はフェアユースだから著作権法の保護の対象にはならないよ、としたのが3つ目の評決です。判決文のJMOL（Judgment as a Matter Of Law）というのがこの判断のことを指しています。

その後、Oracleは地方裁判所に対して新たな審理を求めましたが、2016年9月に棄却されています。これが「JMOLに関するオラクルの申し立てを棄却した地方裁判所の決定」というやつです。そのあたりの経緯やOracleの主張については、下記の記事で解説されています。

オラクル、グーグルによるJava APIの使用めぐり上訴 - ZDNet Japan

今回の控訴裁判所の判決では、"フェアユースに当たる"とした判断そのものが覆されたわけです。なぜ覆されたのかは判決文に書いてあるようですが、難しそうなので読んでいません。誰か読んで教えてください。

追記：
判決文をもう少しちゃんと眺めてみたので、こちらも参考にしてください。
AndroidにおけるJava API使用の何がフェアユースではなかったのか - 我らねぶた馬鹿

今回の判決はあくまでもOracle対Googleの個別事案

勘違いしやすいので注意しなければいけないのは、「APIが著作権法で保護される」というのは、今回の判決に関係なく2015年にすでに確定してしまっています。

そしてその後にOracleとGoogleが争っていたのは、「AndroidにおけるJava APIがフェアユースにあたるか否か」という個別の事案であって、この裁判の判決が、世の中にあるそれ以外のすべてのAPIに適用されるというわけではありません。

今後どうなるか

気になるのは今後Androidがどうなるかということですが、これからまた損害賠償請求裁判をやり直すわけなので、すぐにどうこうなってしまうということはないかと思います。ただ、次にGoogleがどう出るかには注目しておいた方がよさそうです。長期的には、GoogleがJavaを見限るという極端な展開も含めて、いろんな可能性がまた復活しちゃったなあという感じですね。

JJUG ナイトセミナー 「Java SE 10 / JDK10リリース特集」に参加した話

Java Java10

3月26日（月）に開催されたJJUGナイトセミナー「Java SE 10 / JDK10リリース特集」に参加してきました。タイトル通り、先日リリースされたJava 10の新機能などについて特集する会で、参加者240人枠の予約がすぐに埋まり、さらにキャンセル待ち200人以上という盛況ぶりでした。やはりみんな関心があるんですね。
【東京】JJUG ナイトセミナー 「Java SE 10 / JDK10リリース特集」 3/26（月）開催 - 日本Javaユーザーグループ/Japan Java User Group | Doorkeeper

どうでもいい話だけど、Java 10と書けばいいのか、JDK 10と書けばいいのか、はたまたJava SE 10と書けばいいのか未だに戸惑いますね。

新しいリリースモデルのおさらい

まずはオラクルの伊藤敬さん（@itakash）から、新しくなったJDKのリリースモデルに関するおさらいから。

もういろんなところで言及されているように、OSS版であるOpenJDKについては、年2回6ヶ月毎（3月と9月）のメジャーリリース、3ヶ月毎（1、4、7、10月）のパッチリリースというサイクルになります。原則として各バージョンでリリース期間は重複しないので、次のバージョンが出たらそれまでのバージョンは非サポートになりますが、3年毎にLTS（Long Term Support）版が出ます。直近のLTSは次のJDK 11です。

Oracle JDKは、次のJDK 11以降で新しいリリースモデルが適用されて、以降は有償版のみの提供となります。リリース間隔は3年ごとで、サポート期間はそれぞれ8年間。OpenJDKと同様に3ヶ月毎に（1、4、7、10月）パッチリリースが行われます。なお従来Oracle JDKの有償版にのみ提供されていた機能については、段階を踏んでOpenJDKに移行されるので、Oracle JDKとOpenJDKは同等の内容になります。

これまで無償版のOracle JDKを使っていたユーザは、Oracle JDKを有償サポートで使うか、OpenJDKに移行するかという選択を迫られています。非LTSなOracle JDK 8のサポート期限が2019年1月（個人利用の場合は2020年12月）なので、猶予はそれほどありません。
Oracle Java SE サポート･ロードマップ

ただし、これまでのOracle JDKも無償版に関してはOpen JDKと同等のものだったので、この機会にOpenJDKに移行してしまってもそれほど大きな問題にはならないと思っています。その場合、常に最新機能に追随して6ヶ月毎にアップデートを頑張るか、LTSで3年毎にアップデートするかという選択になりますね。
それよりも問題は、Java 8からJava 9にかけては多くの非互換性が含まれているので、Oracle JDK 8のサポート期限である2019年1月までに移行を完了させられるかということに尽きますね。これから始めるプロジェクトに関しては、Java 9以降（現実的にはJava 11）をターゲットにする想定した方がいいと思います。

JDK 10の追加機能の解説

続いて、David Buckさん（@DavidBuckJP‏）によるJDK 10に追加された新機能の解説。あとから資料が公開されるので細かい話は両略しまし（公開されたらリンクを追加します）。あと、Qiitaのきしださんの記事もよくまとまっていて分かりやすいです。

Java 10新機能まとめ - Qiita

Buckさんの話の大部分は、JEP 286のローカル変数型推論についての話でした。いわゆる、Java版の「var」です。JDK 10以降では、変数の宣言時にvarを指定することで明示的に型を指定しなくてもよくなりました。これはあくまでもイニシャライザの型から自動的に静的型が推測されるだけなので、動的型とは全く違います。型を書かなくてもいいというだけで、内部的には型があります。

varが導入されたことで、Javaのコーディングスタイルは大きく変わる可能性があります。ということで、OpenJDKプロジェクトからvarを使う場合のスタイルガイドが公開されています。Buckさんの解説もこのスタイルガイドを元にしたものです。「Oracle Blogs 日本語のまとめ」に日本語訳があります。

Oracle Blogs 日本語のまとめ: [Java] Style Guidelines for Local Variable Type Inference in Java

ここでもっとも重要なのは、"varはコードの可読性を上げるために使う"ということだと思います。タイプ量を減らすといった目的ではなく、あくまでもコードをシンプルにして読みやすくするために使うということです。明示的な型宣言が無いとコードが読みにくくなりそうですが、実際にはコードを読めば何の型かはすぐに理解できるので問題なく、逆に可読性が上がるという結論が多くの言語で出ているそうです。面白いですね。

Java 10でぼくたちの生活はどうかわるのか

最後に、久保田祐史さん（@sugarlife）ときしだなおきさん（@kis）によるセッション。おもに、新機能や互換性などの情報をどう追っていったらいいかという話や、Java 10に移行する上ので注意点などに関する話。これも資料が公開されるそうなので、細かい話は省略します。

Java 10以降におけるアップデートの手順は

  1. （既存プログラムを）再コンパイルせずに新しいJava環境で動かしてみる
  2. 非対応ライブラリや非推奨APIを洗い出す
  3. 非対応/非推奨部分を代替手段に置き換える

という感じにするのがいいそうです。非対応ライブラリの洗い出しには、jdepsやjdeprscanなどのツールを使います。jdepsはライブラリの依存関係を調べるツールで、deprscanは非推奨なAPIが使われている場合に、それを検出するツールです。

個人的に気になって質問したのは、新バージョンの検証をどれくらいのタイミングで初めていくのがいいかということです。これまではリリースサイクルがゆっくりだったので、JCPが固まって参照実装が出たくらいから検証を始めて、リリース後ある程度こなれてから対応というスパンでも十分でした。新しいリリースサイクルだとあまりのんびりしている時間はなさそうなので、これがどう変わるかということです。

LTSを移行ターゲットにしつつ、その間にリリースされたバージョンを順番に検証していくという形が現実的でしょうか。OpenJDKのリポジトリを追えばリリース前にも検証を進めることは可能だけど、そのサイクルを追うのはさすがにしんどいので、LTS以外は正式リリースを追う形でもいいんじゃないか、というのがきしださんの見解。私も同意です。

また久保田さんは、「まずは Java8 → Java9 を乗り越えること。それさえ乗り越えられれば、その後のバージョン間の差分（新機能とか非互換性とか）はそれほど大きくないので、あまり怖くないはず」とおっしゃっていました。

あと「創るJavaはいつ出るか？」という質問の意図について書こうと思ったけど、長くなったので別の機会にします。

Java Day Tokyo 2018に関するアナウンス

伊藤さんから、Java Day Tokyo 2018関するアナウンスがありました。Java Day Tokyo 2018は5月17日（木）開催。基調講演に、なんとMark Rainhold氏の来日が決まったそうです。これが昨日の一番の驚き。参加登録サイトは近日中に公開予定とのこと。

JJUG CCC 2018 Springに関するアナウンス

JJUGより、 JJUG CCC 2018 Springに関するアナウンスがありました。JJUG CCC 2018は5月26日（土）開催。今月末までCall for Paperを募集中なので、ネタを持っている人は怖がらずに応募して欲しいとのことです。
JJUG CCC 2018 Spring

Eclipse FoundationがJakarta EEプロジェクトに関するサーベイを実施中

Java JavaEE Eclipse JakartaEE

去る2017年9月、Oracleはこれまで同社が主導していたJava EEの仕様策定および開発をEclipse Foundationに移行することを発表しました。
それに伴ってEclipse Foundationが新名称を決める投票を実施し、その結果をもって、今後は「Jakarta EE」の名称で開発が行われることが正式に決定しています。
https://mmilinkov.wordpress.com/2018/02/26/and-the-name-is/

現在Eclipse Foundationでは、今後プロジェクトを進めるにあたっての開発者向けのサーベイを実施中です。
Jakarta EE Developer Survey 2018

ごく簡単なアンケートです。期限は2018年3月30日11時59分（太平洋夏時間、日本時間では4月1日3時59分）まで。今後注力していくターゲットを考える上での重要な手掛かりになると思われるので、積極的に参加することをおすすめします。

自転車用スマートロック「LINKA」でセキュリティ向上なるか

自転車

実は年明け早々に愛車のMTBを盗まれてしまい、新しいMTBを買う羽目になりました。
もう盗まれるのはイヤじゃ、ということで2重ロックを徹底するべく、自転車用のスマートロック「LINKA Lock」というやつを導入しました。

f:id:zinbe:20180124120850j:plain

LINKA Smart Bike Lock - Lock Smarter, Not Harder – LINKA Smart Locks
簡単に言うと、ペアリングしたスマホとBluetooth接続が確立しているときだけ、ボタン一個でロック・アンロックできるという代物です。

その他に、以下のような機能もついています。

  • スマホアプリからアンロックできる
  • 1m以内に近いたときに自動アンロックされるモードがある
  • スマホが無いときはパスコードでもアンロックできる
    • でもパスコードの入力はちょっと面倒
  • 振動を検知してブザーを鳴らせる
  • 自転車を停めた場所（最後にロックが作動した場所）をスマホに表示できる
  • スマホに未接続の状態で一定時間経つと、バッテリー節約のためにスリープモードになる
    • 時間は設定で変更できる

YouTubeの解説動画を見ると、なんとなく様子が分かる。
www.youtube.com

ロックの途中でスポークに当たったりすると、安全装置が働いてロックが中止され、スマホに通知が来ます。
また、近づいたときに自動アンロックする機能があるものの、離れたときの自動ロックしてくれるような機能は無い模様。

もともとKickstarterで資金募集してたもので、今は市販されてるものの、169ドルとちょっと高い（ただし、日本にも無料で届けてくれるみたい）。私はメルカリで中古のものを買いました。

実物はこんな感じ。結構ゴツくて重いです。
f:id:zinbe:20180124120945j:plain

私のMTBにはダボ穴が付いておらず、ブレーキ用ブラケットも無いので、タイラップで無理やり固定しました（一応、公式にもタイラップでOKと説明されています）。
こんな感じで、ちょっと不恰好。
f:id:zinbe:20180201090022j:plain

上の動画の最後にあるようにタイラップを裏側に回した方が見た目が綺麗なんですが、私のはシートステーの幅が広めなためうまくフィットせず、写真のようになりました。
内側の横幅は2.1インチのブロックタイヤでもほんの少し若干余裕がある程度。縦幅は、フェンダーが無ければ余裕でした。

取り付けて1週間ほど経ちましたが、今のところ快適に使えています。
特に、コンビニに寄ったときなどにいちいち鍵を取り出す必要が無いのがいい感じです。
バッテリーは1週間で6%減。この分なら2〜3ヶ月に1回充電すれば足りそうです。充電はmicroUSBでできるので、モバイルバッテリーを繋げば良さそう。
f:id:zinbe:20180201134404p:plain

なお、長時間停めるときには、これとは別にワイヤー錠も併用して2重ロックにしています。

現状の不満点を挙げるとすると、次のような感じです。

  • ロック・アンロックが遅い
    • 開始から完了まで3秒くらいかかる。途中で揺らしたりすると安全センサーが働いちゃうので、動かさずに待つ必要がある。
  • ボタンが固い
    • 指が痛いくらい思いっきり押さないと反応しない
  • スリープからの復帰したときに、Bluetooth接続の反応が悪いことがある
    • スマホのアプリを立ち上げ直すと接続されるので、たぶんスマホ側の問題。仕組み上仕方ないのか

私が買ったのは「ORIGINAL LINKA」の方ですが、春にはGPSトラッキング機能も付いた新製品が出るみたいです。
GPS付いてても、通信はどうするんだろうってちょっと疑問ではありますが。

ちなみに、同様のスマートロックで「I LOCK IT」という製品もあります。
Bike Lock - I LOCK IT - The Smart Bike Lock
実は最初はこっちの方が気になっていたんですが、公式サイトからは日本には発送していないということで断念しました。
自動ロック機能があったり、オプションでKye fob（スマホいらずの電子キー）があったりして、こっちの方がちょっと高機能な気がします。

「#12 Creators Learning English Meetup」 #clem_jp

英語 CLEM

先月に引き続き、「#12 Creators Learning English Meetup」に参加してきました。

clem.connpass.com

Creators Learning English Meetup 略して「CLEM」は、英語を勉強中のエンジニアやデザイナーを対象としたMeetupで、ほぼ毎月開催されています。
英語の勉強法やTipsを発表し合ったり、英語で挨拶や会話をするなど、とにかく英語に触れる機会を増やそうという会で、Meetup以外に朝活などもやっているそうです。

今回は開催1周年記念ということで、2017年のCLEMで登場した英語学習Tipsのおさらい、LT大会、として
簡易版"他人に目標を立ててもらう会"（タニモク会）の3本立てでした。

まず https://twitter.com/kayoko_coco:@kayoko_coco さんより2017年の英語Tipsまとめ。去年のCLEMでは、次のようなTipsが挙げられたそうです。

  • 英語の学習はスポーツと同じ
  • 諦めから始めることで挑戦のハードルを下げる
  • 英語で自分が何をしたいのか具体的にイメージしよう
  • 根拠のない自信を持とう！
  • まずは3000語程度の語彙力をつけよう。日常会話は3000語くらいで理解できる！
  • あらゆる隙を見つけて、英語でできることが英語でやる！
  • 独り言を英語で
  • 発音はカタカナで覚えてはダメ。耳コピ、発音記号で
  • オンライン英会話ではお気に入りの先生をまず見つける
  • 英語は英語で勉強しよう！

また、英語学習にオススメの参考書として次のようなものが紹介されました。

補足で、htj_fusionさんからおすすめアプリとしてHelloTalkの名前が挙がりました。

続いて新年LT大会。
まずレアジョブの山田さんから、「オンライン英会話のコツ」。これは、リアルタイムで講師につないでオンライン英会話を実演するという珍しいスタイルの発表で、どんな感じでレッスンが行われるのかがよくわかる、非常に素晴らしい発表でした。


こんな感じ。さすがレアジョブさん。

続いて@d_dateさんより、去年1年間の英語活動報告。海外カンファレンスに参加したり、OSSにコントリビュートしたり、try! Swift Conference の運営に携わったりと、積極的に実践的な活動をされていて、刺激になりました。やはりエンジニアたるもの、単に勉強するというだけに止まらず、こうありたいものだと思わされました。

3番目は私（@zinbe）より、仕事でポルトガルなどの海外に行くことになった経緯と、そのためにやった英語の勉強方法、実際に行ってみてどうだったのかなどを話させていただきました。

www.slideshare.net

できるだけ英語で頑張ろうと思ったのですが、無理でした（というかスライド作りも途中で諦めてる）。でもこのレベルでも海外で仕事できちゃうんだ、という勇気付けにはなったのではないかと思います。
そう、このレベルでも意外と何とかなっちゃうんです。だから恐るるに足らず！
今年は、"何とかなっちゃう"のレベルを脱却できるように頑張ります。

後半はワークショップの時間で、他人に目標を立ててもらう会 （通称タニモク会）の英語特化簡易版。自分が現在置かれている状況をパートナーに説明した上で、今年の目標を立ててもらう、というものです。
私の状況はLTでほぼ話した通りだったのですが、それにねぶたが趣味だということも加えて、次のような感じの目標をいただきました。

  • 一通りのストーリーを持った英語でのプレゼンを、しっかり準備をした上でやってみる
  • 英語で行われる、IT関連のオンライントレーニングコース（Courseraにみたいな）を履修する
  • 外国人旅行者向けの観光案内ボランティアなどに参加する

日常で英語を使う機会を増やさなといけないというのは常に感じていて、観光案内はちょっと気になっていたところでした。TELPみたいなサービスも出てきたしね。ねぶたのことなら案内できる自信があるんだけど。

そんな感じで、このところ下がりかけていたモチベーションがちょっと持ち直しました。頑張ろう。

#11 Creators Learning English Meetup に参加してきた話 #clem_jp

CLEM 英語

12月4日に開催された「#11 Creators Learning English Meetup」に参加してきました。
clem.connpass.com

Creators Learning English Meetup 略して「CLEM」は、英語を勉強中のエンジニアやデザイナーを対象としたMeetupで、ほぼ毎月開催されています。英語の勉強法やTipsを発表し合ったり、
英語で挨拶や会話をするなど、とにかく英語に触れる機会を増やそうという会で、Meetup以外に朝活などもやっているそうです。

今回は2つのワークショップとLT大会の、大きく分けて2部構成でした。
ワークショップで得られたポイントは以下のような感じ。

  • 相手の目をちゃんと見て話をする
  • 初対面の挨拶は、握手→簡単な自己紹介→質問や世間話など
    • Closed Qustion（Yes/Noで答えられる質問）よりも、Open Qustion（5W1Hを使うような質問）をした方が会話が続くのでおすすめ
  • 名刺交換は会話のあとに。相手の名刺の名前を読む。両手を添える必要はなし！

ちゃんと相手の目を見るということのトレーニングとして、相手の顔を見たままで（紙を見ずに）、相手の顔半分を描くというワークショップをやりました。
Open Qestionはいつも実践しようと頑張っているつもりですが、いざやろうとするとなかなか難しいよね。

LT大会は、偶然にも海外カンファレンス参加特集になりました。海外のカンファレンスに参加するにあたって、どうやって英語を勉強したか、というような話。ここでの知見をまとめると、

  • いろんな英語の勉強法
    • オンライン英会話
      • 習慣化することが大事（毎日の時間を決める、先生を固定する、など）
      • テンションが高い先生を選ぶとやりやすい
    • 英語オンリー飲み会
    • ネイティブスピーカーが一緒に参加しているとすごくいい
    • 日本語を使ったら罰ゲーム
    • YouTubeやPodcastで技術関連の英語コンテンツを視聴する
    • 単語集はDUOが最強
    • 単語帳アプリはAnkiがおすすめ
  • ちょっとした手土産を持っていくと、会話のきっかけになるのでおすすめ
  • 海外カンファレンスはパーティー。英語が不安とか言わず、どんどん行ってみた方がいい

こんな感じでしょうか。

私自身、英語はできないながら、海外カンファレンスへの参加回数だけはそこそこあるので、今回の話はあるあるネタが多くて楽しかったです。一方で、英語の勉強法については自分のやり方との違いなど、勉強になる部分がありました。とりあえずDUOやろうかな。

次回は1周年記念ということで、今年1年に出てきたTipsの総ざらいのようなことを計画しているそうです。

CreateJS勉強会 (第9回)に参加してきた話 #CreateJS #CCDojo

Adobe JavaScript

先日アドビ本社で行われた「CreateJS勉強会 （第9回）」に参加してきました。
CreateJS勉強会 (第9回) : ATND

CreateJSはHTML5 Canvasを使ってインタラクティブなコンテンツを作成できるフレームワークで、歴史的には2012年から開発がスタートしていますが、正式版となったのは2017年9月でつい最近のことです。このリリースに関連して開催された今回の勉強会は、

  • CreateJSの概要 + Animate CC 2018の新機能（ICS 池田さん @clockmaker）
  • CreateJS 1.0.0で何が変わったか（野中さん @FumioNonaka）
  • 我々はCreateJSをどう使うべきか？（世路庵 沖さん @448jp）

という豪華セッション3本立て。CreateJSを仕事で使う機会は全く皆無な私ですが、ついつい興味をそそられてしまったわけです。

この勉強会はAdobe Creative Cloud道場との共同開催にもなっていて、当日リアルタイム中継されたほか、現在も録画ビデオが見られます。なので、見逃した方はビデオを見ましょう。
https://blogs.adobe.com/creativestation/ccdojo-192-createjs

CreateJSの概要 + Animate CC 2018の新機能

まず池田さんのセッション。CreateJSとはどんなもので、どういう現場で使えるのかといった概要の紹介。

  • CreateJSの得意分野は、自由度の高いインタラクティブな表現。反面、ユーザインタフェースの作成などにはあまり向かない。
  • 類似技術としては、以下のようなものがある。
    • three.js - 3D表現
    • PixiJS - WebGLベースの2D表現
    • Snap.svg - SVGでのインタラクション
  • 一方で、CreateJSは2D表現のための技術で、Context2Dをベースとしている。
  • グランブルーファンタジーやニコニコ動画など、大手サービスでも広く採用されている。
  • なぜCreateJSか？→Flashプラットフォームとの親和性が高い。Animate CC（元Flash Professional）は公式にサポートしている。

続いて2017年10月にリリースされたAnimate CC 2018の新機能。

  • カメラの深度機能が追加された。レイヤーごとにZ深度を設定して、3Dのような奥行きが簡単に表現できるようになった。
  • Robert Penner式のイージング設定ができるようになった。
  • タイムラインに秒数が出せるようになった。
  • 既存アニメーションの絶対時間を保ったままフレームレートを変えられるようになった。
  • など。

CreateJSと他のフレームワークをどう使い分けたらいいのかがはっきり説明されていてわかりやすかったです。特にCreateJSの場合、Animate CCを使えばコードを書けなくてもタイムラインベースでアニメーションの作成ができるので、これは他のフレームワークにはない強みと言えそうです。
Animate CC自体も、Flashコンテンツの作成ツールという枠組みはとうの昔に捨て去っていて、HTML5を含むマルチプラットフォームなアニメーション作成ツールとして地道に進化を続けています。この辺りはもっと高く評価されてもいいと思っています。

CreateJS 1.0.0で何が変わったか

次に、野中さんによるCreateJS 1.0.0での変更点の解説。発表資料は下記に公開されているので、そちらを参照してください。コード例がたくさん出ています。
CreateJS 1.0.0で何が変わったか | CreateJS Workshop vol.09
ざっくり概要を挙げると、

  • StageGLクラスでWebGLが使えるようになった。
  • 基本的には、StageクラスをStageGLクラスに置き換えるだけでWebGLにできる
  • ただし、若干の注意が必要。たとえば、WebGLはラスターグラフィックス前提なので、ベクター形式であるShapeはそのままでは描画できず、キャッシュする必要がある、など。
  • CodePenにCreateJSアカウントが設けられて、CreateJSの作例が掲載されている。
  • TweenJS 1.0.0で、プラグインモデルが大幅に改められた。
  • PreloadJSライブラリでフォントローダー機能が追加された。フォントファイルやCSS定義およびCSSパスを読み込んでフォントを設定できる。Webフォントを使いたい場合などに便利。

CreateJS 1.0.0では、やはりWebGLが使えるようになったことが最もインパクトが大きいでしょうか。これによって、パーティクルのような複雑な表現を高速に処理できるようになりました。3万個のパーティクルをスムーズに描画するデモは、（残像効果を使って多少視覚的な水増しをしているとはいえ）、なかなか衝撃的でした。

我々はCreateJSをどう使うべきか？

休憩を挟んで、最後は沖さんによるセッション。発表資料は下記に公開されています。
我々はCreateJSをどう使うべきか？ // Speaker Deck

  • アニメーションの持つ力とは何か？
  • アニメーションとそうでないものを分けるものは、"時間軸"。
    • 関連して、アニメーションの原点とされるフェナキストスコープを紹介。
    • フェナキストスコープとは、ゾートロープに先駆けて登場したもので、ゾートロープと同じように回転盤と覗き穴を使って絵をアニメーションさせるというもの。
    • フェナキストスコープ - Wikipedia
  • アニメーションを使えば、そこには本来ないはずのものを作り出すことができる（（静止画なのに動いている、とか）
  • Webにおけるアニメーションの目的とは何か？→フィードバック、世界観の演出、ストーリーの伝達など。
  • アニメーションでしか使えられない情報がある
    • 雨量計の内部構造の解説の例。文章や静止画での説明だと要領を得ないが、アニメーションなら一発でイメージが掴める。
  • Webではさまざまなアニメーション技術が使える。DOM、CSS3、Canvas、GIF、videoなど。
  • 現在の主流は、コード思考のアニメーション。JavaScriptでアニメーションのコードを書く。
  • CreateJSは、コード思考で使うこともできるが、Animate CCを使ってタイムライン思考でアニメーションを作ることもできる。これが最大の強み。
  • コード思考も大事だが、タイムライン思考のアニメーションにつか伝えられないこともある

このセッション、タイトルはCreateJSとなっていますが、実際の内容はWebアニメーション全般に関わる興味深いセッションでした。
コード思考とタイムライン思考、どちらにも得手不得手があります。どんなどちらか一方ではなく、シーンによって適したものを選択できて、両側からアプローチできるということが大切ですね。

f:id:zinbe:20171208141247p:plain