書く気になった背景 私は、プログラマだ。なんだかんだで職歴は20年を超えた。 同時に、かつて10年ほど小さなソフトハウスを経営していたし、今も代表1名の法人を持っている。 そんな経歴により、プログラマ諸氏からは概ねプログラマとして接していただき、経営者諸氏からは稀に経営者としての意見を求められる時がある。 2つの異なる立場についてほぼ同時並行で見聞きする機会に恵まれるのは、おそらく珍しいことだろう。 そんな経験の中で思ったことを、書き散らしておく。 もちろん、守秘義務や職業倫理というものもあり，複数の事案をミックスし曖昧にしてある。 特定の企業についての邪推は無用。ひとつよしなに。 中堅IT業界における、人材受給のミスマッチ 広くIT業界は、長きに渡って、「人手不足!」と叫んでいる。 そして「”使えない人”ばかり面接に来る」というボヤキが続く。 つまり、”デキる”“人財”が来ない、または定

もう半年前くらいになるが，柔軟仕上げ剤のにおいについて相談が増えているという発表を国民生活センターが行い，各メディアも報じた． NHKの報道に拠ると… 業界団体の調査によりますと、柔軟剤の利用者の４人に１人までが、定められた量の２倍以上を使っているという結果も出ています。 2倍以上!? バカじゃねーの??? 嗅覚麻痺してんの??? という気がする． 特に理系は用量について敏感なので…そうでないと実験中に死にかねないので…驚きと嘲笑でこのニュースを見ていた人が多かったのではないだろうか． でもある日，洗濯機を回そうとしていて，ふと，きちんとキャップで測っているからこそ，こういうことになってんじゃないの? という気がしてきた． 大抵の全自動洗濯機は，水量をリットルで指定できる． または，自動で必要な水量を検出して，その量を表示できる． 洗濯したい人は，その量に応じて，洗剤なり柔軟剤なりを投入す

昨日のエントリの反響は大きく，色々な意見がありました． 多くは暖かいご支援で涙が出てきました． もちろん様々な意見はあり，そのほうが世の中としては健全と思います． そうは言っても経産省悪くないし 的な意見もありました． 私もそう思います． 見積もりを出してきちんと名簿も積算もしたのに，後出しジャンケンをする． これは，個人的には卑劣だと思いますが， _だってこの国ニッポンの商習慣じゃないですか，これ__ ． (と同様のご意見も頂きました) 別に経産省は悪く無いです． ニッポンの商習慣を踏襲しただけです． 昨日のエントリにも書きましたが，私は，黙って机を蹴って退席し，契約印を推さなきゃ良かっただけです． …だからこそ，この国ニッポンには，未来がない． とも，思いますけれどね． そんな感じではあるのですが，一つだけ，いい大人がこの理解は無いわ，というご意見があったので，マイルドに晒します． サ

一般的には，黙り通す人のほうが大多数な話ですが． 業界のディープな方々は「どうなっちゃったの? 顛末がよく分からん」って永く思っていらっしゃるでしょうし，珍しい名字ですし，検索エンジンは非情ですので早晩，私の名前は出てきます． 官報の破産情報だけ転載し続けているwebサイトとか，ありますからね． なので，言っちゃいます． わたくし，やっと破産手続き，開始しました． 平成26年(フ)第2841号 平成26年(フ)第2842号 平成26年(フ)第2843号 なんで3つあるかというと，私の分．私が代表だった会社2つ分，合計3つだからです． ややこしいです． 「東京地方裁判所民事第20部」でさえも，封書で誤記して，二重線訂正で送ってきましたから． 原因 まあいろいろあるのですけれど． 致命傷となったものを下記列挙しますが，結局は，私が，経営者として未熟だったということに尽きます． 〇〇が悪かったと

前回 の続き． C言語のおさらい 繰り返しすぎてそろそろクドいかもしれないが，C言語は，いろいろとフリーダムすぎて扱いづらい． にも関わらず，UnixというOSの記述言語を超えて広く使われた理由の一つに，ポインタを用いた自由なメモリアクセスがある． OSやハードウェアの制約がなければ，プログラム自身を含む，全てのメモリは参照可能で，書き込みもできる． ポインタは，加減算によってアドレスを変更できる．ポインタ同士の加減算も可能だ． 自らが管理する変数を，ポインタを用いて，書き換えることもできる． そのような操作を支援するために，特定の変数が専有しているメモリサイズを取得することが可能だ．…など書くと無駄にややこしいが，要するに sizeof 演算子がある． sizeof は sizeof(foo) など括弧を添える書き方が一般的なので，ときどき関数やマクロと誤解されるが，演算子 である．本稿

前回 の続き． たぶんこれで本件に関する一応の最終回． APIは世界の境界線 異なる世界観の端境にあって，両者の言い分を理解して橋渡しをする． API の設計は，端的には橋渡しに尽きる． API の直交性など，細かく言うと設計上気をつけるべき点はある． しかし，それは，より美しく使いやすい API であるための付加価値である． 大事だけれども本質ではない． API の代表例として，OS が提供するものがある． システムコールとかサービスコールという名で呼ばれる． フリーダムなユーザランドと，好き勝手されては困るOSとの間の橋渡しをする． 一例として，リアルタイムカーネル TOPPERS/JSP のサービスコール関数の冒頭を引用する． 心配ない． RTOSのコードなんて読んだことが無いよ，という方でもざっくりと理解できれば十分． /* * メールボックスへの送信 */ #ifdef __sn

