突破口は開くのか

月末になってくると、OUTPUT報告書のことが頭にちらちら入り込んできてなんだか鬱になる。

報告の元となるデータを打ち込む物は存在するのだが、なんせやりにくくて苦痛でしかない。
間違い、抜けが多いのでデータを一通りチェックしなきゃならないし、集計も結局コンピュータを目の前にしながら半手動というお粗末さ。

PCが導入されて15年が過ぎようとしてるのに、未だこの有様とは…。

ふれあいフェスタ

『ふれ愛フェスタ2012』行ってきました！

まぁ元々知っていて行った訳ではなくて、娘が通う塾の先生がそこのイベントでバンドをやるという事で見に行ったというのがきっかけです。
そのバンドは年配の方々が中心で曲はビートルズ。先生はドラムを担当していました。聞くと長いことやってるそうで、いやー皆さん上手でしたね～

同じ趣味を同じ仲間とずっと一緒に続けていられるって羨ましいですね。私も機会があればまたやりたい所です＞（メンバーの一部へ）

その後、ついでだからとあちこち見て回るとコスプレしてる人達がちらほら…。痛車の展示もあったりして。

私は多分、一般的な基準に達していないものの(そう信じたい)、基本的にヲタなのでこーゆーのは心がときめきますｗ

という事で可愛らしい女性2人にお願いして写真を撮らせて頂きました。オジサンは嬉しいです。

ちなみに初音ミクはわかりますが、もう一人は…？


そして、後から分かったのですが、左側の女性は瑞月れみさんといって最近流行の？マルチタレント活動をされてる方でした。

出番待ちの間に娘をかまってくれたので、本人も随分と喜んでいました。本当にありがとうございました！

右側の女性は大橋佑美さんだそうです。ステージではめちゃ緊張してましたねｗ


あーーー、そういえばエヴァ系のコスプレイヤー探せばよかったな・・・。

オマケ：笑えるコスプレ

自転車でGO

2回目のトライで、やっとこの自転車道を走破しました（1回目は迷いに迷って断念）。
全長36.3Kmって聞くと大した事なさそーなイメージだったのですが、やっぱ自転車だと結構な距離。
日頃からの運動不足がたたって帰る途中ヒザが痛くなり、ホント帰れないかと思いました（汗）

帰りはR248を使って距離を抑えたのですが、それでも往復で66Km自転車で移動したんだから今思えば無茶しすぎでしたね（笑）

豊田側は整備状況がイマイチ＆迷いやすいですが、所々景色が良く乗ってて気持ちがいいです。逆に安城側は整備状況はバッチリなのですが、なんにもなくて面白みに欠ける感じ。

ストレス解消にはいい感じなので、今後は豊田側だけ楽しむような形にしようかと思います。

そして写真がゴール地点（安城側）。想像はついてたけど、何もありませんでした（笑）

このl距離を走ってみて判明した課題はとりあえず尻が痛い事。前つかってたサドル（BGコンフォートクラシック）でもとっとけばよかった。あれ超レアなんだよな～。

あと自転車スマホホルダーなんか欲しいね～。

作れと言うが

本日は夢工場様よりネタの提供。

間接的に聞いたので返事はしていないのですが、『スマホであんどんが見えるようにしろ（あいつに作らせろ）』なんて事を言われました。何故そのような話題が出てきたのかは不明です。しかし名指しという事は内製でやりたいという事でしょうか（外注でやりたいなら適任といえる人は沢山います）

確かにあんどんは把握しにくいので、似たようなことは私自身も考えたことあるし、同様に他の人も一度は考えたことがあるかもしれません。

これが実現した時の効果は数値として表しづらいものの、働きやすくする、環境を改善する（騒音をなくし精神的なプレッシャーを低減）といった意味では大変効果のある事だと思います。

では、このシステムを作り上げるにはどうしたらいいでしょうか。

まず、あんどん制御PLCとリンクしたサーバーが必要です。通信にはイーサネットを使う感じになるでしょう。難しそうですが、J社のPLCは通信方法やDLLを公開しているのでなんとかなると思います。

