はてなブックマーク

久々に作ったものをGithubへ公開しました。 元ネタは、よくImageMagickと比較される Imlib2 です。 これのJPEGヒント対応版が欲しくなったので探したのですが、どこにも見当たらなかったのでいっそのこと自分で作りました。 (対応についてはSmallLightのソースを参考にさせて頂きました) JPEGヒント(scale denom)とは まずJPEGヒントとは何かというと、ImageMagickやImlib2で利用しているlibjpeg ver.7以降で利用することの出来る scale_denom というスケーリング手法の俗称です。 これは簡単に言うと予めリサイズ後のサイズがわかっている場合に、元画像ロード時にメモリを効率よく確保しつつリサイズを高速化する手法です。 ImageMagickではこの機能をサポートしており、「-define jpeg:size=640x480

Dockerを使い始めて最初にひっかかるポイントとしては「WindowsにはDockerクライアントがない」という点です。 それは boot2docker を導入したところで同じで、Windows上では docker コマンドを結局直接実行することができません。 どの記事をみても、Windowsで利用する場合は boot2docker ssh してゲストOS(dockerコマンドを実行するための軽量Linux OS)から実行するようなことが紹介されています。 (次期Windows Serverに docker.exe が付属することが最近発表されましたが、まだいつになるかわかりません) これではせっかくdockerを導入しようにも「Macを利用しないといけないのか」というお話になり、 (Macにはdockerクライアントがあるので、dockerコマンドを直接OSX上で実行出来ます) 大多数

7/1にGradle 2.0がリリースされました。 複数の非推奨メソッドの削除が行われたため、 1.xで動作していたものが、2.0から動かなくなるケースが出てきました。 全てのケースを紹介しているとキリがないので、 今回は特に大きいと思われる 2 点の変更点のみ紹介させて頂きます。 変数の直接宣言の非サポート これは1.10くらいのときから警告が出るようになっていましたが、 具体的には以下のように変数を宣言するのが無効になりました。 1 2 project.myProperty = 'some value' assert myProperty == 'some value' これを解決するには、 extの名前空間で囲むか、defキーワードを指定してローカル変数として宣言します。 1 2 3 4 5 6 7 // ローカル変数として定義するか def myProperty = 'some v

Gradleでリソースファイルのフィルタリングを行う例は検索サイトで調べると結構多くヒットするかと思います。 ですが、その殆どが今回紹介する注意点について考慮されていないスクリプト記述をしています。 具体的に何を注意しなければならないのでしょうか。 以下にリソースフィルタリングの例を紹介します。 問題となるスクリプト 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 /** * ベースロジック */ project(':base') { apply plugin: 'java' apply plugin: 'eclipse' apply plugin: 'idea' processResources { from(sourceSets.main.resources.srcDirs) {

今回はGradleでよくハマるであろうポイントを集めたTIPSを11個紹介します。 01. 依存関係のバージョンが指定されたものにならない MavenからGradleへ移行した場合、おそらく誰もが最初に陥る問題かと思います。 端的に言うと、Mavenの pom.xml で指定したままの依存関係の設定をそのまま build.gradle へ移したとしても 最終的に取得される依存関係は殆どのケースで同じにはなりません。 これは「推移的依存関係」によって同じライブラリが存在した場合に優先されるバージョンがMavenとGradleでは異なるために起こります。 推移的依存関係とは簡単に説明すると、ある依存関係がさらに依存する関係のことを言います。 MavenでもGradleでもそれらを自動的に取得しようとしますが、 それらの中で使っている依存関係のgroupIdもartifactIdも同じだがバージ

前回の続きです。 Gradleのプロジェクトの設定が終わっただけでは当然ながら終わりません。 次はビルドが必要になります。 プロジェクト構成は前回の例をそのまま踏襲するとして、 実際にビルドをするときのコマンドを紹介します。 WARとJARのビルド WARのビルドは以下のコマンドで行います。 (build.gradle ファイルのあるディレクトリへ移動してコマンドを実行します) 1 gradle --daemon war なんとこれだけでWARのビルドが出来ます。 非常に簡潔です。 Gradleコマンドは立ち上がりが遅いのですが、上記のように —daemon というオプションを指定することでバックグラウンドに常駐するようになり、２回目以降のコマンドの立ち上がりが早くなります。 さて、前回のプロジェクト構成ですと、WARプロジェクトではないbatchプロジェクトが存在していたかと思います。

ちょっと前まではMavenでプロジェクトを構築している人も多かったですが、 Android StudioがGradleを採用してからはGradleによるプロジェクト構築にシフトしている人も増えてきました。 とはいえ、Web業界で古いシステムを保守・運用している方だとまだまだMavenメインの利用者が多いかと思いますので、 Mavenからの移行も含めた観点で記載して行きます。 Mavenと比較したGradleの利点 Mavenと比較したGradleの利点を簡単にまとめると以下のような感じです。 (この記事を執筆時のGradleの最新バージョンは 1.11 です) 記述量が圧倒的に少ない 記述言語がGroovyなのでJavaも使える。そのため比較的なんでも記述できる AntやMavenの機能も利用できる。特にAntはほぼすべての機能を利用可能。MavenはMavenプラグイン以外は殆ど利用可能

SQL高速化についてはいろんなサイトで取り上げられているので 今更取り上げる必要はないかと思っていましたが、 ふと最近仕事をしている中でハマっている人が多いポイントであると感じたため 改めて書いてみることにしました。 EXISTSが速いという誤解 EXISTSについて書かれたサイトを見ると、 「速い」というような記述を見かけることが多いかと思います。 しかし、これはあくまでサブクエリを組んだ場合に、INやイコールを使って比較するときと比べて速い場合が多いというだけであり、 EXISTSが速いというわけでは決してありません。 ハッキリ言ってしまうと、EXISTSを使うクエリは基本的に遅いです。 これは正確に言うと、EXISTSを利用するケースにおいて相関サブクエリが使われていることが原因で遅くなっています。 相関サブクエリとはどういうものか、以下にメンバー情報を格納した MEMBER テーブ