2014年07月12日

ローカルチケット管理ツール

Twitter で「深夜の真剣お絵描き60分一本勝負」と言うものが流行っていて、何か楽しそうなのでプログラミングでやってみようと言うことでトライ。
1時間コーディング(今日のワンコー)と言うことで。
ドキュメント書く時間は入れずに、コーディングとテストの時間を1時間として、あったらいいなと思っていたものをとにかく作ってみる。

作りたい物リストを管理するのに、TRAC でやっているけど、重いので軽いのが欲しいと前々から思っていた。
そこで、ローカルでだけ動くチケット管理ツールを作ってみることに。

LocalTickets

ギリギリ1時間でとりあえず使えはするものは出来た。
1時間短い。
使いやすさ考えるともうちょっと作りこみたい。
明日また1時間コーディングで強化するかは明日考える。

ツールの使い方は、雰囲気でなんとなく理解してください。
強化することがあったらちゃんと書きます。

投稿者 Takenori : 23:19 | トラックバック

2014年07月15日

Amazon 購入履歴ダウンローダ

何度かバージョンアップしているので、ダウンロードページ分離しました。

Amazon 購入履歴ダウンローダのページ

ダウンロードや使い方などは、リンク先を見てください。

にしても、1時間コーディング 2回目にして全然1時間で終わらず。
6時間くらいかかってしまった。
完成したものは、1時間程度の出来なので、最初の実装方法の選択ミス。

最初は IE でログインして HttpWebRequest を使って履歴をダウンロードしようと思っていたんだけど、どうもクッキーは IE と別なようでログイン状態にならなかった。
今まで他で WinInet だと IE でログインすれば、そのままログイン状態になっていたので、同じようにできると思っていたが出来ず失敗。
ログイン処理を自分で書くと1時間で終わらないこと確定。
ブラウザと同じようにすればログインできるんだけど、これが色々と難しい。
仕方なくログイン処理を実装しようとしたがうまくいかず。
もう一歩何だが何かが足りず。

時間かりそうだからあきらめて次に WinInet を使う方法を試すことに。
wininet.dll のメソッドを呼んでダウンロードするもログインできてない。
少し試したがダメっぽい。
この方法もあきらめて、wininet.dll で IE のクッキーを取得して、HttpWebRequest へそのクッキーを渡してログイン状態を維持する方法を試したが、これもうまくいかず。
だいたいはクッキーのセッション情報を渡せばそのままログイン状態になるんだけど、Amazon はそうはならず。
もうちょっと頑張れば何が原因かつかめそうな気もしたけど、時間かかるからさっさとあきらめて別の方法へ。

結局ブラウザを埋め込んで、そこでログインしてもらって HTML データを取得する方法にした。
自動で次々に読み込む方法にしようかとも思ったが、セミオート方式にした。
そして終わってみると6時間くらいかかっているのである。

今回のことでよくわかるのは、実装方法の選択によって実装時間が大きく変わること。
今まで WinInet + perl or C++ などで IE でログインして、その後ツールでデータ取得と言う方法をよく使っていたので、同じようにしたらすぐにできると思っていたのが間違いだった。
今後は今回の方法と今までの方法のどちらかうまく行く方を選択して使えるので、時間短縮できそう。
ログインできなかった理由を完全に解明すればもっと役立つかもしれないが、Amazon が何か凝ったことをやっているんだろう。
通信のヘッダーやパケットを観察すればできそうだが……
ブラウザの http 通信のログとか見て色々とやっているところは見た。
本気で作る気になったら頑張る。

投稿者 Takenori : 14:11 | トラックバック

自前広告エディタ

SelfAdEditor.zip

自前の広告を配信するための DB を編集するツールです。
これ以外に CGI がないと意味がありません。
CGI はまた後日作ります。
UI がわかりづらいです。

左の3つ広告名、URL、説明を入力して、「広告追加」で広告を追加します。

画像ファイル名に画像ファイルのパスを入れて、「選択されている広告に画像を追加」でリストで選択されている広告に画像を追加します。
フルパスで入力します。
参照で選んだ方がいいです。

