AMP のスコープ

• ページリフローの低減
  • 画像サイズ指定の厳密化とか
• ブロッキングスクリプトを強制的に不許可
• 遅くなりそうな機能はとにかくナシ

https://www.ampproject.org/docs/get_started/technical_overview.html 見ると、別に AMP だからできるのだ！っていう機能はない。

AMPには2つの要素が同居している

1. コンテンツ自体の表示の高速化 (レンダリング負荷の軽減など)
2. コンテンツをダウンロードしはじめるまでの高速化 (CDN配信とか)

後者はつまり AMP を使っている限り悪意のあるスクリプトのあるページにはなりませんよという保証。

AMP のメリット

• 検索流入からの表示が早くなる
  • Google (など) にキャッシュされてCDN経由で配信される

AMP のデメリット

• 普通にロードする限りではたいして早くならない
  • ないし真の static コンテンツに対して AMP JSの実行時間分損をする
• 専用のHTML・CSSを書く必要がある
  • かなり制約が多い。CSS にも !important はダメとか細かい制約がある
• マークアップ側にレイアウトという概念がある
  • は?
• AMP JS で提供される以外の機能は使えない

AMPのメリットはメリットなのか?

検索流入に特化するならメリットになる。Google の CDN 経由で配信されるのが大きい。

しかし、似たような構成 (特にいえばJS無効の) のページのロード時間ってそもそも遅くない。コネクションにかかる時間分の速度向上のために、わざわざ特殊なマークアップで書くメリットはあるだろうか。

AMP は標準になりえるか?

結局 AMP がやってることって「JSなしのページのキャッシュ・プリロード」+「オレサマのJSなら特別に実行してやっても良いぞ」みたいな感じなので、そのために変なカスタムエレメントとか入れてんの? レイアウトまわりにCSS以外の概念入れんの?? という疑念が晴れない。

元々 Cache-Control: public という便利なのがあるのだから、その場合はキャッシュ済みのを CDN から配信するのを優先したらいいだけじゃないか? 既存技術の延長でなんとかできる範囲ではなかったのだろうか? 任意スクリプトってのが最大の問題だけど、AMPならオッケーってのはどうなのか?

ベンダープリフィックスつきのボイラープレートをいちいち書かされるのも意味不明。新しいベンダー出てきたらどうすんの?

カスタムエレメントも、amp-twitter とか amp-facebook とか、どういうつもりで追加してるのかわからないエレメントがたくさんある。いろんなサービスが「カスタムエレメントを定義してくれ」といったら対応コードが無限に増えていくんでしょうか。amp-ad も、メジャーな広告ネットワークをサポートしているけど、そもそもサポートする広告ネットワークを指定されてるのが気にくわない。いろんな無限のアドネットワークがが「ウチにも対応してくれ」といったら対応コードが無限に増えていくんでしょうか。

と、だんだんイライラしてきたのでやめて、別の見方をしてみることにします。

JS フレームワーク AMP

• Google でインデックスされることが保証されてる
• 画像の遅延ロードとかはSEO的にどうなの？という不安があったがAMPでは保証される
• なんとなく便利なインターフェイスがついてて、パフォーマンスが良いことが保証されている

あたりを考えると、変なJSライブラリを使うよりはマシそうな雰囲気があります。この捉えかたで多少心が落ち着きました。

「AMP とは準 static ページを作るためのJSフレームワーク」であって、Google が対応済みという大きなメリットがある! 万歳!!! Google が対応済みってのがとにかく最高!!!

前提

どのOSでもレンダリングは遅くて、多少乱れるので、OS X だから遅いのかな〜とか考える必要はない。

OS X 固有の話

• pcbnew / eeschema は一定の大きさまでウィンドウを広げると刺さります
  • GPU のメモリとかに左右されるかもしれません
  • 自分の環境で「ギリギリまで広げられる範囲」を見つける必要があります
  • Retina だとちょっと広げただけで刺さるので、Retina ではない外部ディスプレイを使いましょう。内蔵Retina に限らず、ppi 高いディスプレイだと使いにくいのでダメです……
• pcbnew を起動したときOpenGL ビューの初期化に失敗します
  • 気にしないで起動してから OpenGL ビューに変えれば普通に動きます
  • または標準ビューにしましょう
• pcbnew はズームレベルを広げすぎる(俯瞰にしすぎる)と刺さります
  • うっかりマウスホイールを回転しすぎないようにしましょう
  • これが一番困ります

eeschema / pcbnew 共通の罠

• ホイール使うとポインタが飛ぶ!!
  • 「設定」から「拡大縮小時にカーソルを中心へ移動」のチェックを外します
• 中クリックしながらドラッグでパンする機能が動かない
  • 「設定」から「画面のパンにマウスの中ボタンを使用」にチェックを入れます
  • 一回ウィンドウの内側を左クリックすると動いたりします
• フットプリントの関連づけに自分の部品がでない
  • 既存ライブラリにある部品名とかぶっていると出ないことがあります (優先順位による)

pcbnew の罠

• 描画モードによって機能が変わります
  • 部品を一括で並べかえる機能はデフォルトのビューじゃないと使えません
  • おしのけ配線は OpenGL のビューじゃないと使えません
