勤怠とChrome Extension

最近JavaScriptを書いている。理由はイントラの勤怠システムを使っていて不便を感じるから。Chrome Extensionでその不満を解消しようというのが目的。

深夜、通常の業務が終了してから、あるいは、大勢の会議で自分と関係のない議論がすすんでいる時間等に書いている。Chrome ExtensionならPCだけあれば開発できるから気軽に開発できるのも良い。

とりあえずぽちぽちと書き始めたらまぁJavaScriptも書けなくないけどあんまり好きな言語ではない気がしている。pythonに慣れ過ぎただけなのかもしれないけど。varの宣言を忘れてしまってforループが無限ループにはまったり言語仕様をいまいち理解していないままに見よう見真似で書いているからかもしれない。

それでもContent ScriptsでDOMをコネコネして普段の勤怠システムでは表示されない便利情報を表示できるようになった。Chrome Extensionの仕組みをよく知らない人からはこんなことできるの？的な驚愕の声も聞こえたりして内心はほくそ笑んでいる。ローカルに持ってきたコンテンツを変形して表示するだけなのに、あたかもサーバが変わったように見えるのだし、特にソフトを専門としない人たちからすれば驚くと思う。

そんなこんなで書き始めると、あれもこれもと思い始めてBackground PageにLocat Storageとどんどんはまりつつある。どうせWindowsでしか使わないのだからCOM連携してExcel出力できれば提出書面だって思いのままになるはず。

という夢を描いてみて、さすがに提出書面自動生成までしてはくれなくても、どうせ同じJavaScriptで書いているのならオリジナルの勤怠システムでやってくれてもいいのに、なんで手元でJavaScript拡張してんだろ。使ってる人が作る事がつくづく大事だと思う今日この頃。

Chromeをイントラの公式ブラウザにできないかなと思っているが…こういうExtension書きが社内に増えるのを嫌う人がいるとならないんだろうな。あーでもFirefoxはいいのか。可能性あるかな。どこから話を持って行こうかなぁ…

Androidアプリ作る

デジカメのデータを出先で見たいとかいうのをtwitterやFacebookで問い合わせたらEye-Fi使えというリプライを多数いただいた。

でもEye-Fiできっちり連携しようと思ったらPCを間にはさまないといけないような気がしてきた。うちのPCは古いので新しいの買えよという話もあるけどあいつを間にはさむのはイヤだ。WiFiのAPにHDDをくっつけているので自動的にそこに入れて欲しいし、自動的に縮小してPicasaに入れて欲しいのだ。

なのでデジカメのSDカードをひっこぬいてAndroidに挿しておいたら寝てる間にこれをやってくれるアプリを書いてみる事にした。誰かそういうアプリがあれば教えて欲しいけど。

挿し換える方がPC起動よりハードルが低いのだ、私は。

技術屋の魂100まで

しばらく更新していないと技術屋の魂を忘れたんじゃないかとツッコまれても何も言えなさそうだけど忘れてないからね！と自分に言い訳。

gitフロントエンド

gitは自分は良いものだと思っているけれどもコマンドラインでだといまいちイメージがわきにくいところもあるのでgitkやgit guiもあるんだけどいまいち好かんというのもあって過去に一度フロントエンド作ったことがある。WinCVSのgit版のようなのが作りたくて。

でも最近自分でコードを書く機会がとんと減ってしまったのでその作業もストップしてしまっている。パブリックドメインにでもして公開しちゃっていいんじゃないかという気もするけど誰も興味ねーんじゃねーかとか。

てか、公開できる程きれいなコード書いてたっけ？という気もする。

gitの内部の構造を理解したりするのに非常に役に立ったので、これは自分としては良い経験と思っておくことにする。というかもっとうまくpython書く自分自身の練習台としてしばらくあたためておこう。

デバッガ屋さん泣かせ

過去の話を1つ。

いくつかICEは触ってきたが過去に使ってきたICEの中にTcl/Tkでデバッガの機能を拡張できる機能を持ったものがあった。その当時そのデバッガは私にとって必要な機能を備えていなかったためにTcl/Tkでデバッガを拡張した。そのデバッガの特徴は…

