tamaの投稿 - Crieit

QnQ開発日誌 Firebaseで管理者用画面はみんなどうしているのかな

2021-11-04T13:27:28+09:00

相変わらず発起人の友人を含む3人でQnQの開発を続けている。

友人が今細かな使い勝手のブラッシュアップをしてくれているので、僕はチーム制導入にあたって、管理者用のコマンドラインツールを作成している。本当は管理者用の画面を作ろうと思っていたんだけれど、セキュリティルールが面倒臭いことに気づいた。

面倒臭い

このWebサービスはFirebaseを使っている。Firebaseは何かと便利ではあるものの、メンテナンスを考えた時にちょいちょい引っかかる。前にも「一時メンテナンスとかどうやるんだろう」と思ったが、調べてみると「意図的にしばらく落とす」みたいなのはなさそうで、強引なリダイレクト処理を入れている人なんかが引っかかった。

今回は管理者用の画面いい加減必要だね、という話をしていて、それ用の画面を作ろうかなと思っていたんだが、そうするとけっこうセキュリティルールが面倒臭い、ということに気づいた。

多分、一部のユーザを「管理者」として、セキュリティルールで都度管理者用の穴を開ける、ということになるだろう。別にやってできないことはないが。

とはいえ、ただでさえうんざりするようなセキュリティルールの記述がさらにややこしくなるのか、とか、管理者特権持っちゃうと、デバッグを兼ねて触っているのに、エラーに気づけなくなりそうだな、とか、色々思うところがあって、うーん、どうしようかなぁと考えた末に、例によってコマンドラインの管理者ツールをシコシコ作ったのだった。

コマンドラインならばAdmin SDKで気にせず書けるし、node.jsじゃなくてPythonでも書ける。入出力を整えてやれば、パイプを使ってそれなりに複雑な操作もできるし。結局こうなるのか。

使い勝手の向上

後は友人が細かな使い勝手の向上に繋がるところをやってくれているようだ。たとえば通知欄で、スレッドAの#20番とあったとして、これを開くとスレッドAの#20番まで飛ぶんだけれど、これまでスレッドAを開いていると#20番に飛んでくれないという謎の状態になっていた。

致命的ではないという感じで放っていたんだけれど、やっぱり不便だった、ということでなおしてくれたんだが、なおってみるとだいぶありがたく思えた。

やはりUXはこういう泥臭い改善の積み重ねなんだなぁと思う次第。全体最適を見失った局所最適は問題だけれど、全体ばかり見て細部を疎かにするのもやはりよくない。

最近「サービスが終わるソシャゲ」をあえていじったりしてみたが、共通して「ゲームのシステム部分がまどろっこしい」というのがあった。同じ作業を嫌がらせのように繰り返させられる、みたいな。できないことはないけど、面倒、という感じ。

今のこのサービスもそういう状態だよなぁ、と反省する。僕は過去「そもそも方向性おかしい」問題に振り回され続けた苦い経験があって、全体最適の重要性については身に沁みているのだが、一方で局所最適の重要性を過小に評価しているのかもしれない。

全体最適と局所最適のバランスは難しく、きっと永遠の課題なのだろうけれど、自分なりの距離感を見つけていきたいものだ。

QnQ開発日誌 SNSからSlack寄りのツールへの移行を模索中

2021-11-02T08:57:05+09:00

まだ続けていたのかと思われそうだけれどまだ続けていた。

Search | QnQ

今何をしているのかというと、SNS的な使い方を諦めて、SlackとかTeams寄りに方向性を変えている。あと使い勝手が悪すぎるので、少しでもUXを上げようと細かい修正。

具体的には、「チーム」みたいなものを作って、そのチーム内でのみ閲覧・書き込みできるような体制にしようとしている。

言い方としては、SlackやTeamsの感じで使う掲示板、って感じかな。あるいは、グループチャットしかないLINEとか？

SNSはキツイしもういらんかな、と

元々SNS的な使われ方を考えて作っていたサービスだけれど、「もうSNSはいいんじゃない」、という話に。評価経済だのなんだの、もう十分でしょ、っていう。

というのは表向きの理由で、実際は「この手のサービスって流行るところまで持っていくのがたいへんすぎるし無理だね」っていう実質的な理由のほうが大きい。特に最近はもうコンテンツさえ作ればGoogleが拾ってくれる時代でもなくなっているし。時代は変わっている。

それでまぁ、それよりも今あるリアルの課題として、「オンラインコミュニケーションの難しさ」があるけれど、それを解決するものとして使えないかな、という話でまとまっている。

イメージはSNSとSlackとかTeamsの間の子くらい

リモートワークでSlackとかTeamsとか使っていると思うけれど、なかなかみんな書き込まないよねとか、すぐ流れちゃうよね、とかいう話をしていて、本サービスの二次元チャットで、ある程度その問題を解決できるんじゃないか、と。

というのも、二次元チャットは言ってしまえば「すべてのレスがリプライ待ち」なので、「話題に遅れる」ということがないし、比較的のんびりしたコミュニケーションにも向いているからだ。このへんの話は、もうちょっと時間をかけてどこかで書きたい。

実際の機能的には、SNSや掲示板とチャットサービスの間くらいの位置づけになるかなぁと思う。開発ではTreeと呼んでいるスレッドをたてるのは掲示板チックだけれど、閲覧権限がチーム。

画像のとおり、「チームの選択」なるものがある。この場合は「qq」としたチームのみで閲覧できるツリー（スレッドみたいなもの）をポストすることになる。ちなみにqqは開発者チームのことで、publicを選ぶと全体公開になる。このへんの名前はわかりやすくしたほうがよさげ。

この機能を、どうつたえるのが一番わかりやすいだろうか。SlackやTeams感覚で使う掲示板。グループチャットしかないLINE。スペースしかないTwitter。そんな感じ？

なので、まだ画面にはフォローとかフォロワーの機能が残っちゃっているけれど、これは完全に撤廃する予定。

なお、まだテスト段階で肝心の「チーム作成機能」はまだ実装していなかったりする。現状、チームは開発者が直接登録する形だ。なので、普通にサインアップすると「全体公開」しか相変わらずできなったりする。

地味なUXの改善

あとはとにかくUX改善しなきゃねっていうところで、本サービス最大の特徴である「二次元チャット」の操作性の向上も少しずつやっている。

友人がしれっと入れた「Ctrl(Cmd) + Enter」での投稿機能は、以前から「あればいいね」くらいの気持ちだったんだけれど、いざ使ってみたら相当便利で、やっぱりUXは実際に入れてみないとわからんなぁと思った。

他、SNSからチャットツール的な使い方を想定=スマホよりPCと割り切ったことで、Macのトラックパッド対応なども。このへんは主に友人が頑張って入れていた。僕はチーム周りの設計などを今メインでやっていて、フロントまわりはあまり絡んでいない。そろそろフロントも真面目にやらんとなぁ、とは思っているけれど中々。

しつこく続ける

ということで、しつこく開発を続けている。まぁこの開発自体が、僕の数少ない友人とのコミュニケーションになっている、というのも大いにあるかもしれない。

イーサネットについて UTPとかSTPとか光ファイバとか

2021-10-12T20:11:49+09:00

昨日LANケーブルの話をしていて、UTPとかSTPとか言われて「ん？なんのこと？」と思った。どうやらケーブルの種類のようだ。あと100mまではイーサネットの規格でOKとなっているとか言われて、そういやイーサネットって、どこからどこまでを定めたものなんだっけ、と気になった。ので、調べた。

一言でいうとIEEE 802.3

まずイーサネットだが、これは仕様的にはIEEE 802.3が本体っぽい。

IEEE 802.3 ETHERNET

基本的には伝送速度の性能を出すための規格で、そのためにOSI参照モデルでいうところの物理層とデータリンク層をカバーしている、とざっくり理解した。つまりケーブルの材質から衝突検知の仕組みはイーサネットの規格のうちだ。どうでもいいけど、OSI参照モデルの分け方はつくづく現実にピタリと合わんな。

以下の記事で、歴史的な経緯、過去の規格をわかりやすく示してくれている。特に一番下の表が参考になった。

イーサネット（Ethernet）のしくみ(1) －イーサネットの規格－ – ネットワークエンジニアを目指して

ケーブル媒体

昔々の10Mbps時代は同軸ケーブルを利用していたらしい。へぇ。100m云々って話が出たのは、100Base-T(Fast Ethernet)かな。ケーブルの媒体を見ると、「UTP」が出てくる。

UTPケーブルとSTPケーブルの違い | LANケーブルと結束バンドのことなら｜パンドウイット

「UTP」は「Unshielded Twisted Pair」の略です。「UTPケーブル」とは「シールド処理が施されていない、ペアの撚りケーブル」を指します。一般的なLANケーブルはこのUTPケーブルを意味しており、家庭やオフィスなど多くの環境で使用されています。

とのことで、なるほど。で、STPはShielded Twisted Pairである。スパニングツリープロトコルではなかった。

通常の家庭の用途でSTPが必要になることはまずないようだ。ただ100mくらいになるとどうなんだろね。信号が減衰すれば、それだけノイズの影響も大きくなりそうだけれど。そういえば昔100mくらいのケーブルを敷設したことを思い出したが、屋内用の癖にやけに固くて、今にして思うとあれはSTPだったのかもしらん。

昔といえば、LANケーブルはお手軽に入手できる撚り線のツイストケーブルとして、コネクタ部分をぶった切って別の用途に利用とかしていた気がする。なんも知らんと色々やっていたな僕。

