2014-04-08

はじめて学会の研究発表会の幹事として動いたので振り返っておく

イベント

学会の研究発表会としては恐らく最も小規模なものなのでblogとして残しておくのもアレな気がしたけど、他の研究会の実施や勉強会の主催に通じる点もあるかもしれないので振り返っておく。幾分、次回へのメモも含まれます。

立ち位置としては、学会の実行委員会から情報を得て、事前準備〜当日〜後始末までの進行を行う幹事（計1名）。

2014-01-21

Instant Apache Wicket 6 を読んでみた

wicket

Apache Wicket 関係の本として Instant Apache Wicket 6 というのが発売されていたので、kindle版を購入して読んでみました。amazonでは、なぜかkindle版とペーパーブック版が別々に登録されているのですが... （洋書だから？）

タイトルも "Instant" ですし、すでに Amazon のレビューでも "This was way too short" って書かれてたりもするのですが、50ページぐらいのハンドブック的な内容です。

ユーザ認証をさくっと作って見ようよ、という題材を通じて、ページ、コンポーネント、モデル、リクエストの処理、いくつかのWicket用の(X)HTMLタグをサンプルコードで解説しています。

初心者がApache Wicketってこういうものなのかなーという概要を知るには、ちょうどいいサイズなのかもしれません。でもWicketユーザとしてはどうしても物足りなさを感じちゃう :-}

そんな本でした。

Instant Apache Wicket 6

作者: Felipe Fedel Pinto,Joao Savio Ceregatti Longo
出版社/メーカー: Packt Publishing
発売日: 2013/08/26
メディア: Kindle版
この商品を含むブログを見る

Instant Apache Wicket 6

作者: Jo o Sávio Ceregatti Longo,Felipe Fedel Pinto
出版社/メーカー: Packt Publishing
発売日: 2013/08/26
メディア: ペーパーバック
この商品を含むブログを見る

2013-08-02

ニセコ開発キャンプに参加しました

イベント

ブログを上げるのがすっかり遅くなってしまいましたが、先月の連休に @shuji_w6e さん主催のニセコ開発キャンプに参加してきました。
天気が良くてサイコーでした。

1日目

移動ルートはこんな感じでした。

大きな地図で見る

新千歳空港

@irof さん、 @grimrose さん、 @Posaune さんと合流するために、新千歳空港へ。
連休前日でしたが、一般車レーンは出迎えの車がみっしりと飽和状態で、警察が出動する事態に。

何はともあれ、@shuji_w6e さんのJunit本を目印に、無事お三方と合流し、第一チェックポイントの余市を目指しました。
f:id:gishi_yama:20130712152956j:plain

小樽

f:id:gishi_yama:20130712120828j:plain
小樽運河プラザでトイレ休憩。北海道らしい初夏で、風はあるけどもすこし汗ばむ陽気で暑いなあと思っていたら、本州のお三方からはもれなく「寒い」とのご感想をいただき、あちらの夏の修羅っぷりを感じました。

f:id:gishi_yama:20130712120943j:plain
運河プラザで売られていた「うにラムネ」。残念ながらウニ由来成分が入っていたかは分からずじまい。

余市

車窓から海なども眺めながら余市まで車を走らせ、先に着いていた @shuji_w6e さん、＠megascus さんと合流です。
お昼ご飯は有名な柿崎商店の海鮮丼へ。道民でありながら、初めて柿崎商店を利用しました。今回はやりませんでしたが、1階で買った蟹とかを持ち込んで、蟹パーティ状態にもできるのですね。

f:id:gishi_yama:20130712131606j:plain
いとこ丼。「サーモン」と「いくら」の組み合わせだから「親子」ではなく「いとこ」なのではないか説。

昼食後は散歩がてらニッカウィスキー工場見学…のはずが、実態はおつまみ片手に試飲コーナーでまったり。
f:id:gishi_yama:20130712135848j:plain
私はドライバーで飲めなかったので、売店で夜のBBQに向けてウィスキー缶の水割りを確保（お手頃価格でいいですねコレ）。それと、試飲した皆さんの評判が良かったりんごワイン、コーヒー豆入りチョコレートを妻へのお土産として購入しました。

ニセコ着、そしてクロスバイクサイクリングとBBQへ

その後、ちょうど美味しそうな実がなってた道路脇のさくらんぼ並木に後ろ髪を引かれながら、開発キャンプ会場こと、ニセコへ。

