はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

こう作ったら小綺麗に書けるってやりかたが、ある程度見えてきた気がするので、まとめておく。 環境 Java 1.8.0_91 Maven 3.3.9 (Maven wrapper) Spring Boot 1.4.3.RELEASE Apache Commons CLI 1.3.1 $ ./mvnw -version Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-11T01:41:47+09:00) Maven home: /Users/yo1000/.m2/wrapper/dists/apache-maven-3.3.9-bin/2609u9g41na2l7ogackmif6fj2/apache-maven-3.3.9 Java version: 1.8.0_91, vendor: Oracle

せっかく Github を使用して、プルリクエストをレビュー、指摘しても、権限設定の問題で、権限さえあれば [Merge pull request] ボタンを押せてしまう。 結果、マージ先でテストを失敗したり、コード品質落ちてしまったり。 あるあるですね。 今回は、Github のブランチ保護機能を使用して、このようなリスキーなマージを機械的に防げるよう、設定をしてみます。 環境 以前、SonarQube と TravisCI を使って Github でのコードレビューを自動化する で使用した環境を流用します。 Github (2016-02-15 現在) Travis CI (2016-02-15 現在) Maven 3.2.5 ORACLE Java 1.8.0_31 Java HotSpot(TM) 64-Bit Server VM warning: ignoring option

Spring Boot に限った話ではないんだけど、今回 Spring Boot で書いたので、そんなタイトルに。 必要とされるシーンが多いわりに、意外と情報が少なかったので、まとめておきます。 DbSetup を使用するものと、DBUnit を使用するもの、それぞれを紹介します。 なお、今回はテストに Groovy Spock を使用します。 検証に使用したものを GitHub に公開しておいたので、こちらを確認しながら追いかけると、より理解しやすいかもしれません。 https://github.com/yo1000/com.yo1000.edu.boot.dbtest 環境 Java 1.8.0_91 Maven 3.3.9 (Maven wrapper) Spring Boot 1.4.0.RELEASE Groovy 2.4.7 Spock 1.1-groovy-2.4-rc-1

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

JIRA って、タスクや、その所在、期限なんかが可視化される一方で、Issue 作成時には入力項目も多く、 一定のルールを敷いても面倒臭さによって、これが守られなくなってしまうこともしばしばあるかと思います。 そこで、Issue 作成をテンプレ化してしまえば、これを改善できるのではないかと考えました。 以下、Issue 作成時にデフォルト値を設定する方法を紹介してみます。 環境 Atlassian Confluence 5.8.10 Atlassian JIRA v6.4.11 準備 まずは、Issue 作成を行うための URL と、設定するデフォルト値、および そのパラメーター名を集めます。 URL まずベースとなる URL を用意します。 JIRA の URL のうち、画像の赤線部分の URL を控えて下さい。 これに、CreateIssueDetails!init.jspa を付け足

まず、TeamCity について。 そもそもご存じない方が多いように思うので、ヒトコトで紹介すると、IntelliJ IDEA の開発で有名な JetBrains 製の CI サーバーです。 オンプレミスの CI サーバーとしては、世の中的に Jenkins の方が有名ではありますが、プロジェクトの階層化に対応しており、ビルド構成も非常に見通しやすく、個人的に非常に気に入っています。 JetBrains 製ということでライセンス形態が気になるところですが、20のビルド構成、3つのビルドエージェントまでは、すべての機能が無償で利用することが可能です。 複数のプロダクトを1つのサーバーで横断的に管理したいなどでなければ、無償の範囲で十分に運用できそうです。 さっそく構築してみます。 環境 ConoHa by GMO メモリ 1GB プラン Ubuntu 14.04 LTS Java 8 Pos

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

2018-05-30 追記 この記事は最終更新日から1年以上が経過しています。 というメッセージが長らく出ていたにも関わらず、今でもそこそこ読んでもらえているようなので、新たに 改訂版を書きました。 新年度を迎え、新たな職場、新たな環境で、はじめて Spring に触れている方も多いかと思います。 とくに、これまでは少人数開発しか経験してこなかったような新人さんがたにおいては、エンプラ開発では非常に多く採用されている Spring を、今まさに学んでいるという方、多いのではないでしょうか。 今回は Spring を学ぶにあたり、まずおさえておきたい基本的な考え方をまとめてみます。 全体俯瞰 Spring MVC には、それぞれ一定の責務を持ったコンポーネントが定義されており、その多くは特定のアノテーションに対応付けられています。 はじめに、それぞれの役割と相互関係を理解しておくことで、Sp

新年度ですね。 新人教育の季節ですね。 さて、今年配属された新人たち、コーディング経験のある方が多いようです。 ところが例年とは、ある一点が大きく異なっていたのです。 コーディング経験はあれど、サーバサイドアプリケーションも、コンソールアプリも、 ウィンドウアプリケーションも、ほとんど組んだことがない。 そう、イマドキ世代は、開発においてもスマホネイティブ世代だったのです。 また、Web アプリの開発をほとんど経験していないため、 避けては通れない教育課程があることにも気が付きました。 セキュアプログラミングについてです。 スマホアプリでは、(WebView でも使っていなければ) XSSも、CSRFもありません。 スタンドアロンアプリであれば、SQL インジェクションもろくに気にする必要がなく、 セキュリティに対して、そこまでシビアにならずに済んでしまうことは想像に難くありません。 We

SonarQube を使用すると、静的解析により、コードに対するさまざまな指摘を受けることができます。この指摘を、コードレビューにも転用できたら、レビューコストもグッと下がって、いろいろ捗りそう。 というわけで実際にやってみました。 環境 SonarQube 5.2 SonarQube GitHub Plugin 1.1 GitHub (2016-02-09 現在) Travis CI (2016-02-09 現在) Maven 3.2.5 ORACLE Java 1.8.0_31 Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=192m; support was removed in 8.0 Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f4

老舗のコード静的解析ツールである SonarQube。 以前はビジュアライゼーションがイマイチで、個人的にもそこまで有用性を感じていなかったのですが、ここ最近のバージョンではこれが非常に改善されていました。 コードの可視化って、客観的なコード評価だけでなく、意外とオエライさんなんかへの説明にも便利なので、環境ひとつで解決できるならこれはサイコーのやつ。 というわけでひとつ構築してみる。 環境 Ubuntu 14.04.3 LTS ORACLE Java 1.8.0_66 Apache Maven 3.0.5 Git 1.9.1 SonarQube 5.2 $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION="Ubuntu 14.0

Java プロジェクトでのテストに、Groovy を使用するとすごく捗りますよね。 Spock まで採用していると、さらに捗りますね。 ただ、これらを使用しても捗らないものもあります。 それがテストデータの管理です。 これについては、みなさんどのようにしているのか、わたし自身も興味のあるところではありますが、ここではヒントになるかもしれない、アプローチのひとつをご紹介したいと思います。 #環境 以下のとおり。 Java 1.8.0_45 Groovy 2.4.3 Spock 1.0-groovy-2.4 DBUnit 2.5.1 #Spock の良さ Spock でのテストがなぜ捗り、快適なのか。 その助けのひとつとなっているのが where: の見通しの良さではないかと感じています。 多くの方が御存知のとおり、where: では、表形式でテストパターンを記述することができます。 以下のよ