現在、日本語ではいくつかの異なるIMEが利用されています。^[1]
主要なIMEには、いずれも独自のかな漢字変換を登録できる「ユーザ定義辞書」（名称は様々）機能があり、辞書のインポート/エクスポートが可能です。

そのため、複数人/複数デバイスで辞書を共有したり、IMEを乗り換える際に辞書データを引き継いだりすることができます。
しかしながら、各IMEは独自の辞書フォーマットを持っており、 複数のIME間で辞書資源を再利用するのは一筋縄では行きません。

しかも、 MS/Googleの2大主要IMEがファイルの正確な仕様を整理された一次情報の形で公開していない雰囲気でした。（あまりよく調べていないので、あったら教えてください。）

この記事では、主要なIMEの辞書フォーマットについて調査し、どのフォーマットが他のIMEで使用できるかをまとめます。

ここでは、主要なIMEとして、以下を対象とします。

• Microsoft 日本語IME (Windows)
• Google 日本語入力
• ATOK
• macOS 日本語IM (旧 ことえり)

ちなみに、MacOSでは日本語IMとは別にText Replacement機能でも辞書登録が可能です。こちらはplist形式で保存されており、また話が変わってくるので割愛。

これとは別に、SKKの事情も調べたかったのだけれど、闇が深いようでよくわからない ので 今回は見送り 。

卒業研究の中間報告の提出期限が迫るなか、どうしても個人的な興味で調べたくなったところで調査したものなので、あまり筋の良い出典に当たれていない点はご容赦ください……（よくわからない個人ブログに基づく情報が多分に含まれます）

#結論

#詳細な仕様

#Microsoft 日本語IME

１次情報がよくわからなかったのだけれど、こういう記事を見つけた。

• デフォルトの拡張子は .txt
• フォーマットはタブ区切りテキスト

形式:

かな    変換後    品詞    コメント

品詞は、以下があるようです。比較的fine-grained。

#Google日本語入力

こちらもよくわからないのだけれど、こんな記事 を見かけた。

それから、OSS版であるところのMozcのユーザ定義辞書インポート部分を読むと、まあまあ分かる。

• デフォルトの拡張子は .txt
• フォーマットはタブ区切りテキスト
• 文字コードはUTF-8 BOMなし

形式:

かな    変換後    品詞  コメント

品詞の一覧は、以下らしい。

#ATOK

ATOKの辞書フォーマットは、公式ドキュメントがわかりやすいです。

• デフォルトの拡張子は .txt
• フォーマットはタブ区切りテキスト
• 文字コードはShift_JISが標準, オプションでUnicode（UTF-8?）も可^[2]

形式1(必須項目のみ):

かな    変換後    品詞

形式2(オプション項目を含む):

かな    変換後    品詞    コメント  自動置換する/しない 置換候補1 置換候補2 ... 置換候補5

非常に整った品詞の一覧があります。
また、()内に示した番号でも指定できるのが特徴的です。

#macOS 日本語IM

公式ドキュメント があります。さすがApple。

• テキストファイル
• ASCIIカンマ区切り

形式1(コメントなし):

かな,変換後,品詞

形式2(コメントあり):
コメントの前のカンマが2つ連続である点が特徴的。

かな,変換後,品詞,,コメント

品詞の一覧も公式ドキュメントにあります。かなり貧困。

部品箱から、大昔に買ったLPC810がたくさん出てきた。

LPC810というのは、「8ピンARM」などと称していっとき話題になった、
NXPのARMマイコンで、多分流行った頃に買ったのだと思う。

8ピンの小さなパッケージにもかかわらず、ARM Cortex-M0コアを搭載した32bitマイコンであるということで話題になったものと思われる。当時はmbedも全盛期だったはずで、mbedのオンラインコンパイラを使った開発例もしばしば見かけた。

今となってはもっと良いマイコンがあるので積極的に設計に採用しようとは思わないものの、この在庫分に関しては、せっかくなのでなんとか料理してやりたい。
しかしながら、電子工作界隈でのLPC810に関する記事は流行当時のものばかりで、そもそも2025年にはどうすればプログラムがビルドできるのかすらよくわからなかった。

そんなわけで、何とか調べてLチカまではできるようになったので、その備忘録を残しておく。

#方針

