「Engineering」カテゴリーアーカイブ

柔らかいのと硬いのと

空前の人手不足

だそうで。更には、これが原因で景気回復にブレーキとか。

つい先日、ある大手外食チェーン店で求人の貼り紙を見たが、そこには「時給¥1,000」とあった。バイトではない。正規雇用のスタッフに対してである。200時間で×200。たぶん、ここに人が来ないのを「人手不足」と言っているのだろう。

かつてこういう状況で日本語が苦手な方々を「安いから」というだけで雇い、クレームの嵐で屋台骨が揺らいだケースがあった。「不況のどん底」と言われたあの頃ならまだしも、今にしてこの状況って、実は何も変わってないんでは?

こういうの、ソフトウェア開発の現場も同じ。使う側の論理で「スキル高いのを安く多数揃えりゃ大儲け」で成功というなら誰も苦労しない。だが思惑どおり予定通り、予算どおりにいかないのが開発の現場であって、最後は現場での切った貼ったで動いているのが現実。高いスキルとは何なのか、それを満足させる対価とはいかほどなのか、恐らく未だ誰も普遍的な回答を持っていない。

# なおここで「日本語が苦手」なのは外国人に限らない。

続く … かも。

 

なんでいまさらXMLなのよ

ここ暫く、連日こう呟き嘆き続けているワタクシ。改めて説明するまでもないが俺は、いや俺もXMLが昔から嫌いである。なのに今のミッションときたらデータをそのXMLとして生成(!)し、更にはそれをファイルにして(!!)他社謹製のシステムに送りつけよという最低な内容。こんなもんHTTPでPOSTしてやりゃ済む筈のところだ。どこの誰がこんなヘタレな設計したのか知らんが、受け側がそれで作られてしまった以上ヤメロとも言えない。やむなく鼻つまんで書き始めたが、カネの為とはいえこれほど楽しくない仕事も初めてだ。

ただPythonには、辞書型をXMLに一発変換してくれるキラーモジュールがある。これを使えばチョチョイでしょうと思った … が、それはアマかった。今回の相手が期待するXMLでは、親ノードの下に同名のノードが並ぶのである。俺がXMLを忌み嫌う理由のトップたるこれを相手が待っている以上、この手は使えない orz …

事ここに至ってテンションだだ下がり。フテ腐れ状態でチマチマとツリーを記述中。あほくさ。尤もこの件、XML云々以前にシステム設計者のセンスの悪さ、スキルの低さこそが原因である。こんなのがビジネスの現場で通用しているという現状、それが怖い。

この業界、昔も今も変わってない。明日も明後日もこのまんまなんだろう。悲しい。

WebGLへの期待

諸般の事情でここまで「激安CortexA8のグラフィクスの非力さをなんとかしなければアウト」という危機に見舞われ、いろんな事にチャレンジしてきた。が、それらはみな「あっちを立てればこっちが立たず」ばかりで解決策とはならず。そんな模索・失意・挑戦・疲労のスパイラルでふと脳裏に浮かんだキーワード、それが「GPU」だった。

これまで俺の場合ずっとサーバ側がメインで、こういうのが必要になるような要件はなかった。だが最近マイニング等でこれが再度脚光を浴びていてNVIDIAのボードがSOLDOUTとか聞いていたし、そのパワーがここで使えないもんかと調査開始。とそこで目にしたのがWebGL=「JavaScriptから使えるOpenGL」。しかも最新のChromiumがこれをサポートしているというのもわかった。

「救われた!」

という思いに、熱い涙が頬を伝った。冗長な処理を延々と繰り返すJavaScriptからスルーパスを受け、そこからは「質より量」と言わんばかりに分身の術で突っ走るその潔さ!  なぜ今までこれに気づかなかったのだと己を叱咤しつつ、ベンチマークを必死こいて書いた。PCのブラウザで試したところ、明らかに
処理時間の短縮に成功している。