ニセコ到着後、まずは開発前の軽いアクティビティ（だと思っていた）クロスバイクサイクリングへ。
f:id:gishi_yama:20130712153004j:plain

正直、20数キロという距離だけで甘く見ていました......。
迫り来る高低差に開始直後から足腰膝が悲鳴をあげ、後半は朦朧とした意識の中で無心でペダルをただただ漕いでました......。
最後尾で10分も到着が遅れてしまい、申し訳なかったです。

道を間違って倶知安市街地まで行ってしまった＠megascus さんのオーバーラン！ネタで盛り上がった後、私の車も宿泊先のロッジへの道が分からずオーバーランするなどして、宿泊地に到着。

汗や疲れをシャワーで洗い流したあと、デバッグ作業（窓の内側に巣を張ってた蜘蛛を外へ逃がす）やディスカッション（議題：このまま明朝のマウンテンバイクに突入すると体力的に死ぬのでは？）などを行いつつ、夕食となるBBQへ。

やはり、外で食べる肉・野菜・酒は格別ですね。なお今回、ホタテを炭火で焼くとき、バターが無ければチーズでOKという新たな知見を得ました。
BBQの後半は、開発者らしく~~実録・ヤバい案件シリーズで~~盛り上がりました…！

その後は就寝まで、各々PCを開いて開発や作業、卓球、ダーツ、ビリヤードなどの活動を行いました。

2日目

朝起きたら @shuji_w6e さんはすでに朝練（ロードバイク）に出陣済。
残されたメンバーもPCを開いて各々の開発・作業、ウグイスの鳴き声をバックにアニソンを流す、などの自主練を行っていました。

マウンテンバイク

午前中は NACのマウンテンバイクコースへ。@tmaeda1981jp さんが合流されました。この日もいい天気。

f:id:gishi_yama:20130713103457j:plain
羊蹄山を遠景に、この草原や林道をMTBで一気に下り降りるという爽快なコースです。膝下まである草むらに突入、気がついたらギアに草が絡まってたり、メンバーのMTBのチェーンが切れて落下・草むらを捜索したり、いつのまにか服に毛虫がついててあわあわしたりとハプニングも満載です。

f:id:gishi_yama:20130713113840j:plain
わずかな登りで再び最後尾の足手まといになり、@megascus さんから水を分けていただいたり（本当にありがとうございました、助かりました）しつつ、オフロードな下り坂を滑走。非常に面白かったです。途中のわき水で汗を流したのも非常に気持ち良く。

MTBから戻り、@irasally さんと @fel97048 さんが合流され、昼食はNAC2階のJoJo'sカフェ。
f:id:gishi_yama:20130713123522j:plain
疲れた体にいい塩加減のじゃがいもとバーガーが、染み渡るように美味しく感じました。

その後、皆さんは川下りへ向かわれましたが、私はその日の午後から札幌で学会のイベントがあったため、ここで離脱となりました。川下り、ほんと楽しいんですよねアレ。

まとめ

開発キャンプとは何だったのか→少なからず足腰の筋肉が開発された。
開発作業進捗→pom.xmlファイルちょっといじった。
個人的には自転車での迷惑のかけっぷり・体力の衰えっぷりに激しくショックを感じた。自転車通勤などの対策が待たれる。
ウィスキー工場以後、おみやげで買ったチョコレートが車のトランクに放置されていたことをすっかり忘れており、帰宅時にはコーヒー豆と溶けたチョコソース的な何かに変質、冷蔵庫に今も封印されている。

また自転車ではご迷惑をおかけするかもしれませんが、次回の開催を心待ちにしています！

2012-09-06

Apache Wicket 6.0.0 をビルドした

Java wicket

Wicket 6 がリリースされてから，~~jarファイルの配布が無くなった様なので~~，mvnでビルドしたときの経過をメモ．

追記1（2012-09-10）

@gishi_yama WicketのjarはMavenのリポジトリからダウンロードできるみたいですよ。 URL

2012-09-07 02:21:28 via Tweetbot for Mac to @gishi_yama

@madogiwa 先輩からのツッコミ。ありがとうございます。

追記2（2012-09-10）

Wicket-Usersによると、
http://www.apache.org/dyn/closer.cgi/wicket/6.0.0/bin
からもjarファイルがダウンロードできるみたいです。

環境

OSX Lion，Java SE 7u7, maven-3.0.3．

