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

柔らかいのと硬いのと

これもエンジニアの仕事

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

あるサイトで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]と説明しているサンプルを多数見るが、これではダメ。

手書き署名をサーバに保存する

ひさびさに本業の話題(笑)。

納品とか受託作業の完了の際とか、ひと昔前までの「受領印」に代わって「タブレットへの手書きサインでOK」というケースが増えてきている。今回これが要求され、以前試しにやったのを復習。

手書き署名=静止画像だが、これがローカルに保存されたものであればフォームエレメントのひとつとしてサーバにアップロードするのも容易である。だがこういう局面でのそれは、煩雑かつ余計な手間をユーザに強いる事になるのでNG。そこで登場するのがHTML5のCANVASというタグで、文字通りここにはいろんなものを書いたり貼ったりすることができる。今回は白地のCANVASに指かマウスでサイン(=お絵描き)をして貰い、それをサーバにアップロードして保存するというところまでの話。

結論から言うと今回は「Fabric.js」なるものを使う使わせて貰う事にした。機能が豊富なぶん記述が冗長になりがちなCANVASの振る舞いを上手くラップしてくれている上、扱うデータ量が大きくなりすぎずこの様な用途に最適、という判断からである。ただこれを<INPUT TYPE=”FILE”>でひとまとめに、というのができれば幸だがそうはいかない。具体的には、署名者の「これで良し」のタイミングで

1.  CANVASの内容をSVG
2.  1で得られたSVGテキストを不可視フィールドの値に(代入)する
3.  2を含むフォームをsubmit

までがクライアントの動作。これに呼応してサーバ側では

1.  不可視フィールドの内容からSVGをファイル化
2.  1をPNGに変換
3.  保存

と、こういう流れになる。サーバ側の動作はもう少し最適化できそうだが、当面これで行く。

以前は大変な思いをした局面だが、つくづく「いい時代になったもんじゃのう」としみじみ。

# これで仕事終わりじゃないんだが備忘録代わりに

追記:  署名がされていない状態でsubmitされないようにするため、SVGのpathを数えるところで小ハマリ。XMLは好かん。

追記:  なんとiOSのWKWebViewがJavascriptのalert/confirm/promptをガン無視! どうすりゃいいのか、これから考える。

追記:  webview.UIDelegateをselfとする事によってJavascriptのalertをフックする事ができた。あとはこのタイミングでrunJavaScriptAlertPanelWithMessageを実行すれば吉。てか、ここまで用意してあるならデフォルトで動くようにしておいてくれればいいのに。