駄々more

高裁でWinnyの作者が逆転勝訴しました。
いやー、めでたい。

オレ自身はWinnyなんか触ったこともねーんだけど。
一時はソースコードも公開されたって言うじゃない。
プロトコルもろバレのP2Pで違法ファイルを交換するって・・・俺にはWinnyを使う勇気は無いよ。
そういうことは、ちゃんとセキュリティを確保して･･･ゴニョゴニョ

そもそも、Winnyユーザーにとっては、この裁判の去就は全く関係ない。
"明らかに存在する著作権法違反" を、作者が幇助したのか否か、というだけの話だから。
つまり、Winnyユーザー(の多く)は有罪、という前提の下でのオハナシ。
この裁判が気になるのは、ウィニーユーザーじゃなくて、ソフト開発者の方だ。

そもそも、なんで作者が起訴されたのか不思議でたまらない。
犯罪に使われうる道具を作っちゃダメ　というなら、明らかに法定速度以上のスピードが出るスポーツカーとかはどーなのよと。
交通事故の裁判では、メーカーの設計者も共犯なのか？

つーか、コンピュータソフトウェア著作権協会（東京、ＡＣＣＳ）とやらが、作者と反対の立場にいることにビックリ。
一般人や音楽/映画/書籍の著作権者ならともかく、まさかソフトウェアメーカーの団体までが・・・。

例えば、会員企業のインターコム(株)のSuper ウルトラISOを持ってるけど、これが(Winnyとかで)不正に入手したDVDイメージファイルに使われないと確信しているのだろうか？
マイクロソフトにしても、「ウィニーはVC++で作りました」とか言われたら「開発環境を提供することで、違法なソフトの作成を幇助した」として連座するのか？　・・・と、聞いてみたい。

プロ市民的な法の拡大解釈自体も気持ち悪いけど、自分自身を棚に上げて他者を批難するダブルスタンダードっぷりも気持ち悪い。
(幸い、うちの会社はパッケージソフトを作ってないので、会員じゃなかった)
これで有罪になっちゃったら(実際になっちゃってたんだけど)、怖くてなんも作れねーよ。まさに、自縄自縛。

まぁこの辺の対応をしているのは、法務部門の人であって開発者じゃないんだろうけどね。
自社の開発部門に聞いてみなよ、「ウチのソフトは犯罪に利用できないよね？」って。

　法務　「ウチのソフトは犯罪に利用できないよね？」
　開発　「犯罪者はヘアピンでも鍵を開けるさ」
　法務　「なら大丈夫。うちのソフトはヘアピンよりも役に立たないから」

あ、そうなの？
それなら確かに心配無用だね。
(なんかディルバートみたいになっちゃった)

前回に引き続き、カッティングプロッタCC200-20で"とりかご"を作れるか精度実験をした。

今回は、ちゃんと MPro110 の特性に合わせて作ってみる。
まずは計測から。

ヨコから見た図。
普通のプロジェクタは、水平より若干上の方向に投影するものだが、MPro110はほぼ真正面に投影している。

上から見た図。
左右バランスもほぼ均等。
まぁ、これはふつうだが。

仕様よりも幾分短い距離でも焦点があったので、それを計測して図面にしてみた。


細かいところはかなり適当。

この数値に基づいて、Javaプログラムで糸の配置を算出した。
とはいえ、この数値のままだと１ドット 0.1875mm ピッチなので、２倍の数値で計算している。

本当は、そのまま出力ファイルにしたいのだけど、ファイルフォーマットが分からないので数字だけ出して、ポチポチ手入力した…。

残念ながら、添付ソフトは 0.1mm 単位でしか設定できないので、端数の分は適当に四捨五入した。

件のクリアフォルダーを、例によってゆっくりゆっくりカッティング。
結構時間がかかったが、紙の時のように、カスが詰まることもなかった。

透明なので見にくいけど、切り出したのがコレ。
余分な部分は引っぺがし済み。

糸の部分が びろろ～ん となってしまっている。
やばい、伸びちゃったかな？

だが、上下にテンションをかけたらまっすぐになった。
別に伸びちゃった訳ではないようだ。





ここでDXFファイルのフォーマットを解説しているので、これを参考に、Javaから直接DXFファイルを出力できるようにしたい。
そうしたら、端数の扱いや、組み立て部分の作り込まで半自動でできるしね。

あと、白い素材を買ってこないと。
意外と、色つきで、固くて、0.2～0.3mm のフィルムって無いんだよね。
0.5mmなら普通に売ってるんだけど…。
コーティング紙とかを探した方がいいのかな？