クライアント名に名前入力して、「クライアント追加」でクライアントを追加します。
クライアントは広告を受信する対象の名前です。
なくてもいいですが、どのクライアントでどれくらい広告が表示されているかなど調べるのにあったほうがいいです。

表示対象は左に何を表示するかを選択します。
下のリストで右クリックするとポップアップメニューが出て、選択してる項目を削除できます。
広告を削除すると、その広告の画像はすべて削除されます。

以上追加方の説明ですが、CGI がないと動作がわかりづらいですね。。

それはそれとして、今日も1時間で終わらず。
1.5時間くらいかかってしまった。
エディタのみならぎりぎり時間程度でいけるかと思ったけどちょっと甘かったか。

投稿者 Takenori : 23:53 | トラックバック

2014年07月17日

自前広告CGI HTML出力

昨日作った自前広告エディタが出力する db を使用して、CGI で広告を出力するものを作った。
とりあえず HTML での出力のみ。
このページのエントリーの下にある広告がそれ。
以前は直接埋め込みだったけど、CGI で出力する形になった。
今のところほとんどデータ追加していないので、前と同じような広告しか出ない。
HTML 以外に JSON 出力は明日かな。
ホームページなら iframe で html 埋め込みでいいけど、ツールなどは JSON で画像と URL もらって、それを使って表示するような形にする必要があるだろうと言うことで。

広告は自分で何か作っているのなら、その広告を出すのが一番効率的だろうと言うことで前から作りたかった。
他のだと数%だけど、自分のが売れたら100%だしね。

1時間程度でできていたんだけど、アップロードしたら sqlite_unicode に対応していないようで文字化けして、しばらく悩んで数十分オーバーしてしまった。
後、DB にもうちょっとデータ追加して種類増やしたい。

投稿者 Takenori : 00:14 | トラックバック

2014年07月18日

1Bitフォントテクスチャ生成ツール

FontTex1Bit.zip

Unity での日本語描画 その2 テクスチャ仮想多重化 で書いたようなテクスチャを作るツール。
1ビットずつフォント画像を重ねていく。

出力する ttf か otf ファイルをドロップして読み込む。
出力する文字を UTF-8 で羅列したテキストファイルをドロップして読み込む。
JIS第二水準漢字まで羅列した glyph.txt を添付しているので、これを使うと楽だと思う。
文字の周囲1ピクセル隙間を開けて配置するので、文字サイズ+2 が 1 文字の大きさ。
文字高さを 62 とすると 64 ずつで区切られる。
保存で PNG ファイルと同名の JSON ファイルが出力される。
JSON は文字コードをキーとして、
LSB からのビット位置、X位置、Y位置、幅、高さ、表示位置左、表示位置上、進む幅、進む高さ
の 9要素が配列で格納される。
JSON はバイナリ化した方が扱いやすいと思うが、ツールの出力としては JSON の方が好きに扱いやすいだろうと言うことで JSON で出力。

このツールで吐かれたテクスチャは専用のシェーダー書かないと描画できない。
それはまた後日。
読み込み側を作るとまた不具合が見付かる可能性が高い。

説明は以上。

で、今日も1時間では終わらず、3時間くらいかかってしまった。
SharpFont がなんかちょっとおかしく手間取ってしまった。
bitmap での出力が正しくない様子。

昨日広告の JSON 版作ると書いたけど、やっぱり止めてテクスチャツールを作った。

投稿者 Takenori : 02:18 | トラックバック

自前広告CGI JSON出力

前回の 自前広告CGI HTML出力 に JSON でも出力できる機能を追加した。
エディタに CGI も添付し、readme.txt に使い方を書いた。

SelfAdEditor.zip

JSON 形式が問題なく使えるかはまだ確認していないので、何かしらアプリに組み込むときに修正する可能性がある。

以上説明。

今回は、JSON での出力を追加しただけなので 30分くらいで終わった。
いくつか DB に広告も追加したので、このエントリのすぐ下に表示される広告の種類が増えている。
自分の広告がいろいろと表示されていい感じ。
表示の仕方はもう少しいじった方がいいかもしれない。
CGI から分離してテンプレート指定で出力できると使い勝手がよくなりそう。

投稿者 Takenori : 23:30 | トラックバック

2014年07月19日