普通のARMマイコンなので、究極的にはARMのコンパイラを持ってきて、データシートを読みながらリンカスクリプトを書いてビルドしてやればいいのだろうが、流石に面倒なので、できるだけ高級な（と言ってもプログラムメモリが貧弱なのでそこまで強力な抽象化ができるわけではないのだが）ツールを使おうとしてみる。

#プログラムのビルド

流行当時の記事をみると、mbedのオンラインコンパイラを使っている例と、LPCXpressoを使っている例がある。

mbedのオンラインコンパイラは、mbedのサービスが終了してしまったので使えない。その後の後継サービスもあるようだけれど、そもそもプログラムメモリが大きくはないので、mbedを使うくらいならもう少し薄い環境でやりたい。(RoboCup Juniorをやっている時にmbed 5を使っていたが、あれは結構デカい)

そういうわけなので、LPCXpressoを使ってみる方法で行くことにする。
しかし、実はLPCXpressoもソフトウェアとしてはdeprecatedらしい^[1]。

そういうわけで、その後継のMCUXpressoを使ってみることにする。

#MCUXpressoのインストール

無料。やるだけだった。MCUXpressoのダウンロードページからダウンロードして、インストールするだけ。 STとかだとこういうツールがWindowsだけというのはありがちだが、Macでも普通に使えた。

#プロジェクトの作成

1. MCUXpressoを起動して、新規プロジェクトを作成する。

• [File] → [New] → [Create a new C/C++ project]
• Preinstalled MCUsからLPC810を選択。
• ボードは選択せずにNext

2. ウィザードの選択

• “C++ Project” を選択してNext.^[2]
• "LPCOpen"とかいうウィザード群もあって、こっちの方が新しいらしいのだけれど、私の手元では上手くいかなかったので、一旦LPC810向けのLPCOpenライブラリはなさそうなので、LPCOpenではない方(CMSISというライブラリ群らしい)を選択する
  • これを書いてから、独自開発ボードのMCUXpressoプロジェクト作成方法 - IoT MCUのHappyTech という記事を見つけた。これならいけるかも。 LPCOpenの方がライセンス周りがクリーンなので、できるだけLPCOpenを使うべき

3. プロジェクト名の設定

• ここではLチカなので"blink"にしておきました

4. ライブラリの設定

CMSISライブラリを選択する。たぶんここでハードウェアごとの設定を指定するようになっているのだろうと思われる。
私はNXPのマイコンはマジで初心者なので、合ってるかわからん。
MCUとしてLPC810を選択していれば、それぞれ一択になるはずなので、選択できるものを選択する。

5. DSPライブラリの設定

DSP(Digital Signal Processing / ディジタル信号処理)に使う高級な関数群を使うかどうかの設定。
基本は使わないのでいいはず。デカいので、不要なら無視してNextでいいはず。
高速フーリエ変換とか使いたい場合は使うといいのかもしれないが、使ったことないのでわからん。

6. MTBの設定

Micro Trace Bufferを使うか、使う場合はどのくらいの容量を割くかの設定ができる。
こんなことをしているとメモリがすぐに足りなくなるので、使わない。

7. CRPの設定, C++の設定

MTB同様、無視していく。

8. プロジェクトの作成
   Finish.10秒くらいかかった。

9. post-build stepsの設定
   このままでもビルドはできるのだけれど、これだとaxfファイルしか生成されないので、binファイルを生成するように設定する。
   [Project]→[Properties]→C/C++ Build → Settings → Build Steps の中にある、Post-build stepsに、コメントアウトされた部分があるので、アンコメントしておく。

#プログラムの実装

今回はポート2(4番ピン)でLチカする。
blink.cppを以下のように書き換えた。

#ifdef __USE_CMSIS
#include "LPC8xx.h"
#endif
#include <cr_section_macros.h>

#include "lpc8xx_clkconfig.h"
#include "lpc8xx_gpio.h"

volatile uint32_t msTicks = 0;
volatile uint32_t power=0;


void SysTick_Handler(void) {
	msTicks++;
}
void systick_delay (uint32_t delayTicks) {
	uint32_t currentTicks = msTicks;
	while ((msTicks - currentTicks) < delayTicks);
}

#define LED_PIN 2

