本日は会社を休んで,たまっている作業をだらだら進めよう.


ちょうど1年くらい前に12ステップ組込みOS自作本が出版されて,本を出したら次は広報と,ここ1年は「組込みOS自作」というものを広めるような活動をしてきた.具体的にはイベント出展や登壇しての発表,関連記事の執筆などだ.


まあ大流行とはいかないが一部ではそれなりに広まってきて,活動の成果がぼちぼち出ているようには思う.


もともと組込みというのは業界主体の活動が多くてコミュニティベースの活動は少なく,業界の人しか入れないというか,別業界のひとや学生とかがちょっと趣味でやってみるというにはなんだか敷居が高いというイメージがある.


これは組込み業界の中にいるひとからは見えにくいことだが,webやLinuxやっているひとから聞いたことでもあるので,実際のところ,そうなのだろうと思う.


なのでぼくの活動は,電子工作やOSとかの低レイヤーをやっているひとというよりも,webアプリやっているような高レイヤーをやっているひとたちをターゲットにしている.(もちろん低レイヤーの人たちも大歓迎だが)


なので実は12ステップ本はハードウェア技術者向けでなく,非常にソフトウェア技術者向けの視点での書き方がされている.高レイヤーから降りてくるひとが理解しやすいような書き方がされているわけだ.


電子工作やっているひとというのは組込みソフトウェアとかも抵抗感無く入れたりするのだけど,上位レイヤーから低レイヤーに降りてくるというのは,なかなか難しいし敷居も高い.自分もそうだったので,そーいうひとたちにまずは興味を持ってもらえるように,そしてもしも興味を持ってもらえたら,次はすんなりと手を出すことができるようにということを考えている.


ということでぼくの組込み関連の活動は,組込み業界に閉じるのではなく,他業界の人や学生さんにアピールして興味を持ってもらったり,あわよくば引っ張り込んだりするようなことを考えている.

組込みの面白さを広めるのに大切なのは組込み業界のイベントで発表することではなく,むしろweb業界のイベントや学生の勉強会とかに飛び込んで行って組込みの話をしてくるようなことをやるべきだと思うので,そうしている.OSCに頻繁に出展したり去年の楽天カンファレンスでLTやってきたのは,まさにそーいう意味合いが強い.


なので実はターゲットは組込み業界でなく,他業界なのです.まあ異端だとも思うけれど,そーいうことをやるひとが一人くらいいてもいいじゃあないですか.


KOZOS開発のポリシーというのはそういうところにあるので,LinuxやAndroidやArduinoとはポリシーが違う.LinuxやAndroidに求められるのは実用性,Arduinoのウリはパッと動かせることだが,KOZOSのポリシーは入門向け(つまり,とっつきやすさ)と学習向け(つまり,組込みOS動作の本質がすべて学べる)という点だ.


だから国産で日本語資料や書籍が多く十分に枯れているH8というCPUを選んでいるし,低価格で購入できて入手性も良い秋月のボードをターゲットにしている.ボードは出来合いのものを使うが,そのかわりソフトウェアはフルスクラッチですべてゼロから作る.このへんはよく「今の時代はARMでやるべきでは」という意見を聞くのだが,ぼくとしてはARMでなくH8で実装することに明確な理由はあるわけだ.


実用向けの組込みプロセッサの世界的な流行りはARMかもしれないが,入門向けに必要なことは世の中の流行がどうかということよりも,まずは初心者向けの日本語の資料が十分にあるか,割込みやレジスタやI/Oや命令セットがシンプルで理解しやすいか,実験するための環境が安価で簡便に構築できるか,といったことのほうが重要だ.だから,そーいう視点でCPU選定・ボード選定をしている.


その後に他のCPUを使う必要がでてきたら,そのときにそれを覚えればいいだけのことだ.「H8で入門したから他のCPUはよくわからない」のだとしたら,それは入門にH8を選んだことが失敗だったのではなく,その後必要になったときにそのCPUの勉強をしていないことがまずいのだと思う.


基礎さえしっかりと身につけば,他のCPUに移行することは難しいことではない.だから複雑なCPUでいきなり基礎を勉強するのではなく,まずは構成がシンプルで理解しやすく資料が充実しているCPUで基礎を勉強して,OSの勉強の面白さを知ってから,その後で徐々に複雑なものを勉強したほうがいいと思う.


この点に関しては,「値段が同じなら高機能なCPUのほうがよい」ということは無い.なぜなら,高機能CPUは割込みまわりが複雑でまともに動かすのにそれなりの設定や知識が必要になったり,シリアル出力をするだけでもいろいろ設定が必要で一苦労だったりするからだ.


