それほどトンデモじゃない いちばんやさしいWeb3の教本
概要
2022年7月20日に発行した「いちばんやさしいWeb3の教本」を購入して読んだ感想です。
なお、2022年7月24日現在、出版元から下のような提示がされていて、大手ECサイトでは電子版は既に発売中止で紙の本は在庫のみとなっています。（紙の本も在庫無くなってます）
弊社2022年7月20日発行の「いちばんやさしいWeb3の教本 人気講師が教えるNFT、DAO、DeFiが織りなす新世界」の内容に関しまして、 SNSを中心にさまざまなご意見をいただいておりますが、現在著者ならびに外部有識者、編集部におきまして内容の検証、精査を行っております。
今後の対応につきましては、修正文の掲載、書籍の回収なども含めて検討しておりますので、方針が決まり次第発表させていただきます。 なお、今後の方針発表は7月25日月曜日を予定しております。 それまでの間、予定しておりました第1章、第2章の無料公開は中止させていただきます。
購入動機
前評判では意味不明なワードサラダというパワーワードがあったので、すべてそんな感じかなと思っておりました。
#いちやさWeb3 実在する技術用語をやさしく噛み砕いているようで実際のところ意味不明なワードサラダなので悪質な本だと思います。
— にゃんだーすわん (@tadsan) 2022年7月20日
TCP/IPをGAFAが独占みたいなのは百歩譲って主張したいことを汲み取れなくはないのですが、このページは本当に意味がわかりません。(引用表記は画像alt中) pic.twitter.com/xM7QsTAU1V
しかし、そのときに公開されているのは1章と2章*1のみで、1章は前評判通りでしたが2章はそうでもないと感じたので、どういう思いで書いたのかというのを知りたいという気持ちで購入しました。
感想
NFT、DAO、DeFiなど非常に詳しく書いてあり、一部主語がデカい部分や色々と間違っていたりと、間違いの部分を目をつぶれば、それほどトンデモとは感じませんでした。
間違いが多すぎて初心者向けじゃないとも感じました。
要するに、怪しいビジネス書にはなっていないと言うことです。
間違いが多いのは、出版元も訂正すると言っていたので、そこは期待したい。残念ながら発売中止となり間違いが訂正されることはなくなりました。
ちなみに間違いについて1つ例を上げると、DeFiのレイヤー解説でSettlement layerとAsset layerをまとめてブロックチェーンにするのは、ちょっと強引やなーと感じるところがあります。
本書から図表24-1を引用してます：
匿名性と透明性についての言及もされており、本書では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を「中途半端な理解」した人が「乱暴な説明」で「言葉足らず」でプロモーションした物でしたね。
Web3の教本は、このような宣伝をすると良いぞw pic.twitter.com/ckwm9N8Lbm
— さっぴー川原🍶カワハラ_IT_Engineer (@sapi_kawahara) 2022年7月21日
*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氏が始めたプロジェクトです。
サマータイムはもちろん、うるう秒があったことまでも細かく記載されており、ドキュメントの情報量がすごくて一度見ると良いです。
また、政治的なことでの国境変更や国名の変更は珍しくないので当初から"地域/地名"形式を使用しています。だがしかし今回のようなキーウ（キエフ）の件は地名の変更になってしまい影響することになりました。
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 "エンジニアのための「カジュアル面談のトリセツ」【電子書籍】[ 川原 英明 ]")
