あっきぃ日誌

鉄道ブログのような技術系ブログのようななにか

東急新横浜線に乗りに行ってきた

昨日開業の東急新横浜線相鉄線を見に行ってきました。本当はもうちょっと落ち着いてから行こうかなと思っていましたが、我慢できなかったので(オタク〜〜)。

横浜線は、我々田園都市線の奥側の沿線民としては、長津田からJR横浜線、もしくはあざみ野から横浜市営地下鉄で新横浜に行けてしまうため、せっかく東急の新路線なのに、特に恩恵が得られないのが惜しいところです。

今回は日吉から乗車をスタートしようとしたため、あざみ野〜センター北〜日吉と、やたら乗り換えをすることとなりました。二子玉川から大井町線経由で東横線に回るのも遠回りですし。そして、超久しぶりのグリーンラインも6両編成に乗れるかと期待したものの、残念ながら4両編成でした。


日吉

グリーンラインから乗り換えて見た東急の発車標。なんですかこれは……?てっきり日吉止まりの電車はなくなったものかと思ってましたが、そうでもないんですね。他線のダイヤに興味ないマンとは言え、もうちょっと調べても良かったかも。なお、昨日の初日は混雑による遅れ、今日は副都心線内で何らがあり遅れていました。相鉄が直通先ダイヤ乱れの洗礼をもろ浴び状態。今後もほぼ毎日やろなあ。

駅名標もしっかり直通仕様に。目黒線側はほぼ延伸したようなもののようなデザインに。

対して、東横線はここでみなとみらい線方面と相鉄線方面に分岐するようになるため、これからは脳死で乗車してかつ寝落ちしてしまおうものなら、新横浜とか、最悪その先の湘南台まで連れて行かれることになるので、恐ろしいですね〜。8両編成とか他社車両に乗っていれば、ある程度回避できそうな気はしますが、どうなんでしたっけね。

日吉駅目黒線側ホームの延伸部はまだ仮設のよう。天井から察するに結構強引な拡張をした雰囲気を感じます。

2本の当駅止まりを見送って、3000系3108Fが到着。車内LCDを撮影。車両とかを撮るのは人が多くて控えめになりました。もうちょい動画も撮りたかったナー。


綱島

横浜線唯一の途中駅である新綱島に到着。

www.youtube.com

降りると反対には4000番台。

綱島駅出口付近は再開発と称してクソデカマンションが建設中でした。東横線綱島駅は目視できるレベルですぐそこという近さでした。

鶴見川をちょっと眺めたあとは駅に戻って再び乗車。写真を撮っているうちに一本逃しましたが、反対には都営車のキングジムが入線。

動画で。

www.youtube.com

後続も相鉄車が来ました。逃したのは東横線からの直通、後続は目黒線からの直通のハズなので、なんというかすごい。

相鉄21000系に乗るのはたしか初めてですが、ドア上のLCDデッカ!あと、こころなしか車内が狭く感じました。荷棚が低い?からでしょうかね。


新横浜

新横浜に着。2面3線になっていて、真ん中は折返し用っぽそうな雰囲気。

駅を出てふらついて戻ってきたときにはメトロ車が折り返し中でした。

コンコースできびしいオタクミク写真。とにかくひとが多い感じでしたが、私を含め観光的に乗りに来たひとたちが落ち着いた頃にどのくらいの混み具合になるかは気になりますね。

北改札でもミク写真。北改札と南改札を挟むように、横浜市営地下鉄の改札口がある感じの構造でした。JR・新幹線方面に行くには、デッキ駅前に上るエスカレーターを使って外を経由するような感じでした。が、多分市営地下鉄側の通路を通って、市営地下鉄の前からある方の改札側の階段とエスカレーターを使ったほうが楽そうな気がしました。

JR・新幹線側の駅にもでかでかと広告が。お祭りムード。

横浜線の駅に戻ったあとは、西谷に向かって、横浜駅(相鉄)を目指すことにしました。来たのは東横線車両の4108F。

湘南台駅も、田園都市線の奥側の民からすると中央林間から小田急でサクッと行けるのでアレですけど、今度からは湘南台東横線車両がいる場合があるというのも、なかなかですね。さらに言えば、海老名でも目黒線の車両が見られるようになるわけで……。

LCDはここから相鉄デザインのものに切り替わる模様。


羽沢横浜国大・西谷