ちなみにコネクタ部分の規格はRJ-45と呼ばれるが、なんで45なんだ？とふと思ったもののよくわからん。

RJ45（8P8C）とは – IT用語辞典 e-Words

8P8Cは納得できるが、慣習的にRJ-45の呼び名が残ったようだ。まぁ正直名前の意味なんてみんな考えないしね。

さて、UTP/STPはわかったが、それ以外にあるの？というと、ギガビットイーサ以降では光ファイバがある。表にあるSMF（シングルモードファイバ）やMMF（マルチモードファイバ）がそれが。光ファイバについては大昔調べたことがある。

データシートを読んで学ぶ、光ファイバ超入門 – 或る阿呆の記

仕事だと、光ファイバの通信ケーブルを使うこともたまにある。なるほど、こういう規格だったのか。

プロトコルもね

ギガビットイーサだと、見慣れたUTPケーブルのやつが1000Base-Tで、光ファイバのやつが1000Base-Xのようだ。つまり僕らがいつも使っているのは1000Base-Tやね。

しかし、光ファイバだったらそりゃギガビットもでるだろうと思えるけれど、UTPで出るのか？と思ったら、下記の記事で解説されていた。

ギガビットイーサネット（１） – ネットワークエンジニアを目指して

UTPでギガビットイーサを実現するために、今まで使っていなかった線も使うだけではなく、さらに符号化技術にも踏み込んでいる。1回のパルス電圧に5つの値をもたせることによって、ギガビットの伝送速度を実現しているらしい。なるほどなるほど。なんでそんなことができるのかはわからんがなるほど。

まぁ実際、家庭用の通信で光ファイバとかやってらんないので、UTPでできるのはいいよね。なんだかんだいって有線もまだまだ使い所があるし、安定性を考えると有線がいいなっていう場面もあるしね。

異なる規格の混在

ただまぁ、そうやって技術革新を積み重ねていけば、いわゆる下位互換性がなくなることもある。Cat5eとCat6の混在はできるけどCat6の意味が薄れるよ、とかよく聞くよね。

Cat6（カテゴリ6）とCat5e（カテゴリ5e）は混在しても大丈夫？使用時の注意点まとめ | LANケーブルと結束バンドのことなら｜パンドウイット

自分の仕事では帯域とかあまり気にしないので、とりあえずギガビット出るCat5e以上だったらいいよみたいな感じで使っていた気がする。まぁ混ぜて使えるだけすごいよね。実際、下位互換性の問題ってずっとつきまとっているんだろうなぁ、通信系は。

まぁ僕は別にネットワーク系ではないので、あまり深入りする必要もないと言えばないのだが、こういう雑知識は得ておくとトラブった時に使えることもあるし、なにより先人たちの苦労を垣間見れて楽しい（当人は楽しくない？それとも楽しい？）ものである。

QnQ開発日誌チームで使う作業メモの共有的な使い方を考える

2021-09-13T02:57:17+09:00

開発っていうか、まぁこのままじゃ一生誰も使わないよね、ということで、どうしたもんかな、と話していた。

結論的には、チームで作業メモを残して共有するような用途に使えないかな、という話になっている。それに向けて、具体的な作業を明日から始めて、来週の連休には実証できるような状態にしたい。

なんちゃってもくもく会

時間をかけて作ったWebサービスは、相変わらず僕の独り言か、あるいは友人との交換日記くらいにしか使われていない。

なんだけれど、アクセス解析を見ると、どうも10人くらいはそれなりに見にきてくれている人がいると思われる。個人ブログを購読しているような感じなんだろうか。不思議だ。まぁユーザー10人って、個人ブログにしてもあまり流行っていない規模だけどね……マンネリ化して久しい僕のブログのほうがよっぽど人が多い。

まぁでも、見てくれる人がいることは有り難い。が、書き込みまではいかないし、このまま続けても書き込まれる未来が見えないので、いい加減ちょっと方向性考えないとね、という話を友人としていた。

話しているうちに、ユースケースとして、チームで開発経過を残し、共有する用途はどうだろうか、という話になった。というのも、現在、僕と友人は「もくもく会」と称して、毎日に近い割合で、日々の作業をサービス上で共有しているのだ。ちょうど50回を迎えた。

もくもく50 2021-09-12 | QnQ

tamaは僕で、yuが友人なのだが、それぞれの枝に分かれて、自分の作業を書き残しているような感じ。で、時々相手の枝にレスしたりしている。

これを、チームの開発に使えないかな、というわけだ。

作業報告、雑談、軽いコミュニケーション

このコンセプトは悪くないんじゃないか、と思っている。

リモートワークが盛んになって、よく言われる問題として、「雑談がなくなった」「寂しい」「他の人が何をしているのかわかりづらい」というのがある。

原理的には、SlackなりTeamsなりで個々人が自分の作業を報告しあえればいいんだけれど、SlackにせよTeamsにせよ、そういう用途を想定して作られたわけではなく、ちょっとやりづらい。

まぁやるとすれば、自分の作業用のスレッドを作って投稿していく、というスタイルが考えられるだろう。というか、昔職場でそんなようなことをしていたこともあった。

あれは悪くなかったんだが、他の人のスレッドって、なかなか見に行こうと思わないと見に行かないんだよね。その点、このサービスなら、特に意識せずとも相手の状況を把握できる。なにかエラーなどでハマっているようであれば、力になれることがあるかもしれないし、逆に助けてもらえるかもしれない。また、仲間のやっている仕事は、けっこう参考になるものだ。

ということで、リモートワークが盛んになり始めた今の時代に即したサービスだと考えられて、中々面白いんじゃないかと思っている。

まー、使ってもらう、というのが一番むずかしいんだけどさ。ただまぁ、目的が明確なら、誰かを誘ってやってみる、ということもできないことはないはずなので、そこはまぁ、頑張るしかない。

技術よりも広報が難しい！！

QnQ開発日誌単体テストなしで大丈夫か？

2021-07-30T02:39:33+09:00

デプロイしたらサインインしていない状態でサイトが見られなくなった、QnQの開発日誌ですこんにちは。今は修正している。

Firebaseのセキュリティルールをミスっていたせいなんだが、Seleniumを使ったUIテストしかなく、匿名ユーザーの挙動がテストケースから漏れていたために気づかなかった。

単体テストがない

この程度のことは単体テストでやるのが良いのだろうと思うのだが、開発メンバーで真面目にフロントエンドをやってきた者がおらず、なかなかハードルが高い。まずVue.jsという時点で経験がないのに、そのうえFirebaseが絡むので、どうにも手を付けられていない。せめて、新しい知識がどちらか片方ならまだなんとかなったと思うのだが……。

UIテストだけ

そんなわけで、せめてこれくらいは……とSelenium IDEを使ってUIテストだけなんとか実行している、というのが現状である。

正直これがあるだけでも実は頑張った。さすがに何のテストもないのはまず過ぎる、と思って作ったのだが、大きな修正のたびに思いもよらないところでテストで引っかかってくれているので、実際役に立っている。

ランスルーテストを流すと普通に数分かかるが、まぁその間はコーヒーでも入れて飲めばいいのだ。

単体テスト入れたいというより

しかしまぁ、さすがにそろそろ単体テスト入れなあかんよなぁと思うのだが、それにしてもハードルが高い……。

というかコードがスパゲッティで非常に汚いし、そもそも抜本的にこのUIどうなの？と非常に思うところあるので、ぶっちゃけフルスクラッチで最初から書き直したほうがいいのかもしれない、とか思う。

ダイエットとバグ修正の話を一緒にできる、そうQnQならね

ちなみにこのバグ修正は、友人とWebサービス上でやりとりしていた。GitHubでもやりとりしたけど。俺の日記帳状態だったが、再び友人との交換日記状態に復帰している。やっぱり複数で使うと楽しい。

もくもく22 2021-07-28 | QnQ

で、上記のスレなのだが、このサービスの特徴が出ている。

上図のように、「ダイエットの話」と「バグ修正」の話を並行している。こういう体験は他ではないはずで、自分たちでは「面白いと思うんだけどなぁ」と言いつつ、閑古鳥が鳴いている僕らのサービスである。

なんか面白そうだなと思ったら、覗いてやってください。

QnQ開発日誌開発したWebサービスは俺の日記帳になった

2021-07-26T02:59:19+09:00

こんにちは。二次元掲示板、「QnQ」の開発日誌でございます。

前回の記事「開発中のWebサービスは友人との交換日記と化した – 或る阿呆の記」では友人との交換日記と言ったが、最近は友人も忙しいのか書き込み頻度がめっきり減ってしまい、最近は書き込みの多分9割くらいが僕の独り言と思われ、交換日記どころかもはや「俺の日記帳」みたいになってしまった。まぁTwitterのタイムラインを汚さずに、いいたいことをネットの虚空に向かってペラペラとしゃべっているとでも言えばよいだろうか。

長らくそんな状態だったのだが、本当に「みんなの日記帳」的な方向に開発が進みそうだ。

俺の日記帳

ここまでに大きな変化もあり、発起人である友人は元々の目論見が外れたということで、ユースケースに悩んでいるようだった。まぁ悩んでいるのは、僕が散々「このサービスは結局なんなんだ」とつっついたせいもあるかもしれない。

