ToDoの作成

さて、馬鹿話は終了にしてやるべきことの整理だ。

  • サインインページの作成
  • サインイン処理の作成
  • セッションの作成
  • サインイン後ページの作成(HomePage.java)

で、これの端っこの方にある簡単そうなところから作る。
それはどこかというと!デレレレレ・・・デデン!辞めようやこういうの。
えっと、サインイン処理を作るところからはじめよう。
なぜならページ作るのまだよくわかんないしー。みたいなー。ところからー。話ははじまるー。
セッションの作成に至っては先ほど言ったとおり、矢野先生に御教授戴かないと解らない始末だ。
このままでは甲斐性無しとして世間様から笑われることになるのでわかるところからやる。
サインイン処理を作るには、

  • ユーザークラスの作成
  • ユーザークラスにサインイン情報保持
  • ユーザークラスをセッションに保存し、未来へと僕の記憶をつないでいく

という感じで話を進めれば問題無かろうという甘い考えの下、やっていくが、もう寝たいので最初のところだけやる。
無理にプログラミングをするのは仕事だけで十分だ。それ以外のことで限界を超える必要など無いし、ともすれば仕事中ですらろくにプログラミングをしてない状況においてこんな風にみんなに責められながらプログラミングをしたところで何にもならないというか犯罪に走る可能性があるので危険だ。もっと言えばページビューは増えて行くにも拘らず誰もコメントをくれないあたりなど、こんな文章読むかボケ的な意見をサイレントマジョリティが訴えてるのではないか?などという邪推も始まりかねないわけで、これもナイトマジックカーニバルの一環と言えよう。そろそろ本気でウザいと感じてる人がいると思われるので始めよう。

前段

今日はyoutubeで色んなPVを見てたりしたら寝る時間がなくなりそうな雰囲気がしてきたので、お風呂に入る前に少しプログラムをすすめることにする。
まずToDoだ。Eclipseさんにお伺いを立てると、Wicket-Auth-Rolesに必要なWebApplicationのサブクラスであらせられるところのAuthenticatedWebApplicationさんは、

	protected Class<? extends WebPage> getSignInPageClass() {
		// TODO 自動生成されたメソッド・スタブ
		return null;
	}

	@Override
	protected Class<? extends AuthenticatedWebSession> getWebSessionClass() {
		// TODO 自動生成されたメソッド・スタブ
		return null;
	}

	@Override
	public Class<? extends Page> getHomePage() {
		// TODO 自動生成されたメソッド・スタブ
		return null;
	}

ということだそうだ。
最後の

	@Override
	public Class<? extends Page> getHomePage() {
		// TODO 自動生成されたメソッド・スタブ
		return null;
	}

に関しては、quickstartにすでに存在しているので、それをそのまま使うとして、

	protected Class<? extends WebPage> getSignInPageClass() {
		// TODO 自動生成されたメソッド・スタブ
		return null;
	}

	@Override
	protected Class<? extends AuthenticatedWebSession> getWebSessionClass() {
		// TODO 自動生成されたメソッド・スタブ
		return null;
	}

だが、getSignInPageClassはgetHomePage()同様にページコンポーネントとしてログイン用画面を返すメソッドで、
getWebSessionClass()はセッション用のクラスを返すところというのがわかる。
セッションのクラスはWicket本に書いていた記憶があるので、それを後で見れば十分だろう。
問題はこのセッションのクラスに入れておくべきものとしてログイン情報があるはず、ということだ。
ここらへんもEclipseさんに聞いてみれば話は早いだろう。IDEとはそういうものだ。多分。きっと。ワンダラーン。