JR直通線ができた時以来の羽沢横浜国大。JR直通線はお腹が痛いときに乗ったら終わってしまうような駅間でしたが、東急直通線は常識的な駅間だったので安心しました。やっぱ本命は東急直通線だったんですねえ(??)。なお、ここは降りずにスルー。

そして西谷着。相鉄線に東急車が居る風景〜〜!!

路線図がカオスの極み。もはや半分以上乗り入れ先の情報じゃないですか。東急線から先の駅とかガツッと端折っても良かったのでは🤔


星川・横浜

Twitter星川駅の留置線が東急の植民地みたいになっている様子を見て、自分でも見てみたかったので一瞬降りました。直前に5080系とすれ違って、それもまたカオスを感じましたが、

いやいやいや、

こうはならんやろ。

乗り入れ直前は5080系長津田疎開の話題とかを見てましたが、直通が開始した途端にこうなっているということは、今後も日常的にこうなる可能性があるんでしょうかね。それにしても、東急の全乗り入れ形式をきれいに並べちゃって。もはや展示場じゃん。

後続の電車に乗り換えて横浜まで移動して、新横浜線乗り鉄は終了しました。本当は横浜駅に入線する東急車も見たかったのですが、さすがに運用を調べないと見られない程度の本数のようなので、また今度ですね。

ところで、相鉄11000系の帯がぐちゃぐちゃにズレていたんですが、帯ってこんなズレ方するもんなんでしたっけ……???


有隣堂巡り

横浜についたあとはノープランだったので、ダラダラ歩いて、思い出したように有隣堂で三方金仕様の本を見て、帰ろうとしたところで桜木町でメシをすることを思いついて、ストヨコバージョンの三方金仕様の本を見て、パスタを食べて帰ってきました。いきあたりばったり。


やっぱ田都民的にはJR横浜線横浜市営地下鉄

帰りは桜木町駅横浜線直通の電車がいたので、これで長津田まで乗って田園都市線に乗り換えて帰宅しました。田都民的には、横浜に行くにも新横浜に行くにも、JRか市営地下鉄といった感じですね。

どういうときに新横浜線が使えるのか考えてみると、田園都市線がガッツリ止まって迂回せざるを得ないときに、新横浜線で新横浜駅を経由することで、市営地下鉄の貧弱なグリーンラインを使わずに迂回できるパターンが増えた、とかでしょうか。うーん、たぶんこれでしか使うことはないかも……w

あとは免許更新に二俣川に行くときに、湘南台から東急者に乗るのを楽しみにするくらいかなあ?

家の固定電話機を買い替えた

15年くらい使ってきた(使ってない)家の固定電話機を買い替えました。使わないんですけども……。

選んだのはシャープのJD-S08CL-Wというやつで、現行よりひとつ手前のものです。中古の相場をしばらくウォッチして、5000円ちょっとで入手できました。

どうせ使わないのになぜ買い換えるかと言うと、設置スペースを減らせるんですよね。使わないもののために設置スペースが食われるのがなんだか気に入らなくなりまして。実際新旧電話機を並べるとこんな感じで、1/4くらいのスペース削減が見込めそうです。

ちなみに前の電話もシャープ。これはYahooが昔やってた、譲りますみたいなジモティーっぽいやつでもらったやつですね。上京時に雑に買った電話機が残念クオリティで1ヶ月もしないで交代になって以来ずっとこれを使ってきました。2003年発売の機種だそうで、下手すると20年モノの模様……。ググって思い出したけれど、子機もあって、どこかにしまってあったかも知れない。

さておき、こちらが設置後。やはりスペースがかなり空きました。やったぜ。

空いたスペースには、そこらにあふれてたミクフィギュアが多少並びました。あふれは解決しない模様。

あとは電話機の設定色々やらなきゃ……設置して1週間くらい経つけど何もやってないわ。

Picamera2 v0.3.9リリース。ハードウェアMJPEGエンコード対応!?試すぞ!

昨日付で、Picamera2ライブラリのv0.3.9(beta release 8)がリリースされました。

github.com

今回のリリースは色々追加や修正はありつつ、個人的に目が行ったのはハードウェアMJPEGエンコード対応でした。12月にPicamera2でMJPEG配信を試したときに、Picamera2のMJPEG配信はPicamera1と比べてCPU負荷が結構重めでしたが、やはりソフトウェアエンコードだったようです。

