桃缶食べたい。

Maven Resources Plugin の Filtering 機能を使ってみる

Eclipse プロジェクトの再読み込みなしでリソースを更新する

chocolablog ver 0.7 にアップデートしました

Bitbucket プロジェクト用アイコン作ったよー

Python nose でユニットテストを書いてみた

Dynabook KIRA V634 を買ったので Fedora 20 をインストールしてみた

友人とハッカ村的な場を作ってアクションゲーム制作に挑戦しました

svn リポジトリをローカルにコピーしてから git リポジトリに変換する

Pushy Grandma ver 0.3 を公開しました

Git 実行時にブランチとユーザー情報を表示してみる

ダウンロード

Eclipse Project Loader

画面解像度が高い

薄い、軽い

メモリ 8 GB

ストレージは SSD のみ

Haswell 搭載

液晶パネルはノングレアではない

assembla の svn リポジトリに git svn clone するとエラーで落ちる

Maven Resources Plugin は必要なタイミングで、リソースファイルを特定のディレクトリにコピーする機能です。
Maven プロジェクトではコンパイルされたクラスは target/classes に配置され、実行時には target/classes に classpath を通せばよいように設計されています。（jar や war にパッケージされるのも targaet/classes 配下のファイルになります。）つまりコンパイルが走るタイミングで src/main/resources ディレクトリ下のリソースも classpath の通る target/classes に配置してやる必要があり、その役割を担うのが Maven Resources Plugin なのです。

Maven Resources Plugin には Filtering と呼ばれる機能があります。これにより、リソースファイルをコピーする際に、リソースファイル内の文字列を動的に書き換えた上でコピーすることができます。
続きを読む Maven コメント (0) 2014/12/31 11:37:58

Eclipse 外で HTML ファイルや prpperties ファイルなどを修正した場合、Eclipse プロジェクトを都度再読み込み（更新）し、修正したリソースファイルを Eclipse に認識させてやる必要があります。WEB アプリ開発などでは頻繁に HTML ファイルやテンプレートファイルを修正するため、その都度 Tomcat を止めて Eclipse プロジェクトを更新する、というのは非常に非効率です。Java クラスについては、メソッドやクラスの定義が変わらない限り Servlet コンテナを止める必要はないのですが、リソースファイルの修正にはまだまだ弱いのが現状です。

リソースファイル変更時に Eclipse プロジェクトの更新が必要になるのは、Eclipse プロジェクトのレイアウトとして、リソースファイルが配置されるディレクトリと実行/デバック時に Eclipse がクラスパスを通すディレクトリが異なるためです。例えば Maven プロジェクトでは、リソースが配置されるのは src/main/resources ですが、Eclipse がクラスパスを通してくれるのは target/classes になります。Eclipse は Eclipse プロジェクトの更新時などにリソースファイルを src/main/resources 下から target/classes 下にコピーし直すのですが、逆にいうと、いくら src/main/resources 下のリソースファイルを書き換えても、target/classes 下にコピーされない限り（クラスパスの通ったリソースファイルは古いままなので）プログラムはリソースとして読み込むことができません。
target/classes 下のリソースファイルを修正すれば一応クラスパス上のリソースを変更することはできますが、次にリソースディレクトリからリソースファイルがコピーされた時に上書きされて巻き戻ってしまいます。

これを解決するため、読み込むリソースファイルの場所を任意のディレクトリに切り替える仕組みを作ってみました。

https://github.com/momokan/eclipse-project-loader (github)

Eclipse Project Loader　を使うことで、クラスパス内のリソースファイルをクラスパスの通っていない別のディレクトリから読み込むことができるようになります。そのため、プログラムがリソースファイルを読みにいくたびに、最新のリソースファイルにアクセスすることができるようになります。

続きを読む Eclipse Class Loader コメント (0) 2014/11/29 19:41:00

Python 製自作ブログの chocolablog を ver 0.7 にアップデートしました。

前回アップデートが 2013 年 5 月 2 日ということで、今回も 1 年以上の間を置いてのバージョンアップとなります。ver 0.6 ではシステム管理側でいろいろ機能を追加していきましたが、ver 0.7 では新機能の追加はほとんどなく、細かな機能拡張と不具合修正のみになります。