早く作ると言うこと

1週間くらい1時間で作ると言うのをやってきたので、今日はその感想など。

「もっと早く作るにはどうすればいいか?」と言うのは常日頃から考えることだけど、1時間と言う時間制約があるとより強く「もっと早く作るにはどうすればいいか?」と考える。
規模の差によって普段の開発に活かせない部分もあるが、多くは活かせる。
地道な開発効率の向上はいつか大きな差になる。

作っていて思うことは――

MSDN の表示が遅い。
ネットで API 検索して MSDN のページだと表示に数秒待たされる。
待っている間は何もしていないので、確実に時間を失っている。
MS は開発者の貴重な時間を奪いたくて表示を遅くしているのかと思うほどだ。
Android の API も遅い方だけど、MSDN はなんかクッションページみたいなのがあるのか、変なローディングがあって遅い。
早く開発するうえでネットの速度は重要だと思うが、相手が遅いとどうしようもない。
最近は MSDN のドキュメントをローカルに入れていないんだけど、インストールできるのならした方がいいかもしれない。
と、書いている途中にインストール方法探して入れることにした。

マシンは速い方がいい。
比較的早いマシンを使っているが、定期的に速いマシンにリプレースした方が効率的だろう。

画面は広い方がいい。
1600x1200 ×2個 と 2048x1536 の小さいのをサブで使っているが、4K で 40インチくらいのが欲しい。
それならフルHDで20インチ4枚分なのでかなり広そう。
4K ディスプレイの種類が早く増えて欲しい。

余計なものは排除して集中できる環境を作る。
コーティング開始する前に集中力を奪うものは排除して、出来るだけ集中できる環境で開発した方がいい。

C# はコンパイルが早くてすぐに起動して快適。
C++ はそれに比べると遅い。マルチスレッドコンパイル+SSDでだいぶ速いがそれでも遅い。
Visual Studio の C# のサポートは色々と助かる。C++ もかなり助かるが、C# には劣る。Eclipse の Java サポートも助かる。

ここまでは環境の話。
実際に開発するうえでどうすればもっと早く開発できるか?

使ったことのある API やライブラリを使う場合は開発時間を読みやすいし、想定外のことは少ない。
ただ、開発していると新しいものをどんどん使う必要があるので、この部分はひたすら色々なものを試して経験を積むしかない。

ツールによる効率化は大事。
ツールで自動生成されたり、サポートされると効率的に開発できる。
ツールの整備は開発効率を上げるうえで重要。

ライブラリの整備は大事。
ライブラリがあり、その間をつなぐだけなら開発は短縮できる。
ライブラリの整備は大事。

ツールの使い方に習熟する。
主に開発に使うツールでより効率的に開発できる操作方法を考えたり調べたりするのは大事。
わずかな差でも何度もやっていると大きな時間になる。


環境の改善、ツール・ライブラリの整備によってもっと早く開発できるようにしたい。
1時間と言うと、このくらいのものと言う限界がある程度想像できるが、その範囲を少しでも広げたい。
GUI 周りを作る時どうしても、パーツ配置してイベントハンドラ記述してと言う部分に時間を取られるので、この辺り必要なものを見栄えの良い配置で自動的に生成してくれるツールがあると早く開発出来る気がする。
どのような入力項目が必要かは最初に考えるので、それをリストアップした後は自動で並べてくれると早く作れる。
他にも欲しいものは色々とあるので、順に整備していきたい。

投稿者 Takenori : 23:09 | トラックバック

2014年07月20日

TJS2 ドキュメントジェネレータ その1

TJS2 スクリプトからそこに書かれたコメントを用いてドキュメントを生成するツールの途中まで。
ツールの基本構造は、TJS2 スクリプトを読んで、JSON 形式で出力する形。
実際にドキュメントとするには、JSON を読んで任意の形で出力する必要がある。
JSON になっていれば、そこから整形してドキュメントにするのは簡単なので、その手前までをやるツールがあればいいと言うことで、作ってる。

tjs2doc.zip