akkiesoft.hatenablog.jp

今回は上のブログとは環境が変わってPi4ですが、同一のPi4上でソフトウェアエンコード(前回のスクリプト)とハードウェアエンコードをそれぞれ動かしてみて、違いをパラッと見てみました。

アップデート

前回テストした環境を流用したため、アップデートを適宜実行しました。

$ sudo apt update ; sudo apt upgrade -y
$ sudo pip3 install -U picamera2 v4l2-python3

バージョンの確認

$ sudo pip3 list
(抜粋)
picamera2     0.3.9
v4l2-python3  0.3.2

ソフトウェアエンコード

まずはソフトウェアエンコード。アイドル中のスクリーンショットですが、CPU負荷は各コア30%くらい、プロセスのCPU使用率もも100%を使うようなものが見られたりして、前回Pi3Bで取得したのと似たような負荷になっています。ストリーミングを開始しても負荷は変わらないため、接続の有無に関わらず出しっぱなしになっているような気がします。

CPU温度は71度くらいと結構アツアツでした(※ヒートシンクなし)。

ハードウェアエンコード

そしてハードウェアエンコード。こちらもアイドル中のスクリーンショットです。各コアの負荷が1ケタ%台になり、プロセスのCPU使用率は30%などとだいぶマシな雰囲気になりました。

ストリーミング1接続中も特に大きくは変わりませんでした。これはソフトウェアエンコードと同様に出しっぱなしになっているものと思われます。

CPU温度も57度くらいに落ち着いたので、効果はバツグンです。

使い物になるようにはなったけど…?

ハードウェアエンコードに変わって、CPU負荷と温度はだいぶマシになりました。これならPi3Bのメダカメラ環境で動かしても問題はなさそうです。実際に切り替えてみたところ、各コア10%前後、プロセスは40%など、63.4度と、Pi4Bよりちょっと負荷が高めという、想像通りの状態になりました。

ただ、初代Picameraがもっと低負荷で動く(冒頭の前回の記事参照)ので、もっとそれに近づいて欲しいし、あわよくば同等になって欲しいので、さらなる改良に期待したいところです。もうちょっと様子を見てもいいかなあ?

節電に目覚めたアッキーソフト!カーテンEjectの消費電力は削減できるか?

カーテンEjectのCD-ROMドライブに使用している電源を、USB-IDE変換とかについていたものから自作USBケーブルに置き換えて節電してみましたという話。


節電をはじめた

ちょっと前に東京電力の節電チャレンジに参加登録をしまして、節電を意識している昨今です。節電チャレンジは、事前予告された時間内に節電をすればいいので、開始時間にエアコンと照明を止めたり、細々した機器とかラズピッピの電源を落として、終了時間まで耐えれば良い感じです。

直近(18:00〜19:00)はこんな感じ。エアコン+照明で700Wくらいのところ、節電中は就寝時に近い100W前後まで削っています。この日は節電対応をしたままお出かけすることで対応としました。電力使用量の記録は、前に買ったスマートメーターのを読むドングルとBルートサービスを使用していますが、プログラムがすぐコケるので半年停止していたものを、プログラムとかドングルの接続とかを見直すことで復活させました。

節電時間中に在宅する場合は、モバイルバッテリーでUSB照明を使って対応しています。エアコンにヤモリグリップで照明を貼り付けてるといい感じになります。モバイルバッテリー充電はそのうちやればOK。トイレも電球型USB照明とモバイルバッテリーで対応します。

一応成果はちゃんと出ているらしく、前年と比べると結構減っていることがわかります。すごいね。


カーテンEjectの電力は削減できるか

さて、節電対応時に止める細々した機器の中に、カーテンEjectのCD-ROMドライブも含まれていて、電源ケーブルを引っこ抜いて対応していました。しかし、そもそも消費電力はどんなもんなのかと思って計測してみると、2.3Wでした。毎朝6時に1回Ejectするためだけに待機2.3W……?なんかもったいないな🤔?

5V換算だと0.46Aなわけですが、電源アダプターの通電LEDがそれなりに食っている可能性がある……?


USB電源に切り替えてみる

というわけで、節電になるかわからないですがUSB電源化してみます。OSCで展示するときに使っていたUSBケーブルを取り出したら、実装の汚さにウ~ンとなったので、ケーブルの改修から先にやりました(脱線)。5Vと12V昇圧用に分けていたUSBコネクターは1つでも良い気がしていたので、それも含めて検証しました。

