人生100年!生涯エンジニア人生!

楽しいエンジニア人生!

人生初のPCR検査→陰性でした

概要

私はコロナワクチンを2022年4月の時点で3回接種済み(ファイザーファイザー、モデルナ)で、マスクをしながらコロナには感染しないように注意をしております。

そんな中、職場にて発熱をした人が出てしまい、その人の5メートル範囲の席に着席していたので、念のためにPCR検査をすることにしました。

なお、感染疑いな状態なので7日間は家庭内では隔離になり、トイレなどは利用したら消毒をしてから立ち去るようにしました。

この記事はPCR検査をしたことを記録として残します。

PCR検査できるところを探す

まずは医療機関かな?と思いましたが、検索すると「発熱をしていない」など「無症状の方」は検査を遠慮してほしいということになっている。

次に薬局などですが、ウェルシア薬局とかならやっているので確認すると2022年7月29日の時点では予定検査数を大幅に超えており、来週に再開するが詳しいことは決まっていないということでした。

www.welcia-yakkyoku.co.jp

そして、最後に向かったのはPCR検査センターというところでした。

PCR検査

PCR検査センターに行き、整理券をもらいます。

当日有効ですね。

予約時間になったら、センターで提示されるQRコードを読み込み「氏名」「住所」「携帯電話番号」などを入力します。
「携帯電話番号」に結果がSMSで送信されるため正確に入力します。

入力が終わったら、無料か有料かの窓口を選びます。
有料だと、その日までに結果がくるそうですが、無料で良かったので無料の窓口に行くと「身分証明書」の提示を求められるので提示してから、確認のために「氏名」「住所」「携帯電話番号」を答えます。
確認が終わると、検査キットを渡されるので、それを持って区分けされたスペースで唾液を入れます。

この唾液を出すのが結構しんどい10分近くかかります。

検査キットに必要量の唾液を入れたら別の窓口に提出すると、検査確認のURLや何時までに結果が来ますということが書いてある1枚の紙を渡されて検査が終わります。

検査結果

2日後にSMSが来ました。

詳細を見なくても「陰性」とわかります。

SMSが来るまでは、もしも?という気持ちがよぎるので「陰性」と出ると「ヨシ!」という気持ちに変わりますね。

実際に、私のPCR検査判定が出る前日に、職場で発熱した人から「陽性」だったと連絡はあったので余計に不安になりました。

詳細を確認するために、SMSに記載されているURLにアクセスします。

「携帯電話番号」を入力すると、ワンタイムパスワードが発行されるので入力すると結果を見ることができます。

証明書も、ここから確認できます。

PDFが表示されました。
なお、PDFのダウンロードはパソコンのみなので、このあとパソコンでダウンロードしました。

余談

PCR検査センターのサイトはFaviconにReactのロゴが出てたので、Reactで作られているんだろうなーと思いました。

PDFのプロパティを見ると「Pdfmake」とあるので、こちらのOSSを利用しているのでしょう。

github.com

COCOA

PCR検査が陰性と判明したあと、職場で発熱した人が医療機関を通じて手続き、新型コロナウイルス感染者等情報把握・管理支援システム(HER-SYS)に登録したという連絡がきました。

その1時間後にCOCOAが反応しました。

個人的な感想としては「お、機能してたんだな」です。

ただ、5メートル離れていたのでBluetoothの距離測定は、そこまで正確じゃないんだなーと思いました。

その後

7日間経過したので、家庭内での隔離は終了しました。
陰性でも、疑いがあるときは自主的な隔離をすることでリスクを回避したほうが良いと感じました。

今回、コロナ感染疑いからの陰性なので、なるべく人との接触を避けるだけで終わりました。

そして、発熱もなく普段の生活に戻りました。

それほどトンデモじゃない いちばんやさしいWeb3の教本

概要

2022年7月20日に発行した「いちばんやさしいWeb3の教本」を購入して読んだ感想です。

なお、2022年7月24日現在、出版元から下のような提示がされていて、大手ECサイトでは電子版は既に発売中止で紙の本は在庫のみとなっています。(紙の本も在庫無くなってます)

book.impress.co.jp