完全に構文解析するわけではないので、疑似コードでもある程度何とかなる。
今のところコメント内部は解析していないので、単純に comment 要素にコメントの中身がそのまま入るだけ。
javadoc 形式等でコメント内部を解析して、構造化するのはまた今度。
関数の引数も解析していないので、そこもまた今度。
字句抽出レベルでの文法エラーがあった場合は、エラーが出るはず。
エラーが出る場合はまだテストしていない。
実際にどんな形の JSON になるかは動かしてみればわかる。
その JSON 見れば意味もすぐに分かるはず。

これで1時間半かかった。
1時間くらいで出来ると思ったんだけど……

投稿者 Takenori : 23:53 | トラックバック

2014年07月21日

TJS2 ドキュメントジェネレータ その2

昨日の続き。

tjs2doc.zip

関数の引数の解析とコメントを javadoc として解析を行って、JSON に出力するようにした。
comment は raw にそのままの内容を、他のメンバに javadoc 解析した結果を入れる。
入る内容は以下のような感じ。
summary : ""
param : { name: "", desc: "" }
return : ""
throw : ""
author : ""
version : ""
see : ""
description : ""
unknown : ""

これで出力された JSON を使ってドキュメントを生成できる。
プラグインのドキュメント化することを考えると、@dll や @lisence 、@url、@category など追加してプラグインのドキュメントを作りやすくした方がいいかな。
後、今ファイルヘッダーコメント入れていないけど、それも入れた方が良さそう。
JSON からドキュメント生成するツール作る時に機能追加しよう。

今日はだいたい1時間だった。

投稿者 Takenori : 23:56 | トラックバック

2014年07月23日

部分的に1バイト文字にして速くなるか?

Slimmer and faster JavaScript strings in Firefox

これを読んで TJS2 でも同じように ASCII 文字列で格納すれば早くなるか試した。
結論を最初に言うとうまくいかなかったんだけど(部分的な変更では無理そう)。

TJS2 は文字列を tTJSVariantString で保持していて、21文字までなら固定長領域に格納される。
これを ASCII 文字列の場合は 43文字まで格納し、ASCII 文字列で比較すれば今までよりも長い文字列を固定長領域に保持でき、比較時も半分の長さを比較するだけで済む。
ハッシュの生成も半分のバイト長。
難点は、2バイト文字のポインタを得たい時には2バイト文字への変換とメモリ確保が発生してしまうこと。
で、この処理がキャストのオーバーロードで実装されていて、色々と使われている。
内部で文字列が tTJSVariantString で表されていればこの処理は使われることは少ない。
ただ、残念なことに tjs_char* で行われている処理が多い。
TJS2 の各種メンバアクセスのうち、PropSetByVS と言うメソッドだけが tTJSVariantString を使って検索していて、他のメソッドは tjs_char* で検索を行う。
だから、ASCII 文字列で保持しても出番が少ない。
全メソッドに ByVS 版を追加するとインターフェイスが変わってしまうし、量がある。
つまり、部分的な変更ではダメっぽい。

TJS2 は以下のような実装になっている。
文字列は全体で保持しているものがあり、同じ文字列の場合はだいたい共通のポインタを指すような実装になっているから、tjs_char* での文字列比較と言っても、一致するのならポインタ比較ですぐに終わる。
ポインタが一致しない場合は、文字列比較になる。
ASCII 文字列で格納するのはもうちょっと考えないとダメっぽい。

今回 tTJSVariantString の ASCII 文字列格納の実装に 1.5 時間くらいかかった。
ちゃんと動くようにもなったんだけど、速くならなかった。
理由は上述の通り。

投稿者 Takenori : 03:33 | トラックバック

2014年07月24日

TJS2 ドキュメントジェネレータ その3

tjs2doc.zip

squirrel プラグイン の manual.tjs を変換したもの

フレームとインデックス部分はないけど、それ以外の部分はだいたい動くようになった。
もうちょっと作りこめば、plugin フォルダ内の各プラグインの manual.tjs からドキュメントが生成できそう。

今日は、結局2.5時間くらいもかけてしまった。

投稿者 Takenori : 01:09 | トラックバック

2014年07月26日

TJS2 ドキュメントジェネレータ その4

複数ファイルを受け付けてマージして出力する形に修正した。
プラグインの manual.tjs をまとめて出力してみた。

