はてなブックマーク

(1) (2) “デキる”中堅IT経営層と4桁(年収)プログラマとの齟齬 “デキる”中堅IT経営層は、日本には少なからず居る。 ここでいう”デキる”とは、技術に夢を持ち、資金調達の能力をもち、潰さず500名規模まで伸ばせる人材の層を指す。 同時に “デキる”プログラマも、日本には少なからず居る。 しかし、両者にはミスマッチがある。 両者とも、実績を積んだのは事実であり、生産性を高めた結果として地位なり収入なりを得ている。 そこには両者なりの合理性がある。 日本の中堅IT経営層は、多段下請構造に自らを最適化することによって自社を潰さず伸ばしていった。 日本の産業構造が求めた結果であり、彼らに求められるのは会社を続け雇用を確保することなのだから、彼らの行動は合理的である。 結果として、日本の中堅IT経営層の多くが考えるリソースとは、”人財”となる。 よって、企業の拡大局面においては、ヒューマン

なぜ日本の「中堅IT企業」は優秀なプログラマを囲いきれないのか。 さきほどは、本稿における「中堅IT企業」を定義し、その企業群が少なくとも統計資料やマスコミ発表資料では活発で伸びていることを紹介した。 その企業群で人手不足が解消されない。特に”デキる”“人財”が来ないし定着しない。そのようなボヤキも紹介した。 今回は、なぜ定着しないのか、私見を書き散らしたい。 下記するのは、見聞きした事例から作り上げた「モデルケース」でしかない。 少なからずの「中堅IT企業」で程度の差こそあれ発生していると想像しているが、広範なケーススタディを行ったわけではない。 くれぐれもこの点には留意されたい。 前回述べたとおり、2つの要因を示唆する。 マネジメント不全 まず、ひとつ目の要因は、マネジメント不全。 これは、書店に行けば事例が山のように報告されているので、説明の必要は無いだろう。 たとえば、この記事で端

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

とある，案件契約ではない非公式なやりとりから． 個人が特定されるような内容ではないので，これくらいなら許され…ますよね． mruby 自身もC言語に比べて処理に時間がかかるところに，RTOSが入るとさらに遅くなったりしないのか少し心配です． 個人が特定されるどころか，同じような直感を持たれる方，案外多いのではないかなと思います． 機器組み込み業界で働いておられるエンジニアの中にもいらっしゃるのではないかな，とも． 端的に言うと，RTOS が入ると遅くなるというのは，概ね誤解です． いやもちろん RTOS がゼロオーバヘッドだと言っているわけではありません． いまや会社の製品の機能として提供されている部分なので，本来なら会社の公式ページに書くべきところですが，そうすると定量計測してホワイトペーパーにしないと格好がつきません． そこまで喫緊の話でもない(非公式なやりとりですし)ので，こちらに書

先ほどの続き． sandbox の需要を理解するには，前提として，Webサーバと RTOS とで，スレッドの使われた方が違う，ということを，知識ではなく，腹に落としていないといけない．世界観の問題． mruby のコアを弄るような方々は，知識としては心得ているはず，だが． — もなか (@monamour555) June 14, 2014 など言って，実装理由を詳説しないのは，ちょっとイケ好かないかなということで． 本題に入るには，OS が提供する thread の使い方について，寄り道をする必要があります． 注: 本稿は，mruby の内部構造，特に，mrb_state と mrbgems の関係を理解していることを前提にしています． thread の使い方，2通り thread は，たかが機構なので，使い方は幾通りもありえます． しかし，代表的なパターンとして，2通りの使い方がありま

おお，さすが OSS 世界の長老．キレの良い予言でございます． @monamour555 まあ、どうforkするかはご自由で私から強制することはできませんが、過去の事例だとこの手のforkしたOSSは長期的には失われる結果になりそうです。 — Yukihiro Matsumoto (@yukihiro_matz) May 29, 2014 全く御意でございます．低頭拝聴です． 賤民である私も，OSS という言葉が無かったころ，Ruby が世に放流された頃には，この世界を見ていた気も無くもないですが． きっと気のせいですね． uClinux, Xen, Android で kernel の fork が起こったのは，失われる運命だったのですね．だめだ fork はダメだ．失われる！だめだ！ やっぱ fork はダメだ失われる！ あーやっぱり，私が書いたコードなんて，消えちゃうよなー．すべから

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

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

