ロシア語由来のキエフ(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氏が始めたプロジェクトです。
サマータイムはもちろん、うるう秒があったことまでも細かく記載されており、ドキュメントの情報量がすごくて一度見ると良いです。
また、政治的なことでの国境変更や国名の変更は珍しくないので当初から"地域/地名"形式を使用しています。だがしかし今回のようなキーウ（キエフ）の件は地名の変更になってしまい影響することになりました。
IANA Time Zone Databaseについては、色々とネタが豊富なのですが、今回はこれぐらいにしておきます。
ウィキペディアも読んでて楽しいので軽く読んでおきましょう。 ja.wikipedia.org
IANA Time Zone Databaseを更新するところはGitHubにリポジトリーがあります。
キーウ（キエフ）の件は、で2022年4月13日にCommitされています。ただ、2022年6月24日時点ではリリースはされていません。そのため各ディストリビューションには反映されていません。
リリースされて、さらにOSが更新されたときに変更されるでしょう。
また、直接更新する方法もありますが、そこはググると出てくるので、自己責任でやってみてください。私はDockerを使って試しました。
OS
まずはOS周りは見てましょう。
Windows
Microsoftが管理しているのでOSのアップデートのときにあると思いますが、現状ではWindowsのタイムゾーンにキーウ（キエフ）はないので追加することはないでしょう。
なお、コマンドプロンプトでtzutil /lとするとWindowsが持っているすべてのタイムゾーンを表示できます。
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辺りを眺めてみてください。
データベース
次にデータベースを見ていきましょう。今回はMySQLとPostgreSQLを取り上げます。
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とは別に変更する必要がありますね。
なお、最新版(14.4)でもEurope/KievだったりするのでPostgreSQLの更新を待ちましょう。
開発言語
今回はPython,Perl,JavaScript,Ruby,PHPを取り上げます。
開発言語は、基本的にIANA Time Zone Databaseを直接読み込むことはしていないようです。言語自体が情報を持っていたりライブラリー（この記事ではライブラリーに統一）の中に情報を持っていることが多いです。
ただ、気を付けていただきたいのが、OSや言語のタイムゾーンが更新してない状態で、タイムゾーン表示を見た目だけ変更して日時表示を行うところに流用ししてしまうとエラーもしくは正しい値が取れません。
PHPの場合は間違った地名の日時を表示しようとするとExceptionが発生して動きません。 下のコードはPHPですが、プルダウンメニューとかを見た目だけこっそりと修正したいなら、こんな感じで差し替えするしかないですね。
<?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をサポートしていて、直接読んで使用しています。
つまり、OSでタイムゾーンが更新されると、Pythonのタイムゾーンも自動的に更新されます。
import zoneinfo zoneinfo.available_timezones()
なお、このようにすると、タイムゾーンの一覧が出てきます。
それより古いバージョンはpytzかな？？
Perl
ライブラリーであるDateTime::TimeZoneを使います。
内部に情報を保持しているのでライブラリーの更新があったときに変更されるようです。
DateTime::TimeZone->all_namesで一覧が出てきます。
JavaScript
標準はIntl.DateTimeFormatで地名はサポートしていません。このデータはブラウザーが保持しているようで、ブラウザーが更新することで変わります。
地名を使用したいときはライブラリーがあります。なおライブラリー内部に情報を保持しているのでライブラリーの更新があったときに変更されるようです。
Ruby
GemライブラリーであるTZInfoを使います。
内部に情報を保持しているのでGemライブラリーの更新があったときに変更されるようです。
require 'tzinfo' TZInfo::Timezone.all_country_zone_identifiers
なお、このようにすると、タイムゾーンの一覧が出てきます。
PHP
内部で情報を保持しています。PHP自体の更新があったときに変更されるようです。
ちなみにDateTimeZone::listIdentifiersです。
まとめ
・タイムゾーンのキーウ（キエフ）の対応は各OSやデータベースや開発言語でまちまちです。
・IANA Time Zone Databaseは更新がありましたがリリースはされていない。（2022年6月24日時点）
・ライブラリー更新なのかOS更新なのかは、データベースや開発言語のマニュアルを参考にして対応しよう
・今すぐ対応するなら表示だけこっそり修正しよう！
昭和的習慣朽ち果てろ！50歳以上の人で「すぐ居眠りしがち」の件について
ツイートが軽くバズった
個人の感想で、50歳以上の人で「すぐ居眠りしがち」と言っている人が居るけどさ、これって結構な確率で「睡眠時無呼吸症候群」だから、会社として検査を勧めないとアカンよ。
— さっぴー川原🍶カワハラ_IT_Engineer (@sapi_kawahara) 2022年6月20日
最悪、仕事中に呼吸止まって救急搬送よ。
ことの重大さに気付いてないよねー。
まあ、私のツイートも個人の感想ですけどね。
個人的な感想ですが・・・
勤務態度として「すぐ居眠りしがち」と言っている人がTwitterで居たのですが、これって本人は多くの人から共感を得たい承認欲求から、このようなことを書いたのだと思うけど、実は勤務中に無意識に居眠りを頻繁する方は、少なからず何らかの病気を持っている可能性があるんですよ。
自分の経験談
ツイートでは、これって結構な確率で「睡眠時無呼吸症候群」と言いましたが、過去に自分が遭遇したのは30歳の方だったのですが、診察した方が良いと強く勧めたら「睡眠時無呼吸症候群」と診断されたことがあります。
肥満じゃないけど、小顔な人だったので大人になってから、その症状が出たらしいです。
このケースは大事に至ってないけど、最悪なケースだと仕事中に呼吸止まって救急搬送になります。
昭和的習慣朽ち果てろ！
Twitterのレスや引用リツートで、他の症例も聞きました。
「睡眠時無呼吸症候群」の他に「ナルコレプシー」「PMSの影響での睡眠不足」「糖尿病の低血糖発作」「ADHDからくる倦怠感」なども居眠りを発生させます。
居眠りをすることは良くないことですが、そこに潜む病気もあることを気付かないのは会社としてヤバいし、Twitterでそこについてイキル感じでツイートするのもヤバいと思います。
こういう病気は意外と身近なもので、昔は「天気頭痛」なんて気分的な物だと揶揄されていましたが、今では当たり前の頭痛として認識されています。
そういう病気を、気合で何とかするのは昭和的習慣なんだと強く思う。
私個人としては、その人の病気による症状に寄り添えないのは、昭和的習慣なので朽ち果てて欲しい。
エンジニアのための「カジュアル面談のトリセツ」のことを聞いてくる会社ありますか？
よくあることです
エンジニアのための「カジュアル面談のトリセツ」のことを転職サイトでもアピールしているので、全部ではないですが一部の会社は聞いてきます。
そのとき、多くの会社が言うのですが「ダメ出しするんじゃないかとドキドキします」とね。
私としては、カジュアル面談は会社のことを知るための場で、それで時間になるのでダメ出しをすることが無いです。
カジュアル面談が実りある結果である状況＝ダメ出しすることがない
ほとんどの会社が、このような感じでカジュアル面談をしてくれるので良い時間を過ごす体験になっています。
ダメ出しするタイミング
そう言っても、時間が余るケースが、一部の会社であります。
時間が余って、会社が望んでいて改善する意思があるならば、ダメ出しするときがあります。
今まで数えるぐらいしかしていません。
だいたい、下のようなケースで時間が余ります。
- 会社説明資料が少ない、または無い
- 質疑応答で返事ができない
- 面接だった・・・
![【POD】エンジニアのための「カジュアル面談のトリセツ」 （技術の泉シリーズ（NextPublishing）） [ 川原 英明 ]](https://thumbnail.image.rakuten.co.jp/@0_mall/book/cabinet/0176/9784295600176.jpg?_ex=128x128 "【POD】エンジニアのための「カジュアル面談のトリセツ」 （技術の泉シリーズ（NextPublishing）） [ 川原 英明 ]")
一番多いのが会社説明資料が少ないケースで、スタートアップに多いのですが、それでも口頭で熱く説明できれば良いのですが、それもできていない会社が見受けられます。
また、会社説明資料として「投資者への資料」や「株主向け資料」を出されても、会社の概要でしか無いので個人的にはへーという感想しか生まれません。
質疑応答で返事ができないケースは、人事担当の人のみがカジュアル面談に参加したとき多いです。
これは自分の書いた書籍『エンジニアのための「カジュアル面談のトリセツ」』でも書いていますが、人事担当でもエンジニアに想定される質疑応答を聞いて用意することが望ましいです。
なお、面接だったケースは、ダメ出しすることもせずに、自然とフェードアウトして終わりにしてます。
まとめ
カジュアル面談で、書籍のことを聞いてくる会社はあります。
ダメ出しすることはないので、楽しくカジュアル面談をしています。
時間が余ったというレアケースなとき、ダメ出しすることが稀にあります。
エンジニアのための「カジュアル面談のトリセツ」に書かなかった「平均勤続年数」のこと
概要
私が執筆した書籍、エンジニアのための「カジュアル面談のトリセツ」で、会社を知る意味でホームページを閲覧することをススメていますが、口コミなどは参考程度にしてほしいと書いています。
そういう会社についての情報として、あまり参考にならないのが「平均勤続年数」です。
私が執筆した書籍『エンジニアのための「カジュアル面談のトリセツ」』についての記事はこちらです。
kawahara-ci.hatenablog.com
このことは書籍では一切触れていないのですが、ここ最近、話題になったので取り上げます。
話題になったのは、これですね。
｢最短は電子書籍配信会社の1.3年｣平均勤続年数ワースト300社ランキング2021
president.jp
参考にならない理由
下にあげる3つの理由があります。
- IT系の会社が若い
- 組織改編で勤続年数なんてリセットされる
- 勤続年数が長い人が正しいとは限らない
これらを簡単に説明します。
IT系の会社が若い
エンジニアが所属するIT系の会社なんて、20年足らずの会社がほとんどで、勤続年数長さなんてどんぐりの背比べにしかなっていないのです。
指標として「会社設立2年、平均勤続年数2年」とか出すならば、百歩譲って指標になり得るかもしれませんが、この程度の情報では、その会社が良いかどうかなんて参考にならないというのが、私の考えです。
平均勤続年数が短い＝会社設立が短いという代表例としてベンチャーがありますが、ベンチャーはベンチャーなりのリスクなどがありますが、平均勤続年数とは別に考えるのが良いです。
組織改編で平均勤続年数なんてリセットされる
こちらについては、やり玉にあげられた株式会社メディアドゥが遺憾表明しております。
私も同意見で、組織改編や会社の吸収合併で平均勤続年数なんかは簡単にリセットされます。
また、事業拡大で積極的に採用を行うなどすると平均勤続年数は下がっていきます。
事業拡大する会社は、会社が成長している段階で、その瞬間に入ることは多くのメリットがあります。
何が評価されて事業拡大しているのか？そういう点を「カジュアル面談」で聞けるのも、「カジュアル面談」ならではの醍醐味なので積極的に聞いてみるのも良いです。
「カジュアル面談」というのは、会社を色々な側面を見ることができるチャンスなので、平均勤続年数のモノサシで測るのは、その会社を一部しか見てないことになるので、物凄くもったいないです。
蛇足ですが、組織改編については、色々なやり方や会社の考えがあるので、どれが正解とは言えませんが、同時期に組織改編を行った楽天株式会社（現、楽天グループ株式会社）は社名を変更しているだけなので、平均勤続年数はリセットされていまん。（ちなみに平均勤続年数は4.6年です）
会社の組織改編という要因や、事業拡大による採用強化で平均勤続年数は短くなったりするので参考にならないのです。
勤続年数が長い人が正しいとは限らない
勤続年数が長い人の言うことが正しいのでしょうか？
ベンチャーなどに多いのですが、ワンマン社長という言葉を聞いたことないですか？
経営者は勤続年数にはカウントされませんが、カウントするならば一番長い勤続年数ですよね？
私が調べた限りですが、ブラックな会社は、上司だけ平均勤続年数が長い傾向があります。
平均勤続年数が長い人が「老害的な発言」をしたり、「理由を説明せずに決まったことだから」と言ったり、そんな傾向があったら、その組織はブラックな道を歩みだしています。
私の持論ですが、このような組織はパワハラが横行します。
この辺りも「カジュアル面談」をしてみると見えてきます。
「カジュアル面談」での老害的な発言の代表例としては「こんなこと知らないの？」です。
自分が老害的な年齢なので、この言葉には特に気を付けていますし、そもそも、自分の得意分野以外では、私だって「こんなこと知らん」です。
このような言葉を「カジュアル面談」で使ってしまうような人は、申し訳ないけどパワハラの一歩手前なので近寄らないのが正しいです。
「カジュアル面談」で、そんなことを言う人が居るの？と思われるかもしれませんが実際に3社ほど居たので、経験談として言っております。
パワハラの傾向がある人が勤続年数が長いとか限りませんが、パワハラが横行する組織でパワハラを行う側は居心地が良いので、勤続年数が長くなるのかもしれないと思っています。
まとめ
ワーストとミスリードするプレジデントオンライン、それが正しいかどうは読む人次第だと思うけど、転職をする際に使う指標としては参考にならないことを書きました。
会社を見る上で、まずは会社のことを書いてあるホームページ、そして「カジュアル面談」における「現場で働く人の生の声」、そういうところを見て聞いて疑問があれば「カジュアル面談」でどんどん質問すれば良いのです。
だから、平均勤続年数なんて、本当に参考にならないのです。
![エンジニアのための「カジュアル面談のトリセツ」【電子書籍】[ 川原 英明 ]](https://thumbnail.image.rakuten.co.jp/@0_mall/rakutenkobo-ebooks/cabinet/9127/2000010809127.jpg?_ex=128x128 "エンジニアのための「カジュアル面談のトリセツ」【電子書籍】[ 川原 英明 ]")
iCloud+の「メールを非公開」についての補足、メールエイリアスについて
概要
下のようなツイートが来ました。
@sapi_kawahara
— 桃苺うさぎ🐰11m🐘 (@momoichigousagi) 2022年2月9日
初めまして。ブログの記事(iCloud+メールを非公開)を見ました。使おうとしてたのですごい参考になりました🙄
ふと思ったのですが、iCloudのエイリアスでも同じことが言えるのですか？いきなり質問してすみません💦
なるほど、そういえばメールエイリアスの言及してなかった。
メールを非公開についての記事はこちらです。
kawahara-ci.hatenablog.com
メールエイリアスとは？
こちらに説明がありますが、iCloudではメインのメールアドレスの他に3つメールアドレスを追加できる機能です。
せっかくなので、エイリアスの追加などの説明します。
エイリアスの追加
iCloudのサービスにブラウザでログインにしてから、メールボックスに移動し歯車アイコンをタップします。
「環境設定」をタップします。
「アカウント」をタップします。
「エイリアスを追加」をタップします。
設定するエイリアス名を入力し、「追加」をタップます。
エイリアス名が追加されました。
追加されたエイリアス名でメールをやり取りできるようになります。
エイリアスの削除
要らなくなったら？
要らなくなったエイリアス名をタップすると、編集画面になりますが、一番下に「エイリアスを削除」があるのでタップします。
確認のダイアログが出るので「削除」をタップすると、エイリアス名が削除されます。
※画面にあるabctest99は削除済みです。
意外と知られてない機能なので説明しました。
メールエイリアスはApple IDがバレてしまうのか？
それでは本題です。
メールエイリアスはApple IDがバレてしまうのか？
返信メールのヘッダーを確認すると、SPFやDKIMに追加される情報にメールエイリアス以外の情報はありません。
このことからApple IDはバレません。
また、iCloundの他のメールアドレスもバレることはありません。
まとめ
「メールを非公開」と「Apple でサインイン」と「メールエイリアス」の違いをまとめましたので、ご確認ください。
メールを非公開
- サイトやアプリの対応は不要です。
- メールアドレスは *@icloud.com
- iOS 15から登場した機能です。
- iCloud+にアップグレードする必要がある。
- メールを返信するとヘッダー情報からApple IDがバレる恐れがある。
Apple でサインイン
- サイトやアプリの対応が必要です。（対応してないサイトやアプリでは使用できません）
- サインインするときApple IDのメールアドレスを使用するかメールを非公開にするか選べる。
- メールを非公開にするときメールアドレスは *@privaterelay.appleid.com です。
- サイトにサインインするときに、または対応アプリをインストールするときにメールアドレスが決まる。
- iOS 13から登場した機能です。
- iCloud+を利用しなくても使えます。
- メールを返信するとヘッダー情報からApple IDがバレる恐れがある。