弊社2022年7月20日発行の「いちばんやさしいWeb3の教本 人気講師が教えるNFT、DAO、DeFiが織りなす新世界」の内容に関しまして、 SNSを中心にさまざまなご意見をいただいておりますが、現在著者ならびに外部有識者、編集部におきまして内容の検証、精査を行っております。
今後の対応につきましては、修正文の掲載、書籍の回収なども含めて検討しておりますので、方針が決まり次第発表させていただきます。 なお、今後の方針発表は7月25日月曜日を予定しております。 それまでの間、予定しておりました第1章、第2章の無料公開は中止させていただきます。

購入動機

前評判では意味不明なワードサラダというパワーワードがあったので、すべてそんな感じかなと思っておりました。

しかし、そのときに公開されているのは1章と2章*1のみで、1章は前評判通りでしたが2章はそうでもないと感じたので、どういう思いで書いたのかというのを知りたいという気持ちで購入しました。

感想

NFT、DAO、DeFiなど非常に詳しく書いてあり、一部主語がデカい部分や色々と間違っていたりと、間違いの部分を目をつぶれば、それほどトンデモとは感じませんでした。
間違いが多すぎて初心者向けじゃないとも感じました。
要するに、怪しいビジネス書にはなっていないと言うことです。
間違いが多いのは、出版元も訂正すると言っていたので、そこは期待したい。残念ながら発売中止となり間違いが訂正されることはなくなりました。

ちなみに間違いについて1つ例を上げると、DeFiのレイヤー解説でSettlement layerとAsset layerをまとめてブロックチェーンにするのは、ちょっと強引やなーと感じるところがあります。

本書から図表24-1を引用してます:

世間的な例:

https://research.stlouisfed.org/publications/review/2021/02/05/decentralized-finance-on-blockchain-and-smart-contract-based-financial-markets

匿名性と透明性についての言及もされており、本書ではAML(Anti-Money Laundering)とCFT(Countering the Financing of Terrorism)*2の話題にも真摯に触れており、Web3がきな臭いビジネスとは違うんだと読んでて感じました。
また、7章を読むとWeb3の世界のきな臭さについて憂いていることがすごく読み取れます
私が思うに、この本を書いたきっかけは世間にあるWeb3の解説がきな臭い物ばかりで、それを何とかしたかったんじゃないかなと感じます。
また、私はこの本を読んで、彼らの考えを知って学ぶところも正直ありました。
特に最後の7章では執筆者の気持ちがあるので、そこは読んでおきたい。

ただ、その行動でWeb3最高!それ以外は駄目!的な感じに書かれているところが多々あります。
そういう過去のテクノロジーがあってこそWeb3があるのに、否定とも取れるような感じになっているのが残念です。
また、ブロックチェーンこそが分散テクノロジーだと言ってたり、いや、それはWeb2の世界というかインターネットの根本だぞ!って感じです。
もう少し既存の技術に対してリスペクトしてほしいなーと思ったりします。

そして、それに追い打ちかけているのが、この著者の特徴と言える書き方である「中途半端な理解」「乱暴な説明」「言葉足らず」です
特に1章は、それのオンパレードになっており結果として炎上に結びついたと考えられます。
例えばプロトコルについては「共通ルール」として書いてあり、大きな意味では間違っていないけど、これこそ「中途半端な理解」「乱暴な説明」「言葉足らず」の典型となっています。
コンピューターを語る上でプロトコルといえば「OSI参照モデル*3が出てくる世界なので、それを踏まえて、プロトコルとは何か?を例えるときは定義から入ります。
そして、ブロックチェーンプロトコルと仮定したらなど言葉から在り方まで定義したり、説明が足りないと感じたらわかりやすい言葉を追加するなど、初心者向けに説明するならば色々と書かなければならないことは沢山あります。
他の章も、そうなのですが、1章は特にひどいです。

そのため私個人として思うことは、1章は全削除か誰か別の方が執筆したほうが良いと感じます。(まあ、改訂版が出ることが無くなったので、それも無いですね)

まとめ

  • 思ってたほどトンデモな本じゃなかった
  • 7章は読んでほしい
  • Web3界隈のきな臭さを憂いているのは感じ取れる
  • 1章は本当にひどいです
  • 1章以外も間違いが多数あります
  • 一部「中途半端な理解」「乱暴な説明」「言葉足らず」になっているので「いちばんやさしい本」とは言い切れない
  • 私は価格通りの価値を感じたが、万人向けではないのでオススメできない

