無料で読める娯楽で下衆なバカ笑いしたあと、私は、真顔になる。(めんどくさいヤツだよ)
経営者にとって何よりも優先されるべきことは、会社を潰さないこと。 その次に、従業員に前月締めの給与を、遅配なく渡すこと。
国境や税関の向こうで、どんなビジネスの変革が起きているのかなんて、実はどうでもいい。 もしかしたら、その変革が会社を潰すのかもしれないけれども。それは今日や明日の話ではない。
…。
ああ、そう言いつつも私自身は、日本型の SIer ビジネスに与する気はない。夢見がちな経営の末に一回会社を潰したうえでもなお。
みずほ銀が何度もしくじり、ケータイが潰えたのと同様に、車載の取り組みも人件費が垂れ流されるだけの徒労に終わるだろうと思ってもいる。美味しいところは欧州がかっさらっていくだろう。 そして中長期的に、日本のソフトウェア業界は、(かつて見下していた)中国か韓国あたりの技術指導を受けながら、下請けで細々と生きながらえていくのだろうとも予測している。日本のソフトウェア技術者の年収、今でも下請け並みに安いのでね。中国企業以下。
さりとて。 (少なくとも大手の) SIer さんたちは、遅配なく給与を払っているんだよね。決算賞与を出せたところもあるかもしれない。
ならば。正義は、そっちだ。SIer さんたちが、正義。
翻って、SIer さんたちを揶揄したくなっている人たちのなかで、彼らを超える売上高なり利益率を挙げられていない人たち(私もだ)ってのは、正義じゃないんですよ。喩えるなら、海賊とか山賊。 賊は、賊らしく闘っていかないと。 経営もしていないような記者の”正論”を賛同リツイートして溜飲を下げているのは、賊らしくないと思うんですよ。
]]>そんな己のキャリアとは全く無関係に、ちょうどその頃、携帯電話業界では変革が起きていた。 i-mode の登場だった。
それ以前の端末に比べると、i-mode 対応端末のソフトウェア規模は格段に大きい。 そして、(新しいものだから当然なのだが)流用できる過去資産も、ほとんど無い。 いきおい、人足不足になる。
最初は
C言語ができるエンジニアが欲しい。Hello world が作れる程度でも欲しい。現場で教えるから。
そのうち
日本語がわかってキーボードが打てるなら、それでもいいや。あと残業が平気な人
開発規模が膨大になったとはいえ、その時点では、今から考えればヒヨコ並みの小ささではある。 とにかく人手。人手が揃えばなんとかなる。
派遣系および偽装請負系、特に地方のソフトウェア会社クラスタにとっては、特需的だった。 まだ日本の家電系メーカは資金に余裕があったし。 地方の銀行が潰れたりして、組み込みシステム以外のプログラマが若干あまり気味だったりもしていたし。
エンジニアの給与は、時給だけで言うなら昔も今も割と良い。 いろいろな背景の人が面接にやってくる。 エンジニアとしての適性に疑問符が付く場合でも、採用になったりもしていた。 とにかく人を集めてくるだけでお金がまわっていく。そこにはソフトウェア工学なんてものは無かった。
「人を集めて放り込むだけ。ちょろい仕事でみんなハッピー、イイねイイね!」などと思ったりもした。 …坊やだったからさ。
あれから 20年弱。 日本の携帯電話業界がどうなったかは、業界に身を置かなくても、専業主婦でも高校生でも伝え聞いているだろう。
ガラケーの進化に伴うソフトウェア規模の爆発、開発者たちのデスマーチ。 そして、iOS と Android という、きちんとしたソフトウェア・プラットフォームによる、ガラケーの殲滅。
今は、後悔している。 当時、何ができたということも無いし、あれで確かに経済は回り幸せを掴んだ人も居たのだけれども。
そして。
同じような構図が、また日本のソフトウェア業界で起ころうとしているように思えている。
今回は、車載ソフトウェアという分野で。
繰り返されることの善し悪しは、正直、よくわからない。 ただ、言える。繰り返されそうだということだけは。
]]>“デキる”中堅IT経営層は、日本には少なからず居る。 ここでいう”デキる”とは、技術に夢を持ち、資金調達の能力をもち、潰さず500名規模まで伸ばせる人材の層を指す。 同時に “デキる”プログラマも、日本には少なからず居る。
しかし、両者にはミスマッチがある。 両者とも、実績を積んだのは事実であり、生産性を高めた結果として地位なり収入なりを得ている。 そこには両者なりの合理性がある。
日本の中堅IT経営層は、多段下請構造に自らを最適化することによって自社を潰さず伸ばしていった。 日本の産業構造が求めた結果であり、彼らに求められるのは会社を続け雇用を確保することなのだから、彼らの行動は合理的である。
結果として、日本の中堅IT経営層の多くが考えるリソースとは、”人財”となる。 よって、企業の拡大局面においては、ヒューマンリソースが現場に投入されがちである。
不思議なもので、彼らの少なからずは「人月の神話」を読んでいる。 特に CTO やそれに準じる職位にあっては、読んだことがないという事例は(私が知る限り)一例もない。
一方、プログラマにとっては、高い生産性を求められるほど、コンピューティングリソースが必要になる。 言い換えると、コンピューティングリソースが与えられないプログラマは、その潜在能力と報酬が高ければ高いほど、”穀潰し”でしかなくなる。 よって、企業の拡大局面において、”デキる”プログラマが現場の投入を望むのは、”サーバ群”である。
乱読傾向にある彼らの少なからずもまた、「人月の神話」を読んでいる。 「拡大局面において無計画に”人材”を投入するのは無能な管理者の行いだ」ということを、自らの体験と重ねあわせて解釈している。
“人財”と”サーバ群”。これがそれぞれ”デキる”層だったとしても乗り越えることが難しいほぼ唯一のミスマッチと、私は考える。
そして、一般論として、技術専門職には予算執行権が十分に与えられない。 私が見聞きしたケースを元に最悪に近いケースを作ると、こんなストーリが作れる。 現実に起きたものを組み合わせたものだが、事例を特定できない程度には脚色している。 (もしこんなことがストレートに起きたのだとしたら、関連する全員にとって不幸以外の言葉がないだろう)
プログラマはロジカルであろうとする傾向があるので、見切りをつける合理的な理由を与えてしまうと概ね手遅れである。 たった 7800 円のケチで、見切りをつけられてしまう。
年商 50 億の企業で、大げさだとしても社運という言葉が出るなら数億からの商いだろう。 「プログラマのほうもちょっとそこは大人になれよ…」など思わなくもないのだが、まあ、プログラマ界隈で、経営層を擁護する意見は少数派だろう。 読者の中にも、それぞれの職場で「7800 円の高すぎるケチ」を見たプログラマも居るだろう。
そして、経営層がこの作り話を聞いたならば、「まったく勝手な話だ」と憤慨するだろうとも思う。 なぜならば、プログラマに対して、彼らが最も大事であると考える “人財” というリソース提供をしていたから。 彼らは彼らの仕事を全うしていたわけである。「なのにあのプログラマときたら」てな塩梅であろう。
もしかしたら、技術に明るければ明るいだけ、理解が難しくなるかもしれない。 技術を解っているというのと、コンピューティングリソースを使いこなせるというのは、微妙にスキルセットが違うものだ。
両方の立場がわからなくもない私には、なんとも勿体無い話だと思えるのだが。 こんな光景はおそらく日本の中堅IT企業では繰り返されているのだろうとも思う。 「ソフトウェアに国境なんて無い」とはいえ、せっかく、そこそこの規模のソフトウェア産業が立ち上がった日本である。 なんとかならないのだろうか。 国内のコミュニケーション不全でグダグダしているうちに壊滅するのを待つしか無いのだろうか。かつて隆盛を誇った家電業界のように。
「じゃあどうすんのさ」について書いて、一連を閉じたい。 …のだけれども、一気に書いておなか空いたので、明日以降。
]]>今回は、なぜ定着しないのか、私見を書き散らしたい。 下記するのは、見聞きした事例から作り上げた「モデルケース」でしかない。 少なからずの「中堅IT企業」で程度の差こそあれ発生していると想像しているが、広範なケーススタディを行ったわけではない。 くれぐれもこの点には留意されたい。
前回述べたとおり、2つの要因を示唆する。
まず、ひとつ目の要因は、マネジメント不全。 これは、書店に行けば事例が山のように報告されているので、説明の必要は無いだろう。
たとえば、この記事で端的に語られるような”症候群”が、会社を覆ってしまう。
http://business.nikkeibp.co.jp/atcl/skillup/15/283861/121800004/
ネットを活用して伸びた企業の例とはいえ、この記事の筆者は不動産業の経営者だ。 また、読者層が特定業種に依らない一般的なビジネスパーソンだ。 よって、この”症候群”は(少なくとも日本の)企業全般に見られる問題といえそうである。
おそらく、IT企業も例外ではないだろう。 今回は、概ね300〜500名程度の「中堅IT企業」を対象としているため、より”既決感症候群” に罹患しやすいかもしれない。
“デキる”プログラマの多くは、程度の差はあれハッカー気質を持つ傾向があり、自らの手でハックできない物事をひどく嫌う。 “既決感”はハックを放棄した者がもつ感情 であり、その感情を持つ組織に”デキる”プログラマが染まることは ほぼ在り得ない。 解っているプログラマ勢からすると「そら定着しませんわ」としか言いようのない話である。
ふたつ目の要因は、ソフトウェアエンジニアリング系の会社に特有のものと言えるかもしれない。 (しかし、私はその職場環境を知らないので想像を域を出ないのだが、もしかしたら、CADを駆使するタイプのデザインスタジオなどでも類似のことはあるのかもしれない。)
本題に入る前に、少しだけ一般論に寄り道する。
企業には、年収の”壁”がある。 各企業の方針には依るが、大抵の日本企業の場合、役員と従業員との間に設定されている。 スタートアップの場合、これは割とお手盛りだったりする。 しかし「中堅IT企業」の場合は、明文化された給与報酬体系として人事や経理といった間接部門が管理している。
その壁は、地域・業種・景気により変動する。 2015 年、私が主戦場としている領域、自動車業界に関連する組込みシステムの開発を行う中堅企業が首都圏事業所での壁は、概ね年収1000万円らしい。 ちょうどキリがよいので、文面を簡単にするため、(年収)“4桁の人”と”3桁の人”と呼ぶ。
3桁の人と4桁の人には、幾つかの違いがある。 しかし、キャリアポルノの本を書きたいわけではないので、細かいことは打ち捨てて、最大の違いにのみ言及する。
それは、リソースを活用する能力の有無である。
IT業界というのは不思議な業界である。 故スティーブ・ジョブズが”知の自転車”と呼ぶコンピュータをレバレッジとする知識集約的な産業であると同時に、”人月”という言葉に代表されるように労働集約的な産業構造を持つ。
言い換えると、IT業界で成果を上げるためのリソースは大別して2つある。コンピューティングリソースと、ヒューマンリソースである。 4桁の人になるためには、両方、最低限でも片方のリソースを駆使して利益に貢献する必要がある。
ここまでの話は、日本に限らない。 程度の差はあれインドだろうがカリフォルニアだろうが同じである。
もう散々言い尽くされているので根拠をいちいち挙げないが、日本のIT産業は、多段下請構造により成り立っている。 言い換えると、ヒューマンリソースを上手く調達し活用した者が管理層として出世していく。 いわゆる「プログラマ○○年定年説」や「PG で下積みして SE に “出世する”」といったキャリアパスも、ここに由来する。 メインフレームを象徴とする SIer で顕著だが、組込みシステムなど広い分野でも、同様の傾向がある。
つまり、取締役にまで出世した「中堅IT企業」のメンバは、そのキャリアパスの最初がエンジニアであろうとも、ヒューマンリソースの活用能力により4桁の人になっていく。 これは別に悪いことではない。 経営層と言うのは、企業を潰さないことが最低限の責務であり、雇用を拡大し社会に資するのが期待される職位だ。
一方、”デキる”プログラマの少なからずにとって、生産性の源泉は、ヒューマンリソースの活用では無い。
むしろ、多くのプログラマはある種の古典的なオタクであり、対人交渉能力の高さは保証されない。 (少数ながら、社交性のある”デキる”プログラマも存在する。何事にも例外はある。) 彼らの生産性の源泉は、コンピューティングリソースの高度な活用にある。
3桁プログラマは、余剰な計算機資源を与えられても、それを使いこなすことができない。 32コアのCPUやPCIバス直結のSSDを与えられても、せいぜいExcel方眼紙で仕様を作る程度のことしかしない。 Excel方眼紙自身の善悪はとりあえず脇に置くとして、「豊富な計算機資源を与えるのは無駄だ」と経営層に見做されても仕方がない。 この辺りは、鶏と卵の問題ではあることは否定しないが。
一方、”デキる” 4桁プログラマは、計算機資源があればあるだけカイゼンのために使い切る。 CI サーバを立ち上げ、メトリクスコレクタを整備し品質管理し、ソースリポジトリと成果物リポジトリを分離し、チャットサーバを立ち上げ、チャットボットを投入する。 DBサーバを立て、Micro PaaS を立て、Excelデータベースは速成したRailsアプリに置き換えていく。
そうすることで、ヒューマンリソースが起こすエラーを可能なかぎり排除していく。 正しい意味での”ソフトウェア工場”を構築し、本人や所属したチームが、真に属人性が必要な、設計や開発に没頭しようとする。
特に、企業の戦略におけるチームの重要性が増していく局面の場合に、この傾向は顕著である。 コミュニケーションコストや不慣れな途中参加メンバが起こすヒューマンエラーがチームの生産性をどれだけ損なうのか、4桁のエンジニアは経験をもって身にしみている。
「中堅IT企業」の経営層とプログラマの間で何がズレているのか、もう答えを示したようなものなのだが。 私見を纏めないでは「日記」にならないので、あと1〜2回引っ張る。
]]>私は、プログラマだ。なんだかんだで職歴は20年を超えた。 同時に、かつて10年ほど小さなソフトハウスを経営していたし、今も代表1名の法人を持っている。
そんな経歴により、プログラマ諸氏からは概ねプログラマとして接していただき、経営者諸氏からは稀に経営者としての意見を求められる時がある。 2つの異なる立場についてほぼ同時並行で見聞きする機会に恵まれるのは、おそらく珍しいことだろう。 そんな経験の中で思ったことを、書き散らしておく。
もちろん、守秘義務や職業倫理というものもあり,複数の事案をミックスし曖昧にしてある。 特定の企業についての邪推は無用。ひとつよしなに。
広くIT業界は、長きに渡って、「人手不足!」と叫んでいる。 そして「”使えない人”ばかり面接に来る」というボヤキが続く。 つまり、”デキる”“人財”が来ない、または定着しない。そういうことらしい。
このボヤキは、スタートアップでも聞かれる。しかし私見では、圧倒的に、受託中心からの転換を狙っている中堅 IT 企業で多い。
考えると、もったいない話である。 スタートアップは成功すればリターンは大きいがリスクも大きいとされる。 ある期間を生き残ってそこそこの規模まで成功した会社なら、財務的なリスクは小さい。 “人財”が定着すればその会社は大きく伸びるだろう。 “デキる”“人財”も、むしろ”デキる”からこそ、その辺りのソロバン勘定はできるだろう。
しかし、現実にはボヤキは消える気配がないどころか、大きくなる一方であるように思える。 日本人にありがちな謙遜のようにも見えない。なぜだろうか。
私には、2つの要因が思い浮かぶ。うち2つはすでに広く指摘されていて経営層にも周知の事項だ。 残りの1つは、ソフトウェアエンジニア界隈では形式化されつつある暗黙知だ。 しかし、経営層界隈、特に中堅IT界隈においての知見共有は、あんまりされていない気がしている。
定義を曖昧にすると例外事例が無駄に多くなるはずなので、ここで「中堅IT企業」についてスコープを絞っておきたい。 ここでは、概ね下記のような条件を設定する。
社員数で言うと300〜500人、年商で50億くらい。社歴は概ね20年以上。
この規模の会社は、全ソフトウェア業界のうちで、相対的に好調である。 このことは定性的・定量的の両面で示すことができる。
定量的には、ソフトウェア業界の懐事情は、経済産業省が行っている特定サービス産業実態調査によって調査されている。 最新データでも、他の規模が軒並みスコアを落とす中、この規模は相対的に好調であることがわかっている。
定性的にもこの規模は活発と言える。 環境性能や自動運転車をキーワードにして、自動車車載ソフトウェアの世界では国際競争が激しくなってきている。 そのような先端の話題に関連して業界系マスコミを賑わすのも、概ねこの「中堅IT企業」規模の独立系ベンダである。
活発で景気も良い。 本稿では具体例を示さないが,日本のソフトウェアの品質は諸外国に比べて悪いわけでもないということも、定量データとして知られている。 なのになぜ中堅IT企業で人材不足なのだろうか。
問題意識の提示と定義だけで長文になってしまった。
続く。
]]>人を殺しても精神耗弱なら酌量されるわけです.少なくとも法的には.
ましてや,正常な精神状態なら一番愛おしい(ことに世間ではなっている)己を殺すっていうのは,よっぽどのことだろうと思うわけです. 高瀬舟どころの話ではないですよ.
…自殺には,おそらく,さまざまな動機があるでしょう.一律に云々は言えないでしょう. その動機の軽さに憤慨するような例もあるでしょう.
ですが.
世間一般の常識として,肝臓大動脈瘤破裂のように,己の不摂生との関連はあれども健康な意志とは無関係な理由で急逝した人を,「護るべき人,履行すべき責任,それらがあるなかで捨てて死ぬなんて無責任」などとは言わないわけで.(…死を悼むレトリックとしてはしばしば言いますけれどね…)
一方で,脳の病に侵された人が急逝したときに「とっとと逃げ出した」と言えるのだとしたら,ナニカがおかしいと,私は思うわけです.
まあ,「死んじゃダメだ」くらいまでの気持ちまでは,同感なのですが. 明らかに有能な科学者が,どうやら手続きが杜撰だったらしいとはいえ,ここまで追い詰められる理由は,あったのだろうかと.
こういうエントリを書く…,マスコミお得意の,炎上マーケティングに踊らせれちゃいました…かね.
]]>Arduino を始めとする,省ピンのマイコンを使っている方にはピンと来ない話かもしれませんが.
ある程度のピン数を持つ,機器組み込み向けのCPUボードには,ベースボードの接続用に,2列のヘッダピンを使っています.
作業机にあった,CPUボードを幾つか見繕ってきました.こんな感じ.
組み込み向けのCPUというのは,センサやらアクチュエータやらを操作することが多く,やたらとI/O端子がついています. それらを一列に配置すると,基板のサイズが大きくなってしまいます.
そういう理由は解るのですが,一方で,試作する側としては2列では困る時があります. 2列だとブレッドボードに刺せないのです.ショートします.
最初からきちんとしたベースボードの基板を起こしたり,ユニバーサル基板で頑張ればよいのではあります. しかし,ブレッドボードはお手軽です.一度楽を味わってしまうと,人間は後戻りできません.
そんなわけで,ケーブルを自作したりするのですが,それもなかなか骨の折れる作業です.
手抜きをして,接触が不安定になりがちなメスのジャンパワイヤーを使って,3D配線を行うという暴挙に出たりします. それはいけません.
など考えながら,CPUボードを仕舞おうとして,私の会社で製造販売している製品が目に入りました.
そのコストパフォーマンスの凄まじさに,一時代を築いた感もある Raspberry Pi ですが,お手軽電子工作のツールとして見た時に,一つだけ欠点があります. それは,GPIO の端子が,13x2列のピンヘッダであることです.
これをケーブルで引き出しても,2列だとブレッドボードにさせないのです.ショートします.
…あれ?
そのため,ブレッドボードに刺しやすくするような変換基板が売られています.
…あれ?
これ, Raspberry Pi 以外の組み込み用CPUボードにも使えるのでは…?
弊社ジャンク棚から,基板を2枚拾ってきました.
Amazon で販売中の,RaspberryPi対応GPIO変換基板キット (ケーブル無し)の基板です. 製造過程で小キズがあったため,出荷から弾いたものです.
本来,リボンケーブルで繋いで使います.例えばこんなふうに.
ただ,このままの使用法だと,ケーブルコネクタの両脇に幅があるため,CPU基板のピンヘッダと干渉しそうです. なので,13x2列のピンフレームと置換します.
そして,はんだ付けをします. 今回の私の用途では,左右両方にコネクタが必要でしたので,片方の基板は裏返して鏡像なるようにしました.
結果,こんな感じになります. 専有面積は大きくなりますが,ベースボードの設計について,ある程度の目処が付くまでの試験的なものですので.
この方法で1列化できるのは,通常の方法(そうでない方法については後述)では連続した26ピンになります. 多くの組み込み向けCPUボードは,それよりも遥かに多くのピン数があります. しかし,特定の機能に関するピンは,ある程度近い位置に配置されるでしょう. 目的を絞って使う際には,便利に使えるのではと思います. 接触が不安定になりがちなメスのジャンパワイヤーを使うよりも,安心できるのではないでしょうか.
実は,この変換基板,30ピンまで対応できます.
本稿を書く目的で,秋月まで行ったのですが,13x2列のピンフレームが品切れでした. (Raspberry Pi 人気のせいでしょうか.) 仕方なく14x2列の品を買ってきたのですが…,
基板に当ててみて,ひらめきました.
基板には,LED点灯など,ちょっとした機能をブレッドボードなしで実装できるよう,ユニバーサル基板と同等の箇所を用意してあります.この部分を使うと,最大30ピンまで一列化ができます.
今回,一列化を試みるきっかけとなったUCB-BF512基板は,15x2列のピンヘッダがついています. つまり,やろうと思えば,30の全ピンを一列化できるのでした.
基板のアートワークをした私自身,想定外のことでした.
]]>Monami-ya.mrb って,twitter 辺りでは目にするけれど,どんな環境で作っているのか判らない
はい.断片的にはtweetなどしていますし,OSX 上でのビルド環境等も(今のところ消極的に)公開しているのではありますが.
ハードウェアがどんな感じなのかは,なかなか想像つかないという方も多いと思います. 特に Ruby 系の方は,組み込みボードそのものに面識が無かったりするでしょうし.
写真を撮ったので,並べておきます.
しょっぱなから写真を撮り忘れました. でもまあ機種名を挙げれば,想像つくかと思います.
MacBook Pro 2.8 GHz Intel Core 2 Duo. すいぶんと古い箱です. メモリは8GB.HDDは500GB.
この程度のスペックでも,monami-ya.mrb のビルドは,1分以内に終わります.
正直言うと,もう少し良いのが欲しいですけれどね…GCCのビルドまで行う場合には…. (会社では,GCCのビルドは,クラウド上のビルドサーバを活用しています)
開発のメインとなるターゲットボードは, BF533CB です. Blackfin という DSP を積んでいます.メモリは RAM 16MB + 内蔵若干,永続ストレージは SPI Flash.
DSP というと特殊なプロセッサという印象を持たれるかもしれません. char のビット幅が16だったり32だったりという変態,みたいな.
しかし,Blackfin に関して言えば,普通の RISC プロセッサとして使えます.char のビット幅は 8 ですし. あまり知られてませんが,品番によっては Microsoft .NET-MF が動きます.uClinux も動きます. しかも 500MHz の高速動作です.
問題は,情報が少ないことです. 特に日本語の情報をwebで求めようとすると,片手で収まるくらいの開発者にしか当たりません. (いや,商社やメーカの中などに入れば,日本人の開発者も,もちろんそれなりにいらっしゃいます)
CPUボードだけでも monami-ya.mrb は動作しますが,シリアルポートのコネクタが便利なので,マザーボードを併用しています.
BF533CB は,シンプルでとてもよいボードなのですが,今後の量産計画は未定のようなのが難点です. 近日中に,BF533CB から,金子システム製の UCB-BF512へ変更する予定でいます.
最近の廉価帯ARMボードだと,USB-serialのアダプタをオンボードで積んでいる場合も多いですが,現在使っている BF533CB にはありませんので,外付けしています.
シグナルが3.3Vレベルであれば,何を使っても良いのでしょうけれども,私は秋月電子通商のFT232RL USBシリアル変換モジュールを使っています. モジュールのみで900円と,微妙なお値段ではあります. しかし,UART は,Lチカが済んだあとから開発終了までデバッグ用として永く使うものですので,安定していることと,壊れても代替がすぐに手に入るほうがよいと思います.
UCB-BF512 は,出荷時点でブートローダとして u-boot が書き込まれていますし,BF533CB も一度 JTAG 経由で書き込めば,同様に u-boot が使えます.
monami-ya.mrb は,uClinux と同様に u-boot 経由でブートできます. よって,JTAG デバッグアダプタは不要です. …と言えれば話は楽なのですが,GDB 無しでは PC 上の mruby 開発が難しいのと同様に,JTAG デバッガなしでの monami-ya.mrb の開発は困難を極めます.
私が使っているのは,PizzaFactory Tiny JTAG です. つまるところ JTAG ですので,ARM用の JTAG アダプタや FT2232 が載ったモジュールを使うことはできるはずなのですが…. 私自身が PizzaFactory Tiny JTAG の開発を行った時に,BF533 プロセッサで謎の相性問題を引き起こした経験があります.
納期の無い趣味なら,相性問題でアタマを抱えるのも愉しみのうちでしょう. 少しでもお仕事が絡んでいるのなら,人件費と比べて,サクッと買ったほうが安いです.
ざっとこんな感じです. (組み込み開発 == ロジアナやオシロといった計測器が積まれた机),のような印象を持たれるかもしれませんが,実際のところ,RTOS や VM のコア部分での開発では,それらの計測器はあっても無駄です.プローブを挿す場所がありませんから.
開発ホスト機を除くと,予算的には,1万5千円もあればお釣りが来るという感じでしょうか. 「STM32F4-discovery は 2千円でお釣りが来るのに!」っていう気もしますが,スペックが違うので比べるのは野暮かなぁとも思います. STM32F4-discoverty は .NET-MF は走りますが,uClinux が走らないですし.
取り留めもないですが,本稿は日記なので,纏めなくても良いですね.それでは.
]]>設計思想に関する話です. 一つのシステムに対して,設計思想は幾通りもあるのが普通です. どの思想にも,一定の理があります.
読者が何かの拍子に,軽量Ruby系実装を選ぶことになった際に,参考になればと思います.
ムーアの法則は,まだしばらく正しい状態にあるでしょう.
つまり,市場シェアが高い(有り体にいうと開発資金のある)があるアーキテクチャには,まだまだ計算機資源が潤沢になる余地があります. 一方,市場シェアが低いアーキテクチャは,性能向上は伸び悩むでしょう.
別に特定のアーキテクチャを云々したいわけではありませんが,SuperH アーキテクチャは,一時期,動作クロック数をメキメキと上げていきました. 今は, ARM Cortex アーキテクチャがその状態のように見えます. PIC32 も,他の PIC アーキテクチャが援軍となっているのか,頑張っているようです.
それが,市場原理というものであります.
このようなメインストリームのアーキテクチャ(今なら Cotrtex)では,ソフトウェアの規模がどんどんと成長します. 多くの RTOS は API が枯れているはずなのですが,ドライバやミドルウェアが成長していきます. 本棚と本の関係と一緒で,計算機資源があるかぎり,ソフトウェアは膨張していきます.
一方,シェアの低いアーキテクチャとそのユーザは,その姿を脇に見て,歯ぎしりをして済ますわけにはいきません. 死活問題ですから. そのため,一部だけでも移植して,メインストリームが享受している生産性の,喩え一部でも得ようとします.
しかし,サブセットは,所詮サブセットです. シェアの低さをひっくり返すことはできず,そのうち,アーキテクチャが消えます. それが,市場原理というものであります.
動作環境がないソフトに価値はありません. せっかく作ったサブセットは,ビット世界のどこかに霧散します.
もちろん,成功する例もあります.
機器組み込み屋からWeb屋まで幅広く知られている例として sqlite があるでしょう. 他の SQL データベースからすれば,サブセットです. しかし,sqlite は,型が極端に少ない,ライブラリとして動作する,など,設計思想が他と一線を画しています.
mruby もまた,機器組み込み以外の分野で,一定の成功はしていると見てよいでしょう. mruby も他の Ruby 実装から見ればサブセットです. しかし,先行する Lua の VM 実装を研究し,他の Ruby 実装には無い特徴を有しています.
サブセットで危険なパターンというのがあります.
実装の一部を切り取ってきて,制約の多いアーキテクチャに移植する,というものです.
「8bit の PIC や AVR に uITRON のサブセットを頑張って実装する」というのは典型例の一つです.
アーキテクチャの制約のため,実装をサブセット化した,というものには,継続性に対するリスクがあります. 上記uTRONの例なら「16bit の使えばいいじゃん.値段変わらんよ」で存在価値は容易に0になりますから.
無論,全てのプロジェクトが失敗するとは限りません.
成功した一例として uClinux が挙げられるでしょう. これは,MMU サポートのない CPU のために Linux のサブセットを作る,というプロジェクトでした. uClinux の場合は,MMU をサポートしない CPU は,かなり長い期間存在する,という見切りの旨さがありました. MMU が無いという前提を立てる一方で,メモリ容量やクロック数には制約がかかっていません. それらは,MMU をサポートしない CPU であっても,性能向上が見込めるからでしょう. そして,実際に,ハイエンドマイコンでは,そうなっています.
今手元にあるチップのメモリやクロックに制約があるから,という理由でのサブセットは,徒労に終わります.中長期的に見て. (…って書くと呪いをかけているように思われるかもしれませんが.)
mruby のコミットログを見た人からは,
そうは言っても,あなた,mruby から stdio.h サポートを外したり,さんざサブセットにしてきたじゃないの
と言われるかもしれません.
ええ,その通りです. そして,まだ,本家 mruby にも,その fork である monami-ya.mrb にも,サブセット化の余地が残っています.
しかし,それらは,特定のアーキテクチャで動かしたいからという動機から来るものではありません. (C99標準が定める)freestanding 環境での実行を確約するためのものであったり,UARTすら用意できないという 機器組み込みシステムでは古今東西普遍的にあるシチュエーションへの対応だったりというものばかりです.
サブセット化をし易い “芯” を作っておくことは大事です. しかし,詰め込むことを先にするのは,リスクが高い. monami-ya.mrb での各種拡張を手掛ける際に,私は,そう考えて設計と実装を行いました.
私も現役の組み込み屋ですから,「そうは言っても目の前の機器に組み込まないと成果にならないのよ」というお話は解ります. 案件ベースでは,サブセット実装をせざるを得ないでしょう.
そして,サブセット実装が持つ,得も知れぬ魔力が解らなくもないです. 私もガラパゴニッポンの組み込み業界で育ちましたので, 実装者として,純粋に,愉しい.不思議な魔力.
しかし,イマイマを乗り切るための方便と,この先何年か使われることを前提とした提案がどうあるべきか, 現在的実装がどうあるべきかというのは,分けて考える必要があるはずです.
なので,(サブセット実装の成果物である)最小サイズの追求を,当面の monami-ya.mrb では行わないのです.
]]>加えて,RTOS とバインドする積極的な理由を述べておきます.
理由はある程度の理詰めはあるものの,結局のところ「オレはこう思うんじゃい」という色彩が強く,別にそうしなくても軽量Rubyはベアメタルで動きます. 時間と予算が潤沢にあるなら,ね.
とはいえ現実は.
別段のファンドが獲得できているわけでもなく,取れる時間も限られ,加えて
過去の事例だとこの手のOSSは長期的には失われる結果になりそうです
という呪いまでかかった状態なので,素早くカタチにしないと,呪いが成就してしまうのでした.
すべては大目標の実現のためです.
\ゆるふわ Ruby だけで,ガチ組み込み開発をしたい/ that’s all.
対極的な大目標として「mrbgems を全部削って,parser も削って,バイトコード実行だけできればよい.場合によってはバイトコードの命令セットも削る.」という設定がありえます. これもまた組み込み風味,いや,むしろ従来型の組み込みシステムっぽくて安全な気がします.
ですが,私はそこには寄り添いません. 先行事例が既にあるから,というのも理由の一つです. 加えて「そこまでするならCで書くわ」とミもフタもなく思うからです. コードゴルフをしたいなら,C言語を使えば良い.その用途ならばC言語は最強です.Ruby で挑む理由がありません.
さてはて,ゆるふわを極めるには,irb 相当の REPL がオンボードで動くことは必須です.
現実的な解として,ホストベースirbの実装が既にあります.私には思いつきませんでしたし,なるほどなぁと関心しきりです. なのですが,ホスト側にもソフトウェアが要る点で,私の想定分野では,重いなぁと思います. 昔の 8bit BASIC マシンやポケコンのようなゆるふわ感はありません.UART で繋ぐだけで REPL が立ち上がってほしい. (ホストベースirbの実装理由が「”ゆるふわ”にしたかった」なんてことは絶対に無いでしょうから,私がどう思おうとも,実装の価値がどうこうなる話ではありません)
先行事例の実装で十分な領域があるのは,アタマでは十分に解っています. 今ここに書いているのは,「ぼくがかんがえたさいきょうの」厨二病的な放言です.
REPL を内蔵するとなると,UART ドライバが必要です.USB-serial ならさらに良いですね.
さらに,”ゆるふわ” なら,何も考えずに Socket や File を使い出せないと嘘です. ファイルシステムやプロトコルスタックを載せたくなります.
きっと使う mrbgems も,中で malloc とかからループとかバンバン使っています.
うーん,”ゆるふわ”. でも,その環境で,ガチ組み込みをしたいわけです.
uClinux 載せるとか,ご冗談でしょう?
しかし,ファイルシステムとプロトコルスタックを,割り込みハンドラから書くのは… 書いている間に,呪いが成就しちゃいます.ねぇ.
そんなわけで,monami-ya.mrb が RTOS とのバインドを推進する理由は概ね述べてしまった気がしますが…. ざっくりいって,理由は,3つあります.
仮にRTOSを入れなかったとしても,UART,タイマ等々の割り込み処理は書かなければなりません. RTOSと比べて自前で書いたほうが十分に高信頼であれば,書くのも悪くないでしょう.
ですが….
TOPPERS や uT-Kernel を始めとして,有名どころの RTOS には,第一線の研究者やエンジニアが関わっています. 彼らが日々バグを潰し合っているコードのほうが,明らかに信頼できます.
(多くのRTOSでは,最小構成に UART ドライバを含みません. しかし,UART は初歩的なデバイスです.大抵の RTOS ではドライバのコードが提供されます.)
RiteVMの実装はほぼ1つでしょうけれども,マイコンはARMで集束に見えているようでいて, いまだにたくさんあります.特にガラパゴニッポンでは.
ARMにしても,セミコン各社でペリフェラルに特色を持たせた結果,なかなか心折れる状態です.
RTOS の上に構築した場合,mruby より下の層を気にせずに保守できます.
保守可能な動作環境の狭さは,その上で動作するソフトウェアのシェアに響きます. 軽量Rubyは,クロスプラットフォーム動作がメリットの一つです. それのメリットを活かせないようでは,自ら潰しているようなものでしょう.
おそらく,最初期のユーザは
C言語で書かれた既存資産を活かしながら,mruby を使ってみたい
と言ってくるでしょう.
Rubyでの書き換えで発生するコストやRubyで実行したときの速度低下のリスクを考えると,保険をかけながらの導入をしたいと思うはずです.
mruby が動作するようなレベルのマイコンなら,既にRTOSを前提としたソフトウェア資産が存在するでしょう.
もし「全部をRubyで書き換えるかmrbgem化しないと,始まりません」と言ったとしたら,おそらくユーザは逃げだします.
ファーストユーザを掴めないなら,普及を考えるなんてありえないでしょう.
そんなわけで, monami-ya.mrb は,従来の mruby 開発者が狙っていたところとは若干違ったところを目指しています. でなければ,fork なんて面倒なことをする必要なんて,なかったわけですし.
私は,私が狙った分野には,2つの大きな需要があると思っています.
私の実装が生き残れるか,というのとは,また別の話ではありますけれども.
]]>mruby 自身もC言語に比べて処理に時間がかかるところに,RTOSが入るとさらに遅くなったりしないのか少し心配です.
個人が特定されるどころか,同じような直感を持たれる方,案外多いのではないかなと思います. 機器組み込み業界で働いておられるエンジニアの中にもいらっしゃるのではないかな,とも.
端的に言うと,RTOS が入ると遅くなるというのは,概ね誤解です. いやもちろん RTOS がゼロオーバヘッドだと言っているわけではありません.
いまや会社の製品の機能として提供されている部分なので,本来なら会社の公式ページに書くべきところですが,そうすると定量計測してホワイトペーパーにしないと格好がつきません. そこまで喫緊の話でもない(非公式なやりとりですし)ので,こちらに書いておきます.
RTOS の前に OS とは何か,から確認していきましょう. 多くのデスクトップ環境では,CPUのコア数はたかだか8個程度でしょうけれども,OS上ではより多くのCPUが存在しているかのように見えています. 本当は1つしかないメモリ空間は,MMUなどメモリ管理ハードウェアの支援を得て,プロセス毎に分けつつも,プロセス内では全メモリを専有しているように見せかけています. ストレージも,本当は1つしかなくても,ファイルシステムという構造を導入することで,複数のプロセスに競合しないように調停されます.
ざっくり言うと,OS というのは,何かを抽象化し管理し保護するソフトウェアです. 現在的なOSのほとんどは,プロセスと呼ぶ抽象化した計算機を管理し,処理がプロセスから外に漏れないようにして,物理的な計算機資源を保護しています.
RTOS の抽象化対象は,CPUです. 実際には全ての処理は時分割されているのですが,それぞれの処理はCPUを専有しているものと(RTOSによって)勘違いさせられています. そして保護対象は,RT == Real Time が示す通り,時間です. なので,多くの RTOS は時間以外のリソースの保護については,かなり無頓着です. 最近になって,セキュリティや機能安全についての世論が固まったため,リソース保護機能付きのRTOSも増えました. それでも,リソース保護機能が時間保護を阻害するとなれば,時間保護のほうが優先されます.
ここでいう時間には,2種類あります.
ひとつは物理時間です.これは一般的な「壁時計」と同じと思って頂いて構いません. RTOS自身オーバヘッドが影響するので,重要といえば重要ではあります. しかし,CPUに与えるクロック次第で改善されやすいものでもあります.
もう一つは実行順序制約です.RTOS ではこちらのほうが重要です. RTOS では,実行順序が事前に見積もれなければならない,とされます. そして,優先されるべき処理については,他の処理を止めてでも実行して良い,とされます. 他の処理を止めれば,実行順序を見積もりやすくなりますから.
通常のOSにも実行優先度の概念はあります.しかしRTOSの場合は強烈です. アプリケーション設計者が必要と思うなら,デバイスへの割り込みすら止めることができます. CPUが持つ計算資源の全てを,特定の処理に割り当てられる. それが RTOS の特徴です.
RTOS は時間を管理する OS なので,これは当然の特徴と言えます. (計算資源 == 計算に要するクロック数 == 時間)ですから.
RTOS は,複数の処理(タスク)に対して,それぞれが CPU が専有しているかのように見せかける抽象化を行っています. 抽象化の裏には,オーバヘッドがあります. これは,時間量として見ると,コンテキストスイッチに要する時間で表されます. 商用 RTOS の星取表で,この数値が俎上にあるのを見たことがある方も多いでしょう.
あまりにも商用 RTOS の営業さん達がけたたましく言うので,このオーバヘッドが無視できないと誤解する方が後を絶ちません. しかし実際のところ,このオーバヘッドが致命的かどうかは,アプリケーションに依ります.
mruby は,大目に見ても C言語で書くよりも2桁のオーダで遅くなります. 「週に何度も口にしない飴玉のカロリーを気にするなら,まず毎日の三食を見直しましょう」という喩えでお分かり頂けますでしょうか.
なお,RTOS のオーバヘッドとして有名な指標には,コンテキストスイッチの他に,割り込みへの応答時間もあります. こちらも,似たような議論が成り立ちます.
とはいえ,「RTOS は重い」にも相応の理由は思いつきます. それは,優先度設計の難しさ,です.
既述の通り,RTOS では,高優先度の処理は,CPUへの割り込みさえも止められます. このような条件で,高優先度で実行される処理の設計が悪くCPUを専有した場合は,システムは最悪の状態になります. 低優先度の処理にはいつまでたっても,処理の機会が与えられません. (ちなみに,このような状態に陥った低優先度の処理は,RTOS 界隈の用語では,”飢餓状態”としばしば言われます.)
日本の組み込み業界では,優先度設計から詳細実装まで全てを一人でこなす例もありますが, 上流が検討もしないで適当に優先度を割り振った仕様書を元に,受託で(再受託で(再々受託で))詳細を実装するということが,しばしば行われます. こういうケースでは,組み上げてみたら真っ当に動かない,ということは,珍しくなかったりします.
それは設計の不備であり,RTOS が悪いわけではないのですが. 外から買ってきた RTOS をスケープゴートにする,ということが起こるのは,人として理解できないわけでもありません.
…もちろん,高優先度の処理で無限ループなどされるとダメですけれども.
優先度の設定に気をつけている限りにおいて,monami-ya.mrbはRTOSと併用しても処理が重くなったりはしません. その辺りには,20年前から RTOS 関わり,TOPPERS/FI4 など RTOS の実装にも関わった経験を活かしてあります.
本家 mruby は…? メモリアロケータの部分をキチンとケアできれば,大丈夫にできると思いますよ.たぶん.
]]>注: 2014-06-17 00:30:00JST バグフィックスがあったので,コードの引用を修正し,体裁も整えました.
昨日で,monami-ya.mrb への sandbox サポートについて,峠を超えました.
その際,sandbox が必要な理由の説明で,スレッドの使い方について説明しました. つまり,monami-ya.mrb は,下位層にスレッドライブラリ(RTOS含む)の存在を暗黙的に期待しています.
RTOS 含めると,動作が重くなるんじゃないの?
みたいなことを仰る方も,世間には稀にいます. それは概ね誤解です. その辺りの話は,別の機会に取り扱いましょう.
注: 本稿は,mruby のビルドシステムと,uITRON4.0 仕様でのアプリケーション記述についての知識があることを前提として書かれています.
って思っていたのに,とんでもねぇ修羅の道だったという.
— もなか (@monamour555) June 15, 2014
いやほんと,組み込み向け軽量 Ruby って言葉を聞いた時に,大いに期待したのですが. 組み込みって,分野広いですから,仕方ないと言えば仕方ないのですが.
愚痴っていてもしかたがないので,fork して拡張するのです.
せっかく軽量 Ruby で “ゆるふわ” したくても,RTOS の細かい差異に振り回されるようではゲンナリです.
OSEK の OIL とか,uITRON/TOPPERS のコンフィギュレーションファイルとか,書きたくないわけです.
そこで,static thread binding の登場となります.
static thread binding は,sandbox 同様, monami-ya.mrb の master ブランチにも develop ブランチにさえも入っていません. なので,仕様は微調整される可能性があります. でも,もう手元では概ね動いているので,ガッツリ変わるということは,ないでしょう.たぶん.
“static” と謳っているくらいですから,記述箇所は build_config.rb になります.
1 2 3 4 5 6 7 8 9 10 11 |
|
前半は,sandbox です.後半の conf.thread でスレッドを定義します. あまり説明の必要は無いでしょう. アクセサは,こんな感じです.
1 2 3 4 5 6 7 |
|
activate は,システム起動時に,スレッドを実行開始の状態にするかを決めます. Win32 や POSIX では無視かエラーかかもしれません. RTOS ではシステム起動時のタスクの実行状態を決められることが多いので,重要なパラメタです.
stack_size は,RTOS では必要でしょうけれども,Win32 や POSIX なら無視されるのでしょう. type は,uITRON/TOPPERS の場合には,:task, :cycric, :alarm, :interrupt とかになるでしょう.
script_path は,そのスレッドが実行する Ruby (mruby)スクリプトを指定します.
1 2 3 4 5 |
|
とか. 普通のスレッド(タスク)なら,while ループの中で何かをさせる感じになります. 上記の場合は,BF533CB ボード上の LED を 1000ms 周期で Lチカしています.
ワンショットのスレッド(uITRONでの,alarm / cyclic / 割り込みハンドラ)では ループをさせないで終わらせることになるでしょう.
ええ,割り込みハンドラも書けます. monami-ya.mrb ならね.
性能的に使い物になるかどうかなんて気にしてはいけません. ムーアの法則が解消する可能性が高いからです.
割り込みハンドラを RiteVM (mruby の VM) で書く場合に,物理時間制約以外のリスクがあるとすると,malloc 時のロックとメモリ枯渇です. monami-ya.mrb では,TLSF アロケータの採用による,mrb_state 間のロックフリー化をしてあります. また,VMのスタック上限をmrb_state毎に指定可能にしてあるため,どうしようもない枯渇は起こし辛いようにしてあります.
現在の本家 mruby では,これらの対応が抜けています. 本家のままでは,割り込みハンドラを Ruby で書くのはリスクが高すぎて実用不能でしょう. まさか割り込みハンドラまで書くとは思っていないフシがあるので,たぶん今後も.
build_config.rb の記述から,下位のスレッドライブラリへのバインディングに必要なコードを静的に生成します.
現時点では,TOPPERS/JSP 用のコードを生成します.決め打ちです. 将来的には, toolchain のように,動作環境の OS を build_config.rb に記述することで,生成されるコードを,変更可能になるべきでしょう.
具体的には,このようなファイルができます.
1 2 3 |
|
uITRON4.0 のコンフィギュレーションファイル
1 2 3 4 5 |
|
TOPPERS/JSP側が用いるヘッダファイル
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
conf.script_path で指定したスクリプトファイルのコンパイル結果
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
ITRONタスクのエントリポイントと,カーネル初期化ルーチンのエントリポイント.
これらのうち,Cソースコードは,コンパイルされ libmruby.a に纏められます.
最終的に,TOPPERS/JSP の libitron.a とコンパイルするところは,monami-ya.mrb の外です. イマイチ,パンチに欠けますが. あんまりタイトにバインドさせると,OS毎のビルドシステムの差異に苦しめられることになるので,今のところはここまでです.
セルフビルドが可能な環境では,全てを隠ぺいすることは容易でしょう.
設計方針は,繰り返しになりますが「ゆるふわ Ruby でガチ組み込み」です.
Arduinoのスケッチみたいなのにも存在価値は認めますが,狙っているのは,そこではありません. mruby と Arduino的なライブラリの組み合わせについては,kyab 氏が約1年ほど先行しています. そこを今更になって再発明する必要性は無いでしょう.
ここで,monami-ya.mrb は全てのタスクを Ruby で書くことを強要しては いない ということは,注目して頂きたい点です.
大目に見ても,RiteVM の処理時間は,C で書く場合より 2桁のオーダで遅いでしょう. なので,物理時間制約の大きなところでは,Cでタスク(スレッド)を書きたくなるはずです. そもそも,いちいち Ruby に移植しないと使えないというのであれば,使う気が削がれます.
TOPPERS にせよ uT-Kernel にせよ,既に資産があるわけです. それら資産を活用しながらも,新しいことができる. そういう設計方針で,この機能は作られます.
それと,この機能はスレッドバインディングに特化しています. スレッドがある以上,スレッド間の通信機能が必要になります. この設計では,通信機能は mrbgems として提供されるべき,と割り切っています.
静的OSの場合,mrbgems だけで通信機能のためのカーネルオブジェクト生成を行うのは 辛いはずですが…それは今後の課題です.
MITライセンスで出します. 誰かが本家にプルリクを投げることは止め用が無いですし,止めませんが. 常識的に考えて,マージは無いでしょう. ターゲットが違いすぎます.
]]>sandbox の需要を理解するには,前提として,Webサーバと RTOS とで,スレッドの使われた方が違う,ということを,知識ではなく,腹に落としていないといけない.世界観の問題.
— もなか (@monamour555) June 14, 2014
mruby のコアを弄るような方々は,知識としては心得ているはず,だが.
など言って,実装理由を詳説しないのは,ちょっとイケ好かないかなということで.
本題に入るには,OS が提供する thread の使い方について,寄り道をする必要があります.
注: 本稿は,mruby の内部構造,特に,mrb_state と mrbgems の関係を理解していることを前提にしています.
thread は,たかが機構なので,使い方は幾通りもありえます.
しかし,代表的なパターンとして,2通りの使い方があります. たぶんデザインパターン的な名前がありそうですが,知らないのでオレオレ命名で.
同じデータ構造で同じ処理を持つスレッドが,多数あるパターンです.
非同期に起こる多数の要求を裁くときに,しばしば見られます. 具体例としては,サーバのワーカースレッドや,ファイルシステム内の処理などがあります.
複数のスレッドが,それぞれ異なるデータ構造を管理するパターンです. データ構造が異なるのですから,各スレッドが行う処理も,当然異なります.
「そういう時はプロセス分けるだろ」と思った方は,POSIX や Windows に頭を侵されています.
多くの RTOS では,スレッドに相当する概念はあります. しかし,プロセスに相当するリソース抽象化概念がありません.(注: 持っている RTOS もあります)
また,POSIX や Windows も,OS の内部では,スレッドに相当する概念はありますが,リソース抽象化の概念は無いか,希薄です. OSが抽象化を提供しているので,当然です.
mruby は,言語としては,今のところスレッドを提供していません. しかし,マルチスレッディングの要求は,上記の2通りのいずれにせよ,間違いなくあります.
mruby を下位 OS のスレッドとバインドする典型的手法として,スレッド毎に mrb_state を割り当てる手法があります.
私は mod_mruby のソースコードを精読したわけではないですが. サーバへの mruby 活用の代表である, mod_mruby も,Apache のワーカースレッドに対し 1 つの mrb_state を割り当てているようです. この場合は,各スレッドは「対称」です. 全ての mrb_state は,同じように初期化されて構いません. 使える mrbgems も全てのスレッド(mrb_state)で同じもので構いません.
非対称なスレッド構成を取ったシステムを考えてみます.
実例として,uITRON, OSEK/VDX クラスの RTOS 上にファイルシステムとユーザアプリを mruby のみで作るとします.
構成としては,デバドラ + ファイルシステム + ユーザアプリになります.
デバドラとファイルシステムは,再利用性が高いので,おそらく mrbgems として実装するでしょう. そして,非同期処理になりますので,(デバドラ + ファイルシステム)のスレッドと,ユーザアプリのスレッドに分けるでしょう.スレッド間通信も mrbgems として提供するかもしれません. 常識的な RTOS のアプリ設計です.
ここで,思い出してみましょう. 現在の mruby では,全ての mrb_state で,全ての mrbgems を共有します. つまり,スレッドを分けても,ユーザアプリは,ファイルシステムを迂回して直接デバドラのメソッドを叩けます.
これを気持ち悪くないと思う開発者が居たとしたら,別の職種にジョブチェンジしたほうがよいでしょう.
今のところ,mruby へ sandbox を仕掛ける実装は殆どみかけません. mattn 氏が mruby-sandbox なる実験をしてはいますけれども. 私はかつて,lazy initialization なる提案をしていて,これは sandbox を狙ったものだったのですが,意図がうまく伝わらなかったのか,フルボッコに終わりました.
実のところ,彼らでないので真の理由は解りません. しかし,私の想像が及ぶ限りにおいて,必要と思わない理由は,2種類あります.
ひとつは,”くみこみ!”など言いながらも,結局 web サーバのことまでしか考えが及ばないから. 対称なスレッドだけですむ世界なら,今の実装でも十分です.
もちろん,世界最高水準の開発者集団ですから,非対称スレッドの設計についても,頭では理解できておられるでしょう. それと,腹に落として理解できるというのは,必ずしも一致しません. 技術というものの難しいところであります.
もう一つは,組み込み系技術者たちは,小さな機器組み込みに偏りすぎているから. ちっちゃいもの好きは,ニッポンの組み込みのガラパゴ特徴ですが,mruby も漏れずに思えます. Mindstorms/NXT やらFM3-USBSTICKやら STM32F4 やら,RTOSを載せるのさえも一苦労な環境に,開発者たちの視線が集中しています.
コードゴルフは私も嫌いではないですが. 現在でもオンチップ 256KB は珍しくないマイコン世界. MB 級の RAM がオンチップになるのは時間の問題なのになぁ…. 盆栽みたいなものですかね.
ともあれ,mrb_state をひとつ持たせるのがやっとの環境では,スレッドと mrb_state の組が複数存在する環境で起こることを想定するのは難しいでしょう. 私は,Mocloudos や mruby + TOPPERS + Blackfin といった,潤沢なスペックを持つ(とはいってもデスクトップやサーバに比べると極めて貧弱な)環境上で mruby を動作させています. そのため,早期に気がついた,ということはあるでしょう.
というわけで,mruby で sandbox が何故必要なのか,なぜ本家に登場しないのか,ざざっと意見表明いたしました.
こう言ってはナンですが,今の体制のままだと,本家mrubyがベアメタルな機器組み込みに応用されるようになるのは,ずいぶんと先になるんじゃないかな….
まあ,別に,”本家”に拘る必要も無いといえば無いのですが.
]]>mruby の機器組み込み向け fork である monami-ya.mrb に,mrbgems の sandbox 機能を追加しました. 何故この機能が必要なのか,という話は後日するとして,どう使うかということを記しておきます. master ブランチに入るまでに,API 等の変更があるかもしれません.
また,mruby 本体に取り込まれるかどうかは,解りません.
本家 mruby では,mrbgems による機能拡張がサポートされています. これは,monami-ya.mrb でも同様です.
mruby は,複数の実行環境を持てます. 実行環境は mrb_state という構造体が代表します.
mrb_state は,mrb_open() の呼び出しによって作成されます. mrb_open() の実行時には,build_config.rb で静的に指定した全ての mrbgems が, mrb_state で使用するものとして初期化されます.
mrb_state ごとに,利用する mrbgems を限定できます. 限定する mrbgems は,静的に指定します.
実例として,monami-ya-mrb/mruby-sqlite3 と monami-ya-mrb/mruby-bin-sqlite3 のみを含む sandbox を挙げます.
monami-ya-mrb/mruby-sqlite3 は monami-ya-mrb/mruby-bin-sqlite3 に依存しています.
build_config.rb に,sandbox メソッドを記述できるようになりました.
1 2 3 4 5 6 7 |
|
この例では ‘sqilte’ という名前の sandbox を指定しています. ブロック内の gem は,従来のと同じです.
このような記述があるとき,minirake を実行すると,build/jsp-bfin/mrbgems/gem_init.c には,従来に加えていくつかの定義が生成されます.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
さらに, build/jsp-bfin/mrb_sandbox_id.h というヘッダファイルが生成されます.
1 2 3 4 5 6 7 |
|
もし, mruby-sqlite3 のみを指定し,依存性のある mruby-bin-sqlite3 を 含め忘れたとします.
1 2 3 4 5 6 |
|
このような依存性の破れを含む記述で minirake を実行した場合には,エラーとなります.
1 2 3 4 |
|
API として mrb_open_sandbox() および mrb_open_sandbox_allocf() が追加になりました.
1 2 |
|
引数 sandbox_id は,mrb_sandbox_id.h にある定義を与えます.
1
|
|
sandbox_id が 0 のときは,mrb_open() を呼んだ時と同じになります. すなわち,登録されている全ての mrbgems が初期化されます.
どの sandbox を指定したかは,mrb_state に保持されます. そのため,mrb_state を破棄する際には,単に mrb_close() を呼び出してください.
]]>@monamour555 まあ、どうforkするかはご自由で私から強制することはできませんが、過去の事例だとこの手のforkしたOSSは長期的には失われる結果になりそうです。
— Yukihiro Matsumoto (@yukihiro_matz) May 29, 2014
全く御意でございます.低頭拝聴です.
賤民である私も,OSS という言葉が無かったころ,Ruby が世に放流された頃には,この世界を見ていた気も無くもないですが. きっと気のせいですね. uClinux, Xen, Android で kernel の fork が起こったのは,失われる運命だったのですね.だめだ fork はダメだ.失われる!だめだ!
あーやっぱり,私が書いたコードなんて,消えちゃうよなー.すべからく,そういう人生だったしなー.何しろ長老がそう言っているもんなー. って陰惨に思いながら,残りのコードを書いていたのですが.
…あれ?
コンパイルが通らないよ?
1
|
|
んー? んー? ググル先生に聞いても解法がわからないよー.コピペできなよー.えーん. こんな単純なところでコピペできない OSS なんか,使えないよー.マサカリ担いだ人しか使えない処理系なんてー (棒
あはは,忘れていました. IREP の扱い方,途中で,変わりました. mruby のコア開発者なら,当たり前の知識ですよね.アテクシ,死ねばいいのに.
コードベースの進化は,OSS の華です.いいんじゃないですかね, ただし,ユーザがその変更についていけていない OSS が,長期的には失われなかったのかな.
賤民の私に言わせてもらえるなら,これ,良くない兆候ですよ.
この節だけは,マジメに言いますけれど.
私が fork したコードなんてどうでもよいです.
良くない兆候ですよ. マージされ得ないオレオレ fork を繰り返して周りがついてこれなくなっている,本家のコード が.
過去の事例によると. ブログエントリって,エッジ効いた技術に平民がどれだけついてこれているかを示す,解りやすい指標ですからね.
何言ってやがるんだと思うなら, mrb_proc_new か何かでググりゃいいんじゃないですかね. 軒なみ mrb->irep[n] ですから,記述が.少なくとも本稿執筆時点では.
角が立つのを承知で,(でももう,どーでもいいので),事例を言えば,uT 以降の T-kernel とか,新世代以降の TOPPERS とかですね. 技術的に正しいながらも,説明不十分でプレゼンスを落としたOSS,しばしば見かけるのは気のせいですかね.
mruby,どうなのですかね? “長期的な視点”を持っているグルには,答えが見えているに違いない.信じるのじゃ. …ので,大丈夫ですかね.
どうなのですかね?
]]>機能としては,ソフト屋さんから別段の注目を浴びるほどのものでもなく. プレスリリース等派手なことはしませんでしたが. 合同会社もなみ屋の名義で,Webアプリをリリースしました.
ほんと,機能としては大したものではないです.
やる気になれば,誰でもやれるネタです. しかし,調べてみたところ,意外なことに,全く同一の機能を提供するサービスは無いようです.
たぶん,もなみ屋を知っている人にとって,リリース告知を受け取った時の第一声は,「機器組み込み屋がなに Rails で遊んでんの?」かなと思います.
でもこれ,実は,(もなみ屋にしては珍しく!),技術先行ではなくて,需要先行のサービスだったりします. ファーストユーザが既に決まっています.どうしたんだ,地に足付けているなんて,弊社らしくないぞ.
もなみ屋の活動拠点は,浅草が近くてスカイツリーも近く,外国人向けのゲストハウスも多いという,IT活用型観光にとっては最高のテスト環境だったりするわけです.
そんななかで,徐々に判ってきたことなのですが. スマホ街歩きって,技術者と一部のオタクだけが盛り上がりはするけれども,実用的ではないのですよ. (別に特定地区の頑張りを dis る意図は無いです)
紙,印刷物っていうのは,やはり最強です. シャチハタスタンプのスタンプラリー,最強です. A3折りたたみのグルメマップ,最強です.
次点で,パッシブNFCタグ辺りかな….電池交換不要なパッシブタグは,紙に準じます. 使える端末が少ないじゃん,というデメリットもありますが.
BLE…うーん.まあ,保守体制が盤石なら.
専用スマホアプリ? ダメでしょ.全然ダメ. 地図の AR マッピングとか,カメラと液晶をブン回して,どんだけ電池持つと思ってるのよ,って話ですよね.(…言っちゃった)
しかし,道案内(ナビアプリ)は,重要です. 特に土地勘のない人を相手にする観光分野では. この点で,スマホ・タブレット・ガラケーは大事.
そんなわけで,「観光客の満足度を高めたまま帰途について頂くには,offine to online の連続性を持たせつつ,どれだけ offilne の情報で済ませるかというのが重要である.」 てなことが見えてきたわけです.バッテリーを使わないことの正義,みたいなものを.
具体的に言うなら,印刷物や掲示物として存在するQRコードやパッシブNFCタグから,地図アプリへのスムーズな連携,とかですね.
じゃあ QRコードに Google Maps へのリンクを込めときゃいいじゃん,という話なのですが. それには 2つほど課題があります.
一つは,デバイスの多様性. ガラケーとAndroidとiOSとで,ユーザにとって自然と思えるリダイレクト先が違うわけです. Android と iOS については,吸収するバッドノウハウがありますけれど,ガラケーはつらい. しかも地方から上京する方の中には,ガラケー所持の方も少なくないわけです.
あともう一つは,統計情報取得の問題. 観光って,概ね何かしら自治体からの公金が入ります. そうすると,成果の測定が求められます. しかし,QR コードに Google Maps へのリンクを含めるだけだと,どこにもログが残らないわけです.
短縮URLサービスの多くは,統計機能を持っています. しかし,観光担当の方はITに詳しいとは限らないので,いろいろとつらい. できれば専用サービスで,地名,緯度経度情報くらいで管理したい,と. それなら,パート職員の方でも片手間でできるわけです.
もなみ屋というのは,RTOS やら開発ツールやらのサポートという,ハードボイルドな商品も 取り扱ってはいるのですが. 結局のところ,人々の生活を愉しくするためのお手伝いを,ソフトウェアを通じて提供するというのがミッションなのであります.
スマホがパッテリー食いで,バッテリーのエネルギー密度が今のままなら,スマホを使わないシステムを提供する.これはミッションに矛盾しないので,始めたわけなのであります.
この話に限らず,地元で観光資料を作ろうとしているのだけれど…. という方のご相談にも乗れますので,ご縁がありましたらお声掛け下さい.
]]>前回,米国での状況は説明しました. 小規模法人や個人が,ネット通販のサイトを開いていることからお判り頂ける通り, オンラインのカード決済サービスは,いくつかあります.
しかし,目標額達成後,速やか(数営業日以内)に代金を回収できるのは,今のところ, WebPay と Yahoo!ウォレットFastPay の2社に限られます.とはいえ,今後,類似のサービスは,日本国内でも増えていくことでしょう.
現存する両社のAPIは,かなり似通っています. (WebPayの運営者ブログで示唆されているとおり,FastPay が WebPay の互換を狙っているように見えます.)
しかしながら,クラウドファンディングサイト構築のためのオープンソースが用いている Balanced Payment や Amazon Payments とは,すくならず API が異なります.
やや悲観的な状況です. しかし,逆説的にいうと,この部分を突破すれば,日本でもクラウドファンディングサイトの構築は圧倒的に容易になるということでもあります.
例えば,地方自治体で,地元の産業活性化のために,クラウドファンディングを使いたいというような案件は,既にいくつかあります.最近だと夕張市や北海道で見かけました. 各地観光協会や商工会など含めれば,潜在需要は大きなものでしょう. それと,Fablab や発明クラブのような,民間団体にも需要はあるでしょう.
しかし,私は,それらの大きな潜在需要に食い込もうという気は,今のところ,ありません. それは自分のビジネスではありません.
私は,単に私のビジネスのスタートアップの問題を解決したいだけなのです. 日本で使えるカード決済のモジュールを,既存のオープンソースに付け加えたい.
しかし,その副産物には,社会起業的なインパクトが…そんな気がしているのですが,どうでしょうか.
という感じで,話が大きくなりました.巻き戻しまして….
私には,私が行おうとするビジネスに対して,一つだけ不安があります. それは,「日本人は,放っておいても作る人に寄付/投資をするか否か」という点です.
また海外の比較になりますが,海外では,無料で入手できるオープンソース製品に対して, バグフィックスや機能拡張に対してお金を払える,または投資を募ることができるという サイトがいくつかあります.しかし,それらのサイトで,日本人らしきアカウントの姿は 見かけません.
言語の壁ということもあるかもしれませんが,もしや,
どうせ,作りたい奴は勝手に作るし,できあがった成果(回路図やソースコードなど)が無料でwebサイトに上がったら使わせてもらうわ
というメンタリティが主流だとすると,日本では,「電子工作好きのための小規模クラウドファンディング」は,成り立たないかもしれません. その辺りについて,読みきれずにいます.
「長々文章を読ませておいて,さいご,これかよ…」ということで,すみません.
ちなみに,作業は私が行う想定です.誰かに頼むにしても私が監修します. 本件に関する私のスペックは,下記のとおりです.
本件のクラウドファンディングのサイトとして,オープンソース向けののクラウドファンディング機能がある Bountysourceを使います. 国内のほうが心理的に安心かもしれないと思いつつ,このお話を国内の大手クラウドファンディングサイトに持ちかけるほど,私の心臓は強くはありませんでした.
極めて勝手なお願いですが,ご協力頂ければ幸いです.
]]>いや,いまさら,意識高い大学生のようなことを思い立ったわけではありません. また,まだ40代前半ですから,社会貢献の余生を模索するには早すぎます. 私は私のビジネスも続けます.
ただ,私が取り掛かりたいビジネスの 副産物 に,社会起業的価値があるかもしれないと,ふと思いついたのです.
私が何を考えたのかは,既に tweet し,「クラウドファンディングサイトの未来」というタイトルで togetter にまとめました.
一連の Tweet に対して,いくつかの反応も頂きました. それぞれのご意見(共感も反論も総論賛成各論反対も)に傾聴した上で,小規模クラウドファンディングサイトの登場は必然だろうと思うようになりました.
当初,私が必要性を感じているのは,個人レベルの電子工作のコミュニティへの,クラウドファンディングでした. このコミュニティは,オンライン/オフライン問わず,ソーシャルネットが,ある程度できています. よって,「〇〇を作ります」と言っている人の技術レベルも,プロジェクトのリスクも,投資する側は,ある程度分かります. 大手サイトでは緻密に行わなければ担保できないリスク管理のコストは,ある程度低減できます. 低コストは,手数料を下げたり,より良いサービスの提供に振り分けたりできる,ということに繋がります.
このサービスは,大化けはしないでしょうけれども,赤字にはならない程度の需給はありそうに,私は思います. なので,私は(もしくは私の会社は),上記のクラウドファンディングサイトの構築に向けて,一定量の開発リソースを割り振ることにしました.
実は,海外では,クラウドファンディングは,もっと気楽に立ち上げられます. そのための,オープンソースや決済基盤が存在しています.
有名どころを挙げるなら,Lockitron があります. 彼らは,自社製品のためのクラウドファンディングサイトを作って,オープンソースで公開しています.
Lockitron のサイトを応用して自社のためのクラウドファンディングサイトを作った例は,記事となり, makezine.jp で読むことができます.
また,クラウドファンディングサイトのための,もっと大規模なオープンソース製品もあります.
ところが,日本では,大きな障壁があります.
それは,決済手段です.
クラウドファンディングは,当たり前ですが,クレジットカードへ課金をし(正確にはオーソリをかけ),目標額の達成如何で集金をしたり返却をしたりという機能が不可欠です.
このような決済サービスは,米国では数多くあります. しかし,先ほどご紹介した togetter に含まれる tweetでも示唆したのですが,日米の金融行政や租税関係により,日本から,米国のサービスを使うには,様々な制約があります.
具体的には,米国の金融機関に口座を持つ必要がある,租税に関する書類を米国に出す必要がある,送金に時間がかかることがある,などです.
つまり,日本では,海外(主に米国)では簡単に行えるクラウドファンディングサイトの構築が,容易ではありません.
もちろん,決済手段だけが問題というわけではありません.
集客のようなビジネス的な問題は当然として,特定商取引法を始めとする消費者保護行政や,言語(日本語と英語)の問題など,課題はいくつかあります. しかし,特定商取引法は適切に表示すればよいですし,サイトに表示される文字は技術的には解決可能な問題です.
やはり,決済手段は,大きな課題として立ちはだかります.
以上,私がクラウドファンディングについて発言をしだした経緯と,海外での状況,日本での障壁について簡単にまとめました.
ここまでの話でしたら,「アメリカは,いいなぁ.それに引き換えニッポンときたら」という愚痴です.
長くなりましたので,次回と2回に分けたいと思います.
]]>私個人としては,OSX でパッケージ管理ソフトを使うのは,PPC だった時代に fink を使ってあまりよい印象を持っておりませんでした. そんなわけで,OSX版のPizzaFactoryも,pkg を作って配ってきたわけです.
しかし,pkg は,それなりに手間のかかること. 更新頻度が私の忙しさで決まってしまうのが悩みでした.
で,最近になって,TOPPERS のカーネルコンフィギュレータを作らねばならなくなって,boost のインストールが必要になり,ココロが折れました. そして Homebrew に助けてもらいました.
OSXのデフォルトのコマンドを上書きしないという方針,気に入りました. あと,Formula 既述の簡潔さも.
それに,Linux や MinGW/MSYS への対応も,そこそこ進んでいる様子.
ああ,もう PizzaFactory も Homebrew で配っちゃえばいいんじゃないの? と.
Homebrew のインストール方法は割愛します. brew doctor の対応がある程度済んだら,PizzaFactory 用の tap を追加します.
1
|
|
つらつらと読み込まれてきます.
1 2 3 4 5 6 7 8 |
|
続いて インストール可能なツールチェインの一覧を得ます.
1
|
|
ズラズラっと出てきます.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
arm-eabi ならば,次のようにしてインストールします.
1
|
|
お手軽ですが,本稿執筆時点では,ソースコードからビルドします. 1〜2時間は覚悟してください.
この点が,正式リリースと言わない理由です. Homebrew には,bottle と呼ばれる,バイナリパッケージによるインストールのサポートがあります. しかし,これが Travis-CI のバグ修正のため滞っています.
なので,今のところは,どうしても欲しくて欲しくてという方のみお勧めします.
あと,tapへのプルリクは歓迎です.
]]>