たとえば高機能なCPUだとデフォルトで省電力側に振ってあるので,コントローラへの電源供給の設定とクロック供給の設定をしないと,いくらシリアルコントローラの設定をしてもシリアル出力ができなかったりする.そしてその事実はマニュアルのシリアルコントローラの章には書いておらず,電源管理の章とクロック管理の章に点在しているので初心者がパッと気がつけるようなものでは無かったりする.こーいう設定を初心者がすべて独学で行うのはきつい.で,LinuxやArduinoの場合の解決方法は「すでに使えるようにドライバを用意してありますこれを使ってください」なわけだが,これは実用やパッと遊ぶにはとてもいいと思うし否定するものではないのだが,勉強にはなりにくいとは思う.


イベントでぼくがよく言っていることだが,組込みは「大は小を兼ねる」ではなく「適材適所」の世界だ.高機能CPUだからといっても,すべての用途に向いているわけではないのだ.むしろ低機能なほうが取り扱いが楽でありがたい場合も多々ある.


そして重要なことは「勉強の面白さを知る」ということだ.


この点が,仕事でやることなのか個人の勉強でやることなのかの大きな違いになる.仕事でやることならば「仕事なのだからやらなければならない,だからやる(やれ)」で終わりだ.だけど個人の勉強はそうはいかない.まずは面白さを知らないと長続きしない.逆に面白ささえ知ってしまえば,モチベーションを保って勉強を続けることができる.このへんに,プロとアマの会話のギャップがあるように思う.プロに必要なのは「実用性」「業務に直結すること」だが,アマチュアに必要なのは「楽しいこと」「モチベーションを続けられること」だ.


だからぼくはプログラミング言語とかも,最初に本格的な言語をいきなり勉強するのではなく,パッと結果が出て面白い簡単な言語で入門するほうがいいと思う.本格的かどうかということよりも,まずは楽しさを知ることのほうがずっと重要だ.それでまずはプログラミングの楽しさを知って,その後に興味が出ればまた新しい言語を勉強すればいい.その後で他の言語に移行できないとしたら,それは最初に勉強した言語の選択に問題があるのではなく,他の言語の勉強をしようとしないことのほうに問題があると思う.


そもそも組込みなんて多神教の世界で,CPUもOSも星の数ほどあり,それぞれに独自の存在価値があれば生き残っていける(これが,汎用PCとは大きく異なる点だ).だから,これひとつだけ覚えておけばずっと通用するなんていう技術は無い.はやりもすたりもあるし,常に複数の選択肢を持って,取捨選択ができなければならない.必要になったらそのCPUでもOSでも言語でも勉強して身に着けるべきであって,今流行のこれこれを勉強してきたから一生安泰なんて思ったとしたら,そっちのほうがよっぽど危険だよなあ.


だからKOZOSは組込みOS学習の「とっかかり用」のOSとして,実用性はさておいて,楽しんで勉強できるようなものにしていきたい.そのためには初心者用の解説本や勉強会が必要だし,イベント出展などで身近に感じられることや,開発者の話が気軽に聞けること,仲間がいるということも大切だ.そのような複合的な意味で「学習向け」を目指している組込みOSは他に見ないので,これはこれで独自の存在価値がある.


もともとは小説読むのが好きで(最近あまり読んでないけど),子どものころは子ども向けの探偵小説をやたら読んだ.これは,マンガは高い割には30分くらいで1冊読んでしまうが小説なら1冊数時間はかかるのでコストパフォーマンスが高いというのと,図書館で無料で借りられるというのが大きな理由だった.


中学になってからはソノラマ文庫(妖精作戦とかクラッシャージョウとか懐かしいなあ)を読みあさって,浪人時代からまた探偵小説を,今度は文庫でいっぱい読んだ.ちなみに好きな作家はクロフツ(フレンチ警部の超努力肌で野心家なところがかっちょええ)とディクスンカー(夜のお城に不審な明かりが…とか,そーいうわくわくする話が好き)と横溝正史(金田一耕助がものすごく好き)だ.金田一作品は八ツ墓村が最高傑作に思うが,田舎村の旧家で事件が起きる系のやつが好き.あ,あとシャーロックホームズとアルセーヌルパンも好き.マントルピースという言葉はホームズで,コンパートメントという言葉はルパンで覚えた.


その影響なのか流れなのか,ぼくは基本的に物を書くことは好きで,雑誌記事を書いたり本を書いたりするのは趣味の延長が仕事になっているような感覚だ.