というと肝心なところを人任せかという感じだが、それは彼が発起人でありプロジェクトでいえばリーダーに相当するからであって、別に責任を押し付けているわけではない。実際、僕も僕なりにサービスの可能性は模索していて、冒頭に書いたとおりもはや書き込みの9割……多分言い過ぎじゃなくそれくらいが僕の独り言みたいな状態になっているほどだ。

そして僕の現在における結論、というよりは現状が、「俺の日記帳」なのである。

具体的には、普段の開発や勉強の軌跡を綴ったり、YouTubeでやっているアニメ美味しんぼの実況をしたり、気になるニュースについて徒然と語ったり、といった具合である。

まぁ正直、Twitterのタイムラインを汚さずに好き勝手言えていいな、程度の感じである。ここから記事化したのもあるので、まったくもって全部無駄というわけではない。

二次元掲示板の使い道

現状のUXから、このサービスの本質を一言で言えば、「二次元掲示板」になるだろう。時系列、あるいは人気順などで書き込みを並べる通常の掲示板と違って、このサービスは書き込みの流れを二次元的に表現している。

個人的にはこのUIだけで面白いものだと思うし、本当を言えばいろいろな人たちの雑談や議論に使われてほしいと思う。二次元掲示板は、常に文脈が強烈に意識されるため、単発の言いっぱなしになりづらいのである。これはTwitterなどで実りのない応酬にしんどみを感じている人たちなんかには特に有効だと思われる。

ただまぁ、そのためには人を集める必要があるのだがそれも難しく、結局ソロユースでの使い道ばかりになってしまった、というのが実際のところだ。これはこれで個人的には可能性があるものだとは思ってはいるので、とりあえず当面はソロでぼちぼちやっていくつもりだ。

と、いう決意を固めていたわけではなかったのだが、今日の話し合いでもまずはソロで地道に使っていくのが現実的かもね、という話になってしまったので、晴れてチームとしても方向性が「俺の日記帳」ならぬ「みんなの日記帳」サービスになってしまったかもしれない。

僕もそうするより他ないんじゃないの、なんて言いながら、正直言うと本当にそれでいいのかなぁ、とか思ったりする気持ちはないでもない。かといって他にアイディアがあるわけでもない。

サービスを使ってもらうってのは難しいなぁなんて思いながら、つくづくTwitterとかnoteはすげぇなぁと、感心するばかりだ。

for文の中でawaitして返り値使う直列処理を Promise.all() で並列処理

2021-07-25T21:32:29+09:00

何か日本語の不自由なタイトルだが、実際僕の思った疑問をそのまま文章にするとこんな感じだった、というか実際こういう間抜けな文章で検索していたので、このままいくことにする。

JavaScriptでfor文の中でawaitして直列でやっている処理を、Promise.all()を使って並列にやりたい、ということだ。const answers = Promise.all( …. ) と書きたい、という話。さらっと検索すると返り値を使うサンプル。

やりたいこと

論よりコードということで、以下のようなfor文があったとする。

function triangle (base, height) {
  return new Promise(resolve => {
    setTimeout(() => {
      const area = base * height / 2;
      console.log(area);
      resolve(area);
    }, 3000);
  });  
}

(async () => {
  let areas = []
  for (const i of [1, 2, 3, 4, 5]) {
    const area = await triangle(i, i);
    areas.push(area);
  }
  console.log(areas);
})();

底辺と高さが1, 2, 3, 4, 5の三角形について面積を求めて、最後に出力している。直列でやっているため、3秒ずつ結果が順番に表示され、15秒後にすべての答えが表示される。

これらの処理は独立であるので、並列で書けるはずだ。

並列化

これを並列化すると、以下のようになる。

(async () => {
  const areas = await Promise.all([1, 2, 3, 4, 5].map(async (element) => {
    return await triangle(element, element);
  }));
  console.log(areas);
})();

実行してみるとわかるが、3秒ですべての処理の答えが出るので、並列で処理してその結果を利用できることがわかる。

２つの処理を同時に走らせてみると、以下のように出力される。

0.5
0.5
2
4.5
8
12.5
[ 0.5, 2, 4.5, 8, 12.5 ]
2
4.5
8
12.5
[ 0.5, 2, 4.5, 8, 12.5 ]

まず並列処理の回答がすべて表示されて、その後逐次直列の処理の結果が出ていることがわかる。

以上。

参考

ありがとうございました。

for文、forEach文のループ処理でasync/await、Promise.allを効果的に使う方法 – ブロックチェーンエンジニアとして生きる

10年ぶりにFirefoxを3ヶ月ほどメインにした所感

2021-06-19T19:16:24+09:00

ここ10年ほど、僕はずっとGoogle Chromeを使っていた。正直Chrome最強だと思う。Chrome最強だと思うんだが、どういうわけなのか、僕のMacではやたらとCPUを使ってくれて、ただでさえ爆熱のMac mini 2018を目玉焼きでも焼けそうなほどに熱してくれる。MacBook Pro 2019でも同様だ。Windowsのマシンではそういうことはなかったので、Macとの相性問題もあったりするんだろうか。それとも何かエクステンションが悪さしているのか。

Firefoxを使い始める

わからないが、もうずっと爆熱が続いて全然なおらないので、ついに僕はChromeをメインにすることをやめて、Firefoxを使い始めた。それが今年の3月のことだ。

Firefoxをメインにするのは、10年ぶりくらいだろうか。僕の中ではFirefoxは今なお3.5だったのだが、もうバージョン90になっている。おかげで軽くタイムスリップしたような気分になれた。

さて、久方ぶりのFirefoxだが、けっこうすんなりと移行することができた。まぁもともと使っていたしね。

以下に、Firefox移行後の所感について書く。

爆熱は微妙におさまった

まずChromeからの移行のきっかけとなった爆熱についてだが、これは微妙におさまった。微妙にというのは、Firefoxも立ち上げてしばらくすると、やはりCPUをぶん回し始める現象が起きたからだ。

しかし、ウィンドウを閉じるとおさまるので、プロセスを終了しないと暴走がおさまらなかったChromeに比べるとマシだ。また、Chromeは起動してすぐくらいの勢いで暴走を初めていたが、Firefoxについては長時間起動していると、という感じなので、まぁいいかなという感じ。

ブックマーク、パスワードの同期

次に同期の問題。

まず、パスワード同期については僕はBitwardenを利用しており、BitwardenはFirefox用のエクステンションも提供しているから、その点は問題ない。

ただ、Android用のFirefoxブラウザにおいては、パスワード欄をタップした時のBitwarden連携が不安定で、出たり出なかったり、出たとしても一瞬で消えたり、ということが頻発してちょっと苛々する。iOS用Firefoxではそういう問題は起きない（まぁキーボードにパスワードマネージャの立ち上げがくっついてる形なので）。

ブックマーク同期については、昔はそれ用のソフトを使っていた（具体的には確かXmarksだ、もうサービス終了している）が、今はブラウザの同期機能を利用しているため、Firefox Syncの世話になった。これは普通に使えたのだが、職場ではproxy経由の時に問題があるのか、使えなかった。うーん？まぁいいけど。

それにしても、今ってクロスブラウザを前提にしたブックマーク同期アプリってあるのかな。ここしばらくChrome一強時代が続いているから、ちょっと厳しいよね。

パフォーマンス

パフォーマンスについては、正直体感ではあまり差がない。その昔は明らかにChromeのほうが快適で、まぁそのためにChromeは天下を取ったとも言えるのだが、今はそんなこともないようだ。

画面の崩れ

ほとんどない。今どきのモダンブラウザで表示が問題になることはないようだ。IEを使っている人は税金払ってほしい。

あ、そういえば職場のクソアプリが、Chromeだといつもレイアウトが崩れていたんだけれど、Firefoxだと崩れなくなった。

エクステンション

PCでWebブラウジングする魅力は、なんといってもフルブラウザ、というか豊富なエクステンションだろう。Amazonの商品の金額遷移を表示するKeepa、タイトルとURLをコピーするシンプルながら使い勝手の良いCreateLink、複数リンクを同時に開くLinkclump、Google検索からゴミサイトを排除するゴシップブロッカーなど、愛用しているエクステンションはいくつかある。

で、調べてみるとだいたいFirefoxに対応しているか、あるいはFirefoxで使える代替えとなるエクステンションがあったので、これも問題がなかった。ただもちろん、人によっては諦めなければならない機能はあるだろう。

とはいえ、大昔野良エクステンションが跋扈していた時代に比べると、随分と環境が整備されたのだなぁと思う。

スマホの検索窓など画面下部に

細かいのだが、いいなぁと思ったのはスマホのFirefoxだと検索窓を画面下部にすることができるところだった。

これは楽天Bigのスクリーンショットだ。楽天Bigはクソデカイので、検索するには少しばかり親指をダルシムのごとく伸ばす必要があるのだが、画面下部にあればホビット族の血を受け継ぐ僕も楽々検索することが可能だ。これは地味ながら嬉しいユーザー体験だった。

既に開いているタブ一覧なども、Chromeがやたらと親指の限界を試すのに比べて、Firefoxは軽く伸ばせば届くところがタップ範囲で、非常に好ましく思えた。

タブをウィンドウから移動させた時の挙動が不満

これまた地味だが、PCでタブを別ウィンドウに移動させた時、期待する動作はマウスポインタの場所あたりに新たなウィンドウを開いてタブが移動することだが、どうもそうならない。これがMac版故なのかどうかはわからないが、あまり直感的ではない。まぁ大した問題ではないのだが、ちょっとイラッとする。