int main(void) {

    // Clock configuration
	SystemCoreClockUpdate();
	SysTick_Config(SystemCoreClock / 1000);

	LPC_SYSCON->SYSAHBCLKCTRL|=(1<<6); // Provide clock to switch matrix
	LPC_SWM->PINENABLE0|=(1<<3); // Enable fixed pin function PIO0_2
	LPC_GPIO_PORT->DIR0 |= (1 << LED_PIN); // Set LED_PIN as output

	while(1) {
		uint32_t current = msTicks;
		LPC_GPIO_PORT->NOT0|= (1 << LED_PIN); // flip LED
		while(msTicks<current+1000){ // wait 1s
			asm volatile ("nop"::);
		}
	}
	return 0; // unreachable
}

#ビルド

上のハンマーのボタンか、Cmd+Bでビルドできる。

#書き込み

書き込みには、USB-シリアル変換回路を使う。
以下のような回路が必要。

私は、LPC810書き込み装置 | 電脳伝説を参考にして、以下のようなボードを組んだ。

実験する分にはブレッドボードに直に組んでしまえばよいと思う。

回路ができたら、書き込みにはlpc21ispを使う。

Windows向けにはFlash Magicなどのより高級なツールもあるらしいが、Macで使えるのはこれが一番安定している感じがする。
先ほどビルドしたプログラムは、プロジェクトディレクトリ下のDebug/blink.binにビルドされているので、これを使って書き込む。
（リリースビルドだとRelease/blink.binになる）

ISPボタン(SW2)を押しながらリセットボタン(SW1)を押すことで書き込みモードに入る。

lpc21isp -bin blink.bin -control /dev/tty.usbserial-0001 115200 12000

• /dev/tty.usbserial-0001は、自分の環境に合わせて変更すること。
• 115200はボーレート、12000はマイコン側のクロック周波数。

書き込みが成功すると、自動でリセットされ、LEDが1秒おきに点滅するはず。

#おわりに

LPCOpenを使いたい。
ってかRustで書きたい。

電子部品を大きく二分するカテゴリとして、「能動部品」と「受動部品」がある。

よく見られる範囲^{[1] [2] [3]}では、以下のようにカテゴリ分けされる。

#能動部品の例

• トランジスタ（含 FET）
• ダイオード
• IC類

#受動部品の例

• コイル
• 抵抗器
• コンデンサ

#定義

上で挙げた参考ページの趣旨をまとめると、能動部品と受動部品は、それぞれ以下のように定義されるようである。

• 受動部品：外部から供給されたエネルギーを消費・蓄積・放出する部品
• 能動部品：外部から供給されたエネルギ－を増幅・整流する部品

…… MECEでない!!

おれは、おこっています。

ICもエネルギーは消費するよ!!!

そんなわけで、おれにはこの分類の意味がよくわからないと思った。

単に回路の基本要素であるLCRとそれ以外を分けたいだけのような気もするし、それならLCRと呼べばよい。

確かに回路設計の際に「このICを使って……」から考えはじめることはあっても、「この抵抗を使って……」から考え始めることはまずないだろうから、
その意味で気持ち的な意味はわかるのだけれど、それ以上に意味のある用語とはとても思えず、
この分類がしばしば電子工作の本のはじめに出てくるのも、甚だ無意味でないかと思う。

そう思ったよ、という記事でした。

もうKiCadを使ってずいぶん経つのだけれど、実はシミュレータを使ったことがなかった。
わけあって使いたくなったので、入門してみることにした。

最終的には、以下のようななんの変哲もないコレクタ接地回路の過渡応答のシミュレーションができた。

基本的には、KiCad7のSpice機能で回路シミュレーションを行う - おながわの日記 （以下、この記事を 元ネタ と呼びます）に従って、やってみただけ。

#使ったもの

元ネタ ではKiCad7の話をしているが、KiCad8が手元にあるので、それを使った。

元ネタの内容から特に変化はないが、ややUIに差分があったので、適宜補足していく。^[1]

• Macbook Pro 2021 (M1 Pro, 11 Core, 32GB RAM)
• KiCad8.0.3

#回路図の作成

マジで、やるだけ。

• 元ネタ と基本的な回路定数は同じ。
• NPNトランジスタのシンボルはKiCadに同梱のSimulation_SPICEライブラリにあるNPNを使う
• 左上にある信号源(V1), 電源(V2)は、それぞれ VSIN, VDC である。これも 元ネタ と同じ。

