1569062369891-bhjjsmlkddyh3njp-lpmibtrv2k0gqujl.png1569062369891-bhjjsmlkddyh3njp-rgvdjv26k950prxv.png
Duolingo で 200-day Streak 達成。サインアップしたのは2018-08-08だが当初はあまり熱心に使っていない。200連続と同時にエスペラントの全課程を修了した。最後の方はエスペラントではなく英語の間違いや表現の差異でテスト不合格という訳のわからない状況だった。Duolingo で全課程修了と言ってもエスペラントで会話はおろかおそらく本もろくに読めない水準で、辞書を携えればボチボチと読める程度、会話は一部の単語は聞き取れるし全体の話題は推測できるが具体的な会話内容には全くついていけない。たぶん日本語で受講する英語コースも同じようなものだろう。Duolingo で学習できるのは初級レベル、せいぜい CEFR A2 程度ではないかと思う。
広告

顧問、ねえ

口入れ屋が顧問紹介サービスを展開してきたが最近は技術顧問の紹介も商業化されているらしい。パートタイム労働に顧問というよくわからないラベリングをすると単価は上がりプライドも保てるという一挙両得の商売ではある。様々な人間関係の市場化――崩壊でもある――の一端だろう。そうは言っても掃き溜めに鶴まではいかなくとも亀程度の人材でさえ相対的に供給不足だから成り立つ商売で、意味がないわけでもない。

CardDAV サーバー

先日も触れたが現状で日本人向けと思われる CardDAV サーバーは iCloud が最大手であり、これを嫌う場合は ownCloud Contacts くらいしかないように思われる。ownCloud よりも Nextcloud の方が機能的には進んでいる雰囲気だが、Contacts については t-bucchi 氏のパッチが取り込まれるよりも前にフォークしたようで、残念ながらふりがなが使えない。手元のサーバーで ownCloud は (Nextcloud も) 稼働はさせているが、試しに ownCloud のホスティングサービスを探してみた。いくつもあるのだが、oCloud.de はかなり前から目にしていたような気がするので見に行ってみると、容量 1GB の無料プランがある。ownCloud / Nextcloud はしばしば Dropbox のようなサービスと紹介されているが、そうした観点からでは容量 1GB はいかにも手狭で、無料プランらしいと言える。しかし ownCloud / Nextcloud の真価は CalDAV / CardDAV にあるのかもしれず、こちらに着目するのであれば容量 1GB はかなり使いでがある。そこで早速使ってみることにした。今まで使ってきたサーバーは大手町の某所に収容されているようだが、ここから ocloud.de へ traceroute してみると千葉→サンタクララ→ニューヨーク→アムステルダム→フランクフルトとつながり、RTT は 250ms 程度だった。それなりだが、シェルを使うわけではないので問題はない。当面無料プランで十分だが、oCloud.de は 500GB プランでも月額1,000円程度なので価格競争力もそこそこある。もちろん iCloud の 2TB で月額1,300円には到底及ばないし、ホスティングだから構成の自由度も低いのだが、代替手段としては検討の余地があるだろう。

ownCloud

iCloud 以外で日本人のアドレス帳をまともに扱えるのは現状では ownCloud だけか。ぷちのいず氏 petit-noise.net がふりがな対応の pull request を出してくれたおかげだ。大いに感謝しつつ ownCloud ホスティングサービスを探すと、確か老舗の oCloud.de が無料ホスティングをしている。容量1GBだが家庭内でカレンダーやアドレス帳を共有する程度なら問題ない。ファイルサーバーとして使うなら100GB程度は欲しいがそれでも€6.9/moで悪くはない。

oCloud.de は Nextcloud も同じように提供している。今や Nextcloud の方がビデオ会議まで可能と明らかにできがよいのだが、ふりがなだけは如何ともし難い。

Zoho Sheet オンラインシートビューアと使い捨てシートの作成

Zoho が オンラインシートビューア という面白いサービスを始めていた。

ビューアと名乗っているが編集が可能であり、編集後のワークブックを .xlsx, .xls, .ods, .csv, .tsv, .pdf, .html でダウンロードできる。「使い捨てシートの作成」というボタンもあり、Zoho にアカウントを作成することなく Zoho Sheet の機能をほとんどすべて利用することができる。ざっと見たところ、共有機能と VBA マクロ/カスタム関数機能は使えないが、条件付き書式やピボットテーブル、ソルバー程度までは使えるようで、WPS Office Sheets 程度の機能はある。フォントは Windows での定番はカバーしている。日本語では MS 明朝, MS P明朝, MS ゴシック, MS Pゴシックが使える。

クラウド型のスプレッドシートといえば Google Docs のそれを一般的には思いつくだろうが、あちらは独自色がかなり強いのでオンプレミスの Excel と行き来しながら運用するのは辛い。

Zoho Sheet は Microsoft Excel との互換性が非常に高く、WPS Office に次ぐ。いわゆるクラウド型のスプレッドシートの中では最も高いと言ってよい。OS を問わず VBA マクロまで対応可能である。クラウド型であるから共有機能も充実している。マイナーであることだけが問題だが、実は Zoho はさほど小さな企業ではないのでサービスの継続性にも不安はない。もう少し盛り上がってほしいところだ。

ただし、なぜか登録ユーザーの Sheet では 日本語フォントが Noto Serif CJK JP のみとなる。これはいただけない。

統計偽装は何が問題か

統計不正問題はなぜ起こった?世界と比較すれば分かる「最大の元凶」
(ドクターZ 2019.02.03 現代ビジネス) https://gendai.ismedia.jp/articles/-/59612)

