カテゴリー別アーカイブ: Engineering

柔らかいのと硬いのと

これもSEの宿命

ひとつ仕事を終えた。その内容について詳しくは書けないが、それはいわば「閉店時間内に築10年のデパートをまるっと隣町まで移動し、その跡地にそっくりなのを新たに建てた」ようなもの。しかもその設計・施工に携わった者が現場に誰ひとりいないという、笑えない状況での大仕事。更に売場の一部は「こちらへどうぞ」で、お客様を旧デパートへ無料送迎するというオマケつき。

我ながら「こんなの良くやり遂げたもんだ」と思っている。むろんそれに向け予め入念な計画をたて、テストとシミュレーションを何度も行って手順書を作成しての事。物理的に要する時間を元に決行の日取りを決め、いよいよその時を迎えたのが先月末。久々に徹夜というSEらしい目に遭ったが、これには先々週末の麻雀がいい予行演習になった(笑)。

とはいえ、やはり動かしてみて初めてわかる不具合が忘れた頃に出てくる。それも原因の殆どは元々の施工主にあるところで。

結局今週、大半の時間をその対処に費やしてしまった。これが来週まで続いたらアカだ(怖)。今はただただ、それが無いことを祈るしかない週末。嗚呼 …

これもエンジニアの仕事

※  以下これまた日頃「イヤな仕事にも笑顔で応え」な苦労をされているエンジニア以外には面白くもなんともないであろう「ただのグチ」なのでお許しを。

あるサイトで500(Internal Server Error)が出ているので調べて欲しい、との依頼。Apache+PHPではよくある話で、発生箇所はすぐにわかった。システムで自動生成される.phpの中にあるXMLタグの書式がダメで、PHPのパーサがエラーで落ちているのだ。

が、そのシステムは「既にいないどこかの誰か」が何年も前に作ったもの。対策を講じようとソースを眺めてもサッパリわからないし、そもそもこういうのに安直に手を入れたら別の問題を引き起こしかねない。

そこで現場と相談の末、苦肉の策として

  1.  .phpが生成もしくは更新されるのを監視する
  2.  それを検知したらsedで.phpから問題のタグを削除する
  3.  1に戻る

という処理をバックグラウンドで動かす事にした。これなら利用者には影響ゼロだし、負荷も軽い(だろう)し。監視にはLinuxのinotify-waitを使う事にした。

だがこんなの、典型的な対症療法(=ボロ隠し)である。ファイルの監視もsedもかつてはもっと有益なところで使ったもんだが、それをこのような非生産的、かつ屈辱的な局面で使う事になろうとは orz …

まあそれもどうにか目論見どおりに機能している様だし、これは一過性のものと、あまり深く考えない事にした。今はその「既にいないどこかの誰か」が何年も前に作ったやつをそっくり捨てるという、次の展開に期待するのみである。

IoTの実態

IntelがEdisonら極小ワンボードをそっくりオワコン化らしい。俺はArduinoで充分だったので手を出さなかったが、Curie搭載のそれもパッとしなかったし、これは必然でしょう。

が、これは単にメーカーが「売れないからやめました」という話ではない。IoTというよくわからん言葉だけがひとり歩きした、実体の覚束ないブーム(こういうのをバブルという)の終焉がいよいよ明確になったとみるべきだろう。

俺的にはここ数年、このおかしなブームのお陰で様々なデバイスが安価かつ大量に出回ってくれて大いに楽しめた。またその結果H/W、ひいては電気の基礎までを初心に戻って再履修できたのが最大の収穫だった。

が、それはあくまで私的な話。少なくとも国内のビジネスという観点からは企業向けの研修とか検定とか、及びそれに付随するキットもしくはパッケージが抱き合わせで売れたぐらいなもんだろう。あとはせいぜい便乗書籍。これがIoTの実態。

半導体製品拡販のためのブーム作り、次は何が来るか?  メーカーのお手並み拝見と参りましょう。

iOS developperのあるある話

これの続き。

※  以下内容、日頃プログラミングに携わっている向き以外には面白くもなんともないであろう「ただのグチ」なのでお許しを。

—————————————————————————–

クライアントからの要求がこれまで

「iPadで矩形領域内にフリーハンドで線引きせよ」

という認識でいたら、実は

「iPadのカメラで撮影した画像の上にフリーハンドで線引きせよ」

だった。この時は「ふむ、Canvasの背景を画像にするだけだよね」と、軽い気持ちで取り掛かった。そして軽やかにハマった。

まずはiPadのカメラを起動、得られた画像をそのままCanvasに貼り付けてみたが無言。同じコードでもPCのブラウザだと出るので、恐らく画像がデカすぎるのだろうと推測した。そこで調べてみたところ、iPadのカメラで得られる画像は(W:H)=(3262:2448)。実に液晶パネルの3倍近い。そこでこれをCanvasに貼る直前でリサイズしてやる事にした。

が<input type=“file”>のonChangeで得られる画像はBase64エンコード、幅も高さもわからない。ならばとこれをnew Image()でイメージオブジェクトに変換してみたが、なぜか幅も高さも取れない(涙)。結論から言えばこれを別のCanvasに展開、その上でリサイズしたやつを使えばバンザーイ!  というところまで手探りの数時間。

だがこれも「恐らくサイズのせいだろう」という前提での措置。どこまでならOKなのか、そんなのさっぱりわからん。まだまだやる事あるんだし、この先どこで地雷踏む事になるやら。

iOSとそのアプリケーション、使う分には悪くないがそれらはみなこういう苦労の末にあるというのをご理解頂きとうございます。

Xcodeふたたび

久々に本業でiOSアプリケーションを作る事に。正直なところ「やりた***」が、それもArduino方面で遊ぶための糧を稼ぎ出すため。覚悟を決め、カチッと頭を切り替えた。

今回のそれはキャリヤ版iPadがターゲットで、サーバとの間で通信を行う。扱うデバイスはGPSとカメラ。機能的な要点はタッチパネル上での手書き署名とGoogleMap。これらをゼロから書いたら大変だが、たぶん以前使ったUIWebViewで行けるだろうと判断、まずはここから調査を始める事にした。

するとどうやら今ではWKWebViewという新しい仕組みが推奨の様なので、早速これを試してみることに。だが、3年ぶりのXcodeで既に右も左もウラシマタロウ状態。さーて困った、とググってみれば出てくるのはSwiftの例ばっか。それもStoryBoard(俺はこれが生理的に好かん)からという例のパターンばかりで、早くも心折れそうになった。

それでもどうにか、手持ちのiPadでWKWebViewにURLを与えて動かすところまでは進んだ。そこからCANVASだgeolocationだセキュリティだプライバシーだをひとつずつ片付けていって、どうにか必須機能の全てをWKWebView内で動作させるるところまで辿り着くまでに約2日。まだ何点か問題・課題を残しているし、工期は2ヶ月と決して余裕はないが「これなら恐らく大丈夫」と今はひと安心な段階。

しかしまあ、うっかりミスると煙が出るわ感電するわなArduinoとくらべ、この過剰サービス懇切丁寧な開発環境と、ミスっても「あ、いけね」でいくらでもやり直し可能、というこの違い。お釈迦様の掌の上の悟空になった気分である。はぁ。

#備忘録1 iframe内から親documentの要素にアクセスする際に指定するコンテキストは[window.parent.document]。[parent.document]と説明しているサンプルを多数見るが、これではダメ。