YAMAGUCHI::weblog

海水パンツとゴーグルで、巨万の富を築きました。カリブの怪物、フリーアルバイター瞳です。

Caravelle BLEを使い始めた

はじめに

こんにちは、StackdriverあらためGoogle Cloud Operations担当者です。在宅勤務が常態化した結果、本社でのオフラインでの決定事項などが減り、以前からリモート勤務が常態であった私にとっては逆に仕事がやりやすい状態になっています。

さて、在宅勤務が基本で、外出する娯楽も減ってくると、室内、とくに在宅での趣味が充実してきます。その一環で、これまで会社の工作室(Maker's Room)でのみ行っていた電子工作も、やはり家でできるようになったほうが良いと思いはじめました。ちょうどそのとき、たまたまネットでCaravelle BLEの再販が始まったと知ったので、急いで注文し、作成することにしました。

用意したもの

ビルドログ

ビルドログはほぼなくて、素晴らしいビルドガイドがあるので、そちらに従っていれば電子工作経験があればすぐに作れると思います。

以下諸々作業中の感想です。自分の基盤はver 2.1と書かれていました。

  • 電池基盤のコンデンサーのはんだ付けは基盤を固定してないと難しかった。(買うのが面倒でクリップ台無しで作業してたらハマった)
  • インサートの熱圧入はコツがいるけど、ガイド通り230-240度くらいでゆっくり段階的に入れていったらまっすぐ入れられた
  • ファームウェアのビルドのときに、レポジトリ内のDockerfileに気づいてなくて、はるか昔に作ったようなクロスビルド環境作るのかとすこし面倒に思ったけど、結果 qmkfm/base_containerの存在を知ったからよかった
    • docker run -it -v /path/to/repo:/qmk_firmware:rw --entrypoint /bin/bash qmkfm/base_container で環境に入ればすぐビルドできる
    • Python入れたりする手間がちょっとだけ減る
  • DFUでのファームウェアアップデートが簡単すぎてびっくりした

できた

f:id:ymotongpoo:20200705161003j:plain
Caravelle BLE 完成

初めての無線キーボードの自作、初めての48キー常用を始めたわけですが、デフォルトキーマップが良いのか意外に移行で手間取ることはありませんでした。*1

デフォルトではキーボードと端末の通信インターバルが90秒で設定されていましたが、たびたび接続が切れてしまうため、60秒に設定を変更したところ非常に快適になりました。接続中は特にひどい遅延もなく*2、快適に使っています。しばらくはこれをメインキーボードとして使っていこうと思います。

今後

とりあえず普通に使えるようになったので、今後はこのあたりを改善していこうと思います。

  • BATT_LV で3000m以上出てるのにWindowsがバッテリー不足として認識してしょっちゅう接続が切れるので原因を調査する
  • キーマップをどんどん最適化していく
  • パームレストを買う。OEMプロファイルのキーの高さだと、結構高さがあって疲れる。

おわりに

制作日数は就寝前の数時間を使って2日程度でしたが、ここまですんなり作成できたのは、ひとえに元の製作キットとビルドガイドが作りやすく作られていたからだと思います。ICとダイオードを全部つけなくていいのは本当に楽でした。作者のid:SatT99さん、すばらしいキーボードを設計してくださってありがとうございます!

これからも素敵なキーボードを期待しています。

この文章はすべてCaravelle BLEを使って書かれました。

参照

satt99.hatenablog.com

github.com

*1:少しだけキーマップは変えたものの、ほぼデフォルトです

*2:あくまでプログラミングやブラウジングでの基準。ゲーミングキーボードとしては厳しい

OpenTelemetry関連プロジェクト関係図(2020年6月現在)

はじめに

こんにちは、StackdriverあらためGoogle Cloud Operations担当者です。先日、OpenTelemetryの現状まとめ、という記事を書きましたが、その流れで現状のOpenTelemetry関連プロジェクトの関係図に起こして(バックエンドサービスがある場合はGoogle Cloud Operationsとする)、各種機能がどうなっているかを簡単に整理しておこうと思います。

ymotongpoo.hatenablog.com

関係図

OpenTelemetryはご存知のとおり複数言語を対象とした計装用フレームワークなのですが、先の記事に書いたようにCollectorがGoで実装されてるため、プロジェクト全体でいうとGoで実装されたものの割合が多くなります。Goの実装に関係するコンポーネントを図にすると次のようになります。*1

f:id:ymotongpoo:20200625101812p:plain

この図の中にある数字は次のリストの数字と対応します。

  1. OpenTelemetry specification
  2. OpenTelemetry for Go (API, SDK)
  3. OpenTelemetry collector
  4. OpenTelemetry collector upstream exporter (アプリケーション → Collector)
  5. OpenTelemetry collector downstream exporter (Collector → Cloud Operations)
  6. OpenTelemetry receivers
  7. OpenTelemetry direct exporter

見ての通り地味に多い!自分が関わっているのは主に #7 の開発ですが、もし各種APMベンダーやOSSがそれぞれ対応するとしたらどの部分を実装しなければいけないかというと、この図で言うところの #5 と #7 の部分だけです。あるいは、あるとすればパイプライン に独自の処理を追加する場合には、上の図には登場しないですが Processor を実装する必要があります。(その場合のcontribute先は contrib レポジトリになる)

各言語向け実装

上の図で見てわかるように、各言語向けに実装しなければいけないのは #4 もしくは #7 の実装とわかります。そのうち各APMバックエンドが各言語向けに個別に提供しなければいけないのは #7 のみです。

Google Cloud Operationsの場合は次のとおりです。

まだ本家の仕様がstableになっていないこともあり、Python用とJava用のExporterは建設予定地としてプレースホルダが用意されているだけです。

おわりに

OpenTelemetryはまだ仕様が安定版に至ってはいませんが、ようやくその目処が立ち、様々なところでチラホラと話が聞こえてきた頃だと思います。そこでExporterという名前が出てきたときにどのExporterか混乱しないように、ぜひこの図を参照してください!大きな変更があれば今後もなるべくこのブログで情報を共有していこうと思いますが、とりあえずいまはこんな状況です。

*1:社内の説明用に描いた図ですが、すべて公開情報なのに公開しないのはもったいないので掲載するためにこのエントリーを書いた

OpenTelemetryについての現状まとめ (2020年6月版)

はじめに

こんにちは、StackdriverあらためGoogle Cloud Operations担当者です。ここ最近は業務でOpenTelmetry関連をほそぼそとやってきたんですが、ようやくOpenTelemetryも安定版リリースのめどが立ってきたので、これまでと現状と今後を簡単にまとめておこうと思って書き始めたら、全然簡単じゃなくて10000文字超えました。(なおこのシリーズは今後も続きそうな気がするのでタイトルに日付を振っておきました)

TL;DR

  • 分散トレースとメトリクスの計装フレームワークとしてOpenTelemetryというものがCNCF Sandboxプロジェクトとして進行中。これはOpenTracingとOpenCensusのマージプロジェクトであり、各々の正式な後継版である。
  • とはいうものの、まだ仕様もstableリリースになっておらず、当然各言語向けのライブラリも安定版は出ていないので、プロダクションに入れたい人は定期的に様子を伺う程度で良いと思う。
  • 早めに試したいという人はそろそろ各製品向けのexporterが出ているので、軽く試してみても良いと思う。

経緯

OpenTelemetryは現状はアプリケーションのオブザーバビリティのためのライブラリ群で、現状はトレースとメトリクスに関するライブラリを提供しています。OpenTelemetry以前のメトリクスとトレース、そしてOpenTelemetryマージ後の3つに分けて経緯を並べていこうと思います。記憶をもとに書いていますが、時系列はほぼ合ってると思います。

メトリクス

  • Google社内でクラスタマネージメント基盤であるBorgの監視のためにBorgmonを開発する
  • Soundcloudのex-GooglerがBorgmonのコンセプトを元にPrometheusを開発する(2012年ころ)
  • 同時期に同様にTSDBを元にしたモニタリングOSSAPMが開発され、メトリクス取得に関するAPISDKが乱立する
  • 2016年にPrometheusがCNCFプロジェクトととして採択される
  • Google社内で使われていたトレースとメトリクスの計装フレームワークであるCensusを元にOpenCensusが公開される(参照

トレース

  • 2010年にGoogle社内で使われている分散トレーシング基盤であるDapperに関する論文が発表される
  • Dapperを元にzipkinやJaegerといった分散トレースのOSSが開発される
  • 同時に商用APMでも分散トレーシングの対応が進められる
  • 分散トレースの共通API仕様としてOpenTracingがOSSとして進められ、2016年にCNCFプロジェクトとなる
  • GoogleがOpenCensusとしてメトリクスと同様に分散トレースの仕様と実装を公開・開発する
  • OpenCensusの開発と並行して、W3Ctrace contextの仕様が提案される
  • 2019年3月末にOpenTracingのブログでOpenCeususとのマージが発表される(まだOpenTelemetryという名前は決まっていなかった)
  • 2019年5月にOpenTelemetryというプロジェクト名が発表されたり、CNCFのTOCへの登録がされたりした。(c.f. CNCFからのアナウンス)またKubeCon EU 2019でも発表された。(セッションの録画

OpenTelemetryマージ後

  • OpenTracingとOpenCensusの共通項であるトレース部分から仕様の策定が始まり、JavaとGoが参照実装として先行的に実装される。
  • 2019年11月頃にTraceの基本的な仕様と参照実装が揃う
  • 元来は出自からわかるように分散トレースとメトリクスのための計装フレームワークであったが、今後の方向性としてCollectorと呼ばれるエージェントを使うことを想定しているので、Collectorにロギングエージェントとしての機能を持たせるべくLog SIGも2020年4月から活動開始。
  • 2020年5月末現在、仕様はv0.5.0に向けて頑張っている。今の議論が進んでいる議題はMetricsに関してはViews API、CollectorはServerlessサービスとの連携という状況。Logに関してはFluent Bitとの連携を行っている。

仕様

全体的な話

OpenTracingやOpenCensusと同様、OpenTelemetryは各言語ごとにライブラリが存在しているため、細かな実装は言語ごとに異なりますが、OpenTelemetryは常に仕様が先行して策定されるため、大まかな概念はどの言語でも共通しています。

f:id:ymotongpoo:20200601163702p:plain

仕様のレポジトリにある画像を引っ張って来ただけですが、分散トレースもメトリクスも同様の構成になっているので、全体感を把握するにはこの図が一番良いと思います。普通に使う場合は各APMベンダーやOSSが用意したexporterを利用するだけなので、特に気にする必要はないかもしれません。

そうではなくOpenTelemetryを使って計装されたアプリケーションやライブラリからメトリクスやスパンに関するデータを取得して、独自のバックエンドに送信もしくは保存するということをしたい場合にはこれらの違いを意識することになりますが、たいていの場合はAPISDKの両方を利用することになります。仕様のドキュメントにも説明がありますが、簡単に紹介すると

  • API: 計装したデータを取得する最低限のインターフェース。各言語向けライブラリ実装者はAPIはなるべく近い設計で実装するよう求められる。
  • SDK: APIの上にデータの取り出し方法や送信方法などの実際にデータを取得して送信する場合に便利なヘルパーが多く用意されている。

自分で使う場合には各言語向けAPIおよびSDK実装を利用することになるので、 opentelemetry-xxx (xxxは言語名)のライブラリを利用することになりますが、SDK実装は主要なAPMバックエンドOSS(Jaeger、Zipkin、Prometheus、標準出力など)のexporterを例として実装することになっているので(SHOULDレベル)それらを参考にしながら作ると良いと思います。

また各言語向けライブラリのレポジトリのディレクトリ構造もできるだけ意味がおなじになるようにガイドラインが提示されているので、そちらを参照しながらライブラリを見ていくとわかりやすいと思います。

トレース

分散トレースのAPIの仕様はここにあるとおりです。(実際にはOpenCensusとOpenTracingの両方がもととしているDapperにある概念と踏襲しているので、どちらかを触ったことがある人は理解しやすいと思います。)

  • Traceは複数のSpanからなる一連の処理のまとまり
  • Spanがある処理の単位。Spanは各Spanの開始・終了のタイムスタンプ、Span内でのイベントとラベルとタイムスタンプ、その他ラベルのキーと値などを保持している
  • TraceとSpanの紐付けをSpanContextで行っている
  • Linkは例えばキューなどを挟んだバッチ処理など、長めの時間軸で別れた処理をつなげる場合に使う
    • Linkを用いると複数のTraceをまとめることができる。(実際にはTrace内のSpanContext同士を紐付ける)
  • Spanの状態はTracerと呼ばれる管理オブジェクトで管理し、Tracer自体の呼び出しはTracerProvierによって行う。(TracerProviderはグローバルでsingletonとして提供される)

メトリクス

メトリクスは基本的にOpenCensusの概念を踏襲しているので、OpenCensusを使ったことがある人は理解しやすいかもしれません。これもやはり仕様を読んでもらえばそのとおりですし、protoファイルを読むのに抵抗がない人はそれを読むのが一番早いのですが、簡単にまとめます。

  • Metric: 取得したいデータとそれに付随するメタデータを取りまとめるオブジェクト。各種メタデータのキーと値、と時系列のデータを保持している。Metricの種類に応じて、記録した時系列データに対する送信インターバル間での処理が変わる。
    • 同期的、加算的、単調的の3つの性質を判断基準として現在Metricの種類が6種類定義されている。
  • Measurement: Metricに記録される時系列データの最小単位。ある時刻におけるデータとそこに紐づくラベルが記録されている。
  • Label: あるアプリケーション内で共通なラベルもMetric事に異なるラベルもすべて同じデータ型である "Label" として扱われている
  • Resource: あるイベントではなく、すべてのMeasurementもしくはMetricに紐づくようなリソースに関係するラベルはResource内でまとめて管理され、再利用される。(例: Kubernetesのpod名、GCEのインスタンス名、など)
  • MetricはMeterを通じて記録され、各MetricはMeterと紐付けられている。MeterはMeterProviderにより提供される。(MeterProviderは通常グローバルでsingletonとして提供される)

各種APMベンダーが自身のバックエンドとの互換性を持てるように意見を出してなるべく最大公約数を踏まえつつ仕様を頑張って絞っているので、Dapperの概念が下地にあって共通認識が持ちやすかった分散トレースよりも議論に時間がかかり、当初予定しているよりもだいぶリリース計画が後ろ倒しになっています。

現在上記の定義に加え、Views API (OTEP #89)というものの導入が議論されています。これはOpenCensusにおけるViewに相当するもので、これが入るとアプリケーションでの計装が楽になると同時に、exporterの実装内でMetricの種類に応じた集計(Aggregation)もやりやすくなる予定です。

コレクター

OpenCensus時代にはServiceと呼ばれていたもので、OpenTelemetryにおいても当初はServiceと呼ばれていたものが、Collectorという名前に改称されました。

OpenTelemetryの特徴はOpenCensusと同様に、テレメトリーデータの取得と送信を切り分けていて、exporterの差し替えを行うだけでバックエンドの切り替えができる(=アプリケーション内の計装を変えずに済む)という点が利点でした。さらにそれを推し進めてOpenTelemetry用のエージェントを用意して、バックエンドの切り替えをエージェント側でのみ行うようにすれば、アプリケーションコードを一切変更せずに、エージェントの設定切り替えだけでバックエンドの切り替えができるようになります。

またそれだけでなく、コレクターはGoで実装されているのですが、コレクターからバックエンドへの送信を行うexporterはGoでのみ実装すれば良くなるので(各言語のSDK実装はコレクターへの送信を行うexporterは実装している)、コレクターがメインの構成が進むとAPMベンダーの対応も楽になるという利点があります。

f:id:ymotongpoo:20200601163747p:plain

この図はopentelemetry-collector内の設計に掲載されているものですが、見てわかるようにOpenCensusのときのものをそのまま採用しています。

もちろん、アプリケーションから直接テレメトリーを送信する構成と違って、新しい層が導入されるので複雑さは増しますが、アプリケーションからバックエンド固有のコードを排除したという意味では、開発プロセスを考えたときにメリットがありそうです。

さらに、分散トレースとメトリクスの送信を行うエージェントがせっかく走っているので、ログフォワーディングもそれに行わせたい、というのがいまLog SIGで行っていることです。

ガバナンス

プロジェクト全体

CNCFプロジェクトであるためオープンガバナンスが求めらます。おおよそCNCF sandboxプロジェクトとして求められる役職と手続きを設定して行っていますので、詳細はこちらを参照してください。

まず大元にGovernance Committee Charterがあり、Technical Committee Charterの健全性の担保やCode of Conductの設定、マーケティング活動、などなどを行っています。Governance Committeeのメンバーは2019年は初期メンバー5人がOpenTracingとOpenCensusのコミュニティーから設定され、以降は選挙により1年毎に2年の任期で選出されます。(3人、2人と年ごとに交代していく)選挙への参加はコミュニティーでの貢献(Pull Request数、Issue数など)が20以上のアクテイブな人と、既存のメンテナーが可能です。立候補者が出揃った後、選挙参加者による投票によって得票数順にGovernance Committeeメンバーが決定されます。

Technical Committee Charterはリリースに関する決定やレポジトリの管理、コーディング規約など、技術的な意思決定を行います。また各SIGとのすり合わせもTCの担当です。TCメンバーもGCと同様の基準の参加者による選挙から選出されます。またTCにはChairもいて、その決定も追加の選挙で行われます。

また言語関係ない仕様の提案に関しては、 OTEP (OpenTelemetry Enhancement Proposal) という形で提案が行われ、cross language spec SIGのapproverが許可したものに関しては仕様に反映されていく形になります。

各SIG・レポジトリ

各SIGのメンバーはmember、approver、maintainerの3種類に別れ、それぞれ細かな基準があります。

各SIGは技術領域によって分かれていて、現在は次のSIGが存在しています。

各SIGのレポジトリは opentelemetry-xxx という命名規則open-telemetry org配下に置かれています。

各SIGのミーティングは常にオープンで、いつ開催されるかは各種カレンダーフォーマットで公開されていて、議事録はGoogle Docsで公開されていて誰でも参加・閲覧可能です。また各SIGのGitterも誰でも参加可能です。

詳細は community レポジトリの README.md に諸々リンクしてあります。

github.com

またOpenTelemetry本体の機能としては入らないけれども、みんなが使えると嬉しいもの(特定の言語でメジャーなフレームワークに対して組み込めるプラグインなど)は opentelemetry-xxx-contrib というレポジトリにまとめていく方向で動いています。

参加企業・OSS

OpenTelemetryはアプリケーションの後ろで使われるAPMに大きく影響を与えることになるため、その参加企業・OSSプロジェクトがどれくらい積極的に参加しているかも気になると思います。いままで自分はGo SIGしか確認していませんでしたが、各SIGの議事録も含めて確認できた参加企業やOSSプロジェクトは次の通りでした。(レポジトリのPull Requestだけでなく、仕様策定や実装策定に関わっている人をピックアップするためにそうしました)

大まかな数でしか見ていないですが、前に書いてある会社ほど参加回数が多くなるように並べています。

  • APM vendor/Cloud Platformer
    • GoogleMicrosoft、New Relic、Dynatrace、LightStep、Splunk / Omnition、Honeycomb.io、Datadog、AWS、Sumo Logic、Zillow Group、VMWare / Wavefront、Elastic、Logz.io、Sentry、Orijitech、Arm Treasure Data
  • OSS
    • Prometheus、Jaeger、Grafana
  • Infrastructure
    • Salesforce/Heroku、Postmates、Fastly、Kinvolk、Bison Trails、Verizon Media、Cisco、Mailchimp、Out There Labs
  • User

参照

引っ越し備忘録(2020年2月版)

はじめに

こんにちは、StackdriverあらためGoogle Cloud Operations担当者です。非常事態宣言のまま落ち着かない日々が続きますが、COVID-19が日本で感染者を大きく増やす直前に引っ越しをしまして、そちらに関してはようやく落ち着いたので記録をまとめておこうと思います。

前回の引っ越しのときは前々回の引っ越しの備忘録を見てまったく同じことをしたのでなにも代わり映えがなかったため記録しなかったんですが、今回の引っ越しは前回とは違った作業がいくつか増えたので記録することにしました。前々回の引っ越しの備忘録はこちら。

ymotongpoo.hatenablog.com

引っ越し準備

部屋探し(2019年7月〜2020年1月)

結構厳しめの条件を設定してSUUMOやHOME'Sから来た通知をもとに様々に検討していました。厳しめに設定していたので合致する条件の物件はなかなか見つかりませんでした。別に急いでいるわけでもなかったので不定期にやってくる通知を淡々と眺めるというのを半年くらい繰り返していたら、2020年の新年のある日、家賃以外は条件がかなり良い物件が見つかったため、仲介会社にダメ元で家賃の値下げ交渉をお願いしてみたところ、許容できる範囲に家賃が収まったので引っ越しを決意しました。

契約(2020年1月)

かなり忙しい時期だったので仲介業者にもろもろ丸投げして書面上の手続きは完了しました。入居日が2月1日だったため引越し先の日割り家賃交渉云々は特にありませんでした。退去は2月半ばだったので、それは日割りでの支払いということになっていたので終了。

引越し作業

引越し業者選定(2020年1月上旬〜中旬)

引っ越しを決めたのが1月頭で引っ越しが2月頭というのを決めたのはいいけれど、自分が1月に海外に行く用事が3回もあるため、圧倒的に時間が足りないということで、今回は荷造りも手伝ってもらえる引越し業者を検討しました。前々回の反省以降引越し侍は使わないと決めていたものの、相変わらず引越し業界の慣習である「無駄に電話をかけまくる」「メールやウェブでの調整はほぼ無い」という状態は変わっていなかったので、友人のおすすめからA社、中堅のB社の2社で相見積もりを取らせてもらって、安い方で決めることにしました。

2社で見積もりを取るタイミングが1週間くらいずれてしまいましたが、友人から紹介してもらったA社がB社の見積もりよりも数万円安かったのでそちらに決定しました。B社が先に見積もりに来て、B社の見積もりも交渉をしてだいぶ値引きはしてもらっていました。A社には「B社が値引きしてくれてXXX円という見積もりだったのですが、こういう条件で無理のない範囲でこれよりも低い価格は難しそうということであれば見積もりに来ていただくのはお手数だと思うので遠慮なくおっしゃってください」という連絡をしたんですが、電話口で「いけそうだ」というふうに言っていて実際に見積もりに来たら数万円安い価格になっていました。助かります。

またB者が見積もりに来たときに置いていったダンボールもA社が送り返してくれました。B社にお断りをしたあとは自分で返送しようと思っていたため、業者間での揉め事にならなければいいなと思いつつ、大変ありがたかったです。

A社は「ベスト引越しサービス」という会社です。

荷造り(2020年1月中旬〜2月上旬)

今回は荷造り込みのサービスということではあったんですが、なるべく早く引っ越し作業を進めたいというのと、値引き交渉の際の条件が半分荷造りを行うだったので、荷造りは依然として必要でした。細かな荷物の荷造りをしたあとに、棚などの解体が必要だったり、その間に海外出張・旅行が挟まっていてかなりのドタバタでしたが、引越し当日には食器以外はほぼ終わった状況になっていたので安心でした。

引っ越し当日(2020年2月上旬)

当日は午前中に荷造り担当の人が来てくれて、細かな荷物を全部丁寧に梱包してくれました。皿の梱包とかいままですごく適当で「これは割れるかな...」というような際どい梱包で引っ越しを繰り返していたんですが、今回は緩衝材の使い方などとても参考になるくらいキレイに梱包してもらいました。

午後に実際に荷物の搬出・移動・搬入だったのですが、予想以上に荷物が多かったこともあり一時は今日中に終わらないのではないかと思って追加料金を覚悟していました。結局ちょっと足は出たものの当日中に終わり一安心でした。

搬出中には「要るかも」と思っていたものも、結局次の家に来てから思い切って捨てたりしていたので、教訓として「無駄な大型家具の搬出・搬入は引っ越し時間にも影響を与えるのでさっさと処分する」ことを学びました。

粗大ごみ廃棄1回目(2020年1月下旬、2020年2月下旬)

居住地域によっては粗大ごみの回収受付にかなり時間を要するところもあるため、早めの申請が必要となります。自分の場合もそれに該当して、回収の申請をしても最短で1ヶ月程度先の予約しかできないということがよくあるので、粗大ごみ廃棄の予約をとりあえず引っ越しの諸々が決まる前に、引越し日の前後となる1月末と2月末にそれぞれ1回ずつ申請をしました。

粗大ごみの申請は後からごみの内容に関しては、捨てるものを減らす内容の修正はいつでもできるため,*1、まずは捨てる可能性があるものをすべて列挙し、後述するメルカリの販売にも回しておいて売れたら消す、という運用がうまくいきました。

粗大ごみ廃棄2回目(2020年3月中旬以降)

一度粗大ゴミで捨ててみたものの、なんかもったいないなと思ったのと、部屋が片付いてきて余裕ができたこと、COVID-19の影響で自宅勤務が増えたので気分転換ということで、大型家具をかたっぱしから梱包・発送たのメル便(旧「大型らくらくメルカリ便」)で出品し始めました。

もともと粗大ゴミでだそうと思ってた家具が数千円の利益で売れたので元は大きく取れました。ありがたい。トータルで数万円の利益になりました。

大きいものよりも細かいもののほうが意外と売れるので、宅急便コンパクトの箱をまとめ買いしとくとコンビニに行くついでに出せて便利でした。

各種契約変更

以前は引越れんらく帳を使って各種手続きを終えましたが、次のような話も見たので使うのをやめました。

水道

東京都水道局は引っ越しの手続きをオンラインで行えます。

suidonet.waterworks.metro.tokyo.jp

ガス

東京ガスも引っ越しの手続きをオンラインで行えます。

home.tokyo-gas.co.jp

電気

東京電力でも引っ越しの手続きをオンラインで行えます。

www.tepco.co.jp

引っ越しにあたり東京電力の利用をやめ、転居先では熊本電力にしようと思っていたのですが、本当に1月が忙しすぎたので引っ越して落ち着いてから連絡しようと思い東京電力に転居の連絡だけしました。結局まだ熊本電力には切り替えていません。

kumamoto-energy.co.jp

インターネット回線

引き続きフレッツ光を利用する予定なのだけれども、前回までは116に電話して引っ越しの手続きをおこなっていたのを、今回はメールで行ってみることにしました。

hikari-fiber.com

メールを送ってみると早速次のような自動返信が返ってきました。

f:id:ymotongpoo:20200119202554p:plain

結局電話でした。その後、引越し先に光回線のコネクタがすでに設置済みなので工事の必要がないと言われて安心しきっていましたが、2月1日に引越し先の鍵を渡されて中を隅々まで探してみたらコネクタが見つからず、挙げ句にコネクタがある場所が封印されていたという謎な状況でした。

管理会社に連絡し、木ネジで止められていた板を外してもらって無事に光回線のコネクタにアクセスできたんですが、こういうことは物件を見に行くときに確認しておくべきことですね。

事後処理

各種サービス住所変更(2020年2月~3月下旬)

本人確認書類が必要ではなかったもの

本人確認書類が必要だったもの

特にマイナンバーカードが残念で、引越し前に紛失してしまったので確定申告をしたタイミング(2月上旬)で住所変更と合わせて再発行の申込みをしていたのだけれども、結果受取手続きの連絡が3月下旬に来て、受取の予約をしようと思ったら緊急事態宣言が発令されて結局まだ受け取れていません。

会社

各種公的手続きのために住所変更を伝える必要があるため、住民票の写しのコピー(PDF)を送って連絡完了。あと自分で社内システムで変更できるものは変更しておしまい。

その他

ネットワーク環境改善

元々Google Nest WifiGoogle Wifiを持っていて、これでPPPoE可能だったので、引っ越しと同時にインターネットの終端装置をルーター付きのものからただのONUに変更しました。家には玄関の靴箱の上にある光回線のコネクタがある棚から各部屋にCAT5eで繋げられるようになっていたので、大元をGoogle WifiでPPPoEをして、メインの部屋にGoogle Nest Wifiを置いて、その2つでメッシュを組むような形にしていました。

しばらくはそれで特に不満はなかったのですが、緊急事態宣言のあと明らかに同じマンション内で在宅勤務する人が増え、ネットワークの速度も遅くなったので、IPoEやIPv4 over IPv6での接続ができるようにEdgeRouter Xを買い、ついでに古いイーサネットケーブルを全部CAT6aにし、スイッチングハブも安いものからNETGEARの業務用に変更したりともろもろ改善しました。

今では平日昼でも下りが最低200Mbps、平均で300Mbpsくらいは出ていて、上りのほうが速い状況なので、ストレスなく在宅勤務できるようになりました。

収納棚の整理

旧居に比べ新居は収納が非常に狭い(そのかわり生活空間は広い)ので、うまく棚などを工夫して収納する必要がありました。いらないものはメルカリで売ったり捨てたりできたのですが、やはり棚が必要だということで、アイリスオーヤマのメタルラックとディアウォールと壁美人を駆使して収納スペースを作りました。

アイリスオーヤマのメタルラックは旧居で使っていたものに追加で買い足したので、部材をあちこち移動させながら使いまわしができて、ユニット化した家具の便利さを改めて実感しました。(ルミナスでもエレクタでもいいと思いますが、買うと決めたら同じブランドのものを買い増すのが良いと思います)棚一枚や延長ポールなどをうまく買い足すことで、常に家に合ったサイズで使えますし、要らなくなった棚はメルカリなどでも売りやすいので重宝しています。

2x4家具は作るのは面倒だけど、間取りに合わせたジャストサイズな家具ができるので、DIYを始めたい人にはおすすめです。(自分もこれでDIYにはまり、必要とあればインパクトドライバーと木ネジで諸々組んでいます。)

*1:増やす内容だとトラックの予定積載量をオーバーするため別日の予約をさせられることがある

*2:宅急便転居サービスに登録すると以前の住所への宅配便も転送してくれる。ただし郵便の転居届が完了していないといけない。

*3:https://support.google.com/maps/answer/3093979

Windows 10でApple Wireless KeyboardとApple Magic Trackpadを使う

はじめに

こんにちは、StackdriverあらためGoogle Cloud Operations担当者です。この自己紹介、いつまで続けたらStackdriverの名前よりもCloud Operationsのほうが浸透するんでしょうか。

Magic Keyboard - 英語(US)

Magic Keyboard - 英語(US)

  • 発売日: 2015/10/14
  • メディア: Personal Computers

Apple Magic Trackpad 2 - スペースグレイ

Apple Magic Trackpad 2 - スペースグレイ

  • 発売日: 2018/05/16
  • メディア: Personal Computers

さて、最近COVID-19の影響で強制在宅勤務が続いているので、家の開発環境の設定などをしているのですが、普段は分割キーボードのErgoDox EZを使っていて、最近DUMANG DK6 Ergoを買ってより充実した開発環境を手に入れたはずでした。 ところが、DUMANG DK6 Ergoがどうも製品品質が安定せず、購入したものと交換品の2つがともに右手側が初期不良(ショート)を起こしていて使えないという状況に陥っています。

さらに悪いタイミングは重なるもので、ErgoDox EZの左手側のTRRS端子がどうも接触不良を起こしていて、認識されないようになってしまいました。現状ではとりあえずDUMANG DK6 Ergoの左手側とErgoDox EZの右手側を使うという不格好な構成でしのいでいるのですが、これが続くのはしんどい。

さらに、どちらか片方が更に何らかの問題を起こしたら家で使えるキーボードがなくなる!(メインで使っているデスクトップマシンにはBluetoothのドングルなど挿していない)

というわけで、Bluetoothドングルを購入し、ずっと眠っていたApple Wireless KeyboardとApple Magic Trackpadを奥から引っ張り出してきてWindows 10で使えるようにしました。(上のAmazonリンクは新型だけど、自分が持ってるのは当然旧型)

Bluetoothドングルの接続

買ったBluetoothドングルは正直良くわからないメーカーのものしか在庫がなかったので、Amazonで購入するのが一瞬ためらわれましたが、もう急いでいたので1000円ちょっとだしいいかと思って買いました。

すでに起動しているWindows 10のマシンに接続してみたら普通に使えたので一安心。

Apple Wireless Keyboardのペアリングと設定

次にApple Wireless Keyboardをペアリングしてみます。久々に電池を入れて、電源ボタンを長押ししてペアリングモードに設定。その後「スタート」→「設定」→「デバイス」→「Bluetoothまたはその他のデバイスを追加する」を押したところ、あっさり接続完了。自分はUS配列を使っているので、ネット上で見かけるような変換キーが効かない、などの症状もなく、普通に文章入力できるようになりました。

しかし一点だけ、Apple Wireless Keyboardはcaps lockのキーがAの左にあって、これをcontrolキーにしなければ生産性ガタ落ちです。というわけで、往年のCtrl2capをインストールしました。Windows XPをメインで使っていた頃から思っていたのですが、このツールは行っていることから考えると「Cap2ctrl」が正しいのではないでしょうか。

docs.microsoft.com

それはさておき、こちらをダウンロードしてきて、cmd.exeよりインストールします。管理者権限で行わなければいけないのだけ注意が必要ですが、そちらのサイトにあるようにコマンドプロンプト

$ ctrl2cap /insall

を実行して再起動したら無事に設定完了。

Apple Magic Trackpadのペアリングと設定

こちらもキーボードと同様に電源ボタンを長押ししてペアリングモードに入り、デバイスの追加をするとペアリングまでは簡単に行われました。ところが、こちらはポインティングとクリックはできるものの、スクロールができません。そこで、Appleが配布しているドライバをインストールします。

正しく処理を行うにはBoot Camp用にインストールするデバイスドライバ群をすでにmacOSが動いているマシンからインストールイメージを作成したりしなければいけないのですが、面倒だったので他の方法がないか探していたらWindows 8.1までに対応したデバイスドライバーがAppleの公式サイトで配布されていました。

support.apple.com

公開日が2015年という、かなりの古さのサイトで正直ビビっていましたが、そもそも古いデバイスを使おうとしているのと、Windowsの下位互換性の高さを信頼して、そのまま上で配られている以下のデバイスドライバーをインストールしてみました。

  • AppleWirelessTrackpad64.exe

これをインストールすると、無事に2本指でスクロールを認識しました!無事解決!これでキーボードが壊れても代替で使えるキーボードが確保できたので、安心して使い続けられそうです。