• 部品を一括で並べかえる機能は基板外形がないと機能しません
  • チュートリアル的なPDFだと外形なしでやってる風なんですが、できません
• 配線の undo できない
  • 配線ツールを選択している状態だと undo できないので ESC 連打して通常の選択ツールにします。するとなんと undo できます。
• 全配線の ripup
  • 標準描画モードにして、全体を選択する。このとき選択対象にワイヤーとviaを入れる。選択されたら削除する
• 配線を維持してコンポーネントの移動
  • OpenGL ビューだとできません
  • 標準ビューだと回路図エディタと同様に G でできる
• ここにさらに追記されます

前提

どのOSでもレンダリングは遅くて、多少乱れるので、OS X だから遅いのかな〜とか考える必要はない。

OS X 固有の話

• pcbnew / eeschema は一定の大きさまでウィンドウを広げると刺さります
  • GPU のメモリとかに左右されるかもしれません
  • 自分の環境で「ギリギリまで広げられる範囲」を見つける必要があります
  • Retina だとちょっと広げただけで刺さるので、Retina ではない外部ディスプレイを使いましょう。内蔵Retina に限らず、ppi 高いディスプレイだと使いにくいのでダメです……
• pcbnew を起動したときOpenGL ビューの初期化に失敗します
  • 気にしないで起動してから OpenGL ビューに変えれば普通に動きます
  • または標準ビューにしましょう
• pcbnew はズームレベルを広げすぎる(俯瞰にしすぎる)と刺さります
  • うっかりマウスホイールを回転しすぎないようにしましょう
  • これが一番困ります

eeschema / pcbnew 共通の罠

• ホイール使うとポインタが飛ぶ!!
  • 「設定」から「拡大縮小時にカーソルを中心へ移動」のチェックを外します
• 中クリックしながらドラッグでパンする機能が動かない
  • 「設定」から「画面のパンにマウスの中ボタンを使用」にチェックを入れます
  • 一回ウィンドウの内側を左クリックすると動いたりします
• フットプリントの関連づけに自分の部品がでない
  • 既存ライブラリにある部品名とかぶっていると出ないことがあります (優先順位による)

pcbnew の罠

• 描画モードによって機能が変わります
  • 部品を一括で並べかえる機能はデフォルトのビューじゃないと使えません
  • おしのけ配線は OpenGL のビューじゃないと使えません
• 部品を一括で並べかえる機能は基板外形がないと機能しません
  • チュートリアル的なPDFだと外形なしでやってる風なんですが、できません
• 配線の undo できない
  • 配線ツールを選択している状態だと undo できないので ESC 連打して通常の選択ツールにします。するとなんと undo できます。
• 全配線の ripup
  • 標準描画モードにして、全体を選択する。このとき選択対象にワイヤーとviaを入れる。選択されたら削除する
• 配線を維持してコンポーネントの移動
  • OpenGL ビューだとできません
  • 標準ビューだと回路図エディタと同様に G でできる
• ここにさらに追記されます

背景

KiCAD は1つのプロジェクトにつき1つのボードしか作れない。小さな基板であれば1つの基板にVカットを入れるでいいが、どうしても複数ボードとして設計したい場合に困る。

複数プロジェクトにして回路図をわけると、今度はこの回路図間でコピペが動かないという問題が発生する。KiCAD はプロジェクト間のブロックコピー・ペーストができない。

考えたやりかた

$ cp Root.sch ModuleA.sch
$ cp Root-cache.lib ModuleA-cache.lib

結果的にできる構造

Root.sch
  _module_a.sch
  _module_b.sch
 
ModuleA.sch
  _module_a.sch

ModuleB.sch
  _module_b.sch

それぞれキャメルケースのファイル名の回路図がルート回路図で、_ から始まるスネークケースのファイル名の回路図が階層化回路図になっていて、上記のような参照関係になる。

こうすると、Root.sch で全体を見ながら各階層化回路図に変更をかけたことが、個々のモジュール用回路図にも反映される。ネットリストはモジュールごとの回路図から生成するので、これでボードごとのネットリスト出力ができる (Root.sch に対応する kicad_pcb ファイルは作らない)。

ワークフロー

基本的に Root.sch 開いた状態で階層化回路図を編集する。

これで保存をして閉じて、ModuleA.sch を開くと、編集が反映された状態になっている。この状態でフットプリントの関連付け、及びネットリスト出力をして pcbnew すると、該当する基板の部品だけを出せる。

ネットリスト・pcbnew した後は以下のようになる

Root.sch はあくまで全体管理用なのでネットリストとかは出さない。

.sch 間のコピペ

コピペ対象の回路図が階層化回路図になっていなければならない。なので、全体を見ながらモジュールの構成をしたいときは Root.sch を開いてそれぞれコピペ(ブロックを保存)することになる。

他に方法はないのか

わかりません。普通に全部を吐きだしたネットリストから、うまいこと各階層シートごとのネットリストだけ分離するようなスクリプトを書けばもっと楽に管理できるかもしれません。

標準のネットリストファイルはS式なんですが、ちょっと見た感じだと簡単にはできない気がしました。