配置は「い16」です。新刊は、技術系よろず(？)同人誌「ElectroComplex」2号（￥300）です。内容は創刊号に引き続き記事1本で、電子工作の製作例紹介となります。特殊なMOSFETを使用した無電源AMラジオについて解説します。
既刊（創刊号）については、￥300 ==> ￥200 で頒布します。在庫は（前回の頒布数から予測すると）十分にある予定です。
line-height は相対指定しよう、というサンプル
他のCSSとの相互干渉を避けるため、個人のウェブスペースに置いてあります http://metanest.jp/lineheight.html
PCを別のケースに入れ替えた話
先代の Antec P182 が、先日の分解清掃の際にフロントパネルの爪をいくつか折ってしまったりなどだいぶ老朽化した感じもあり（また、マザーボード取付部にメンテナンスホールが無いなど設計も古いので）、新しいケースに入れ替えることにしました。ケースには SilverStone SST-FT02 を選びました。
発売からそれなりに時間が過ぎていることもあり、流通状況はあまり良くありませんが、オークションに出るのを待つなどしなくても通販系のショップなどにたまに入荷するようです（ただし、異常に高額で売ってる店もあるので注意）。FT02 と RV02 の、マザーボードの90度回転配置と（通常の配置では後部になる側が、上部になる）、左右が逆の配置（マザーボードを右側面ではなく左側面に取り付ける）は、同様のものを他に見ないユニークなもので、しばらくはこのケースを使う予定です。
1枚目の写真ですが、組込み前にファンを全て換装しました。下部の3連180mm吸気ファンは SST-AP181 から AP182 に、上部の120mm排気ファンは Noctua の風量特化型ファン NF-S12A を付けています。AP182 は可変範囲が広く、また可変範囲であれば任意の速度に設定できるので、冷却重視にも静音重視にもベストの選択かと思います。ボリュームのつまみをいったん外す必要がありますが、ケースの元々は速度設定スイッチがあった場所に同じネジで取り付けできます（LとHのマークが逆になりますが。あと配線の向きが合わないので、周辺と干渉するのを避けるために曲げざるをえませんが、その際に端子を折ってしまわないよう注意）。
また排気ファンは、吸気をメインとする「正圧」がコンセプトの SilverStone のケースでは、正常動作中であれば静圧は必要ないわけですから、やはり風量特化型ファンがベストの選択かと思います。
CPUクーラーです。メーカーの公称では165mmまでとなっていますので、Cryorig のハイエンドクーラーなどでなければたいていは入るでしょう。Noctua NH-D15 がやはりちょうど公称165mmです。
こちらのクーラーは、別のパーツの店頭在庫がありそうだった店に偶然に残っていた、サイズの「無限 大」（Mugen Max, SCMGD-1000）を、SST-FHP141 のデュアルファンにしたものです（こちらも現在、かなり流通が細くなっていますが……）。ちょっと特殊で38mm厚のため、25mm厚ファン用クリップで取付けられるよう、長さ28mmのスペーサーを加工してクリップ取付用の台座にしています。まぁはっきり言って無駄なこだわりですので、普通には、このファンを挟むようなほぼ専用の設計と言える SST-HE01 を使えばよいでしょう。HE01 であればトリプルファン化も可能ですし。
組み込み後の写真です。電源の部分のパンチングメタルは、かなりでかい（長い）電源でないと位置が合いませんので、たいていの場合、電源の吸気はケース内側からにせざるをえないかと思います（あるいは正圧設計を活用してファンレス電源を組み合わせるのも良い手かも。SST-NJ600 が出るのを待ってるんですが……いつ出るのやら）。狭い設置場所で無理に撮影したため（ライカ判に換算して14mmのレンズ）、不自然に奥行きが強調された、不動産屋のイメージ写真のようになっていますが、全体の感じはだいたいつかめると思います。
技術書典に申し込みました
「IME文節」という謎のジャーゴンについて
はじめに
日本の仮名漢字変換関連の某システムの一派の方面が発信元のようですが（その集団ないし個人を糾弾することが目的ではないので、ここでは明示しませんが）、「IME文節」という謎の（良くない）ジャーゴンが広まっているようですので、注意喚起の意図で本稿を書きます。
結論
それは、「複合語」や「接辞」や「造語成分」などに関する処理ではないですか？ そうであればそのまま、例えば「複合語の分割と変換」などのように表現すべきです。
なぜ「IME文節」などという表現がされるのか
検索で見つかるいくつかのウェブページや資料などから、私が推測した所では、以下のような理屈により「IME文節」という概念が必要だと思われているようです。
(1) 日本語の文法では、文は以下の BNF のようになっている（ここでは句読点等は除いて考えている）。
<文> ::= <文節>＋ <文節> ::= <自立語> <付属語>＊
ここで、自立語とは名詞や動詞だから、仮名漢字変換としては、活用語尾などへの対処は必要であるが、辞書を引いて対処することになる。（付属語についてはたいていはひらがなであり、ここでは考えない）
(2) しかし実際に変換の対象となる文には、「電子情報通信学会定時社員総会において」というような、1語として辞書に用意するのはありえないようなものもよく出てくる。
(3) なので実際の仮名漢字変換では、ここで示したような日本語の文法によるものよりも細かい分解が必要である。
(4) そこでこの、仮名漢字変換で必要な分解の単位を「IME文節」と呼ぼう。
という感じのようです。
どこがどう問題か
前の節で示したうちの、(3) までは問題ありません。問題は (4) です。「IME」という表現が含まれていることから、広まったのは1990年代後半以降であることは確実でしょう（ただしもっと古くから同様な考え方がされていた可能性はあります）。
しかし、そのような自然言語処理の手法はワープロにおいてもっと以前からちゃんとあったものです。仮名漢字変換を実装して出荷されたものとしては最初のワープロである東芝 JW-10 他は、1980年前後のものですから、当然「IME」という語が広まるよりも古いですが、このような「辞書に無い自立語」のことはちゃんと考えて作られています。研究所で研究開発を担当され、JW-10モデル1を設計された天野真家先生が著者に入っている学会発表で「局所意味分析」といったような語が題ないしアブストに入っているものがありますが*1、それが、JW-10モデル1における、これに相当する処理で、後述する「接辞」としての扱いに近い形ですが、このような自立語の処理の実装の報告となっています。*2
そういったように、日本において実用的な仮名漢字変換が最初に実装された時点で考慮されていたものであり、また以降で述べるように、言語学的にも以前からきちんと扱われていたものを、ワープロのような自然言語処理でも扱うようになったものに過ぎませんから、あたかもIMEにおける特異な現象であるかのようなジャーゴンを与え、その名で呼ぶのは不適切です。
国語学的にはどうなのか
ソシュールや*3チョムスキー以後の言語学がとり入れられた現代の日本語文法学を持ち出すまでもなく、橋本文法の解説などにも*4、以上で説明したような「自立語よりも細かい単位」について、実際にはきちんと言及はあります。*5
橋本文法の原典『国語法要説』は、流石に参照はたいへんですが（というか私も見ていません）、山口明穂編『国文法講座 1 文法の体系』（1987）であれば、公共図書館での取り寄せはそんなに難しくもないと思います（CiNiiで見たところ、大学図書館への所蔵で200件以上あります）。それを読むと、より細かい単位について、以下のようなことが書いてあります。
（要約）さらに細かくできそうなものとして、「本箱」や「酒樽」といったような複合語は、「本」と「箱」、「酒」と「樽」といったように分解できるが、分解されたそれぞれは部分にしかなっていない。また、付属語の他に、「お山」の「お」のような接頭辞などの接辞もある*6。
また、古くからあるいくつかの仮名漢字変換システムにおいても、このような語のために、入力の扱い方を変えるモードのようなものとして「複合語変換」というような名前の機能を持っていたり、マニュアル内で「造語成分」といったように説明されていたりします。
まとめ
まとめると、そもそも「文節」ではなく、ちゃんと「複合語」や「接辞」という専門用語があるものを、単に仮名漢字変換において切り分けが必要だというだけで「IME文節」などと呼ぶのはあまりに雑であり、やめるべきだろう、ということになります。
完全に余談
以上の議論では全く触れていませんので（意図的です）、あたかも「文節」というものは、国語学において、橋本文法における文節として自明と言ってしまってよいほどに確かなものと扱われているように思えるかもしれませんが（あるいは、学校の国語の授業ではそのような前提があるかの如く教授されているかもしれませんが）、そんなことはなく、かの水谷静夫先生ですらおおいに悩まされたという話が『国語学五つの発見再発見』（創文社版 p. 107 脚注12）にあります*7。
*1:他、いくつかの講演資料のようなものにも見つかる。
*2:詳細には、「だいいっかい」→「第一回」のような変換において、「第」と「回」には関連があるから、というような話なのですが、「第一階述語論理」が例外だ、というのが「自然言語処理」の講義では余談(？)でした。
*3:「四大文法」のひとつ、時枝文法にはソシュールの影響がある（批判的だとも、誤解であるとも言われているようだが、ともかく影響があったということはそうだろう）。
*4:いわゆる「学校文法」のベースが橋本文法であるということは事実ですが、義務教育で扱っていることが橋本博士の文法の全て、などというわけはありません。
*5:ましてや、書店にはむしろそちら側の本しかないというような状況の、俗説の入り込む隙などは全く無い。
*6:「付属語と接辞の違いは、根本的なものでなく程度の差に過ぎない」ともあって、これはちょっとわからないのだが……。
*7:国研での用語調査の際の集計対象を文節としたので……といったような話。
「トロン―国産ＯＳが世界標準になる」とかいう見出しの記事について
結論
いつものアレなのになんで今回はこう騒ぎになってるの？
事実関係
2017年11月のニュースとして、μT-Kernel（従来のμITRONにおける小さめのプロファイルに相当）を、IEEE標準の「2050」にするために、著作権の移管などがあった。（IEEE 754（浮動小数点）とかIEEE 802（LAN）などと同様なワーキンググループのひとつ。他にどういうものがあるかは http://standards.ieee.org/develop/project/computer_technology.html で見られる）
この件に関する情報としては、
- IEEE Standards Association からの発表 http://standards.ieee.org/news/2017/ieee_tron.html
- トロンフォーラムからの英語記事 http://www.tron.org/blog/2017/12/ieee-standards-association-ieee-sa-and-tron-forum-sign-agreement-to-advance-iot-development-and-interoperability/
はあるが、日本語でちゃんとした内容を伝えるものは、なぜか（いつものことだが）出ていない。
今後何が変わるか（予想）
以下の内容は私の予想だが、そう大きくは外れないだろう。
結論としては、何も変わらない。
例えば ISO/IEC 14576 (STbus) は、元はTRONプロジェクトで開発されたTOXBUSであり、「TRONプロジェクト発の世界標準」のひとつだが、それで何が変わっただろう？
IEEE P2050のページ（ http://standards.ieee.org/develop/project/2050.html ）の右の「PAR」（Project Authorization Request）と書かれている所にあるPDFに、プロジェクトのスコープやミッションなどが書かれているが、要するに、今あるμT-Kernelの仕様書をレビューし、IEEE標準のひとつとする、ということだけしか書かれていない。つまり、μT-Kernel以外の、（μでない）T-Kernelをはじめとするその他のTRON全てについては、全く無関係な話でしかない。
また、最も強く懸念されることとして、以前の（1.0の頃の）ITRONの仕様書がそうであったように、1万円以上の価格で購入しない限り、仕様を見ることができなくなるかもしれない、という点があるが（実際に現状で「IEEE P2050 IEEE Draft Standard for Real-time Operating System (OS) for Small-scale Embedded Systems IEEE P2050/D2, October 2017」を入手するには、268ドルで購入する必要がある）、2017年のうちに移管されている（はずである）μT-Kernel2.0の仕様が、2018年4月現在、英日版とも、tron.org のウェブページから閲覧可能であることから（単に更新されてないだけにも見えるが）、もし、著作権の移管により見られなくなるものならば、現状がそれに違反していることになるので、恐らく問題ないものなのであろうと、強く推測される。
その他
坂村先生の風呂敷はいつものことだし、アンチが「Linuxという世界標準があるのに」とか意味のわかんないこと言うのもいつもの後継なんですが、なんで今回はこんなにバズってるのというか。読売新聞効果ですかね？
先生の威勢のいい談話が出るのは結構ですが、教育用キットT-Car（リンク先画像 http://ascii.jp/elem/000/001/089/1089654/img.html ）とか出るんですかどうなんですか。
TypeScriptにおけるobject typeのunionの、あまり期待されてないのではないかと思われる挙動について
結論
Discriminated Union （ http://www.typescriptlang.org/docs/handbook/advanced-types.html#discriminated-unions ） を使おう
サンプルコード
'use strict'; type A = { a: string } type B = { b: number } type C = { c: boolean } type T = A|B|C const v1: T = { a: '1', b: '1', c: '1' } const v2: T = { a: 1, b: 1, c: 1 } const v3: T = { a: true, b: true, c: true } const v4: T = { a: false, b: '0', c: 0 }
何が「期待されてないのではないかと思われる挙動」なのか
ここで（v4ではエラーになるのはともかく）、v1〜v3に代入している値は、型 A, B, C のどれにも代入できないにもかかわらず、それらの union である A|B|C 型には、コンパイル時のエラーにならず、代入できてしまう。これは、（静的な）強い型付けを期待しているプログラマの想像に、多分、反している。
仕様ではどう言っているのか
仕様 （ https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md ） では（以下、2018年4月現在のバージョンである Version 1.8 を前提とする）、§3.4 Union Types に、次のようにある。
A type T is assignable to a union type U if T is assignable to any type in U.
(訳: 型Tの値は、union型Uに、Uのどれかの型に代入可能である場合に、代入可能である。)
ここで、次のようではないのは意図的なものなのではないか、と思われる。
***NOT*** / A type T is assignable to a union type U if and only if T is assignable to any type in U.
(訳（こうなってはいない）: 型Tの値は、union型Uに、Uのどれかの型に代入可能である場合、かつその場合に限り、代入可能である。)
つまり、このあたりの挙動については、型によって安全を保証することを諦めている（のではないか）と思われる。理由としては、最初に結論として述べたように、Discriminated Union を使えば、こういった問題は避けられるからである。
想像される実装
以下は tsc の実装を読んだわけではなく、いくつかの例で試した結果からの想像である。
複数個の object type のある Union型 U への object 型 T の代入可能かのチェックでは、
- まず、 T の属性名の中に、U の型のどれにも現れない属性名がないか確認する。どれにも現れない属性名があったら代入できない。この時、その属性の名前のみがチェックされ、型はチェックされない。
- 次に、U の型について、左から順番に、T が代入可能かどうかについて試してゆく。この時、通常の代入可能のチェックとは異なり、T の側に属性が余ってもエラーにはしない。