・・・って何の話かというと、ようやく出願できた特許の話。

まあ、書類上は「取り外し可能な記憶媒体を用いた冗長性のあるストレージシステム」という名前だけど、面倒なんで「しっぽ」と呼称することにした。
で、ホームページも用意した。
って、のべるやを置いてるところだけど。

で、しっぽが何かというと、リムーバブルHDDでRAID５やRAID６みたいに冗長化する技術。
まぁ、より正確にいえば、RAID4とかRAID-DPに近いんだけどね。

RAIDと違うところは、ストライピングしないので、個々のHDDは読み書きする時にしか挿さなくて良いと言う事。
データディスク単体から、データを取り出せる(書けないけど)ということ。
ディスクの数をどんどん追加してもリビルドが不要だということ。

いやー、こんなの誰か思いついていても不思議じゃないんだけど、聞かないんだよなぁ。
その割りに、応用範囲はすげー広そう。
HDDだけでなく磁気テープやDVD-Rでも使えるから、企業の大規模ライブラリから家庭用HDDレコーダーにも転用可能だ。

ダビング１０のことを考えると、特にHDDレコーダーは期待大。
しっぽを使えば、
・ダビング１０のルールを破らずに
・ダビングの権利(回数)を保持したまま
・HDDから消せる(空き容量を増やせる)
・・・というメリットがある。

”ルールを破ってない”かどうかは、専門じゃないので確証はないけど。
そこをクリアできれば、すげーホットなアイデアなんではないかと。
興味があるメーカーさん、(万が一読んでたら)是非ご連絡を。

とはいえ、そんなところは専門外なので、とりあえず自分用にPCで使うソフトウェア(Java)を開発中。

まぁ、詳しいことはホームページで・・・って、まだあんまり詳しく無いけど。
わかんねーよ、という人は、専用掲示板を用意したので、そちらにどうぞ。

のべるや 0.42 を公開

今日は日帰り出張だったので、昨日作った 0.41 を使ってダヴィンチ・コードなんぞを読んでみた。
だけど、やっぱり読みにくい。

原因は、

• 次の行の先頭が見つけにくいこと
• 背景色のせいで文字が読みにくいこと

・・・だと思う。

文字が読みにくいってのは、半透明色が使えないとどうにもならないんだけど・・・
１ドット毎に白/黒の判定をして、白の時だけ色を付ける・・・なんて手もあるが、もっさりにも程があるだろう。
なので、とりあえず色を付けるのを上端・下端だけにした。

せめて次の行が見つけられやすいように、こんな風にしてみた。

　　●●●●|●●●●
　　④③②①|④③②①
　　④③②①|④③②①
　　④③②①|④③②①
　　④③②①|④③②①
　　④③②①|④③②①
　　④③②①|④③②①
　　●●●●|●●●●　　・・・写真載せた方が楽だったな

うーん、やっぱり微妙かも。

のべるや 0.41 を公開

画面を左右に分割して読んでいるんだけど、たまに右下と左上の対応関係を間違えてしまうことがある。
同じ行をループしたり、１行跳ばしてしまったり・・・。

行のつながりが一目で分かるようにはできないだろうか

・・・ということで、色を付けてみた。

既に何本か破線を表示していたが、それに合わせて背景に 赤/青/緑 を表示するようにした。

本当は、半透明色を使いたかったんだけど、compact framework ではサポートされていないみたいだ。
RGBに加えてα値を指定できるメソッドもあるのに、実際に書いてみたら思いっきり不透明だった。

仕方なく、間隔を空けて破線を書くことで、網掛けにしてみた。
メニューから、色の濃度を指定できるが、これは単純に破線の間隔を制御している。

ちなみに、[濃い]にすると、ちょっともっさりする。
正直、微妙な感じに思えるので、バージョンも控えめに 0.01 だけUP

アドエスでは、インターネットに接続するのに EasyDial を使っているのだけど、リモートデスクトップ接続するときには VPN 接続をしなくてはいけない。

一部のソフトでは、[接続]→[詳細設定]→[例外設定]に登録したアドレスを要求すると、勝手に"プライベートネットワーク"用の接続設定で接続されるのだが・・・。