ver 0.6 で実装したスパムコメントのフィルタリング機能は、1 年半くらい運用してみてまずまずの成果をあげているようです。フィルタリング機能は 2 段構えなのですが、第 1 障壁を超えてきたコメントスパムが 2 件だけでした。その 2 件も察するに、スパマーさんが試しに普通にコメントしたんじゃないかという感じの内容だったので、第 1 障壁の役目としては問題ない範囲になります。

スパムコメント対策に限らず、システムとしてはだいぶ成熟してきた感が強くなってきているので、今後もこんなペースでの開発が進んでいくことになるんじゃないかと思っています。当面は大きめの機能追加の予定はありません。（単にネタ切れとも言う）

続きを読む chocolablog 開発コメント (0) 2014/11/03 15:24:13

あのバケツ見てるといつもこれを思い浮かべます。

続きを読むコメント (0) 2014/06/22 18:58:28

chocolablog は Python で書かれていますが、これまであまりユニットテストの整備に時間を割いてこれませんでした。しかし初期バージョンの開発から 2 年以上が経ち、その間に何度か sqlite3 をとりまく DB アクセス部分を中心に、処理を書き換えています。他のロジックはともかく、コアとなるコードはしっかり動作を担保しておくべきだなと感じ、ユニットテストの整備に着手することにしました。

Python では 2.1 移行、ユニットテストフレームワークとして unittest が組み込まれています。これは個人的に大好きな JUnit をベースに作られているそうです。ただネット上で目にした Python 系のオープンソースプロジェクトでは、この uniittest モジュールではなく nose というモジュールを使ってテストコードが書かれていました。nose を使うとテスト失敗時にデバッグツールの pdb を自動で起動してステップ実行ができたり、ソースコードのカバレッジレポートを出力できたりと、テストの書き方以外の面でもいくつかメリットがあります。
今回は unittest よりさらに簡単にユニットテストを書けるらしい nose を使い、ユニットテストを書いてみました。

続きを読む python コメント (0) 2014/05/29 08:02:50

薄くて軽くて高性能なノート PC が欲しくなって、Dynabook V634/W7K を買ってみました。Intel 第四世代 CPU はまだ買ったことがなかったので、これが Haswell 初体験です。

今まで MacBook Air を使っていたので、PC 選びの基準は MacBook Air でした。MacBook Air はコストパフォーマンスを含めてすばらしいマシンだと思いますが、画面解像度の高さが 900 ピクセルしかないことと、Fedora 20 で英数・かなキーを認識してくれないのが数少ない残念ポイントでした。それでなんとなくネットを見ていたらこのマシンが目に入り、衝動買いしてしまいました。
やったね！これからはお出掛け前の気分で MacBook Air と Dynabook V634 を選べるね！

Dynabook はハードウェアデザインもかなり MacBook Air を意識して作られたようです。キーボードの感じなんかは特に MacBook Air を追いかけてる感じがしてます。

Dynabook V634 は、私が見かけた PC の中では私のマシン選びの条件を一番多くクリアしていました。

画面の物理サイズは、Dynabook V634 の高さは MacBook Air よりひとまわり小さいです。
画面解像度が 2560　x 1440 なので、UI が随分小さく細かくなったように感じます。
だがそれがいい。これだけ解像度があるとタイトルバーがやたら太い GNOME3 を使う上でとても安心です。

外出時の持ち運び用途なので重要。MacBook Air が重く感じてきたのでそれより重いのは NG。
MacBookAir が 1.35 kg、Dynabook V634 が　1.12kg　なので若干軽いらしいです。持ってみた実感として軽くなった印象は…少し軽くなってる？？

開発で DB やら eclipse やらいろいろ動かすので積めるだけ積みたい派です。
Dynabook V634　は　8GB （おそらく DDR3）なので、悪くはないレベル。次のモデルではぜひぜひ 16 GB とか検討して頂けると泣いて喜びます。

MacBook Air の高速環境に飼いならされた身としては SSD もはずせないポイント。
けれど容量にはそれほど要求はなく、120 GB あれば十分でした。Dynabook V634　の SSD は 256GB なのでかなり潤沢です。
最近のメーカー品だと HDD とのハイブリッド構成なんかもあるそうですが、ディスクは音や重さを考えると返ってないほうがいいのかなと思います。

