どうも世の中に自作キーボードなる世界があるというのはHHKBのユーザーミートアップで知ったのだが、HHKB持っているし、静電容量スイッチは無いみたいだからいいかぁ‥とその場ではスルーしていた。
その後、しばらくして調べてみるとHHKBと同じ配列ベースの自作キーボードがいくつかあることを知り、興味があったので技術書典に行ってみた。そのときに買いたいと思っていたのがchoco60だったのだが、残念ながらその場で売り切れ。何も買わないのももったいないと思い購入したのが、『Learning Custom Mechanical Keyboard』(通称: #白ウサ本)だった。
実際に作る前に読んでおくと自作キーボードに必要な知識を得られる。コンパクトにノウハウがまとめられた良い本だった。知識を得た上で実際に自作キーボードの世界にいざ入門!
やりたかったこと
・HHKBと同じレイアウトで
・HHKBよりもキータッチを軽く、静かにしたい
やったこと(準備編)
1⃣キースイッチの選定
遊舎工房に行って実際に様々なスイッチを試してみた。良さげな静音軸スイッチをいくつか選んで一個ずつ購入。あとは家で押しまくって何が良いのか決める。
自分の中ではHealios、画像にはないけどGateron InkのSilent Blackが良かった。
やはり価格相応という感じ。Healiosはv2があり、v1よりもv2のほうが良い印象。
2⃣キーキャップ準備
ハマると自作キーボードの世界で一番散財しやすいポイントだと思った。こだわると$100オーダーの世界。でも最も目につくポイントでもある。また、手元に届くまで平気で半年以上はかかるので気長に考える必要がある。
今回はGMK RED SAMURAIをベースにしている。
ベースキットだけでchoco60に必要な分割スペースバーが手に入るのがポイントだった。GMK RED SAMURAIキーキャップセットが届く。
— ぺけよ (@Xyo) September 19, 2021
ベースキットだけでも、キーの種類豊富。割と好みの臙脂色で良かった。これは黒系のキーボードに使うことにしよう。 pic.twitter.com/rydwpq4MWK
3⃣潤滑とスプリング交換
潤滑は「recompile keys キースイッチ ベストプラクティス」を参考にした。この辺の作業が一番コツコツ感がある。
スプリング交換はやっているうちにどのへんが良いのかわからなくなり(気づくとスプリングの種類が増えている)、完全に迷宮に入り込んだ感がある。
個人的にはHHKBよりも軽くしたいという当初の思惑があって、45sを上限としたが、軽すぎるのも考えものだということがわかったので、今後は重い方向にトライしても面白いのかもしれない。
Lubeすっかぁ。
— ぺけよ (@Xyo) November 8, 2020
赤 45s x 2
黄 40s x 9
黄緑 35s x 24
緑 30s x 9
水色 25s x 13
青 20s x 5 pic.twitter.com/nOGfXxAe7M
5⃣ソケット対応
完成後にキースイッチ交換したくなると思い、Mill-Max 3305-0-15-80-47-27-10-0を使用。個体によってはタイトでソケットが入りにくい場合がある。面倒でも金属ヤスリで足の部分を少し削ると良い。無理にソケットを付けようとすると足が折れて、付けるのがますます困難になる。
やったこと(工作編)
基本的に公式のビルドログに沿ってやったぐらいである。
少し自分のやったこと事を補足すると
・コンスルーピンヘッダはんだ付け後のピン除去
ボトムプレートと干渉しないように、はんだ固定側のピンは切って、高さを切り詰めた。
・ファームウェア書き込み
「自作キーボード温泉街の歩き方 (初心者編)自作キーボードにファームウェアを書き込む」を参考にした。
・ダイオードのはんだ付けが終わったらピンで一度通電テスト。
基板のみで文字が打てるのかをまず確認した。
・スタビライザーのlube
この動画を参考にした。
底面がぶつかるところにバンドエイドを仕込んでクッション代わりにするのをband aid modと呼ぶらしい。
たしかにやたらと静かになる。
作ってわかったこと
・キーは軽ければ軽いほど楽...とは限らない。
適度に反発力がないとかえって疲れるし、タイプミスも多くなる。(35s以上が良さそう。)
・TRRSケーブルはふにゃふにゃのほうが取り回ししやすい。
スリーブ付きは見た目が良いが、ケーブルが固くなり取り回しが難しくなる。
・HHKB準拠のコマンドキーを集めるのが割りと大変。
HHKBに寄せてると1.5Uのコマンドキーが必要になるが、この大きさのコマンドキーは割と希少。(手持ちだとGMK9009の拡張パーツぐらいしかない)
HHKBに慣れているのでALTと交換したくはないのが悩みのタネ。
・変荷重レイアウトが難しい。単に人差し指中指から遠いほど軽くするものではないと思う。例えば...
①<>→対になっているキーは重さを揃えたい。
②zxcv→Ctrlと組み合せると人差し指も割と使う領域なのでこちらは揃えた。
①②は作りながら対応したが、今後は更に以下も追加すべきと考える。せっかく増えたスプリングなので、バネ配置を考えていた。結構難しい。左が初案。右がv2。
— ぺけよ (@Xyo) October 27, 2020
初案では押す力が強い指から遠くなるほど弱くなるよう変荷重にしたんだけど、単純に距離じゃないんだよな...。(<>のように対になっているキーは揃えたい。Ctrlで押すキーは人差し指使う等) pic.twitter.com/Sh8a5myl7n
・ソケットの厚みにそこまでこだわらなくても良かった。HealiosとSilent black Inkを両方とも40sスプリングに変更して比べてみた。正直スプリングを同じにすると打鍵感の違いは分からんなぁ...。静音性もSilent black Ink とHealios v2は同じように感じる。
— ぺけよ (@Xyo) October 25, 2020
Healios > Silent black Ink ≧ Healios v2
個体差が有るような気がするなぁ。 pic.twitter.com/c70Gd9mc1V
・スイッチブレートの位置決め大事。ソケットはんだ付けに関する自分用メモ
— ぺけよ (@Xyo) May 6, 2022
①こて先のコンディションを確認する。はんだがついたら拭き取る
②こて先でスルーホールとソケットを同時に温める
③はんだをこて先で溶かしたらソケットの足で溶かす(コテ先使うとソケットの中に流れやすい)
④はんだを下げてしばらく温め続けて様子見。 pic.twitter.com/faoEPw8G3p
ちなみにカスタムUSBケーブルは@2zk氏から購入した。
TRRSケーブルだけで難儀していた自分にとって、カスタムUSBケーブル自作はすごすぎる。
今回は好きな様にやってしまえ!と吹っ切ったおかげで初自作ではあったが
自作キーボードの狂気レベルでは一気に4層目ぐらいにたどり着いた。
自作キーボードではqwerty配列に拘る必要すらないという自由度がある。
次はキー配列のカスタマイズに手を出してみたいと思っている。
■Java16
(LTSは現行11 → 次回17)
Java16で組み込まれるJEPは17個
更新5個。内、3個が正式化
用語:
JEP(JDK Enhancement Proposal) 機能改善
CSR(Compatibility & Specification Reviews)
(非互換性を伴う変更のレビュー)
リリースノートはこの辺の用語を気にしたほうが良い。
試用機能
試用版を提供することでフィードバックを得やすくする。
言語機能:Preview
API:Incubator
試験的に追加されたライブラリー(モジュール)
jdk.incubator.~パッケージ名で実装。後に正式なパッケージ名に変更される。
JVM機能:Experimental
と各々呼ぶ。
明示はしてないけどPreviewは2回、3回目に正式化される慣例。
(今回previewいれると17に間に合わないのでPreviewはなし。)
■言語仕様変更
・Pattern Matching for instanceof
instanceofでパターンマッチング
15以前必ず成り立たないものはコンパイルエラー。
16以降は必ず成り立つものもコンパイルエラー。
if(str instanceof Object o){}とか。
◆Records
・イミュータブルな型。暗黙的にfinal。Lombokの@Value相当。
・要素、コンポーネント名と同名のアクセサ、getterにはならない。
・自前で書くなら必ず全内部フィールドの初期化が必要。
→カノニカル(正規)コンストラクタと呼ぶ。
・必ず書かないといけないなら省略できる
→コンパクトコンストラクタ
(QA)実装も自動生成?
→クラスファイルに実装はかかれない。(生成されるclassに実装はない。)
invokedynamic. JVMで実装時に実行される。
今後はtoString()とかも最適な内部実装になる。hashcode()も。
JVMのバージョンごとに最適な実装を提供をする。
・Sealed Classes(2nd preview)
・親クラス定義時に継承できる子クラスを限定できる
今の所つかい道なさそう。
・non-sealed→ハイフン付きキーワード(予約語)が登場。今後も増えるかも。
・Warnings for Value-Based Classes
primitive classを活用してインライン表現が可能なようにプログラミングモデルを強化
(値クラス JDK8からあるValue-Based classもこれの対象にしたい)
非互換性バリバリの変更。
ValueBasedアノテーションが追加される
JVM側も変更。
■API
・Vector API(Incubator)
SIMD演算をJavaから使える
Intel ハイエンドならAVX512命令サポート。これだと double(64bit)*8 が同時に演算できる。
レイトレーシングを題材に実際に使ったら遅くなった。
JITが効かんから?
・Foreign memory Access API(3rd Incubator)
大量データを処理するためにGCで管理されないメモリを確保するAPI
Undafeを使わず標準APIを提供する。
◆Stream.toList()
→collector(Collectors.toUnmodifiableList())と書かなくて良くなった。今まではcollector経由。
変更不可リストなのでCollectors.toList()と置き換えられない。
・Unix-Domain Socket(AF_UNIX) Channels
ソケットプログラミングをもっと簡単に。
・Foreign Linker API (Project Panama)
JNIをより便利に。ネイティブ実装をもっと楽に呼びたい。
今はincubatorパッケージにある。実行時にモジュール追加が必要。
■OpenJDK
・Alpine Linuxで最小Docker imageを作る話
・musl、busybox、apk→コンパクトなLinux
・SpringBootで簡単なコントローラー付ける→初回961MB。コレを減らしていく。
・jlinkで最適化、jdepsで必要なモジュールを確認
・mercurial → git, GitHubに移行。
■JVM変更
・ZGC
スレッドスタック処理をsafepointから並行フェーズに移行することでZGCのSTW(Stop The World)を更に減少
・Elasctic Metaspace
Metaspace領域のフラグメンテーションやメモリフットプリントを改善
・Storongly Encapsulate JDK Internal by Default
sun.misc.Unsafeをふくむ重要なAPIを除くJDK内部実装へのアクセスを原則不可
■ツール変更
・Packaging Tool
・JDK14で入ったjpackageが標準化
jpackageでインストーラーを作ってユーザに提供する流れが一般的になるかもしれない。
■その他所感
・サンプルコード、最近はvarだからけなんだなぁ。
TypeScript同様、右辺が明確なものはもう型を意識しないのかも。
(実際コーディングもエディタ補完で右辺から書いて左辺みたいな感じになってるし。)
・recordのObject class由来のメソッドがJVMで実行される話が一番面白いと思った。
Effective Javaで長々と解説されていたアレらをイイ感じにJVMが片付けてくれるなら願ってもないことだ。
T-26といえば鋼鉄の騎士I派。
— ぺけよ (@Xyo) January 20, 2021
2020年にプレイ動画が上がってて懐かしい気分になった。
(SFC)鋼鉄の騎士Ⅰ プレイ動画04 by KANAN https://t.co/lKHt578zML #sm37235650 #ニコニコ動画 pic.twitter.com/RXQmlL0Ijq
なぜ洋書を買うのか
グランドパワーなどの雑誌で日本語でも資料は読めるが、面白い写真は洋書のほうが多く載っているように思う。どうしてもこの手の話題は海外からやってくるので、邦訳本を待つにしてもタイムラグがある。
自分は昔から英語嫌いだったので、今の本棚の状況は昔の自分からしたら信じられないかもしれない。
ただ、写真メインなものは文章量も多くなく、割とそこまでキツくない。知ってる単語遭遇率はTOEICなんかよりも圧倒的に高く、文法もせいぜい中2レベルの知識があれば読める。どうしても文章メインでキツい場合は最終手段でgoogle翻訳アプリを使う。(カメラ→翻訳)
訳もgoogle翻訳一本にするのではなく、DeepLと組み合わせたりする。(特に訳がしっくりこないとき)
google翻訳はドイツの昔の書体、フラクトゥールも識別できるので心強い。
■Panzer Tractsシリーズ
ドイツ戦車資料本の筆頭(個人見解)。よくグランドパワーの引用先になっているし、割と有名なシリーズなのではないかと思ってる。本屋では見かけないが、割とメジャーなプラモ屋に行くと資料コーナーによくある白くて薄い本。
時系列に沿って車輌特徴などがコンパクトに纏まっている。車輌タイプごとに異なる図面が掲載されており、車体変更点の遷移などについて詳しく知りたければこの本で良いと思う。
見たことない写真の掲載率が多く、三面図も多いので、個人的にこのシリーズは大変気に入っている。
難点はページ数の割に価格は高いということか。薄めでよく纏まっているので、場所の取らなさは申し分ない。最近ツイッターのやり取りで再刷時に訂正が入ることを知った。なので、なるべく新しいやつを買ったほうが良い。気に入った車輌だけにするつもりだったが、この本は仲間を呼ぶ傾向にある。収集癖の悪いところが出てしまう。
■Nuts & Boltsシリーズ
マニアックな車種でも、一定の厚さを保持する本。一体どうやって調査したんだと発刊の度に思う。誰得なんだ...???? と思わせるラインナップが多い中、好きな車種がこのシリーズにいたら当たりと思って良いだろう。
車輌説明、部隊解説、カラー図面、写真が多め。博物館などの実写写真も多く参考になる。プラモデルによる作例有り。
ハンガリー内には早期(44年10月)に(A)を受領している3.Pz.Div, 13.Pz.Div(後にFeldherrnhalleの一部), 24.Pz.Divが居るからこの中に8月生産車輌が居ても不思議では無い。
— ぺけよ (@Xyo) August 21, 2019
■Motorbuch Verlagシリーズ
シュピールベルガー本と表現されているのをよく見かける。邦訳書はあるが独→英→日のように翻訳されているようだ。私は元のニュアンスを確認したくてドイツ語版を買ったが流石にドイツ語は厳しい...。
解説ボリュームは多く、本の厚さの割に価格は良心的。古い本のようだが、割とこの本で知りたいことが解説されていることが多いように思う。内部構造に対する言及が多いので、戦車の中身を知りたいと思ったらこのシリーズが良いと思う。
panzer werecksのvol3読み返していたけど、p77にtyp7の履帯付けたメーベルワーゲン載ってるなぁ...。ブルムベアとかJagdpanther IV/70以外だとそんなに無いパターンかも。(調べたらすぐ写真出てきた...) pic.twitter.com/7EpXND60aT
— ぺけよ (@Xyo) June 10, 2019
■On The Battalefieldシリーズ
PeKo Publishing。Panzer Wrecks同様、こちらも大判写真いっぱい。遺棄車輌限定ではないので、ドイツ側の生きている、稼働状態にある車両写真も多い。(遺棄状態もそこそこ多いけど。)
久々にzshの設定を見直したのでメモ。
(windows10にwsl2まで入れた状態からスタート)
・brewのインストール
https://qiita.com/mtsgi/items/8a844870f30b30ef21e4#windows-terminal
curl file git入れていたので、build-essentialあとrubyがbrew実行前に必要。
・zshインストールからログインシェルの変更までを行う。
https://qiita.com/mtsgi/items/8a844870f30b30ef21e4#zsh-on-ubuntu-on-wsl2-on-windows-10
・zinit導入
https://qiita.com/szk07/items/b15c38ec73e547a23439#zinit-の導入
zsh-syntax-highlighting, zsh-completionsあたりを入れた。
・Powerlevel10k導入前のフォント整備
https://qiita.com/mtsgi/items/8a844870f30b30ef21e4#powerline-on-zsh-on-ubuntu-on-wsl2-on-windows-10
https://github.com/romkatv/powerlevel10k#fonts
Powerlevel10k導入前に対応フォントのインストールを行う。
自分はおすすめのまま、Meslo Nerd Font patched for Powerlevel10kを入れたが...
・他のフォントを調べたいなら
https://github.com/powerline/fonts
・windows terminalのフォント設定。
"profiles":->"list"のubuntuと同じグループ内に"fontFace" : "MesloLGS NF",を追記
・おまけ:デフォルト起動をubuntuにしたい場合は
"defaultProfile":→ubuntuのguid値を貼り付ける
・Powerlevel10k の導入
https://qiita.com/szk07/items/b15c38ec73e547a23439#powerlevel10k-の導入
やりたかったことのメイン
brewでインストールした後、
https://github.com/romkatv/powerlevel10k#zinit
のとおり、zinit ice depth=1; zinit light romkatv/powerlevel10k
を.zshrcに追記。
最後に.zshrcの見直しを行った。昔の設定だとデフォルト設定なのにsetoptしてるの結構あったので(いい加減)、マニュアルもとに見直したのであった。見直した版をgithubに上げておいた。
https://github.com/lyo/conf/blob/master/.zshrc.wsl2
・大企業運営の法人向けサービスにおけるOpenJDK移行事例 #ccc_g2a
スライド資料:https://slides.com/hiroyuki_onaka/jjug-ccc-2019-spring/#/
・OpenJDKの移行事例が増加。
・PATH、JAVA_HOMEを差し替えればいいというわけではない話。
・OpenJDK 11.0.1→11.0.2で起動しなくなった。
java.net.URLStreamHandlerに非互換変更が入っていた。
・マイナーリリースでも互換性がなくなるような変更が入ることがある。
・リリースノートの提供は11.0.3からだった
・OSSになっているので今後はGithubのコミットログ、Issueから変更を洗い出せる
→トラブル発生時の切り分け、調査方法も変わってくる。
・OpenJDKに移行すると古いDBのバージョンはサポート対象外になる。
DBのバージョンアップ、マイグレーションが必要になる。
・同様にアプリケーションサーバ(Tomcatなど)も。
→デプロイも必要になる。
バージョンアップに伴うアプリケーションサーバの仕様変更に注意する。
8.5以降だとファイル作成時のパーミッションの違いなどがある。
(昔、tomcatのバージョンアップに伴い、パラメータのデフォルト長が設定されるようになって、
長いリクエストを投げるところで動かなくなった苦い経験がある。リリースノートの確認は大事だと思う。)
・OSのバージョンアップも必要。
・継続的にインフラをメンテしているシステムはうまく行っているが、
そうでないケースは苦戦している印象とのこと。今がラストチャンス。
・開発リーダー1年目。メンバーのスキルアップのためにやっていること。#ccc_g2b
スライド資料:https://docs.google.com/presentation/d/1Xx5UPJkmy2dgzRloe8zaGGpEPWk1rhLiAMypK4TKRz8/edit
・メンバーのスキルアップ
・輪読会
題材は「リーダブルコード」「レガシーソフトウェア改善ガイド」。
本の内容がすべて正しいわけではない。参加者で議論できるが良いところ。
業務中に発表資料の作成可とした。一人で読み込むよりは粗くなるのがデメリット。
・心理安全性の確保。雑談できる雰囲気。ランチタイム、仕事のことは話さない。
(輪読を業務の一環と認めてるのは良い。チーム全体の技術レベルの底上げは見返りが見込めそう。)
・Javaコミュニティなう #ccc_cl
・用語の整理
・Java SE 12:仕様、 OpenJDK12:実装
・Javaの仕様策定プロセス
・JCP:Java Community Process。仕様を策定するプロセス。
・RI:参照実装、TCK:技術互換キットを作る
・JEP:実装ベース。仕様ではなく提案。並行して実装を進める。
使えそうならJSRに組み込まれる。ZGCとかはこっちの流れ
・OpenJDK ... Java SEのRIとして実装されるJDK。Oracleメンバーが80%を開発。
・JavaEE ... 開発停滞→ JakarutaEEへ。
Jakaruta EE8→2019年後半にリリース予定。TCKも移管された。
・ 新機能はjavax名前空間は使えない→商標問題。
・javax.*はjakaruta.*に移行する方向性→ただし、いつ、どのようにやるのか具体策は未定。
→全てのwebフレームワークに影響が入る。
影響範囲が広いのでリグレッションテストができるようになっていたほうが良い。
・Javaのリリースサイクル
・半年に1回定期アップデート。開発が間に合わない機能はドロップされる。
・サポートは6ヶ月間←限られたリソースを言語の進化の方向に投入したいから。
Javaエンジニアとしては追いつくようにしたい。
・LTSは8→11→17→23。LTSだから大規模なアップデートになるということはない。
...が、LTSだからなるべく機能を入れる、ドロップさせないようにする力が働くかもしれない。
今はVMの改良を頑張っているフェーズ。
(dockerなどのコンテナ技術、サーバレスアーキテクチャだと
起動時のフットプリントの軽さを求める流れになっているからだろう。)
・カンファレンス参加時の心構え
→don't be shy. 周りの人とコミュニケーション取る。
・マルチテナントECシステムにおける拡張性と最新性の両立 #ccc_c3
スライド資料:https://www.slideshare.net/ssusera756b0/ec-146376859
・標準ロジックの上にテナント毎のカスタマイズロジックを組み込む為の実装方法
やり方は2つ
・組込版→継承を用いた方法
・クラスローダーを用いて店舗毎にロードさせるクラスを変更させる。
・クラスローダーを用いる正当な目的とは
・同一JVM内部でのスコープ分離。別のクラスローダーにロードされると
同一クラスでも別クラス扱い。今回のケースはコレ。
・クラス定義の動的取得、変更→ネットワーク経由でクラスを動的ロードとか。
・URL→店舗情報→ファクトリメソッドにてカスタマイズクラスのインスタンスを取得。
・API版→AOP、アノテーションを用いた方法
・AOPの仕掛けを作るときにJavassistを利用。
・セッション情報の維持
・最近はjson形式でのエンコードが多いかも。
・Javaのシリアライズ機構を使っている。
・やり方は以下の3パターン
・デフォルト
・シリアライズ対象外オブジェクトが含まれているケースなどカスタマイズが必要な時
・writeObject/readObject
・writeReplace/readResolve→インスタンスそのものをすげ替える
・テナント毎にDB情報はどのように切り分けしている?
→スキーマによって分けている。
・テストエンジニアが教える JUnitを書き始める前に考えるべきテスト #ccc_e4
スライド資料:https://speakerdeck.com/nihonbuson/jjug-ccc-2019-spring
・テストの目的(JSTQBによる)
・欠陥の検出。→デバッグして要員特定・修正はテストに含まれない
・対象ソフトウェアの品質レベルが十分であることの確認
・十分≠完璧。バグがないことを示すことはできない。
・意思決定のための情報提示
・顧客に製品の品質を示す。上司に意思決定の判断材料を提供する
・欠陥作り込みの防止
・早期にテストすることの重要性。開発フェーズの早い段階で間違いに気づくことが重要。
・参加者ペアでチェックリスト作成ハンズオン
・テストを先に作ることで、プログラムはないけど仕様の不明な点が洗い出せる。
・テストケースを作るときに何故それが必要か説明することはできるか。
・よくある都道府県を選ぶドロップダウンリストの例だと...
・2つ。リストの最初と最後を選択できるか。
・4つ。都・道・府・県のいずれか。
・文字数のパターンで抽出
・各地位毎。例えば送料計算があるからなど。
・極端な例だと47全て。コード上に47パターンをswitch caseで実装しているところがあるから...等。
・テストケース名、テストドライバメソッド名を日本語の表記にするとわかりやすい。
・QAチームとの連携
・単体、結合→開発者が品質を担保しなければいけない。
・システムテスト→業務一連の流れ。QAチームが見たいのはこのレベル。
単体・結合テストの肩代わりをさせてはいけない。
・checkとtestの違い
・checking→意図通りに動くか確認。自動化テストとはcheckingの自動化を指す。
・testing→製品破壊的なことをしても問題がないか確認。QAチームがやりたいのはこっち。
・開発者はQAチームにcheckingをさせることがないように心がけること。
→QAチームがtestingに注力できるように。開発者の心構え。
・自動化テスト→本当に肝心な部分、お金のかかる部分を自動化する。
手動でやっても意味のないテストを自動化しない。
・オススメ本
・ソフトウェアテスト技法ドリル―テスト設計の考え方と実際
・[改訂新版]マインドマップから始めるソフトウェアテスト
・ソフトウェアテスト教科書 JSTQB Foundation 第3版
(・発表内容と直接関係はしないが、セッション中にリアルタイムでアンケートを取って、結果をみんなで共有できる仕掛けが面白いと思った。)
・ゴールドマン・サックスにおけるApache Beamを用いたビッグデータ処理の紹介と実例 #ccc_a5
・GSの社員構成→社員の1/4以上はテクノロジー部門所属の技術者。
社内で利用するソフトウェアの9割を内製→他社との差別化。
・Githubでも様々なソフトウェアを公開している。Eclipse-collections、reladomo(Java ORM)等
・Apache Beam
・GoogleがApacheに寄贈したデータフロー向けフレームワーク。Batch+strEAM
・複数言語に対応しているが、日本語向けの文献は少ない。
・バッチとストリームの使い分け
・バッチ:データセットが限定的かつ不変
・ストリーム:データセットが限定的ではない、または可変
→ GSで利用してるのは主にバッチ。月次レポート処理等に利用
・構成要素は主に3つ
・Pipeline
・Pcollection
・Transform
Input → Pcollection → Pcollection... → Output
Transform
Pipeline
・対応 I/O
・file-based、messaging、database
・構築したパイプラインの上でSQLを実行できる。
Beam SQLと呼ぶ。joinもできる。
クエリのオプティマイズも内部で行なっている。
・Apache calsite
・SqlTransform
・Row
・コードの構築
・pipelineを作る
・pipelineを設計する
・読込
・変換
・出力
・pipelineを実行する
・これらをJavaのコード上で行う。
パッと見た感じはFluent Interfaceを多用し、
がしがしメソッドを繋げるような感じのコードだった。
・元々はこれらを構築する担当がいたようだが、pipelineの構成を
GUIで組めるようにカスタマイズしたらしい。デモを拝見したが、
今は亡きYahoo Pipesのイメージだ。GUIを使って作成したジョブは
Flinkに渡して実行される構成のようだ。Flinkの他Sparkでも実行できる。
・質疑応答
・どのぐらい処理時間が短縮したか
→重いレポートだと40-50分だったものが1分以内で応答が返る
・テストはどうやっているのか
→ Transformに対してテストを行なっている。
(・有用なライブラリを用いてただコーディングするのではなく、
GUI使って構築作業自体を一段メタ化しているのがすごい。
・並列性の高い参照処理なら確かにマシンパワーお金をつぎ込めば
つぎ込んだ分だけ、処理短縮に効果を発揮ししそうだ。)
・JJUG会長と一緒に考えたSpring Boot x JavaScript x IntelliJ x アジャイルというモダンな新人研修を今まさにやっている話 #ccc_e6
スライド資料:https://speakerdeck.com/masatoshitada/modern-new-employees-training-spring-boot-javascript-intellij-agile
・従来型の新人教育と現場との乖離
・従来型教育の課題
・設定された課題を達成することがゴールになっている。
・チーム内コミュニケーションが文書、口頭伝達のみ
・技術がダサい(Java+Servlet+SQL only)
・学習が受け身→技術変革が次々と発生するので主体的な学習が求められる。
・コミュニケーション
・従来型 → フォルダをバージョンごとに切る
・モダン → git、gitlab、チャットツール(slack)
・研修のカリキュラム例
・IT基礎
・Java(15年変わってない。日付に関する内容もJava8導入のDatetime APIには触れない)
・web(JS扱わないけど、最近はクライアントサイドの開発が必須)
・開発演習(EC or予約サイトが定番。構成管理(git)は使わない)
→登壇者の感覚だと、世間の9割がこのタイプの研修。
・モダンな研修にする際の課題(カサレアルは研修を作る会社なので踏み切れない)
・モダンな研修にしても売れるかわからない
・Strutsな現場が多い
・人事が技術に疎い
・モダンな研修
・クライアントサイドからサーバサイドまで一通り自力で作れる
・各種公式ドキュメントが調べられる。英語読めなくても翻訳する姿勢が大事。
・研修で用いたシステム構成
・SPAアーキテクチャ
クライアント | サーバ
React | Spring Boot
material-UI | JDK11
・Servlet APIは隠蔽される
新人教育レベルならServletの知識は不要と判断
・Servlet、JSP、JDBCは扱わない→SpringDataJDBC、MyBatisを利用
・JDKはAdaptOpenJDKを使用→自宅学習でもライセンスを気にせず利用できる。
・開発環境
受講生ローカル 研修サーバ
IntelliJ+git ⇆ docker(擬似クラウド)+GitLab(講座内容)
・講座スケジュール
・技術研修は4月中旬から6月中旬まで。2ヶ月ぐらい
・全体概要説明とGit(2日)
・クライアントサイド(8日)
・サーバサイド(13日 Java含む。Java自体は軽めの2日)
・開発ワークショップ(13日)
・ソースコード静的解析ツールを導入(esLint、CheckStyle)
→明らかにコードは綺麗になる。レビュー負担の軽減。
・研修を変えたことに変化
・現場の技術に馴染むのが早い
・SPA API アーキテクチャ 用語の理解
・理解度は例年通り。Servletを学んだケースと変わらないが、学んだ幅が広いので、
受講生の学ぶ意欲は高い。→学ぶ範囲が広いので要所要所でまとめ、復習する時間を設けた。
・クライアントサイドからサーバサイド技術を学ぶ順番が良かった。
GUIで自分たち作ったものに対する実行結果が早く確認できる。興味を引きやすい。
・ServletやJSP、JDBCは触れなくても問題がなかった。
SpringでもServlet技術を要するのはフレームワークの動作自体に手を加える限られた人。
・企業によってこの方法に合うケースと合わないケースがあるだろう。
・今回の形で実施したケースはまだ3社のみ。
・質疑応答(登壇者と同じようにプログラミング研修に関わっている方が会場内には多かった)
・プログラム初心者の反応はどうだったか
・Servlet研修時の反応と変わらない。ルールが多いので伝える必要あり。
・研修を始める前の受講者のレベルは
・一例での研修対象者は10人弱。
経験者は半分、トップクラスだと学生からコーディングをたくさん
やっていたメンバーもいる。少し触れた程度の経験者は1/4。残り1/4が未経験者
・今回の研修は全員名経験者を想定して作成している。
・講師一人で20人見ている。でも静的解析などのツールの助けが必須。
・受講者と講師の役割分担
・元々はサブ講師がスクラムマスターとプロダクトオーナー役を兼ねた。
→受講生側に作成側の意識を醸成するためにプロダクトオーナー役は
別チームの受講生としている。
(・研修のアップデートは大事だけどかなり思い切った構成だと感じた。特にSpring採択。
・一応未経験者向け研修とのことだったが、最初から割と知識がある集団がいるからよりうまく回っていたのでは
無いかなぁと想像。会社によって合う合わないはかなり意見が分かれそう。
・受講生側のスキルも世間一般よりも高いのでは無いかと感じる。
・Functional Spring Cookbook #ccc_a7
スライド資料:https://docs.google.com/presentation/d/1-0NopTfA-CGiCNvKPDOH9ZDMHhazKuoT-_1R69Wp8qs/edit#slide=id.g566754e519_6_0
・Functional Springという用語があるわけでは無い。
・annotation style→easy
・Functional style→simple
・simple(必要なものだけ)≠easy(最小限の作業)
・Spring は二つ通りのやり方がある
・Spring MVC Mvc.fn
・Spring WebFlux.fn(Spring 5.1から)
・アノテーションではなく、関数でルート定義を書く。
(このスタイル、Angularのrouter定義を彷彿とさせるやり方だと感じた。)
・Githubにサンプルあり。
・Bean Registlation
・application context→あまり書かない
・@Compornent →scanさせる方法
・@Bean → これをprogramaticにさせる。
・HTTP Client reactiveに使う方法の紹介。cash→メモ化
・Bean Validation 標準で用意されているものは使いづらい
→作った。YAVI;やばい Yet Another Validation
・Either API Either...モナド
・DataBaseAccess
WebFlux.fnではR2DBCが使える(rはReactiveから来ている)
・@によるアノテーションを取り除くと...フットプリントが小さくなる。起動が速くなる。
・サーバ起動デモ→アプリケーションサーバの立ち上げ0.7秒!
・SpringFu 実験レベル。まだプロダクトで使ってはいけない。
・ServletとSpringのコードが同じようにかける。サンプル例だと1行違うだけ。フレームワーク固有の書き方をうまくラッピングしてくれている。
(このような仕掛けが発展すれば一個前のセッションで話していたServletの技術は無視しても良くなるのかもしれない。)
・海外からの参加メンバーが多いけど、相変わらず言語の壁を感じてしまう。もったいない。今回はOracleの開発カードの電池をもらえたぐらいのコミュニケーションしか取れなかった。開発者が多いけど英語のセッションが増えてきている。次回は挑戦してみたい。(会社の同僚はグイグイ話していた。すごいなぁ...。)
]]>
■Javaはコミュニティの力で再び偉大になれるのか(JJUG基調講演) #ccc_e1
資料:https://www.slideshare.net/yusuke/java-98886920
・ライセンスの話(コピーレフト、準コピーレフト、非コピーレフト)
・Java EE Gurdians → 後のJakaruta EE
仕様の策定プロセスもOracleから移管
・Eclipse MicroProfile → マイクロサービスを意識したEEの仕様
マイクロサービスはSpring Boot v.s. MicroProfile という構図になりつつあるので
マイクロサービスに興味がある人は Micro Profileの話題をキャッチアップしたほうが良さそう。
・リリースモデルの変更
2018/09 Java11 (ここでOraclejdkとOpenJDKが同一になる。)LTS
その次のLTS → Java17
Java11リリースまではJava8はサポートされる。
今後はマイクロサービス、コンテナ対応が主。今のJavaの問題はフットプリント、起動時の重さが問題。Dockerや仮想環境のことを考慮すると、マイクロ秒での立ち上げが要求される。昔Javaが重いと批評されていた時期があるが、それと似たような感じにまたなっている。でもこれは解消される方向に向かうだろうとのこと。
・Javaのカルチャー:コミュニティーがJavaを支えている。誰でも関係者になれる。
(最終的にはSunやOracle決めているイメージがあったが認識を改める。)
HHKBでのイベントは約6年ぶりだったので(前回のレポート)面白そうな話が聞けるかなぁと思い参加してみた。
残念ながら家事に手間取ってしまい、やや時間を過ぎたぐらいで到着。
会場では最初の和田先生のビデオ講演が少し始まっていた。最後の方でinfinity 60% keyboardがHHKBを参考にしている話を紹介したあたり、完成品を長く使ってほしいという話が印象に残った。自分がHHKBを使いはじめたのは二十歳の頃、動画でも出ていたぷらっとホームで買ったものだったので、なんだかんだで長い間、この完成品に触れられていたのは幸せなことである。
ミートアップでは動画の通り、面白い要望が出ていた。ハードウェアでのカスタマイズ機能が今後出るなら色々面白いことができそうだ。最近40% keyboardの世界も面白そうかなぁと思っていたけど、ちょっと踏みとどまりそう。
会場で誰かが言っていたけど、末永くこの商品が続けば良いと思う。もし壊れてまた買いたいと思ったときに商品が無いのは辛い。そのためには色々ユーザの要望を取り込んでいけなければならないのもわかるが、できればUS版はこのままの形で残しておいてほしいと思う。個人的には白の経年による黄ばみがなんとかならんかなぁと思うけど、懇親会では年季の入った感じと評されてまぁ、それも悪くはないのかなぁと思い直した。
その他、会場で感じたこととしては、HHKBが日本だけの閉じた世界ではなくなりつつあるのだなぁと思った。いつかこのミートアップが日本限定でない日が来るのかもしれない。(HHKBで告白された中国のエンジニアが羨ましい。)
懇親会では私も前に作ったBTアダブタを持参。
各自のキーボードを持ち寄せて話ができたので面白かったし、何より同じものが好きな人同士の空間というのは居心地が良い。
このイベントで一番ビックリしたのは帰りにキーボードが一台増えていたことだろう。
(初代proが壊れるまで我慢と思っていたけど、13年経っても全く壊れる気配は無く、会場特価だったので思わず買ってしまった。)
・キートップ差し替え
昔憧れていた赤Ctrlも購入。手元で通常pro版と押し比べができるようになったので改めて書くが、やっぱりtype-Sの方が押し心地は軽い。イベントに参加して安く購入できた喜びもあるが、type-Sに触れられている喜びのほうが勝っているので、やっぱりとっとと購入すべきだったかもしれない。
・最寄り駅到着
ホテルから出られる準備をして、DLRを使ってCutty Sark for Maritime Greenwich駅に到着。途中、ビルの間を通ったりして、やっぱりこの路線は ゆりかもめ っぽいなぁ等と思う。3日目から感じていたことだが、ロンドンは色んな人がいるがアジア人の割合は低いように思う。特に白人や黒人はみんな体格が良いので電車内だとなかなか肩身が狭い...。
・グリニッジ大学
ちょっと道迷いそうになりつつ、公園を目指す途中。妻のスマフォが役に立った。
確かこの辺りで、黒人の学生風の女性に話しかけれ、中国人かと聞かれた。隣には確かにアジア系の女学生らしき人もおり、何か聞きたかったのだろうか。日本人だと答えると気さくに「おはようございます」と日本語で返してくれたのが記憶に残っている。
・付近の町並み
この辺も昔からある家が多いのだろうか。重厚な感じは他の町と余り変わらなかった。
・グリニッジ公園到着
少し奥の方に行くと丘になっていて、なんとなく天文台があるんだなぁということが分かった。
・丘の途中
少し登ってちょっと後ろの方を振り向くとシティがよく見えた。
・グリニッジ天文台
丘を登り切って天文台到着。(2枚目ぼけてる...。)
・グリニッジ天文台の中に入ったところ
中には天文台など、天体系の話を取り扱うゾーンと、やっぱりグリニッジということで時間を扱うゾーンがある。時計がたくさんあった。
・本初子午線
Tokyo発見。
本初子午線を跨いで一枚。確かこの頃、ちょうど仕事でもGMTを意識する機会があったので、なかなかタイムリーにグリニッジに行けたなぁと思う。
・帰り道にまた写真を何枚か
車の量は少し多いが、シティに比べれば落ち着いた雰囲気の良い所だ。
この後は乗り継いでまたTubeに載ってピカデリーサーカスに向かった。時間にあまり余裕がなかったので写真は無し。昔の上司から旅に行く前に頼まれたガスコインのレプリカユニフォームはないかと店員に聞いたが、「old player」と苦笑される憂き目に遭う。(そもそも自分の英語力ではガスコインは通じず、筆談で対応。ギャスクインと発音すべきであった。)
仕方がないので、妻の提案で別の店で売ってたイングランド代表のレプリカユニフォームを買うことにした。陽気そうな中東系のおっさんに取ってもらってレジに連れて行かれたがおっさんから想定の倍、50ポンドぐらいの金額を提示される。そんなに高いと買えないなぁと言ったら、レジを打っていた同じ中東系の若い男性が冗談で半額だよと言った。(あぶねぇ...。)
レジの若い男性がおっさんに「アジア系に冗談は通用しないから止めろ」と言っていたのを覚えている。日本人だろう?とレジの男性は言っていた。イギリスで日本人だと言ってきたのはこの人だけだったな。客商売してると分かるんだろうか。
時間も迫っていたので、お土産を買ったらささっとホテルまで帰って、バスでヒースロー空港に向かった。
・出発直後
・ちょっと経過
疲れもあったので、4時間ぐらいはぐっすり寝たろうか。ちょっと気づくと予想以上に進んでいてちょっとビックリ。時差は行きよりもはっきりと体感できる。
偏西風の影響を直に体感。行きよりもやっぱりスピードが出ている。
・迂回
帰りもやっぱり北朝鮮は避けるようだ。突然旋回した。
このあとは仁川空港でちょっと休憩して再び搭乗。旅行に持って行ったビーフジャーキーが検疫で引っかかることを知り、機内であわてて食べ始め、あごを痛める。
・成田空港着陸まであと少しのところ
出発時にはよく分からなかったが、日本の夜の町並みにはカラフルだ。少し白系が多いように思う。無事着陸して帰国すると安堵感が沸いてきた。何故か分からないがやたら嬉しかった。
イギリス滞在中は結局時差に慣れないままだった。そのおかげかは分からないが帰国後、時差には苦しまなかった。いつもの日常に漸く戻ってきたという感じだ。
・個人的な買い物
欲しいモノはほとんどタンクミュージアムで購入。
・その他雑記
持って行くべきだったもの
①スリッパ、クシ、歯ブラシなどホテルで使うモノ。向こうのホテルにはアメニティは想像以上にない。
②ハンドクリーム。これは向こうの洗剤が肌に合わなかったからか、やたら肌が荒れたので。
③ネックピロー。機内で寝る時間は長い。座ったまま寝るのは大変。
旅行前に準備すべきモノ
・両替...空港内のレートは高い。幸い高いレートのまま£→¥に戻すことも出来たが、国内で安く交換した方が良さそうだ。ポンドを円に戻した後はカード払いでやり過ごす。
次回への反省
・TAX Free。今回は全然利用せず。もう少し余裕があったらなぁ...。
こんな感じで初の海外旅行は終わったのだった。やはり異国の地はなかなか神経を使うので、疲れる。その分今まで見たこともないような景色を見ることが出来るので、旅行にハマる人の気持ちもなんとなく分かるようになってきた。
]]>・WWIコーナー
塹壕戦が再現されていた。WWIはやっぱり凄惨な感じ。
・マークI
しばらく塹壕を進んでいくとマークIがいた。付近に逃げ惑うドイツ兵も置かれていたが、この鉄のかたまりが突っ込んできたら逃げたくなる。
・マークシリーズ大量
塹壕エリアを抜け出すとマークシリーズ一色。流石にこれが生み出された国の博物館なだけはある。
・WWIIエリア
入って早々Tiger IIシリーズだらけだったので驚いた。Tiger II好きからしたら最高の光景である。(連合国側からしたら最悪の光景かもしれない。)
平日だからか、館内は閑散としていた。客よりもスタッフ(整備関係だろうか?)の方が多かったかもしれない。写真を好きに、自分のタイミングで撮れるのは非常に良かった。
・後ろからもう一枚
最高の空間だ...(´д`*)
・近寄ってもう一枚
こんな感じで接写しまくった。実物を近寄って見れるというのは幸せなことだ。
・柵の中のTiger I
残念ながらTiger Iは柵の中で閉じこもっていた。整備中なのだろうか。フューリーは見たので、ああ、これが映画の中で動いていたヤツかぁと思うと感慨深い。
・Luchs
ゲームやってたら大好きになってしまったLuchs。これも色々写真撮ったのでプラモ作りの参考にできそうである。
・Pz.IV
車体はD型、砲塔はH型から持ってきたというレアな一台。
この系統のプラモを何台作ったかもう忘れてしまったが、こうして実物を見られるのは本当に嬉しい。35倍の大きさが実感できる。
・記念コイン
ああ、ディズニーランドとかで見る記念コインを作るヤツだ...と思ったら本当に1ペニー硬貨と入れて作るタイプでちょっと驚く。日本じゃ硬貨を加工したら法律違反だからなぁ...。実際に作るときはポンド硬貨も入れてハンドルを回す。ハンドルは結構重かった...。
・カフェの脇にあったチャレンジャー
その昔、父親がタミヤのプラモを作っているのを見て、面白そうだったから作りたいと思ったのを覚えている。それがこのチャレンジャーだった。以来、プラモや絵、プログラミングと何かしらモノを作ることの面白さに気づいたのであった。そう考えると今の自分の生き方を決めた戦車であると言っても過言ではない。
・フューリーコーナーの落書き再現
カフェの近くにフューリーコーナーがあったので見ていたらさりげなくナチの標語。
・II号戦車の車体
一部屋抜けて少し開けた部屋に移動。こちらもイギリスやアメリカ、ドイツの戦車などが展示されていた。昔作ったドイツのII号戦車などもあった。これは車体前面のアップ。プラモやゲームだとペラペラ装甲のイメージだけど、それでも実物だと重みが伝わる鋼鉄の板である。対人間なら十分脅威だったのだろうなぁと想像する。
・隠れた戦車の著名人
ドイツからはポルシェ博士。(戦車好きからすると隠れてない)
・Panther
後ろから。中戦車なのに、結構なでかさ。
・KV-I
これも中学時代に作ったなぁ。こいつからは少し怖さを感じた。戦車って今までは面白い、楽しいモノというイメージが強かったが、やっぱり本物はちょっと怖い...ということが実際に見て分かったのは一つの収穫である。宮崎駿氏が「泥まみれの虎」で戦車は恐ろしいモノと言っていたが、なんとなく分かった。相手にしてはまずい威圧感がある。想像よりもかなりでかいからだろうか。当時のドイツ軍人はよくまぁこれに立ち向かったモノだと思う。自分が触れ合っているのがプラモやゲームでなんとまぁ、幸せなことか。
・お土産コーナー
戦車博物館なので戦車グッズが多い。プラモも例外ではなかったが、これは日本のプラモショップの方が品揃え豊富な気がする。
・大量の書籍
当たり前だが、洋書(?)コーナーが超充実してるのは羨ましい。
・再びWool駅へ
博物館にはもう少し居たかったが、イギリスのこの時期は日の沈みが早い。流石に異国の地の夜道、それも街灯がほとんど無いような道を歩く勇気はないので、15時になるちょっと前ぐらいには博物館を出て出発。行き同様、帰りも途中で人にほとんど合わなかった。一人だけ、途中の分かれ道のところで「hi」と声をかけてくれた人がいたぐらいだった。
・駅前到着
だいたい15:30ぐらい。ほぼ夕方って感じの日の傾き加減である。
・構内の橋から一枚
さらばWoolの地。終点からさほど離れていないため、ほぼ時間通りに電車到着。このままwaterlooまで帰った。
・waterloo到着
到着時刻は確か18時半ぐらいだったろうか。早朝には気づかなかったが、ターミナル駅とあってやっぱり凄い人の数だ。
・駅周辺散策
テムズ川の方に行き、ロンドン・アイ等を見たり、対岸のビッグベンなどを見た。
アンディ・ウォーホル風、工事看板がお洒落。夕食もこの辺のインド料理屋で済ませた。
・再び駅内へ
戻ってみると大勢の人が電光掲示板を食い入るように見ていたのが印象的だった。
・ピカデリーサーカス
自分達はこのあと、お土産を探すために地下鉄でピカデリーサーカスに行き、付近を散策した。その後ホテルに到着。確か22時半ぐらいか。この日は疲れ切ってそのままベットに倒れ込んで寝てしまい、早朝に風呂に入った。
・切符購入
ホテルがRoyal Albert駅のすぐ近くだったので、早朝から行動開始。ボービントンから帰ってきた後も色々回ってみたかったので、1日乗り放題のトラベルカードを買うことにした。ピークとオフピークの2種類ある。オフピークの方が安いが、午前9時30分以前は使用できないので、ピーク・トラベルカードの方を買うしかない。
・路線図
流石元祖鉄道の国。東京と同じぐらいたくさん地下鉄が走っている。料金は○○駅から××駅がいくら...という考え方ではなく、ゾーンという領域が設定されており、1~3ゾーン内の移動は□£というような料金設定になっている。
・Royal Albert駅
早朝5時ぐらい。緯度が高いのでまだ完全に暗い。乗客もまばらであった。すぐ近くのCanning Townという駅までまずはこのDLRという、高架線&無人運転という、ゆりかもめ的な電車に乗って向かった。Canning Town駅でtubeと呼ばれる地下鉄に乗り換え。Jubileeラインという路線でwaterloo駅に到着。だいたい30分ほど。地下鉄は大江戸線のように電車の上部に向かって狭くなるタイプだった。トンネルも半円状でtubeと呼ばれる理由が分かったような気がした。
・切符購入(写真は帰ってきたときに撮った)
waterloo駅到着後にトイレを済ませ(30ペンスかかった!)、South West Trainsの無人券売機で切符を購入。このページを参考に買いたいチケットの種別を決めて買えば特に問題はなかった。チケット種別を往路(Return)、座席タイプをstandard(少しよく分からなかったのが電車の出発時刻?を打ち込むところで少し戸惑ったぐらいか。)にして発券。流石に60£越えなのでちと高いが、距離を考えればしょうがないか。切符は途中、車長が見回りに来るので、その時に見せてチェックをもらう。
・waterloo駅の電光掲示板
電光掲示板を見てSouth West TrainsのWeymouth行きを調べる。会社のホームページに時刻表があるので、事前に何時行きで何時着なのか調べられる。自分達は6:30発の電車に間に合わせるため、30分以上早くwaterlooに着いたが、トイレやら発券やら慣れないことを色々やっていたら割と良い感じの時間になっていた。プラットフォームの番号が出ているので、そこに向かう。(確定するまでは--という表示になり、どこに停車しているのかは分からない。)
waterlooはターミナル駅のため、かなり大きな場所だった。屋根の方を見ると半筒状になっており、機関車トーマスのイラストを思い出した。
・South West Trains
事前調査で途中、分割されて先頭五両までしかWeymouth行きに行けないという罠もあるみたいなことを知っていたが、乗ったこの車両は5両しか無く、その様なことはなかった。遅れもなく、ほぼ時刻通りに出発できた。
・South West Trains の路線図
南西に延びているのがよく分かる。waterlooは一番右上、目的地のWoolは左下終端から4つ手前なので、ほぼ、端から端へ移動する感じである。
・車内から
7時近くになってようやく明るくなり始める。車内も結構ガラガラだった。
朝飯も省いてきたので、少し日本から持ってきたおやつを食べていた。
どのあたりだったか忘れてしまったが途中、水辺付近を走るときがあってその時に撮った写真だ。
・自転車置き場
ちょっとカルチャーショックだったのが、車内への自転車持ち込みokというところ。途中、何人かここに停めていた。
南西に行くほど、緑が多くなる。途中湿地帯?みたいなところを通った。草原と言うよりもコケの緑が多いような感じ。
・Wool駅到着
だいたい9時ぐらい?予定よりも10分ぐらい遅れ。出発時刻は定刻だが、その後ずるずる遅れる傾向にあるみたいだ。Woolは無人駅なので、結構寂れていた感じだが、住宅はそこそこあった。ただし、店の類とかはそんなになかったように思う。
・駅前の地図
右下が現在地、左上に目的地のボービントン博物館(Tank Museum)がある。
明るいし、開館が10時で時間もあったので、歩いて行くことにした。
駅を出て右手に踏み切りがあるので、そこを渡ってしばらくまっすぐ。
左手側には草原というか、湿地帯みたいな開けた場所がある。
少し進むと分かれ道。左側の狭い道のほうを通る。
川渡って、しばらくまっすぐ。
道なりに向かってそのまままっすぐ。
10分、15分ぐらいして振り返ったところ。さっきの車道と合流。
緩やかな上り坂を上ってまだ真っ直ぐ進む。
戦車訓練中の看板。明らかに戦車がある感じである。
もうちょっとだけ進むとようやくボービントンの文字。
看板の案内通り、左手に向かって進む。木々の多い、ちょっとうっそうとした道を通る。下り坂から上り坂を歩いて
まだひたすら真っ直ぐ歩く。途中に学校のような古い建物があり、周辺は牧場のようだ。
この辺で戦車にすれ違った。(見直して気づいたが、道路に履帯の後がある!)実際の動く戦車は音が滅茶苦茶でかく、砲は付いてなかったが、車体がこっちの方を向いていると結構怖い!
遠いので少し不安にはなったが...漸くゲート&戦車前に到着。だいたい30-40分ぐらいは歩いていたように思う。途中、街灯らしきモノは見つからなかったので昼間なら良いが、暗くなったら歩きたくはないルートである。
で、また道に沿いにしばらく歩く。
途中いくつか戦車を見ながら、
インターネットで見たことのある建物に漸く到着!
・Seven Sisters到着
簡易な展望台と下に降りるための階段があり、これはそこから撮ったもの。周辺の風は強く、木々が全て傾いて生えていた。この日も海に向かって歩くと強い抵抗を感じるぐらい風が強かった。寒さと強風で耳が痛くなったのを覚えている。風が強いこともあり、周辺の家の窓は小さいそうだ。
海も荒れている。前評判通り、ドーバー海峡というのは荒れやすい海なのだな。
海の向こうはフランスなのだが、向こうも似たような崖になっているようだ。モネも「エトルタの断崖」を描いたときはここと似たような崖を対岸側で見てたのだろう。
前に見た絵画の世界が本当に目の前に広がっているみたいで、感無量だった。
・白亜の崖に近づいたみたところ
白亜はチョークの原料になる。白亜自体も脆い。落ちてた木片をすこし当てるだけで木が白くなり、確かにチョークなんだなぁと感じる。添乗員さんの話によると風や潮の力によって年30cm程、浸食されているらしい。
・近くのホテルで少し遅めの昼食
前の晩のフィッシュアンドチップスでも思ったことだが、何故グリーンピースがたくさん出てくるの...。
・ロンドン市内(ビッグベン周辺。)
・ウエストミンスター寺院
周辺をしばらく歩いていたが、昼間見るよりも夜の方がやっぱり綺麗だ。昼間は曇ってぼんやりしているからかもしれない。
・バッキンガム宮殿
掲げられている旗の種類で女王陛下が宮殿に居られるかどうかが分かるらしい。この日は運良く宮殿内にいらっしゃったようだ。
・ピカデリーサーカス周辺
ピカデリーサーカスはロンドンの中でも繁華街なので、人がたくさんいた。この日は近くの中華料理屋で夕食。久々の白米だったので美味しかったのを覚えているが、まだこの頃もイギリスの時間感覚に慣れず、徹夜明けという感じだったのであまり食べれなかった。2次会で飲みに行こうとしていたお年寄りグループが居たが、なんて元気なんだろうと思ったものだ。
・ホテルの朝食
朝食はバイキング形式だった。ベーコンが厚く、美味しかったのを覚えている。
残念ながらイギリス滞在中で一番美味しいものにこの時点で出会っているとは、この時点では想像もしていなかった。
・ロンドン塔
バス移動中にちらっと見ることが出来た。
移動中に添乗員さんがBFコンセントの裏技を教えてくれた。どうもBF型のコンセントは真ん中にボールペンの類を突っ込めばC型コンセントでもさせるらしい。知らんかった...。
・落書き?
trump wall...時事ネタかな。
・高速道路移動中
なんか急に地元の高速を走ってるような感覚に襲われる。左車線、右ハンドルで日本と変わりないのもそう感じる一因となっているのかもしれない。
ちなみに標識のスピード制限を表す数字は時速何㎞...ではなく、マイル表記なのだろうだ。ややこしい。
・羊
イギリス滞在中に思ったが至る所に羊がいる。歩き回る羊を見かけることは少なく、黙々とその場で草を食べ続けていた。
・Bibury到着
オックスフォードを経由して、Biburyという小さな町に到着。ロンドンの赤茶レンガと違って白色系のレンガ目立つ。閑静な町だった。
・swan hotel
シェイクスピアの時代からの建物らしい。日本で言うと戦国時代か。
・町を流れる川
この辺歩くとき、ちょっと肌寒かった。
白鳥もいて、一緒に写真撮れたりした。
この写真は更に奥に行ったところの写真。更にこの先を見て、またぐるっと戻った。
途中公衆トイレにも寄ったけど、トイレ入るのにお金を払う必要があり、カルチャーショックを味わう。Biburyの後は近くのBourton-on-the-Waterに向かった。
・Bourton-on-the-Water到着
こっちの町は黄色のレンガ目立つ。確か少し小雨が降っていた。イギリスの天気は目まぐるしく変わる。一日中同じ天気と言うことはなく、降ったりやんだりを短時間で繰り返す。そのためかどうかは分からないが、イギリスでは雨降っても傘は使わず、フードでやり過ごす人が多いようだ。最近傘を使う人も増えてきたが、それはアジア系移民の影響らしい。現地では雨のことをシャワーと呼ぶみたいだ。
・昼食のカフェの道中
こういった小道は眺めているだけで楽しい。カフェでは紅茶(イギリスというと紅茶のイメージが根強いが、アールグレイなど、特定銘柄にこだわる人は少数なようで、大抵の場合はイングリッシュ・ブレックファスト・ティーらしい。)カフェではサンドイッチやスコーン、あとケーキを食べてしばらくゆっくり過ごしていた。ツアーのおばちゃんたちが「please おかわり」と言ってたのを無駄に覚えている。
・豪雨
カフェでゆっくりしていた原因でもあるが、すごい雨だった。手前のカモが少し可愛そう。
しばらくすると雨も小雨に戻ったので散策再開。
付近のお土産屋さんっぽい店で妻にアクセサリーを、自分は記念品としてマグネットを買った。その後は付近のホテル(お城みたいな感じの所だった。)
・夕食
夜は別の町に行って夕食。写真の店ではないが、パブっぽい店に入った。
名物のフィッシュ&チップスを食べる...。が、どうも体内時計はまだ日本時間らしく、徹夜状態なので、あまり食欲はなく、完食できなかったのが心残り。
どうも味付けは出された後に各が好きにやるらしく、塩やケチャップ、レモンをかけて食べる。おそらく下味処理とかはしてないのだろうか。そのまま食べるとエライ淡泊な味だった。
・ホテル内散策
ホテルに戻った後はホテル内を散策した。暖炉があったりとなかなか良い雰囲気のホテルだった。寝る場所もこのホテルが一番暖かく、寝やすかったが、寝不足による胃痛であまり快適でなかったのは覚えている。この日の終わりになってもまだ体内時計は日本時間のままのようだった。
・中国北東部上空
既に雪に覆われていて凄い寒そうな光景だった。
・旅行の役に立つかもと思って買ったコンパス。
このコンパス、アウトドアな感じで気に入った。角度を読む用のレンズが着いている。調べてみたらレンザティックコンパスというようだ。仁川~ヒースロー空港だと、ロシアの上空を地図上では弧を描くようにして飛ぶ。なので、最初は北東方向だが、徐々に南西向きへと針が変わり、だいたいどの辺の位置か想像が着く。
機内では同じツアーの関西のおばちゃんが隣だった。おばちゃんはお酒をおかわりしまくってやりたい放題だったのを覚えている。話し出すと全然止まらない。話を聞くと一人でアフリカにも行っていたようなので、このおばちゃんはただ者ではないと確信した。
・飛行機の座席に着いていたナビゲーション。
行きは序盤で1回ほど気流に捕まり少し、ジェットコースターみたいな感覚を味わう。これがまた数回来るのかなぁと嫌気がしたが、幸いにも以降その様な事はなかった。
・昼/夜のエリア案内
西向きに移動していていたので、太陽に追われながらロンドンに着くという感じだ。いつまでも機内から見える景色は夕焼けであり、またそれが長時間続くのは変な感覚だった。
・イギリス上空
厚い雲に覆われていた。結構揺れるのかなぁと思ったが、そんなことは無かった。
・空港上空
久々に地面が近づいてきて安堵したのを覚えている。あと、オレンジ色に統一された夜景が綺麗であった。
・ヒースロー空港到着
やっぱり紳士の国?イギリスに来たって感じの絵があったので、撮った。
・空港からロンドン市街のホテルにバスで向かう。途中、車内で建物の写真をいくつか撮った。
・レンガのマンション。(レンガ造りのくせに縦にでかい!)
ヒースロー空港(西側)からホテルのあるロンドン東側へ移動。この時点で日本時間で言うと深夜だったのでクタクタだったが、初めて見る景色のためか、何枚か写真を撮っていたようだ。最初に感じたのはとにかく向こうの建物は風格があるというか重みのある色をしているということ。基本、建物は古く、新しい建物はホテルのある再開発の激しいドックランド周辺に行かないとあまり見かけなかった。日本で言うと日本屋敷がひたすら首都近郊を埋め尽くしているような感じだろうか。あの重厚な建物がたくさんひしめき合っている雰囲気は日本には無いものだと感じた。こっちは新しいビル多いし。
それと飛行機からでも確認できた、オレンジで統一された街灯が印象的だった。
・ホテルの部屋の中で撮った深夜のテムズ川。
左手の赤い光が集中しているところがテニスで有名なウィンブルドンのようだ。
ホテル内のバーでも数人がテレビでテニス観戦してお酒を飲んでいたのを覚えている。
・別角度から
移動日はこんな感じ。風呂...(といってもシャワーのみだったが)にはいってさっさと就寝した。寝た時間は現地時間で22時だったので、日本で言うと翌朝7時まで徹夜していたということになる。
フタを開けると大体こんな感じ。DCジャックはちょっとはみ出した。
必要なもの
・Arduino pro mini 3.3v 8MHz版(加えてPCからスケッチを書き込むためのFTDI USBシリアル変換アダプター)
・USB Host Shield for Arduino Pro Mini
・RN-42 XVP(前回のを流用)
・DCジャック
・コンデンサ 0.1μF(パスコン)
・5v ACアダプター
5vレギュレータをつけようか迷ったかが、スペースの関係上、早々に断念。
(しかし、完成後のスペースを見るとできそうな感じではある。)
5v ACアダプター使用前提の設計とした。
加えて諸事情により自分は抵抗 3.3kΩを使用。
以下、やったことをつらつら並べる。
1.USB Host Shield for Arduino Pro Miniの購入
国内では入手できないので、ある意味これが一番敷居が高い。PayPal経由で自分は本家から購入。
Amazonでも互換のパチものが売っているようだったが、後述のVBUS jumperが無いようだったので自分は避けた。
(国内でもどっかの代理店が売ってくれればよいのだけど...。)
2.USB Host Shield for Arduino Pro Miniの下準備
3.3vのままではUSB機器に給電できないので、外部からVBUSへ5vを供給しなければならない。
本家のマニュアルを元にVBUS jumperを切断し、VBUS pad とRAWピンを接続する必要がある。
具体的には↓の方のツイートが参考になる。
https://twitter.com/YuuichiAkagawa/status/307151034839613441
(このVBUS pad とRAWピンの距離感が残念なところ。ほぼ対角線上だ。)
3.USB Host Shield for Arduino Pro Miniと Arduino Pro Miniの接続
スペースを少しでも確保するため、本家の写真にもあるようにUSB Host Shieldの上にpro miniを載せる形で半田付け。
4.9600bps対応
8MHz版を使用する場合、以前使用していた115200bpsだとエラー率が高く、使用できないようなので、
前回使用したソースコードを修正した。(bps以外にも最新ライブラリに追従するための微調整も含めた)
Arduino以外にRN-42側も9600bpsに変更する必要があるが、ここで自分はRN-42側のコマンドモードで設定しようとしてハマった。
一回リセットしようさせようとreset pinをカチカチやってみたが、どうも初期状態に戻らない。調べてみると一旦HIDモードに入るとfactory reset出来なくなるようだ(う〜ん、前に初期化した記憶があるのだが...。HIDに入る前だったか...?)。仕方なく、GPOI7をonにすることで対応。RN-42評価キットの実装から間に抵抗3.3kΩを追加したが、モジュール側で設定出来るならこの抵抗は不要。
4.RN-42と接続。
ブレッドボードでテストした後、フリスクケースに収まるようにハンダ付け。
最終的な回路図は以下の通り。
3.3v機器同士の接続は繋げればイイだけだから非常に楽である。
Windowsとの接続テストの様子。特に問題なし。
iPadとの接続もok。今はこのスタイルをベースにやってる。
一番大変だったのはフリスクケースの加工である。大きめにカットするときにニッパーを使って切断したが、
本当にお菓子入れかと思いたくなるぐらい材質が堅かった。熱いホットボンドを垂らしても全然平気。
電子工作のケースに良く選ばれている理由がよく分かった。
ここ最近では一番のヒットかもしれない。背景がすごい印象的な漫画。けど、日本の何処かにこういうところが在りそうだと思わせる不思議な雰囲気がある。横尾忠則の絵画「暗夜行路」シリーズを観たときにもそういう感覚があったように思う。この印象的な、どんよりとした背景と落書きっぽい主人公との対比がまた良い感じだ。
ストーリーも面白く、可笑しな設定が当たり前のように前提となって話が進行して行く様はまるで短編小説を読んでいるかのようだ。一話ごとに完結しているので一気に読み終えてしまった。前作の「蟹に誘われて」もこのあとすぐに購入したが、やっぱり面白さは変わらなかった。
個人的には「方彷の呆」や「ニューフィッシュ」など、ちょっと不気味な話が好きだ。
あと各話の最後にある作者の日記も印象に残る。読んでいて思ったのは作者の感受性の高さ。自分が今まで気に留めなかったこと、気になってはいたけどスルーしていたことに言及していて、普通の人が無視するようなことにも目を向ける人なんだなと感じた。
次の単行本が出たらまた買いたい。