SPA の設計とアーキテクチャ Chapter 1(SPA Design and Architecture ch1)
Manning の “SPA Design and Architecture”、第1章のまとめです。
- Manning[http://www.manning.com/scott2/]
1. シングルページアプリケーションとは何か
- ウェブアプリ開発者の長年の夢は、デスクトップネイティブアプリに迫ること。
- SPAも同じ。JS、HTML、CSSだけでネイティブのようなアプリを作りたい。
- 2000年代初頭のAJAXから始まった。もともとはデータを非同期に送受信するためのIEのActiveXコントロールだった。それがXMLHttpRequestとして、メジャーなブラウザで採用された。
- ユーザ操作を止めることなくリクエストを出せるAJAXと、動的にDOMを変更できるJS、そして動的にページのスタイルを変えられるCSSによって、AJAXはウェブ開発の最前線となった。
- ページ内の操作だったAJAXをアプリ全体に適用したのがSPA。
- 発展途上の技術のため、様々なやり方があり、様々なライブラリがある。自分のSPAプロジェクトにとって何が最適なのかを見極めるのは難しい。
- SPAについて広い知識を持てば、正しい実装にたどり着きやすい。
- 本書では MV* フレームワークに限定して解説しているが、React や Web Components のような別のアプローチもある。
Apache の Order Deny,Allow と Order Allow,Deny
何回設定しても覚えられない Apache の Order Deny,Allow と Order Allow,Deny の意味。
Apache 2.4 からは RequireAll, RequreAny, RequireNone という新しいディレクティブが 導入されてわかりやすくなったみたい。 http://httpd.apache.org/docs/trunk/mod/mod_authz_core.html#requireall
でも今日は 2.2 までの古い Apache のお話。
デフォルトAllow
Order Deny,Allow
公式の説明
First, all Deny directives are evaluated; if any match, the request is denied unless it also matches an Allow directive. Any requests which do not match any Allow or Deny directives are permitted.
Deny ディレクティブが Allow ディレクティブの前に評価されます。アクセスはデフォルトで許可されます。Deny ディレクティブに合わないか、Allow ディレクティブに合うクライアントはアクセスを許可されます。
Allow にも Deny にもマッチしないリクエストは許可される。つまりデフォルトで許可の設定。追加で拒否の設定をすることもできる。
最初にDenyディレクティブが評価されて、そこでマッチしなければ許可。次に、Denyに合致したリクエストのうち、Allowに合致しないものが拒否される。Denyの効果をAllowで打ち消せる。だから、丸ごと拒否しておいて、一部だけ許可するという用途に使える。丸ごと拒否の Deny from all と一緒に使うことが多い。
Rails + Passenger + Apache で一部のURLのみBasic認証をはずす
以下の3つの設定で可能。
- SetEnvIf で特定のURLに、例えば noauth=1 という環境変数を割り当てる。
- Allow from env=noauth
- Satisfy any
<VirtualHost *:80>
ServerName example.com
DocumentRoot /proj/example.com/current/public
RailsEnv production
SetEnvIf Request_URI ^/$ noauth=1
SetEnvIf Request_URI ^/some-assets/ noauth=1
<Location />
Options -MultiViews
Order Deny,Allow
Deny from all
Satisfy any
Allow from env=noauth
AuthUserFile /etc/httpd/etc/passwd
AuthName "admin"
AuthType Basic
Require valid-user
</Location>
...
ツブヤ大学「日本のMakeはどこに向かうのか?」 at DMM.make AKIBA
終わるのが惜しくなるような、惹きつけられるトークセッションでした。行ってよかった。もう一時間、聞いていたかった。
ツブヤ大学「日本のMakeはどこに向かうのか?」 2015.1.27 at DMM.make AKIBA http://peatix.com/event/69062
3Dプリンタにはいろんな利点があるけど、何よりも、データだけ流通させられるから関税がかからないという利点がある。(遠藤さん)
Maker って、昔のシンガーソングライターみたいなもの。歌詞作って、曲作って、歌って。分業せずに、なんでもできる。今はそれが普通になった。maker という言葉も、20年後には溶け込んで、当たり前になる。
3Dプリンタで、いびつなプラスチックが存在できるようになった。造形に失敗してゴミ箱に捨てたやつを友人が拾って「これはいいっ」とか。お前は千利休か!(土佐さん)
3Dプリンタでプラスチックが制御できるようになったのは画期的。それまではフィギュア造形のごとく一つひとつ手で流し込むか、数百万かけて金型をつくらないとできなかった。(土佐さん)
プラスチックが制御できるようになって嬉しいのは、ここにいる人たちだけ。家庭の主婦は喜ばない。素材が大事。セラミックが本命。自分の子供にぴったりのサイズの食器を作れるようじゃないと。(小笠原さん)
明和電機は父親が経営していた会社の名前。小学六年生の時に倒産した。倒産直前は悲惨。自分も可変抵抗器の製造をさせられた。嫌で逃げ出したり。自分は芸術家になりたかった。芸術家と町工場が合わさってできたのが今の明和電機。(土佐さん)
いろんな背景の人が集まると、モノそのもので採算を取らなくても、後でオプションやネットで回収するという案も出てくる。積み上げ式コストでなくていい。Celevoにも、家電メーカー出身者に加えて、おもちゃメーカー出身者が入った。すると作り方が違う。(小笠原さん)
make界隈はバブる。そう断言してしまう。(小笠原さん)← 大事なことなので2回言った
iPhoneケースを作るようになったのはたまたま。元はTシャツ屋だった。Tシャツ業界は夏と冬で需要が格段に違う。事業の継続が難しくなって、何とかしなきゃと、iPhoneケースに手を出した。ケースは岐阜で作っている。岐阜のものづくりはすごい。ものづくりの人はシャイ。そういう人たちをだまくらかして(=協力してもらって)15万円のぼったくり(=高級)iPhoneケースを作った。航空機に使われる超々ジュラルミンを高精度に加工。(後藤さん)
ECがすごいといっても、ネットで流通するTシャツは高々5%程度。不動産とか、実店舗とかの、リアルの方が圧倒的に大きい。(後藤さん)
DMMがやらなければ3Dプリンタブームはもう終わっていたかもしれない。昨年タイで3Dプリンタがすごく流行っているというから展示会に行ったけど、どこにもなかった。小資本の出力サービスは続けられない。大手が大々的にやるから谷を超えられる。(原さん)
2年ほどまえにIoTという言葉が出た。乗ってみようと思いDMM に企画を持ち込んだ。まずは3D出力サービス。次にものづくりログ。そうしてDMM はメイカーの味方という雰囲気を作る。そして .make AKIBA。ここまでは企画書の筋書き通り。(小笠原さん)
モノを作ると、最終的には BtoB で流通させる必要がある。Bへの営業や出荷などの雑務はしんどい。やりたくない maker も多い。そういうところをサポートしたい。(原さん)
DMM.make AKIBA の椅子やテーブルは造園屋をやっている弟が作った。スチームパンクっぽいやつを、と頼んだ。スチームパンクだと行き過ぎ。「っぽい」でやりたいことが通じるのは、弟との数十年の付き合いがあるから。床材も、アメリカで古い工場を解体するという話を聞いて、コンテナで買い付けに行ってもらったもの。(小笠原さん)
事業としてものづくりをする maker と、日曜大工的 maker がいる。議論する上でそこは区別する必要がある。DMM.make はその真ん中あたりを狙っている。(小笠原さん)
関連記事
日本のMakeはどこに向かうのか?【DMM.make AKIBAで取材しました】 http://blog.sideriver.com/flick/2015/01/makedmmmake-aki-3846.html
Pepperエンターテイメントロボットアプリの作り方
よしもと所属の、髙橋征資さんとシンキョンホンさんによる、エンタメに特化したものづくりを行うエンタメーカーユニット、バイバイワールドによる Pepper エンターテイメントロボットアプリの作り方ワークショップに参加してきました。バイバイワールドは、Hello World の先を行くユニットです(なんのこっちゃ?)。2013年1月から Pepperアプリの開発を始め、ちょうど2年経ちます。その、Pepperアプリの第一人者達が、惜しげもなくノウハウをさらしてくれました。
・パフォーマンスとインタラクションという概念。 ・リズムに乗せて動かすのは難しい。動かすたびにタイミングがずれることがある。 ・ビデオはMP4でなるべくサイズが小さくなるようにしている。1280x800。Pepper のタブレットは解像度が高くないので、これくらいでも違和感がない。音は無し。 ・音素材はOGG。MP3くらい軽い上にChoregrapheの中でも鳴らせる。 ・ボックスを分けてダンスを作ると、ボックス間に0.何秒のレイテンシが生じる。 ・ボックス間のレイテンシはPepperのバージョンによって差がある。 ・ダンスのような長いものは一個のタイムラインにする。テーマソングは2分、4000フレームくらい。 ・キリのいい数を一拍とすると作りやすい。テーマソングは25フレームが一拍。 ・FPSを変更する。通常は25。30にすると、少し速くなる。 ・既存の曲に合わせる場合、FPSを調整してできるだけ近づけた上で、最後は曲の速度を調整する。キリのいい数字を音楽の一拍目にしたい。 ・タイムラインが3000フレームくらいなると、動作レイヤが重くなる。モーションレイヤはテンポをキープしてくれる。 ・パフォーマンス系は、常にコンテを描く。 ・台本を読み込んでコンテを描く。 ・歌系は五線譜のタイムフレーム版みたいなのを作る。時間軸のある絵コンテ。 ・Pepperを頷かせる動作を大量に配置したタイムフレームを用意して、同時にピッピッピッピと音を鳴らせる。頷きに手などの動作を入れれば絶対に合う。 ・カーブで見たときに、極力きれいな動きになるようにしている。ダンスなので。 ・間合いがちょっと狂うだけで、相当気持ち悪い。 ・顔認識に失敗しても、相手は演技しているので、ランダムに表情の点数を付けている。 ・終わった後に表情を認識すると、落ち着いた後なので、常に認識させて最もいい値を採用している。 ・逆光だと顔を認識しづらい。子供も認識しづらい。背が低くカメラに収まらない、声が小さい。目線を下げると、かなり見つけやすい。 ・子供相手のワークショップをやるときは、そもそも声が小さく認識できないことが多い。Pepperのマイクが上についているので、上方向からの声の方が認識しやすい。顔を落とし、腰を落としても厳しいので、タッチパネルでも先に進めるように作った。 ・音は、二文字、三文字は聞き取りにくい。少ない文字だと誤認識が増える。イントネーションのある言葉の方が認識しやすい。架空の言葉は認識しづらい。 ・音楽を流すと、認識率が下がると思う。音は無い方がいい。 ・Pepperとしゃべるにはコツがある。ソフトウェア的に、マイクに指向性を持たせている。目の前から話すと認識率が上がる。 ・「いいえ」は使わないようにしている。「やりますか?」「いいえ」よりも「やりますか?」「いいよ」と人は答えがち。「いいえ」は「いいよ」などと混同される。 ・感情認識ボックスは無い。Pythonで作る。表情認識と音声認識から配列を受け取って、分解して作っている。 ・表情認識の失敗要因:人がいない、顔が見つけられない、解像度が低い。 ・この例はゲームなので、深層心理までは追わない。音声は本当の感情を取れるようになっているが、それをゲームに使うとみな点数を取れなくなるので、表情7、音声3にした。 ・ロボットUIはテクノロジーの進化に大きく依存。ロボットUXはテクノロジーだけでは実現できない。 ・紙でプランを作る。それをビヘイビア+システムに落とす。 ・ピッチ132、スピード100、テキスト「おハヨーゴザイマーアーッ酢」、自作のおじぎ。テクノロジーじゃない。努力。 ・早口言葉1億倍は、音楽編集ソフトで作っている。 ・Pepperはお役立ちロボットではない。その場を和ませて、楽しませて終わらせる。ロボットであるとともに、ゲーム機的な側面もある。 ・最初のころは1アプリ1月で作っていた。最近は、2〜3分のパフォーマンスなら3、4日で作る。ライブラリがかなり充実してきている。インタラクティブなアプリは1ヶ月、少なくとも2〜3週間は欲しい。 ・バグもある。これをやると落ちやすい、というのがある。 ・モーターが熱くなって動かなくなることがある。 ・実機を触って特性を把握した上で、できるだけバーチャルで作る方が効率がいい。 ・始めて作った5分くらいのアプリは、2人がかりで1ヶ月。SBショップなどで動かす場合は、危なくないように、などの配慮が必要。 ・1次審査はストーリー、コンセプト重視。モーションは、後で作り込めばいい。 ・「わたしはxxです」は「わたしは、xxです」と発音される。間を入れたくない場合はカタカナにするといいことが多い。 ・「スマホ」は「ス↑マホ」と発音されるので、全部漢字にしている。カタカナにすると平たく読む。経験としては。 ・タグを使うこともできるが、多用すると初音ミク状態、ロボットボイスになる。 ・よくあるバグ。コピーとかできなくなる。SDKを再起動すれば直る。 ・Qichat の日本語で、アスタリスクは使わないほうがいいとアルデバランのエンジニアが言っていた。 ・Sayボックスで歌わせるには、がんばる。あるいは、録音したものを流す。自分で歌ったものを流しても、結構わからない。ああ、歌うとこんな声なんだな、と受け取られる。そのうちボーカロイドPepperが出る。 ・Say の調整は本当に時間がかかる。吉本ロボット研究所では専用の部隊がいる。 ・今は、一人で作るというのはほぼなくなっている。 ・タブレットも、ローカルでウェブページを作ってからPepperで試すほうが効率がいい。 ・Pepperタブレットのキーボードは隠されている。ソフトウェアキーボードは出せない。JSで書くしかない。 ・JSからもSayできる。 ・既知のバグ:タブレットがリフレッシュされない。激しいことはやらないほうがいい。最低でも50msくらいあける、余裕をみて200ms空ける。タブレットが落ちる。
【2015/01/17 16:00〜18:00 @3331 Arts Chiyoda】