CPU も最高クラスが欲しいわけではありませんでしたが、電源消費が改善されたと噂の Haswell であることは条件でした。Dynabook V634 は Intel Core i7-4500U です。
Dynabook V634 はバッテリーの持続時間が長いことでネット上では大きく扱われているようですが、この辺は Haswell の功績が大きいのではないでしょうか。ちなみに、私の買った V634/W7K の駆動時間は 14 時間です。同じ大きさで画面解像度がひとまわり小さい V634/W6K は 22 時間連続稼動するそうです。

公式サイトには SuperView LED液晶とあります。パネルの種類はあまり詳しくないのですが、ノングレアではないです。
照明が綺麗に写りこみます。人によってはすごく気になるポイントだと思います。
他のスペックが満足できるレベルだったので、この点は妥協しました。開発用途として使うつもりなので画質にはそれほどこだわらないので、気になるようならアンチグレアシートなど検討してみようと思います。

ということで、Dynabook V634 は軽い・早い・画面が広いという私の中の条件を納得できるところで達成していました。

ただしお値段は日本メーカー製だけあってだいぶ高いです。
ハードウェアスペックやマシン自体の作りを比較すると MacBook Air の品質の高さを再認識させられます。あの値段であのスペックとなれば、OS うんぬんの話は抜きにしても、人気が出ないはずはないです。この辺はもう少し日本のメーカーにも考えて欲しいところ。
続きを読む Linux, お買い物コメント (0) 2014/05/25 19:49:45

ここ最近休日を有効活用しきれてないなーと感じていたので、先週の土曜日に、友人と集まってそれぞれ自分の作業をするハッカソン的イベントを開いてみました。お題は特になく、自分で決めた目標にむかって刺激し合いつつも、もくもくと作業していこうぜ、という主旨です。ハッカソンならぬハッカ村です。

友人達は iPhone 用ゲーム作りを進めたり、ドールのメイク（？）をしたり、南方海域へ出撃したり、まどマギ叛逆を見たりとそれぞれ個性あふれるテーマを選んでいました。私は気分転換をかねてアクションゲーム的なものを作ってみました。RPG には幾度となく挑戦しては敗れたり破れなかったりしていますが、アクションゲーム制作は（おそらく）はじめてで楽しかったです。

できあがったのがこちら。
グラフィックを用意する時間があまり取れなかったので、適当に描いても味があるように見せかけられる和風テイストにしています。かなり昔に見つけてブックマークしていたいい感じの水墨画ブラシがここで役に立ちました。

製作期間は、キャラクターや背景などの画像素材の用意も含めて 1 日に区切っていました。ハッカ村はお昼頃集合で開始だったので、午前中に家で必要になりそうな画像はひととおり準備しています。プレイヤー画像 4 点、敵画像 1 点、背景画像 1 点、ライフゲージ 1 点をだいたい 3 時間強で描いています。

最終的なゲームの仕上がりとしては、果たしてゲームに成立しているかと言われるとかなり微妙なレベルなのですが、これまでのゲーム開発での蓄積もあって、それなりの速度感で作っていけたんじゃないかと思います。ゲームのメインロジック、テクスチャー合成、キーボード入力処理、キャラクターのアクションの扱いなんかは別で作っているゲームのエンジン部分をそのまま利用しています。ちょっと斬撃エフェクトの演出効果を変えたいという場面で、テクスチャーのパラメーターを 1 つ変えるだけで加算合成や乗算合成に切り替えられたりというのは、開発環境としてはなかなか使い心地が良かったです。

続きを読むゲーム製作, 雑記コメント (0) 2014/05/22 08:52:14

今年になって、個人的なコードを書き溜めていた svn リポジトリを徐々に git に移行しています。

私はフリープランでもプライベートリポジトリを無制限に作れることから、数年前から assembla を使っていました。しかし最近（？？）になってフリープランで作れるリポジトリ数に上限が設定されたようで、新しいリポジトリが作れなくなっていました。有料プランへ乗り換えられればよかったのですが、リポジトリ数をふまえて開発予算（お小遣い）と相談した結果、やむなくお世話になった assembla から bitbucket に移住することにしました。念のため強調しておきますが、これまでながらく愛用していたことからもわかるとおり、assembla 自体に不満があるわけではありません。あくまでやんごとなき事情（お小遣い）のため、泣く泣くの別れとなります（涙）。