ソースコードのダウンロード

Apache Wicket のダウンロードページから，から apache-wicket-6.0.0.tar.gz をダウンロード．

ビルド

展開して、mvn packeage を実行.

$ tar -xvzf apache-wicket-6.0.0.tar.gz
$ cd apache-wicket-6.0.0
$ mvn package

完了

問題がなければ、各ディレクトリの target 以下にjarファイルがビルドされている。

[INFO] Reactor Summary:
[INFO] 
[INFO] Wicket Parent ..................................... SUCCESS [1.917s]
[INFO] Wicket Util ....................................... SUCCESS [18.271s]
[INFO] Wicket Request .................................... SUCCESS [6.281s]
[INFO] Wicket Core ....................................... SUCCESS [1:55.553s]
[INFO] Wicket ............................................ SUCCESS [0.170s]
[INFO] Wicket Date/Time .................................. SUCCESS [7.543s]
[INFO] Wicket Extensions ................................. SUCCESS [29.266s]
[INFO] Wicket Development Utilities ...................... SUCCESS [6.645s]
[INFO] Wicket IoC common code ............................ SUCCESS [5.244s]
[INFO] Wicket Spring Integration ......................... SUCCESS [6.509s]
[INFO] Wicket Velocity ................................... SUCCESS [4.567s]
[INFO] Wicket Auth Roles ................................. SUCCESS [4.985s]
[INFO] Wicket Guice Integration .......................... SUCCESS [6.018s]
[INFO] Wicket JMX ........................................ SUCCESS [3.359s]
[INFO] Wicket Objects Sizeof Agent ....................... SUCCESS [1.990s]
[INFO] Wicket-Experimental ............................... SUCCESS [0.046s]
[INFO] Wicket-Atmosphere ................................. SUCCESS [7.426s]
[INFO] Wicket Examples ................................... SUCCESS [26.289s]
[INFO] Wicket Native WebSocket Parent .................... SUCCESS [0.035s]
[INFO] Wicket Native WebSocket Core ...................... SUCCESS [6.729s]
[INFO] Wicket Native WebSocket Jetty ..................... SUCCESS [4.653s]
[INFO] Wicket Native WebSocket Tomcat 7.x ................ SUCCESS [4.487s]
[INFO] Wicket Bootstrap .................................. SUCCESS [2.600s]
[INFO] Wicket Examples Parent ............................ SUCCESS [0.034s]
[INFO] Wicket Examples Jar ............................... SUCCESS [4.007s]
[INFO] Wicket Examples War ............................... SUCCESS [0.701s]
[INFO] Wicket Quickstart Archetype ....................... SUCCESS [7.221s]
[INFO] Wicket Common Tests ............................... SUCCESS [0.791s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4:44.009s
[INFO] Finished at: Fri Sep 07 01:41:57 JST 2012
[INFO] Final Memory: 82M/484M
[INFO] ------------------------------------------------------------------------

備考

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:16.889s
[INFO] Finished at: Fri Sep 07 01:32:50 JST 2012
[INFO] Final Memory: 26M/102M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.8.1:jar (attach-javadocs) on project wicket-util: MavenReportException: Error while creating archive: Unable to find javadoc command: The environment variable JAVA_HOME is not correctly set. -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :wicket-util

みたいなエラーが出る場合は、クラスパスにJAVA_HOMEを設定し忘れているので、パスを通して再実行.

$ export JAVA_HOME="/Library/Java/JavaVirtualMachines/jdk1.7.0_07.jdk/Contents/Home"
$ echo $JAVA_HOME
	※パスが通っている事を確認
$ mvn package

2012-06-07

Tuning Java SE for Throughput and Latency に参加しました

Java

Tuning Java SE for Throughput and Latency に参加しました。

セミナーは、

Java Performance (Java Series)

作者: Charlie Hunt,Binu John
出版社/メーカー: Prentice Hall
発売日: 2011/10/04
メディア: ペーパーバック
購入: 1人クリック: 49回
この商品を含むブログを見る

を書かれた Charlie Hunt 氏のテキストに基づいて進められました。

要約は toggeterにもまとめられていますので、セミナーの中でチューニング心得として印象に残っている点をピックアップします。

JVMオプションは特性を把握して使う。

JVMのオプションをWeb検索すると、ここ10年弱の間に作られた日本語の記事もたくさん見つかるのですが、過去のJVMを前提に書かれたものや、必ずしも個々の運用環境にマッチするものではないので、鵜呑みしないように注意しましょうということ。

セミナーを受けた上で今まで参考にしたことがあるサイトを見返すと、確かに古いJVMや特定の環境を想定して書かれたままの情報もいくつかありました。例えば、MaxTenuringThresholdとか（OSやJVMのバージョンによって、設定できる値が異なる）、CMSIncrementalModeとか（server（マルチコア）環境には適していない）。

JRE（JVM）は最新版を使う。

講師の方も会場の反応も、「なかなか難しいよねえ」という反応が印象的でしたが、起動オプションによる挙動や初期値にもデバッグや改善があるので、マイナーバージョンアップであっても（可能なら）しっかりやっておきたい、ということ。

私の職場の環境は極力最新版にしていくルールなので幸せなんですが、そうではない現場も多いのですね。

GCのタイミングの変更も手段の一つとして考える。

CMS-GCを使っていてFullGCが避けられない時は、ヒープメモリ配分だけではなく、GCのタイミングが変更するのも手段の一つとして有効だよ、ということ。

マイナーGCが動作するメモリ利用率の閾値を設定できるオプションがある（例：CMSInitiatingOccupancyFraction）ので、たとえばyoung領域がめいっぱいになる前に早めにGCが走る様に設定するのも効果敵な場合がある。ただしメモリの効率的な利用とはトレードオフになるので、これも実際にチューニングしながら最適な所を見つけていく。

最終手段

ヒャッハッハッ　メモリだぁ〜！

ということで、チューニングにも限界はあって、64bit環境にしてヒープ領域もシステム領域もたくさんメモリを確保することも考えましょうということ。

NPE

ぬるぽ。

2011-08-22

PostgreSQL勉強会＠札幌に参加してきた

PostgreSQL イベント

開催から2週間近くも経ってしまいましたが、PostgreSQL勉強会＠札幌に参加させていただきました。

以下、私的まとめ等です。

@syachiさんの「削除フラグのはなし」（スライド）

はじめに

論理削除でおこりがちなケースとして……

削除フラグがあるのだから、リレーションは使わない、レコードも消さない。プログラム側で何とかするから、不整合は起こらない！
- 将来的に、データ構造と蓄積されたレコードの整合性・正当性・有効性が不明瞭になりやすい。
- データの矛盾や誤データをカバーするためのコードが増えていく。

データベースの基本は「矛盾を排除すること」。データベース側で削除フラグを利用するときに想定されそうな矛盾を極力排除し、付き合いやすいデータベースを維持するためにはどうするか。

生きているレコードは1件のみ。死んだレコードは複数件許可。こんなときは？

ユーザIDなどの本来一意なカラムに対して、有効な削除フラグが1件になるような部分インデックスが有効。

論理削除を伝播させたい時（例：削除されたユーザにひもづくレコードも削除としたい）は？

削除フラグを、bool値ではなく、「キー値が負のもの」などというルールにしてしまう。
削除動作として主キーに-1をかければ、外部キーで関連するものを変更できる。

いっそ削除テーブルに入れてしまいたい時は？

各テーブルのレコードが削除された事をトリガにして、関連するテーブルのレコードを削除テーブルに移動してしまう様なFUNCTIONを用意する。
テーブル名を一貫したルール（delete_xxx）にしておけば、類推も楽。

削除フラグは我々の中でも一番の小物……

業務分析や設計を怠ると、下書きフラグ・一時停止フラグなど、次なる強敵も。

@iakioさんの「XIDを周回させてみよう」（スライド）

はじめに

PostgreSQLを長く使ってると、データが見えなくなってしまうXIDの周回問題が発生する仕様らしい
- じゃあ発生する瞬間を見てみよう！

トランザクションIDとは

トランザクションごとに発行されるID。
このIDの大きさで、データベースに要求された各トランザクションの実行順番の整合性管理している。トランザクションIDは各テーブルに Xmin, Xmax という隠し属性的なカラムで管理されていて、SELECT文で閲覧可能。

ある環境化でXmin, Xmaxの値がオーバーラップすると、トランザクションが無効になる≒データが消失する。

PostgreSQLの自衛手段

トランザクションIDの逆転防止の為に、PostgreSQLには自衛手段が組み込まれている。

例
- 上書きを予防するための特別なトランザクションIDの予約領域がある。
- 一定の数に達しているトランザクションIDは振り直す。
- 残りのトランザクションIDの数が危険域に達する頃に、エラーログを吐く。

このため、通常利用などにおいては、周回問題を発生させるのは難しい。（逆に言えば安全）

周回問題を防ぐ為に運用側で意識することは？

PostgreSQLの自衛手段が動作するために，VACUUM FREEZEをきちんと行う様にしておくのがベター。

質疑やフリートークで出た話。

論理削除について
- トリガは多用すると、コストが高かったり、全容を隠蔽してしまう可能性もあるので、ここぞというポイントで利用するのがベターかも。
- トリガを使ったときのテストには、PG_TAPみたいな応用出来そうなツールもある
- 削除テーブル方式は、元テーブルのレコード件数も少なく保っておけるので、（生きているデータを相手にするデータアクセスには）より良いかも。
- 削除テーブルの実現には継承、パフォーマンスの悪化にはWAL無しテーブル（9.1から）っていう方向性もあるよね！
- 最近はORMで論理削除をサポートしようとする動きも若干ある。（そもそも論理削除は日本ではニーズが高いけど、諸外国はそうでもないらしい）
その他
- みんなデータベースのmigrationってどうやってるんだろう？→ツールやサポートを行うORMが幾つかあるものの、大規模な変更時の物も含めてベターな手段はなかなか難しい模様。
- Macユーザー多いですね！（林檎マークの背面パネルで埋め尽くされた机を見ながら）
- 次回は10月頃？

感想

論理削除について。私もプロジェクトのデータベースで論理削除を使っているんですが、削除フラグを伝播しなくても良かったり、矛盾が発生するような要求が（まだ）無いので、比較的救われてるんだなと実感しました。
ただ「削除はされてないけど基本的には不要になったデータ」はどうしても出てしまうわけで、紹介していただいた手法はそういったデータにも使えそう。特に「削除フラグはbool値じゃなくてキー値が負数でも良いよね」っていう考え方は、普段エラーコードなどを使っていながら、目から鱗でした。大変勉強になりました。

周回問題について。PostgreSQLについて検索したときに単語は良く見かけていて、漠然と怖いなーと思っていたんですが、どういう仕組みなのか、現在のPostgreSQLがどういった対策をとっているのかを学べて一歩理解が深まりました。「運用で役に立つかどうかは別として」みたいな前置きもされていましたが、Xidの様な仕組みはアルゴリズム的な視点からも非常に興味深かったです。

時間が押していたので自重してしまったんですが、実は聞いてみたかった（リクエストしたかった）ネタとして、PostgreSQLには、複数のデータベースから固有のテーブルだけをレプリケーションする仕組みってあるのでしょうか。
例えば，Aデータベースからはfooテーブル、Bデータベースからはbar, bazテーブルだけをレプリケーションするCデータベースといった感じのものは実現できるのかなあと。やっぱり同期ツール的なプログラムをアプリケーション側で書くしか無いのでしょうか。

2011-05-12

Wicketで新しいウィンドウ（タブ）での表示を抑制するための試行錯誤（中）

Wicket Java

どうしても画面を新しいタブ・ウィンドウでの表示を抑制したいというニーズがあり、Wicketで実現可能かどうか、試行錯誤中。

いまのところ、Wicketの複数ウィンドウサポート機能をオンにした上で、ページマップの数や名前でウィンドウ（タブ）をcloseする案をチームで検討していて、一見行けそうな気がしているものの、まだまだ隠れた問題がありそう。

Applicationのinitメソッド

protected void init() {
	super.init();
	getPageSettings().setAutomaticMultiWindowSupport(true);
}

全てのページの親となるWebPageクラス

public class HeaderPage extends WebPage {
	public HeaderPage() {
		// PortalSession.get().getPageMaps().size() > 1 などの条件の方が良い？
		if(getPageMap().getName() < null) {
			/* ウィンドウを閉じる処理や、不要になったPageMapを
　　　　　　　　　removeする処理をここに書く */
		 }
	}
}

上記のソースで現在の問題点として解っているのは、ModalWindowやPopupWindowの表示も阻害してしまうこと。
ModalWindowやPopupWindowを阻害せずに、意図したURLの新しいタブ・ウィンドウでの表示だけを抑制できる方法は無いものかなあ。

もし、良い意見をお持ちの方がいらっしゃいましたらよろしくお願いします……