テレワークの問題点

新型コロナウイルスの影響でテレワークの日々が続いています。毎日在宅で仕事をしていて思うのは,職場というのは仕事に適したつくりになっているのだなということです。私含め首都圏のように住宅事情が狭小であったりすればなおさらです。

換気というのも一つの問題です。事務所などの建物は法的に空気管理の基準が定められているそうですが,さて自宅だとどうなんだろうなという疑問が生じます。もしかして良くない空気環境で仕事をしているのでは? 少なくとも,仕事に適した基準に沿うように自分で空気を管理している意識はありません。

二酸化炭素をモニターする

今回,自宅の仕事環境の改善を目指して二酸化炭素濃度のモニターを購入しました。なんだかんだいって,ネットで見て面白そうと思ったので買ってみただけというのが真相です。

私が購入したものはカスタム (CUSTOM) CO2モニター CO2-miniです。 USBから電源をとって動きます。電池は内蔵されていないので,ケーブルを外すと動作しません。作業用のPCにつないでおいてもいいかもしれません。気温とCO2濃度が時々入れ替わって表示されます。説明書のどこにも書かれていませんが,データをコンピュータに吸い上げる機能もあるらしく,ウェブを検索するとプログラムを書いてみたというような情報が出てきます。

ランプはCO2濃度に応じて緑・黄色・赤の3種類が点灯します。緑は800 ppm未満,黄色は1,200 ppmまで,赤は1,200 ppm以上です。事務所の衛生管理では1,000 ppmが基準となっているそうです。屋外だと400 ppm前後くらいらしいです(参考)。

DSC_0512.JPG

在宅テレワークで試してみる

自宅で試していたところ,夕方から夜にかけて1,000から1,200 ppmくらいまで上昇するようです。窓を2箇所開けると効果覿面,ものの数分でガバッと下がります。1箇所開けて換気扇を回すのでもかなり改善します。窓を開けずに換気扇でもまあまあ下がります。数字の変化を見ていると面白い。

私の自宅で試した範囲では,窓を閉めて放置しておいてもそんなに能率や健康に影響ありそうではありませんでした。先のリンク先には2,500 ppmを越えると仕事のパフォーマンスが下がるという研究結果が紹介されていますが,うちでそこまで上がることはなさそうです。なので,あまり神経質に計り続ける必要は多分ないのでしょう。

もっとも,換気の効果はCO2以外にも湿気やにおいやウイルスなどもあるでしょう。換気のための動機付けとしてCO2濃度を測るのは良いのではないかと思います。それに,窓を開けて数値が下がるのを見ると,手軽に達成感が得られて気分転換にもなりますよ。

「エンジニアHub」にて記事を執筆しました。「文字コード再入門 ─ Unicodeでのサロゲートペア、結合文字、正規化、書記素クラスタを理解しよう!」として公開されています。

若手エンジニア向けのWebメディアとのことで、プログラミング上の注意点にフォーカスした内容になっています。コード例にはJava, Python, Rubyを用いています。

拙著をすでにお読みの方には復習となる内容ですが、まだの方はこの機会に是非お読みいただければと思います。記事の最後に拙著『[改訂新版]プログラマのための文字コード技術入門 (WEB+DB PRESS plusシリーズ)』の版元へのリンクも設定されていますので、興味を持たれた方には書籍の方もお読みいただければ幸いです。

当記事編集担当の方には「とても品質の高い記事」とのことで感謝のお言葉をいただきました。読者のお役に立つことを願っています。

ブログをさぼっている間に時間がずいぶん経ってしまって、もう半年も前のことなのですが、趣味で撮っている写真が、世界的に有名な写真誌米国National Geographicの運営している写真投稿サイトYour Shotにて、編集者の選ぶ1日12枚限定の「Daily Dozen」に選出されました。これはプロの写真家でも出せば必ず通るというものではなく、調べた人によると選ばれる割合は約0.3%だそうです。受賞歴に記載している写真家もおり、レベルの高い作品が自分のものと一緒に選出されているのを見ると大変光栄に感じます。

今回選出された写真は札幌の冬の夜景を撮ったものです。

選出された写真にEditor's Noteという編集者のコメントがついているのですが、それを読むとこちらの撮影意図を的確に汲んでくれているのがわかります。写真でコミュニケートできた実感があります。

残念ながらNational Geopraphic独自のYour Shotのシステムは2019年10月末で終了してInstagramに移行してしまうということです。今までのサイトを静的な形で保管しておけば良さそうなものですがそういう措置もとられないようなので、ここにスクリーンショットを掲げておきます。

URL: https://yourshot.nationalgeographic.com/photos/13439604/

yourshot-top.png
yourshot-bottom.png

Editor's Noteにはこう書かれています。(by Kristen McNicholas, Associate Photo Editor, Nat Geo Your Shot)

I love how the city glows with the snow shining on the roofs off the city lights. Great work photographing the city from a higher altitude and giving us a sense of the huge scale of the city. Well done!

ブログをさぼっている間に時間がずいぶん経ってしまって、授賞式がもう1年半も前のことなのですが、本業の方で情報処理学会から山下記念研究賞という賞を頂きました。大変光栄なことで、これを励みにより良い研究をしていきたいと思います。

受賞した研究は、複雑化した情報システムの現状を理解する活動に役立てるためのもので、私の著書の題材である文字コードとは全然関係ないのですが、ややこしくなってしまったものを解き明かすということが動機となっている点では共通しているといえるのかもしれません。