次にそのサーバーを中心としたネットワークを構築します。広大な範囲でも通信ができるよう無線ルーターをはじめ、中継器も相当数必要ですね。当たり前ですが、それらの機器までは有線での接続になります。

スマホはもちろん会社で支給でしょうね。 自分の組だけでよければ7台くらいは欲しい所です。個人だとOS,機種、様々な問題があるしWIFIの切り替えを忘れてあんどん見てませんでした、という話になりかねません。

アプリの仕組みはサーバープッシュ？(メールみたいな方式）知識はありませんが恐らくこういった形です。

…ざっくりと考えてみましたが、なんか随分と金、時間のかかりそうな話です。

今日、改善作業をする時間が出来た事くらいで喜んでいる現場の班長に何ができるでしょうか。

少しでもいいから全体像をイメージして物を言ってほしいものです。

あと、こうした話が出た時、上の方の考えにすっぽり抜けてるのは、完成したあとのサーバーを含めた機器の維持・管理の事です。機械である以上は我々が相手している設備と同じですからね。

…あーあ、ネタにマジレスしてかっこ悪い。

ListViewのカスタマイズ

ListViewをカスタマイズして使う際、パフォーマンス的な観点からAdapterクラスのgetView()メソッド内ではView(convertView)の再利用が推奨されています。

@Override
public View getView(int position, View convertView, ViewGroup parent) {
 if (convertView==null ) {
  convertView = inflater.inflate(R.layout.xxxxxx, null);
 }
 //データをセットする処理など

    return convertView;
}

一般的にListViewは同じビューを繰り返し表示させて使う為、ビューの再利用は上記で良いのですが、データの内容によってビューがコロコロ変わる様な使い方をすると、渡されたビューが使いたいビューと異なり、NullPointerException等の問題が発生する場合があります（アクセスしようとした子ビューが無い等の理由で）

そのような時はinflateするレイアウトにidを付与しておき、渡されたビューが同じかどうかの判断材料として使います。

 @Override
 public View getView(int position, View convertView, ViewGroup parent) {
  //これはリストビューに表示するデータを表現したクラスです
  JobProcess item = (JobProcess) getItem(position);
  //データのタイプに合わせてビューを準備する  
  switch (item.getType()) {
  case JobProcess.SUBTITLE:
   if (convertView==null || convertView.getId()!=R.id.subtitle ) {
    convertView = inflater
      .inflate(R.layout.contents_subtitle, null);
   }
   TextView tvSubTitle = (TextView) convertView
     .findViewById(R.id.textSubTitle);
   tvSubTitle.setText(item.getProcessText());
   break;

  case JobProcess.PROCESS:
   if ( convertView==null || convertView.getId()!=R.id.process) {
    convertView = inflater.inflate(R.layout.contents_process, null);
   }
   TextView tvCNO = (TextView) convertView.findViewById(R.id.tvCNO);
   tvCNO.setText(item.getProcessNo());
   TextView tvProcText = (TextView) convertView
     .findViewById(R.id.tvProcText);
   tvProcText.setText(item.getProcessText());
   break;
  default:
   
   break;
  }

  return convertView;
 }

Tagを利用してない場合はそこに何か目印を付けるのもアリだと思います。

  case JobProcess.NOTES:
   //
    if (convertView==null || !convertView.getTag().equals("notes")) {
        convertView = inflater.inflate(R.layout.contents_notes, null);
        //タグに目印をセット
        convertView.setTag("notes");
    }
    TextView tvNotes = (TextView) convertView.findViewById(R.id.tvNotes);
    tvNotes.setText(item.getProcessText());
 
  break;

しかしビューを何種類も用意すると、データの『並び方』によっては再利用率がぐっと落ちますね。今自分が作ってるアプリではリストビューをスクロール（＝ビューが再利用される）するほどデータ量が無いので良いと思うのですが。

金環日食

これは書かねばなるまい（今回は長いですｗ）


小さい頃から宇宙に関する事は大好きで、親が買い与えてくれた百科事典のうち、科学・宇宙の内容が書かれた第９巻ばかり見てた事を思い出す。

小学校の授業で友達と一緒になって日食の理屈をまわりに説明し得意げになったり、当時は星もよく見えたのでオリオン座大星雲を見つけて感動したり。

そんな天文好きな俺にとって、今日の金環日食は本当に楽しみだった。

…といっても知ったのは今年の初めの頃で、この時はとりあえず忘れないようにとカレンダーにメモしておいた。

アドレナリンplz

重要じゃなくても、緊急性が無くても、
偶には単に楽しめる仕事に熱中してぇ。

そうでないとどーも気が病んでくるのぅ…。

トラノマキ その7

コンテンツの追加/編集をどのように行うか。仕様を決めかねています。

初めの構想ではWindows系アプリでしたが、ユーザーの立場を考えると『誰がわざわざアプリをダウンロードしてまで（しかも自宅で）手順書メンテせなアカンねん』って話になりますよね。

開発が楽そうって理由で思いついたのですが、こういう視点では誰も受け入れてくれなさそうです。

手順書をメンテしたいと思うであろう瞬間を想像するとやはり仕事中。そうすると、(1)Webアプリをスマホで操作、(2)トラノマキアプリに機能を組み込むかの2択。

いや、文字入力や画像作成の事も考慮すると、(3)多目的Pにアプリ組み込んで一時的なファイル作成→スマホでアップロード→サーバー側で組み込み処理、という手もありでしょうか。

多目的Pが完全にネットにつながっていれば一番楽なんですけどね。いや待て、そもそも、課専用のちゃんとしたサーバー/ネットワークがあってWifiで個人用スマホをつないでやれば…ああ、言い出すときりがない。


この際、開発におけるハードルの高さは問わないものとして…あとは操作性、手軽さを優先すると(2)案か…？

うーん本当に難しい。

コスト改革？

とある書類に目を通す機会があったんだけども、銭の話しか書いてなくて本当に呆れる。

時間だってコストの一部だと思うのだ。

一つ一つは小さくても、それが積もり積もって現場は苦しんでいるのに、何故それに気付かないのだろう。

この件はいつか言わねば。

トラノマキ その6

独自に作ったライセンス認証が通らない原因がやっと分かりました（結局SSL通信自体は上手くいってました）。

社内の人にテストしてもらった結果Android2.3端末だけNGだった為、同エミュレータを使って確認してみると、あるデータを複合化する際にjavax.crypto.BadPaddingException が発生している事がわかりました。この例外の説明を読んでも意味不明なのですが、早い話『こんな鍵つかえねーよ』って所でしょうか？

トラノマキ その5

テストバージョンをリリースしました　…が、早くもバグをいくつか発見。

• 圏外の時に更新処理をすると落ちる（タイムアウト処理の書き忘れ）
• ラインセンス認証が出来ない（致命的）

１つめは分かるからいいとして、問題はライセンス認証。よく解らないままSSL通信やってるから、まぁありえる話ですが…。いまだ疑問に思ってる証明書がどうたらって話、きっとそれ関わってる感じがします。

でもどうして自分の端末では上手くいったんだろう？？

これは苦労しそうな予感…

トラノマキ その4

大分完成が近づいてきました（ただしクライアント側の話）。

OutOgMemoryErrorの対策

bmpオブジェクトをリサイクルするだの色々あったのですが、トラノマキではImageViewを１つしか使っていなくて意味が無さそうだったので、画像を縮小して読み込む方向で解決できました。（参考記事：画面に合わせて画像を縮小して読み込む）

ライセンス認証もどき

PHPの勉強も兼ねていたし、SSL通信(HTTPS通信)や暗号化など初めて取り組みものばかりなのでかなり苦労しました。その苦労の甲斐あって、なかなかそれっぽい物が出来たんじゃないかと思います。
通信に関しては出来上がってみると通常のHTTP通信とさほど変わりないコードなんですが、未だ謎は多いですね。このあたりに手をだすなら通信技術の知識が必須だと痛感いたしました。


更新処理のパフォーマンス改善

いくつか前のエントリでも書きましたが、更新処理に時間がかかり過ぎていたのでアルゴリズムを大幅に見直しました。

変更前では目次ファイルを走査し、それぞれのファイルに対しサーバー側とSDカード内の更新日を取得し比較を行う、という方式でしたが、この方法だと (1)サーバー上に無いファイルも比較を行ってしまう (2)ファイル毎にHTTP通信によるオーバーヘッドが発生する　という２つの問題があります。

そこでサーバー側に『存在しているファイルとその更新日』をリストアップするPHPスクリプトを配置し、Android端末ではそのリストを取得、そしてそれを元にしてSDカード内ファイル更新日と比較を行う、といった方式に変更しました。

この変更によりパフォーマンスは以下のように改善しました（単位はミリ秒）

とまぁ、ドヤ顔でグラフを載せていますが最初に考えた方法が酷すぎるってことですね（このままリリースしなくて本当によかった・・・）。


という事で、あとは多少リファクタリングを進めてそれが終わったら次のステップに入る予定です。

LGS-CHASSE

前回の自転車を点検した時から数日悩んだ結果、やっぱり新しく自転車を買いました。

軽くてタイヤの抵抗が少なそうなクロスバイクにするってのだけは決っててあとはクワトロ（自転車屋）で一目惚れ。

ルイガノ LGS-CHASSE2012年モデル。後から色々調べてみたら良いもん買ったんだなぁと。

乗った感想はこうです。
マヤ『これが…CHASSE(シャス)の力なの？』

いやぁ、アホみたいに快適です。ちゃんとした自転車がこんなに楽しく素晴らしいものだとは知りませんでした。

通勤用途がメインの予定ですが、これはどこかへ出かけたくなります。魅惑の世界に足を踏み入れてしまったかな（笑

セキュリティーと効率化

久々に買ってしまいました。AndroidSeccurity とPHPの入門本の計２冊。R248の精文館で買ったのですが、ここは旧店舗時代から引き続きPC書籍の品ぞろえが豊富で、私のお気に入りの本屋です。あんざいゆきセンセのAndroid LayoutCookbookも置いてあったのでついつい買いそうになるが今回は必要ないので我慢。

なぜセキュリティー？

トラノマキリリース後のバグフィクスを視野に入れるとアプリはGooglePlayに置いた方が効率が良いのですが、そうすると可能性は低いながらも関係者以外に使用される恐れがあります。また、データの置いてあるサーバーのパスワードが現在はソースにベタ書きになっているので、いくら内容がアレなアプリでも流石にこの状態はマズイだろうという事で本気で対策する事にしました。

Androidのセキュリティーに関する記事はネット上にもありますが、断片的なのでやはり根本的な事を学ぶには不向きです。

この本は、Androidの仕組みの解説からどんな危険性があるのかを明確にし、どのように対策すべきか、またアプリ作成にあたっての失敗事例等も書かれおり大変勉強になる本です。最近多いとされる安全性に問題のあるアプリを作らない為にも是非手に入れておきたい一冊です。（同時に以下のリンクも参照すると良いでしょう）

書籍「Android Security」の暗号鍵生成方法には課題がある

【送料無料】 Android Security 安全なアプリケーションを作成するために / タオソフトウェア株... 価格：3,360円（税込、送料込）

【まとめ買いで最大15倍！5月15日23：59まで】10日でおぼえるPHP5入門教室／山田祥寛 価格：2,940円（税込、送料別）

なぜPHP？

理由は２つ。１つは先述した通り、関係者以外のアプリ使用を防止する為で、独自のライセンス認証を実装するにあたりサーバー側にもちょっと手伝ってもらおうという訳です。

２つ目はデータ更新処理のアルゴリズム見直しの為です。現在はAndroid端末側でサーバーのファイルの更新日を１つずつ見に行く形になっていますが、将来的に更新チェックするファイルが増えた場合、その処理時間も大幅に増える事が予想されます。

その為、更新リクエストがあった際にサーバー側にファイルの更新日をリストアップして返す処理を持たせ、HTTP通信によるオーバーヘッドを軽減させようという狙いです。

この本にはやりたかったファイルIO、XML、データベースのサンプルがあったので即買い。元々Perl使いだった私にとっては、導入部分に加えてこの３つのサンプルがあるだけで合格点！

PHPもなかなか楽しいですね。

←昔愛読したPerlの本。イイ奴だった…。

緒方恵美

大物からリプライ来た記念に。

ノリ良くて好きだｗ もちろん碇シンジの声で再生されました。

自転車を点検してみた

近頃温かくなってきた事もあって、なんだか自転車に乗りたい気分になってきました。

ところが私の自転車は自然にブレーキが掛かるマゾ仕様で、乗ってると本当にキツイ。タイヤが回るとうねうね動いてブレーキに干渉するんだよね。

今思えば買って間もない時期からこんな症状だったのかも…？量販店で買ったし調整でも悪いのかなぁ思って真面目に点検してみると、まぁ酷いもんでした。

やっぱりというか調整云々では無く、リムが曲がっていて、スポークも1本折れてました。あと、ハブも逝ってるようでベアリングのゴリゴリした感触が。お前まで私に負荷をかけていたのか…笑

ついでにチェーンも伸びてるようです。一番ちっさいスプロケットではどうもかみ合いが悪くなってます。

こりゃぁダメだなぁ…。

ネットで各パーツの値段をざっと見た感じだと、修理するのに１万じゃ済まない気がする。

軽い自転車欲しいなぁ。今度はクロスバイクがいいなぁ。
けど良いやつだと４～５万するんだよなぁ。

うーんうーん

答えを導く

算数の宿題が分からないと娘に聞かれる事が度々あります。今回はこんな問題でした。

半径が３cmの円が図のように３つ並んでいる時、この外周を最短で通る線（オレンジの線）の長さを求めよ


答えは至って簡単ですが、いつもこの手の問題は説明に悩みます。大事なのは答えを知る事ではなく、答えを導き出す為のプロセスを知る事だからだです。

これは仕事においても同じことが言えます。特に保全という職種では、故障した設備を素早く復旧する必要があるうえに発生する問題も多岐にわたる為、答えを導き出す（＝問題を特定する）知恵を持つ事はかなり重要な筈です。

多くの人はこの点に気づいてると思いますが、人材育成としてこの『問題を特定する能力』に着目した取り組みはあまり無かったのではないでしょうか。これは誰にでも異常が解るようにするとか、既に確立された調査方法を覚える事とは別の方向性です。

若い子らを見ていると（といっても知る限り2人か）、小難しい事はソツなくこなすものの、初めて見る現象に対して極端に弱い感じがあり、いささか心配になります。


今も昔も教育の場で教えていく内容というのは「交換手順」「操作方法」「調整方法」等が中心で、評価もそれに準じたものになっていますが(※)、早期育成を狙うのであれば、そこへ辿り着くプロセスについても重視すべきです。

もしかすると、『このような現象になったらこの部分を見る』のような答えを積み重ねていけば、こうした能力というのは経験と共に身についていくものなのかもしれません。

数少ない情報から様々な要因を想定し、切り分け、検証し、特定する。…と、言葉で言うほど簡単なものではありませんが、これは一人前に近づく為のステップであり、同時に修理屋としての醍醐味でもあると思うのです。


私は決して経験豊富ではありませんが、今後部下に対しては問題を特定していくまでのプロセスに重点を置いて物事を教えていこうと思います。（何の発表文だよコレ）


※『～についての調査が出来る』といった評価項目も存在したように記憶していますが、それこそ多岐多様なケースがあるため評価という点では順当ではないと思います。

ちなみに数か月前、技能評価で『若者の早期育成傾向が達成できている』との見解が出されましたが、こうした評価が上層へあがり社長の発言（URL参照）につながったのでしょうか。
http://sankei.jp.msn.com/economy/news/120322/biz12032218290019-n1.htm