Twitter から この辺のやりとり勉強になるぅ https://t.co/BQzNAjSoyP — 松本 亮介 / まつもとりー (@matsumotory) March 18, 2014 というやりとりは，こちら． @yukihiro_matz ええ，それはRuby世界からの見方ですね．C世界から見れば，const char * の長さが mrb_int になるのは危険です．SIZE_MAX と MRB_INT_MAX の大小関係は，C言語処理系に依りますから．(続 — もなか (@monamour555) March 18, 2014 連ツイなので，前後も読んで頂ければと． ちなみに，この後，Matz 氏がコミットを一部撤回し，結局のところ，API の分裂は避けられた． やっちゃマズい fork ソフトウェア開発の世界では，やってよい fork と，やっちゃマズい fork という

#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にみるグローバルソフトウェア開発」というタイトルでの講演は，聴講していない． そのため，今書いているエントリは，元の文脈から逸れている可能性はある． インスパイヤ系ってことで，ひとつよしなに． いろいろ思うところはあるのだが，一気に書くと発散するので，数回に分けて書く． 「運」てのは，生き方の一番深いところに直結するゆえに共通見解を極めて見出しづらい概念だからなぁ…．140字ではやはり無理なので，web日記行きだぬ． — もなか (@monamour555) February 14, 2014 今回は，「運(幸運/成功)」について． 「運」とは何か． @miura1729 @hyoshiok 最初の一人が運なのは当たり

曰く． 一円単位でコストを削っているのでファームウェア書き換え前提のプロセスは組み込みではないです。iPhoneは組み込みじゃないですから。 溜息が出る． 組込みシステムの文脈で露出の高い方から，こういう類の意見が出るたびに． 組込みシステムでは，一円単位でのコスト抑制がかかることは，珍しくは無い． それは，その通り． コストが全て．だから，最近の自動車のコンピュータは書き換え可能になっている． ムダ・ムラを徹底的に排除する，あのトヨタの自動車でさえも． iPhone は組込みではないという． ならば，科学館や美術館へ行ってみるといい． iPhone の兄弟である iPad が，壁面に掲げられ，パネルに埋め込まれ，運用されているのをしばしば見かけるだろう． ああ，組込みシステムの開発者たちは，そういう場所に行く暇もないくらい忙しいのだっけか． サイネージの多くが，Windowsで動いている

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

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

まくら とあるWebメディアから，新春インタビューの依頼を受けました． どこからかは，載るまで秘密です．載らないかもしれませんし． このエントリを書いている時点では取材前ですし，載ったとして，(当然)年越しです． 来年の予測を，ざっくばらんに…とは言われたものの，そのとおりにすると，纏まらないわ人を無闇にdisるわで大変なことになります． 我ながら目に見えるょぅ…． 組込みシステム業界は，誰の顔を見ている? そんなわけで，ここ数日，寝しなに，来年とか今後数年後の組込みシステム業界を空想してみたりしていました． そのとき，ふと思ったのです． もしかして，日本の組込みシステム業界って，組込みシステム業界のことしか考えていないんじゃないの? オピニオンリーダーたちの発言から 組込みシステムに限らず，業界には，オピニオンリーダーという方々がいます． 彼らの意見は，必ずしも業界の代弁人ではありません

(2013-05-03 21:57 JST : ソースコードの誤記修正) 話のマクラ 新製品リリース前でプログラマーズハイになっておられるらしい shi3z 氏が，イカしたエントリを挙げておられる． ついに僕もソースコードを確認しないと気が済まなくなりました。本当にちゃんと最適化してるのか、自分の目と頭とで確認しています。 よくわかる最適化 – UEI shi3zの日記 をを! 社長自ら！ すごい！ この関数は、一見すると無駄がないように見えますが、実は無駄の塊です。 たとえばコンピュータは割り算が苦手です。なのに二回も割り算をやっています。 割り算よりは掛け算(乗算)の方が圧倒的に速い(下手すると10～100倍くらい?)ので、まず割り算をしている部分を2.0の逆数の乗算に変更します。 よくわかる最適化 – UEI shi3zの日記 最近，トシのせいかすぐに感涙してしまう私は，感化されて，