という記事があった。要約すると次のようになる。

霞が関の統計に対する信頼が揺らいでいる。統計職員はここ15年で大きく減少し、先進各国に遅れを取っている。各省の減員幅を調整できないのは縦割り行政のせいだ。霞が関では文系官僚が跋扈し、彼らは数学の素養を要する統計を軽視している。スペシャリストの理系は出世できない。厚労省では医師の技官は局長止まりで統計ユーザーとしての能力が発揮されない。年金数理を扱う技官も縦割り行政のため旧労働省では活用されない。統計事務はさほど専門性のないノンキャリが担う結果、日本の統計業務は世界的に見劣りする。今回の不祥事は縦割りと人員・報酬カットのせいだ。

ドクターZという筆名(プロフィールにほぼ何も書いていないので実質は匿名だ)で適当なことを書いているものだ。日本で統計の地位が低いことは事実だろうが、いま問題となっている統計偽装は、理系だの数学だのという水準の問題ではない。官僚が適正手続を無視しているという問題だ。文系理系など噴飯ものの議論で、人員・報酬カットで水準が落ちたというのは倒錯した理解だ。日本ではデタラメな思いつきと派閥争いと集団思考で前提データなしに結論が先に決まり、その結論を正当化するための理論が捏造され、その理論に従ったデータが集められる。戦前もそうだったし、ここ20年ほどの劣化した政府でもそれが行われてきた。その程度の重要性しかあらかじめ与えられていない統計だからこそ、人員・予算が削減されてきたのである。人員や報酬を充実させても、日本政府あるいは日本人が右のようなデタラメな意思決定を続ける限り、統計の水準は下がることはあっても上がることはあるまい。また、官僚が適正手続を無視するというのは民主主義に対する重大な挑戦であって、テクニカルな是正が可能であるかのように語る人がいるとすれば、それは問題の隠蔽と改善と称する焼け太りを招くだけであろう。

鬼門:フリガナ

ownCloud から Nextcloud への移行を進めている。いつも面倒なのがフリガナだ。ownCloud のアドレス帳アプリ (Contacts/OC) は t-bucchi 氏の仕事 https://petit-noise.net/blog/phonetic-name-patch-is-merged-by-owncloud-contacts/ の恩恵に与り感謝に堪えないのだが、Nextcloud のアドレス帳アプリ (Contacts/NC) では残念ながらフリガナを扱えない。まったく細かいことなのだが、極東特殊民族語にはずっとついて回る話だ。アプリの中を覗いてみたがだいぶ構成が変わっているうえ、自分は PHP や JS を使いつけておらず、それなりに手間取りそうである。

vCard は1995年に策定されたらしい。最新の規格は vCard 4.0だ。ライブラリーは Sabre/DAV などいくつかあって、4.0もサポートしている。しかしどうもアプリケーションレベルでは3.0サポートが精々のようだ。Contacts/OC のフリガナ対応も X-PHONETIC-* を用いている。

もともと、フリガナは規格に入っていない。日本では携帯電話 (ガラケー) の普及に伴いアドレス帳の交換が必要になり vCard が広く利用されるようになったが、日本人にとってはフリガナはとても大切なものであるから、各社知恵を絞った (だろう) 結果、SOUND プロパティーに格納するようになった。これは元来 μLaw などの音声データを格納するためのものだ。ふりがなと発音は異なる概念である。ガラケー業界はここにシフトJIS (正確にはたぶんコードページ932) の文字列を格納した。まだ Unicode は規格として未成熟だったからだろう。後にスマートフォンの普及に伴って Unicode (の記述方式である UTF-8) が一般的になっていく。これと前後して vCard 3.0では SORT-STRING プロパティーが用意された。RFC には “To specify the family name or given name text to be used for national-language-specific sorting of the FN and N types.” とある。特にフリガナ用ではなく、どんな氏名表記体系であっても整列用の別途の表現を収容するために用意されたものだ。これもまたフリガナではなかった。vCard 4.0では SORT-AS パラメーターが設けられ、複数の整列キーを使えるようになった。これはこれで進歩だったが、すでにApple が X-PHONETIC-FIRST-NAME, X-PHONETIC-LAST-NAME を使っていて、目下これが事実上の標準となってしまっている。

vCard 4.0のサポートを明示しているアプリケーションは意外に目にすることがない。Thunderbird + CardBook のほか eM Client が4.0対応という話もあった。実際に eM Client で vCard を出力してみると、vCard 4.0ではあるようだがフリガナは X-PHONETIC-* で表現されている (追記: というのは誤りで、eM Client はふりがなを扱わないものの CardDAV / VCard から取り込んだデータの X-PHONETIC-* を破壊しないということのようだ)。 SORT-AS は N;SORT-AS=”{surname}, {givenname}”:{surname};{givenname};{middlename};{prefix};{postfix} のように用いられている。まさに整列用で正しいのだが、フリガナとしては使えない。結局、市場の多くで vCard 3.0 + X-PHONETIC-* が使われている模様である。

Sabre/DAV のドキュメントには次のような記載がある ( http://sabre.io/dav/building-a-carddav-client/#retain-full-vcards%21 ):

Our recommendation

  1. Download the vCard
  2. Retain the entire vCard and store it locally, or at least in some lossless way
  3. Parse the vCard and populate your models with the information that is relevant to you.
  4. Keep a reference to which vCard property maps to what information in the model.

これを遵守しているのか、Contacts/NC も自身が知らない X-PHONETIC-* を破壊せずにおくようだ。CardDAV サーバーとしての運用には堪えられる。