マルチユーザーだとちょっと使いづらかった

Firefoxでマルチユーザーっぽく使おうと思ったら、ユーザーごとにprofileを作成し、都度切り替えていくことになると思うが、どうも使いづらい。

たとえば他アプリからURLをクリックしてFirefoxに飛ぶ時、Chromeだと最後に開いていたユーザーのウィンドウで開くが、Firefoxだと必ずデフォルトのprofileで開かれてしまう。

また、Firefoxを起動した時に最初に開かれるのがデフォルトユーザーではなくなることもちょくちょくあり、まぁOS再起動などすればなおるのだが、どうにもprofile周りは挙動が若干不安定に思えた。

そもそもabout:profilesを毎度入力するのがイケてないように思うが、他にいいやり方があるんだろうか……。

まぁでも、少し特殊な使い方だとは思う。

総評

ということで、Firefoxを3ヶ月ほどメインにした結果、十分に使えるものだということがわかった。

わかったが、しかしFirefoxでなければならない積極的な理由も特にはなく、恐らく多くの人にとってFirefoxを使う一番のモチベーションは「Chromeを使いたくない」になってしまうのではないだろうか。

まぁでも、それは案外バカにできない理由かもしれない。僕のChrome熱暴走問題は恐らくおまかんなのだが、おまかんと言われても僕の環境で起きている以上僕にとっては大きな問題であって、ブラウザを変えるだけで解決できるならそうしてしまいたいし、事象が異なるだけでブラウザを変えたい気持ちになっている人は、何も宗教上の理由がなくてもけっこういるであろう。

まぁもちろんChrome以外というだけなら他にも選択肢があるんだが、「結局WebKitじゃねぇか」みたいなものが多い中で、Firefoxの「Geckoですけど？」はひときわ輝いてみえる（個人の感想です）し、昔からクロスOSでやってきている信頼感もある。

ということで、Firefox悪くないんじゃないの、と言いながら、実はこの記事はBrave上で書いてます。結局WebKitじゃねぇか。いやBlinkです。使えればなんでもいいよ。はい。

EMC村の動画でフェライトコアの原理を勉強した

2021-06-16T23:37:25+09:00

【ノイズ対策】知らなきゃ損する！フェライトコアの使い方 #28 – YouTube

このチャンネル本当に面白いし有り難いし10年前に見たかった。めっちゃオススメ。今回見たのはフェライトコアについての解説。あー10年前に見たかった。

フェライトコアの思い出

フェライトコアがノイズを減らすのは知っていた。

というのも、フェライトコアに思い出があって、大昔レーダーやっていた時に、基板設計の人が失敗したらしくめちゃくちゃノイズだした結果、とにかくつけまくったという記憶があるのだ。いや、この作業自体はどうでもよくて、覚えているのは設計の人が品管にめちゃくちゃ詰められていて可哀想だったことだ。その品管の人はいつもピリピリしていて、かつ設計＞品管のヒエラルキーが工場内ではあるためか、ここぞとばかりに責めまくっていたように見えた。なんだかなぁと若かりし僕は思ったものだ。

ノイズどうすんねんと詰められた設計が持ってきたのがフェライトコアだった。自分の設計ミスなのでと、申し訳なさそうな設計の人と一緒にフェライトコアをあちこちにつけた記憶。僕はフェライトコアがなんなのか知らなかったが、とにかくその設計の人が可哀想だったので、うまくいってほしいなと思いながらフェライトコアをつける作業をしていた。

まぁ結果的にノイズはよかろうという程度に減ったのだが、フェライトコアがなぜノイズ対策になるのかは知らなかった。

フェライトコアがノイズ対策になる理由

フェライトコアは磁性体で、ノイズ電流によって発生した磁束を取り込んで熱に変換するのだが、特に高周波に対して抵抗の性質を持つことで、ノイズ対策になる、ということだ。普通の抵抗はすべての周波数に対してきいてしまうが、フェライトコアは一種のローパスとしてはたらくらしい。なるほどね。

フェライトコアの利用で考慮すること

まぁもはや僕が使うことはないだろうと思いつつ、考慮すること。

低周波用と高周波用がある

だいたい1MHzを境に、低周波用と高周波用があるとのことだ。1MHz……だいたい高周波用だったのかなぁ。

巻数

巻数が多いほどノイズ対策になる、とのことだ。まぁそれはなんとなくわかる。数式的には、インピーダンスは巻数の自乗に比例する、とのこと。ただ100MHz超えの高周波帯では、増やしすぎると高周波のインピーダンスが下がってしまうこともあるらしい。その原理も教えてもらったけどよくわからかった😂

ノイズの伝搬モード

ノイズの伝搬モードにはノーマルモードとコモンモードがある。ノーマルモードは二本の線で行って帰ってくるようなノイズなので、それぞれの線にフェライトコアを取り付ける。一方コモンモードは同じ方向のノイズなので、一緒に取り付ける。なるほど。伝搬モードによってフェライトコアの取り付け方が違うので、伝搬モードを確認しておく、ということだ。

ようやく原理を知ったのだった

今はもう全然違う仕事をしているので、もう僕がフェライトコアを直接使うことはないだろうが、なんとなく思い出して見てしまった。まさかフェライトコアを知ってから10年近くたった今になってその原理を知ることになるとは。当時この動画を見たかったものである。

DynamoDBの多対多で隣接リストやった時の冗長性対策どうしよう

2021-06-12T18:01:20+09:00

DynamoDBウキウキで初めて早速引っかかる問題の一つが多対多とn+1問題だと思うんだが、これについてはAWSのドキュメントに一応解決方法が乗っている。それについて書いた記事がこれ→「DynamoDBで多対多のテーブル設計 – 或る阿呆の記」。

隣接リストというデザインパターンで、初めて見た時はギョッとしたけど、実際やってみるとたしかに効率的にクエリが書ける。テーブルの構造についても、ああつまりRDBの中間テーブルに要素をもたせるとこうなるのか、ということで、個人的には納得もした。

ただこの方式は、冗長である。したがって、同一であるべきアイテムの情報に不整合が発生する可能性がある。それについて、どう対応したもんなんだろうか。

トランザクション処理

真っ先に思い浮かぶのはトランザクション処理だ。進化を続けるDynamoDBは、一定の制約はあるもののトランザクション処理もサポートするようになった。試しに使ってみたのが「DynamoDBにboto3でトランザクションな書き込み – 或る阿呆の記」の記事。

ただ数的な制約とか、boto3.resource()だと使えなくて低レベルなboto3.client()を使う必要があったとか、Lambda関数のboto3が古くてzipあげる謎工程が必要だったとか（さすがにこれはもう解決しているだろうが）あって、結局実際には使わなかった。

トランザクション処理はDynamoDBにおいては最終手段の気もする。

バッチによる定期メンテ

次に思い浮かぶのは、不整合を確認するバッチによる定期メンテだ。一日に一回くらいテーブルをフルスキャンして、おかしなところがないか確認する。

というとなんか阿呆っぽいんだけれど、実際こういうバッチを走らせてなんとかしているシステム世の中たくさんあると思う。。。

リアルタイム性を犠牲にできるユースケースであれば、なんだかんだでこれが一番ラクな気がする。しかしそうやって謎のバッチスクリプトがあちこちで走り始めると、何がなんだかわからなくなってくるので、管理の問題は別途出てくるけど……。

ほっといてもそのうち直る仕組み

このケースはけっこうある。たとえば最新値などがそうで、最新値は常に変わり続けるから、たとえ1回ミスって不整合があっても、ほっといたら再更新かかるのでなおっている。それだったらわざわざコストかけて面倒見るより、あえて放っておく、で十分だったりする。

結局……

ということで、自分はといえば、結局

リアルタイム性が必要→更新が多いはず→対応しない。ほっといたらまぁだいたい合ってるでしょって感じ
リアルタイム性はそんなでもない→あんまり更新もない→バッチで確認したら十分

のあわせ技でなんとかしている感じ。とはいえ、実際不整合はほとんど発生していなくて、たまに見つかるとだいたいアプリケーションのロジックがそもそもポカしていたりするので、まぁこれくらいでいいのかなぁと思いつつ、みんなどうしているんだろうというのは気になっている。

開発中のWebサービスは友人との交換日記と化した

2021-05-16T18:36:44+09:00

友人が発起人になって、一緒に開発したWebサービスがある。

QnQ

これはまぁ、一言で言うと二次元チャットみたいな感じ。二次元チャットってなにそれ意味分かんないと思われるが、Twitterのツイートツリーが分岐する様子が可視化されたもの、といえば少しイメージがわくだろうか。たとえば以下のような感じだ。

二次元チャット

ブログとnoteの使い分け | QnQ

僕がnoteを本格的に書き始めたのはここ10日ばかりのことだが、もともとブログをやっていた僕は、その使い分けをどうしたものかと考えていた。で、それについて考えた軌跡である。僕の考えがツリー上に展開されているのがわかるだろうか。

これは僕の独り言状態だが、ログインしていれば誰でもコメントをつけることが可能だ（上記のURLについては、既にクローズしているのでコメントはつけられない）。で、見切れているが友人もコメントしてくれている。

多分今までにないフレームワークで、けっこう面白いと思う。

ちなみに、当初かなり意識高い系で売ろうとしていた。友人がnoteに公開記事を書いている。

質問に質問で返されるドM向けQ&Qサービスを公開｜adnyer｜note

ちなみに僕も自分のブログに紹介記事を書いた。