手動でVPNに接続しようとすると、
[接続アイコン？]をクリック→[接続]→[接続]→[VPN サーバーの編集]→接続先を選んで右クリック(長押し)→[接続]
面倒なことこの上ない。しかも、最後の[接続]の隣は[削除]。
うっかり押したらどうなることか・・・。
PocketPC2003くらいからずっとこうだけど・・・何とかならんのか？
デスクトップ用OSでは、毎回イヤになるほどUI変えまくるのに・・・。

で、C#でプログラムを作っちゃおう・・・と思ったんだけど、ダイヤルアップなんてOS依存にもほどがあるじゃん。
とても.netで用意してるとは思えない･･･。

ネットで探してみると、標準で含まれている rnaapp.exe を使って繋げられるようだ。
rnaapp.exe -e"接続名" -p というショートカットを作って実行してみると・・・
[切断完了]・・・接続してねーよ。
しかもBluetooth接続まで切断してくださるようで・・・余計なお世話だ。

簡単にできそうに思えたんだけど、意外と面倒くさそうだ・・・。

またまた のべるや を修正。
今回の修正内容は、以下の２点。

• メニューのショートカットキーを、アルファベットから数字に変更
• ズームアップの方法として、”画面切替”モードを追加

各メニューのショートカットに(F)だの(U)だのアルファベットを設定していたけれど、わざわざキーボードを開いて打つはずがないので、テンキーで入力できるように数字にした。

"画面切替" モードは、[Enter]キーで上半分と下半分を切り替えて表示する。

今までの画面を分割して１行全部を表示する方法を"画面分割"方式と呼ぶことに。

画面切替方式は、一覧性は悪いが、違和感は少ないと思う。
とっつきは良いんじゃないかな。
慣れてくると、従来の画面分割方式の方がいいと思うけど。

内部的には、新たな拡大方式をどんどん追加できるように、ズーム画面の描画ロジックを別クラスに移した。
なにか良い表示方式が思いついたら追加していきたい。

のべるや を修正。
今回の修正内容は、以下の3点。

• 画像のキャッシュ(先読み)
• 履歴管理の修正
• バージョン情報メニューの追加

画像キャッシュ機能は、現在のページの前後1ページずつを先読みするようにした。
ページ切り替え時の表示が若干速くなった（ような気がする）

履歴関係は、いい加減に作ってあったので根本的に作り直した。
まず、履歴情報を１つのファイルにまとめて最大50件まで保存されるようにした。
（メニューから選べるのは3件のままだけど）
旧形式の履歴ファイルが既にある場合は、自動的に変換する。
また、[ファイルを開く]メニューから履歴に残っているファイルを開くと、最後に開いていたページが開くようにした。

最後のバージョン情報メニューは、文字通りの機能。
今更ですが。

ついでに、.Net Compact Framework のバージョンを 3.5 → 2.0 に変更しようかと思ったのだけど、画像処理周りの変更が大変そうだったのでやっぱりやめた。

ところで、前回修正した Xcrowl 対応だけど・・・くるくるスクロールが意外といい感じ。
最初は違和感があったけど、１冊読破するうちに慣れてしまった。

のべるや ver 0.21 を作って、マニュアルを書き直した。
修正内容は、十字キーの処理の修正。
メニューにXcrowl対応という項目を用意し、それが選択された時のホットキーの配置を変更した。
まぁ、詳しくはマニュアルをどーぞ。

なんで修正したのかと言うと・・・

ここ数日で、いきなりブログのアクセス数が増えた。
まぁ、それでも大したことないんだけど、原因は のべるや くらいしか思い当たらない。
のべるやの公開ページの方は、累計で70件くらい。
でも、のべるや以外に何もないページだから、そのうち10人や20人くらいはダウンロードしたのかも。
それで、せめて十字キー周りの不具合だけはと、あわてて修正した訳だが・・・

まずは原因を調査しようと、デバッグモードで監視しながら十字キーを操作してみたが、解決の糸口がなかなか掴めない。
[←]を1回押したつもりが、身の覚えの無い余分なキーイベントが２、３回起きたりする。
それどころか、キーを押していないのにキーイベントが発生することも・・・。
どーゆーことやねん！

・・・と、数時間悩んだところでふいに思い出した。
そーいえば あどえす の十字キーって、指でクルクルなぞるとスクロールするんだっけ？

もしやと思って、設定 を覗いてみたら・・・スクロールが有効になってた。
使ってないから忘れてたよ。

デバッグモードで監視してみたら、スクロールでキーイベントが発生してる。
しかも ↑ キーとか ↓ キーとか。PageDownとかじゃないのね・・・。