• 全てTcl/Tkで記載
• ARMの逆アセンブル機能もTcl/Tkで記述
• デバッガのUIは一切使わずにデバッグが可能
• メモリダンプやレジスタの変更等の基本的な機能に加えコールスタック解析をdwarfがなくてもある程度実現
• Tcl/Tkでも遅さを感じない応答性

できるものだった。elfのシンボルテーブルくらいはこのツールで読んでたんじゃないかな。ブレークポイントとかはさすがに手動ソフトウエアブレークポイントとかは実装しなかったけどものすごく便利だった。そのうちデバッガ屋さんがボクの不満を解消してソフトウェアに反映してくれるようになったのでこのツールはその時点で役目を終えたのだけど。

てか全部Tcl/Tkで書いたために誰もメンテナンスできなくなってしまった時点でTcl/Tkの限界を感じてしまった。Tcl/Tkの言語仕様はものすごくシンプルで誰が書いても同じ書き方になるし後から読み返しても意味がわかるしいいんだけど、どうしても書かないといけないコードのサイズが大きくなる。という反省からpythonに移っていったという。

今から思うとアホやなぁと思う。でもそれがある事で本当に作業の効率が上がったんだよ。という昔話。

管理職

管理職って労務管理等の業務をこなす立ち位置の人ってことだと思ってるんだけど、それだけやってれば良いってもんじゃないと思っている。むしろ労務管理なんてほとんどしない人の方がいいと思っている。といっても労務管理にまつわる作業量が少ないのではなくて、労務管理にかける時間量が少ないのが良いと思っている。労務管理というルーチンワークに関してはできる限り時間をかけずに処理してしまい、自分のグループのメンバーを導くような仕事をきっちりこなせるのが良い管理職だと思っている。

ということで管理職になってからもいろいろとツールを作っている。部門内の業務の体制を書いて出したりする資料があるけれどExcelで提出しないといけないらしいのでyamlの簡単版みたいなテキストを書けばExcelの資料に変換するツールとか、勤怠入力で残業時間の入力忘れとかがないかをチェックするツール(こんなのイントラで対応して欲しいけど)とかを自作して効率を上げている。書いてるのはpython+wxPythonでExcelの操作はxlrdやxlwtを使っている。でも管理職の業務ってルーチンワークといえども日々発生する作業よりも半年に一回とか月に一回のものも比較的多いのであんまりツール作るモチベーションが高くないのも事実としてはあるかなぁ。

という事で管理職というポジションをやりながらもpythonでツールを作成するという事も並行してやっている。忘れてないよね、魂。

Androidのroot取得とJN-DK01

ここには会社に所属する人間としての意見ではなく個人の意見として書くことにする。もしこのブログを読む人がいたらそこは理解して欲しい。

Android端末のroot取得については私自身が個人で購入した端末に対してはきっとやらない。なぜなら何が起こるかきっちり考え切れるものではないしそれが単純に恐いから。そういう使い方を想定して作られているわけではないし知らないところで何かやらかして誰かに迷惑をかけるかもしれない。それがイヤなだけ。

でも、rootを取りたいという気持ちはわかる。その気持ちの1つは言葉は適切じゃないかもしれないけど探究心だとかそういうものだと思う。GPL部はソース開示しているので見れば何を書いているのかは理解はできる。そこに書いてあるものを改善したり、他の方法を試してみたりする場合にはソースがあっても動作させる環境が必要になる。だからそこに存在するソフトウエアが動作するハードウェアが必要だというのはそういうものだろうと思うし、オープンソースというのは本来そうあるべきだと思う。ただし、GPLで開示している範囲については非常にプリミティブな機能が多いのでそこまで厳密に同じハードウェアでなくても動作検証はある程度はできるのではないかと思っている。じゃあそういう検証ができないものって何だろうと考えると思いつくのはその端末に固有のデバイスを操作するためのデバイスドライバがそれに相当すると思う。ただ、デバイスドライバのソフトウエアを変更する上ではソフトウエアが存在するだけではダメで、そのハードウェアのスペックがわからないと普通は書けない。タイミングなどの問題もあるのでソフトウエアでは理論上問題のない内容になっていたとしてもそれが実際に動作するかは別問題だ。なので、いくらソフトウエアやハードウェアをオープンにしたとしてもこの問題は解決できないと思っている。

