Lycolog

別の端末に持っていきたいときに使える

確認環境

手順

1. ユーザー証明書の管理を開く
2. 信頼されたルート証明機関＞証明書
3. mkcertで始まる証明書を探す
4. 右クリック＞すべてのタスク＞エクスポート
5. DER encoded binary X.509 (.CER)
6. 適当なファイル名を付けてエクスポート

主に狭い賃貸で一人暮らしをするときに個人的に便利だと思ったグッズ集

三角コーナーいらず

ダイセルの三角コーナーいらずは文字通り三角コーナーを不要にしてくる便利グッズだ。

三角コーナーがあると三角コーナー自体の掃除が必要になったり、接地面の掃除が必要になったり、結構手間だし、これをさぼっているとウジ虫が湧くことがあり、非常に面倒だ。

しかし三角コーナーいらずであれば、接地面が存在しないため、このようなことは起きない。また袋が小さいため底の浅いシンクでも使えるのがよい。更にシンクの壁や、上側とかにも置けるため設置場所をあまり選ばないのもいい。これは引っ越しをよくする場合に重宝するポイントだろう。捨てる時に手を汚さないようにするために袋に耳がついてるのもありがたい。袋自体に脱臭・抗菌加工があるためハエが寄り付きづらいのもポイントだ。

市販の買い物袋をぶら下げたりするタイプもあるが、そちらだと袋が大きすぎたり、水切りができないという欠点があるが、これであれば専用品であるために水切りができ、袋も小さいというメリットがある。実際これに変えてから三角コーナーにウジ虫が湧くことはほぼなくなった。

但し放置していればウジは沸くので、適宜廃棄することが肝要だ。

ニトリのダイキャストフライパン

ある日、私はフライパンを使っていて取っ手と鍋本体を繋ぐリベット（釘）に汚れが溜まって困っていた、これを解決してリベットがないフライパンを探したが、大抵高かったり重かったりしてイマイチだった。そこで見つけたのがニトリのダイキャストフライパン、KARUFURA3だ。

見ての通り取っ手のつなぎ目にリベットがなく、ニトリなので安い。20cmタイプで360g（実測値）と重量も軽い。買って3年ほど使っているがコーティングが剝がれることもなく今でも特に問題が出ていない。

三年位前だろうか、まだコロナが猛威を振るっていたころの話だ。私は自転車で街を走っていて一つの街頭広告を見かけた。『手洗いに「解除」はありません。』という文字が書かれ、柔らかなテイストで家族のイラストが描かれたシンプルなものだった。広告主は牛乳石鹸で、その時私は「確かにそれはそうだ。しかし石鹸なんて使わなくなったな」と思っていた。この広告は今でも同じ場所に掲示され続けており、通る度に眺めては物思いにふけっていた。

そしてつい先日ホームセンターに行った時のことだ、レジの前で牛乳石鹸の特売がされていた。「ふーん、石鹸かぁ…」と思い、買うか悩んだがレジに並んでいたので判断しきれず、その時は買わずにいた。

翌日である今日になり、石鹸を使ってみるのも悪くないのではないか？と思い、早速買ってみることにした。理由としては石鹸の方が安く済みそうだと思ったからだ。というわけで牛乳石鹸の赤箱と石鹸皿を買ってきた。石鹸皿はコーナンにあったアスベル エミール　石けん皿　ホワイトだ。汁受けがついているので石鹸のぬめりをキャッチできるのがいい。全く今風ではない古臭い作りだが、これでいいのだ。

私は長らくボディーソープを使っていた。何故なら石鹸は使い辛く、古臭いと思っていたからだ。ボディーソープは使いやすくモダンだと思っていたので使っていた。昔の私は新しいものが好きで、新しいものにすぐ飛びつく癖があった。よく近所の人からも「君は進みすぎている」と言われたものだ。

ボディーソープを使うときは十分に泡立たせるために二回ほどプッシュすることが多く消費量が多いのが悩みだった。また替えのリフィルも場所を取るし、ごみが多い。取り換え時に抜いたポンプから中身が垂れてきて汚れるのも好きでなかった。

しかしそれらの課題は石鹸なら解決できるのではないかと思ったのだ。石鹸はコンパクトで場所を取らないし、それだけにごみも少ない。何なら私は今、新聞を購読していて紙ごみはリサイクルに出せるので、環境保全の意味でもよい。ボディーソープのリフィルもリサイクル出来るはずだが、する気が起きない。しかもなくなった時の詰め替え作業も不要だ。ついでに言うと軽い。記憶が確かなら石鹸は中々減らないので長持ちするので節約になるし、買いに行く手間が省けるのはいいことだ。また、ボディーソープと違って残量がわかりやすいのも利点だろう。ボディーソープはある日突然出なくなって困ることがあるが、石鹸は小さくなったら買いに行けばいいだけだ。常にストックしておく必要はないし、ストックしておくにしてもボディーソープのリフィル一本分の面積に10個くらい置けるのも魅力といえる。