プラグイン API リファレンス

マージして出すのは、TJS2 スクリプトから生成するときはいいとしても、このプラグイン API リファレンスのようなものだとちょっとごちゃごちゃしすぎか。
プラグイン名 クラス名...、プラグイン名 クラス名... と並ぶ方がプラグインの場合は、見やすそう。
出力方法をマージ方式かファイル分割方式のどちらか選択式にして、プラグイン名をコメント内にいられるようにしたら、とりあえずは完成かな。

デフォルト引数とプロパティの読み/書き対応、継承 の認識辺りも未対応だけど、区切りがついたら一度ソースコードを修正BSD辺りで吉里吉里Z プロジェクトにコミットするかな。

今日は45分くらい。
その後プラグインフォルダの manual.tjs の修正に時間かかった。

投稿者 Takenori : 00:38 | トラックバック

2014年07月29日

吉里吉里Z 64bit版試作

今日のお題は吉里吉里Z 64bit版。
2時間くらいかかって、ビルド通ってある程度動くところまで。

tvpwin64.zip

とりあえず制限として
・JPEG の読み込みは無効化しています。
・Phase Vocoder は動きません。
・WAVE で 16bit float 変換がある部分は動きません。
・グラフィックで SIMD 系が使用されないので、その辺りの合成は遅いです。
・FPU の精度設定か何か周りが何もしてません。
・例外発生時のCPUダンプ周りが怪しいかもしれません。

追加機能として
・CPU の機能は、AVX2 まで取得できるようになっているので、ログにいろいろ出ます。

後、Variant 型からポインタ変換している辺りや Win32 API 周りで問題があるかもしれません。


JPEG は SIMD libjpeg が 32bit なので、まだ対応してない。
libjpeg-turbo は、64bit 対応しているはずなので、そちらに差し替えれば対応できる。

Phase Vocoder や Wave は、アセンブリからイントリンシックに書き換えないとダメ。
グラフィック周りも、アセンブリからイントリンシックに書き換えるか、アセンブリを 64bit 対応させないとダメ。呼び出し規約周り合わせればいけるかも。

FPU は、_control87 で落ちるので無効化しといた。
64bit だと何か違うんだと思うけど、調べてない。

投稿者 Takenori : 02:15 | トラックバック

2014年08月10日

QUMARION ロガー

ずっと誇りかぶっていた QUMARION だけど、SDK の制限が少し緩和されたと言うことで、QUMARION を自分にとって使えるデバイスにすべく何かツールを作ることにした。
QUMARION は入力デバイスだけど、言ってしまえば表示デバイスでもある。
CLIP STUDIO ACTION で QUMARION を操作しながら画面を見て動かしたり微調整したりするのは、なんだかもどかしい。
そもそも形としてポーズがそこにあるのだから、現在の状態を順次記憶して、そのデータを後で 3D アニメーションツールで時間指定や微調整できる形の方が扱いやすいのではないかと思い、背中のボタンが押させれた時に順次そのポーズを記録していくツールを作ることにした。

ツール自体は C# の方が楽に作れるだろうと思って作り始めたが、C# から DLL へアクセスするラッパークラスを書いているだけで、1時間経ってしまった。
その後実際に呼んでみると cdecl で、マングリング もされていると言うことで、ラッパークラスをまた色々と書き換えた。
で、2時間くらいかけて初期化部分まで書けた。
1時間コーディング 3日かけてここまで。

ここまでできれば後は楽。
ポーリングでデータを取得し、ボタン状態を確認して、ボタンが押されたタイミングでのポーズデータを順次書き出していけばよい。
その辺りは次に作る。
今は初期化までできたところ。
出力は BVH ファイル形式でやるつもりなので、そのデータフォーマットの調査も必要。
ボタン押されるたびに 1秒程度時間を進めて各種ボーンデータを書き出していくことになると思う。
その後、時間間隔の調整ツールを作るか探すかすると思う。
不要キーフレームの削除ツールも必要か。
BVH ならたいていのツールで読めると思うので、そっちで何とかできるんじゃないかと思っているけども。

qumalog20140809.png

投稿者 Takenori : 23:27 | トラックバック

 
Total : Today : Yesterday :