で、制作過程は一切写真を取ることも無く冒頭の完成写真のとおりになりました。Youtubeとかで制作過程を丁寧に撮るようなやつに、私はなれない……ッ!!

ネクターは別の使い古しを流用して自作。コネクターはピンヘッダーケーブルのメスが出るようにして、モジュールに差し込んで使えるようにしたものの、USBケーブルの接続の考慮が漏れたので、USBケーブルだけモジュールに直接はんだ付けをしました。そして接続部をビニールテープでグルグル巻きにして完成。見栄えはかなりスッキリしましたね。AC-USB電源と芯ケーブルの間はUSB延長ケーブルを噛ましました。

新USBケーブルとUSB電源を使うと消費電力はどうなるか……1.1W(5V換算0.22A)!半分になりました。LEDのぶんだけ差が出ただけという説がありますが、Ejectのトレイ動作も問題なかったので、一応待機電力の削減に成功しました。やったね。


まとめ

無計画な工作が間に挟まりましたが、専用電源?から、自作USBケーブルに置き換えた結果、待機電力を半減させることに成功しました。どちらにせよ気にするような消費電力でもない気がしますが、たかが1Wされど1W。せっかく作ったのでこのままUSBケーブルで行ってみようかと思います。元の電源アダプター自体、引越し前から使っていてかれこれ8年くらいだと思うので、替え時ということにしましょう。

あと、これもAC電源・USB電源のどちらでもできる話ですが、間にオンオフできるスイッチを噛ますのも手ですね。うん、最初からこれで良かった説があるな?

Misskeyサーバーを立ててみた

国産のActivityPub互換な分散型マイクロブログ用ソフトウェアであるMisskeyを立ててみました。Misskeyがどんなもんか触ってみたかったのと、どうせなら構築と運用の知見もほしいなと思っただけです。また、mikutterにあるメインアカウントを捨ててこちらに移るとかではなく、こくだハイクももちろんたたみません。

Misskeyについては開発しているしゅいろさんがgihyo.jpで連載を初めているのでこちらを読むと良いです。

gihyo.jp

今回立てたサーバーは、ほぼ10年間麦子がふよふよしているだけだったmugiko.moeドメインを使いました(テスト用Mastodonもここのドメインを使ったりしてます)。ユーザー登録の解放はしてませんが、招待制でちんまりゆるゆるとやってみようかと思っています。

misskey.mugiko.moe

UIと麦子イラストの相性、なかなか良い。


構成

自宅のDockerホストでdocker-composeを利用してMisskeyを立てて、自宅WebサーバーのUbuntu Server 20.04のApache2からリバースプロキシーします。Mastodonも同じ感じなので、構成自体はわたし的にはそんなもんという感じです。

Misskeyのインストール

以下のドキュメントを参考にDockerでサーバーを立てました。

misskey-hub.net

設定ファイルの書き換えポイントは以下の通り。default.ymlはいらないところを書き換えまくってけっこうミスりました。思ったより書き換えるところ少なかったですね。

  • default.ymlの書き換えは、urlのドメイン部分、DBのuserとpassのみ。
  • docker.envの書き換えは、default.ymlで指定したDBのuserとpassをそれぞれPOSTGRES_USERとPOSTGRES_PASSWORDに当てはめ。パスワードが上の行なので注意。
  • docker-compose.ymlはwebの外向けのportを変更。3000だとMastodonとかぶるので。

Apache2の設定

nginxの設定例はありましたが、Apache2の設定例がなかったので、Mastodonの設定をベースになんとなくでこねこねしました。WebSocketのパスのあたりは自信がない。もしかしたら/streamingまでやっていいかも?

ドメインDNSレコード作成とかLet's Encryptの取得は適宜いい感じにやります。

<VirtualHost *:80>
	ServerName example.com
	Redirect Permanent / https://example.com/
	RewriteEngine on
	RewriteCond %{SERVER_NAME} =example.com
	RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [L,NE,R=permanent]
</VirtualHost>

