サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
体力トレーニング
itoasuka.hatenadiary.org
面白みがないので JPA はとりあえずおいときます。Doma がお気に入りなので、Doma が念頭にあったりします。それを踏まえて Scala + Wicket にあう ORM を探しています。文中でいう「エンティティ」とはレコードと紐づくクラスのことです。 Squeryl Wicket で利用するなら直列化に関する仕組みがしっかりできていないといけません。Squeryl その点でポロポロ問題がでました。以前もとりあげましたが、まず、エンティティに定義している serialVersionUID がなぜか永続化対象になってしまいます。これはバグでしょう。それから、エンティティのフィールドにカスタム型(ユーザ定義型)が使えるのですが、そのカスタム型が必ず継承しなければならないクラスが Serializable ではないのでカスタム型を使用したエンティティは直列化できなくなってしまいます。 結論
私は前々から Wicket は Scala と相性がいいに違いないと言ってはいましたが、未だに試していなかったのでこの連休を利用して試してみました。ORM は最近 Doma がお気に入りだったのですが、Scala では APT が使えないので Squeryl を試してみました。 とにかく直列化が鬼門 Wicket といったら、とにかく Serializable です。Scala の場合は、直列化可能なクラスには @serializable を付けるのがお約束です。ところが、これは java.io.Serializable を実装するのとは意味が違っているようで、Model に食わせることができないのですね。 それから、Wicket は Scala ネイティブなフレームワークではないので、ほうぼうで Java コレクションが使われているわけです。Scala には Scala コレクションを
YHVH とはユダヤ/キリスト教における唯一神を指す聖なる四文字です。ユダヤ/キリスト教では神の名をみだりに口にしたり書き表すことははばかれるので、このように子音だけで表現するようになったといいます。そして、時がたつにつれて、結局これをなんと読むのかがわからなくなってしまったというオチがついていたりします。かつては「エホヴァ」じゃないかと言われていましたが、それは間違いで、「ヤハウェ」だろという説があったりします。 さておき、システム開発の現場においても、システム様を畏れ敬うがあまり、子音だけで表記しようとする人がいます。こうしようとすることを YHVH 症候群と言います(今さっきつけたw)。例をあげると↓のようになります。 通常表記 発症者表記 test tst copy cpy flag flg servlet srvlt コンピュータのリソースが豊富な昨今、このような略に可読性低下以
きっと同じような記事を書く人がたくさんいるんだろうなぁと思いつつ。 アジャイルはウォーターフォールよりも難しい | 日経 xTECH(クロステック) ↑こちらの記事に触発されて、私がウォーターフォールやりながらアジャイルでやりてぇと思ったときの経験を書いてみる。 難しさ(1)落ちない水。隠れた溯上用水路 ウォーターフォールとは、滝のことです。各プロセスが手戻りすることなく、次々にこなされている様が、また、ガントチャートなどで書き表わした場合の様がその滝のように見えますね。 さて、このプロセスって、ちゃんと予定通りこなすことってできるんでしょうか? まず無理でしょう。なぜなら、見積り工期の根拠が乏しいからです。ふたを開けてみたら「思ったより時間がかかった」という経験を持っている方は少なくないでしょう。 また、やってみたら「この仕様じゃダメじゃね?」となったこともあるか思います。と言いますか、
とあるところに CentOS で構築した Web サーバを収めました。それは、LAN 内からしかアクセスできないのですが、そこの決まりでクライアント認証をしなければならなかったのでかように設定をしました。 ところが最近、これにつながらなくなりましてさあ大変。 まったく原因がわかりませんでした。 現象1 Linux からはつながる このサーバ自身に入れておいた Firefox からは接続することができました。でも、お客様が使っているのは Windows。ここかはらなぜかアクセスできない。ブラウザは IE7。Firefox 3.0.x でも試してみたけどダメ。 現象2 再現できない(と思ってた) 仕方がないので、似たような環境を自社内に構築して確かめてみたら。上手くいく。と思っていたけど、試していたのは証明書と LAN 用に構築した CA のみで、ディレクトリ構造などは二の次にしておりまして、
ちょっとした成功体験を紹介します。 どんなプロジェクトだったか オフコン系の社内業務支援システムをWebベースに作り変えるプロジェクトでした。まだ全部終わってませんので過去形でいうのは適当ではありませんが。 コンポーネントの登録を省力化した とにかくこの手のシステムは1画面あたりの項目数が多い。なので、コンポーネントの生成と登録をちんたら手組しているとラチがあきません。そこで私がとった方法は、Excelシートに項目名とコンポーネントの種類、Wicket ID、必須か否かや値の範囲などの簡単なバリデーション情報を書いて、それを POI で読み込んでソースを生成することでした。 はじめはコンポーネントの種類はまさしくクラス名で指定していたのですが、何度かバージョンアップを繰り替えして今では和名で指定しています。実際のクラス名とは別区XMLファイルで結びつけています。たとえば「テキストフィールド
Wicket と ActiveObjects の組み合わせが良いよ!という記事をかなり前に書きました。ところが、その「良さ」を発揮するための Databinder というプロダクトがなかなか Wicket 1.4.x に対応してくれない! んじゃあ、自分でやるぜ! と思って Databinder のソースを見てみたのですが、ちょっと厳しいところがありまして(Wicket 1.4 のジェネリクス対応のせい)Databinder の開発チームも同じところで悩んでいることがあとでわかりました。 ということで、Wicket と ActiveObjects の組み合わせが流行っているなんて言われる割に Databinder なしでみんなどうやってるんだろ? なんて思っていたところです。もしかして、DTO 的なものをわざわざ作っているのでしょうか? それとも Proxy を使ってる? 何にしてもいまい
ここのところJavaによるWebアプリケーションの経験が皆無な人にいろいろ教育してみてわかったのですが、教育の観点からするとWicketはとてもいいですね。 つまり、学習コストが低い。 故あってWicketとともにSlim3も学習対象にしているので、Slim3のような「薄い」フレームワークとの対比となるのですが、以下のような学習コストの低減にあたっての利点がありました。 HTTP そのものの知識がほぼ不要。 テンプレート(View層)の作成には HTML の知識だけでほぼことたりる。 JSPのJSTLのようにJava以外のものを身につける必要がない。 ページ間の値の引渡しについて特別に設計、考慮の必要がない。 ただし、Wicketはリソース食いな上にデフォルトのパスがカッコ悪いので、BtoCのWebサービスにはあまり向かないでしょう。逆に従来のC/S型の社内システムをWebベースでリプレー
Slim3 の Online Demo のソースなどを見てみると、input タグなどはナマで使っていることがわかります。代わりに EL 関数が使われています。 なんかごちゃごちゃしてて見にくいなぁと、脊髄反射的に Twitter でボヤいていたら id:higayasuo さんに返信をいただいたのでここでも紹介させてもらいます。 @itoasuka HTMLのtagにtaglibを使うとDWとかでプレビューできなくなるので基本使いません。表示系のtagでないなら、別にいいと思うけど #slim3 http://twitter.com/higayasuo/statuses/6228338500 なるほどー。 Twitter というインフラの存在と私のボヤきにすら返信をくれる id:higayasuo さんに感謝感謝です。
「層が厚い」ってのは自分自身が積み上げたノウハウの厚さってだけで他の言語も厚いのかもしれないけど、とにかく今自分がJavaを中心とした開発でできていることを他の言語でやろうとするととてもじゃないけどやり切れないんですよ。 具体的な話をしますね。 まず、FindBugs。自動的にバグを見つけてくれるツールです。もちろん、業務ロジック的なバグなんてのは人間じゃなければ見つけられっこないわけですが私の場合だとif文の条件を反対に書いてしまってヌルポさせちゃうパターンなんかをいち早く見つけてもらって助かってます。それから、マルチスレッドプログラミングをするときもかなり助かります(waitとnotifyのかけかたがちぐはぐになっているのを見つけてくれたりしてくれます)。あと、オープンしたものをクローズしてないとかそういうのも見つけてくれますね。ビギナーに使わせると転ばぬ先の杖としてもかなり威力を発揮
Scala東北のMLに流れてきた記事です。後で読み返し易いようにここにもメモしておきます。 非関数型言語に慣れ親しんだ身としては、「while使わないで再帰関数使えよ」という関数型言語のスタンスを見ると真っ先に思いつくのが「言いたいことはわかるが、でかいループ回したらスタックオーバーフローするべ」ということです。 しかし、Scalaをはじめとする関数型言語ではコンパイル時に再帰関数を最適化してスタックを使わないループ等にしてくれるそうでこの心配はないとのこと。ただし、これには条件があってScalaの場合 自分自身を呼ぶ末尾再帰関数であること 再帰関数が、オーバーライドされる可能性のないメソッドであること。つまりメソッドを定義するクラスが final であるかメソッド自体が final、あるいは private であること 末尾再帰関数というのは関数の最後の処理が再帰呼び出しになっているよう
「Scalaスケーラブルプログラミング[コンセプト&コーディング] (Programming in Scala)」(通称コップ本)の帯の背表紙のところに「コード量はJavaの半分以下」と書いてあります。 マジで? ということで、実験。 実験方法 みんな大好き Cubby の雛形プロジェクトを Maven の cubby-s2-archetype で生成させたものを Scala で実装しなおします。↓これで生成させた奴です。 mvn archetype:generate -DarchetypeCatalog=http://cubby.seasar.org 看板コメント分を差し引いたコードのバイト数で比較します。インデントは Tab でやります。Scala 特有の構文に寄らない改行はできるだけもとの Java ソースと同じようになるようにします。 結果 結論から言うと Scala で書いた方
Scala をやろうなんて尖った方は Java では Commons Logging + Log4J なんてとっくに卒業して Slf4J + LOGBack なんて構成を使っていたかと思います。 今回は、実はそれとはあんまり関係ない話で、Commons Logging でも使える話です。 Java でこんなコードがあったとします。 package example import org.slf4j.Logger; import org.slf4j.LoggerFactory; public class Hoge { private static final Logger LOGGER = LoggerFactory.getLogger(Hoge.class) public void fuga() { LOGGER.debug("debug") } } Scala ビギナーの私は、これを Sc
今、私が出入りしている会社で何やら新人研修的なものをやっているようなんです。Seasar2 を用いて何かのシステムを作っているようですが、トレーナーの語調からすると上手く行ってないようです。 それで、トレーナーの方が切々とトレーニーになにやら説明しています。 仕事の進め方はそこそこの会社で違うでしょうから、私のような外の人間がとやかく言うようなものではないでしょう。でも、ちょっと気になるのが人情。私にもしゃべらせろと思ってみたり(笑)。とは言え、そんなことはおくびにも出さずに自分の仕事を淡々としていますがね。 ということで、私がその時言いたかったかったことをここで言わせていただきたいと思います。 それは、新人には「すべてのものにはトリガー(引き金)がある」ということを強く教えなければならないということです。 クラス図書いてみろと言って、上手くできない。なぜできないのか? みんなきっと学歴で
1. Web サーバの設定方法を覚えてほしい そんなに深くじゃなくてもいいんです。Apache でも IIS でも、なんだったら AN HTTPD だっていい(というか AN HTTPD って学習用にはかなりおすすめです)。それでどこにファイルを置くと外部からアクセスできちゃうのかということを知ってほしい。直リンクで様々なファイルを叩いてほしい。 「どんなところで稼働するのか」ということをほとんど学ばずに Web アプリケーションを書いている人って意外と多くて、そういう人が顧客情報がぎっしりつまったデータファイルを平気で外部からアクセス可能なところに置いたりするんですよね。 2. HTTP クライアントを作ってみてほしい とにかく Web プログラム自身が吐き出した HTML を善意に解釈するブラウザ(IE や Firefox)からのみアクセスされるものだと思い込んでいる Web プログラ
昨日のエントリがあまりにも「動かすだけ」だったので、もうちょっとまともなアプローチを模索してみました。ポイントは Maven2 に GAE/J SDK 関連の依存性を追加 ロガーは java.util.logger を使いましょう ローカルで動かそう デプロイしよう Wicket のプログラム自体は昨日と同じです。将来的に GAE/J で JDO を使用することを睨んでいます。 Maven2 に GAE/J SDK 関連の依存性を追加 Wicket 使いの方の中には Maven を使っている方が多いんじゃないかという思い込みのある私です。私も Maven 愛好者です。ということで、GAE/J に関するパッケージも Maven 管理したいわけです。セントラルリポジトリに該当のパッケージは登録されていないのですが Maven Archetype for GAE/J project で参照してい
ミッションは、Wicket の QuickStart で作成した Maven プロジェクトにできるだけ手を加えることなく Google App Engine で動かすことです。 修正または作成しなければならない点は以下の 2 つです。 セッションストアを変更する。 appengine-web.xml を作成する。 なお、この記事の内容は Wicket 1.4-rc4 で試しました。 セッションストアを変更する Wicket では、デフォルトでは org.apache.wicket.protocol.http.SecondLevelCacheSessionStore というのを通してセッションをディスクに保存するようなことをやっています。Google App Engine ではファイル I/O は認められていませんので、このままではエラーになってしまいます。 これを変更するには Wicket
独断と偏見でランクをつけてみました。 レア度 F : abstract よく IT ゼネコンさんが気にかける「一山なんぼのプログラマ」はほとんど見ることがないし、なんのためにあるのかもわからないでしょう。元 COBOLer でよれよれになりながら Java をやっている古兵の方々も気にもかけないキーワードかもしれません。 もちろん、基底クラスを作る役目の人、フレームワークなどを作っている人はたくさん見ていることでしょう。 レア度 E : 大域脱出 ↓こういう書き方。大域脱出が必要なケースって意外とないんですよね、Java って(C だとしょっちゅうだったような気がしないでもない)。 hoge: for(String[] foo : fuga) { for (String bar : foo) { if (bar.equals("xxx")) { break hoge; } } } レア度
というか、RAID 5 がついてる PC サーバって無意味な気がするのです。 この辺の価格帯のものって、零細〜小企業があたりが自社サーバ用に「奮発して」買うものというパターンが多いと思うのですよ。 でも、それが「町の SIer さんのすすめで入れました」ぐらいだと、きっとその会社には IT 系の専門スタッフなんていなかってりするわけで、要するに RAID 5 を積んでても HDD が壊れたことに気がつかなかったりするわけですね。下手すると、すすめた町の SIer さんですら RAID 5 を構成する HDD が壊れるとどうなるのかわかってなかったりするわけです。 ついでにこのブログをお読みのそこのあなたはどうですか? 自分の身近の RAID マシン。なにが HDD が壊れたサインなのかすぐに言えますか? でも、これってありえることですよ。バッテリ交換ランプをチカチカさせたまま UPS を使
みなさん、Javadoc 書いてますか? Javadoc は「API ドキュメント」と言われることが多いように、主にライブラリ的なプログラムで書いてこそのものだと思っている方もいるかもしれません。しかしながら、仕様書を Word や Excel(笑)で別途作ると、プログラムと仕様書の同期がとれてないというはめに陥り易くなりますので、Javadoc はどんなときも活用したいというのが私の考え方です。 まず、overview.html を書け Javadoc コメントをいくらか書くような人でも、overview.html を書く人は意外と少ないのではないでしょうか。リファクタリングが何度となく行われるアジャイル開発の現場では、クラスの構成がよくかわりますので、いちいち詳しいコメントを書いていられないということはあるかもしれませんが、overview.html はそれほど何度も手をつけるようなも
すごくいい。とってもいい。何がいいって、まず ActiveObjects から褒めてみますね。 使えるようになるまでがあっというま(設定やコード量的に)。DI コンテナとかいらない。設定ファイルももちろんいらない。 エンティティに合わせて CREATE TABLE を発行してくれる。すでにテーブルが存在したら、現在のエンティティに合わせて ALTER TABLE も発行してくれる。リファクタリングをよくする人にはうってつけ。 Commons DBCP や C3P0 がクラスパス内にあったら、それを自動的に認識してコネクションプーリングに使ってくれる。ちなみに C3P0 はクラスパス内に Log4J があったら Log4J でロギングしてくれる。log4j-over-slf4j を入れとけば SLF4J でログをはくから Wicket とのログの親和性も問題なし。 パフォーマンスはどれぐらい
ちょっと前から気になっていたもののなかなか試せず、最近になってようやく試し始めている Wicket について書いてみたいと思います。 最近は Cubby を多く使っていた私にとって、どのへんが良いと感じたかというと。 複雑な画面制御をしてもプログラムが追いやすい。Cubby の new Redirect(HogeAction.class) という書き方はなかなか良いなとは思っていたけど、比じゃない。Cubby はリンクサポートが罠だから、尚更。 イベントドリブンだから、どのボタンを押したらどう動くというのが書きやすい。 HTTP がステートレスプロトコルであることを忘れさせてくれるほど自然なライフサイクル。 とにかくエラーメッセージが親切。下手なことをやっても Wicket 部分で NullPointerException で落ちることはまずない。NullPointerException
Cubby にしろ、JSF にしろ Struts にしろ、バリデータにはたと違和感を感じました。 オブジェクト指向なんだから、どんな値が OK な値なのかはオブジェクト自身が知っていなきゃいけないんじゃないのかな? 車オブジェクト自身が、搭乗定員を知らないのはおかしくないですか? いやいや、搭乗定員 5 名でも、その気になれば 6 人乗れるよ。それを取り締まるのは法律であって、バリデータは法律なんだって話もありますが。 でも、「1 リットルの器」オブジェクトに 2 リットル入るのは明らかにおかしい。外野がなんと言おうと入らないものは入らない。 特に POJO が流行った今、「物」を表した「オブジェクト」は、ほとんどが単なる構造体。 なんか、違和感を感じるんですよねぇ。
COBOL(COBOLer)の延命治療のため粉骨砕身しているオープン系技術者のみなさんこんにちは。 私も30を過ぎたころから少しずつ人が丸くなり、COBOL に対する憎悪を燃やしてばかりでもなくなりました。ということで、今日は私のようにやむを得ず COBOL と付き合うはめになった人のために Ubuntu で OpenCOBOL を使う方法のさわりの部分を紹介したいと思います。 と言っても私もまだ触りたてなんですけどね。いっしょに勉強していきましょう。 OpenCOBOL は、その名のとおりオープンソースの COBOL の処理系で、gcc のトランスレータとして動作するそうです。昔の C++ みたいですね。 まずは、インストールしましょう。パッケージはたぶんないので、ソースからビルドします。入手は以下のサイトからどうぞ。 http://sourceforge.net/project/sho
昨日のエントリの続きっぽい話です。 おそらく、SIerさんの内作フレームワークで、プロジェクトがハッピーになったケースってとても少ないと思います。私の経験と、見聞きした範囲で言わせてもらえば1件もありません(!)。 それでなぜ上手くいかないかと言えば、以前のエントリでもふれましたが、その内作フレームワークがそのまま適用できるケースがまずないからです。なので、カスタマイズなんてのが発生します。そのカスタマイズは内作フレームワークの開発者数人に託され、それを用いて開発を行っている(下請けさんなどの)数十人が待たされたりするのです。こんなの上手くいきっこない! 特に日本の受託ソフトウェア開発の特徴を見てみると、とにかく「自分仕様」が多い。アメリカではパッケージソフトを用いたり、オーサリングツールレベルまで昇華した超高級フレームワークで定型的に作ってしまうパターンが多いらしいですが、日本ではその割
大手(ばかりではないでしょうが)SIer さんがたまにやる、どこにも公開していない内作フレームワーク(今回は、Java の Web アプリケーション用のものを念頭におきます)でプロジェクトをすすめるのはこういうリスクがあるんですけど、考慮してますか? っていう話です。 わざわざ書くってことは、考慮してない現場をまのあたりにしてるからなわけですが。 名の知れているフレームワークと言うとまずは Struts ですね。名が知れていないものでも、容易に情報が得られるフレームワークはたくさんあります。また、プロの編集者がちゃんと編集・校正して、しっかりと製本されたそれらの参考書も手にはいります。 いっぽう、内作のフレームワークについて、それを使わされる下請けさんなどの立場で見るとどうでしょうか。 プロジェクトが始まるまで、下手すれば名前すら聞いたことがない。 プロジェクトが始まっても、なぜか実行環境
仕事モードのときはデスクトップ OS に Ubuntu を利用しているのですが、「まだまだだなー」と思うことがよくあります。 私が Ubuntu を使うのは、仕事で PC を使うときは主に Linux 上で稼働させる Web アプリケーションを開発している割合が多いので、開発環境も Linux なら何かと好都合だろうと考えたためです。 私は vi も emacs も大して使いこなせない 私がコンピュータに青春を燃やしたとき MS-DOS がほとんどだったこともあり、vi や emacs は最低限の使い方しか知りません。社会人になってからも基本的に Microsoft のお世話になっているので、CUI で vi か emacs なんて質じゃないんです。これがまず前提なんです。 やはりドライバがネック Windows では、ハードウェアのドライバはメーカが当たり前のように提供してくれますが、L
なんか Windows から Linux に乗り換えたいなと思って Linux にしてみたけどしばらくしたらやっぱり Windows に戻っちゃったという人も少なくないと思います。そんな人に送る、Linux を使いつづけるためのコツを挙げてみたいと思います。もちろん、はじめて Linux に移行してみようと思う人の参考にもなったらうれしいです。 デスクトップのカスタマイズに凝らない デスクトップ Linux を Mac 風にするとか、Windows 風にするという記事は、いつだって大人気です。でも、Mac 風にしたいなら Mac 使った方がいいし、Windows 風にしたいなら Windows にしたほうがいいです。とはいえ、Mac にみせかけて実は Linux、Windows にみせかけて実は Linux ということで人を軽く驚かせることがおもしろいなんていう人もいるでしょう。それはそれ
特に大規模プロジェクトの場合、プログラマのレベルの違いによるプログラムの質の差をなくそうとして重厚なフレームワークが用いられることがあります。 ほんとうにそう思ってるならソースコードレビューのひとつもしてみなさいって、お偉いさん。 そんなんで均質化なんてできやしないですよ、イマドキ。COBOL じゃあるまいし。 Java を例にすれば、文字列を等号で比較しちゃったり、プリミティブ型のラッパー・クラスを new で作っちゃったり(valueOf 使えよって話。というか Autoboxig すら知らないって何?)、せっかく BigDecimal で取り回してんのにプリミティブ型に変換してから計算しちゃったりと、構造的な作りよりも、もっと基本的な部分にレベル差がでることのほうがずっと多いですよ。 ベテランはイカした基底クラスを作ってさくっと画面量産とかできちゃって、ビギナーはなかなかそうはいかな
次のページ
このページを最初にブックマークしてみませんか?
『イトウ アスカ blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く