« 2011年8月 | トップページ | 2011年10月 »
いんきゅばすver2.0.0をリリースしました(内部的な表記はベータバージョン(2.b.0)になっていますが)。久しぶりにLinux版も更新し、機能的にはWIN版/Linux版で同期が取れています。
変更点は前回記載した通りなので記述が重複するのですが、ver.1.7.xからの主な変更点は以下の通りです。
動作環境はver1.xと異なり、Java7が必須になります(ver1.xはJava6です)。
今後、ver1.xはバグフィックスのみとし、新しい機能はこのver2.xに追加していくことになると思います。次バージョンのcoroid-serverもこのver2.xをベースにすることになると考えます。
自分の作成しているプロダクト、作成時期によって使用しているloggingライブラリがバラバラなので、そろそろ統一したいなあ、と考えていたところ、SLF4J Migratorなるものがあることに気付きました。
早速使用してみたのですが、変換対象の.javaファイルの文字コード、改行コードともシステムデフォルトであるとみなして処理するため、Windows上でUTF-8/LFなファイルを対象に実行すると悲惨な結果になってしまいました。
file.encodingとline.separatorを指定してやればよいのですが、file.encodingについては-Dfile.encoding=”UTF-8”で良いもののの、コマンドラインでline.separatorを指定する方法が分かりませんでした。bashでは下記リンク先のようにできるそうですが…
そんなわけで、GUIでエンコーディングと改行コードを指定できるように変更した.jarを作成しました。ダウンロードは以下のリンクから。
ソースは以下になります。
…ところでMacの改行コードって今も\rなんですかね…？
久しぶりにffmpeg/avconvのビルドを行ってみました。時間がかかったのでちゃんと動くのか試すのはまた後日ですが…
ビルドに当たってはこちらのサイト(2011.09.07更新)を参考にさせて頂きました。
少しハマったところがあったのでメモしておきます。(ちなみに私はlinux向けビルドなので、完全に同じ手順ではないです。)
1点目。libvpxのダウンロード先ですが、
双方つながりませんでした…前者は公式のリポジトリなのですが最近ずっと不安定らしく、http://code.google.com/p/webm/downloads/list から落としてきました。
参考:
2点目。openjpeg_v1_4_sources_r697.tgzをビルドしようとすると、
‘Z_BEST_COMPRESSION’ undeclared (first use in this function)
というようなエラーで失敗してしまいました。これはSVNリポジトリから最新バージョンのコードをとってきて対処しました。しかしlibtiffを認識してくれず、ちゃんとはビルドできず仕舞いです…(libtiffもtiff-3.9.5.tar.gzから4のβではpkg_configを使うようになっていたり、変更点があるようです)
参考:
3点目。libschroedinger-1.0のインクルードファイルが、冒頭リンク先では $INC/schroedinger にインストールされる想定ですが、私が同手順でインストールしたところ $INC/libschroedinger-1.0/schroedinger になっていました。これは一時的にシンボリックリンクを張って対応しました。
いんきゅばす派生元(つまり本家)であるさきゅばすもついに更新再開されたようです。元々にちゃんねるの該当スレッドでニコニコ動画サービスの現行仕様への対応を行われていた方がプロジェクトに参画された、という理解で良いんでしょうかね？
また、現行仕様への対応だけではなく、従来のバージョンに対して新しい機能も追加されているようです(以前記載したcookie共有の件も時期的に考えてさきゅばすといんきゅばす両方使用してらっしゃる方からでしょうか)。いんきゅばすはさきゅばすの上位互換です、というように書いて来ましたが、この文言消しておかないといけないですね…
さて、いんきゅばすの話です。
やろうやろうと考えていて中々できなかったこと全2個中の2個目もやっと目処がついてきました。目標としては
の実現、ということになります。
処理の並行化やコマンドラインからの実行機能の充実を考えたとき、現行のものではGUIの部分とタスクの部分の結びつきが強すぎて変更を加えるのが大変、というのが1点目で解消したい事です。
2点目は、ちょっと建て増ししすぎてインタフェースがわかりづらくなってしまった部分をどうにかしたいのと、不要な機能はこの機会に削ってスリム化してしまおうというのが魂胆です。スリム化については貧乏性が災いして、まだ全然うまくいっているようには感じられませんが…
いんきゅばすver1.xに対する使用者からみた主なメリットは以下のようになります。
機能についての詳細説明は、正式版リリースの際にまた行いたいと思います。
ちなみに画面はこんな感じです。(クリックで拡大)
一応動作するファイルもありますが、実行する場合は以下の点に注意してください。
今の時点ではこれ以上の実行準備に関する説明はご容赦を。
java.comからはまだJava7は入手できないようです。ここから入手できるようになるくらいにはver2.0.0リリースしたいですね。
そもそもコンポーネントのサイズが何やら大きいぞ？と使いはじめから思っていたのですが、そのときはNimbusってそんなものなのかな…と考えていました。表題の件もJavadocを見ると
進捗文字列をサポートしない、または進捗バーが不確定モードのときだけサポートする Look & Feel もあります。
なんてことが書いてあったので、仕様なのかも、と考えていました。
が、コマンドプロンプトから起動してみたところ、大きさもネイティブのLAFと同じだし、プログレスバーに文字もちゃんと表示されていました。なんでだろ？とNetBeansが使用しているAntのbuild.xmlでrunの部分を見てみたところ、-Dfile.encoding=UTF-8が設定されており、もしやこれが？とおもって検索してみたところ、やはりそうでした。
file.encoding設定値がフォント構成ファイルの情報読み込みに影響を与えるようです。
NetBeans7.0.1とEclipse3.8m1で試してみましたが、ファイルの文字コードをUTF-8に設定すると、双方のIDEで実行時にfile.encodingもUTF-8に設定されてしまうようです。
ユーザ(私)がUTF-8を設定したのはコンパイル前のjavaソースをUTF-8で書きたいからであって、実行時にどうこうしたいからじゃないんですけど、なんで両方のIDEともこんな仕様になってるんでしょうかね。あとfile.encodingって結局何がしたいための定義なのかもよく理解できません(昔からのバグが多く残っているようですし)…
結論から言うと使い方が間違ってたわけなんですけれど。
Java7で導入されたjava.nio.file.Pathのregisterメソッドを使用する事でファイル更新を監視できるようになりました。
webで検索してみると、大体変更のあったファイル名を出力するようなサンプルがヒットします。こんな感じのプログラムでしょうか。
1: WatchService watchService = FileSystems.getDefault().newWatchService();
2: Path dir = ...;
3: dir.register(watchService,
4: StandardWatchEventKinds.ENTRY_CREATE,
5: StandardWatchEventKinds.ENTRY_MODIFY,
6: StandardWatchEventKinds.ENTRY_DELETE);
7: while (true) {
8: WatchKey key = watchService.take();
9: for (WatchEvent<?> watchEvent : key.pollEvents()) {
10: WatchEvent<Path> ev = (WatchEvent<Path>) watchEvent;
11: Path file = ev.context();
12: System.out.println(file);
13: }
14: }
ディレクトリdirのファイルが追加/更新/削除した場合に、その変更があったファイルのファイル名を出力しています。
このプログラムを見て、fileっていうのは変更がファイルを示すものなんだろうな、と思い込んでプログラムを組んだのですが、得られたfileを操作しようとしてもファイルが無いと、言われてしまいます(もちろん削除以外の操作で、です)。
これは何かおかしいぞ、と思いPath#toAbsolutePath()でフルパスを得て出力してみたところ、パスが確かにおかしい。
さらに検索してみたところ、OracleのThe Java Tutorialsページにそのまんまの解説がありました。
上記のコード中のfileは、ファイル名のみの情報を持つ(パスの情報は持たない)ため、パスを含めた正しいファイル情報を得たいのであればresolveメソッドで監視対象としたディレクトリのパスを加えてあげないといけないようです。
Christain Bauer: HIBERNATE イン アクション
理論と実践が双方とも素晴らしい製品であるHibernate。本書はそのプロダクトを書名に冠していますが、Hibernateを使うつもりがなく、ORマッピングの解説書として読むにしても十分な良書です。Second EditionとしてJava Persistence With Hibernateという書籍も出版されていますが、残念ながら現在のところ
和訳はされていません。-インアクションは2.xの、Java Persistence-は3.1の頃のものなので、最新版とはちょっと違うところもあることに注意。 (★★★★★)
アンドリュー・S・タネンバウム: 分散システム 原理とパラダイム 第2版
クライアント/サーバシステムを構築する上で必要となる知識が総論されてます。Web技術者も、フレームワーク部分を開発するのであれば必読。 (★★★★★)
Ｊｏｅｌ Ｓｐｏｌｓｋｙ∥著: ジョエル・オン・ソフトウェア
前述の書籍「ソフトウエア開発プロフェッショナル」をより砕いたもの、という感じでしょうか。
前書きではプログラマでなくSE向けの本のように書かれているが、プログラマが読んでも面白い本であると思われます。
SEになった新人（あるいはそういう会社に入る/入りたての人）にとっては、これからどういったことが仕事を遂行していく上で起こりえるのか、どのように考えて行なっていけばいいのか決定する助けになると思います。
元は″Joel on Software″というブログの記事で、web上でも一部日本語で読めます。
http://japanese.joelonsoftware.com/
(★★★)
ドナルド・Ｃ・ゴース,ジェラルド・Ｍ・ワインバーグ: ライト、ついてますか
問題解決（一昔前のの流行語で言うところの『ソリューション』）能力は、システムエンジニアのスキルとして備えるべきもののうちのひとつです。しかし、これは難しい。学校で出されるテストと違い、唯一の、（問題提出者が想定している）解を求めるだけが「問題解決」では無いからです。そもそも、何が問題なのか、それは本当に問題なのか、それは本当に解決すべき問題なのか、その問題解決方法は正しいのか、などを解決しなければ、「その解は正しいのか」に辿りつくことができません。この本の最も良いところのひとつは、本があまり厚くないこと。すぐに読めるし、何回も読み返す気になるでしょう。 (★★★★★)
スティーブ・マコネル: ソフトウエア開発プロフェッショナル
コードコンプリートで有名なスティーブマコネルの著書。新人ＳＥに読んで欲しい。個人として業界の中でどうあるべきか、組織としてどうあるべきか、ＳＥのプロ意識とは？ＳＥの心構え概論、といったところでしょうか。また、業界における資格の重要性についても説かれています。この業界では資格が特に軽んじられる傾向がありますが、この傾向はどんな弊害をもたらすのか、将来的にこの業界は資格に対してどのような姿勢で臨んでいくべきなのか。日経ＢＰ社では（他の出版社もだが）最近、似たような類いのあまり面白くない書籍が乱出版されていますが、この本は別格だと思うので安心して購入して欲しいと思います。 (★★★★★)
最近のコメント