余談

バージョンで語る物って、私はどうしてもDoCoMo2.0を思い出します。
あれこそ、Web2.0を「中途半端な理解」した人が「乱暴な説明」で「言葉足らず」でプロモーションした物でしたね。

www.j-cast.com

*1:発行記念で2022年7月20日~7月31日まで1章と2章を公開してたのですが、炎上後2022年7月23日をもって非公開になりました。

*2:https://www.zenginkyo.or.jp/news/2018/n10817/

*3:https://ja.wikipedia.org/wiki/OSI%E5%8F%82%E7%85%A7%E3%83%A2%E3%83%87%E3%83%AB

ロシア語由来のキエフ(Kiev)表記から、ウクライナ語のキーウ(Kyiv)に変更することを、エンジニア的に考える

経緯

首都「キエフ」の表記をウクライナ語の「キーウ」に変更へ 日本政府:朝日新聞デジタル www.asahi.com

現在、日本国内で広く使われている「キエフ(Kiev)」は、ロシア語の発音に由来する。一方、ウクライナ語は「Kyiv」とつづり、発音は「キーウ」に近い。

ということなので、これについて何らかの変更依頼はあると思われるのでまとめてみます。

前提知識

地球は球体で自転によって太陽が動きます。球体なので太陽が見える位置が変わります。太陽の位置によって時刻が変化する。

※フラットアース支持者はお帰りください。

地域によって時刻が変化するが、それは「タイムゾーン (Time Zone)」呼ばれ、その基準と運用は「協定世界時(Coordinated Universal Time)」で決められている。 エンジニアなら、TZやUTCという略語を聞いたことあるでしょう。

この協定世界時を、コンピューターシステムでは、どのように運用されているのでしょうか?

大きく3つの運用が存在します。

  • IATA Timezone Codes
  • Windows
  • IANA Time Zone Database

まず、最初のIATA Timezone Codesです。名前のとおりIATA(International Air Transport Association)は国際航空運送協会のことで航空業界のタイムゾーンで、その辺りのシステムでは組み込まれるんだろうと思いますが、その辺りの知識がないし今回の記事とは関係ないので割愛します。

次に、Windowsです。WindowsタイムゾーンMicrosoft自身が管理しています。これは昔からなので、WindowsタイムゾーンMicrosoft管理ということだけ覚えておいてください。今回の記事では軽く触れます。

最後が、IANA Time Zone Databaseです。こちらは2011年10月14日よりICANNのIANAが管理していますが、その前はArthur David Olson氏が始めたプロジェクトです。

サマータイムはもちろん、うるう秒があったことまでも細かく記載されており、ドキュメントの情報量がすごくて一度見ると良いです。

How to Read the tz Database

また、政治的なことでの国境変更や国名の変更は珍しくないので当初から"地域/地名"形式を使用しています。だがしかし今回のようなキーウ(キエフ)の件は地名の変更になってしまい影響することになりました。

IANA Time Zone Databaseについては、色々とネタが豊富なのですが、今回はこれぐらいにしておきます。

ウィキペディアも読んでて楽しいので軽く読んでおきましょう。 ja.wikipedia.org

IANA Time Zone Databaseを更新するところはGitHubリポジトリーがあります。

キーウ(キエフ)の件は、で2022年4月13日にCommitされています。ただ、2022年6月24日時点ではリリースはされていません。そのため各ディストリビューションには反映されていません。

github.com

リリースされて、さらにOSが更新されたときに変更されるでしょう。

また、直接更新する方法もありますが、そこはググると出てくるので、自己責任でやってみてください。私はDockerを使って試しました。

OS

まずはOS周りは見てましょう。

Windows

Microsoftが管理しているのでOSのアップデートのときにあると思いますが、現状ではWindowsタイムゾーンにキーウ(キエフ)はないので追加することはないでしょう。

なお、コマンドプロンプトtzutil /lとするとWindowsが持っているすべてのタイムゾーンを表示できます。

docs.microsoft.com

WSL2などインストールすると、そこは別のOSが動きますので、たえばUbuntuだったらIANA Time Zone Databaseで管理されます。当然ながら、ホストOSであるWindowsには影響ありません。

Windows以外

Linux,BSD,macOS,iOS,Androidなどは、IANA Time Zone Databaseです。