質問に質問で返されるドM向けQ&Qサービス、QnQを公開・開発中です – 或る阿呆の記

タイトルは似ているが、内容は僕と友人の性格的な違いがけっこう出ている。

さて、このサービスだが、公開して半年ほど経過するものの、たいへんなことに現在定着したユーザーは0である。マジで。使ってくれた人もいるが、定着した人はいなかった。

その理由については色々思うところありつつ、せっかく作ったので僕と友人は使っている。その結果、長い時間をかけて作られたこのサービスは現在、僕と友人の交換日記状サービスになっている。交換日記ならまだマシで、僕の独り言コーナーになっていることもよくある。

それでも開発を続けているのは、実際面白いサービスだと思っているのと、まぁ数少ない友人との繋がりだから、みたいなのもある。後はまぁ、自分でサービスを開発して運用しています、というのは今後転職する時にも使えるだろう、というのもある（今の職場にはそれなりに満足しているので、転職予定はない）。

とはいえ、さすがに僕と友人の交換日記状態が延々と続くのは余りにも悲しいし虚しい。使ってもらえないのはサービスとしての魅力がないからなんだが、僕にはどうしても本質的に面白さのあるサービスだと思えてならない。自分の子供だから可愛く感じるんだと言われればそうかもしれないんだが……。

どうにも諦めるには惜しい気がするので、もうちょっとちゃんと作り直し、都度宣伝もしていきたいと思っている。

noteは始めたばかりだが、SNSとして非常に参考になるところがあるので、色々考えて反映し、なんとか使ってもらえるような、魅力あるサービスにしていきたい。定期的に開発日誌をつけていくつもりだ。がんばろう。

Lambda関数でDeadLetterQueue(DLQ)を試す

2021-05-13T23:16:42+09:00

AWSのLambda関数をイベントで起動した時、複数回エラーを起こしたら、DeadLetterQueue、すなわちDLQを飛ばしたい。DLQを試すもの。Cloudformation使う。DLQはSNSとSQSが指定できるが、今回はSNSを使う。

系

以下の系を試す。

CloudWatch -> Lambda -(error)-> SNS -> Email

やってみる

CloudWatchで1分ごとにLambda関数を起動するようなものを、Cloudformationｗと使って用意する。SNS Topicについては、コンソールから作成する。

SNS Topicを作る

コンソールからSNS Topicを作成する。名前は仮に DeadLetterQueueTopicとする。とりあえずEメールに飛ばすようにしておくと、確認しやすいと思う。

ディレクトリ構成

ディレクトリ構成は以下。__init__.pyは空。

.
├── __init__.py
├── hello_world_function
│   ├── __init__.py
│   ├── hello_world
│   │   ├── __init__.py
│   │   └── app.py
│   └── requirements.txt
├── samconfig.toml
└── template.yaml

という構成でやってみる。

template.yaml

TargetArn に SNS Topic のARNを入れる。

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
  sam-app

  Sample SAM Template for sam-app


Globals:
  Function:
    Timeout: 3

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: hello_world_function
      Handler: hello_world/app.lambda_handler
      Runtime: python3.8
      Policies:
        - AWSLambdaBasicExecutionRole
        - arn:aws:iam::aws:policy/AmazonSNSFullAccess
      Events:
        HelloWorld:
          Type: Schedule
          Properties:
            Schedule: rate(1 minute)
      DeadLetterQueue:
        Type: SNS
        TargetArn: arn:aws:sns:xxxxxxxxxxxxxxxxxx:DeadLetterQueueTopic

samconfig.toml

sam build –use-container の後に sam deploy –guided で作るとよい。以下のようになる。

version = 0.1
[default]
[default.deploy]
[default.deploy.parameters]
stack_name = "sam-app"
s3_bucket = "aws-sam-cli-managed-default-samclisourcebucket-1miie23rwqpqg"
s3_prefix = "sam-app"
region = "ap-northeast-1"
capabilities = "CAPABILITY_IAM"

requirement.txt

空でもいいけど。

requests
six
regex

hello_world/app.py

def lambda_handler(event, context):


    return True

DLQ

sam build --use-container

sam deploy

デプロイすると、1分間にLambda関数が起動する。で、このままだと正常に終了してDLQが飛ばないので、わざとエラーを起こす。そのためには、上記コードの raise Exception のエラーを外してデプロイする。しばらく待っていたら、DLQがSNSに飛ぶ。SNSのSubscriberにEmailを用意しておけば、すぐに確認できる。

後片付け

SNSのトピックは手動で作成したので、手動で消す。

忘れずにスタックを消す。消し忘れると延々とLambda関数が起動し続けることになってしまうので注意。
aws cloudformation delete-stack --stack-name sam-app

DLQ -> SNS -> Lambdaにした時のproperty

Slackとかに飛ばしたい時は、DLQのSNS経由でLambda関数に飛ばすことになる。Lambda関数のeventのpropertyをメモしておく。

{
  "Records": [
    {
      "EventSource": "aws:sns",
      "EventVersion": "1.0",
      "EventSubscriptionArn": "xxxxx",
      "Sns": {
        "Type": "Notification",
        "MessageId": "xxxx",
        "TopicArn": "xxxx"
        "Subject": None,
        "Message": "xxxxxxx",
        "Timestamp": "2021-05-13T03:02:52.129Z",
        "SignatureVersion": "1",
        "Signature": "xxxx",
        "SigningCertUrl": "xxxx",
        "UnsubscribeUrl": "xxxx",
        "MessageAttributes": {
          "RequestID": {
            "Type": "String",
            "Value": "xxxx",
          },
          "ErrorCode": {
            "Type": "String",
            "Value": "200"
          }
        }
      }
    }
  ]
}

気になるのは event.Sns.Message だが、これはシリアライズされたJSON。json.loads()でデシリアライズすると以下のようになる。

{
"version": "0",
"id": "xxxx",
"detail-type": "Scheduled Event",
"source": "aws.events",
"account": "xxxx",
"time": "2021-05-13T02:47:42Z",
"region": "xxxx",
"resources": [
"xxxx",
],
"detail": {}
}

resourcesとidから、エラーを起こした元のLambda関数を辿ることができる。

参考URL

ありがとうございました。

TwitterのツイートログをEvernote経由でObsidianに落とし込んでいる手順

2021-05-08T00:09:10+09:00

やりたいことはつまりTwitterのログをObsidianで保存したいということなのだが、なぜEvernoteを経由という無駄っぽいことをしているかと言えば、元々Evernoteでツイートを管理していたからだ。個人的にはもはやEvernoteを使うことはなく、以前のログ置き場にしかなっていない。元々のやり方を踏襲しているのでEvernoteを経由しているだけで、別にEvernoteを経由する意味は本質的にない。

が、さすがに老舗のサービスだけあって、連携したサービスやソフトも多くあるので、それらを使うことで、プログラミングをすることなく、TwitterのログをObsidianに保存するという目的は達成できたので、とりあえず今はそのようにしている。この記事は、その手順のメモである。そのうちにはEvernote部分を取っ払いたい。

ツイエバでTwitter→Evernote

まずTwitter→Evernoteだが、これは「ツイエバ – TwitterのツイートやメンションをEvernoteとEmailへ」のサービスを利用している。

なぜツイエバを使っているのかと言えば、もともとEvernoteに情報を集約させていたからだ。しかし、昨今あまりにもEvernoteが使いづらくなり、先行きも不安しかなく、正直もはやEvernoteを経由する意味はない。

まぁでも、老舗なだけあってなお種々のサービスとの連携があるのは強みかもしれない。

evernote2mdでEvernote→Obsidian

さて、問題はEvernoteからどうやってObsidianにするか。だが、これはつまりEvernoteのノートをいかにしてmarkdown形式に変換するか、という問いに等しい。

まずEvernoteのノートをローカルに落とすには、Evernoteのデスクトップアプリで、普通に「エクスポート」を使って.enex形式で落とせば良い。いつの間にか、50個までしかまとめてエクスポートできなくなっていた……そういうことするから、みんな離れていくんやで……。

問題は.enexをどうやって.mdに変換するかだが。

これはGitHubで公開されている「wormi4ok/evernote2md: Convert Evernote .enex files to Markdown」がもっとも楽だと思う。

インストールはREADME.mdにあるとおり、Macなら

brew install evernote2md

でOK。

で、使い方は、以下。

evernote2md <エクスポートした.enex>

これを実行すると、notesディレクトリができていて、その下にmd形式に変換されたノートがある。あとは、これをObsidianのユーザーディレクトリ下に打ち込むだけ。

これでけっこううまいこと変換される。

うん。満足。

着々とEvernoteからの乗り換えが進む

既にメモ用途としてはほとんどObsidianにうつっている。

Web Clipさえも、最近はnoteを使っているが、しかしWeb Clip、なんだかもう使わなくなっちゃったな……。

Evernote、もうダメかもなぁ。昨年末の大改造は大不評だった。みんな、課金体系とかじゃなくて、アプリの安定性や機能に文句を言っていた。僕もそう。

以前はプレミアム会員だったこともあるのだけれどね。。。

楽天Bigを買いました。iPhone 8 と半年かけて比べていきます

2021-05-05T18:32:34+09:00

楽天Bigを購入した。別にさほど欲しかったわけではないのだけれど、楽天のUnlimitedプランの一年間無料が4/7までであったことから、駆け込みで申し込み、ついでに購入してみたという流れだ。中身はZTEだし、49,800円はちょっと高いなというのが実感だが、まぁ2万ポイント返ってくるので良しとする。今どきの楽天ポイントはRakuten Payで使えるし、良いだろう。