現在,書籍執筆が6冊(うち1冊は共著)で雑誌記事は月刊ペースで2本を連載中と,フツーのサラリーマンにしては多作な部類に入ってきた.サラリーマンやりながらの月刊連載2本はキツくもあるが,好きでやっているのでストレスはあまりたまらない.なのでぼくはブログとかメールとかの文章も,基本,長い.(笑)


物を書くことは,物を読むことよりも,100倍たいへんだが1000倍楽しい.

で,物を書くことについてなのだけど,まあぼくの場合はなにかいろいろ自分でやってみたり試してみたりしたときに,最終的なまとめとして本を書く,というパターンが多い.

いろいろ自分で趣味とかで試したりしていると,なんでこの分野には本が無いのかなーとかこういう本があればもっといいのになーとか思うことがとても多い.世の中的にあまり手が付けられていない分野の場合はなおさらだ.


で,そーいうことをやっているうちに段々知識がついてくると,無いならじゃあ自分が本を書いてしまうか,そうすれば後の人はとっても嬉しいだろう,というパターンで本を書くことが多い.Cオブジェクト指向本とか組込みOS自作本とかリンカ本とかは,そーいう感じで書き始めた.組込みOS本とかは,自分が好きで作り始めた自分オリジナルのものを題材に本にできているわけだから,まあ物書きとして最高に嬉しいパターンではある.


物を書くっていうのは,とてもいい趣味だなーと思う.これは本だけでなく,ブログを書くとかホームページを作るとかケータイ小説を書くとか同人小説を書くとか,そーいうのも含んでそう思う.

まず物書きっていうのは,ノートPCさえあれば元手無しですぐに始められる.書くこと自体には特別な技術は必要無いし,誰でもすぐに始められる.お金も電気代くらいしかかからないし,運がよければ雑誌記事や本になったりしてお金がもらえる場合もある.


そして,情報を発信すれば喜ばれることもある.とくに技術的話題とかは,発信することで喜んでくれる人がいたりすることがある.生産的で誰を傷つけることもないし,何も無いゼロからものを生み出す,クリエイティブでとてもいい趣味だ.元手がいらないから,中学生でもすぐに始められる.


だから,なにか物を書いて発信するひとがもっと増えるといいなーと漠然と思う.


今は物を書くことに対するハードルというのはとても低いと思う.たとえば昔はきっとそうではなくて,原稿用紙にペンで書いていたから校正とかがたいへんそうだし,書いたところでなにかメディアにでも載らなければ誰に読まれるわけでもない寂しい感じで終わってしまう.


でも今は違って.ノートPCさえあれば誰でも簡単にブログとか書いて世界に向けて発信することができる.誰でも自分の思いや考えやいい意味での技術的自慢を,すぐに簡単に世界に向けて発信できるわけだ.


だから物を書くっていうのは,とてもいい趣味だなーと思う.こーいうことにインターネットやコンピュータが使われると,技術がひとの生活を豊かにしているなーと思うし,技術というのはこーいうふうに使われてほしいなーと思ったりする.

高校生とか学生とかも,もっといろいろ書いて発表するといいなーと思うし,技術者も技術的話題やいろんな発見を,どんどん発表するといいなーと思う.文章を書くことは楽しい.いまこのブログを書いているのも楽しい.自分が好きなことを文章にして発信するというのは,最高に楽しいし良い趣味だと思う.


文章を書くことが好きでホント良かったなーと思う今日この頃だ.

「C言語 入門書の次に読む本」の改訂新版がいよいよ発売された。ISBNが新しくなっているので新刊として考えると、ぼくの6冊目の著作になる。1冊は共著で他5冊は単独執筆。フツーのサラリーマンとしてはかなり多い著作数になるのではなかろうか。


今回、改訂用に読み直したのだが、うーんやっぱり若いころの文章というか、日本語がちょっとなあという部分がいっぱいあってあちゃーという感じ。ほんとは全部直したいくらいなのだけどそれをやりだすと切りが無いし、このへんはもうそろそろ完ぺき主義でなくあるていど割り切るようにしないと新しいものが書けなくなってしまうので、妥協もいたしかたないところだなあ。前向きな妥協ってことでご勘弁ください。


内容的には未だに通用するというかまあいいこと書いてあるんではないかとは思うのだが、今となってはちょっと極端なところもあるかなあ、と思う。まあ8年以上も前に書いた本だし、筆者自身の考え方も変わってはいるのでこのへんもまあいたしかたがないところだ。ていうかそんな昔の本が改訂されてまた出ること自体、やっぱり普遍な内容を書けているのかなあともうぬぼれちゃったりもする。