実際に使ってみた感じも手に取って何度か揉めば十分に泡立ったので、ポンプを押して更に泡立てるという工程がなくなり楽になった気がする。何より石鹸をこねくり回すのは新鮮で楽しい。しかも顔まで行けるので、フェイスソープが要らなくなった。

牛乳石鹸を買うときは色は青と赤で少し迷ったのだが、乾燥肌が辛いなど最近肌に関するトラブルに絶えないので赤にすることにした。子供のころは赤い牛乳石鹸といえば高級品というイメージだったし、実際赤の方が高いのだが、ボディーソープと比べたら些細な価格なのでどうでもいい話だ。

今まで使っていたボディーソープだとリフィルが400円程度するが、牛乳石鹸の赤い奴は3つ入りで300円程度、1個辺り100円くらいである。どう考えてもこちらの方が安い。しかも牛乳石鹸は大阪の会社なので、地産地消的な意味合いでもよい。

「SEA BREEZE ボディシャンプー クール＆デオドラント」という非常に長く覚えきれないので買い替えに地味に難儀する商品名から、「牛乳石鹸の赤箱」という非常に明快な商品になったのも買い替え時にありがたい。SEA BREEZEはシリーズ商品が結構あり、毎回これで合ってたっけ…？となりがちなのがよくない。いや、もう色で覚えたが。他にも売っている店があまり多くないのも悩みだった。牛乳石鹸なら大抵の店にあるだろう。

因みに牛乳石鹸の箱にはSOAPと書かれており、固形だから石鹸、液体だからソープという話ではないらしい。そういえば昔は液体のやつをボディーシャンプーとか言ってた気がしなくもない。また、赤箱は関西向け、青箱は関東向けだったらしい。近所で赤箱の方が青箱より売れてそうだったのはそこにも理由があるのかもしれない。

しかし変革シリーズも第五弾となった。思えばWordPressからadiaryの乗り換えも変革シリーズにしてしまってよかった気がする。

• デスクトップにアイコンを表示させる
• 日本語のフォルダ名を英語化する

デスクトップにアイコンを表示させる

何故か標準ではアイコンが出てこないが、これをすることでデスクトップでファイル操作ができるようになる

1. アクティビティを開き、「ex」と打ち、拡張機能を開く
   

   

2. Desktop Icons NG (DING)をONにする
   

   

日本語のフォルダ名を英語化する

/home/hoge/デスクトップみたいなパスを/home/hoge/desktopに変える方法

以下のコマンドを流す。

env LANGUAGE=C LC_MESSAGES=C xdg-user-dirs-gtk-update

Node.jsとGoogle Chrome, Microsoft Edgeを用いて、try-catchとif文でエラー処理にかかる時間がどのくらい違うのかを調べた。

• 計測手法
• 計測結果
• 計測に使用したCPU
  • Intel Core i7 13700端末
    • Node.js v16.20.2
    • Node.js v18.19.1
    • Node.js v20.11.1
    • Microsoft Edge 121.0.2277.128
    • Google Chrome 122.0.6261.58
  • Intel Core i7 1265U端末
    • Node.js v16.20.2
    • Node.js v18.19.1
    • Node.js v20.11.1
    • Microsoft Edge 121.0.2277.128
    • Google Chrome 122.0.6261.58
  • AMD Ryzen 5 5600G端末
    • Node.js v16.20.2
    • Node.js v18.19.1
    • Node.js v20.11.1
    • Microsoft Edge 121.0.2277.128
    • Google Chrome 122.0.6261.57
• 全体サマリ表
• あとがき
• 参考

計測手法

次の4パターンを100万回実行した結果を記載している。

1. Result型としてエラーオブジェクトをreturnし、if文で判定する方式
2. Result型としてエラーインスタンスをreturnし、if文で判定する方式
3. エラーオブジェクトをthrowし、try-catchで判定する方式
4. エラーインスタンスをthrowし、try-catchで判定する方式

確認に使用したコード：https://gist.github.com/Lycolia/304bc9e825e821c2d582f3ef9f700817

計測結果

CPUによって処理速度がかなり変動するが、いずれの環境でも処理速度の速さは以下の通り。

1. Result型としてエラーオブジェクトをreturnし、if文で判定する方式
2. エラーオブジェクトをthrowし、try-catchで判定する方式
3. Result型としてエラーインスタンスをreturnし、if文で判定する方式
4. エラーインスタンスをthrowし、try-catchで判定する方式

計測に使用したCPU

Intel Core i7 13700端末