元ネタ では、V1の設定の画面しか拡大されたscreenshotが出ていなくて、V2の設定をはっきりとは書いていないのだけれど、
回路図を見れば9Vであることがわかる。 そのように設定する。 （デフォルトでは1Vなので、波形がクリップする）

#SPICEモデルの追加

NPNトランジスタQ1の特性を設定する。
元ネタ 同様に、RohmのBC847BのSPICEモデルを使う。
直接のリンクは 元ネタ では示されていないのだけれど、BC847B - データシートと製品詳細 | ローム株式会社 - ROHM Semiconductor からモデルはダウンロードできる。

ダウンロードしたら、解凍して、Q1のプロパティ→"Simulation Model…"→ “SPICE model from file (*.lib, *.sub, or *.ibs)” からダウンロードした bc847b.lib を選択する。

#シミュレーションの設定

やるだけ。
元ネタ では「コマンド」を設定せよと書いてあるが、KiCad8では"New Analysis Tab…"という正弦波に+記号が重なったようなボタン(またはショートカットキー ⌘ + N) から設定できる模様。

値を設定したら、“OK” を押して設定完了。
上の再生ボタン的なやつまたはショートカットキー “R” でシミュレーションが実行される。

それから、右側の"Signal" の表から “V(OUTPUT)” と “V(INPUT)” を選択して、プロットさせると、以下のようなグラフが得られる。

シミュレーションはこれで完了。

これでちょっとした回路設計とか、回路の勉強が捗るといい。

今WaveshareのE-Inkディスプレイ で遊んでいて、
しばらくは専用のHATを使っていたのだが、直接触ってみるためにFPCのブレークアウトボードをAmazonで買った。

実験に使っているデスクがスチールデスクで、塗装されているので絶縁されているとは思うのだけれど、
裏面で短絡したりすると怖いので、カバーを作ってみた。

せっかくなのでデータ公開。

組み立てにはM3のビス2本が必要。

ダウンロード(STL)

昨夜、高校時代のチームメイトであるTomixが以下のようなtweetをしているのを見かけました。

ラフスケッチの練習したい

— Tomix (@TomiXRM) December 5, 2024

意匠が強いハードウェア設計している人みんなラフスケッチが上手いよな、やっぱりデザイン事務所でインターンとかしたら場数こなせるんだろうか

— Tomix (@TomiXRM) December 6, 2024

本人に聞いたわけではないので、彼のツイートの真意は不明なのです。が、私はこれをみて、私自身がこの夏スケッチの勉強を少ししていたことを思い出しました。

だからといって特別上手くなったわけではないのですが、良い勉強でした。

そういうわけで、彼に頼まれたとかでは全くないのですが、当時利用したいくつかの資料をまとめておくことで先人たちから受けた恩を送ることにします。

なお、本稿では「スケッチ」の語をもっぱら物理的な製品の核心的なアイデアを記録、伝達したり、意匠を検討するためのメディアとして描画されるものの意味で使います。
より広範な絵画のクラスとしてのスケッチにも学ぶべき点は多い^[1] が、本稿の主な対象ではないのでご留意を。

#きっかけ

私がスケッチの学習に手をつけようと思ったのは、今年の夏、UC BerkeleyのSummer Sessionに行った ことがきっかけです。

この中で、Prototyping and Fabrication(DESINV22) という授業を受講しました。

授業は、こんな感じ。（1単語分だけ私も出演している。）

この投稿をInstagramで見る

Jacobs Institute(@jacobsdesigncal)がシェアした投稿

授業では、3D プリンタやレーザー加工機などのおなじみのデジタルファブリケーションの技術の基礎から、それを使ったRapid prorotypingに基づくデザインのプロセスを取り扱いました。
その中で、Chris Myers先生（めちゃくちゃ褒め上手。“Good design is less design” と “Iterations!!” が口癖）が、スケッチをして見せてくれたり、スケッチの描き方についてちょっとしたワークショップをしてくれたりしました。

そこで勉強を進めるうちに、「スケッチはおもしろ工作おじを目指す上での基本スキルだろうな」と思ったので、今のうちに身につけておこうと、勉強してみることにしました。

#リソース色々

