ログ取得ツール計算結果の問題は、入力データのshapeの違いによるものだったみたい。元のモデルと違うデータを入れないとダメってことみたい。何らかの都合によるものなんだろうな、たぶん…と言うわけで、どうにか正しくなった。
graphファイルの入力データのshape情報とかCPU数の情報とかも、何となく分かってきた。gistのファイルは修正済み。
ようやく次に進めそうな感じ。道のりはそれなりに長いが。
Category: プログラミング
先日のNCSだが、caffeのモデルをそのまま使ってCPUで計算した値と、NCS用にコンパイルしてNCSで実行した場合の結果が異なるという事件に悩まされている。
例えばexampleのcat.jpgはこんな画像なんだが…
caffe> 0.469843 n02123045 tabby, tabby cat
ncs> 0.18958 n02124075 Egyptian cat
そもそも自分にもこいつが何キャットなのかうまく判別できないんですが、普通のネコじゃ…ダメなのかな？ しかし同じモデルで同じデータを食わせているので、結果は同じになってほしいんだがなぁ。色々やっていると、caffe側が正しそうな気がした。NCSの使い方を間違ってるのかも。イメージのロードのTransformerの引数に固定値を入れているのが間違いなのかもしれない。そこ以外に思いつかないよ。
作ってみたテストプログラムは以下のgistに。bycaffeとbyncs2サブコマンドに同じ引数を与えて使ってます。なかなか難しい。そもそも画像認識したいわけじゃないんだ俺は。誰もが「ひよこ鑑定士」を失業させたいわけじゃない。ここはサクッと終わらせたいのに！
子供がTVに影響されて「プログラミングをやりたい」と。マジですか。これは親の許可を得るようなものなのか…とも思ったけど、うちは母親が厳しくてTVやゲーム、PC、スマートフォンへの接触が極端に制限されているんですよね。まあ母親自身がTVは大好きなのでTVだけはやたらに緩いんだけど。私はどっちかっていうとTVを制限したくて、ゲームはほどほどに、PCには自由に接触させてもいいかなと思っているんですが。たまに悪いことしてないかチェックする程度で。
で、長男はゲームの時間を削ってでも「プログラミング」やってみたい、という話。TVは削りたくないらしいが。そこで、Scratchの使い方を適当にチュートリアルの進め方を教えて時間制限だけはかけて、放っておいた。しかしPCを使い慣れてないためか、うまくできないのよね。チュートリアルは説明は日本語になって読めるんだけど、画像が英語のままっていう問題もあって、日本語の説明は読めても、該当するパーツがどれなのか分からない様子。すごい頻度で「これどうするの」「できない」と呼ばれる。ただし自分にとってもScratchは初見。無論、英語やコンピュータ世界のコモンセンスを解するぶん彼よりも分かることも多いんだけれども。
私はPythonは結構長いことちょくちょく使ってきたけど、今までipythonとかptipythonとかjupyter notebookとか使ってないんです。いつも素のpythonコマンドを使っていた。同じように、nodejsもnodeコマンドだし、Rubyはirb。それで別に何の不自由もないよ、と。
ただ、ipythonの奴らとかは、シェルコマンドも同じプロンプトに打てるんだよね。さらに、jupyter notebookは保存したりcheckpoint/restartもできたりするし、ブラウザのインタフェースで処理系がサーバサイドで動けるのでそれが助かったりもする。「デスクトップ環境はMacだけど、PythonはLinuxで動かしたい」とか「性能の高いリモートのマシンで動かしたい」とか、そういう時の話ね。
jupyter notebookはカーネル(利用する処理系)を各種切り替えられるみたいなので、Python以外のユーザも使っているみたい。
そんな奴にうちの大事な娘をやるわけにはいかん！！ ← お茶パシャ〜
JavaのDIを愛する奴にロクな奴はいないの続き。この↓問題ね。
package org.abc.def;
@Component
public class Xyz extends BaseX {
package org.abc.efg;
@Component
public class Xyz extends BaseX {
別パッケージに同一名のクラスを作りたい場合の対応方法。
確かに@Componentに引数をつけて@Component(“blablabla”)とすれば、起動時のエラーはなくなる。ただし、Context.getBean(org.abc.def.Xyz.class)するときにエラーになる。例外の名前は忘れたけど…クソが。
ではどうするか。
正解は、クラスを与えて"blablabla"部分を求めるメソッドがあるから、そちらを呼んで"blablabla"側の文字列を使ってインスタンスを作る、でした。なんて便利なんだろう？ 革命的な便利さだよ？
…これをアホと言う以外の評し方をするのが難しいよ。単にnewでいいじゃんか。書くことが増えてハマりやすく、不便になって、その挙句に遅いときた。いちいちログ出し過ぎなんだよ。クソが。
乗り換えるか否か…
giteaのlfs対応を見てみた。まあ、ひととおりのところは使えるみたい。droneから見るときはgogsと同じだと思えばいいのかな？
とりあえず、lfsを使うケースとしては、リポジトリサーバとしてバイナリをそのまま放り込んでraw urlでアクセスさせるとか、そういう使い方が考えられる。
raw url対応はどうか。
- サイズ0のファイル(非LFS)が1024バイト読める
- なぜ？
- gogsもそれは同じだった
- 簡単なバグで原因は分かった気がする。gogsのほうにissueを書いてあげたけど、直すかなあの人…
- それ以外のサイズにするとちゃんとしたデータが読める
- LFSのraw urlは普通のやつとは別形式
- メタデータっぽいものが読める
というわけで、あんまりraw urlは信用できないっぽい。まー、しばらくはgogsかな。gogsはraspi向けビルドも分かりやすい置き方だから助かる。むかしgogsでarm用のをraspiで使おうとしたらNGだったことがあるんだよね。それでraspi向けビルドを使うようにしている。
先日こういう話があったばかりだが、、、
CIツールのdroneは仕事でよく使っている。非常に便利なものであって、広まって欲しいなと思っているんです。
そこで、自分でローカルで遊ぶのはどうやるんだろう、と思った。昔はdroneにCLIがついていて、MacでそのCLIをコンパイルしておいて、docker-machineで立てたdockerを相手にローカルディレクトリの.drone.ymlを実行するみたいなことができたんだけど、今はもうできなくなっているようだ。
そこで、docker-composeでコンテナを立てることを考える。drone自身はアカウントを持たないので、ログインするアカウントとして連携できるリポジトリサーバが必要。リポジトリサーバは色々対応しているが、こちらもローカルで立てるんなら、gogsが最も手軽だろう。
そこで、適当にディレクトリを掘って、こういうdocker-compose.ymlを作る
https://gist.github.com/wtnb75/a273b8c03131fe8a7b561a2177a11406
そして、実行する。
# DRONE_SECRET=$(uuidgen) docker-compose up -d
Creating network "drone_default" with the default driver
Creating gogs
Creating drone
Creating agent
# open http://$(docker-machine ip):3000
# open http://$(docker-machine ip):8000
3000の方がgogsで、8000の方がdrone。gogsはsqliteでセットアップする。他のDBMSにしたい時は適宜docker-compose.ymlをいじってDBのコンテナを立てればいいと思います。URLやドメイン名はdocker-machine ipのIPアドレスを使うといいだろう。リポジトリを作ってpushしてみよう。
drone.ioがサービス停止したみたいですね。https://archive.drone.io/ によれば、
Your repository configuration and build history will remain available for the next 90 days. After 90 days all data will be purged. Please login below to access a read-only copy of your data.
まあこれ…儲からなかったんでしょうね。お金払って使っていた人はいるんだろうか。
droneのOSS版はいろんな会社の社内で使われていると思います。自分も非常に便利に使わせてもらっているわけですが、ここまで便利なものでもビジネスにするのは難しい…ってことかもね。OSS版の開発が続くかどうかは心配している。
publicなものではまだtravisがあるから、githubユーザはそっちに移行していく感じになるんだろうな。
setterとgetterというバカバカしいものがありまして。クラスの中のメンバ変数をわざわざprivateにして、publicメソッドのsetXXX()やgetXXX()を作ってその変数にアクセスさせるという。結果、メンバにアクセスするコードはこうなる。
a.getXXX().getYYY().getZZZ().setAAA(1);
これ、外からprivateメンバにアクセスしてるんですよ。こういうイリーガルなコードが世間に流布していて、あまつさえ書いてるやつらは正しいことをしてると思ってるんです。クソが。
まあ、そういう文化と称するものがあるんですよ。何でもかんでもprivate変数にpublicなgetter/setter。これをIDEが自動生成するからいいんだそうです。おめでとう、人類はそこまで思考停止するようになった。例えば将来、最高に頭のいいコーディングAIが出てきたとして、そいつが書くコードがgetter/setterの嵐になっていることを想像できるでしょうか？ なってるわけないですよね。
かねがねから私はJavaのDIを信奉する人々を信じていなかったのだが、決定的なクソ仕様を発見したので、嬉々としてご報告する。
ソースがこんな感じになっているとする。パッケージが異なる同名のクラスね。
package org.abc.def;
@Component
public class Xyz extends BaseX {
package org.abc.efg;
@Component
public class Xyz extends BaseX {
これ、エラーになってプログラムは起動すらしません(ConflictingBeanDefinitionException)。component scanにゴテゴテに書けばどうにかなる可能性もあるけど、こんなんウンコでしょう。ネームスペースのことを理解していないんですよこいつら。パッケージが違ってクラス名が一緒なんてそこら中に転がってることでしょう？ java.util.Optionalとcom.google.common.base.Optionalとか、タイムスタンプ系の各種DateだのTimestampだのTimeStampだのとか(すでに忘れてるけど、要するにたくさんある)。それはDIの世界では決して許されない。