/usr/share/zoneinfoに情報があります。/usr/share/zoneinfo/Europe辺りを眺めてみてください。

データベース

次にデータベースを見ていきましょう。今回はMySQLPostgreSQLを取り上げます。

MySQL

マニュアルにzoneinfo databaseについての記載があります。

5.1.15 MySQL Server Time Zone Support dev.mysql.com

If your system has its own zoneinfo database (the set of files describing time zones), use the mysql_tzinfo_to_sql program to load the time zone tables. Examples of such systems are Linux, macOS, FreeBSD, and Solaris. One likely location for these files is the /usr/share/zoneinfo directory. If your system has no zoneinfo database, you can use a downloadable package, as described later in this section. To load the time zone tables from the command line, pass the zoneinfo directory path name to mysql_tzinfo_to_sql and send the output into the mysql program. For example:

IANA Time Zone Databaseをインポートして使用するようですね。OSの更新があったら、こちらの更新もすると良いようですね。

PostgreSQL

マニュアルにzoneinfo databaseについての記載があります。

B.4. Date/Time Configuration Files www.postgresql.org

timezone_abbreviations can be set to any file name found in .../share/timezonesets/, if the file's name is entirely alphabetic. (The prohibition against non-alphabetic characters in timezone_abbreviations prevents reading files outside the intended directory, as well as reading editor backup files and other extraneous files.)

インストールしたところにtimezonesetsというのがあるらしい。 GitHubで確認すると、IANA Time Zone Databaseにソックリですね。 このtimezonesetsをOSとは別に変更する必要がありますね。

github.com

なお、最新版(14.4)でもEurope/KievだったりするのでPostgreSQLの更新を待ちましょう。

開発言語

今回はPython,Perl,JavaScript,Ruby,PHPを取り上げます。

開発言語は、基本的にIANA Time Zone Databaseを直接読み込むことはしていないようです。言語自体が情報を持っていたりライブラリー(この記事ではライブラリーに統一)の中に情報を持っていることが多いです。

ただ、気を付けていただきたいのが、OSや言語のタイムゾーンが更新してない状態で、タイムゾーン表示を見た目だけ変更して日時表示を行うところに流用ししてしまうとエラーもしくは正しい値が取れません。

PHPの場合は間違った地名の日時を表示しようとするとExceptionが発生して動きません。 下のコードはPHPですが、プルダウンメニューとかを見た目だけこっそりと修正したいなら、こんな感じで差し替えするしかないですね。

エルビス演算子を使っているので5.3でも動きます。

<?php
$timezone_kyiv = [312 => "Europe/Kyiv"];
$timezone_identifiers = DateTimeZone::listIdentifiers();
foreach ($timezone_identifiers as $key => $value) {
    $value = $timezone_kyiv[$key] ?: $value;
    echo $key . ':'. $value . "\n";
}

Python

3.9からIANA Time Zone Databaseをサポートしていて、直接読んで使用しています。

docs.python.org

つまり、OSでタイムゾーンが更新されると、Pythonタイムゾーンも自動的に更新されます。

import zoneinfo
zoneinfo.available_timezones()

なお、このようにすると、タイムゾーンの一覧が出てきます。

それより古いバージョンはpytzかな??

pytz.sourceforge.net

Perl

ライブラリーであるDateTime::TimeZoneを使います。

metacpan.org

内部に情報を保持しているのでライブラリーの更新があったときに変更されるようです。

DateTime::TimeZone->all_namesで一覧が出てきます。

JavaScript

標準はIntl.DateTimeFormatで地名はサポートしていません。このデータはブラウザーが保持しているようで、ブラウザーが更新することで変わります。

地名を使用したいときはライブラリーがあります。なおライブラリー内部に情報を保持しているのでライブラリーの更新があったときに変更されるようです。

github.com

Ruby

GemライブラリーであるTZInfoを使います。

rubydoc.info

内部に情報を保持しているのでGemライブラリーの更新があったときに変更されるようです。

require 'tzinfo'
TZInfo::Timezone.all_country_zone_identifiers

なお、このようにすると、タイムゾーンの一覧が出てきます。

PHP

内部で情報を保持しています。PHP自体の更新があったときに変更されるようです。

ちなみにDateTimeZone::listIdentifiersです。