よーしこれをA8で再現だーっ!!!

 

…  ハイ、結果から申しましょう。A8でこれ、満足に動きません。てか、数分かかっても動けばまだいい方。無反応とかtopで100%とかそのままハングとかとかとか  …  何やってもダメ。要は現状

使いものになりませんねこれハハハ!

結論、それは「二日間の徒労の末、振り出しに戻る」。悲しすぎる。

numpy恐るべし!

正直言ってPythonは好かん。好かんがいまや、Pythonを避けては通れない … という想いからこれまでにそのひと通りは理解してきたつもりだった。そしてちょっとしたテストプログラムならさらさらっ、というレベルには達していたつもりでいた。

ところが今回、グラフィックスの性能評価という局面でその遅さに行く手を阻まれた。「しゃーない、Cで書こうか」とも思ったが、ここでふと思い出したのがnumpy。そこで試しに2次元配列同士の矩形コピーをこれで書いてみてビックリ。ループがなくなって、実に1000倍の高速化!  いやー

お見逸れしましたnumpy
恐れ入りましたnumpy
感動をありがとうnumpy

あのトロいPythonが、科学計算とかビッグデータの解析とかで活躍というのがようやく理解できた。「これはアレにも使えそうだな」といま考えているところ。ふふっ、楽しみだ。

Linux採用の意義と意味

近年、組み込み機器をLinuxでという傾向が加速している。ところがその実態ときたら、Linuxを用いることの意味とか意義とかを正しく理解することなく、ただ単に「ヨソもやってるしトレンドだから」で上意下達というのが大半である。こんな時、現場は不慣れな開発スタイルに「またかよ」と辟易する。がその一方で8bit@ひと桁MHz世代なオッサン達はみな「32bitで700MHzで」と聞いて「これは途轍もないパワー!」と喜ぶだろう。更にはそこへ「潤沢なメモリをどうぞ♪」ときたら、それはもう「何でもできるスーパーコンピュータが目の前に!!!」と安堵することだろう。

が、そんなスーパーCPUが今や数百円で売られているのにはそれなりの理由がある。つまりそれは「S/WからH/Wへの要求性能」がそこまで上がって来ているからなのだ。遥か昔は「H/WありきでのS/W」だった、そんな従属関係はとっくの昔に逆転しているのである。

近年スマホやタブレットのみならず、ルータとかビデオとか、更には白物家電にまでその「設定はGUI(Graphical User Interface)で」が普通・常識となった。それは産業用機器にしても然りで、かつてはその保守に担当者が専用装置機材一式持参で出張していたものが、最近では「顧客の側でWebブラウザから」というのが当然になってきている。そして今や、本来の機能までをもこの
「Webブラウザ上で」とする例が急増してきている。そこで話は冒頭に戻る。

新製品の開発開始にあたって機能UPはいいが、果たして

そのH/Wの体力はS/Wの要求に対して充分なのか?

その見極めはいちばん最初の、それもいちばん重要なポイントである。ここを見誤ると、S/Wがどんなに努力しようとも機能を満足する事はできない。またそれが充分なのであれば、次はそのマージンが広いほどS/Wの実装は楽になる( = 工期の短縮に繋がる)。
これらを製品としての

*  売価
*  償却期間
*  中途での保守

と開発コストとの兼ね合いでいち早く見極めること、それこそがビジネスという観点での成功の可否になる。だがここで躓いたまま、徒に時間と人員(=コスト)の浪費を続ける例をよく聞く。理由は簡単で、その担当者にはこうした事を短時間で済ませるための高い技術的スキルと、コスト面での制約・制限を把握するマネージメント能力の両方が求められるからである。

「他社との競争に勝つには、機能も性能もさることながらリリースまでのスピードこそがキモ!」は組み込み機器の世界でも同様、どころか最優先課題だろうと思う。ここを正しく理解し実践している企業こそが勝ち組たり得ているのは、決して偶然ではないと思う。