これから半年ほどかけて、iPhone 8とどちらをメインにするか、自分の生活に合わせて検証していくつもりだ。

携帯料金値下げの流れ

携帯料金の値下げは菅総理肝いりということもあって、各社一斉に相当の値下げがなされた。MNOではDoCoMoのahamoが皮切りになったし、MVNOではIIJが口火を切って、さらにnuroが追いかけたという感じ。

この流れは楽天にとっては逆風と思われ、実際ahamoにはかなり焦らされたのではなかろうか（まぁahamoに度肝を抜かれたのは業界全体そうだろうが…）。これ、ITリテラシーの低いそうのサポート代金が視覚化された側面もある（「20GBで2980円のahamoが安いわけ　実はドコモの本音も見え隠れ（佐野正弘） – Engadget 日本版」）。

まぁ言ってしまえばIT介護費用だったんだよね。それをなくせば安くなる、と。これは菅総理の思惑とは違ったかもしれないし、そもそも総理の介入は正直どうかと思うんだけれど、サポート費用に対価をつける流れができたのはいいことだと思う（「ドコモ、ahamoでも店頭サポート提供　ただし有償 – Engadget 日本版」）。

日本の労働生産性が非常に低い原因の一つが、学ぶ気のない、やってもらって当たり前気分の阿呆に合わせすぎていることだと思うんだ。対価を取ればいいんだけれど、無料でサポートするから、一部のテイカーのためにみんなが疲弊しているのだと思う。

そういったサポートを必要としない人たちは多く、いわばMVNOの格安SIMなどは彼ら向けのサービスだったわけだが、楽天Unlimitedもそういうまともなリテラシーを持った人向けに訴求していた面があった。

なので、ahamoの登場は楽天に逆風……と言えるが、そこで楽天は1GBまで無料、という恐るべきプランを打ち出し、このインパクトは非常に強いものとなった（「楽天モバイル、20GBまで月1980円の段階制プラン「1GBまで無料」 – Engadget 日本版」）。

いや実際、このプランに一番驚いたのは、IIJやnuroを始めとするMVNO勢力だよなぁ。格安SIMの愛好者が全部取られてもおかしくなさそうなエゲツないプラン……。

なので、IIJやnuroは、1GB以上2,3GBまでならこっちのほうがお得、という微妙な間隙をつくような形になっている。

ちなみに僕はBiglobe。なぜかというと、4月から半年間は480円/月のキャンペーンをやっているからだ。それが終われば1,280円/月になる。もとより加入時のキャッシュバックが大きかったから入ったに過ぎないのだし、半年後にはおさらばよ（MVNO利用者はこういう人が多いだろう）。

楽天Unlimitedを使うべく

さて、問題は半年後、Biglobe後どこにするかだ。筆頭候補はnuroモバイルだったのだが、ギリギリ楽天Unlimitedも一年間無料キャンペーンの申し込みに間に合いそうだったので、入ってみた。

僕が加入したのは本当にギリギリの4/7。この時点では、まだ楽天UnlimitedはiPhoneに正式対応していなかったし、ましてiPhone 8となればかなり特殊な対応をする必要があった。正直SIMのためにそこまでやるのはバカバカしかったので、iPhoneで無理にUnlimitedを使う気もなかった。まぁ楽天回線の実力もわからないので、メイン回線にするのは少し怖かったし。

ということで、せっかくだから楽天Bigでも買ってみるかと思ったのだ。楽天Bigという名前はどう考えてもダサいが、まぁそれが楽天らしいのかもしれない。中身はZTEだと言われている（「Rakuten BIGのベース？中国で品切れ続く『世界初スマホ』ZTE AXON 20 5G（山根博士） – Engadget 日本版」)。型番のZR01はZTE、Rakutenだったりするんだろうか。

Rakuten Handという選択肢もないではなかったが、iPhone 8を持っている自分が、それを使う姿を想像できなかった。持ちやすさという点では、今やスモールデバイスに分類されるだろうiPhone 8で十分だからだ。その点、楽天Bigは6.9インチという巨大なディスプレイを持っている。したがって、当然持ちづらいことは予想できたが、その分ネットは見やすいはず。iPhone 8とは明らかに違う特性を持っているので、使う姿がまだ想像できた。

ということで、楽天Bigを購入したわけだ。

楽天Bigの使い勝手

さて、楽天Bigを購入して一ヶ月が経過しようとしている。目論見どおり、iPhone 8とはまったく違う特徴を備えていることから、メインは相変わらずiPhone 8ではあるものの、サブスマホとしてけっこう活躍している。

以下に所感を書く。

デカイ

とにかくデカイ。デカすぎる。しかも重い。ずっしりとした質量を感じる。コイツを持って読書でもしたら、ちょっとした筋トレになるかもしれない。

が、よくよく考えてみるまでもなく本のほうが重い。つまり、楽天Bigは見た目以上の重量感がある、ということだ。あくまで重量感であるので、冷静に考えればそれほどの重さというわけではない……はずなんだが……重い。

そして持ちづらい。ポケットにも入らない。いや、入らないことはないが、あまり入れたくはない。普段はカバンに入れている。これは男性に多いと思うが、ポケット族にとってはマイナスかもしれない。

画面上部に手が届かないが、考えられたアプリもある

そして手が届かない。Twitterでツイートする時に指がつる。

が、iPhoneやGalaxyも長細い形態を採用しているからか（というよりZTEはそれの真似だろうが）、案外そのへんについて考えられているアプリもある。たとえばブラウザアプリのFirefoxなどは、画面下部で検索からタブの選択など、多くの操作できるようになっていた。素晴らしい。

逆に、古臭いアプリなどは画面下部に真っ黒な余白を残してくれていたりもする。悲しい。

ネットはさすがに快適

前述の「重い」ということを除けば、ネットはiPhone 8 よりも随分と快適。iPhone 8だと、冗談抜きで画面の半分くらいは広告やタブバーなどに占領されてしまうのがつらかったが、楽天Bigなら全然平気。特にその長細さ故に、広告は横軸で大きさを規定され、肝心の縦軸の侵食具合が減ったのは嬉しい。

バッテリーの持ちはテザリングで半日置いといても半分くらいだった

バッテリーについてだが、今の所困っていない……ものの、メインスマホとして使っていないために、まだまだ評価できない。

ただ、テザリングで半日ほどiPhoneに繋げていても、50%にもなっていなかったことから、ヘタなモバイルルータを使うよりもよほど良いものであることが示唆される。

指紋認証は素晴らしい！

全面ディスプレイだが、指紋認証が使える。しかも、背面のなんか押しづらいところにあるのではなく、画面下部の、iPhone 8以下でいうところのホームボタンに位置するところにあって、これがめちゃくちゃ使いやすい。正直一番感動したのはこれかもしれない。

スペックでは圧倒しているのに！Androidの悲哀、ゲーム

スマホゲーをよくしている人にとっては、やはりAndroidであることの悲哀を感じずにはいられないかもしれない。Antutuのベンチなどを見ると、楽天Bigが圧倒しているはずなのだが、実際に動かしてみるとiPhone 8のほうがヌルヌル動く。2021年になっても変わらないのだなぁ。いや、楽天Bigはたしか2018年のデバイスだけれど。まぁでも、今も変わらないんだろうな。

まぁ、僕は大したゲームをしないので、まぁ良いんだが。ただ、その長細さが災いして、プレイしづらいゲームはけっこうあるかもしれない。

クラウドのおかげで移行がかんたん

これは別に楽天Bigの特徴ではないが、嬉しかったのは多くのサービスで移行がすんなりいったことだ。SpotifyやAmazon Kindle, Audibleなど、サービスの移行が非常にかんたんであった。いや、共有といったほうがいいかな。iOS、Android間の移行は極めて楽になっている。

特に感動したのはQRコード決済である。本当に楽。スペックではSuicaが圧倒しているかもしれないが、トータルのユーザーエクスペリエンスはQRコード決済が圧倒的である。交通決済でもQRコードの試験が実施されているし、やがてSuicaはQRコード決済に敗北するのではなかろうか。スペックはたしかに良いが、運用がたいへん過ぎる。導入コストも大きい。Suicaは良くも悪くも日本的技術革新の極みという感じがする。

半年かけて見定めるよ

ということで、与太話も含めて随分と長くなってしまったが、少なくともサブスマホとしては思っていたより活躍してくれているし、楽天Bigだけ持って出歩くこともけっこうある。

今後、半年ほどかけて、iPhone 8と比較し、自分に合うのはどちらなのか、見極めていくつもりだ。

LPIC303合格体験記。勉強はPing-tオンリー

2021-04-18T01:34:03+09:00

クラウド全盛の世の中、Linuxを業務で使うことはあまりない、というより使わないようにしているという方が正しいですが、LPIC Level 2の有効期限が切れかかっていて、まぁせっかくなのでLPICの上位資格の一つでも取っておこうかと、303を受験しました。セキュリティ系なら、得られた知見も多少活かせるところがあるかもしれないし。

勉強期間は半年、合計30時間ほど、勉強方法は漢のPing-tオンリーです。

スコアと難易度

まずスコアですが、580でした（なお範囲は200 - 800）。

分類	正答率
Cryptography	64%
Host Security	75%
Access Control	90%
Network Security	70%