<VirtualHost *:443>
	ServerName example.com
	DocumentRoot /var/www/example.com

	ErrorLog /var/log/www/example.com-error.log
	CustomLog /var/log/www/example.com-access.log combined

	SSLEngine on
	SSLProtocol -all +TLSv1.2
	SSLHonorCipherOrder on
	SSLCipherSuite EECDH+AESGCM:AES256+EECDH:AES128+EECDH
	SSLCompression off
	SSLSessionTickets off
	SSLStaplingResponderTimeout 5
	SSLStaplingReturnResponderErrors off

	Include /etc/letsencrypt/options-ssl-apache.conf
	SSLCertificateFile /etc/letsencrypt/live/example.com/cert.pem
	SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
	SSLCertificateChainFile /etc/letsencrypt/live/example.com/chain.pem

	Header always set Referrer-Policy "strict-origin-when-cross-origin"
	Header always set Strict-Transport-Security "max-age=31536000"

	RewriteEngine On
	RewriteCond %{HTTP:Connection} Upgrade [NC]
	RewriteCond %{HTTP:Upgrade} websocket [NC]
	RewriteRule / ws://192.168.29.14:3100/ [P,L]

	ProxyPreserveHost On
	RequestHeader set X-Forwarded-Proto "https"
	ProxyPass / http://192.168.1.23:3001/
	ProxyPassReverse / http://192.168.1.23:3001/

	# リバースプロキシ先が死んでたときに出す503ページのための設定
	ProxyPass /503.html !
	ErrorDocument 503 /503.html
</VirtualHost>

(2/16更新) ProxyErrorOverride Onを削除。

初期設定

起動できたらアクセスして管理者ユーザーを作成。細かな設定は以下のページを参考に実施しました。

hide.ac

ユーザー登録解放はしないので無効化しつつ、ほかはちょいちょいですが、ほぼ必須なのはプッシュ通知のためのService Worker設定。Mastodonだと.env.productionに書かれていますが、MisskeyはWebUIに持ってきてるんですね。

あとは設定画面を眺めたり、画像を設定して麦子をちりばめて遊びました。

まとめというか感想

Mastodonと比べて設定の自由度は大きそうでした。まだ触れていない機能も色々あるっぽく、色々充実しています。Mastodonと両方触るとお互いの方向性みたいなのが見えて面白いですね。ただクッキークリッカー機能いる?w

しばらく触っていればアップデートとかストレージ消費量とか、また見えてくるものがあると思うので、ゆるっと楽しんでみようと思いますん。

冒頭に書こうとしたら長くなりすぎたしキモかった雑記

イーロン・マスクによる「ほぼ日刊俺が考えた最強のTwitter(笑)」によってTwitterの先行きがより怪しく見えるようになってきた今日このごろ、皆様いかがお過ごしでしょうか。先週末はMastodonのユーザー数がまた跳ね上がり、Pawooは支えきれず週末の間ダウンし、Misskey.ioもユーザー急増で大変そうでした。

bitcoinhackers.org

また、最近は、Nostrという別のプロトコルによるSNSぽく使えそうなサムシングがもてはやされています。私もちょいと触ってみた感じ、IRC2.0っぽいなあと思った次第です。そもそもIRCに例えて通じるかは怪しいなと思ってTwitterMastodonでアンケートを取ったら、Twitterのフォロワーなら通じそうでしたが、Mastodonは半々でユーザーの層というものを感じさせられました。さておき、Nostrはログの完璧な保存を求めるなら自分で収集する何かを持たないとかなという感じで(TwitterMastodonも同じっちゃ同じですが、儚さレベルが一弾くらい違うかなみたいな)、他も色々というか、まあ、無理じゃないかなあと。このみんなで手探りする感じが良いっていう人もわりといたんですけど、それ多分Mastodonの初期の頃に飛びこんだ人たちも同じこと言ってたんじゃないかなあ。まあ、いい意味で分散かあ。

あと、一部メディアはmixi回帰がどうとか言い始めてますが、ガラパゴス路線に逆走してどうするんでしょうか。日本人だけのSNSに閉じこもっちゃうのは個人的には超ビミョーですかね……。それで良い人ならまあそうしてもらって。それもまた分散。

そもそも、Twitterの代替って一口に言っても、人によって求めるものが全然違いますし。ある人はタイムラインの空気感だったり、ある人はUIだったり、ある人は機能だったり、ある人は投稿の自由だったり、本当にバラバラ。仮に全員が満足するものがあったとしても、Twitterにいる人全員がそっくりそのまま移れるほどのインフラを作ること自体(金銭的に)無理があるので、分散は避けられず、その他も色々諦めないと代替は見つけられないんじゃないかなあと思っています。