核分裂からエネルギを取り出すには、水に転嫁して蒸気タービンを回したり、熱電変換素子 (ゼーベック効果・アルカリ金属熱電変換を問わない) を利用して電気にしたり、放射線で蛍光体を励起させて光にする方法などがある

@atsushi015 ディーゼルエンジンで発生した機械運動を発電機にぶち込み、発生した電気をモータに供給する電気式ディーゼル動車と言うのもありまして.... まあそれを電車と言うのか気動車と言うのかという微妙なところはありますが

上野御徒町駅のツーリストインフォメーションセンター問題とは、本来外人旅行者向けの旅行案内所なのに、何を思ったのか案内板にはカタカナで大書きにしてアルファベットを小さく添えるという原則通りの対応をしている、誰が対象者なのか案内などにちゃんと反映されていないという問題である

このアカウントは、notestockで公開設定になっていません。

そしてコミケカタログで発生している同問題とは、これである。日本語ページの見出しの注意書きが日本語なのはいい。だが英語や繁体字、簡体字やハングルといったページにおいても注意書きが日本語の大書きと英語の小書きという組合せとなっており、本質的には上野御徒町駅のツーリストインフォメーションセンターと何ら変わらないように感じる
https://www2.comiket.co.jp/info-a/C96/C96CtlgNotes.pdf

どうでもいいんですが、コミケカタログの繁体字と簡体字とで表現が全く違うのがおもしろいよね。英語もイギリスとアメリカとで表現の違いがあるけど、ぱっと見でここまで大きく表現を変えてくるってこともないだろうし

@yakumo ちゃんと2.6GHz, 3.2GHz対応の同軸ケーブルを使おうね

このアカウントは、notestockで公開設定になっていません。

うらやま死刑なので死にたいです

"ベロベロに酔ったお姉さんに金よこせって絡まれてリアルに身の危険を感じたので大人しくポケットの千円差し出したら｢素直で偉いぞ～｣って頭撫でられて五千円貰った(？？？？？？？？？？？？？？？？？？？？)"
https://twitter.com/Hirochi_K99/status/1157303289353887744?s=19

@yakumo だってアルミ巻いたら改善した訳じゃん?

@yakumo ケーブル外皮に書かれている規格について確認だ! (S5C-FBなど)

同軸ケーブルの種類と解説-Asahi Satellite Page http://www.satellite.co.jp/coaxial-cable.html

@Kaedeojisan 今年度は金離れが悪いのでダメです

@Kaedeojisan んなもん自分で用意せえ

このアカウントは、notestockで公開設定になっていません。

個人的には逆に、DMの返信がHTLに現れなくなり、トゥートすべてをフラットに扱った上で公開範囲で規制するという思想がゆがめられたな、という感じがしている https://social.mikutter.hachune.net/@charsiuCat/102557178770095815

スタバの前に居ます (解る人の方が少ない)

京急電鉄の大規模分譲マンション〈全200邸〉プライム上大岡の広告、一見まともだけどおかしなところが一つある。それは上大岡駅からの距離が、地下鉄からの方が大書きにされていることだ (改札の位置を立体で考えず、平面で考えてません?)

メディア・ル・トランで映像付きの油壷マリンパークのCMが流れていたあの時代

京急油壺マリンパーク https://youtu.be/Ra-cNBOAS0o

京急キッズファンと京急キッズランドとでは、対象年齢 (前者が学童、後者が保育園) だけじゃなくて運営会社 (前者が京急開発、後者が京急サービス) まで違うんですよ

ご指摘はごもっともだが、このような世界は作りたくないと感じている。理由は以下の通り
・同じ名前のツールでローカライズされている場合の取り扱い
・開発の国際化が困難になりかねない
・開発者の慣れ

「プログラミング＝英語」という状況は正しくない。多言語でコードを書ける世界が求められている https://wired.jp/2019/08/04/coding-is-for-everyoneas-long-as-you-speak-english/

・同じ名前のツールでローカライズされている場合の取り扱い
これは例として挙げられたExcelの数式が、格言語間で標準ライブラリ機能名が違うときのいい例で、違う言語のExcelで開いたときにその数式がちゃんと計算されるのか、そして式を変更したときに他言語版の関数が編集時の言語に変換される、ないしは言語間で衝突せずに混用できるのかという問題が残る。これは一般のプログラミングにも言えて、標準の変数・メソッド・クラスなどが言語間で衝突しないかどうかという問題だけでなく、自分で作ったモノが外国語と衝突しないかと注意深く確認しなければならなくなって面倒と言えば面倒である

・開発の国際化が困難になりかねない
現在は書き言葉としてラテン語を用いていた時代とは異なり、文書の交換がインターネットをはじめとする電気通信回線によって瞬時に行われる時代である。この性質を活かしてプログラムのオープンソース化を図り、開発の多国籍化・多人数化や、高速化をしており、仮にプログラミング言語を母国語化してしまうとプロジェクトごとの分断が起きてしまい、車輪の再発明が多発することとなる。そうでなくとも別の母語で作られたプロジェクトに貢献する場合、現在は英語だけで済んでいたのがさらに多くの言語を学ばなければならないという話になってしまう。

・開発者の慣れ
英語にある程度慣れた、英語以外を母語とする開発者が、いまさら母国語でのプログラミングをしたいか?という疑問がある。少なくとも僕はやりたくない。そして同時に "開発の国際化が困難になりかねない" でも触れたように開発者の分断が起こるがゆえに標準ライブラリの整備が進まず、結局ある程度のことを超えたら母語プログラミング言語ではプログラムを開発できなくなり、初学者者にそれを奨めない・奨められないという事態になりかねないという話になる。

補足事項として追記しておくと、C# やVB6では日本語変数名などが一応サポートされているらしく、それを使った開発も可能である。しかしだ、様々な標準クラス・メソッドが直接入力モードで入力できる文字の英語で用意されているのに、わざわざ日本語入力モードにした上で誤変換などに気を使って日本語で命名したいかという疑問がある。少なくとも僕はやりたくない (Part 2)。そして中国語圏などの、日本語同様に入力と文字が一対一に対応しきれない言語を使っている言語圏の開発者もやりたくないんじゃないの?と想像する

各言語でライブラリに関わるドキュメントを用意しろというのには同意する。日本語の翻訳を機械翻訳を基本としたMS、許さんぞ (人力翻訳も訳がおかしいというツッコミは無視する) https://mastodon.cardina1.red/@lo48576/102559171995353396