16C24T, 5.20GHz, L2 24.00MB, L3 30.00MB。ミドルタワーPC。

Node.js v16.20.2

処理環境

処理結果

Node.js v18.19.1

処理環境

処理結果

Node.js v20.11.1

処理環境

処理結果

Microsoft Edge 121.0.2277.128

処理環境

処理結果

Google Chrome 122.0.6261.58

処理環境

処理結果

Intel Core i7 1265U端末

10C12T, 4.80GHz, L2 6.50MB, L3 12.00MB。ノートPC。

Node.js v16.20.2

処理環境

処理結果

Node.js v18.19.1

処理環境

処理結果

Node.js v20.11.1

処理環境

処理結果

Microsoft Edge 121.0.2277.128

処理環境

処理結果

Google Chrome 122.0.6261.58

処理環境

処理結果

AMD Ryzen 5 5600G端末

6C12T, 3.90GHz, L2 3.00MB, L3 16.00MB。ミニタワーPC。

この端末はOSがUbuntuであるため、これまでのWindows環境との単純比較はできない。

Node.js v16.20.2

処理環境

処理結果

Node.js v18.19.1

処理環境

処理結果

Node.js v20.11.1

処理環境

処理結果

Microsoft Edge 121.0.2277.128

処理環境

処理結果

Google Chrome 122.0.6261.57

これだけバージョンが合わなかった。

処理環境

処理結果

全体サマリ表

凡例

1. Result型としてエラーオブジェクトをreturnし、if文で判定する方式
2. Result型としてエラーインスタンスをreturnし、if文で判定する方式
3. エラーオブジェクトをthrowし、try-catchで判定する方式
4. エラーインスタンスをthrowし、try-catchで判定する方式

CPUによってかなり差が出ているが、Intel CPUの13700と1265Uを比較した場合、例外を作らない1, 3のケースでは処理に大きな差がないが、例外を作る2, 4のケースでは有意な差が認められるので、モバイル向けとデスクトップ向けでCPUの処理効率に差があることがわかる。

AMD CPUと比較した場合、Node.js環境で例外を作らないケースではIntel CPUに大きく引けを取るが、ブラウザ上でのそれではパフォーマンスは高い。また例外を作るケースでもNode.js・ブラウザ共にIntel CPUと比較した場合のパフォーマンスが比較的よいという、面白い結果になっている。但しOSが違うことの影響もあるため、単純比較はできないが…。

あとがき

ひとまずtry-catchを使うと遅くなるということが確かめられたので良かったし、環境によって劇的遅くなるケースがあるというのは思わない収穫だった。

これを試そうと思った切欠はtry-catchが乱用されているコードを見てパフォーマンス劣化に繋がっているのではないかという疑問を抱いたからだ。try-catchでパフォーマンスの劣化が起きることは知識としても経験としても知っていたのだが、ちゃんとレポートしたことがなかったので今回まとめてみた。

try-catchの利用によりパフォーマンスの劣化が起きるというのは、古い時代にあった開発のお作法を知っている人であれば、それなりに常識だとは思うが、最近は知られていないか、知られていても意識していないことが少なくないと思われるので、今回記事にしてみた感じだ。

100万回の実行なので細かい話になるとは思うがパフォーマンスチューニングは細かいことの積み重ねでもあるので、むやみやたらに例外を使わないことは重要だと思う。そもそも例外は制御しづらいので、可能な限りif文で処理を書くことが望ましいだろう。

処理が遅延する原因としては二つあると考えていて、一つは例外生成時に顕著であることからスタックトレースの生成を初めとしたエラーオブジェクトの生成に時間がかかっているのと、もう一つはcatchでも遅延が出ることから、コールスタックから最寄りのcatchを辿るのに時間を取られていると思われる。今回の検証では特に出してないが、以前確認した時の記憶が確かであれば、catchに入らない限り、tryだけで顕著に処理が遅延することはなかったと思う。

あと、どうでもいいことだがconsole.log()で結果を出したときにEdgeだけObjectのKeyの順序が他と違ったので転記しているときに微妙に不便だった。何回やっても同じだったので恐らくEdgeだけキーをソートするアルゴリズムが違うのだと思う。まぁObjectとかHashとかMapとかDictionaryみたいなやつは順序が保証されないので別にいいっちゃいいんだけど、まさか実装によってソート方式が違うというのは思いもしなかった。

EdgeとChromeで処理結果が優位に違うのも、恐らくこれが原因なのだろう。分からないが多分JSのエンジンの実装が違う気がする。

それとLinuxのEdgeにはマウスジェスチャー機能がないという悲しいことも分かった。

参考

• Performance Effects of Exceptions in Java | Baeldung
• The Exceptional Performance of Lil' Exception