サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
hideoku.hatenablog.jp
Gradle の社内勉強会をやることになったので、ネタ集めをしています。 「Gradle、実はこういうこともできるよ」ネタを考えてたら 私がよくやるのを紹介したらいいかもと思いつきました。 Gradle はスクリプトベースのビルドツールなので、 極端な話、ガリガリとスクリプトを書けば何でもできます。 ちょっとした Excel 読み込みからの→ファイル生成を個人的によくやります。 自分用の作業テンプレートを作っておく意味もあって、まとめておきたいと思います。 Gradleタスクを作る build.gradle は以下のような感じです。 buildscript { repositories { mavenCentral() } dependencies { classpath 'org.apache.poi:poi:3.13' classpath 'org.apache.poi:poi-oox
CheckStyle の設定で苦労したので、作業メモを残しておきます。 やりたいこと テストクラスはメソッドを日本語で宣言したいので、 テストクラスのメソッドだけを CheckStyle のチェックから外したい。 MethodName モジュールの仕様 メソッドの命名チェックを行っているのは “MethodName" というモジュールです。 <module name="MethodName"/> CheckStyle の設定ファイルではこんな感じで設定されています。 デフォルト値は省略されていますので、明示的に属性値を書いてみると以下のような感じに。 <module name="MethodName" format=“^[a-z][a-zA-Z0-9]*$" allowClassName=“false"/> format 属性で「小文字英字で始まって」「英数字のみ」という命名ルールが規定さ
Web アプリケーションの受け入れテストを行うフレームワークとして、Geb が Groovy のエコシステムのひとつとしてリリースされています。 有名な Selenium を Geb は内部で使用していて、色々なことができる上に、比較的少ないコードで簡潔にテストコードを実装できそうなので、採用してみたいと考えていました。 The Book Of Geb - Table of Contents - 0.7.2 Geb のマニュアルサイト(英語)を根気強く読めば、Geb のことは理解できると思います。わかりやすいサイトです。ですが、動かすまで時間がかかったので備忘録的にまとめてみます。 Gradle で依存関係を設定する ビルドツールとして、Gradle を使っています。build.gradle は次のように設定しました。 apply plugin: 'groovy' apply plugin
標準出力 System.out.println() がきちんと実装できているかをテストする必要がありました。 どうやってテストすればいいんだろうと調べてみました。 JUnit でテストする方法 次のサイトがとても参考になりました。色々な方法が紹介されています。 ・標準出力に結果を出すプログラムをJUnit 4.1でテストする方法 - 結城浩のはてな日記 Spock でテストする方法 今は Spock でテストしていますので、先ほどのサイトを参考にしながら作ってみました。 class SystemOutTest extends spock.lang.Specification { def "標準出力にきちんと文字列が出力される"() { def savedSystemOut = System.out def printStream = Mock(PrintStream) System.out
個人的にテストコードを書いたり、Gradle で自動化するのを実践しているのですが、 仕事に活かせているのは小規模で自分の裁量が大きいプロジェクトに限られています。 大規模なプロジェクトになると色々と抵抗勢力が多くて、色々と説得するのが億劫なので こっそり Gradle を仕込んで Jenkins 動かそうと今試みています。 個人的にはコソコソ動いてておもしろいので、成果をメモしていきます。 "ふつう" な前提条件 Gradle を仕込むのは「ふつうの Eclipse プロジェクト」です。 ここで言う「ふつう」とは… ◯Maven ディレクトリ構成ではない src/main/java, src/main/resource, src/main/webapp といったディレクトリ構成ではなく、 src の下に java ファイルがあったり、WebContent ディレクトリの下に WEB-IN
FXML を使ってアプリケーションを作る場合、ロジック部分は Controller クラスを作って実装します。 その Controller のなかで javafx.stage.Stage オブジェクトを取得する方法をまとめます。 Stage オブジェクトを取得したい理由 すでに存在するウィンドウから新しいウィンドウを表示したい場合、次のような実装をします。 class OpenDialogController { void handleOpenButtonAction(ActionEvent event) { Stage newStage = new Stage() newStage.initModality(Modality.APPLICATION_MODAL) // ここでControllerが属する Stage のオブジェクトを渡したい… newStage.initOwner(???
前回「JavaFX ListView の要素を Drag&Dropで移動させてみた - Java開発のんびり日記」で Drag&Drop でリスト間の要素を移動させる簡単なサンプルを作りました。 移動できる先がリストの末尾だけなのは物足りなくて、できればドロップした場所に要素を挿入したいですよね。 ということで、ごり押しなところもありますが、今回は任意の行に挿入するバージョンです。 作ったサンプルの概要 ・ListDrag2.fxml(GUI部分) ・ListDragController2.groovy(MVCのControllerあたり) ・ListDragApp2.groovy(アプリ起動) ・style.css(動的なスタイルを使っているので) の4つのファイルで構成しています。 構成はほとんど前回のシンプルなものと変わっていません。 すべて同じパッケージ内にあって、sample パ
Spock 0.7 から、これまでの Mock に加えて Stub と Spy も使えるようになったので今回調べてみました。 ぶっちゃけ Mock だけ使えれば事足りるんじゃないかと思ってました。 (調べてみた後も若干そう思ってます) テストダブル(Test Double) テストダブルは、テストする対象が依存しているオブジェクトを置き換える代役です。 モック、スタブ、スパイはテストダブルになります。 テスト関連本だと、当然のように「ダブル」って言葉が出てきますが、 ちゃんと理解していないと混乱する用語だと思います。 テストダブルについては『JUnit 実践入門』の第11章に詳しく書かれています。 私はこれを読んで、理解ができました。 JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)posted with ヨメレバ渡辺 修司 技術評論社 201
6/25 に開催された「アジャイルサムライ読書会 at 大阪道場」にて ・よいユーザーストーリーとはなにか? ・ユーザーストーリーをうまく分割するには? というテーマでディスカッションがあった。 ふたつのテーマではあったが、結果的にユーザーストーリーの分割に議論が集中した。 巨大なユーザーストーリーをどうすれば、分割することができるか? 分割しづらい一連の処理をいかにして分割していけばよいか? 喧々諤々… 難しい問題で、うちに帰ってからも色々と考えてみた。 そもそも、ユーザーストーリーとは 私の解釈は、ユーザーに価値をとどける単位。リリースできる、リリースする単位。 『アジャイルな見積りと計画づくり』には、ユーザーストーリーの定義として以下のようにある(P50)。非常にわかりやすい表現だと思う。 ユーザーストーリーは、システムについてユーザーまたは顧客の視点からフィーチャーの概要を記述した
今日にいたるまで『SQLアンチパターン』についてブログを書こうとして、 2回失敗してます。 1回目:『SQLアンチパターン』を読んだ 最初はあまり期待していませんでした。 題名からしてなんとなくおもしろくなさそうだった。 そもそもオライリーだし、取っつきにくいはずだ。 (ここは正直に…) ただ、好評なツイートが多かったので買ってみました。 2,3章読んで、考えが一転しました。 おもしろい。スラスラ読める。あまりのデジャブ感に笑える。 これはブログ書いてまとめようと思いましたが、そこ止まり… 2回目:デブサミで『SQLアンチパターン』にサインしてもらった 読んでる時にちょうどデブサミに参加することができて、 もしかしてと思ったら監訳者の和田さんのサイン会がありました。 「ブログとかで感想ください」 和田さんにそう言われたので、ネタもあるし感謝の意も込めて、よしブログ書こうと決意。 帰りの新幹
Eclipse のデフォルト文字コードを UTF-8 にしているため、Windows では Gradle 実行結果がコンソールで文字化けするという事象が発生していました。 どうやら明示的にを指定しなければ、OS デフォルトの文字コードが採用されるようです。Windows の場合は Shift_JIS だと思います。Eclipse コンソールが UTF-8 で、Gradle の出力が Shift_JIS ということで文字化けです。 ここで Eclipse コンソールの文字コードを変更すればよかったのですが、Gradle の設定を変えることを選択しました。 file.encoding で指定する Gradle も Java で動いているので、Java のファイル入出力の文字コードを変更すればいいようです。色々と試しました。そして、その文字コードはシステムプロパティの file.encoding
このページを最初にブックマークしてみませんか?
『I'm still growin' up ...』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く