受賞者には賞状とメダルが贈られます。メダルの柄はチャールズ・バベッジのDifference Engine、19世紀のイギリスで開発された一種の機械的な計算機です。コンピュータの元祖といえばENIACを思い浮かべる人が多いと思いますが、絵になるのはこちらということなのでしょうか。

DSC01044-2.jpg

Go言語における文字列はUTF-8のバイト列を保持します。また、Unicodeの1符号位置に対応するデータ型としてruneというものが用意されており、これは32ビット整数と同じものです。他の言語でいうchar型にあたります。

Rustでも類似の形です。つまり、文字列型はUTF-8のバイト列を保持し、Unicodeのスカラー値に対応する型としてcharが定義されています。(ここでわざわざ「スカラー値」といい「符号位置」としていないのはRustのドキュメントがそうしているせいで、まあほぼ同じようなものですが、サロゲート上位下位の範囲の値を含まない点だけが違います)

こうなるとUTF-16の出る幕がない感じになってきます。今後、JavaやC#のように「文字列はUTF-16、char型は16ビット」というものから、こちらの方式へシフトしてくるのでしょうか。JavaなどはUnicodeのBMPにしか文字の割り当てのなかった頃に設計されたので、当時ならこうだろうなというのは分かります。

ちなみにRubyは文字列の内部コードはひとつのものに限定されませんが、Unicodeの使用ではUTF-16でなくUTF-8が普通なので、GoやRustと近い形といえるでしょう。ただしchar型にあたるものはありません。

発売されてから半年以上経ってようやくのことながら、当サイトに書籍『[改訂新版] プログラマのための文字コード技術入門』のページを作成しました。

今のところ簡単な案内と版元やオンライン書店へのリンクがあるだけですが、のちのち情報を増やしていくかもしれません。

同書はすでに多くの方にお読みいただいています。まだの方はこの機会にぜひどうぞ。

ばたばたしていて当サイトの更新も怠っているうちに、拙著『[改訂新版]プログラマのための文字コード技術入門』が技術評論社から発売されました!

既に書店の店頭に並んでいます。電子書籍版は数日前から先行発売されています。

近いうちに当サイトでも紹介ページを作りたいと思います。まずはお知らせまで。

拙著『プログラマのための文字コード技術入門』(技術評論社刊)の増刷が決まったとのことです。これで第7刷になります。年明け頃に出るそうです。読者の皆様はじめ、販売いただいている書店それにもちろん版元の技術評論社の皆様に御礼申し上げます。

電子書籍版もあり、PDFとEPUBが販売されています。紙の本でも電子書籍でも、お好きな方をどうぞ。

電子書籍版は第5刷がベースになっています。第7刷と違いはないはずです。

季節は年末。帰省のおともに、あるいは冬休みの自由研究に(?)、ぜひ「プログラマのための文字コード技術入門」をご活用ください。

第6刷のときとほぼ同じ文面になってしまいました。

先日テレビを見ていたら、人名の名字にJIS第3水準漢字が映っていました。

「野㞍」と画面に映っていました。「のじり」という名字だそうです。この「㞍」はJIS X 0213の第3水準、面区点番号1-47-63です。「尻」の異体字ですね。UnicodeではCJK統合漢字拡張AのU+378Dにあります。最初に作ったCJK統合漢字にはなくて後から追加されたということになります。

漢字において点の有無は別字になることもあればならないこともあります。単に運筆の調子を整えるために点を打つこともあるそうで、そういう習慣を知らないと特に意味のない形の違いで悩んでしまいそうです。今回の「㞍」がどういう経緯で成立したかは知りませんが、そうしたものの一種かもしれません。

JIS X 0208の幽霊漢字についてTwitterで興味深いツイートを見ました。

朝日新聞デジタルの記事で、JIS X 0208の出所不明の幽霊漢字「彁」らしく見える文字が大正12年の印刷物に見えたという話です。

内容について詳しくは記事(2011/09/05付)そのものを読んでいただければ良いのですが、備忘として概要をかいつまんで紹介しておきたいと思います。

JIS X 0208の幽霊漢字とは

JIS漢字コード規格JIS X 0208にはいくつか出所不明の漢字が含まれていて幽霊文字と俗に呼ばれています。拙著『プログラマのための文字コード技術入門』第3章にも説明しているので詳細は省きます。中でも55区27点の「彁」は手がかりがまるで存在しないものとして知られています。

新聞社の記事データベースでヒットした

この記事によると、朝日新聞社の記事データベースでキーワードに「彁」を含む記事がヒットしたということです。1923 (大正12)年2月23日付の朝日新聞朝刊に「埼玉自彁会」として入っていたとのこと。

リンク先には画像も掲載されています。文字がだいぶかすれていますがなるほどそのように見えます。

「彊」の誤認か

この記事で推測されているところでは、「自彊会」という言葉の「彊」の字がかすれて、データベースへの入力の際に「彁」として入力したのではないかということです。同じ記事のより良い状態の復刻版紙面を確認したところ、「彊」と読み取れたということです。画像を見ると確かに「自彊會」と見えます。

さらに記事では、JIS X 0208に「彁」が入ったのも同じ字のかすれたものを誤認したのが理由かもしれないという、ご存じ笹原宏之先生の推測を紹介しています。また、今後も同じ誤りが生じるかもしれないという懸念も示され、疑問があれば、もとの紙資料に立ち戻るべしとしています。

JISに入った理由が同じかどうかは決定的な証拠があるわけではなく推測の域を出ませんが、なかなか本当らしい説だと思えます。

(もし間違えることが多いならいっそのこと「彁」を「彊」の略体として採用するとなかなか愉快なのでは......とちょっと思いました。冗談ですよ!)

月別 アーカイブ