在米中は主に先生に色々聞いていたのだけれど、帰国後は本を読んでみることが学習法のほとんどの部分を占めました。
先生に聞いた部分はあまり再現性がないので割愛して、読んだ本(+動画)を紹介します。

#『プロダクトデザインのためのスケッチワーク』

Amazon

ケーススタディが充実していたのが良かったです。
遠近法や投資図法などのパースの取り方が主な話題でした。

絵を描くのが好きだけど得意というほどでもない私が、基本的語彙や前提となる知識を整えるのにはちょうど良かったです。
デザインという領域は芸術領域から工学領域にかけて広がる広範な概念ですが、工学畑出身の人間に特にお勧め。

#『プロダクトデザインスケッチ : デザインの発想から表現』

Amazon

こちらは、表紙にあるような色彩に富んだスケッチにまつわる話題が多かった印象です。
陰影の入れ方とかがよく説明されていたので、レンダリングを作る時には参考になるかも。逆に、その場でザクザク描いていくようなスケッチに関する話題は少なかった印象です。

#『スコット・ロバートソンのHOW TO DRAW : オブジェクトに構造を与え、実現可能なモデルとして描く方法』

書誌情報(国立国会図書館には書影がないらしい)
Amazon

これは、かなり汎用的なスケッチの本です。地力がつく感じ。パースの勉強をするには一番役に立った気がしますが、ちゃんと分厚いので、完走はしてません。
中で出てくるエクササイズはかなり有用なのですが、個々のエクササイズが無限に凝れてしまうので、どこで次に進めるかが難しかった印象です。

#『気になるモノを描いて楽しむ 観察スケッチ』

これは、描き方というよりは、スケッチする上でどんな部分に注目するかの点で参考になりました。
絵だけ眺めていても面白いので、パラパラとめくっていけるのも良い。

#『だれでもデザイン』

Amazon

日本のデザインイノベーション界隈では大・著名人であるところの山中先生の本です。
この本はスケッチの勉強をしようとはとは無関係に読んだのですが、スケッチの話が出てきます。

山中先生といえば、今年開催されていた「未来のかけら」展はすばらしかったです。

この投稿をInstagramで見る

Yusei Ito(@yusei_ito)がシェアした投稿

その中でも、デザインスケッチに関するワークショップをされていたようで^[2] 、ていねいなレポート を書かれている方がいらっしゃいます。

それから、TEDxでの以下の講演も、その場で描いている臨場感が伝わって刺激的で、モチベーションが上がりました。

山中先生のスケッチの話題は、スケッチを単に伝達のためのレンダリングに留めず、描く人本人の思考の場としても捉えている点が一貫していて素敵です。
Berkeleyで学んだときもやはり思考の場としてのスケッチの使い方を学んで感銘を受けたので、どうも私はこのスタイルが好きなようです。

Instagramにもたくさんのスケッチが上がっているので、楽しい。

この投稿をInstagramで見る

山中俊治 Shunji Yamanaka(@yam_sketch)がシェアした投稿

#気になってるけどまだ読んでない本

#Sketching: Drawing Techniques for Product Designers

Amazon

なんかいい噂をたまに聞きます。（読んでないからそれ以外に言うことながない）
カーリルの情報ではつくば周辺には蔵書がなさそうなので、どこかに行った時に探してみます。

#自動車とプロダクトデザインの基本と応用 : DESIGN & SKETCH : プロダクトデザイナーになるためにスケッチから始める実践的方法 新装版

Amazon

なんかこの記事を書いていて、そういえばちゃんとNDLで検索はしてなかったなと思った^[3] ので、検索してみたら出てきました。
なんか良さそうですね。（読んでないからそれ以外に言うことながない）

#まとめ

この手の記事は実は世界初ではなくて、例えばこれとかもそれ系の記事です。
他にもいくつかあるので、興味があれば探してみてください。

他にもいろんな本やWebサイトを見たり読んだりした気がするのですが、今覚えているのはこの程度なので、思い出したら追記します。

絶望している。
先日、ある血縁関係にある人間 ^[1]から「blog見ているよ」と言われた。

正直なところ、本人が「見ている」と主張する私のblogなるものが、本当に正しくここであるかは怪しい ^[2] ものの、本人が私をインターネットで探しているという事実だけで吐き気がする。