ここでもしも私が部品メーカの立場の人間だったらと考える。部品メーカの人が自分の部品を動かすためのソフトウエアを販売する事で商売するという可能性があるか？と質問されると私はあると思っている。オープンにするソフトウエアは非常に基本的でノウハウの含まないものにしておき、最大限にパフォーマンスを発揮するためには自分たちのノウハウを詰め込んだプロプライエタリなデバイスドライバを販売するという場合だ。ソフトウエアに自信があるのならこういう選択肢もあるだろうけれど、この戦略をとる場合であってもソフトウエアはオープンにする必要がある。一方で販売するものはハードウェアでありソフトウエアはリファレンス程度でしかないというケースも考えられるだろう。この場合にはソフトウエアをオープンにする事で得られるメリットがあると考えている。でもソフトウエアをオープンにするためにはその部品のハードウェアのスペックも公開しないとその目的が達成できない(前者の場合はそうじゃないかもしれない)ので、ハードウェアのスペックは部品メーカがソフトウエアをオープンにするとともに公開するのが良いのではないかと思っている(このへんの考えは自分がその立場じゃないので甘いかも)。自分たちの部品を使ってもらうために市販されている開発用の基板に部品を接続し、オープンソースのみを使ってリファレンスのソフトウエアを作成し、部品のスペックとともにソフトウエアを公開しハードウェアを販売する。ソフトウエアは一部の協力的な人の手によって問題点が改善され、作った自分たちもソフトウエアを改善する時にはオープンソースにコミットする。ハードウェアが自身の勝負するフィールドである場合には、ソフトウエアのメンテナンスのコストを削るためにはこういう方法が考えられるんじゃないかと思っている。逆に端末メーカから部品のスペックをオープンにするという事は普通はできない。

さて、rootをとるための手段についても考えてみる。脆弱性をついてroot昇格するというのはroot化という単語を聞いた時に素直にイメージできるものかもしれない。でも、Androidの場合はuserビルドではなくengビルドやuserdebugビルドをする事でroot権のとれるROMイメージなどというのはすぐに作れてしまう。JN-DK01というのはuserdebugビルドしたROMイメージが書き込まれて販売された端末だ。adb rootですぐにroot取得できるし、fastbootでROM書き換えも可能。これは端末メーカとして出せる1つの答えだ。Gadget1に参加した時にもJN-DK01の再販署名運動が一部で起こったくらいにこういう需要は少ないながらもあるものだと思っている。まぁこういう端末を作るには非常にいろいろな準備が必要になるのでそう単純ではない。この準備をしないでuserdebugした端末を出せばいろいろなところでほころびが発生しAndroidの上で組み上げられた世界が崩壊すると私は思っている。Androidのセキュリティを勉強する会で話した意図はこれに該当する。でも、こうした開発用の端末を自分たちで用意しないでroot取得をしないで欲しいとお願いをするのは片手落ちだとは思う。

理想的には、ちゃんとオープンにできる製品として組み上げられた商用の電話機ではない開発用のAndroid端末(これがJN-DK01に相当する)が用意され、そこに搭載されている部品のハードウェアのスペックが部品メーカから公開され、ソフトウエアも全てオープンになっていれば、探究心は満たされると思う。少なくともJN-DK01の時には私はこれをめざすべきだと思っていた。

探究心以外の目的でのroot取得についてはAndroidのセキュリティを勉強する会で話をした通りであり、やってはいけないという線は必ず存在する。こちらはこちらできっちりと対応をすすめていくべきだと考える。

あくまで1つの意見として。