Kotlin で Groovy の Closure のインスタンスを取得・生成する方法 - mike-neckのブログ
G* Advent Calendar 2017 の 6日目は groovy.lang.Closure のインスタンスを Kotlin で生成・取得する方法です。 Groovy! 3分くらいで読み終われます。 groovy.lang.Closure のインスタンスを Kotlin で生成・取得する方法です。Kotlin コードの中で Closure を作って Groovy に渡すということを指しています。 生成方法 早速ですが生成方法です。 ある A というクラスがあって、 Closure の中で用いるプロパティを A から取得したい場合は次のような関数を書きます。 fun <A> closure(a: A, cl: A.() -> Unit): Closure<Unit> = object: Closure<Unit>(a) { fun doCall() = this@closure.cl
JetBrains系IDEと各種ITSとGitを連携してスマートに作業する - mike-neckのブログ
JetBrainsユーザーグループにて「IntelliJとYouTrack」というタイトルにて発表してきましたが、グダグダな発表をしたのでちゃんとまとめた記事を書きます。 jbugj.connpass.com 要点 JetBrains系IDEでは、標準に付属しているツールを用いることで、スマートに作業ができます。(なお、一部のIDEについてはリポジトリーからインストールしないといけなさそうです(GoglandにはTaskManagementプラグインが付属していないようだった)) Task Management プラグイン ITS(イシュー管理システム)とIDEを連携させてTask と Context を管理できるプラグイン Task - イシュー管理システムのチケットに該当する、作業の単位をあらわす Context - 開いているファイルのカーソルの位置や、プロジェクトツリーの開いている
JSUG勉強会 2017 - 3 〜ドメイン駆動設計 powered by Spring のメモ - mike-neckのブログ
JSUGの勉強会に参加したので、そのメモ。 jsug.doorkeeper.jp 資料は公開されるだろうから、ここでしか聞けないことを中心にメモ(ツイート)したつもりだが、資料に盛り込まれている可能性は十分にある。なお、資料は以下の通り。 ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring from 亨 増田 www.slideshare.net 個人的な感想 ドメイン駆動のセッションや話は「ドメイン駆動はいいぞ」という感じで抽象的な話になりがちなことが多いのだが、今回はフレームワークが限定されたこともあってどのようなオブジェクトをどのように作っていくという具体的な話が聞けて満足だった ビジネスルールとドメインロジック ビジネスルール(契約・法令・明文化されていない商習慣)などがソフトウェア開発の分析対象(もちろん、ビジネスルールがゲームのルールだったりサー
Rule Based Model ConfigurationのManagedインターフェースを生成するgradle pluginを作った。 - mike-neckのブログ
なるべく、わからないようにリリースしたつもりだったのですが、さすがGradleの日本の第一人者、綿引さんにすぐに見つかってしまいました。 @mike_neck さんのプラグインがポータルにあがっておる。https://t.co/YOdb34pLcK #jggug— Takuma Watabiki (@bikisuke) 2015, 8月 15 Gradle - Plugin: org.mikeneck.rule-based-model-generation Rule Based Model Configurationのインターフェースの制約 これ、結構ドキュメントがしっかりしていないので、インターフェースを書くのに、難しいところがあったりします。 それを簡単に解決するプラグインです。 まあ、webアプリを作ってる人にはほとんど関係無いです。 あくまでgradle pluginを作ってる人に
Gradle Payara plugin(unofiicial)をリリースしました - mike-neckのブログ
meets GradleのPayaraプラグイン(unofficial)をリリースしました。 org.mikeneck.payara-pluginで詳細な情報が記述されています。 また、レポジトリーはこちらです。 github.com 使い方 プラグインの導入 以下のビルドスクリプトをbuild.gradleの先頭に記入します。 すべてのバージョンのGradleで利用可能な記述方法 buildscript { repositories { maven { url "https://plugins.gradle.org/m2/" } } dependencies { classpath "gradle.plugin.org.mikeneck:payara-plugin:0.0.2" } } apply plugin: "org.mikeneck.payara-plugin" Gradle2.
Gradle-2.9-rc1が11月4日に利用可能になってました #gradle - mike-neckのブログ
10月1日にGradle2.8-rc1が出たという記事を書いてから、1ヶ月、Gradle2.9-rc1が2015/11/4に出ています。 mike-neck.hatenadiary.com というわけで、いつもどおりリリースノートの意訳 Gradle TestKitがもっと便利になった Gradle TestKitがGradle2.6で出てからプラグインのテストが簡単になったわけですが、今回のリリースでもっと便利になりました。TestKitはデバッグ、クロスバージョンテスト、ビルド成果物を取得することができるようになりました。 より簡単になった機能テスト Gradle TestKitはプログラム的にGradleビルドを走らせて、プラグインの検証を行うわけですが、テスト対象のクラスなどに対してデバッガーを割り当てることを容易にしました。 Gradleビルドの正確なシミュレーションを提供するた
Gradle3におけるJavaプロジェクトのビルド入門(1) #gradle - mike-neckのブログ
Gradleは元々の作りが非常にブラックボックスなため、設定されたオブジェクトのライフサイクルがわかりづらいなどの問題があり、Gradle3に向けて、それを修正している最中です。その中核となるのがRule Based Model Configurationという仕組みです。 その仕組については以前にもエントリーを書いているので、そちらを参照してください。 mike-neck.hatenadiary.com 基本的な考え方は 値オブジェクトの生成(プラグインが値オブジェクトを生成する) 値オブジェクトの設定(ユーザーがオブジェクトの中の値を変更できる/mutableなオブジェクト) 値の利用(ユーザーもプラグインも値を変更できない/immutableなオブジェクト) という流れにそって設定を記述していくという考え方です。 では、Javaプロジェクトはどのように変わっていくかを今回は簡単に説明
今 gradle.org に何が起きているのか？ - mike-neckのブログ
gradle,org に何か異変っぽいものが起きているらしいです。 Gradleさんどうなってしまったの https://t.co/L1ssx97cY4— Yasuharu Nakano (@nobeans) 2015, 10月 26 僕も昨晩確認してみたところ、こんなページになっていました。 @saba1024 なんか、直ってた pic.twitter.com/aA7ebZzNlG— Shinya Mochida (@mike_neck) 2015, 10月 26 何だろうと憶測で思いを巡らすのも面倒なので、聞いてみました。 discuss.gradle.org で、マーク・ビエイラさんが「Gradlephant」(gradle象)と「Build Happiness」について知りたかったら、読んでねと紹介されたのがこちらのページ。 gradle.org 簡単に訳してみましょう。 grad
Gradleからdockerを起動して分散テストさせてみた #gradle #docker - mike-neckのブログ
昨日のエントリーの続きです。 mike-neck.hatenadiary.com Gradle万能派の僕には、納得がいかなかったので、最後までやってみることにしました。 切り捨てたこと まず、分散テストは何が目的なのか考えると、テスト結果をマージすることが目的なので、以下のことは切り捨てました。 dockerの外でコンパイルしたクラスファイルの共有(昨日のドハマリその2により、共有してもコンパイルしてしまうので諦めた) srcディレクトリーの共有(Javaファイルを生成するタスクがある場合はsrcディレクトリーの共有をすると、各コンテナがJavaファイル生成を行ってしまうので、諦めた) 【2015/10/20 12:19追記】 つまり、コンパイル結果を共有しても再コンパイルされるので、buildディレクトリーの共有は諦めました この結果、妥協するのは次の点です。 各コンテナでソースコード生
Gradle3.0で一部が激しく変更されるっぽい感じが漂う件 - mike-neckのブログ
gradleは単なるタスク実行基盤ツールですが、僕が3～4年前に人から「gradleなんてクッソマイナーで型もないgroovy(偏見)のツールなんて誰が使うか」と言われてた頃から比べると、Androidでの採用もあり、かなり普及した感があります。 さて、そんなだいぶ馴染んできたgradleですが、gradle3.0のデザインドキュメントを読んでいると、Javaだけのプロジェクトならそれほど変わらないかもしれないのですが、nativeと一緒のプロジェクトにおいては激しく変更される(より親密になる)ような感じがあります。 Gradle2.4で新しい(というかバイナリービルドでは使われていた)機能のドキュメントにその変更について若干見え隠れしています。これは以前書いたエントリーを参照下さい。 mike-neck.hatenadiary.com 【補足】なお、この記事は5月に書いたものですが、すで
gradle2.4のRule based model configurationがユーザーにとって地味に嬉しい - mike-neckのブログ
gradle2.4のリリースノートを先日眺めていたらRule based model configuration improvementsという記述があって、そのユーザーガイドのコードを試してみました。 モデル モデル(POJO)をあらわすインターフェース。Managedアノテーションを付与することによってモデルであることをあらわす。このアノテーションが付与できるのはインターフェースかabstractクラスでないといけないらしい。というのも、gradleが場面場面でオブジェクトの可変性・不可変性を管理しているからのようです。 package sample; import org.gradle.model.Managed; @Managed public interface SampleModel { void setFrom(String from); String getFrom();
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