と、ここで重大な問題が浮上してきて、そのまま沈んでいって欲しい感じだが、一応浮上させたのでどうにか処理をしてやろうという問題がひとつ在るとか無いとかいう噂のひとつとして、まだスケジュール管理アプリの名前について考えていなかったのだが、カッコヨロシゲな名前を思いつくまま命名しようと思っているところだ。こういうものは得てしてその時ふと思いついたものを名前としなければ、ナイトマジック(夜の魔術)として、必死に考えたイカした名前を翌朝以降に見たときに俺は何を血迷っていたのか激しく疑問であると言うしかないような渋知でバカパクなインパク知ネームを思いつけてしまい、最終的に自決に至らざるを得なくなるので注意が必要だ。例えば今日見たテレビのCMでサモハンキンポーが出ていたが、サモハンプロジェクトXと名付けた場合、翌朝どころか20秒後に後悔することは目に見えているわけであり、もっと偶然性を持っていて、なんつーか俺適当に決めたんっすわ。別に、カッコヨロシとかカッコワロシとかそういう系の話は抜きで。マジで。偶然。全然こだわりねぇし。そこらへんに関しては俺ちょっと普通よりクールじゃないっすかぁ?という言い訳が苦も無く成立する名前にしておく必要がある。例えば「マンダリン」とかそういう名前だ。「エビスガオチェルシー」とかまで行くとちょっと格好を付けてる雰囲気になるのでこれ以前で止めておく必要がある。「ベラルーシ」とかにするのはもってのほかで、なぜならば俺は特にベラルーシに関して詳しくないというか、ベラルーシって地名だった気がするけど、なんかサッカーに関係ある?サッカー選手?ってな具合で、仮にサッカー選手だったら、なんでスケジュール管理するのに蹴鞠プレイヤーのお名前を頂戴してるのこのイカレパンスト野郎は。脳みそ空に飛んでったの?みたいな展開になるのは目に見えているわけであって、縦しんば地名であったとしても、お前ベラルーシで何する気なの?まずベラルーシに行くスケジュール自体存在しないのに、足を踏み入れたことすらないような場所の名前でスケジュール管理するとかお前どんだけ他力本願なのコロ助野郎が。となってしまうという可能性も捨てがたいというか、事実そうなる。ので、「旅籠屋」とかが多分最適だと思われる。結論としては「sketch」になりました。ナイトマジックネームです。今後ともヨロシク。

で、関係ない話が大半になったのでここで止めて続きは以降。

矢野勉さんのWicket本に関して

もしWicketについてよく知らんけんなんぞ俺にWicketのやり方教えたりーなと思ってる諸氏には矢野勉さんの本を買うようにお勧めする。WicketStrutsとかの比較に関しては解りやすい図版が入っているものの、肝心のWicket内の考え方に関しては図版が一切と言って良いほど無い。コンポーネント入れ子構造などを説明するのにもっと図版を使ってもいいと思うのだ。あと以前も書いたがポインタが無く、ひとつのコンポーネントについての記述がちょいちょい色んなところに飛んでて、最低二度通読しないといけないというのもある。
ただ、それを補って余りあるぐらい、知りたいことが書かれている本で、正直、俺これやりたかったんだよ!なんだよ!なんも言わなくても解ってくれてるじゃんヤノッチ!マジ今度宮本むなし奢るわ!と思えるぐらいで、単なるチュートリアルを文字に起こしました系のこの本を買った俺はファンタジスタだった的後悔を伴う諸般の本とは一線を画すというか、内容の良さは当然ながらWicketへの愛情が文末から如実に伝わってくるあたり(ちなみに本書の語尾は全て「だウィケッツ!」で統一されている)が、これは買っておいて良かった!と思える本になってるので買っておいたほうがいいというか買っておいたほうがいい。あと、語尾は普通だから期待しない方がいい。

データベース準備

まず最初にやるべきことはログイン画面の作成だろうということで、
ログインするためのIDとパスワードの準備をする。

USERSテーブル

ID NAME PASSWORD
INT PRIMARY KEY VARCHAR(255) VARCHAR(255)