念のため、スクロールを無効にして操作してみたところ、全く問題なかった。
つーことで、意図しないページ移動が発生するのはソフトウェアの不具合ではなかった。
なんだ、じゃあスクロールを無効にしておこう。
めでたし、めでたし。

･･･という訳にはいかんわな。

そんな訳で、苦肉の策として、Xcrowl対応モードを用意した次第。
Xcrowl対応モードでは、上下キーの役割と左右キーの役割を逆転させる。
　左右キー　：　ページ移動
　上下キー　：　ズーム画面の表示部分の移動

"上下キー"で"左右に"移動する・・・ うぅ、気持ち悪い。

でも、"うっかり" スクロールしてしまっても、ちょっと画面が左右に移動するだけ。
読むのに合わせてクルクルすれば、操作性も（そんなに）悪くない（かも）。
まぁ、俺自身は気持ち悪くても十字キーを押すけど。

のべるやを更新した。ver 0.20

• 過去３冊まで履歴を残すようにした
• 余白設定を３パターン登録できるようにした（ホットキーで切り替え）
• 画像以外のファイルが混じっているzipに対応

あと、それに合わせてホームページも更新。
マニュアルっぽいものも追加した。
まぁ、誰もDLした形跡がないし、要らないだろうけど。

今後の予定

• 表示順の変更（zipのエントリ順 -> 名前順）
• キーイベントの処理の修正(想定外のページ送りが発生してしまう)
• IMEを半角数字に(その他だとホットキーが効かないので・・・)
• （ZIPではなく）フォルダ指定に対応
• Webサーバー上のファイルに対応
• 横書き文書への対応
• (分割ではなく) 切り替え表示

しかし、.Net Compact Framework はやっかいやね。
IMEを制御するくらいのこともおいそれとできねー。
コード書いてる時間より、調べ物してる時間の方が長いよ。
MSDNで調べると、Compact Framework で使えない情報がわんさか引っかかるし。
Javaで書いた方が楽だったかなぁ。

とりあえず、ノベルビューアを余白設定と最後に開いていたファイルを保存するように修正した。

で、公開しようと思って、名前とアイコンを決定した。

　のべるや　（Novelujah）

で、ココログ内に置こうと思ったんだけど・・・置けない？
Vectorに置くほど真面目にサポートする気も無いし・・・

で、形ばかりのホームページを作成して、ファイルを置いた。
ほんと、形ばかり・・・。

要望とか文句とかは・・・ブログの方にコメントしてください。

アドエスで小説を読むためのソフトをC#で作ってみた。
といっても、青空文庫のテキストデータや、.bookみたいな電子ブック形式でもなく、画像(jpeg)を見るためのもの。

ようするに、実際の文庫を裁断して、ScanSnapなどのドキュメントスキャナで読み込んで出来たデータを読むためのもの。

所詮画像でしかないわけで、当然マンガミーヤCEなどのマンガビューアでも見れる訳だけど、アドエスの画面ではとても読めない。
800x480と、解像度は一人前なんだけど、実際のサイズは 65x40mm ほど。
文庫本の1/4以下だ。

なので、まずは上下左右の余白をカットしてみた。
余白のサイズを設定して・・・
(1)余白設定画面

(2)ズーム画面[１分割]

・・・あんまり変わらんなぁ。

仕方ないので、ズームアップ。
(3)ズーム画面[2分割]

1行を一気に表示できないので、画面を左右に分割して表示している。
この画面だと、『その高田へ水を汲み上げ、先祖代々、泥の面をはいまわって、わずかばかりの米をつくってきた。』と読む。
つなぎ目の”面を”の部分はバッファとして両方に表示している。

操作は、十字キーの左右で画面がスクロールし、上下で前後のページに移動する。
Enterキーで ズーム画面 <-> 余白設定画面 の切り替えをする。

とりあえず試しに、水曜の日帰り出張で使ってみた。
本は司馬遼太郎の箱根の坂(上)。以前読んだ本だけど。

最初は、目線が右にいったり左に行ったりして戸惑ったのだけど、50ページも読むと次第に慣れてきた。
一方で、十字キーの操作性が悪いことが判明。
左を押したつもりが、微妙に下を押してしまって、ページが変わる・・・なんてことが多発。
キーイベントの処理に細工が要りそうだ。

あとは、一気に読んだあとで思ったのだけど、設定の保存が要る。
少なくとも、アプリを終了したときに、どのファイルを何ページまで読んでたのか覚えていないと不便だ。

そのあたりを修正できたら、どこかで公開しようかな。