一緒に働けない人、働きたい人 - The HIRO Says
ガイアが俺に書けと囁いているので、徒然なるままに。 一緒に働けない人 １．常に他人事 たとえ仕事であっても、絶対に自分でやろうとしない 自分の仕事ではないと常に考えようとする／発言する 「へ〜大変ですね〜」が口癖 ２．言葉の定義にイチャモンをつけたがる 「それって、xxという言葉の定義と違いますよね。それじゃ私の仕事じゃないです。」 「何でそこでその言葉を使うのか理解できません。そもそも（以下略」 『「バグがあるかもしれない」と「バグがある可能性がある」とは意味が違いますよね』 私も意味が分からなかったです ３．話している最中に内容をすり替える ４．最終的には逃げる これが癖になっている人って、何で社会人やっているんだろうね？ こういう人とは、話しても理解し合うことは不可能。一緒に仕事をしていても、尻拭いを強いられている感に苛まれるだけ。関わらない環境を作った方が良い。 昔しんどいと思った
【slim3】画面遷移のための”Controller”−（３）UTの実施方法 - The HIRO Says
前回、slim3 の画面遷移制御用コンポーネントである ”Controller”の実装方法をまとめました。 今回は、この Controller の UT の実施方法を見てみます。 １．テストクラスの概要 Controller のテストクラスは、Controller クラスと一緒に Ant で自動生成されます。 テストクラスのポイントは、以下の２点です。 （１）org.slim3.tester.ControllerTestCase を継承すること。 （２）jUnit 4.x 系でテストを実装すること。 詳細は、jUnit4.x系の使い方をご覧下さい。 ２．テストケースの基本的な実装手順 Controller のテストケース（テストメソッド）の基本的な実装手順は、以下の通りです。 （１）ControllerTester#start() で、Controller のパスを指定する。 Contro
【slim3】JSPの開発手順および注意事項 - The HIRO Says
前回まで、slim3 の画面遷移制御用コンポーネントである ”Controller”について触れてきました。 今回は、この Controller から呼び出される／を呼び出す JSP の開発手順、およびその際の注意事項について見ていきます。 １．あらかじめ用意されているもの slim3-blank をインストールする際、あらかじめ以下のものが用意されています。 ベースとなる JSP 部品 CSS これらをベースに、自動生成した JSP（後述）に修正を加えていく形で、JSP を開発していくことになります。 なお、slim3-blank のインストール時に用意されているファイルについては、slim3のプロジェクト構成をご覧下さい。 （１）ベースとなるJSP部品 war ディレクトリ下に、以下の４つの JSP 部品が用意されています。 JSP ファイル名 内容 header.jsp ヘッダー：タ
【slim3】ビジネスロジックとしての”Service” - The HIRO Says
前回紹介した Model は、あくまで JavaBeans であり、それ自体に永続化の機能はありません。 BigTable への Model の永続化、および BigTable からの Model の取得といった persistence に関する処理は、Model 以外の別のクラスで定義する必要があります。 また、FrontController（後述）は画面遷移を扱うクラスであり、Struts の Action クラス同様、ビジネスロジック及び persistence の処理を定義すべきではありません。 slim3 では、ビジネスロジック及び persistence の処理を行うクラスとして、”Service”というクラスを定義・使用します。 １．Serviceの作成方法 こちらの記事の、”gen-service”をご確認下さい。 ※gen-gwt-service については、後日触れます
【slim3】永続化対象としての”Model” - The HIRO Says
GAE ではデータを、”BigTable”という key-value ベースの DB（key-value store）で管理します。 この”BigTable”へ永続化するクラスとして、slim3 では”Model”というクラスを定義・使用します。 １．Modelの作成方法 前回の記事の、”gen-model”をご確認下さい。 ２．Modelの概要 Model は、一言でいうと JavaBeans です。 基本的に、永続化対象のデータ項目をインスタンス変数として定義し、その getter/setter を定義すればＯＫ、という作りになっています。 ３．Modelの詳細 Model は、slim3 や BigTable で使用されることから、単なる JavaBeans には見られない以下のような特徴を持ちます。 ※以下は、Model 生成時に自動的に用意されます。 （１）java.io.Ser
【slim3】jUnit4.x系の使い方 - The HIRO Says
前回も触れましたが、slim3 のテストでは jUnit 4.7 を使用しています。 jUnit は、4.x 系になってから、仕様がアノテーションベースに変更になっています。 前回はうまくまとめられなかったので、今回は jUnit 4.x 系の使い方を簡単にまとめてみようと思います。 ポイント 4.x 系の場合、大きく２つのポイントがあります。 TestCase を継承しない アノテーションを使用する TestCaseを継承しない 4.x 系では、@Test アノテーション（後述）をテストメソッドにつければテスト対象として認識されます。 そのため、3.x 系までのように org.junit.TestCase クラスを継承する必要はありません。 ※特別にクラスを継承することは可能。Service のテストで触れる予定。 但し、TestCase クラスを継承しなくなると、assertXxx()
slim3のテストコードの注意点 - The HIRO Says
slim3 でプログラムを生成すると、自動的にテストコードも作成してくれます。 ただ、テストコードは jUnit 4.7 を使用しているため、3.x 系とは色々と違うところがあります。 （私は知らなかったのでハマりました…） 今回は、jUnit 3.x 系との違いをまとめてみました。 具体的な違い １．@Testアノテーションの存在 jUnit 4.x 系では、@Test アノテーションのついているメソッドがテストケース（テストメソッド）になります。 jUnit 3.x 系では、テストケースにいちいち testXxx() という名称をつける必要が（事実上）ありましたが、jUnit 4.x 系では、テストケースに好きな名称をつけることができます。 メソッドの命名に自由度が広がるので、テストコードの可読性・保守性を高められそうです。 ※Eclipse や Maven で jUnit 3.x 系
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