移住先として選んだ bitbucket はリポジトリ数の上限こそないものの、コミッターの総数が 5 人までに制限されています。私は他人に見せられるコードは別途 github に置いているので、プライベートリポジトリについてはこの制限はまったく考慮しなくてよいものでした。

assembla から git への引越し作業にはすこし面倒でした。
ネットの各所に資料があるとおり、svn リポジトリを git リポジトリに変換するには git svn clone を使えばいいのですが、assembla 上の svn リポジトリにこのコマンドを使うと以下のようなエラーが発生し、変換処理が異常終了してしまいました。

...
r372 = 4b5404a5643c5d3refref081c06c3acaa2e8eeb (refs/remotes/trunk)
Checked out HEAD:
  https://subversion.assembla.com/svn/momokan/myrepo01/trunk r372
error closing pipe: 不正なファイル記述子です at /usr/libexec/git-core/git-svn line 0.
error closing pipe: 不正なファイル記述子です at /usr/libexec/git-core/git-svn line 0.

詳細がよくわかないのですが、時間を置いて再度実行してもここで落ちてしまうため、別の手段で移行を進める必要がありました。

続きを読む Linux コメント (0) 2014/05/13 22:15:33

一度中毒症状から抜け出しても、ふとしたきっかけで再びクッキーを焼きたくて焼きたくて仕方なくなってしまうという恐怖のクリックゲーム Cookie Clicker にて、せめてプレイヤーの身体だけは守ろうというコンセプト（嘘）で去年公開した Pushy Grandma をバージョンアップしました。
Pushy Grandma は Cookkie Clicker のクッキーを自動でクリックし続ける Grease monkey スクリプトです。

今回のアップデートでは通常のノーマルクッキー、ゴールデンクッキーに加えてクリスマスのトナカイが自動クリックされるようになりました。
おばあちゃんがトナカイを屠るようになりますので、ぜひぜひご利用の方はアップデートしてみてください。

Greasemonkey 用 Cookie Clicker 自動クリックスクリプト
Pushy Grandma ver 0.3

インストール手順は前回と同様になります。
そのまま ver 0.3 のリンクを開いてもらえればバージョンアップできるかと思いますが、もしうまくインストールできないようでしたら、一度 Pushy Grandma を削除してから再度インストールしてみてください。

続きを読む WEB 技術コメント (7) 2014/04/26 13:55:39

<<2018, 7>>

最近になって、私が関係しているプロジェクトもだいたい Suvbersuin から Git に移行してきました。Git 自体は便利ですし、おもしろい機能もいっぱい詰まったとても魅力的なツールなのですが、Git を使う上ではいくつか気をつけなければならない点があります。

1 つは、自分が今どのローカルブランチにいるかを意識しなければならないことです。
Git では複数のブランチを切り替えて渡り歩くということが頻繁にあります。develop ブランチで開発していたけれど、少し大きめの実装をしなければならなくなると専用の別ブランチを切ってみたり、そこで日をまたぐと翌日には develop にいるものと思い込んで別ブランチで develop のコミットをしてしまったり、という失敗をたまにやってしまうのです。
もちろん、まず git branch を実行して確かめる習慣をもつことが重要ですが、いちいち git branch をタイプするのが何気に面倒なのです。

もう 1 つ、Git でコミットをする際のユーザー名とメールアドレスの設定忘れです。
Git でコミットするとコミットログに自動で user.name と user.email が追記されますが、これはリモートリポジトリからソースコードを取ってきた後自分で設定しなければなりません。git config に --global オプションを設定すれば設定値を共有できるそうですが、私は違うアカウントでいくつものリポジトリを自分のマシンに置いておくことが多く、それぞれのリポジトリで正しい名前でコミットされているかをいつも気にかけています。

ということで、より快適な Git ライフを手に入れるべく、git コマンド実行時にブランチ名やユーザー情報を表示するシェルスクリプトを書いてみました。

続きを読む Linux コメント (0) 2014/03/06 00:01:52