ちょいと寄り道して，前回の補足． @monamour555 gccのversionは何をお使いですか？4.3以降だと-Wconversionとか使えませんかね。。 — ぬん。 (@amasawa_seiji) March 19, 2014 鋭い．(汗 はい．-Wconversion ，使えます．記憶が正しければ GCC 2.95.x から． ただ，検出が割と難しいようで，3.4系でパッチが出て，立ち消えになったり． 当時の経緯はこのエントリが詳しいです． また，GCC 4.3 以降では，挙動が微妙に変わったりしています． 変更内容の詳細は，GCC Wiki を． GCC は，そんな事情なので，前回の記述 もしかしたら気の利いた処理系では警告を出してくれるかもしれないが． は，完全に筆が滑っております． お詫びします…が，必ずしも訂正はしません． 今回の後半は，その辺りについて． -Wcon

#include <stdio.h> #include <stdlib.h> int main(void) { int a = 65535; char b; b = a; printf("%d %d\n", a, b); return EXIT_SUCCESS; } 「a に 65535 を代入し，b に a の値を代入しているのだから，b も 65535 になるはず．」 などとLL言語(JavaScript や Ruby など)に慣れていると思ってしまいがちだが，そうはならない． なぜなら，一般に，char 型の変数が保持できる値の範囲は，int 型の変数が保持できる値の範囲よりも小さいから． 概ね(…とボカす理由は後述)，char は -128 から 127 までの整数しか保存できない． この性質は，ときどき，極めて恐ろしい． C言語は，上の例のように保持できる値の範囲が小さい変数への

特定の話題にインスパイヤされ，いくつか似た話題で連投した． けれども，これで一旦打ち止め． 本稿は，アッサリと進め，終わる． オレオレ定義を始めると，長くなるし焦点はボケるし，ロクなことがない． 本稿の契機(元ネタ)は「未来のいつか/hyoshiokの日記」の「まつもとゆきひろのコピーは作れるのか。」および，その反響 tweet から． 元ネタ曰く， Rubyが世界中で使われるようになるまで10年かかった。だけど、クラウドのサービスを使えば、それは1年に短縮できるとまつもとさんは言う。mrubyも成功したので、自分の方法論をまねすれば誰でもできるのになんで後進がいないのだろうか？と彼は問う。 1日なのか，20年+1日なのか ここで唐突に，話題を移す． Ruby のような，世界の誰もが使うような素晴らしいソフトウェアの話 ではない ． 世界の片隅ニッポンのとある休日に起きた，一人ハッカソンの

なんとなく，今日現在の mruby について，私自身が薄ぼんやりと考えていることを書いておく． なんでこのタイミングなのかに，あまり深い意味はない． 一つのきっかけとして，イベントはある． mruby を話題の中心に据えたイベントが，今日の午後開催される． 私も聴講者として参加する予定だ． 参加した後だと，その感想と混じる． なんとなく私見の純度が下がるかな，とか． 私は，何を書いても，誰かや何かをdisっているように受け取られがちだ． けれども，本稿もdisりの意図は全くない． 徒然なるままに． 小規模組込みも視野に入れている割に，Lチカに向かない言語 この tweet が象徴的だと思う． TinyFeather+mrubyでLチカしてみたんだけど、意外と難しいかったw String <=> byte Arrayの変換がpack/unpackないのに苦労したっていうのが本題 — ふぇえ

140字以内で纏めると，こういうこと． 「Q. 決定プロセスを何かで公開してほしい」「A. 軽量Rubyフォーラムに加入すると参加する事ができる。」 あかん，TOPPERSが抱える数少ないデスパターンを，完全踏襲しとる．w http://t.co/bVOtyNMrs9 — もなか (@monamour555) January 31, 2014 私は，TOPPERSプロジェクトという，組込み系OSSを担いだNPOに参加していた． 設立準備から手伝って，一応10年くらい理事もしていた． NPO法人TOPPERSプロジェクトは，組込みソフトの団体として，成功したと思う． 電子ピアノにも，宇宙機にも，自動車にも載った． 私が書いたソースコードも，割と入っている． そこらそんじょのOSSなんざ蹴散らすくらいの採用例，出荷総数はあるだろう． 今は辞めた． 理事も辞めたし，今や会員ですらない． 当時やっ

雇用はいちばん難しい かつてお世話になった方が，起業計画中とのことで，相談を受けた． 私は，起業家としては失格の部類なのだけれども，スタートアップの空気感は解る，みたいなレベルではあるので，返事を書いた． 送信後，読みなおしたら割と一般論っぽかったので，ちょちょいと書きなおして当日記にも載せておく． ついでにセルフツッコミも入れておく． のっけから自分の話の腰を折るが，スタートアップでは”一般論”は”役に立つ”を意味しない． 毒にも薬にもならない，ってことだ． 優秀な技術者の雇用ですか…これは一番難しい問題ですね． たぶん私自身もあと20年くらい悩み，挙句に答え出ないかも…． 私自身の近況に限って言えば，もう新規の雇用は止めました．法定福利や源泉税務にかかる手間を考えると，どんなに優秀な技術者であっても割に合いません． (日本の雇用行政は，本当に不合理非効率だと思います) 省いた手間は，費