正答率は44/60 = 73%。問題を解き終わった後、各問題について自信のほどで0-5点にして計算してみたところ、だいたい7割といったところでしたから、自己採点どおりの結果なのかなと思います。

これまでの試験はだいたい9割くらいの自信があったので（過去のやつ→https://hack-le.com/category/certificate/lpic/）、やはりレベル3にもなると難しくなるなーという感触は正直ありました。最初の1問目がいきなりわからなかったのでだいぶ焦った。

この後で詳細を書きますが、Ping-tだけで勉強してきたのですけれど、「あっ、この問題、Ping-tで見たことない！」みたい逆進研ゼミ現象けっこうありました。

まぁでも、合格ラインには到達できるということですね。

勉強方法、勉強時間

前述したとおり、勉強方法はPing-tオンリーです。

https://ping-t.com/

Ping-tしか使っていません。今までのLPICの試験もすべてPing-t1本でやってきました。もうPing-tの回し者かってくらいPing-t推しです。

勉強時間もこれまでとたいして変わりません。今回余計な語呂合わせ戦法なども使ったので無駄に30時間くらいかかったような気がしますが、多分真面目にやると20-30時間くらいなのはどの試験も同じだと思います。まぁやり方にもよると思いますが。

自分の場合は、Web問題集を2週して、コマ問をすべて解いて、あとはひたすら模擬試験です。僕はコマ問大好きですけど、しなくていいんじゃないってコメントもいただいたこともあります。読んで覚えるタイプの人ならそうかもですね。でも僕は書いて覚えるタイプなので、コマ問で一気に記憶が定着する感があります。あとコマンドのオプションについては語呂合わせ使ってアホみたいに覚えました（記事書くかも）。結果、模擬試験については10分程度で90%以上安定、という状態に。

それでもスコアは580。うーん。Ping-tで全然やってないところがけっこう出ました。auditctlはエライ突っ込んだ問題出されて知るかって思った記憶が。Ping-tに問題投稿コーナーとかあったら送ってもよかったんですけど。いやさすがに大ぴらにやったらダメか。一応守秘義務みたいなのあるし。なんだよそれって思うけど。やっぱりああいうの、覆面して問題調査しに行ってるんですかねー。

ということで、Ping-tだけだと解けない問題はたしかにけっこうあるんですけれど、合格ラインには到達できる、できた、という感じです。なので、謎の教材に大金払う必要ないです。Ping-tを信じなさい。

あ、DNSSECのところは、正直Ping-tの解説だとよくわからなかったのですが、以下の資料の19ページをよく読んで理解できました。良い資料ですね。ありがとうございます。

https://www.nic.ad.jp/ja/materials/iw/2012/proceedings/t9/t9-Funato.pdf

DNSSECのところ、ZSKだのKSKだの頭こんがらがってくるので、是非参考にしてください。

勉強内容は役に立ちそうか

さて、LPIC303の勉強は果たして役に立つのだろうか、という点ですが。

どうなんですかね。自分の場合、LPIC Level2の有効期限が切れそうで、なんだかもったいなくて受けたという感じで、別に必要があったわけではありませんでした。LPIC Level 2も、果たして資格を取得した意味があったのかと言われるとよくわからない。あったのだろうか。

一生使うことがないだろうコマンドのオプションや設定ファイルのパラメータを覚えるのは控えめに言って虚無でした。というか、たとえ使うにしてもググるよそれ、って思う。問題にしやすいのはわかるんだけれど。まぁそれはLevel 1でrpmやaptのオプション死ぬほど覚えさせられた時にも思いましたが。二度と使わねーわ。manするわ。

ただまぁ、通り一遍のシステムについては知ることができたのは良かったと思います。RADIUSとか知らなかったけれど、会社でしれっと会話に出てきた時には100年前から知ってましたみたいな顔して会話してました。この時は「あっ、その言葉、Ping-tでやったやつだ！」と進研ゼミ現象が起きました。

あー、あとX.509証明書のフィールドを死ぬほど覚えさせられたので、抵抗感はだいぶ薄れたと思います。証明書の話はWebでもIoTでも何かと出てきますからね。DNSSECの仕組みを頑張って理解できたのもよかった。

まぁ正直この時間使ってAWSの資格でも取ったほうが直接の役にはたったと思うし、今業務で差し迫って必要でないのに取る意味ある？と言われたら微妙だと思うんですが、Level 2の資格が切れそうなら、取得してもいいんじゃないですかね。そのうちに役立つ日が来るかも知れないし。受験代もいつの間にか安くなっていたし。会社から補助金出るならいいですが、自腹で受ける人もいるでしょう。僕も零細で働いていた時には必死だったので、自腹で受けていました。。。あの頃こそ補助してほしかったなぁ……当時僕の年収は200万でした。まぁ世の中ままならないものです。

Linuxのサーバーをゴリゴリ使うことは多分ない、というかそれをしなくていいように立ち回っているというほうが正しいですが（サーバレス万歳）、まぁでも、だからこそ資格取得くらいはしてみてもいいかもしれないですね。有効期限が切れそうになったら、今度は304でも取ろうかしら。仮想化も通り一遍の知識はつけておいてもまぁいいかなと思えますし。

まぁ、たまには試験を受けるのも、程よい緊張があってよいですね。AWSの試験も受けようかな。

（参考）LPIC303受かったよ | QnQ

AWS Lambdaのロギングを考える

2021-01-26T03:25:25+09:00

ロギングをどうするかで困っていた。AWS Lambdaでは、プリント出力したものがCloudWatchに保存されてとても便利なのだが、考えもなしにとりあえずポンポン入れていたところ、確かに情報はあるので追えないことはないんだが、地道に時間にあたりをつけて検索するなど、非常に泥臭い作業が要求され、なにかとつらかった。

APIのコール回数など集計したいという要件も出てきて、重い腰をあげてロギングについて頑張って考えました、という話。

ユースケースを考える

AWS Lambdaで、何も考えずにとにかく必要そうなのをログ出力しているが、フォーマットも何も整っていないため、ほしい情報を探し当てるのも一苦労だ。

ログをjson形式に構造化させてやると、CloudWatch Insightsでクエリを投げて検索・集計することができる。ということで、ユースケースに対応できるように、ログ出力について考えたい。

ユースケースとして以下を考慮。

ERRORだけ抜き出す
ユーザー別に叩いたAPIについて集計する
詳細な検索ができるように、ハンドラに渡された情報は全部取っておく

前提条件として、node.jsを使っていたりPythonを使っていたりする。そのため、特定の言語のライブラリに依存した解決はあまり好ましくない。

結果

以上の条件を考えて色々調査し、必要なことを考えた結果、以下のような感じになった。

{
  "msg": string // フィルタリングできるような固有のメッセージ
  "funcName": string // 実行関数
  "dateTime": string // ログ出力した時刻 RFC3339 に則る(jsならDateオブジェクトをconsole出力すればよい)
  "level": INFO | WARN | ERROR,
  "event": object // Lambda関数のeventパラメータをそのまま
  "input": object // 必要なやつ
}

levelでログレベルを設定。inputとmsgでフィルタリング、集計を容易に。困ったらeventとfuncNameで頑張って追えるようにしておいた。また、独自フォーマットなので言語やライブラリに依存しない。

このフォーマットはほとんど「AWS Lambda Logging: An Intro How-To and Best Practices | Scalyr」を参考にしています。

以下のような使い方を想定（node.js）。

function logging(msg, funcName, event, level, inputValues) {
  const logMsg = {
    msg: msg,
    funcName: funcName,
    dateTime: new Date(),
    level: level,
    event: event,
    input: inputValues
  }
  if (level === "INFO") {
    console.info(JSON.stringify(logMsg))
  } else if (level === "WARN") {
    console.warn(JSON.stringify(logMsg))
  } else if (level === "ERROR") {
    console.error(JSON.stringify(logMsg))
  } else {
    console.log(JSON.stringify(logMsg))
  }
}

exports.handler = async (event, context, callback) => {
  logging("CallApi", "functions/users/app.handler", event, "INFO", {userId: "testUser"});
}

で、CloudWatch Insightsを使うとたとえば以下のようなクエリを投げて集計できるわけだ。

filter msg like /CallApi/
| stats count(input.userId) by input.userId

運用を通じてブラッシュアップしていきたい。

参考リンク

この記事は、開発中のWebサービスQnQで草稿を作りました。よかったら見ていってね（宣伝）。

Lambda関数のロギング設計を考える | QnQ

その他、参考にさせていただいた記事です。ありがとうございました。

QnQ開発日誌 Firebasde匿名認証機能で誰でも気兼ねなく見られるようにした

2020-12-15T20:31:36+09:00

https://qnqtree.com/

友人と開発中のFirebaseなWebサービス、QnQの開発日誌です。質問に質問で返す、Q&AならぬQ&Qサービス。どんなサービスかの詳細は「質問に質問で返されるドM向けQ&Qサービス、QnQを公開・開発中です – 或る阿呆の記」。

作って公開したのはいいものの、覚悟していたけれどやっぱり開店休業状態が続き、周囲の人に使ってもらって意見を伺いながら、どうしたらユーザー増えるかなーと試行錯誤中です。で、今まではGoogleまたはTwitterでログインしないと何も見えない状態だったんですが、今回はそういったことをせずに中身を見られる匿名ログインを導入しました。

本記事では、導入の背景と、すったもんだをつらつらと。僕らの週末と引き換えに作られました。

