トップ 追記

KeN's GNU/Linux Diary


2017年12月17日

_ [computer] OpenBlocks AX3のストレージ交換

Debianをインストールして基幹に使っているOpenBlocks AX3のストレージが不穏なメッセージを出し始めた。

 ata1.00: exception Emask 0x0 SAct 0x6000 SErr 0x0 action 0x6 frozen
 ata1.00: failed command: WRITE FPDMA QUEUED
 ata1.00: cmd 61/08:68:39:1d:00/00:00:00:00:00/40 tag 13 ncq 4096 out
          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
 ata1.00: status: { DRDY }

smartctl -x /dev/sdaで見てもPRE-FAILなヤバそうなレポートが出ており、緊急にストレージ交換をする必要がある。

AX3のストレージ付き製品を使用しているので、SATAで2.5インチあるいはハーフスリムであれば交換はできるようだった。ただ、ハーフスリムのものはもう各社とも撤退ぎみで、ぷらっとオンラインでも納期応相談という状態のため、若干放熱に心配はあるが2.5インチでいいだろうと踏んでサンディスクの256GB SSDを調達した(今はメモリ系は品薄で高いねぇ……)。

いくつかこちらの事情でハマりどころはあったものの、AX3のOSの仕掛けがよくできていて実際の停止時間は極めて短く済ませることができた。

交換ストレージ準備

新しいSSDにどう現状のOS状態をコピーするかだが、AX3のDebianはフラッシュメモリにブートローダとカーネル、最低限の基本構成が書き込まれており、外部ストレージは/.rwとしてマウントされて、aufsで/etcや/usr等の各システムがオーバレイしている仕掛けになっている。フラッシュメモリが壊れたら元も子もないが、外部ストレージのほうは/.rwの内容をコピーすればよく、ブートローダやカーネルといった起動にあたってちょっと面倒くさい部分を考えなくていい。

手元にRATOCのリムーバブルケース+eSATA・USBの外ケースを持っていたので、これに新SSDを3.5インチマウントアダプタ(裸族のインナー CRIN2535)を使って接続する。ミリネジも買っておいたのだが、インナーのほうに付いていた。

あとはこれをAX3のeSATAにつなげて……としたのだが、AX3のeSATAコントローラはつなげると一応反応らしきものはするものの、OSを再起動しないとディスクを扱えないようだ(scanもできなかった)。元ストレージがいつ天に召されるかわからない中での再起動は怖いので、USBにして接続。今度は普通に/dev/sdbとして見えたので、cfdiskで/dev/sdb1をLinux形式で作成し、「mkfs.ext4 /dev/sdb1」でext4形式にする。