ということでこの本を読む人へのメッセージなのだが、ぜひ他にもいろいろな本を読んでほしいと思う。そしていろいろな本を読んで、いろいろな角度で考えてほしいなあと思う。まあこれはべつに「この本の内容はあやしいから他の本も読んでおいたほうがいいよ」ということではなく、この本に限ったことでもない。


というのは、技術書ってやっぱり1冊だけ読んではい終わりではダメで、いろいろな本を読んでさまざまな角度から考えられるようにならないとなあと思うからだ。工学技術っていうのはこれが絶対に正しいという「正解」っていうのは無くて、状況によっていろいろ選択できることのほうが大切だ。本もそうで、「この本は正しいからこの本をすべて信じる」「この本はダメだから一切信じない」とかいうようなステレオタイプな考えで読むのではなく、箇所箇所によって、「この本のこの部分はまっとうだと思うから自分に取り込もう」「でもこの部分はちょっと違うんじゃないかと思うので、他の本と比較してみよう」とか考えられることが重要だ。


工学っていうのはどの本も正しくもあり間違ってもいるのだ。なぜならそれは状況次第で取捨選択されるべきもので、状況によってコロコロと変わるものなのだ。だから1冊の本を一概に「これは良い」とか「これはダメ」とか0か1で考えちゃうのはちょっと危険な気もする。いい悪いで考えてあら探ししながら読むのではなく、「この本から何かを得よう」という考えで読むことが重要だ。


いろいろ読んだうえで、「あの本にはこう書いてあったし、今回はそうしてみよう」とか「あの本にはこう書いてあったけど、今回の状況ではこっちの本のこれこれの内容のほうが適切だと思うから、今回はこっちにしてみよう」とか取捨選択できることが大切だ。工学ってホント取捨選択の、多神教の世界だと思う。それはプログラミング言語もそうだし、CPUもそうだし、OSもそうだし、開発環境もそうだ。これしかできなくて常にそればっかり使うというのではなく、いろいろ知っておいて状況に応じて今回はこれを使おうとか選べることが大切だ。


工学書っていうのは深い内容を書けば書くほど、最大公約数的な書き方はできなくなる。だから深い内容の本ほど、状況によっては正解では無いという内容も多くなってくる。だからいろんな本を読むことは、とっても大切なことだと思う。


本日は有給消化のためと、たまには骨休めも必要ということで、休んでゆっくりしています。(でもいろいろ作業しているのだけど)


ところでFreeBSDではメーラにmnewsを利用しているのだが、ちょっといろいろいじってインストールしたのでメモ書き。


まずインストールについてだが、UNICODEが利用したかったので、mnews-PL6に対して以下のパッチを適用してソースからビルドした。


http://www.doga.co.jp/~taka2/mnews/


ビルド方法やインストール方法についてはいくつかの場所で説明してあり、まあそのままやっただけ。

FreeBSDでのmnewsのビルドについては以下を参照。そのままではうまくいかずMakefileを修正する必要がある点に注意。


http://www.cory.jp/98/mnews.html


さらにそのままではいくつかの不具合があったので、以下の修正を入れた。


まず、そのままだとメール送信時にサイズ上限があるので、リミットを外す。
--- src/mailsend.h~     2000-08-18 08:37:08.000000000 +0900
+++ src/mailsend.h      2011-03-29 22:38:24.000000000 +0900
@@ -21,7 +21,7 @@
 #endif /* (!MSDOS || USE_LONG_FNAME) */
 #define        ALIAS_PARAM1    "alias"         /* エイリアスパラメータ(1)      */
 #define        ALIAS_PARAM2    "group"         /* エイリアスパラメータ(2)      */
-#define        MAX_SEND_SIZE   (48L * 1024L)
+/* #define     MAX_SEND_SIZE   (48L * 1024L) */

 #define        FORWARD_START_MESSAGE   "------- Forwarded Message\n"
 #define        FORWARD_END_MESSAGE     "\n------- End of Forwarded Message"
--- src/newspost.h~     2000-03-26 01:27:29.000000000 +0900
+++ src/newspost.h      2011-03-29 22:38:29.000000000 +0900
@@ -15,7 +15,7 @@
  */

 #define        POSTER          "poster"
-#define        MAX_POST_SIZE   (60L * 1024L)
+/* #define     MAX_POST_SIZE   (60L * 1024L) */

 #define        PF_FROM_MASK    0x0001
 #define        PF_SUBJ_MASK    0x0002