この問題は、俗に「身バレ」と呼ばれるものだと思うのだけれど、私に関して言えば本名でやっている以上身バレなどと烏滸がましいことをいうつもりはない。

しかし、だからこそ、インターネットには入ってきて欲しくなかったのだ。

私は家族の前では ゆうせい を演じているし、インターネット^[3] や友人たちの前では yuseiito を演じている。それらは相互に関連しあっているし、多くを共有しているが、しかしそれぞれにそれぞれの優先順位があり、敵がいて、味方がいる。

ここに文章を書いているのは、 yuseiito であって、ゆうせいではないので、それを一方的に接続されると、読んでいる君にも有害な結果にしか繋がらない。

もう本人は気づいているものと期待して、ここに警告する。読むな。これはあなたのための文章ではない。

より理性的に言えば、インターネットは公共空間であるから、読むのは君の自由であるが、それを読んであなたがどのような心境になろうと、私はその説明責任を負わない。これは私の表現の自由の範疇の問題である。

私は〈私〉という〈個人〉として、いま自由に生きている。干渉してくれるな。

blogを書きたい気分なので、書く。

といっても、米国の紀行録以外に特段書きたいことがなく、かつそれはあまりにも多くの労力が必要なので、
先日人に言われて気づいたことについて書く。

私は、しばしば三人称代名詞として「人間」ないし「ヒト」「ホモサピ」を使う。

例えば、「XXXはYYな人間である」だとか「人間に会いたい」、「XXな人間がいた」「私はfoobarなホモサピです」のように。

もっとも、身体がパソコンでできているような人々の仲間内では、こういった語用は当然のものとして流通しているので、普段意識する機会はない。

しかし、どうやらこれは一般的な語用ではないようで、しばしば違和感を持った人間が驚いたような反応をする。

実のところ、このある種の 逸脱 は、50%無意識で、50%意識的である。
50%の無意識は、世界のあらゆるagentを計算機かそれ以外かで認識していて、その点で計算機以外をホモサピと呼んでいるだけという話で、私にとってホモサピに見えたものがホモサピであるという、 きわめて素直な 語用である。

他方、意識的に、そのように言葉を選んでいる面というのもあって、これが重要である。

「ホモサピ」とか「ヒト」とか「人間」という言い方の代替案を日本語で考えてみる。
すると、実はこれが案外難しく、極めてニュートラルな（すなわち、先輩、後輩、恋人、友人、同僚、家族 etc…のような、「ヒトである」以外の追加の情報を相手に与えない）人称代名詞というものが見当たらないのである。

たとえば、「彼は〜な先輩です」のような言い方では、続柄を示してしまっているし、「〜な男だ」のような言い方では「男である」という余分な属性を提示していて、好まない。

続柄は話題に余分なcontextを加えるし、性別を使った人称代名詞も、本人に尋ねるまで不明確であることはいうまでもない。^[1]

唯一使えるとしたら「人」（ひと）なのだけれど、おれは自分も他人もどのくらい「ひと」なのかに自信がない。homo sapiensだけれど、ひとである感覚がないヒトというのは、案外いるものだ。

そんなわけで、ひとまずは種としてのhomo sapiensと、その言い換えをなるべく使おうと思っている。

と言いつつ、なんとなく流れで「人」（ひと）を使うことも多いので、自己矛盾、単なる逆張りでは？と言われると、そうかも？とも思うが、それはそれでいいじゃないか。

言葉遊びは、楽しい。

Fusin360でいろんな種類のギヤが組み合わさった構造^[1]を作ったので、作り方の備忘録。

3Dプリントするにしても、レーザーカットするにしても、Fusionは便利でいい。

筆者は機械工学に関する専門的教育を受けておらず、独学と模索をまとめています。趣味の工作やプロトタイプには十分な内容と考えていますが、プロとしての品質が要求される目的では参考にしないでください。

#平歯車

インボリュート曲線は大変なので、辛いかと思いきや、一番簡単。
標準で含まれているSpurGearアドインを使う。

• How to create a spur Gear in Fusion 360.

Utilities > ADD-INS > SampleScripts を実行する。 (PythonのバージョンとC++のバージョンがあるっぽい。どちらも動く)

#板歯車

いわゆるラック. (rack) 歯は台形でよいので、モジュールを決めてしまえばほぼ自動的に決まる。