Firebase 匿名認証

匿名ログインというのは、Firebase Authenticationで言うところの「匿名認証」の機能を導入した、ということになります。「JavaScript を使用して Firebase 匿名認証を行う」この機能です。

Firebase Authenticationを用いると、GoogleやTwitterなどのIDプロバイダを利用して、Webサービスの認証に使えるわけですが、そういったIDプロバイダを利用しない認証、ですね。

そりゃただのログインしてないユーザーじゃないのか、という感じですが、これを使うとセキュリティルールで保護しているFirestoreにもアクセスできるようになります。

導入の背景

なぜこの機能を追加したか？

「知らないサービスの中が見えないと怖い」「知らないサービスにログインするのに抵抗がある」と、複数人から意見を頂戴したからです。あれですね、中の見えない初めてのお店怖い、みたいな感じですね。オンラインでは探検家の僕も、オフラインではそんな感じなのでわかります。

実際、誰にどこまで見せるかは、度々議論になっていました。ですが、心理的安全性を考えて、インターネットに完全公開するのは気が引けていました。とはいえ、GoogleやTwitterのアカウントを持っていれば誰でもログインして即見られる以上、ログインしていないユーザーに見せないのは、機能的には意味のないことです。扉に鍵をかけているわけじゃない。

で、まぁ実際に「怖い」という意見をもらったこと（それもリアル知人）で、意味のない規制だから取っ払おうか、ということになりました。

公開後、覚悟はしていたものの、ほとんど使ってもらえないので、これで少しでもユーザーにとって親しみやすくなればという感じです。本来であれば、実質的には変わらないとはいえ、見た目上公開範囲が変わっているわけですから、既存ユーザーの支持なく勝手にできない変更ことだと思います。このよくわからんサービスを使ってくれる人には感謝しかない。ただその既存ユーザーがマジで少なくてですね…。まぁ、実際のところ困る人もいないだろうなぁ、と。

という、悲しくも切実な裏事情でした。

導入のすったもんだ Bug & Bug & Bug

さて、今回は認証・認可の観点から言えば劇的かつ根本的な変化と言えます。なので、大幅な変更を覚悟していた……のですが、匿名認証機能自体はすぐに使うことができて、ちょっといじった感じだとうまく動いてそうだったので、さっと公開したところ、公開後次々とひどいバグが見つかって、速攻で差し戻したという経緯があります。やはり認証周りの変更はエグかった。

今まで適当に誤魔化していたところが、匿名ユーザーという本来想定していなかったユーザーが出てきたことによって、次々とエラーを引き起こしました。またDBが汚れたことによって、それがさらに想定しないエラーに繋がり、エラーがエラーを呼ぶ地獄のエラーチェイン。エラーがとどまるところを知らない。

コーディング規約もなく各々勝手に開発していたため、関数の粒度や返り値のポリシーのなさで苦しみました。追いついていないドキュメントに嵌められました。適当なnullチェックやエラー処理に泣きました。適当なログ出力故に、エラーの該当箇所を血眼になって探しました。ユニットテストもないので入出力はデグレの嵐でした。

自業自得の地獄に悶えゲロ吐きつつ、一個一個バグを潰していき、気がつくとほぼすべてのファイルについて手を入れた、開発以来の一大リファクタリングになっていました。特にルーティング周り、めっちゃ手を入れることになりました。そして週末は終わっていました。

振り返ってみると、むしろ最初よくあれで公開したなと思ったんですが、油断や慣れ、焦りがあったなぁと思います。少しでも早く機能追加しなきゃ、今までいけたしいけるっしょ、みたいな。僕もコードレビューしたんですが、全然的を射ていないしょうもない指摘（文言変えたらいんじゃね、レベル）だけしてOKしたんですが、本当に反省して、しばらく凹んでいました。

あとはこの週末と引き換えに出来た機能が、どれくらい効果あるかを見ていきたいと思います。

ところで、当然のように、Firebase Authenticationのダッシュボード見ると匿名ユーザーがめっちゃ増えているんですが、これ放置してていいのかな。でも定期的にスクリプト動かして削除はどう考えてもおかしい気がするし。

今後の開発

QnQは大きな課題を3つ抱えています。

人が来ない人が来ても続かないバグが多い

今回の措置は、人を少しでも増やすための施策であり、また大規模なリファクタリングを伴うことで、安定性も多少向上しました。

で、次の大きな更新としては、ユーザーへの通知機能があるかな、と思います。匿名ではないログインをしてもらえれば、Eメールを使ったアクションなんかが技術的にはできるわけですが、しかしこれって、実際どれくらいなら許されるんだろう？などと疑問に思って調べつつ、まぁでもだいたいどのWebサービスでもやられているので、ある程度は良いのではないかと。ただ個人情報なので、取り扱い厳重注意で、Authenticationの外には出したくないですが……。

というか、今回みたいな大きな変更があったら、そもそも通知して然るべきの気がする。リリースノートまで作るかどうかは微妙ですが。Webサービスのリリースノートとか見たことないな。

また、そもそもサービスの敷居が高いという意見もかなり頂戴していて、もう少し親しみのありそうな機能追加（これも大きな改変になるかと）も予定しています。まぁ年内は無理だろうなぁ。

あとユニットテスト作ります……はい……。

nginx + certbot + Let's Encrypt で TLSv1.0やTLSv1.1が無効化できない時

2020-12-12T02:30:54+09:00

TLSv1.0やTLSv1.1は既知の脆弱性があるために、各種ブラウザでも対応が打ち切られています（参考「ついにTLS 1.0/1.1の無効化が決定！影響や確認・対応方法とは？ | さくらのSSL」）。なので、もうサーバー側で対応する理由はないわけで、無効化する必要があるのですが、nginxの設定をなんぼいじっても無効化できないと思ったら、certbotでLet's Encrypt使っている場合そっちの対応もあって半日ハマっていました。

環境

AWS EC2
Ubuntu 18.04
nginx 1.18.0
certbot 0.31.0
- Let's Encrypt によるドメイン証明

やりたいこと

TLSv1.0とTLSv1.1が使えるせいで、ssllabs.com のテストでB評価と言われる。実際、ほとんどのブラウザで無効化されるし、もはやサポートする理由がないので切りたい。

確認の仕方

作業に入る前に、先に確認の仕方を見ておく。

opensslコマンド

簡易的に見るならば、以下のコマンドを実行するとよい。

TLS1.1
openssl s_client -connect example.com:443 -no_tls1_2
TLS1.2
openssl s_client -connect example.com:443 -no_tls1_2

それぞれ実行するとずらずら表示される。対応していなければ SSL handshake has read 7 bytes and written 0 bytes というようなバイト表示がされる。ので、-no_tls1_2オプションをつけた時にそうなればよい。

ssllabs.comでテスト受ける

時間がかかるので最初と最後だけ受ければいいと思うが、SSL Server Test (Powered by Qualys SSL Labs) でテストを受けて確認する。TLSv1.0、v1.1をサポートしていると、Protocol Support の項目で怒られる。

よければこんな感じ。

Testの結果

やること

nginxの設定ファイルと、certbotでLet's Encrypt使っている場合はそちらのファイルも見る。むしろそっちだけでもいい。

nginx.confの設定変更

nginxの設定ファイルの基本については過去記事「nginxの設定ファイル nginx.conf の読み方超入門 – 或る阿呆の記」を参照。

httpディレクティブ内にある、ssl_protocolsの項目を以下のように記述する。

ssl_protocols TLSv1.2;

もしかしたらserverディレクティブに記述しているかもしれないが、その場合は /etc/nginx/sites-available/* の設定ファイルの記述を確認する。

TLSv1.3も対応しているならそれも書いておく。ただしTLSv1.3対応については本記事ではスコープ外。

そして文法チェックしてOKだったら再起動。

sudo nginx -t
sudo systemctl restart nginx.service

で、だいたいどこのサイトもこれでOK！とあるのだが、実際にやってみると相変わらずTLSv1.0とTLSv1.1が一向に無効化されなかった。他の設定も色々試したが駄目。

certbot + Let's Encryptの場合

結局たどり着いたのはここ「How to remove TLSv1.0 / 1.1 and enable TLS 1.3 in Nginx – libre-software.net」で、certbot + Let's Encryptで証明書発行している場合は、こちらの設定があるのだという。

具体的には、/etc/letsencrypt/options-ssl-nginx.conf について、ssl_protocolsを確認する。TLSv1.1とかの記述があったらそれが原因なので、removeしておく。

ssl_protocols TLSv1.2;

これでnginxを再起動して、確認したらいけるはず。

むしろこちらの設定だけで、nginxの設定はしなくてもよかった。このサイトのサーバーがそうで、nginxの設定ファイル見たらTLSv1.0、TLSv1.1切ってないのに実際には使えなくて、変だなーと思っていたら、こっちの設定で切っていたという。

まぁでも、nginxの設定もちゃんとしておくにこしたことはないね。

参考

ありがとうございました！

How to remove TLSv1.0 / 1.1 and enable TLS 1.3 in Nginx – libre-software.net
- ここのおかげ

Disable TLS 1.0 in NGINX - Server Fault
- それらしい議論がされているのだが、結局関係があったのかなかったのかよくわからずじまい
  - 日本語に自動翻訳しただけのゴミサイトが引っかかるのほんとどうにかしてほしい
nginxの設定で暗号化通信をTLS1.2のみ許可する - Qiita
- コマンド参考にしました