さらに、メールに添付された画像等を見る際にファイル名が正常に表示されず、セーブしようとしてもやはりファイル名が空欄になってしまう問題の修正と、IMAP4対応パッチを適用するとmnewsのメール選択画面などでカーソルキーがなぜかうまく利用できなくなってしまうので、その修正。select()で待ってしまうのがまずいらしいので削除する。

--- src/mnews.c~        2011-03-29 22:36:45.000000000 +0900
+++ src/mnews.c 2011-04-01 00:38:15.000000000 +0900
@@ -2962,20 +2962,24 @@
                if (mime_mtype == M_MTYPE_MULTI) {      /* multipart    */
                  if (!mime_get_param(ptr3, MIME_BOUNDARY, boundary)) {
                    fclose(fp1);
                    fclose(fp2);
                    mime_part_menu(file1, boundary, mime_news_group,
                                   mime_stype);
                    return(1);
                  }
                } else if (mime_mtype == M_MTYPE_APP) { /* application  */
                  mime_get_param(ptr3, MIME_NAME, file_name);
+               } else if ((mime_mtype == M_MTYPE_AUDIO) ||
+                          (mime_mtype == M_MTYPE_IMAGE) ||
+                          (mime_mtype == M_MTYPE_VIDEO)) {
+                 mime_get_param(ptr3, MIME_NAME, file_name);
 #ifdef notdef
                } else if ((mime_mtype == M_MTYPE_MSG) &&
                           (mime_stype == M_STYPE_PART)) {
                                                /* message/partial      */
                  mime_mtype = M_MTYPE_UNKNOWN;
                  mime_stype = M_STYPE_UNKNOWN;
                  while (fgets(buff1, sizeof(buff1) - 1, fp1)) {
                    if ((!buff1[0]) || (buff1[0] == '\n')) {
                      break;
                    }
@@ -3960,21 +3964,25 @@
       mouse_row = key - ' ';
       mouse = 0;
       break;
     }
     key = '[';
   }
 #endif /* MOUSE */
   switch (escape) {
   case 0:
 #ifndef        DONT_HAVE_SELECT
+#if 0
     if (key == 0x1b && term_select()) {        /* ESC                  */
+#else
+    if (key == 0x1b) { /* ESC                  */
+#endif
 #else  /* !DONT_HAVE_SELECT */
     if (key == 0x1b) { /* ESC                  */
 #endif /* !DONT_HAVE_SELECT */
       escape = 1;
       key = 0;
     }
     break;
   case 1:
     if ((key == '[') || (key == 'O')) {
       key = '[';       /* O はキーバインドで使うので [ に変換 */

さらに、MSPLが無効でビルドした際に.mnews_setupでpop3_modeをoffにしたときに強制的にMSPL利用になってしまい起動が遅い問題の修正。

--- pop3lib/pop3lib.c~  2002-01-09 15:07:09.000000000 +0900
+++ pop3lib/pop3lib.c   2011-04-01 00:35:11.000000000 +0900
@@ -133,26 +133,30 @@
   static int           first = 1;
   char                 spool_dir[PATH_BUFF];
   struct stat          stat_buff;
 #endif /* MSPL */
   char                 *ptr;
   POP3_ERR_CODE                status;

   switch (pop3_connect_mode) {
   case 0:                                      /* MSPL→POP3 接続      */
 #ifndef        MSPL
-    pop3_connect_mode = 1;
+    pop3_connect_mode = 2;
 #endif /* MSPL */
     break;
   case 1:                                      /* POP3→MSPL 接続      */
 #ifndef        POP3
+#ifndef        MSPL
+    pop3_connect_mode = 2;
+#else
     pop3_connect_mode = 0;
+#endif /* MSPL */
 #endif /* POP3 */
     break;
   default:
     break;
   }
   status = POP3_ERR_COMM;
   switch (pop3_connect_mode) {
   case 0:                                              /* MSPL 接続    */
 #ifdef MSPL
     if (first) {

あと、上記サイトではmmfilterというファイル添付用のフィルタを公開しているのだが、ソースを見たところ、バッファサイズが固定なので添付できるファイルのサイズに上限があるように思える。


まあサイズ拡張すればいい話ではあるのだが、面倒なのでperlで同等のフィルタを書いてみた。せっかくなので以下で公開する。「mnewsでメール送信時にファイルを添付させるスクリプト」ってやつね。mimefilter.plというやつ。


http://kozos.jp/tools/


これでメール参照も快適だ。