形状は以下を参考にして、歯を一つ作ったあと、繰り返し配置して好きな長さに伸ばす。

最後にギヤの厚さでExtrudeして終了。

• 歯車の歯形及び寸法｜小原歯車工業株式会社
• Onshapeでラックとピニオンを作る

#内歯車

正しい内歯車の作り方 - 歯車のハナシ が参考になる。

前述の方法で平歯車を作ってから、それをPress/Pullで内歯車の歯形になるよう変形して、それを鋳型のように使って補集合をとることで得られる。
変形は、歯元のたけを0.25モジュール小さく(するために円の方を0.25モジュールのばす)するのと、歯先を0.25モジュール伸ばす2つ。

今日(2024/06/12)から、8月中旬まで、渡米します。
主な目的は、はカリフォルニア大学バークレー校 (University of California, Berkeley)のSummer Sessionsを受講すること^[1]です。

#何

アメリカの大学において、 Summer Sessions とは春学期と秋学期の間に行われる夏の短い講座群を指します。
通常の学位取得を目指す目的の学生のほか、 一般にも開放されている ことがあり、私も visiting student として受講します。

したがって特定の専攻が決まっているわけではなく、散発的に関心のある講座を履修登録しています。^[2]

#経緯

そもそも、高校の頃から米国の大学には関心があり、直接海外進学を悩んだこともありました。
しかし、COVID-19もあり、また自分の決心もうまくついていない状態だったので、日本の大学 ^[3] に進学しました。

しかし、大学生活のどこかで一度、海外での大学生活を経験してみたいという思いが残っており、休学して 時間ができた今しかないと考え、この夏に渡米することにしました。

正直、 円が弱すぎてかなり迷った のですが、 時間は不可逆なので、今のタイミングを生かす べく思い切りました。

ベイエリアの家賃の高騰も重なり、正直通帳はみたくない心境ですが、今後の人生において、それに見合うだけの影響を受けることができると信じています。 ^[4]

#Why UC Berkeley?

最も原始的な理由は、強烈な憧れです。 BSDのBはBerkeleyのB 。
やはりコンピュータ屋さんとしてBerkeleyには、強い憧れがあります。

しかし、「今、いく先」としての決め手となったのは、CSよりもむしろその外側の分野が強いことです。

CSの研究が盛んなのはもちろんですが、(Computer以外の）EngineeringやArtなどの分野も、興味を惹くプログラムや研究が多く見つかりました。このような、バランスのよいトップレベルの環境に短期間にしろ身を置くことには、 おもしろ工作おじさんになるための何かが得られそうだという直感的期待 があります。

また、同校には RCJ で知り合った米国人の友人が進学しており、かねがね現地の様子について聞いており、影響を受けました。

さらに、それらに加わる小さな（しかし重要な）理由として、夏の間だけ留学生にもForm I-20を発行しており、学生ビザ(F-1)が取りやすいという都合もあります。^[5]

それ以外にも理由があるといえばあるのですが、あまり勉強の中身に関連したことを言ってしまうとまた行動が割れるので、ここまでにしておき、また終了後に述べようと思います。

6/12から8月中旬まで渡米します 🇺🇸
UC BerkeleyのSummer Sessionsに参加するのが主目的で、併せてBay area 一帯を見学してこようと思います。🗽 クソデカ機会に感謝!! pic.twitter.com/HN8dH6LSKF

— Yusei Ito (@yuseiito_) June 7, 2024

#今後の予定

6月12日に出発し、8月20日ごろに帰国予定です。
その間、考えたことや現地での（束の間の）生活については、このblogで報告できればと思います。

記事が出なかったら、余裕がないか、めちゃめちゃ楽しんでいるかのどちらかです。

渡航期間中、皆様にはご心配をおかけすることも多くなるかと思いますが、どうかご容赦ください。

高々2ヶ月強 の留学^[6] ですから、どうぞご心配なさらず。みなさんから見れば、おれが実家（あるいは、地元の人々にとっては、つくば）に行っている期間と同じようなものです。

いつもこのような無謀を応援してくれる友人や家族に、本当に感謝しています。
渡航の計画を明かした途端、周囲の人間が「見送りに行こうか」とか「体に気をつけてね」とか「寂しい」とか言ってくれて、本当に幸せです。

それから、このような機会をもてたこと自体にも、心からの感謝を。