あとは「mount /dev/sdb1 /media」のように適当にマウントし、「rsync -av /.rw/* /media/」で現状をコピー。16GBしかなかったので一瞬で終わった。

最後にAX3固有だがDebianのシステムパーティションとして見えるように、「e2label /dev/sdb1 DEBIAN」でDEBIANラベルを付けておく。「umount /dev/sdb1」で解除し、交換の日に備えて社内外に連絡等の諸々の準備を行う。

ターミナル

AX3のコンソールはRS-232Cのシリアルターミナルであり、これまではLinuxデスクトップ+ELECOMのUC-SGTでモニタリングをしていた。その後、機器群の整理をしてAX3の近くからLinuxデスクトップがなくなって、手元のラップトップは皆macにしてしまった(デスクトップは今でもどれもDebianだけど)ため、UC-SGTがmacではうまく認識されなくて困る、という事実に思い至る。

鯨井さんの記事を見ながらやってみたのだが、タイミングが悪いのかOS X 10.10で署名の問題を解決できず(古いのを読ませてから新しい設定を入れる、というのも試してはみた)。

あまりこれに拘泥しているのも時間が惜しいので、https://www.mac-usb-serial.com/ の検査でサポートされていることを確認して、7.90ユーロでドライバを購入。インストールして接続してみたところ、問題なく/dev/以下にttyデバイスファイルができた。

cuやscreenはどうも挙動が変だったので、homebrewでminicomをインストールし、「minicom -D /dev/ttyデバイスファイル」で接続。AX3のDebianのログインプロンプトが表示され、普通にコンソールとして操作できる。

ストレージ交換

左右4つの小ネジ、後ろのネジを外し、ツメを押しながら上に引き上げる。ツメがちょっと外しずらかった。引き上げるときに変にナナメに力を加えるとSATAのライザーカードが折れかねないので注意。

photo

本体からライザーカードを抜き取り、ディスクマウンタに付いているハーフスリムSSD基盤を取り外す。剥き出し基盤なのでスペーサーが付けられており、この取り外しにはかなり小さな精密ドライバが必要。mSATA化の方向に行く中でハーフスリムがどれだけ入手性があるのかはともかく、なくさないように一式まとめて保存しておく。

2.5インチSSDのほうは特にスペーサーはいらないので、普通にネジで取り付ける。あとは本体にライザーカードごと刺し直し、蓋をして交換は終了。

再起動

交換してシリアルから送られてくるコンソールを見ながら緊張と祈りの再起動……特に何ということもなく、あっさり起動して必要なサービスが復活した。すばらしい。

放熱についても、冬のせいもあるかもしれないが以前より上昇しているという傾向も見られなかった。

さて、16GBから256GBになると、いろいろと欲が出てもくるが、あまり無茶なことをすると基幹に影響が出るので、あくまでもネットワーク監視系特化で何か考えよう。


2017年12月08日

_ [life] 皆さまからいただいた原稿はこう加工されますというお話

昔からお世話になっているモーリさんから編集とライティングにまつわるアレコレAdvent Calendar 2017に書け、という有形無形のプレッシャーが……昨日のアドベントカレンダーご担当はmktredwellさんでした。

本日は某制作プロダクション会社の編集者が、著者さまや訳者さまからいただいた原稿をどう加工して紙面化しているのかを記してみます。編集者の方々や、執筆・翻訳をして出版社から出版しよう、という方にも参考になれば幸いです。

背景として、私自身は基本的に企画やライティングはせず、クライアントである版元さま(=出版社。ほぼ技術書系)が企画して著者さま・訳者さまが執筆された原稿を、版元さまとともに編集・校正し、紙面化して確認をいただき、最終的に印刷所にお渡しする、という編集のお仕事をしています(企画やライティングのお仕事のほうが多い同僚もいます)。

また、OSS開発者兼技術書執筆者でもあり、自分の執筆と仕事に欠かせない環境としてRe:VIEWというマークアップドキュメント変換システムの開発保守をずっと続けています(Re:VIEWのオリジナルは青木峰郎さんが作成されました)。このRe:VIEWと商業組版ソフトInDesignやフリーの組版ソフトLaTeXと組み合わせた「自動組版」を使って、紙面化の作業も兼務しています。

よって、最初にエクスキューズしておくと、ここからの内容はあくまでも某制作プロダクション会社の中の私のチームが採用している手順というだけで、弊社ですべての書籍をこうしているとか世間一般にこうである、というわけではないことにご注意ください。

イテレーション、イテレーション、イテレーション

世の中にはMicrosoft Word(以下Word)をはじめ、一太郎、Excel、PowerPoint、LaTeX、HTML、XML、Markdown、Sphinx、Re:VIEW、AsciiDocなど、たくさんのドキュメント形式があります。

著者さまや訳者さまがどのようなファイル形式で書かれるかは、ある程度版元さまから指示があるのが普通ですが、「なんでも書きやすいものでいいですよ」と放任になっていることもあります(実際それを加工しないといけないのは当方なんですけどね……)。

ともあれ、どのようなデータであろうと、最終的に紙(≒印刷所入稿用PDF)にする、というゴールには変わりありません。

 原稿→編集・校正→組版(紙面化)→紙面に編集・校正→組版反映(紙面化)→……→印刷所入稿

しかし、現ラムダノートの鹿野さんが「どんな原稿形式でもそれをマスターデータとしてがんばる」といったことを書かれていたかおっしゃっていた気がしますが、もし原稿がせっかくマークアップテキスト形式で書かれているのならば、私もなるべくそれを生かしてできるだけ制作終盤ギリギリまでそれを使っていきたいと常々考えています(Wordや一太郎のようなバイナリデータ原稿の場合はノーチャンスです)。つまり、

 原稿→編集・校正→組版(紙面化)→原稿修正→編集・校正→組版(紙面化)→……

のように、元原稿をあたかもソースコードのように捉え、編集・校正でコード修正、組版というコンパイルを経て紙面を生成するのを繰り返す(ここではイテレーションと呼びます)ことをしたいわけです。

実際のところそのようなイテレーション型の作り方ができるかどうかは、妥当な費用・時間、紙面デザイン、版元さまや著者さま・訳者さまの意向、といった要素に依存します。

まず、イテレーションを実現するには、一般的な「DTPオペレータが手作業で原稿を見ながらDTPソフトInDesign上で紙面要素に割り当てていき(手組み)、その後は紙(ゲラ)上で赤入れしたものを目視で反映していく=InDesign DTPデータが最新データで、原稿ファイルは乖離した遺物」というやり方ではなく、何らかの「自動組版」の仕組みが必要です。そのために、Re:VIEWあるいはXMLとInDesignを組み合わせたり、LaTeXを採用したりといった自動組版を設計し運用しています。しかし、これには紙面デザインやツールを調整する費用・時間のコストがかかります。ともかく初校を早く安く! という案件の場合には向きません。

また、Re:VIEW+InDesignにせよLaTeXにせよ、自動組版の場合はInDesignの手組みほどのレイアウトの自由度は提供できません(正確には、できなくはないけれども妥当なコストで実現しづらく、イテレーションもやりづらいものになります)。流し込み、ある程度の白スペース許容、紙面の後からの見た目の調整は最小限、といった制約がかかってきます。LaTeXを使った組版であれば完全な無人オペレーションのためいくらでもイテレーションはかけられるのですが、InDesignの自動組版の場合はどうしても人手が介在するので、コスト的に多くても3、4回以内のイテレーションとなるのが普通です。

そしてこれらを踏まえた上で、あとはどれだけこのようなやり方を採用したいかどうかの問題となります。結局著者さま・訳者さまなり、版元編集者さまなりが「原稿ソースで」文章校正を管理したいという欲求がないと、なかなかうまくは運びません。もちろん、そういった要望がなくても、イテレーション作業が妥当と社内で判断したときには、対外的には従来どおりゲラを出しつつ内部ではイテレーションを採用していることもあります(特にLaTeX採用の場合)。なお、初校以降から要素のデザイン調整が全面的に入る、制作終盤に本格的な編集を始める、といった傾向の著者さま・版元さまとは完全に相性が悪い仕組みなので、その場合は当初からこの方法は除外しています。

コウカンサレルモノ—テキストマークアップ形式

前述のとおり、ドキュメント形式は多種多様ですが、いただく原稿は概して次のいずれかの記法のどれかになろうかと思います。順序はおおむね私の業務範囲での案件数に沿っています。

  • Markdown(実際はGitHub Flavor)
  • Re:VIEW
  • Word
  • LaTeX
  • プレインテキスト+独自マーク記号
  • HTML
  • XML(DocBookまたは独自スキーマ)
  • AsciiDoc
  • Sphinx(reStructuredText)

いずれにせよ、手組みの場合は最終的に社内タグを付けたプレインテキスト、自動組版の場合はXMLまたはLaTeXに帰結する必要があります。社内タグは次のような感じです(Re:VIEWのtopbuilderで吐き出したものがほぼそれです)。

 ■H1■第4章 InDesignで自動DTP
 ◆→開始:リード←◆
 この章ではいよいよ、IDGXMLドキュメントをレイアウトに割り付け、…
 ◆→終了:リード←◆

 ■H2■4.1 作業方針
 前章で作成したXMLドキュメントをInDesignのレイアウトに割り付けるにあたり、…

 1       レイアウトテンプレートの△master.indd☆ファイルをInDesignで開き、…

変換の流れについて言葉で説明すると長くなるので、ドキュメント形式ごとにどうしているかを図示しましょう。

photo (クリックで拡大)

実際には変換したあとに変換漏れ対処や細かなカスタマイズのためのフィルタ(Rubyコードあるいはシェルスクリプト)を通すこともありますが、大きな流れとしてはこのようになっている、とお考えください。

登場しているツールのリンクも示しておきます。

Markdownは紙面表現には絶望的に機能が不足しているのですが、どうしてもこの形式を保持して自動組版と組み合わせたいという場合は、Re:VIEWタグがところどころに埋め込まれた原稿を作っていくことになります(以下は『サイバーセキュリティプログラミング』(オライリージャパン、2015)より)。

 パッケージがインストールされたら、7章で作成する@<hidx>{GitHub}GitHubを使ったトロ
 イの木馬をビルドするために使うモジュールをインストールできるか試してみよう。ター
 ミナルに次のコマンドを入力する。

 ```
 root@kali:~#: @<ttb>{pip install github3.py}
 ```

なお、Wordについては当初大いにこの記事に書き連ねたのですが、呪詛の言葉しか並ばずまったくクリスマスにそぐわないため、ばっさり削除しました。1つ申し上げておくと、いくらWordで見た目を綺麗に作っていただいても、(原稿の内容ではなく)Wordドキュメント形式に起因する諸々の問題で信頼性に疑義があるため、図にあるとおりまずプレインテキストにしてから編集します。Wordのスタイルを活用してツールによる初校作成を実装したのは、長大・要素膨大・多数の編集者が関与という条件のあった『できる大事典Excel VBA』(インプレス、2017)ほか数冊のシリーズくらいです。

最近はWord数式の含まれたものについてはPandoc、あるいはdocx2texの変換も試したりしていますが、まだ全幅の信頼を置くには至っていないため、たいていは手でLaTeX数式に置き換えています。

食ったパンの枚数だって数えられる—バージョン管理

手組みにせよ、イテレーションの自動組版にせよ、必ずバージョン管理サービスは利用します。ローカルマシンのストレージほど信用ならないものはないですし、私の勤務体系はだいぶフリーダムなので、オフィスでも自宅でも外出先でもデータに容易にアクセスし、履歴をたどれる必要があります。

著者さま・訳者さま・版元さまが供与されているならGitHub・GitLab・Backlog・GitBucketなど基本的にはどのサービスでもそれを使うようにしています。こちらから提供するときにはGitHubか自前で運用しているSubversionあるいはGitBucketです。

実際のところ、InDesignデータや図版データなどはバイナリで数十MB〜数百MBと大きく、リポジトリを圧迫する上に、そんな生データはDTPの担当者以外にとって無用の長物なため、gitとは相性がよくない傾向です。gitを使うプロジェクトでも、それらのデータのほうはSubversionで管理しています。Subversionは内部的にはディレクトリベースの管理構造なので、1つのリポジトリで編集側・DTP側のデータを完全に分割管理できます。

プログラムソースコードと違って原稿の場合は変更によって「壊れる」ことはなく、むしろ並行作業を長く続けると「競合の発生」と「マージの負担」のコストが大きくなるので、「1章を終えた」という大きな単位ではなく、たとえば「今日はここまでやった」といった小さな単位でコミットしています。GitHubでもブランチを切ってマージして……は省略してmasterに直接入れることもよくありますし、rebaseもほぼ使いません。

人の目、機械の目—編集作業

さて、原稿が揃い、バージョン管理にひとまずいろいろとつっこんで方針の策定ができたら原稿の編集加工作業に入ります。本編から逸れて長くなりそうなので手短かにしますが、おおむね以下のような作業が挙げられます。

  • 用字用語の統一(版元さまごとのルールあり)
  • 誤字・脱字の訂正
  • 読みにくい・意味がわかりづらい箇所の改変あるいは提案
  • 見出しレベルや採番の確認(Re:VIEWの場合はおおむね自動任せ)
  • 必要に応じて数式箇所のLaTeX記法化
  • 使用図版の整理、場合によってはラフ描き
  • 引用出典元の確認
  • (料金や時間次第ですが)動作検証

章立てや節・項にまたがって全面的に書き直すというタイプの編集者も世に多くいますが、私は文章というのは著者さまが責任を持つべき範囲であると考えます。段落を壊さない範囲での読みやすさ改善は積極的に施しますが、文章をごっそり入れ替えたり作文したりすることはあまりせず、「ここが不足しているのでは」「この説明順序だと変では」という提案をする程度に留めています。いずれにせよ、編集着手前に「どの程度直してよいか」を著者さまに確認することが重要です(「たとえ誤脱字であってもすべからくお伺いを立てるべし」というケースもあります!)。

エディタはDebian GNU/Linux+Emacs+SKK+編集作業専用モードを利用し続けています。モードとしてはjaspace.elをマイナーモードで取り込み、Re:VIEWの場合は自作のreview-mode.el、LaTeXの場合はauctex、それ以外のテキストの場合はhensyu-mode.el(自作)を使います。これらのモードを使う主な目的は、タグのショートカット入力とカラーリング(タグや、全角半角スペース/タブ、多種存在して混同しやすい二重引用符やハイフン/マイナスの記号を見分ける)です。フォントには等幅かつ可読性に優れたVLGothicを愛用しています。

photo (クリックで拡大)

単文節変換の日本語入力機構であるSKKを使っているのは1993年以来常用して慣れているからというのもありますし、版元さまごとに送り仮名や漢字の開きなどが異なるルールの下、常時3〜4冊の編集を抱える中で一般的な連文節変換型の日本語入力ではルールの違いに耐え得ないことに依ります。たとえば午前には「組込み」「例えば」を使うA社案件、午後には「組み込み」「たとえば」を使うB社案件、という具合です。

表記統一にはEmacs上でgrepやquery-replaceを多用するのは当然として、ある程度原稿整理の済んだところで日本語の表記揺れ発見に優れたJustRight!(ジャストシステム社、Windows版)での検査も行います。最近はRedPenに同種の機能が実装されつつあるので楽しみに見ています。

誤脱字についてはいちおうJustRight!、RedPen、あるいはtextlintなどの検査ツールはありますが、技術書に対してはキーワードなどに対するfalse alarmが多く、私はあまり使用していません。目視とありがちミスに対するgrep(1つ誤字を発見したら全体をgrepするなど)を使うことがほとんどです。

「読みにくさ」というのは極めて主観的な事柄なものの、私は文のリズムからそれを判断します。読点はブレス、句点はふーと息をつき、段落の終わりはそこで一旦休んで次の段落に備えるところです。リズムが崩れている、テンポが悪いと感じた箇所にはたいてい、誤脱字があったり、文が日本語としてそもそも破綻していたり、段落内の文が長すぎたり短すぎたり、他者の文章の借用であったりが潜んでいます。共著・共訳の場合は全体のタームやトーンをなるべく整える必要もあります。

「意味のわかりづらさ」もまた主観的判断ですが、本には想定読者というものを必ず立てるわけで、一度自分の持つ知識をリセットして、そのペルソナを被って読んでみます。すると、読者にとって「唐突にわけのわからない内容が出てきた」、あるいは「当たり前のことを長々と書くよりこっちを説明してほしい」といったことが見えてきます(とはいえ、自身の知識レベル以上には変身できませんが)。単著の場合は思い込みに過ぎるところはないか、共著の場合は互いで矛盾していたり同じことを繰り返したりしていないかも注意します。

レベル、採番確認は、マークアップシステムを利用するものなら変換結果をおおむね信頼できるのですが、プレインテキストやWordから変換したテキストのように、リテラルで番号が振られたものについては、grepやwcを使って検査するシェルスクリプトを作って確認しています。1行内で複数回登場するパターンへのチェックなど、より重厚な確認が必要な場合はRubyで書くこともあります。

 #!/bin/sh
 # check.sh: 見出しを一覧し、図・表・リストの一覧とそれぞれの総数をカウントする例
 # (番号と総数がずれていたら途中が抜けている可能性がある)
 egrep "■H" $*
 echo
 egrep "^図[1-9]" $*
 egrep "^図[1-9]" $* | wc -l
 echo
 egrep "^表[1-9]" $*
 egrep "^表[1-9]" $* | wc -l
 echo
 egrep "^リスト[1-9]" $*
 egrep "^リスト[1-9]" $* | wc -l

図版については書くとまた長くなるので割愛します。なお、「キャプチャに矢印や囲みを入れた結果の画像しかない」という原稿ですと、

 ◆→著者様:お手数ですが加工前の原図をご支給ください -編集者←◆

というコメントを初校で目にすることになるでしょう。

初校作成までにおおむね2〜3回程度見直した上で、組版に進みます。

組版周りについても、とても長くなるので割愛します(自動組版の詳細は『Re:VIEW+InDesign制作技法』電子版をご参照ください)。組んだPDFが正しくできているかを照合する(内校)のも編集の仕事の1つですが、本来この時点で文章はすでにほぼ完成している「はず」なので、紙面要素が正しく適用されているか、作図に間違いがないかといった箇所を重点的に確認します。

そうしてできあがったものがついに著者さま・訳者さま、版元さまに届き、晴れて校正を受けるときがやってきます。マークアップ原稿によるイテレーションを採用しているなら文字校正は直接元原稿の修正を、そうでなく手組みならゲラなりPDFなりに赤入れを、進めていくことになるでしょう。

まとめに代えて

いろいろと書き連ねてはみましたが、どのような原稿であろうとも、紙面化は可能です。ただし、標準的なテキストマークアップ形式で書いていただき、版元さまを通じてご要望を出していただければ、原稿をソースとしたイテレーションを導入できる見込みは高いです。特にRe:VIEW形式で書いていただけるといろいろと捗るので、ぜひ検討してみてください! ご質問にはTwitter @kmuto でお答えできることもあります。

以上、12月8日、こんな感じで私はいただいた原稿を編集加工して紙面化しています、というお話でした。良い週末を。明日のご担当は51_arayaさんです。

編集とライティングにまつわるアレコレAdvent Calendar 2017


2017年11月27日

_ [travel] 台北MRT駅から桃園空港行きMRT駅への移動ルート開拓

ハノイと台北にしばらく行っていたのだが、帰国便は桃園空港。新たに機場線MRTができて便利になったものの、ほかのMRTからの乗り継ぎは大変らしい(往路は空港からバスで来た)。

ということで、帰国前日にソロ行動で下見をしてきた。

MRT板南線を出て標識どおりに歩いてみたところ、大回り&人多すぎのコースで、20分近く歩くはめになった。これはひどい。Googleマップもいまいち変なコースしか出てこない。

2時間近く駅の中をさまよう不審者となってコース取りを検討した結果、板南線限定・エスカレータは使える(車椅子やベビーカーではない)前提となるが、両改札間6〜7分・階段なし・人混み少なめのルートの開拓に成功した。淡水線の場合はあまり救いにならないので、機場線MRTよりも普通にバスを使ったほうがよいように思う(中和線の三重駅がわかりやすそうだけど、機場線の各駅しか止まらないのだな)。

公式サイトでは駅内情を把握できないのだが、台湾のネット有志による、日本の駅3Dマップのようなマップが公開されている。

http://weijidai.pixnet.net/album/photo/320220346 weijidai, 台北車站立體導覽圖, 201702

東京に負けないなかなかのダンジョンっぷりである……。

さて、2017年11月時点で、肝心の開拓したルートは次のとおりだ(クリックして拡大)。

photo


①まず、板南線は頂埔側先頭に乗り(たとえば忠孝復興からなら進行方向の先頭)、台北駅で下車。上下のエスカレータがあるので上がる。

②登ったら振り返ると改札(忠孝西路口)があるので出る。背後に機場線の案内があるが、これは罠であり、絶対に向かってはいけない。

③改札を出ると上下のエスカレータがあるので登る。

④K地下街というほうに入っていく。このとき上方向のエスカレータと階段しかなくて一瞬絶望するが、階段横にエレベータがあるので、これで下る。なお、下った横にトイレもある。

⑤K地下街は混んでいるので、いったん右方向の誠品地下街(スターバックスがある)に入ってから左に折れ、あとはひたすら誠品のオシャレショッピング通りを突き進む。このあたりまでくれば、機場線の案内があるので迷うことはないだろう。

⑥地下街の突き当たりに上下エスカレータがあるので登る。

⑦上がったら右に折れ、宣伝パネルが両側にずらずらあるだけの一本道を進む。

⑧改札に降りるエレベータと上下エスカレータがあるので好きなほうで降りる。

⑨機場線MRTの改札到着! そういえば降りた先にはトイレが見つからなかった気がする。車内にトイレはないし、乗っている時間も長いので、必要なら周辺のところに行っておいたほうがよさそうだ(マップからすると、改札エレベータを降りずに進むとありそう?)。

機場線MRTのEXPRESSはおおむね毎時0,15,30,45分の15分間隔で、ターミナル1は35分・NT$150、ターミナル2は37分・NT$160。車内は荷物置き場もあり、開発著しい市内を抜けると緑豊かな山々と高所の快走を楽しめる。

……が、やっぱ松山を知ってしまうと、桃園は遠すぎるねぇ。成田-桃園だと移動の時間ロスが料金以上に大きく感じてしまうし、大型機やLCCが多いのでセキュリティや入出国審査がオーバーフローしている印象(モスクワ並みの時間がかかった)。

photo photo photo photo photo photo


2017年11月17日

_ [indesign] APFS+InDesignのスクリプトウィンドウの組み合わせバグをなんとかする

DTP作業用のmacを新調。すでに周知されているとおりInDesign CS6が動かなくなっているので、InDesign CC 2017をひとまず次の安定版ターゲットとすべくいろいろと立ち回っている。

macはもともとSierraが入っていたところに移行失敗でやむなくHigh Sierraになってしまったのだが、例のAPFS化により、InDesignのスクリプトウィンドウが困ったことになった。

本来は次のように辞書順にスクリプトファイルが並ぶ。

photo

これが、High Sierra環境だと、次のようになる。

photo

従来はOSから返るディレクトリのファイルエントリが辞書順になっていたのが、APFSになって生のハッシュ順になってしまったということらしい。Linuxでスクリプトを書いていた身からすると「フツーsortしてから加工を始めるだろ」と思うのだが、Adobeの開発は辞書順で返ってくる前提しか考えていなかったようだ。

APFSでない環境あるいはファイルシステムであればこの現象は発生しない。

InDesign CC 2017、2018両方で確認したこの現象についてはAdobeのチャットサポート経由で伝えており、たぶん2018では直るのではないかと、薄い期待を込めて思う。2017にも入れてほしい、とはお願いした。

ともあれ、このままでは何かと困るので、同等のスクリプトウィンドウを2時間ほどで作ってみた。こんなかんじ。


photo

Hacking InDesign with JavaScriptdialogScriptWindow.jsxとして置いた。

app.scriptPreferences.scriptsFolderはユーザー環境のほうしか見てくれないのでどうしたものかと思っていたのだが、scriptsListならアプリケーション・ユーザー環境両方のスクリプトファイルのパス一覧を配列で返してくれるので、これを加工することにした。しかも、scriptsListを実行した瞬間にパスを読み直してくれるようなので、ファイル追加にも対応できる。

scriptsListはちょっと変わった配列になっていて、

 [ "アプリケーション:Scripts Panel:Samples:JavaScript:AddGuides.jsx",
   "/Application/Adobe%20InDesign%20CC%202017/Scripts/Scripts%20Panel/Samples/JavaScript/AddGuides.jsx" ]
 [ ..., ... ]
 ...

のように、1つめに表示用フレンドリーなパス、2つめに実際のFile URIを格納する配列の配列という形となっている。:なのはたぶんmacだからで、Windowsだと違いそうだが、いずれにせよAPFS以外なら普通にスクリプトウィンドウを使えばよいので構わないだろう。

APFSの影響でこのscriptsListはバラバラな順序になってしまっているので、1つめのパス名に従ってソートした上で、関係ないファイルは飛ばしてツリー化する。applescriptも私は使わないので、JavaScript系のファイルのみにした。

ツリー構成(TreeView)はあまり情報がなくて苦労したのだが、要は枝を持つものはnode、端となるものはitemとして追加すればいいItemListの延長線だった。

TreeViewのonDoubleClickイベントはオブジェクトモデルビューアに載っていない。最初迂闊にalertを呼び出してみたら、初期描画のときにもなぜかこのイベントが呼び出されるようで、ひどい目にあった。

実際のスクリプト呼び出しはdoScriptを使ってscriptsListのFile URIを実行するだけで変わったことは何もしていない。

あとはInDesign CC 2017のUI文字が大きすぎる(13pt)ので9ptになるようにTreeViewに指定してみているのだが、どうもこれは無視されるようだ。

ということで、早くこんなツールがなくて済むようにバグ修正が待たれる。


2017年09月11日

_ [indesign] DTPerのスクリプトもくもく会#3に参加してきた

前々から気になっていた DTPerのスクリプトもくもく会 にようやく参加でき、Yusukeさんらお会いしてみたかった方々にもお会いできてたいへん有意義な時間でした。

新たな知見も得られて、今後のAdobeツール向けのスクリプト開発がまた一段とはかどりそうです。ありがとうございました。

  • ESTKのオブジェクトモデルビューアの元データは、~/Library/Preferences/ExtendScript Toolkit/<ESTKバージョン>/omv$indesign-<バージョン>.xmlのようにして格納されている(ユーザー環境から拾っていることから推測できるように、一度そのバージョンをビューする必要がある)。これを拾えば、普通には困難なEnumerator値の逆引きができる。具体的には/dictionary/package/classdef[@enumeration='true']から簡単に拾い出せた。
  • ESTKの不快なプチフリは、すべてのAdobeツールのnapを切りまくればよい。ESTKとInDesignだけはやっていたのだけれども、全部やらないと効果がないらしい。( https://ten5963.wordpress.com/2017/06/22/estkのプチフリについて/ から転載)
while read domain; do defaults write "$domain" NSAppSleepDisabled -bool YES; done < <(defaults domains | awk 'BEGIN {FS=", "} {for(i=1;i<=NF;i++)print $i}' | grep -i adobe)

私は「スクリプト作成のためのスクリプト支援」として、InDesign上での検索UIで指定した内容を、JavaScriptのソースとして書き出すというスクリプトをもくもく会の間に作ってみました(ある程度作っていたものをブラッシュアップしました)。

実行するとこんな感じで吐き出します。

app.findChangeTextOptions.caseSensitive = false;
app.findChangeTextOptions.ignoreDiacritics = false;
app.findChangeTextOptions.ignoreKashidas = true;
app.findChangeTextOptions.includeFootnotes = true;
app.findChangeTextOptions.includeHiddenLayers = false;
app.findChangeTextOptions.includeLockedLayersForFind = false;
app.findChangeTextOptions.includeLockedStoriesForFind = false;
app.findChangeTextOptions.includeMasterPages = false;
app.findChangeTextOptions.kanaSensitive = true;
app.findChangeTextOptions.wholeWord = false;
app.findChangeTextOptions.widthSensitive = true;
app.findTextPreferences = NothingEnum.NOTHING;
app.findTextPreferences.findWhat = "あああ";
app.findTextPreferences.justification = Justification.RIGHT_ALIGN;
// app.findTextPreferences.underline = (new Boolean(true));
// app.findTextPreferences.strikeThru = (new Boolean(true));
app.findTextPreferences.underlineColor = "C=0 M=0 Y=0 K=60";
app.findTextPreferences.underlineGapColor = "C=100 M=47 Y=0 K=44";
app.findTextPreferences.underlineGapTint = 50;
// app.findTextPreferences.underlineGapOverprint = (new Boolean(true));
app.findTextPreferences.underlineType = "直線ハッシュ";
app.findTextPreferences.underlineOffset = 8;
app.findTextPreferences.underlineWeight = 1;
app.findTextPreferences.strikeThroughType = "二重線";
app.findTextPreferences.strikeThroughOffset = 0.5;
app.findTextPreferences.leadingModel = LeadingModel.LEADING_MODEL_CENTER;
// app.findTextPreferences.allowArbitraryHyphenation = (new Boolean(true));
// app.findTextPreferences.numberingRestartPolicies = resolve("/@find-text-preferences/@numbering-restart-policies");
// app.findTextPreferences.bulletChar = resolve("/@find-text-preferences/@bullet-char");
// app.findTextPreferences.parent = resolve("/");
app.changeTextPreferences = NothingEnum.NOTHING;
app.changeTextPreferences.changeTo = "いいい";
app.changeTextPreferences.changeConditionsMode = ChangeConditionsModes.REPLACE_WITH;
// app.changeTextPreferences.numberingRestartPolicies = resolve("/@change-text-preferences/@numbering-restart-policies");
// app.changeTextPreferences.bulletChar = resolve("/@change-text-preferences/@bullet-char");
// app.changeTextPreferences.parent = resolve("/");
// app.activeDocument.changeText();

テスト用に適当に設定したのでちょっと長くなっていますが、設定項目がnullやデフォルト値の場合は書き出さないので、普通はもっと少なくなります。皆さんがもくもくしている中でお時間をいただいて、スクリプト実装内容の発表もさせていただきました。

資料にもあるとおり、私のサイトHacking InDesign with JavaScriptにて、dialogExportFindSet.jsxという名前で公開しています。Enumeratorの逆引きテーブルができたので、「この設定はJavaScriptだとどうなるんだろう?」というときにもちょっと使えるかもしれません。

InDesignのXML探索や、characterの操作などはかなり遅いのに対し、find/grepの検索・置換はチューニングされているのか圧倒的に高速です。InDesignのXMLドキュメント操作においては「ダミー文字を入れておいてdocument.findTextしたりdoument.changeGrepしたりする」というテクニックをよく使います。

そういえばMD5500さんからの宿題となっていたInDesign XMLのDOMの一部を取り出してまた戻す、という操作ですが、やはり綺麗にできそうな気がしません。InDesignのDOM処理はかなり怪しく、ツリー上のUI操作もスクリプト命令も貧弱だし、DOMの「変更」操作は容易にクラッシュするので、コンテンツを直したら一部ではなく全体を組み直すようにしないとやっぱりうまくいかないのでは……というなんとも心許ない返答となります。


2017年08月01日

_ [travel] ロシアMAKS旅行(5)

ロシアMAKS旅行(4)より。

photo photo

咳は少し出るし若干疲労感はあるが、スープ効果とパブロンでだいぶ復活。

土曜のMAKSにパートナーと2人で向かう。

金曜とはうって変わり、Kazansky駅はかなりの混雑。乗ろうとした特急は立ち客で埋まっている。時刻表に掲載されている次の時間の車両は今日は走らない、と言われ、ちょっと思案。しかし各駅列車は空調がなく時間がかかるので、結局30分ほど後になるが特急を選択。

この選択は正解で、急行列車はすぐ到着し、着席して発車を待つことができた。発車の頃には通路や車両間に多くの人たちが立って乗っている。

Otdykh駅も昨日の数倍の混雑。荷物検査やバスに乗るにも時間が当分かかりそうと判断して、昨日見たバス降り口側の仮設トイレで済ませておく。

荷物検査やバス乗車は時間はかかったものの、バスは2本見送って着座でゆっくり会場へ。曇りで涼しく、ありがたい。

しかし、多数の人々が荷物を検査されて迷彩服姿の軍人にバスに次々と詰め込まれて運ばれていく、というのはとてもソビエトロシアっぽい感じがあるな!

入場口も荷物チェックにたどり着くまでにだいぶ時間がかかったが、チェックのあとは昨日同様前売りチケットの力ですぐに抜けることができた。

photo photo photo photo photo photo

会場も人でごった返し。たまに空いたところに入り込んで撮影する。

photo

前日にランチ調達ができなかったので現地で……とハンバーガー屋に並んだのだが、ここは失敗だった。お手洗いなのかツーオペからワンオペになってしまっていたり、ホットコーヒーを売りにしているのかそのオペレーションに時間がとてもかかったり、でさほど後ろではなかったはずなのに全然進まない。

そうこうしている間にPAK FA T-50のフライパスデモが迫っていたので、購入をパートナーに任せて撮影スポットに向かったものの、進み切れないままダイヤモンド型の機体が遠くへ飛び去るのを見るのみとなってしまった。

photo photo photo

その代わり、MiG-35の地上展示があったので、じっくり近くから観賞。

パートナーと合流。ハンバーガーはポークだった(いろいろ手が塞がって撮影できず)。

photo photo

昨日は選びたい放題だった芝地が立ち見の人で埋まっており、ちょっと呆然とする。そうこうしているうちに、Su-34、Su-35、そしてT-50 2機によるデモフライト。これは嬉しい。

T-50が戦闘機動で空を踊る。斜めにゆっくりと進む変態機動もおおいに見せつけてくれた。これで見たかった機体は全部見ることができた。我が旅行に一遍の悔いなし。

photo photo

このあとのSR-10のフライトでどっと観客が減ってくれたので、滑走路に近い前方に移動し、椅子も設置。立ち見は多いけれども、探すとところどころに空きスペースは多い。

そうしているうちに、ロシアSwiftsチームによるMiG-29編隊のデモ。フレアをばらまき、6機が息の合った機動で旋回する。

会場ナレーションが「我らがロシア万歳!」みたいなことを叫んだところで、観客も口を揃えて「ウラー!」

photo photo

軽飛行機(CH-801)のあとは昨日も見たThe Baltic beesのフライト。ロシアンナイツチームまで見るにはこのあと3時間も待たないといけないし、それを見ていると宿に戻るのが20時くらいになってしまうので、ロシアンナイツは諦めてBaltic beesの途中で帰ることにする。

会場内の仮設トイレはどこも大行列だったが、会場から出たところの入口付近の仮設トイレは空いていた。

バスを1つ見送り(それでもやっぱりすぐ来るので)、座って駅へ。特急はなかなか来なかったが、それでも来た列車の乗車ドアはちょうど立っていた位置だったので、あっさり座れた。後からやってきた人たちはやはり立ちっぱなし。

モスクワだけなのかロシア全般なのか、こういう近郊列車も地下鉄も、列を作って待つということが基本ない。乗車口はここという案内もないし、そんなに正確な停車位置はないという理由もあるかも。なんとなくボーッと皆立っていて、到着するとドア付近に殺到して乗り込み、席を確保する。ただし、降りる人を待つ、子供連れ最優先、というのは守っているようだし、殺到はするものの力づくで割り込むということはないので、これでうまくいっているのだろう。

ダスビダーニャMAKS、素晴らしい満足の体験だった。

photo photo photo

帰りにおみやげを買いにTsvetnoy Bulvar駅のTsvetnoy Central Marketへ。ハチミツのスフレを購入。

photo

最後の晩餐。鶏肉とマッシュルームと玉葱をバターで炒め、スメタナで煮込む。ピラフとあわせ、ザワークラウトとともに。いい夕食であった。

帰り支度が必要だが、疲れ切ったので食後は2人でぶっ倒れ。一度起きたものの、歯磨きが限界だった。

photo

朝食は最後の残り物を。ピラフと黒イクラの組み合わせがタラコ焼きおにぎりのようでイケる。結局買ってきた食材で残したのは、ピタパンひとかけとコーン油、白ワインくらい。がんばった。

荷造りを進める。チェックアウトまで、私のほうは風邪がまだ治り切っているわけではないので安静にして寝る。パートナーは残りの現金を持って最後の買い物へ。

photo photo photo photo photo photo photo

12時に宿をチェックアウト。アパートメントホテルアダージョパヴェレツカヤは、不満な点の少ない、良い宿だった。ATMにお金が入っていなくて引き出せないのが問題点くらいか(スキミングの可能性はたぶんないとは思うのだけれども、いちおうATMを使うときにはいつもプリペイドのカードを使っている)。

気持ちよい空気の中、Paveletsky駅へテクテクと歩く。というか、空港への列車がお昼時間帯がすっぽり抜けて、5分で駅に走り込むか(無理)、40分待つかしかない。

旅行初日に苦労した道のりも、わかってしまえば地下道をまっすぐ抜けるだけだった。 地下道ではハンドスピナーがたくさん売っている。

photo photo photo

Aeroexpressの入場改札はなし。少し待つと列車がやってきた。いざDME空港へ。

降りるときに改札でQRコードをかざす。旅行前にチケットを購入していたけれどもそのときにはQRコードがまだ発行されていなかったので、ネットからダウンロードしておいたので、それをスマートフォンでかざすだけ。

さて、DME空港について入場荷物検査をしたあとにJALカウンターに行くわけだが……ここでしくじった。Departureの表示のとおり2Fに上がったのだが、ここは「すでにチケットを持っている」人向け。

1FのJALカウンターに行くと、JALパックほか帰国の皆さまの長蛇の列……。オンラインチェックインは済ませているものの、DME空港のJALは手荷物カウンターというような代物はないのでエコノミーの行列に並ぶしかない。おまけに「機器の調子が悪い」らしくてカウンターがほとんど開かず、進まない……。30分ほど待って荷物を預け、搭乗チケットを取得。去年はこのあとの出国審査に1時間かかったことを考えると、お昼をゆっくりというのは無理そうだなと心配になる。

幸い昨年と違って出国審査やセキュリティは空いており、あっさり突破はできた。

Aeroexpressの列車待ちとJALカウンターの時間ロスの影響で時間はあまりないものの、せっかくプライオリティパス持ちになったので、DME空港の2つのラウンジを試してみたいと思っていた。パスを持たないパートナーはゲート近くで買ってきたごはんを食べる、ということでまずはS7のラウンジ。

photo photo

けっこう混んでいる。食事はミネストローネやカナッペ、ブリヌイなど。ミネストローネはだいぶひどい出来。ブリヌイはスメタナとジャムを付けて悪くない味だった。しかしだいぶ狭くてゆっくりできる感じではないなぁ。

もう1つのBusiness Loungeへ。Business Loungeはこのホールに2つあるのだが、最初に行ったほう(出国に近いほう)はプライオリティパスは受け付けず、ゲートに近いラウンジを指示される。

photo photo photo photo photo photo photo

さて、こちらを後側にしたのは失敗だった……。広さはS7より上なのだが、ともかく席がない。ソファー席は家族連れで埋まっていて、席が空かないかと狙っている人たちが常にうろうろしている。

幸いスツール席を確保できたが、足は浮くし両脇は狭いしで落ち着けるものではない。スイーツはチョコレートばかりで選べず。温かいものはのびたペンネ、水っぽいマッシュポテト。カニカマサラダと豆サラダはわりとマシだったので、こちらを主につまんでいた。

この席の長所は、空港の様子がよく見えることか。シャワールームがあったので、最後に使えばよかったかも。歯磨きだけしてラウンジを出る。

なお、荷物を持って席を立った瞬間に次の人がずざーっと席取りにきた。サツバツ!

photo photo

JAL搭乗。B787-8で、席も往路とまったく同じ。夕食の鳥チーズパスタはけっこうイケた。

朝食のホットサンドはちょっと喉に詰まるので二口程度。

うとうと寝たけれども、映画として『ローガン』(プロフェッサーもローガンも悲しい……)、『コング』(時間切れで途中までしか観られなかった。大味感がすごかったが残りの内容が気になる。とりあえずサミュエル・L・ジャクソンを見ていれば十分に面白い気がしてくる)。

定刻に到着。西からの帰りは早いねぇ。荷物も珍しくすぐ出てきて、帰宅。 東京は暑いょ……。

帰国当日も二度の洗濯をしながら修正納品などをしつつ、翌日から業務など本格復帰。 時差ボケは徐々に回復中。

  • 去年でおおむねモスクワのメジャーどころを回ったこともあり、2人とも慣れた感じでモスクワの生活を楽しんだ。MAKS以外は予定を固定していなかったので、行き先は「明日どうしようかー」みたいなゆるい決め方。そういえば結局「モスクワに来たらまずはここ」というクレムリン宮殿内には入らなかったな……。
  • 天気がよくないときもあったけれども、気温はおおむね快適だった。今の東京がほんとツラい。
  • 飛行機を除いた24回の食事のうち、外食らしいのはわずか6回。ほかはほぼ自炊、あとはスーパーのお惣菜で済ませた。おかげで旅費がえらく安くなっている。
  • 乳製品はヨーグルト、生クリーム、バターは最高。牛乳はパートナーによるとちょっと酸っぱかったらしい。野菜はやや固め。牛肉はロシア産のは品質が悪い。豚肉、鶏肉、ウサギ肉は良い。卵が何気に最高。パンは黒パンや白パンのほか、中東系のピタパンやホブス、ユフカなどバリエーションが多い。焼くオーブンがほしかった。魚介はあまり試していないが、ニシン酢漬けやカニカマはおいしい。お酒は風邪っぴきだったこともあり、ほとんど飲めなくて悲しい。
  • MAKSはとても良かった。交通機関のMAKSシフトなども整備されていて、とまどうことはまったくなかった。そして西側やアジアのエアショーでロシア機というとまれだし、そもそもロシアの現役機がこんなに何度も長時間飛び回るのを観られる機会はここしかない。
  • Google Mapsは大活躍。なぜかコンパスを掴むのに時間がかかるが、バスやトラムなどのルートやリアルタイムの待ち時間を示してくれるので、知らない場所でも安全にたどり着くことができた。トロイカカードのリチャージも機械で簡単。
  • 昼間が長いせいもあり、治安的に危なさは感じなかった。去年はひったくりを数件目撃したけれども、今回はせいぜいメトロの駅で寄ってきた人にお金をねだられたくらい。

2017年07月31日

_ [travel] ロシアMAKS旅行(4)

ロシアMAKS旅行(3)より。

photo photo photo photo

いよいよモスクワエアショー「MAKS(ロシア語表記でMAKC)」本編、一般公開日の金曜日。 この日はパートナーとは別行動で、パートナーのほうはトレチャコフ美術館やイコン美術館に行ってみるらしい。

朝に青焼修正依頼に対応していたら、ちょっと予定していたよりも遅くなってしまい、朝ごはんは前日の残りとヨーグルトであわただしく出発。どこでも仕事ができるというのは考え物だ。

入場チケットはWebで購入し、印刷済み。

会場まではKazansky駅(最寄りメトロ駅はKomosomolskaya)から出ている近郊列車で向かい、Otdykh駅で降りてシャトルバスで会場のラメンスコエ空港、というルートとなる。

実際のところ、TVでも毎日ニュースで「今日のMAKC」的なコーナーがあるほどの一大イベントなこともあり、交通機関は完全にMAKSシフトされていて迷うことはほとんどない。

Komosomolskaya駅からKazansky駅側に降りると、「MAKS→」の案内が床や壁に続いており、Kazansky駅では特設切符売場がずらりとできている。ここで往復の特急券を購入、664RUB。レシートみたいなしょぼい券だが、バーコードが付いており、それを自動改札のリーダーにかざせばよい。往復で違いがわからなかったのだが、別にどっちを使ってもかまわなかったようだ。

特急スプートニク号にちょうど乗れて座れた。検札は1回やってきた。途中数駅だけ停まり、だんだんとダーチャが飛び飛びにあるような森林風景を見るうちにOtdykh駅。50分くらい。

Otdykh駅からはやはり案内に従って簡単な手荷物検査を受け、バスに詰め込まれる。ぎゅうぎゅうに詰め込まれてしまったが、いっぱいバスは来ていたので1本待ってもよかったかもしれない。MAKSシフトで信号で停められることもなく進むが、それでも20分くらいかかるし、気温は快晴26度、冷房なし、とちょっとしんどい。

写真は撮れなかったけれども、空港入口手前にはMiG-25などの往年の航空機が並んでいた。

MAKS会場入口で、もう少しだけ厳密な手荷物検査があり、当日券購入の行列はあるが前売チケット持ちはそれをスルーしてバーコードチェックを受けて入場。最近物騒だし、記名入場券なので何か確認はあるのかと思ったのだけれども、何もされなかった。MAKSサイトのFAQにあったとおり、水も食事も折り畳みチェアも問題なく持ち込めた。

開場からさほど時間が経っていないこともあり、上空では最終練習中の航空機も見える。ほかに軽飛行機や気球などがいくつも。

ついにここに来れた、という気持ちが高まる。

photo photo photo photo photo photo photo photo photo photo photo photo photo photo photo

IL-76のお出迎えのあとは、MiG-29、Su-35、34、カナード付きモデルのSu-35にSu-30。天国はここにあったんだ…!

途中、デモフライトに向かう巨大なMi-26がドナドナされていた。

photo photo

Mi-28とKa-52かな。ソビエトのヘリコプターってちょっと独特。

photo

会場にはスタッフがたくさんいる。ガイドブックをもらった。スーパーマンのマントを付けているのも道案内のスタッフ。

photo photo photo photo photo

A-50早期警戒機、Tu-160爆撃機、Tu-95爆撃機。冷戦時代だなぁ。

photo

背中に樽を載せたこいつは、VM-Tという特殊輸送機。バイコヌール宇宙基地にロケット関連の大型製造物を持っていくのに使っていたらしい。

photo photo photo photo photo photo

年代ものの飛行機たちの中に、現役っぽい迷彩Su-27。最高。

MiG-1.44って実在したのか。前から見るととんでもなくカッコ悪い(笑)。

photo photo

端ではドラッグレースみたいなのをやっていたようで、爆音とタイヤが軋む音に人が集まっていた。

photo photo photo photo photo photo

平日で午前ということもあり、会場はまだ余裕がある。トイレも仮設がたくさん用意されている(ただし流れないし洗うところもないので、覚悟は必要。仕方がないので飲み水で手を洗った)。

食事の屋台はハンバーガーのほかは蒸しトウモロコシが多い。

銃の組み立てデモとか、払い下げ品の販売とか、航空機に関連してレーダーや対空ミサイルなどの展示も。

滑走路正面の原っぱに陣どった。ハンズで買った背もたれ付き折り畳み椅子のデビューは上々だが、陽射しがけっこう暑い……。

photo photo

11:00になり、いよいよフライトデモのスタート。10機のヘリコプターがまず横断。

photo

Il-114のデモ。だいぶ古い設計の機体だけど、何か特別な意味があるらしく、観客がウラー!(万歳!)と叫んでいた。

photo photo photo photo

Su-35来た! Falcons of Russiaチームによる、4機フォーメーションでぐるぐると回ったり2機ずつで交差したりと魅せる。最高。

photo

練習機SR-10のデモ。前進翼機の実物が飛んでいるのを見るのは初めてだな。ラジコンのようにブンブン回っていた。

photo

ChelaviaチームによるR2002の編隊飛行。レシプロ機はあまり興味がないので……。

photo photo

MiG-29M2かMiG-35Sのどちらかであるみたいなんだけど、ロシア語のアナウンスではわからないし、外見で違いを見分けることも難しいのでわからないな。MiG-35はエンジンノズルがスラストベクター化によって長くなったらしいのだが、角度によっては長く見える気がするけれども、そうでないようなときもある……。上がったり下がったり失速寸前に止めてみたりと大いに暴れていた。

photo photo

Yak-130(途中にIl-2があったけどレシプロ機は……)。派手にフレアを上げていた。

photo photo

Su-30による戦闘機動的アクション。プガチョフコブラもやってくれました。会場は大いに盛り上がる。最高。

photo

持ってきたパンのお昼ごはん。サンドイッチはターキーとトマトが入っていて、気温でちょうどマヨネーズがとろけておいしい。パイは肉の詰まったサモサで、悪くないけれどもちょっと喉に詰まる。

しかしともかく暑い……。帽子をかぶって傘を差して、でも容赦なく陽射しが照りつける。でも暑いからと薄着になると風が吹いて寒かったりと温度調整が難しい。

photo photo

L-39を駆るラトビアのチームThe Baltic beesによるデモ。黄色と青のハチの塗装がかわいい。が、デモ30分はちょっと長すぎ(笑)。

photo photo photo photo

このあとは午後まで軽飛行機系の展示なのでしばらくいいか、と思っていたところで雲行きがどんどん怪しくなり、横殴りの強い雨が降ってくる。これはたまらんと屋内展示の建物へ。

皆雨宿りにやってくるので、混み混みで動きづらい。スホーイ社のブースでSu-27のカタログをもらってきた。しばらくボーイング社ブースの横で座って休み。

photo

しばらく天候を見ていたが、晴れ間は見えてきたけれども雷が鳴っているし、風も強いので午後は期待できないと判断。だいぶ疲れたし、雨でズボンが濡れてよくないので、引き上げることにする。ロシアンナイツは見たかったけど(あとから投稿ビデオなどを見た限りではかなりはしょった形でいくつかはやったのかな)。

同じことを考える人は多かったようで、バス停に向かう頃には雨は止んでいたものの、バスは激混み。駅に着いて、上がったプラットフォームは普通列車のほうだったようで(特急は奥のプラットフォームに行くべきだった)、Kazansky駅行きの列車もかなり混んでいた。幸い20分ほどで降りた人がいて座ることができたけれども、蒸して変な汗が出てくるのでだいぶ辛め。普通列車のほうは各駅で止まりながら1時間10分ほど。

photo

Kazansky駅のスーパーで少し食材を買い、宿に戻って汗だくの体をシャワー。本当はお風呂に入っておきたいところだったなぁ。

青焼修正の残りを片付け、納品。ややしけ気味のジャムウエハースと紅茶で一息ついていたら、体の芯から震えが……。やっぱり体が疲れているところに雨で風邪をひいてしまったらしい。風邪薬を飲み、布団を重ねてベッドで震え寝る。なんかロシアに来るたびに風邪ひいてるな!

photo

夕食は簡単めかつ体が温まるよう、鳥、玉葱、ナス、ズッキーニ、マッシュルームでスープ。そういえば鳥は本当はモモ肉がほしいところだったのだが、ロシアのスーパーだとモモだと必ず骨付きで、骨なしは胸肉しかない。あとはレバーかまるごとか。

ともあれ、パンとたっぷり野菜のスープでだいぶ体は楽になった。しっかり治さないと。

宿のセルフランドリーを使ったのだけれども、Booking.com経由の予約だと無料サービスではなかったそうで、フロントで540RUBを支払う。まぁ普通にランドリーを頼むと下着2つでその値段になるので、十分に安い。浴室内のヒーターでわりと乾くので、セルフランドリーを使わなくなって以降は手洗いしてそこで乾かすようにしていた。

ロシアMAKS旅行(5)へ続く。