255は特に理由は無い。NAMEなどはもっと短くしていいだろう。
PASSWORDは現状では生パスワードを入れるが、最終的にはハッシュ化されたものを入れるのである程度の長さを用意しておく方がいいだろうけども、SHA-256だとすれば64文字で事足りる。ただ、ここら辺に関しては今後直していけばいいので現状では256文字でいい。何よりも素人当然の僕としてはSHA-256を使ったことが無いので実際に64文字出力されるのかどうか知らないのだ。そしてこれは後でテストしてみればいいだけの話だ。

というわけでデータベースにUSERSというテーブルを作って準備完了。次はWicket-Auth-Rolesに必要なものを作っていくよ!ちなみにwicket-auth-rolesという表記が正しいってのは書き始めたときから気付いてるから忠告してくれなくても大丈夫だよ!ファミ通の攻略本だよ!

やること

必要なのは、

  • 認証画面
  • カレンダ表示
  • タイムライン表示
  • スケジュール登録

で、認証はWicket-Auth-Rolesを使って行くつもりだけれども、内容は良く理解していない。
もうひとつ理解していないのはデータベースだ。曲がりなりにもOracleを「触ったことがある」ので、
H2特有の動きを理解する必要がある。例えばデータベースの保存場所、など。
DAOのアレにbutterfly persistenceを使うことに関してもDAO自体よく解っていないし、
細かいDBの動きも理解してない状態でDAOを使うことになるので、そこらへんも学びながらになる。
内容や仕組みをガッチリ説明している文章を見かけないので困ったことだが、
butterflyに限らず、DAO知ってるっしょ?俺、お前、馬鹿じゃないって信じてるっしょ?みたいな感じで
全体的に俺に優しくしようとしていないというか、もっと俺に気を使ってやさしい説明を心がけて欲しい。
だが無いものをねだっていてもどうしようもないし、ねだり続けてるうちに、あ、こいつメンドクサイ系の存在だ、やばい。やばいっつーかなんか、臭くね?なぁ、臭いよな?ガス?なに?あれ?誰?ん?あ?こいつ、死んでるじゃん!なにこれ!こいつマスマスメンドウ!みたいなリアクションを戴く事になりかねないし、別にここの下りを詳しく書く必要は無いから省略するけど、なんにせよやるべき事はDAOでDBを使えるようになることが重要と考える。
あと、ここに関してはかなりオフレコだが、Google Guiceの使いどころも理解してない。そろそろみんな逃げた方がいい。俺を一人にした方がいい。マジ寂しくて死ねる。あれは俺が中1の時だった。みんなが俺のことを面倒がって逃げて、あれ。この話関係ない気がする。そして続けると俺がますます駄目になる気がする!

ちょっと違う方向に盛り上がったので本流に戻すとして、

の勉強が必要。
そして、TDDのよいところだろうと思うのは、テストコードを書いて調べながら進めていけそうなところ。
ただ、xUnitもちょりっとしか書いたこと無いので、DBに対してどんな風に書くべきなのか解らない。
guiceを使うとよい気がするとアンニュイに思い続けている黄昏時という名の曙前の時間帯。それが今。

Wicketブログ

Wicketを使ってスケジュール管理アプリを作る記事を書く。

  • Java初心者
  • 普段はしょぼいPHPを書く仕事。
  • TDDで進める。やったことはない。
  • Wicket+Google Guice+butterfly persistence+H2の予定
  • Active Objectsにしようと思ったが2年間更新はなく、SVNを見てもH2に対応する気配が無いので辞めた。

以上が前提条件。Javaは本当に知らないが、BlackBerryアプリ開発をやったことがあった気がする程度。
参考にするのは矢野勉さんの「オープンソース徹底活用 WicketによるWebアプリケーション開発」
本日読み終わったところ。
詳しい説明へのポインタが無い分、一回の通読では理解できない部分が多かったというか、
流し読みしてしまった部分が多かった。
が、二回読む前提で読めば問題なかろうもん。がんばろう。