www.php.net

まとめ

タイムゾーンのキーウ(キエフ)の対応は各OSやデータベースや開発言語でまちまちです。

・IANA Time Zone Databaseは更新がありましたがリリースはされていない。(2022年6月24日時点)

・ライブラリー更新なのかOS更新なのかは、データベースや開発言語のマニュアルを参考にして対応しよう

・今すぐ対応するなら表示だけこっそり修正しよう!

昭和的習慣朽ち果てろ!50歳以上の人で「すぐ居眠りしがち」の件について

ツイートが軽くバズった

個人的な感想ですが・・・

勤務態度として「すぐ居眠りしがち」と言っている人がTwitterで居たのですが、これって本人は多くの人から共感を得たい承認欲求から、このようなことを書いたのだと思うけど、実は勤務中に無意識に居眠りを頻繁する方は、少なからず何らかの病気を持っている可能性があるんですよ。

自分の経験談

ツイートでは、これって結構な確率で「睡眠時無呼吸症候群」と言いましたが、過去に自分が遭遇したのは30歳の方だったのですが、診察した方が良いと強く勧めたら「睡眠時無呼吸症候群」と診断されたことがあります。
肥満じゃないけど、小顔な人だったので大人になってから、その症状が出たらしいです。

このケースは大事に至ってないけど、最悪なケースだと仕事中に呼吸止まって救急搬送になります。

昭和的習慣朽ち果てろ!

Twitterのレスや引用リツートで、他の症例も聞きました。

睡眠時無呼吸症候群」の他に「ナルコレプシー」「PMSの影響での睡眠不足」「糖尿病の低血糖発作」「ADHDからくる倦怠感」なども居眠りを発生させます。

居眠りをすることは良くないことですが、そこに潜む病気もあることを気付かないのは会社としてヤバいし、Twitterでそこについてイキル感じでツイートするのもヤバいと思います。
こういう病気は意外と身近なもので、昔は「天気頭痛」なんて気分的な物だと揶揄されていましたが、今では当たり前の頭痛として認識されています。

そういう病気を、気合で何とかするのは昭和的習慣なんだと強く思う。
私個人としては、その人の病気による症状に寄り添えないのは、昭和的習慣なので朽ち果てて欲しい。

エンジニアのための「カジュアル面談のトリセツ」のことを聞いてくる会社ありますか?

よくあることです

エンジニアのための「カジュアル面談のトリセツ」のことを転職サイトでもアピールしているので、全部ではないですが一部の会社は聞いてきます。
そのとき、多くの会社が言うのですが「ダメ出しするんじゃないかとドキドキします」とね。

私としては、カジュアル面談は会社のことを知るための場で、それで時間になるのでダメ出しをすることが無いです。
カジュアル面談が実りある結果である状況=ダメ出しすることがない

ほとんどの会社が、このような感じでカジュアル面談をしてくれるので良い時間を過ごす体験になっています。

ダメ出しするタイミング

そう言っても、時間が余るケースが、一部の会社であります。
時間が余って、会社が望んでいて改善する意思があるならば、ダメ出しするときがあります。
今まで数えるぐらいしかしていません。

だいたい、下のようなケースで時間が余ります。

  1. 会社説明資料が少ない、または無い
  2. 質疑応答で返事ができない
  3. 面接だった・・・

一番多いのが会社説明資料が少ないケースで、スタートアップに多いのですが、それでも口頭で熱く説明できれば良いのですが、それもできていない会社が見受けられます。
また、会社説明資料として「投資者への資料」や「株主向け資料」を出されても、会社の概要でしか無いので個人的にはへーという感想しか生まれません。

質疑応答で返事ができないケースは、人事担当の人のみがカジュアル面談に参加したとき多いです。
これは自分の書いた書籍『エンジニアのための「カジュアル面談のトリセツ」』でも書いていますが、人事担当でもエンジニアに想定される質疑応答を聞いて用意することが望ましいです。

なお、面接だったケースは、ダメ出しすることもせずに、自然とフェードアウトして終わりにしてます。

まとめ

カジュアル面談で、書籍のことを聞いてくる会社はあります。
ダメ出しすることはないので、楽しくカジュアル面談をしています。
時間が余ったというレアケースなとき、ダメ出しすることが稀にあります。