この記事の前提事項

綺麗で正しくきちんとした資料作りを目的としておらず、使い捨て、走り書きの絵・図を書く、というのが目的となっています。

もしきちんとした図をツールで書きたいのであれば、以下がオススメです。

Flow Chart Maker & Online Diagram Software
Cacoo（カクー）: アイデアを今すぐこのキャンバスに

綺麗に図を書けるし、共有も簡単にできます。

雑感

最近とにかく絵やDBの図をノートに書きまくるので、キャンパスノートの消費が激しいです。1冊2ヶ月くらいで使いきってしまいます。（少ないかな）

図や絵は大きく、表も大きめに書くので、ますます消費スピードは早くなります。1回の説明で1ページ使ってしまう程の雑さ加減です。勿体無いノートの使い方をしてる自覚はあるのですが、勿体云々よりも「もっと速さを・・！もっともっと速く！！」という事を中二っぽく心がけているので、雑に沢山書いています。英単語も数文字書けば後は口頭でフォローできるから単語の末尾部分はもう何書いてるか解らないし、漢字もごにょごにょって書いて何書いてるか解らない部分も多々有りますが、重要なのはそこではなく、概要・構造・全体像をお絵かきで把握して貰う事にあります。

以前は全くお絵かき説明をせず口頭ばかりだったのですが、試しにお絵かきしてみたら、これが全く何も書けなくて愕然としました。単語をポロポロ並べるくらいしかできないのです。そこで始めて「ああ、自分は構造というか、全体像を他人に説明できる程理解して無かったんだ」という事をはっきり認識しました。それから他人に説明する時はノートを使ってババっと手書きで説明する機会が増えました。実際絵を書いてみると、「この位置にこの表を書いてしまうと、他の要素が書けない」等、複数の要素の関連を意識するようになって、自然と全体像を意識するようになります。

最近有名なベンチャー系のIT企業でもトヨタのカンバン方式を採用していたり、ホワイトボードに付箋をペタペタしたり、結構アナログな方式も見直されてきていますね。
www.publickey1.jp
タスク管理ツールのredmineやjiraにもかんばんが現れましたが、ツールに頼りきるのではなく、こうしたホワイトボードに付箋を張る企業も沢山あります。

ツールを使おうとすると「こういう設定にしておかないと後で拡張する時に困る！」だの「よし！皆で最強のワークフローを最初に作ろう！運用はそれからだ！」だの「他のデータとの連携が云々！」とかいってそもそもスタートすらせず終わってしまう場合が多いので、アナログ方式で「とりあえずやってみる」というのも重要かもしれませんね。特にプログラマーの場合は「真っ先に行動に移す」よりもそもそもの設計から考えだしてしまい、収集がつかずに企画がポシャる可能性が高いので尚更です。

世間でも言われていますが、デジタル一辺倒にならず、デジタルとアナログを上手く使い分けて取捨選択していきたいですね。特にIT企業ではデジタル色で染まっている傾向が強いので、ノートに文字や図や絵を書いたり、付箋で管理してみたり、アナログのメリットについてもう一度考えていきたいですね。

大至急パターン

大至急は何故無能なのか

さて、簡単に大至急パターンを見たところで、何故大至急が無能なのかを考えてみます。

こんな事があったら要注意

• タスクの優先度全てが「至急」や「急ぎ」しか設定しない。
• 定期的に音沙汰が無くなり、ある日突然大至急と依頼をする。
• メールの件名に「大至急」等と付けてしまう。
• 枕詞が「大至急」。
• 我が社は「急ぐ社風」です。

こんな場合は要注意です。IT業界の場合は、redmine等のタスクが全部「急いで」等となっている人は確実に「大至急先輩」です。

大至急と言われたら

大至急の理由を説明して貰おうとしても無駄な場合がほとんどです。そもそも管理ができないから「大至急」と口にしているので、急ぐ正当な理由をまともに説明できません。

大至急と言われた場合は、いつも通りに仕事をすればいいのです。相手は「大至急」という言葉に安心感を覚える場合が多いので、いつも通りのスピードで仕事をして「◯◯様のご依頼だったので、特別に大至急対応させて頂きました！」等とプレミア感を醸しだして返すだけで満足してしまう場合もあります。そもそも大至急仕事をしてまともな品質になる訳がないので、いつも通りの仕事をすれば、結果としてそれが最速で高品質になる場合がほとんどです。どうしても正当な理由があって急がざるを得ない場合は、◯◯という要件を削るか、ここを次期フェーズに遅らせる事ができれば速くなります、等と条件を付けて交渉するといいかと思います。

↑のように対応しましたと上司に報告して、もし上司が「もっと急げるだろ！大至急ぅぅぅ！」と返してきても「この作業は十分最適化されており、これ以上急ぐと不用意に品質を劣化させるだけでクレームが来ます。仮に急げてもコストに見合いません」等と冷静に感情的にならずに返しましょう。それで上司が納得しないのであれば、某企業の「チャレンジをお願いしたい」のと同じなので、最悪な結果が待っているかもしれません。

雑感

客商売の場合は大至急パイセンはクレーマーとして対応したりで大変なようですね。下手な対応するとクレームが入って今度は上司から「大至急！」と依頼されたりするようで、本当に大変そうです。

大至急という言葉を口にすればする程、自分の無能さを強める結果になります。いつも「大至急！」と言ってしまうと、周りから「あいついつも急いでんな」という評判が広まるので、「はいはい急ぐ急ぐwww」等と徐々に雑な対応されるようになり、狼少年のような状態になります。終いには本当に急ぐ必要に迫られた時に「大至急！」と依頼しても「大至急パイセンが急いでいらっしゃいまーすwwwﾌﾟﾌﾟﾌﾟwww」と相手にされなくなり、破滅するしかない状況に愕然とするかもしれません。

このように「大至急」という言葉は「悪」や「マイナス」のイメージを連想させるので周りへの心証も非常に悪く、周りからの評価を下げたり孤立したりする事は必至です。まさに百害あって一利なしなのが「大至急」なのです。

大至急と思わず言ってしまう場合はまず「何故大至急なのか」を考え、大至急にならないために状況を整理したり、逆算してスケジュールを検討したり、急ぎタスクが発生しそうかどうかを事前に検討して動くようにすると、徐々に「大至急」の理由がなくなっていき、最後には言わなくなります。その頃には無能から有能にクラスチェンジしている可能性が高いので、きっと周りからの信頼も勝ち取り、狼少年ではなくなっているはずです。

clickイベントで取得できる値

雑感

ブラウザの実装の問題だとすると、この問題は恐らく他のFWにも同じ事が言えると思うのですが、どうなのでしょうね。

正直こういうブラウザの実装によって挙動が変わるとか、IE6問題の再来のようで死ぬほどアホくさいです。本来開発者が集中するべきところはそこではないので、なんとかして欲しいものですが、どうにもならないのでしょうね・・・

AngularJS　アプリケーションプログラミング

• 作者:山田祥寛
• 出版社/メーカー:技術評論社
• 発売日: 2015/08/19
• メディア:大型本
• この商品を含むブログ (2件) を見る

速習ECMAScript6: 次世代の標準JavaScriptを今すぐマスター！

• 作者:山田祥寛
• 出版社/メーカー: WINGSプロジェクト
• 発売日: 2015/08/28
• メディア: Kindle版
• この商品を含むブログを見る

1, gmailを開く

まずは対象のgmailをwebブラウザで開きます。

2, 世代管理用のラベルを作成する

世代管理専用のラベルを作成します。ここでは「30日で削除」という名前でラベルを作ります。

3, 世代管理したいメールをフィルタで「30日で削除」ラベルに振り分ける

世代管理したいメールのフィルタを作成し、前述で作成したラベルに振り分け設定をします。

4, Googleドライブを開く

先ほど作成したフィルタに対して、Apps Scriptを作成・適用したいので、Googleドライブを開きます。

5, Googleスプレッドシートを新規作成する

Apps Scriptを作成するのにGoogleスプレッドシートが必要なので、新規作成します。

6, スプレッドシートのファイル名を付ける

初期状態だと「無題のドキュメント」となっているので、適当にファイル名をつけます。

7, スクリプトエディタを開く

メニューバー → ツール → スクリプトエディタ と開きます。

8, スクリプトエディタが開く

スクリプトエディタを開くと、以下のような画面になります。既に雛形のメソッド「MyFunction」がありますが、これは使いません。

9, スクリプトを編集して保存する

以下のスクリプトをコピペして貼り付けて下さい。

function expire30days() {var day = 30;
  var label = '30日で削除';
  var threads = GmailApp.search('older_than:' + day + 'd -is:starred label:' + label);
  for (var i = 0; i < threads.length; i++) {
    threads[i].moveToTrash();
  }}

もし「30日で削除」というラベル名にしなかった場合は任意に「var label = 'xxx'」の部分を編集して下さい。

編集できたら「保存」ボタンをクリックします。

10, プロジェクト名を設定して保存

プロジェクト名の入力を求められるので、適当に「gmail」と入力してOKボタンをクリックします。

11, スクリプトを実行してみる

作成したスクリプトを早速実行してみましょう。▶ボタンをクリックするとスクリプトを実行できます。

12, 実行権限を付与する

Apps Scriptからgmailを操作するには、gmailに対して「Apps scriptで操作される事を許可する」必要があります。

13, 実行を許可する

「許可」ボタンをクリックして許可します。

14, スクリプトが実行される

許可ボタン押下後、元のスクリプト画面に戻り、自動的にスクリプトが実行されます。「30日で削除」ラベルに沢山メールがある場合、削除に時間がかかります。

2016/01/02時点ではApps Scriptは6分までしか実行できないようです。スクリプトを実行してから6分経過すると強制的にスクリプトが停止します。
Quotas for Google Services  |  Apps Script  |  Google Developers

15, トリガーを作成する

作成したApps Scriptを定期的に自動実行して欲しいので、トリガー(cronみたいなの)を作成します。

16, トリガーを追加する

初期状態だとトリガーが空っぽなので、リンク部分をクリックしてトリガーを追加します。

17, トリガーを作成して完了

どのメソッドを、どんなタイミングで定期実行するかを決める事ができます。日タイマーを選択すると、毎日自動実行してくれます。

これでgmailに作成した「30日で削除」ラベルに振り分けられたメールを、expire30daysメソッドを毎日定時実行して削除する世代管理が設定できました。

雑感

会社の場合は使用するメールアドレスが1個の場合がほとんどだと思いますが、個人で使うメアドは複数の場合が多いですよね。すると必然的にMail.appやThunderbird等のメーラーを使う機会が増えます。

最近だと大抵imapでメールを同期すると思いますが、メール数が多いと同期に時間がかかったりしてPCが重くなったりする事もあります。なので、可能な限り不要なメールは削除していく事をオススメします。

少ないメールアカウントで少ないメール数なのが理想なのですが、私の場合は個人で使うメールアドレスが5アカウントもあるので、大量のメールをimapで同期しています。これが最近メールの掃除をしていなかったせいか、Mail.appが非常に重く困っていました。(メモリは32GByte搭載）そこで今回メールの大掃除をするべく、この記事を書いたわけです。

正直gmailが正式にマルチアカウントの同時表示に対応してくれれば、もうローカルでメーラーを起動する機会もなくなるので、対応して欲しいですね。

現象

以下はチュートリアルのjsonを返すコントローラーです。

import java.util.concurrent.atomic.AtomicLong;

import org.springframework.http.MediaType;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

import com.music.anime.tree.json.Greeting;

@RestControllerpublicclass GreetingController {

    privatestaticfinal String template = "Hello, %s!";
    privatefinal AtomicLong counter = new AtomicLong();

    @RequestMapping(value = "/greeting", method = RequestMethod.GET, produces = MediaType.APPLICATION_JSON_VALUE)
    public Greeting greeting(@RequestParam(value = "name", defaultValue = "World") String name) {
        returnnew Greeting(counter.incrementAndGet(), String.format(template, name));
    }
}

しかし、jsonではクロスドメインの壁を超えられないので、jsonpを返したいところです。

そこで以下のようなクラスとメソッドを用意すると、親クラスのjsonpQueryParamNamesに「callback」というパラメータが設定されます。この値が設定されると「callback」というパラメータがある場合はjsonpになるよ、という処理がされます。

import java.io.IOException;

import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.http.converter.json.Jackson2ObjectMapperBuilder;
import org.springframework.http.converter.json.MappingJackson2HttpMessageConverter;
import org.springframework.http.converter.json.MappingJacksonValue;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.servlet.mvc.method.annotation.AbstractJsonpResponseBodyAdvice;

import com.fasterxml.jackson.core.JsonGenerator;
import com.fasterxml.jackson.databind.ObjectMapper;

@ControllerAdvicepublicclass JsonpAdvice extends AbstractJsonpResponseBodyAdvice {

    public JsonpAdvice() {
        super("callback");
    }
}

しかしこの状態でjsonpを出力してみると、何故か以下のようなjsonpが返ってしまいます。
http://localhost:8080/greeting?callback=test

/**/test({"id":1,"content":"Hello, World!"});

何故か先頭に「/**/」というコメントが挿入されてしまいます。

正直これではカッコ悪過ぎますね。

対応

何故先頭に謎ものコメントが挿入されるのかあまり解ってないのですが、以下のようなメソッドを定義しておくと、謎の「/**/」を削除する事ができます。

import java.io.IOException;

import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.http.converter.json.Jackson2ObjectMapperBuilder;
import org.springframework.http.converter.json.MappingJackson2HttpMessageConverter;
import org.springframework.http.converter.json.MappingJacksonValue;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.servlet.mvc.method.annotation.AbstractJsonpResponseBodyAdvice;

import com.fasterxml.jackson.core.JsonGenerator;
import com.fasterxml.jackson.databind.ObjectMapper;

@ControllerAdvicepublicclass JsonpAdvice extends AbstractJsonpResponseBodyAdvice {

    public JsonpAdvice() {
        super("callback");
    }

    @Beanpublic MappingJackson2HttpMessageConverter MappingJackson2HttpMessageConverter(ApplicationContext ctx) {
        ObjectMapper mapper = Jackson2ObjectMapperBuilder.json().applicationContext(ctx).build();
        returnnew MappingJackson2HttpMessageConverter(mapper) {
            @Overrideprotectedvoid writePrefix(JsonGenerator generator, Object obj) throws IOException {
                if (!(obj instanceof MappingJacksonValue))
                    return;
                String funcName = ((MappingJacksonValue) obj).getJsonpFunction();
                if (funcName != null)
                    generator.writeRaw(funcName + "(");
            }
        };
    }
}

MappingJackson2HttpMessageConverterメソッドがあると、
http://localhost:8080/greeting?callback=test
のURLで以下の正常なjsonpが返るようになります。

test({"id":1,"content":"Hello, World!"});

これでようやくまともなjsonpを生成する事ができます。

www.bunkei-programmer.net

はじめてのSpring Boot―「Spring Framework」で簡単Javaアプリ開発 (I・O BOOKS)

posted with カエレバ

槇 俊明 工学社 2014-11

Amazonで探す

楽天市場で探す

オフィスグリコとは

オフィスグリコのサービススタッフが定期的にオフィスを訪問し、代金の回収や商品の補充・賞味期限管理等を行います。 オフィスの従業員の方が各自で利用したい時に、BOX、冷凍冷蔵庫から商品を取り出し、代金を備え付けの貯金箱に投入して頂くシステムになります。 BOX、冷蔵庫の設置費用は不要、また盗難、紛失などによる金銭的補償も求めませんので、安心してご利用頂けます。

https://www.glico.com/jp/enjoy/service/officeglico

オフィスおかんとは

オフィスおかんはオフィスにいながら美味しくて、健康的な食事を
24時間いつでも食べることができるぷち社食サービスです!

https://office.okan.jp/service/

両方ともセルフレジ形式で、商品を持っていく時に集金ボックスにお金を投入するシステムです。

しかしですね・・・・

利用者の支払額が明らかに少ない

という状態なのです。なんとほぼ毎月赤字が出ているという驚愕の状態です。

オフィスグリコの場合、例えば100円のおかしが10個有るとして、10個売れたらカエルの口の集金箱に合計 10 ✕ 100円 ＝ 1,000円 入ってないといけませんよね？しかし1,000円以下しか入っていないのです。

という事は、誰かがお金を払わずに持って行ってしまっている、という事になります。なんという残念な事なのか・・・

では、何故赤字になるのでしょう？

環境

原因の推測の前に、環境の説明です。

赤字理由の推測

雑感

あまりに赤字が続くので、オフィスグリコとオフィスおかんとの契約を解除せざるを得ないような危機的状況になってしまっています。

100円玉と50円玉を間違えて投入するケースはあり得るんですが、それなら逆に商品価格より多い金額を投入する間違いがあっても良いはずですよね。しかし、多かった事は一度もないようです。必ず少なくなります。そう考えると、うっかり投入ミスの可能性は低いかな、と。なら、「後で払うから！」等の幼稚な悪意満載のミスしか無いのではないか、と考えています。

これらの対策として「対面式販売に限定する」等の意見がでると思いますが、対面式にすると、誰かがレジ係りをする＝人件費が発生するので、おかし・惣菜の値段以上のコストが発生するのですよね。また、レジ係りの人がいない場合、例えば定時後・病欠・お昼休憩中・深夜・早朝の場合はコンビニに行かざるを得なくなってしまいます。それだとオフィスグリコ・おかんのメリットが薄れてしまいます。

自販機タイプもありますが、自販機を置くスペースって結構が必要になるし、ランニングコストが高かったりするので、導入のハードルは高い。
www.glico.com

最小限の人件費・ランニングコストでおかし・惣菜等を気軽に購入できるのがこういうサービスの強みなので、できるだけルールは緩く、便利であって欲しいですね。みなさんの職場では赤字は発生して無いですかね？もし赤字を解消するいい方法があれば、是非教えて欲しいです！

ネスカフェ ゴールドブレンド バリスタ ホワイト PM9631

posted with カエレバ

ネスレ日本

Amazonで探す

楽天市場で探す

よくあるエラーケース

MySQLのバージョンは5.5〜5.7が対象になります。この記事の事を実際に試したい場合は、docker-machineでmysqlのコンテナを作るとよいです。以前書いたこちらの記事も合わせてご覧下さい。
www.bunkei-programmer.net

MySQLの設定はこんな感じです。

 mysql> showvariableslike'char%';
＋--------------------------＋----------------------------＋
｜ Variable_name            ｜ Value                      ｜
＋--------------------------＋----------------------------＋
｜ character_set_client     ｜ utf8mb4                    ｜
｜ character_set_connection ｜ utf8mb4                    ｜
｜ character_set_database   ｜ utf8mb4                    ｜
｜ character_set_filesystem ｜ binary｜
｜ character_set_results    ｜ utf8mb4                    ｜
｜ character_set_server     ｜ utf8mb4                    ｜
｜ character_set_system     ｜ utf8                       ｜
｜ character_sets_dir       ｜ /usr/share/mysql/charsets/ ｜
＋--------------------------＋----------------------------＋

文字コードがutf8mb4のデータベースを作成します。

createdatabase hoge charset utf8mb4;

droptable if exists tbl_table_charset;
createtable tbl_table_charset(
    v varchar(10)
)engine=innodb charset=latin1;

mysql> select * from tbl_table_charset where v = 'あ';
ERROR 1267 (HY000): Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8mb4_general_ci,COERCIBLE) for operation '='

mysql> insertinto tbl_table_charset values('あ');
ERROR 1366 (HY000): Incorrect string value: '\xE3\x81\x82'forcolumn'v' at row1

mysql> update tbl_table_charset set v = 'あ';
Query OK, 0rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0

mysql> insertinto tbl_table_charset values('a');
Query OK, 1row affected (0.00 sec)

mysql> update tbl_table_charset set v = 'あ';
ERROR 1366 (HY000): Incorrect string value: '\xE3\x81\x82'forcolumn'v' at row1

droptable if exists tbl_col_charset;
createtable tbl_col_charset(
    v varchar(10)character set latin1
)engine=innodb charset=utf8mb4;

mysql> select * from tbl_col_charset where v = 'あ';
ERROR 1267 (HY000): Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8mb4_general_ci,COERCIBLE) for operation '='

ERROR 1118 (42000) at line 1: Row size too large. The maximum row size for the used tabletype, not counting BLOBs, is8126. You have tochange some columnstoTEXTor BLOBs

で、何が問題なのか

先ほどのコンソールを見て貰うと解りますが、selectしただけでエラーが発生してしまう点にあります。つまり、アプリケーションからlatin1等のマルチバイト非対応カラムに対してマルチバイトで検索するwhere句を発行されると即エラーになるのです。と言うことは、バリデーション処理が必須になるという事に繋がります。

例えば「商品コード」というvarcharで英数字が入るカラムがあったとして、通常ならそのカラムが「あああ」等と検索されてもエラーにならず、0件の結果が返ります。しかしこの商品コードがlatin1等である場合、「あああ」と検索された場合はSQLExceptionが確定してしまうので、シングルバイトの入力チェックバリデーションが必須になります。商品コードは最初はutf8mb4だったがいつからかlatin1に変更されていて、最近「Illegal mix of collations (latin1_swedish_ci,IMPLICIT)」なんてエラーが出るんだけど、なんぞこれ？というケースがあります。今まで必要無かったバリデーションが必要になってしまうのです。

雑感

このお話、残念ながらノンフィクションです・・・

antelopeとbarracudaの違いも知らず、row_type？何それ？という時代に設計したテーブルが段々と肥大化してしまい、ついにantelope＋utf8mb4のInnoDBテーブルのサイズの限界に達してしまい、大きいデータが来た時にのみエラーが出てしまうという状況に遭遇し、以下のエラーに悩まされました。

ERROR 1118 (42000) at line 1: Row size too large. The maximum row size for the used tabletype, not counting BLOBs, is8126. You have tochange some columnstoTEXTor BLOBs

この制限は確かMySQL5.5以降から発生するので、「joinするの面倒だから1テーブルに全項目を押し込めようぜ！」等と横着をしたりせず、適宜テーブルを分割するようにすれば、このエラーは起きにくくなります。また、もしInnoDBファイルフォーマットがBarracudaではなくAntelopeになっているのであれば、できるならBarracudaに変更し、create tableする際は「row_format=dynamic」を付けると、こういった制限に引っかかりにくくなります。現在のInnoDBファイルフォーマットは以下で確認可能です。

mysql> showvariableslike'innodb_file_format';
+--------------------+-----------+
| Variable_name      | Value     |
+--------------------+-----------+
| innodb_file_format | Antelope  |
+--------------------+-----------+

この辺りを疎かにしていると私のようにアホな目に合うので、手遅れにならない内に確認した方がいいでしょう。

検証環境

• iMac Retina 5K
• idk v1.8.0_25
• Spring Tool Suite Version: 3.7.2.RELEASE
• Spring boot v1.3.1.RELEASE
• docker toolbox（docker v1.9、docker-compose v1.5.2）
• Google chrome ＋ Live reload plugin（LiveReload - Chrome Web Store）

Live Reload

変更部分のみ差分読み込みする形ではなくリスタートなので、プロジェクトが大きくなるとリスタート処理がちょっと遅くなりそうです。今後に期待ですね。

使い勝手に関しては「ほ〜ん、凄いな」と思ったのですが、ちょっと困った事がありました。

それはですね・・・

今ライブリロードがonなのかoffなのか解りづらい

点です。アイコンが非常に解りづらいのです。以下をご覧下さい。真ん中のアイコンがライブリロードpluginです。

1個目の画像がオンで、2個目の画像がオフです。アイコン真ん中が◯か●かの違いです。これは見辛い・・・・

Remote update

個人的に非常に気になる機能だったので、ちょっと試してみました。

気づいた点は以下です。

• 更新速度は遅い。
• 更新対象URLが1個しか設定できない。

という点です。

リモートのjarを更新するために、ローカルのソースが更新されたかどうかをポーリングしているようで、このポーリングのデフォルト値は1000ms、つまり1秒です。
Appendix A. Common application properties
「spring.devtools.restart.poll-interval=100」等と設定すれば、ポーリング速度を早める事が可能です。ポーリングは調節可能ですが、問題なのは更新速度です。スッカスカのプロジェクトで1文字変更して、ローカルのdockerコンテナにリモートアップデートするのに以下のように約5秒かかりました。ちょっと遅いかな？と感じました。ローカルのdockerに対してこの更新速度だと、外部サーバに対して行ったら更に遅くなる事は間違いないでしょう。

22:42:45.790 [File Watcher] INFO  o.s.b.d.r.c.ClassPathChangeUploader - Uploaded 2 class resources
22:42:50.820 [pool-1-thread-1] INFO  o.s.b.d.r.c.DelayedLiveReloadTrigger - Remote server has changed, triggering LiveReload

更新速度よりも「更新対象URLが1個しか設定できない」という方が問題かと思います。

nginx-proxy:image: jwilder/nginx-proxy
  ports:- "80:80"- "443:443"volumes:- "/var/run/docker.sock:/tmp/docker.sock:ro"restart: always
redis:image: redis
  expose:- 6379h2:image: making/h2-server
web-pc:image: tree-tips/web-pc
  links:- redis
    - h2
  expose:- "8080"environment:- VIRTUAL_HOST=www.hoge.local
    - VIRTUAL_PORT=8080
  command:>
    --spring.datasource.url=jdbc:h2:tcp://${H2_PORT_1521_TCP_ADDR}:${H2_PORT_1521_TCP_PORT}/~/hoge

nginx-proxy:image: jwilder/nginx-proxy
  ports:- "80:80"- "443:443"volumes:- "/Users/tree/docker/hoge/certs:/etc/nginx/certs:rw"- "/var/run/docker.sock:/tmp/docker.sock:ro"restart: always

server {
    server_name _; # This is just an invalid value which will never trigger on a real hostname.
    listen 80;
    access_log /var/log/nginx/access.log vhost;
    return 503;
}
upstream www.hoge.local {
            server 172.17.0.5:8080;
}
server {
    server_name www.hoge.local;
    listen 80 ;
    access_log /var/log/nginx/access.log vhost;
    return 301 https://$host$request_uri;
}
server {
    server_name www.hoge.local;
    listen 443 ssl http2 ;
    access_log /var/log/nginx/access.log vhost;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA;
    ssl_prefer_server_ciphers on;
    ssl_session_timeout 5m;
    ssl_session_cache shared:SSL:50m;
    ssl_certificate /etc/nginx/certs/www.hoge.local.crt;
    ssl_certificate_key /etc/nginx/certs/www.hoge.local.key;
    add_header Strict-Transport-Security "max-age=31536000";
    location / {
        proxy_pass http://www.hoge.local;
    }
}

server {
    server_name www.hoge.local;
    listen 80 ;
    access_log /var/log/nginx/access.log vhost;
    return 301 https://$host$request_uri;
}

23:21:53.024 [File Watcher] INFO  o.s.b.d.r.c.ClassPathChangeUploader - Uploaded 2class resources
Exception in thread "File Watcher" java.lang.IllegalStateException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at org.springframework.boot.devtools.remote.client.ClassPathChangeUploader.onApplicationEvent(ClassPathChangeUploader.java:107)
	at org.springframework.boot.devtools.remote.client.ClassPathChangeUploader.onApplicationEvent(ClassPathChangeUploader.java:56)
	at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:163)
	at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:136)
	at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:381)
	at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:335)
	at org.springframework.boot.devtools.classpath.ClassPathFileChangeListener.publishEvent(ClassPathFileChangeListener.java:68)
	at org.springframework.boot.devtools.classpath.ClassPathFileChangeListener.onChange(ClassPathFileChangeListener.java:64)
	at org.springframework.boot.devtools.filewatch.FileSystemWatcher.fireListeners(FileSystemWatcher.java:230)
	at org.springframework.boot.devtools.filewatch.FileSystemWatcher.updateSnapshots(FileSystemWatcher.java:223)
	at org.springframework.boot.devtools.filewatch.FileSystemWatcher.scan(FileSystemWatcher.java:183)
	at org.springframework.boot.devtools.filewatch.FileSystemWatcher.access$100(FileSystemWatcher.java:41)
	at org.springframework.boot.devtools.filewatch.FileSystemWatcher$1.run(FileSystemWatcher.java:150)
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
	at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1917)
	at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:301)
	at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:295)
	at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1471)
	at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212)
	at sun.security.ssl.Handshaker.processLoop(Handshaker.java:936)
	at sun.security.ssl.Handshaker.process_record(Handshaker.java:871)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1043)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1343)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1371)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355)
	at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)
	at org.springframework.http.client.SimpleBufferingClientHttpRequest.executeInternal(SimpleBufferingClientHttpRequest.java:80)
	at org.springframework.http.client.AbstractBufferingClientHttpRequest.executeInternal(AbstractBufferingClientHttpRequest.java:48)
	at org.springframework.http.client.AbstractClientHttpRequest.execute(AbstractClientHttpRequest.java:53)
	at org.springframework.http.client.InterceptingClientHttpRequest$InterceptingRequestExecution.execute(InterceptingClientHttpRequest.java:93)
	at org.springframework.boot.devtools.remote.client.HttpHeaderInterceptor.intercept(HttpHeaderInterceptor.java:57)
	at org.springframework.http.client.InterceptingClientHttpRequest$InterceptingRequestExecution.execute(InterceptingClientHttpRequest.java:85)
	at org.springframework.http.client.InterceptingClientHttpRequest.executeInternal(InterceptingClientHttpRequest.java:69)
	at org.springframework.http.client.AbstractBufferingClientHttpRequest.executeInternal(AbstractBufferingClientHttpRequest.java:48)
	at org.springframework.http.client.AbstractClientHttpRequest.execute(AbstractClientHttpRequest.java:53)
	at org.springframework.boot.devtools.remote.client.ClassPathChangeUploader.onApplicationEvent(ClassPathChangeUploader.java:102)
	...12 more
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
	at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
	at sun.security.validator.Validator.validate(Validator.java:260)
	at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
	at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
	at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
	at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1453)
	...32 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145)
	at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131)
	at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
	...38 more

23:24:42.310 [File Watcher] INFO  o.s.b.d.r.c.ClassPathChangeUploader - Uploaded 2class resources
Exception in thread "File Watcher" java.lang.IllegalStateException: Unexpected 301 response uploading class files
	at org.springframework.util.Assert.state(Assert.java:392)
	at org.springframework.boot.devtools.remote.client.ClassPathChangeUploader.onApplicationEvent(ClassPathChangeUploader.java:103)
	at org.springframework.boot.devtools.remote.client.ClassPathChangeUploader.onApplicationEvent(ClassPathChangeUploader.java:56)
	at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:163)
	at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:136)
	at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:381)
	at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:335)
	at org.springframework.boot.devtools.classpath.ClassPathFileChangeListener.publishEvent(ClassPathFileChangeListener.java:68)
	at org.springframework.boot.devtools.classpath.ClassPathFileChangeListener.onChange(ClassPathFileChangeListener.java:64)
	at org.springframework.boot.devtools.filewatch.FileSystemWatcher.fireListeners(FileSystemWatcher.java:230)
	at org.springframework.boot.devtools.filewatch.FileSystemWatcher.updateSnapshots(FileSystemWatcher.java:223)
	at org.springframework.boot.devtools.filewatch.FileSystemWatcher.scan(FileSystemWatcher.java:183)
	at org.springframework.boot.devtools.filewatch.FileSystemWatcher.access$100(FileSystemWatcher.java:41)
	at org.springframework.boot.devtools.filewatch.FileSystemWatcher$1.run(FileSystemWatcher.java:150)

nginx-proxy:image: jwilder/nginx-proxy
  ports:- "80:80"- "443:443"volumes:#    - "/Users/tree/docker/anime-music/certs:/etc/nginx/certs:rw"- "/var/run/docker.sock:/tmp/docker.sock:ro"restart: always

雑感

リモートアップデート先が1URLしか設定できない件は何とかして欲しいですね。ローカルであってもdocker等で複数のインスタンスに対して更新したい要件って昨今では多いと思うので、今後に期待ですね。

もしかしたら、起動時は複数インスタンスを起動して、リモートアップデート時に1インスタンスにスケールダウンしてから更新させ、更新が終わったら再び元のインスタンス数にスケールアップする、とかしたら複数インスタンスの更新できそうな気がしないでもないですが、簡単に実現できるようになれば最高なんですけどね。。。これが実現できればローカルからプロダクションまでjavaでフルdocker環境とかできそうな予感がします。

とりあえずローカルのdockerの場合は1インスタンスで我慢すればリモートアップデートがちゃんと動くので、色々試していきたいと思います。

環境

• JDK1.8
• Spring boot 1.3.2.RELEASE

☓ 駄目な例

@Configurationpublicclass WebAppConfig extends WebMvcConfigurerAdapter {

    @Overridepublicvoid configureMessageConverters(List<HttpMessageConverter<?>> converters) {
        Jackson2ObjectMapperBuilder builder = new Jackson2ObjectMapperBuilder();
        builder.indentOutput(true).serializationInclusion(JsonInclude.Include.NON_NULL);
        converters.add(new MappingJackson2HttpMessageConverter(builder.build()));
    }
}

これは駄目でした。インデントが有効になってnull値の場合に属性が出力されないようになったのですが、以下のように謎の「/**/」が混入してしまいます。

/**/test({
  "head" : {
    "code" : 200
  },
  "body" : {
    "cd" : "コードです",
    "name" : "名前です"
  }
});

◯ 正しい例

@Configurationpublicclass WebAppConfig extends WebMvcConfigurerAdapter {

    @Overridepublicvoid configureMessageConverters(List<HttpMessageConverter<?>> converters) {
        Jackson2ObjectMapperBuilder builder = new Jackson2ObjectMapperBuilder();
        builder.indentOutput(true).serializationInclusion(JsonInclude.Include.NON_NULL);
        converters.add(new MappingJackson2HttpMessageConverter(builder.build()) {

            @Overrideprotectedvoid writePrefix(JsonGenerator generator, Object obj) throws IOException {
                if (!(obj instanceof MappingJacksonValue))
                    return;
                String funcName = ((MappingJacksonValue) obj).getJsonpFunction();
                if (funcName != null)
                    generator.writeRaw(funcName + "(");
            }
        });
    }
}

答えは簡単でした。前回の記事と今回のJackson2ObjectMapperBuilderを組み合わせるだけです。これで以下のように先頭の謎のコメントは削除されます。

test({
  "head" : {
    "code" : 200
  },
  "body" : {
    "cd" : "コードです",
    "name" : "名前です"
  }
});

各社どう翻訳したか

疑問に思った人の意見

• ちゃんと挙動を確認しておきたい
• 単純に好奇心
• 自分の目で確認しないと信用ならない
• 知っておいて損は無い

疑問に思わなかった人の意見

• ツールのやる事なんて知らなくていい
• 自分そういうの詳しくないんで
• そういう事を意識していたらそれを使う意味ない
• 訳が解らないから

ざっくりこんな感じでした。

疑問に思わない人の意見は尤もな意見です。しかし、裏で何が行われるか知っているけど、それを意識しないのと、何も知らないし考えもしないのは違いますね。

完全に把握する必要はないのですが、ほんの少しでも知っておいた方がいいですね。そうしないと、「こんな事しらなくていい」→「それを知るきっかけが訪れない」→「一生知る機会が生まれない」と繋がってしまうかもしれません。

他人に言われるがままで疑問に思わない

凄く極端な例ですが、昔こんな方がいました。

• 環境構築は完全に手順任せで手順をコピペするだけのマシーンと化している。
• デプロイ等の作業は、メモ帳にメモっているコマンドをコピペするだけ。エラーが起きても無関心。
• 何か質問ありますか？と聞いて質問してきた試しがない。
• 知識の源泉が、その職場でやっている事だけに限定されてしまい、外の世界を知らない。

この方は、日々の開発の中で、「このロジック、なんでこういう回りくどい事してるんだろう？何か特別な意味があるのかな？」とか、「この設定でなんでこうなるの？」など、ほとんど何も疑問に思わない人でした。完全に手順・指示に沿って、ロボットのごとく作業するだけでした。その作業内容も、基本他のロジックのコピペで、そのロジックが中で何をしているのかを考えもしないようでした。
www.bunkei-programmer.net

例えばこの方はこんなミスをしていました。あるITに微妙に心得のある風のクライアントから、日付のフォーマットをハイフン区切りにしたいので「YYYY-MM-DD」にして下さいと依頼を受け、その方はこんなコードを書きました。（クライアントはハイフンにしたいだけで、ちょっと頑張ってYYYY-MM-DDと書いてみたが、間違いだった事に気づいていない）

// ↓これが修正前のコード// SimpleDateFormat sdf = new SimpleDateFormat("yyyy/MM/dd");// ↓これが修正後のコード
SimpleDateFormat sdf = new SimpleDateFormat("YYYY-MM-DD");
Date date = sdf.parse(createDate);

普通に考えれば、よほど特殊な事情が無ければ「YYYY-MM-DD」は明らかに間違いで、「yyyy-MM-dd」が正解だと解ります。しかし彼はクライアントの言われるがまま設定し、見事バグとして起票されてしまいました。何故YYYY-MM-DDにしたの？と聞いてみると「言われた通りにやりました」と返答されました。確かにその通りなのですけどね。。。しかしここで「明らかにおかしくないかこれ？」と疑問に思わない点が、危険だなあと思いました。

たとえクライアントに言われた事であろうと、常に「ん？これ本当にあってる？」と考えたり、「これ言われた通りに反映するとヤバイよな・・？」と考える事は重要だと思うのです。言われるがまま作業をするだけだと、全く何も疑問に思わず、何か新しい事を知ったり知識を深めるきっかけがつかみにくいと思います。

疑問に思わない事を続けた末路

更に極端な例ですが、こんな感じに日々の作業で何かを疑問に思う事が無いタイプの方は、「他人に完璧にセットアップして貰った環境の上で、ビジネスロジックを書く事しかできない。しかもそのビジネスロジックは他の処理をコピペするだけ、という状況に陥っていました。他人が敷いてくれたレールの上を、他人が作った電車をコピーして走らせる事しかできない、というわけです。

そう、ビジネスロジックしか書けない症候群に陥ってしまっているのです。

そんな感じでできる範囲があまりにも狭く、何年経っても局所的な作業しかできないため、徐々にその人に仕事を振りにくくなっていくという事が起きてしまいました。

局所的な知識しか無いと設計の幅が狭まる

ビジネスロジック以外に考えられる事ができないと、設計の幅が致命的に狭くなる事があります。

ロジックで頑張ろうとせず、インフラ側で対応した方が効率が良くメンテナンスフリーにできたりするのに、知識が無いが故にそういう発想に至らない。ビルド・デプロイを工夫すればそんなロジック不要になるのに、知識が無いが故にそういう発想に至らない。発想が「ビジネスロジック」という狭い範囲に閉じてしまうが故、より効率の良い設計ができない場合があります。

そしてそういう状況に陥っている事を本人は気づく事ができません。そんな世界がある事を知らないからです。そしてそれを知るきっかけが生み出せないでいます。

もっと疑問に思って欲しい

プログラマはもっと日々行っている事を疑問に思ってもいいと思います。

「なんでそういうプロジェクト名にしたの？」「この設定すると何が起きるの？」「このファイルなんでここに置いてるの？」など、些細な事すら疑問に思って欲しいと私は思っています。ほぼ全ての事にはそうしている理由があるので、疑問に思う事ができれば、それを知るきっかけが生まれます。そこで疑問に思わなければ、一生それを知るきっかけが無いかもしれません。

「些細な事を質問するなんて恥ずかしい」と思っているなら大間違いです。「些細な事を知ろうともしない事が恥ずかしい」のです。

これは、社内だけでなく、社外の話にも言えます。「クライアントはなんでいつもこんな非効率な事やろうとしてるんだろう？何か理由があるのか？」「クライアントがこんな事を言うのは、向こうに何か事情があるのだろうか？」など、相手側の行動に対して疑問に思うと、相手側が抱えている問題を解決するきっかけが生まれる事もあります。

雑感

私の個人的な意見ですが、知識が増えるきっかけは大抵「疑問に思う」事から始まっていると思っています。

例えばネットでIT系のニュースを日々見ていて、「お？この記事に書いてあるライブラリなんだ？凄そう」と疑問や興味を持ち、実際それを使ってみたり勉強してみたりする事に繋がります。そしてそこで出てくる専門用語や技術が解らず、初めて「他人に聞いてみよう」「気になるから自分で調べてみるか！」という行動を起こすのではないでしょうか。

そうやって少しづつ知識を増やすきっかけを増やさないと、「え？それを知らずにその作業してたの！？嘘でしょ・・・」と言われる人間になってしまう可能性があります。そうなってしまうとgithub等の外部から自分の知らない未知の知識を取り入れる事もできないので、自分の知識源が自分の周りの非常に狭い範囲に限定されるリスクもあります。そうなってしまうと、将来がちょっと怖くなりますね。。

今回は非常に極端な例を挙げましたが、疑問に思わない人、は本当に増えてきていると感じています。最近はIDE・フレームワークが何でもかんでも自動でやってくれるので、余計に考えなくてよくなってきているのですよね。高機能になればなるほど利用者は考える事をやめてしまいがちなので、思考停止しないよう常に疑問に思う事を意識し、裏で何が行われているのか、今やっている事は正しいのか、を意識していきたいですね。

ちなみに冒頭の記事の「気軽に聞けない事」に関して私の意見を言うと、「ガンガン質問していいけど、同じ質問するのは最大3回くらいにして欲しい」です。同じ質問を何回もされると、流石に「覚える気ねーな・・・」と思ってしまうので、嫌な感じがしますね。質問をする事自体は凄く良いことだと思います。然るべき人に聞けばググるより速く回答が貰える可能性があるし、回答する側にとっても、他人に説明するという練習をするきっかけにもなります。

最近ではもう本当に疑問に思って質問してくれる人が減ってきているので、バシバシ質問して欲しいですね。

dockerイメージ

hubotをwebhookに反応させる

さて、では本題です

# イメージをpullする
docker pull treetips/dockerfile-centos-hubot-slack:latest

# コンテナを起動する
docker run -dit--name hubot-slack -eHUBOT_SLACK_TOKEN=xoxb-XXXXXXXXXXX-XXXXXXXXXXXXXXXXXXXXXXXX treetips/centos-hubot-slack:latest

# コンテナにsshする
docker exec-it hubot-slack bash

# hubotをslack連携して起動（フォアグランド起動）
./bin/hubot --adapter slack

HubotSlack= require 'hubot-slack'
module.exports =(robot)->
  robot.listeners.push newHubotSlack.SlackBotListener robot,/^おい/i,(res)->
    res.send "なんだよ"

curl -X POST --form'payload={"channel": "#bot-room", "username": "ぼっと", "mrkdwn": true, "text": "おい"}' https://hooks.slack.com/services/XXXXXXXXX/XXXXXXXXX/XXXXXXXXXXXXXXXXXXXXXX

雑感

hubot-slackのスクリプト開発、正直辛いですね。とりあえずカッとなってdockerイメージ作ったので大分開発しやすくなりましたが、まだまだ開発しにくい感が否めません。

というか、hubotって「あの呼びかけにあれが反応しない」等が非常に解りにくいんですよね。hubotがhubot宛（自分宛）にmentionしても反応しなかったり（多分無限ループになるから）、その辺がいちいち面倒臭くて、あれこれ試してるうちにチャットルームがテスト投稿でビッシリ埋まってしまい、「てめー何チャットルーム荒らしてんだコラ」と怒られたりします。

そうならないためにも、個人でslackアカウント用意してしまって、dockerfile-centos-hubot-slackのイメージであれこれ試行錯誤すると、チャットルーム荒らしの汚名を着せられる事もなくなります。きっと・・・

ImageMagic

[vagrant@node1 ~]$ ll
total 12956
-rw-rw-r-- 1 vagrant vagrant 13266141 Feb 1222:23 ImageMagick.tar.gz
[vagrant@node1 ~]$ tar zxf ./ImageMagick.tar.gz
[vagrant@node1 ~]$ ll
total 12960
drwxrwxr-x 15 vagrant vagrant     4096 Feb 1222:23 ImageMagick-6.9.3-4
-rw-rw-r--  1 vagrant vagrant 13266141 Feb 1222:23 ImageMagick.tar.gz

mkdir-p ImageMagick-latest && tar zxf ImageMagick.tar.gz -C ImageMagick-latest --strip-components1

cd /usr/local/src
# DL
sudo wget http://www.imagemagick.org/download/ImageMagick.tar.gz
# フォルダ名を固定化して解凍
sudo mkdir-p ImageMagick-latest && tar xzvf ImageMagick.tar.gz -C ImageMagick-latest --strip-components1# コンパイル・インストールcd ImageMagick
sudo ./configure
sudo make
sudo make install

cd /usr/local/src
sudo wget http://ftp.gnu.org/gnu/autoconf/autoconf-latest.tar.gz
sudo mkdir-p autoconf-latest && tar xzvf autoconf-latest.tar.gz -C autoconf-latest --strip-components1cd autoconf-latest
sudo ./configure
sudo make
sudo make install

[vagrant@node1 src]$ autoconf --version
autoconf (GNU Autoconf) 2.69
Copyright (C)2012 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.
[vagrant@node1 src]$ convert --version
Version: ImageMagick 6.9.3-4 Q16 x86_64 2016-02-18 http://www.imagemagick.org
Copyright: Copyright (C)1999-2016 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Features: Cipher DPC OpenMP
Delegates (built-in):

ImageMagickのPlaybook

ansibleのplaybookです。ansible v2.0.0.2 で実装していて、becomeやblock等の新機能を使っているため、旧バージョンでは動きません。

github.com

雑感

今回はvagrantを使っていますが、最近はローカルでdockerを使う機会が増えました。

ImageMagickはyumを使えばもっと簡単にインストールできますが、やはり最新版と比較するとインストールできるバージョンが古いのですよね。アップデートを考えるとyumの方が遥かに楽ですが、dockerの場合はパッケージの更新の考慮が不要になる（イメージ自体を更新）ので、最新バージョンのソースコードからコンパイルしてインストール機会が増えていくんじゃないかと思っています。

本当はrpmがあると楽てきて嬉しいのですが、ImageMagickのサイトで配布されているrpmを「sudo rpm -ivh xxx.rpm」とやっても、依存が付属していないのでエラーになるのですよね・・・あれはちょっと使い物にならないので、ソースからインストールした方が速いです。

これであなたも無事、失敗できる！

雑感

いかがでしたでしょうか。多分こんなような事は皆やっちゃってるんじゃないでしょうか。

色々なプロジェクトを見てきて、チケット管理が成功しているのは、やはり選択肢が非常にシンプルで少ない、ワークフローを上手く使って行動を制限できているプロジェクトの成功率が高いように思えました。

特に、トラッカーはマジでシンプルで選択肢が少ない方が上手く行きやすいように思えました。要件定義・設計・実装・単体テスト・結合テスト・・・・みたいに細かくしたい気持ちはよく解るのですが、それ、間違いなく失敗します。皆そんな綺麗に運用できません。設計チケットで実装のコメント合戦を始めるし、単体テストチケットで仕様調整の話を始めます。細かすぎです。目茶苦茶少ないくらいが丁度いいです。

進捗率に関しては、私は全く要らない機能だと思っています。例えば調査系のチケットの場合、調査を完了したら進捗率はいくつなの？等と困ってしまったり、進捗率が0%のまま最後まで進んでチケットを終了するときに仕方なく100%にするようなチケットも結構あります。「ここで進捗率を更新しないといけない」みたいなルールを設けても、細かすぎて覚えきれないし、誰も守りません。他にも「実装着手したら進捗率を5%に更新してから実装して下さい」等もアホ臭いです。そのスケジュール管理、おかしいと思いませんかね？もっといい方法探したほうがいいのでは？と思ってます。今だったらgitのコミット頻度とか見れば、本当に実装が進んでそうなのか等が解ったりしますよね。作業者の申告制みたいな管理やめて、機械的に管理できる仕組みを模索した方がいいと思います。

redmineのチケット管理は徐々に色々増殖して破綻していく傾向があるので、「どれだけできる事を減らせるか」「どれだけ行動を制限できるか」の2点にかかっているかと思います。プログラマはどうしても細かく分類して、あらゆるものを無駄に管理したがり、最後は収集がつかなくなって放置されるものが増える傾向があるので、どれだけシンプルにできるかが成功するための鍵になる、と私は考えています。

そもそも今の時代に個人でプリンタって必要か？

今回の私のケースでは、ネットで物を買い取って貰いました。ネットでの買い取りは紙媒体が必要になる場合があります（古物営業法の関係？）。私の場合はここ数年で紙媒体への印刷が必要になった機会はネットでの買い取りサービス利用時だけです。印刷する機会は完全に無くなる訳ではありませんが、どうしても紙媒体が必要になるケースはありますね。

紙媒体への印刷が必要なのは解ります。しかし、個人でプリンタを所有する意味はあるのか？という点を疑問に思いました。プリンタのインクは高価だし、印刷用紙も常備しないといけないし、プリンタ自体の設置スペースもかなり必要になります。これを自宅に常備する必要はあるでしょうか？プリンタに関する事全てをプロに任せる事はできないでしょうか？

それ、ネットプリントでできるよ

www.printing.ne.jp

PCやスマホから専用アプリ等で印刷の予約をすると、予約番号が貰えます。コンビニのプリンタに出向き、予約番号を入力すると、カラー・モノクロ等で印刷する事ができるサービスです。以下のような感じです。

セブン-イレブン ネットプリント操作方法

ネットプリントにはファイルのアップロード速度やアップロード枚数等の制限はあるものの、自宅に年に1回使うか使わないかのでっかいプリンタを常備させるより、これで済ませた方がいいのではないか？と思います。

雑感

昔からごくごく稀に使うから、中々プリンタ処分できないんだよな〜と思ってました。長期間プリンタを稼働しない事も普通にあり、すぐインクが固まってしまいます。固まったインクノズルをメンテする機能がプリンタに内蔵されていたりしますが、これがまた何故かごっそりインクが減らされるんですよね・・・理不尽だと思いつつ、プリンタを捨てる事ができませんでした。

自宅のプリンタはもうとにかく使う機会が少ないから、まず間違い無く埃を被っているし、電源＋USBケーブルどれだっけ！？と探しまわる事も多し。しかも今回の私の例のように、いざ使おうとしたら起動時にエラーが起きて何もできなくなるパターンもあります。

プリンタというのはそもそも定期的にメンテナンスが必要なデリケートな機械であり、快適に使い続けるには素人には非常に難しいものです。会社で「ただいま◯階のプリンタの紙詰まりの対応を業者に依頼中です」「ただいま◯階のトナーを・・（略」等、定期的に不具合が出ては業者を呼んで、という光景を目にしますね。プリンタに纏わるトラブルは本当に多いものです。それを個人で快適に使い続けるために定期的にメンテナンスするのは、ちょっと難しいと私は思っています。

このようにプリンタトラブルに嵌って時間を消耗し、精神をすり減らし、埃をかぶらないように注意したり、設置スペースに泣いたりする。正直もうこうやって消耗する時代じゃなくなってきましたね。著名なコンビニは確実にネットプリントサービスをやっているので、自宅に機材を置かず、外部のサービスに頼るべきですね。ネットプリントであれば、クラウドサービスのように使った分しか請求されないので、コストを抑える事もできます。時は金なりといいますし、自宅にデカイプリンタを置いて時間を消費するのは非常に勿体無い。その時間をもっと別の事に活用すべきです。

今回のように、いざ使おうと思った時にエラーが起きたり、インクが切れたりしてすぐ使えない場合も普通にあるので、自宅に常備しているからといって、すぐに使えるかどうかは日々のメンテにかかっているという状態になりがちなので、皆さんも自宅からプリンタを排除して、インク残量を気にしたり設置スペースを気にしたり駆動音を気にしたりするのを止めて、ネットプリント等の外部サービスに移行し、楽になりましょう。

雑感

このスパムチラシの量は、「ネットだとgoogle先生の速攻制裁されるから、抜け穴だらけでガバガバの現実世界でスパムしたるで〜」等と考えているようにしか思えませんね。

もしここにgmailのフィルターみたいなものがかけられたら、1ヶ月に一体何通届くのでしょうね。。。私の場合は恐らく佐川急便とクロネコヤマトからの不在票しか届かないでしょう。電気もガスも水道も、検針票はネットに移行したので届きませんし、スマホもMVNOなのでそもそもWEB明細オンリーです。届くものいったら不在票かクレカ会社からのDMくらいです。

こうして徐々に現実世界にネット世界のスパムの波が押し寄せてくるのは正直嫌ですね。ネットと違って機械的に排除する事も容易ではありません。もういっその事郵便受けの口を塞いでやろうか

どうでもいいんですよ！

DBの検索部分を全文検索エンジンでの検索にリプレースするタスクで言われた一言。

Aさん「全文検索エンジンの事なんて知りませんよ！treeさん（私）がやってくださいよ！私はメソッドの中身なんてどうでもいいんです！SQLと同じ結果が返ればどうでもいいんですよ！速く作って下さいよ！」

いやね、それを実装するのがあなたの役目なんですが。

私はスキルが低いんです！

突然言われたこの一言。

Aさん「私はスキルが低いんですよ！？そんな事できませんよ！！」

テスターからやり直して出直してくれ。

捨てます

バッチの実装を任せた時、データの状態について聞いた時の返答。

私「この時こういうゴミデータができてしまうのですが、これらデータはどう処理されますか？」
Aさん「大事なデータじゃないし、捨てますけど。」

待て。大事かどうかを決めるのはあなたじゃないし、捨てるとか、何考えているんだ・・・

鉄壁の前提人間

URLパラメータをキーにDBを検索する画面で、パラメータ値が未設定の時に500エラーが返るバグについて実装内容を確認した時の一言。

Aさん「ここは絶対にURLパラメータが設定される想定です」

待て待て、URLパラメータ（QueryString）が未設定とか、普通にあるぞ。そんな前提条件が通るWEBアプリなんてまず無いでしょうよ。

私「ここにバリデーション入れてくれませんか？」
Aさん「いや、ここは絶対に値が来る前提です。話が違うからやりません。やるならお金下さい」

・・・・

ちなみにその前提は彼が勝手に作った前提で、全く合意が取れていないという・・

ループの鬼

都道府県毎に処理するSQLを実装して貰うというお仕事を依頼した時のやりとり。

私「ここ、47都道府県を処理する部分ですが、47回SQLを実行するのは負荷かかるので、SQL1回で済ませられませんか？」
Aさん「え？47回実行するのマズイんですか？」

単純にスキルが低過ぎるが故の返答でした。大した処理内容でもないのに、1つの処理で47回ループして47回SQLを投げてしまうという異常性に気づけるスキルを身につけて頑張って欲しい。

そこまでする必要無い

私「◯◯を格納するクラスなのに、◯◯に関連の無いフィールドが混じっているんですが、何か意図はありますか？」
Aさん「ありません。動けばいいじゃないですか。」
私「良い設計をしたいと考えているので、そのフィールドを別のクラスに移動してくれませんか？」
Aさん「そんな事どうでもいいじゃないですか。そこまでする意味あるんですか？」
私「そういう事の積み重ねで今の酷いコードができるんです。いつもあなたが苦しみながら修正しているコードはそういう設計思想の元、出来上がったのです。」
Aさん「そうなんですか。でも私はそこまでする必要は無いと判断したので修正しません。」

・・・1ヶ月後・・・

Aさん「うぅ〜・・・・うぅ〜・・・（今にも死にそうで苦しそうな呻き声）」

だから言っただろ・・・あの時の自信は一体なんだったんだ。

私が悪いんで！！

私「この装置、Aさんが既に利用実績があるから採用したと聞いたのですが、使い方ざっくり教えて貰えますか？」
Aさん「ああ、あれですね。あれは私がそれを使ったPJを聞いた事があるってだけなんですよね」
私「え？マジですか・・・保守も契約してないし、もう納品まで時間が無いですね・・・」
Aさん「解りました！私が悪いんで！始末書でも何でも書きますよ！」

oh・・・・開き直るとか、人間のする事じゃないな・・・

私には権限が無い

私「◯◯の作業をお願いしたいのですが、できますか？」
Aさん「私には権限が無いので、できません。」
私「では私がサポートするという条件で権限を与えますので、お願いします。」
Aさん「え・・・すいません実はやった事が無いのでできません」

何故か結構いるのですよね、「未経験である事」を「権限が無いからできない」という事にすり替えようとする方が。素直に「やった事が無いですがお願いします」みたいに言って貰えればいくらでもサポートするのになあ。

書籍に書いてあるんで

私「なんだこの処理。修正するか」

・・・・Aさんがその修正を元に戻してコミット・・・

私「は・・・？なんかrevertされてるな。」
私「Aさん、ここ、解放する処理入れないとエラーになるので、入れてくれませんか？」
Aさん「私のコードは書籍通りのコードです。これで正しいです。」

？？？？書籍に書いてあるサンプルと、今やってる処理が同じ？そんな訳ないだろう・・・どういう理屈なんだ。

雑感

思い返してみると、色んな事言われたなあ・・・どれもこれも私を驚かせる発言ばかりでした。本当はもっと沢山言われてきてる筈ですが、今回はすぐに思い出せるかなりショッキングな発言をピックアップした形となりました。（単に思い出せないだけですが・・）

ビックリするようなセリフを口走ってしまう人に共通していた事は、「今が良ければそれでいい」「無駄に頑固」「打たれ弱く衝動的な行動をしがち」「どうでもいいと言いがち」という感じでした。彼らの大分部は、ビックリ行動のしっぺ返しを喰らうという自業自得な状況でした。結果として自分で撒いた種に自分で苦しみ、早々に去って行く人が多いように思えました。私の「そのやり方だとこういうデメリットがあり、後々こういう事になるかもしれませんよ」という言葉も届かない場合がほとんどで、自分の考えを全く変えようとしませんでした。悪い意味での頑固一徹というやつです。

逆に、無駄なプライドがなく、素直で、自分の行動を見つめ直せるタイプの人はあっという間に伸びていき、すぐに巣立っていきました。その調子でどんどん吸収して巣立って欲しいですね。

やはり素直さを失ってしまうと、引くに引けない状況になって絶対どこかで詰んでしまうので、頑固にならないように気をつけていきたいですね。

増田概要

一言でまとめると、「歩道を歩く歩行者も、自衛はした方がいいよ」というお話です。

そういうお話ではあるのですが、書き方が悪いせいで、「歩行者は自転車乗りの俺達に合わせリスク回避策取れや」といった上から目線な印象を強く感じてしまうため、記事の本質を無視して読み手が「自転車＝無条件に悪。歩行者＝無条件に神」という論理を展開し、炎上に至っているわけです。

書き方が悪いせいで本題から逸れてしまっている、残念な増田なのです。

増田の本題

この記事の本題を以下だと仮定します。

人間はロボットでは無いので、どれだけ法令遵守をこころがけても自転車の法律違反は起きてしまう。どんなに注意しても、ヒューマンエラーを100%防ぐ事はできません。法律的に自転車が100%悪い事は解っている、だが、だからといって歩行者が何もせず「自転車が悪い！」と叫んで無策な状態になるよりは、何かしらの安全策を講じた方が、理不尽な危険から身を守る可能性はあるよ、と。

こんな感じでしょうか。要は「理想は道路交通法を100%順守で100%事故が起きない事だが、現実的に考えると100%事故を防ぐ手段は無いから対策しようぜ！」という事ですね。

未だ変わらない自転車乗りの意識

道路交通法が改正され、自転車は「軽車両」扱いとなりました。それに伴い、今までの自由過ぎた状態から一気に法的なルールが追加されました。
自転車の交通ルール :警視庁
自転車はルールを守って安全運転～自転車は「車のなかま」～｜警察庁
http://www.mlit.go.jp/road/road/bicycle/pdf/guideline.pdf

私は東京都内に住んでおり、自転車通勤をしています。原則車道の端っこを走っているのですが、自転車レーンも無く車の交通量が非常に多いので、どうしても自転車通行可の標識がある歩道を通らざるをえない場合や、自転車通行可の標識が無いが安全のためやむを得ず歩道を通過する事もあります。

実際に自転車に乗っている私から見て、道路交通法を守らずに危険運転する人は多いなあと感じています。

なかなか進まないインフラ整備

海外では自転車専用レーンの整備が進みつつ有りますが、日本ではまだまだ整備が進んでいません。整備されていない訳ではないのですが、こんな状況だったりするようです。

これは難しい。。 pic.twitter.com/E3bQOKinkT

— sakamobi (@sakamobi) 2014年9月14日

これは極端な例ですが、明らかに「どや？対応したぜ？」みたいな役人のやりましたアピールのために、ただ青線を引いただけのように感じてしまいますね。まあ青い線があるだけでも車道を走る車に自転車の存在を意識させる事はできるのですけどね。

自転車王国オランダでは、自転車レーンのインフラ整備が非常に進んでいるようです。
【まとめ】世界一の自転車先進国オランダは自転車専用レーンが当たり前！ | Actionなう！

一方アメリカ・ニューヨークでは、自転車レーンはあるものの、意識がおいついていないせいか、自転車レーンに車が駐車している事もあるようです。
matome.naver.jp

少なくとも私の通勤ルートでは自転車レーンの青い目印を見ることができないので、非常に残念です。

歩行者の意識はどうだろう？

もし自転車が歩道を100%走る事が無い状況があったとして、歩行者は交通ルールを守っているでしょうか？
道路交通法,(略)道交法
歩行者側にもきちんと交通ルールはあります。もし冒頭の増田で「歩行者は神。100%優先されるから何しても良い」と考えているなら、それは誤っています。歩行者側にも交通ルールは有り、それを破ってはいけません。

「ほーら歩行者もルール守ってないだろ？お互い様だろwww」等と言いたい訳ではなく、他人の違反を指摘するだけでなく、自分自身も適切に交通ルールを守るべきだと思うのです。そのルールも守らずに他人に「お前は100%間違っている」理論を振りかざしても、「お前も違反してるだろ」等と水掛け論になってしまい、解決には至りませんね。

ちなみに、youtubeで歩行者の飛び出しによる事故を探してみたのですが、ワラワラ出てきました。
www.youtube.com
※ ショッキングな映像を含むため、耐性の無い方は閲覧しない事をオススメします。

ついでに自転車の事故です。
www.youtube.com
※ ショッキングな映像を含むため、耐性の無い方は閲覧しない事をオススメします。

行き場の無い自転車

現実的にはこんな感じで、自転車は自動車からも歩行者からも疎まれていますね。道路交通法的には自転車は原則車道を通っていい筈なのですが、自動車からは「危険だから通るな！」と言われる事が多いのが現状です。そして自転車通行可の標識がある歩道でも、歩行者から「自転車は危険だから歩道を走るな！」と言われます。正直どこを走っても誰かに何かを言われてしまうのが自転車の現状ですね。

自転車事故の大分部は都内で起きている

都内自転車の交通事故発生状況 ：警視庁
警視庁の資料を見ると、やはりというか、自転車事故前提の発生場所は都内が31.1%を占めていると書かれています。47都道府県のうち、都内だけで3割を占めてしまう程に一極集中していますね。

自転車についての議論

雑感

増田のコメントにあるような「道路交通法を破る奴が悪い。だから俺は無策でいく。」となるより、「いつどんな理不尽に巻き込まれるかも解らない。個人で何かしらの防衛策を講じた方が不利益は少なく済む」と考えた方がいいと私は思っています。コメ主の主張は確かに正しいです。物事が100%理想通りに動く世界があれば、その主張は最高です。しかし、世の中には理屈が正しいのに、突如理不尽によって被害を被る事があります。相手側に過失が100%あったとしても、被害を受ける場合もあります。それを考えると、私は痛いのも怖いのも嫌なので、対策をしても損は無いと思っています。

IT業界で例えると、「負荷でサイトがダウンしたぞ！？ブルートフォースの総当り攻撃を受けてるようだ。でもアタックしてる方が悪いんだから、俺は何もしない。相手が悪い」という対応に利益があるのか、不利益を生むのか。この場合は誰が攻撃してきているのかを詳細に特定できない場合があり、損害賠償の請求先もありません。ここで「相手が悪い！」と叫ぶよりも「攻撃されないよう防衛して不利益を減らそう」と考えた方が、最終的に自分にふりかかる不利益は減らせます。

今回自転車と交通事故について色々調べてみましたが、「自転車＝悪」「自転車を免許制にすれば解決・改善」等と一概には言えない問題なんだな、と再認識しました。自転車の問題は、自転車先進国のオランダでさえ問題を抱えています。自動車と違って、問題表面化・認知されて、それを改善しようとする歴史がまだ浅いので、まだ探り探り解決しようと努力しているように見えました。そんな状態なので、一方的には「あれは悪だ」と決めつけても何も解決しないので、冷静に現状の問題を認識して、まずは個人でできる防衛策を考えていきたいですね。

最近youtubeで「ドライブレコーダー」で検索した動画をよく見るのですが、自動車・自転車に乗りたくなくなる程怖くなります。「どういう状況で事故が起きているのか」を知る事もできるので、事故動画に耐性がある方は、是非見てみる事をおすすめます。恐らく「俺、もう危険運転やめるわ・・」と思うことでしょう・・
www.youtube.com

docker-compose

実はもう準備してあります。
github.com
英語ですが、使い方も全部書きました。

簡単に言うと、git cloneし、docker-compose upするだけで、MySQLのv5.5, 5.6, 5.7の環境が準備できてしまいます。

しかも、それぞれのバージョンごとにmy.cnfを用意してあるので、バージョン毎に設定を変える事もできます。

使用しているimageはMySQL公式のimageです。
https://hub.docker.com/_/mysql/

環境変数を設定すると、MySQL起動時にスキーマ、ユーザ、パスワード、rootパスワードを作成・設定した状態で起動してくれます。その変もバージョン毎に変更できるようにしてあります。

雑感

初回はdocker pullが走ってしまうので、イメージのダウンロードにちょっと時間がかかってしまいますが、これで無茶苦茶簡単にMySQLサーバをフルセットで準備する事ができます。

これでローカル環境にはMySQLサーバではなくMySQLクライアントだけインストールするだけで済むようになります。重たくメモリを喰うMySQLサーバをローカルに起動したり、複数バージョン運用するのに職人芸で対応したりする必要も無くなります。もしまだDMGやexeでローカルにMySQLサーバをインストールしている方がいれば、これを機にdockerに移行してみませんか？

Jooqとは

www.jooq.org
詳細は公式サイトを見た方が早いのですが、簡単に言うとJavaでタイプセーフにSQL発行できるライブラリです。

言葉で説明しても伝わりにくいので、実際のjavaのコードを見るとイメージできると思います。

List<PrefectureRecord> results = dsl.selectFrom(Prefecture.PREFECTURE)
    .where(Prefecture.PREFECTURE.PREFECTURE_CD.eq(Byte.parseByte("13")))
    .fetchInto(PrefectureRecord.class);
results.forEach(System.out::println);
↓
+-------+-------------+---------------+
|area_cd|prefecture_cd|prefecture_name|
+-------+-------------+---------------+
|      3|           13|東京都          |
+-------+-------------+---------------+

※ static importすればもっとシンプルな記述ができます。

こんな感じでSQLファイルにSQLを記述するタイプではなく、javaのコードでSQLを発行する事ができます。

S2JDBCのような見た目ですが、S2JDBCと違い、group byやhaving等、高度なSQLを扱う事ができます。その変わり、SQLファイルにSQLを書く事は基本的にできません。

Jooqのサンプル

今回も例によって既にモノはできています。

github.com

root
├ master（gradle, docker関連）
└ base（共通親プロジェクト）
　　└ batch（バッチプロジェクト）

@Autowiredprivate DataSource dataSource;

・・・中略・・・
    Flyway flyway = new Flyway();
    flyway.setDataSource(dataSource);

@Autowiredprivate DSLContext dsl;

・・・中略・・・
    List<PrefectureRecord> results = dsl.selectFrom(Prefecture.PREFECTURE)
        .where(Prefecture.PREFECTURE.PREFECTURE_CD.eq(Byte.parseByte("13")))
        .fetchInto(PrefectureRecord.class);

Jooqを触ってみて

といっても業務で使っているわけではなく、私個人でちょっと触った程度なのですが。。。

List<Record2<Byte, Integer>> results =
    dsl.select(Prefecture.PREFECTURE.AREA_CD, DSL.count())
    .from(Prefecture.PREFECTURE)
    .groupBy(Prefecture.PREFECTURE.AREA_CD).fetch();

select
        prefecture.area_cd
        ,count(*)
    from
        prefecture prefecture
    groupby
        prefecture.area_cd

List<PrefectureRecord> results = dsl.selectFrom(Prefecture.PREFECTURE)
    .where(Prefecture.PREFECTURE.PREFECTURE_CD.eq(Byte.parseByte("13")))
    .fetchInto(PrefectureRecord.class);
results.forEach(System.out::println);

+-------+-------------+---------------+
|area_cd|prefecture_cd|prefecture_name|
+-------+-------------+---------------+
|      3|           13|東京都          |
+-------+-------------+---------------+

select
        sum(cnt)
        ,
    from (
        select
                count(*) as'cnt'
                ,xxx_cd
            from
                aaa
            groupby
                xxx_cd
    ) tmp
    inner join bbb
        on tmp.xxx = bbb.xxx
;

Configuration configuration = new Configuration().withJdbc(new Jdbc() //
        .withDriver(dataSourceProperties.getDriverClassName()) //
        .withUrl(dataSourceProperties.getUrl()) //
        .withUser(dataSourceProperties.getUsername()) //
        .withPassword(dataSourceProperties.getPassword()) //
).withGenerator(new Generator().withDatabase(new Database() //
        .withName(generatorClassName) //
        .withIncludes(".*") //
        .withExcludes("(batch_.*|schema_version)") //
        .withInputSchema(dataSourceProperties.getSchema()) //
).withTarget(new Target() //
        .withPackageName("com.github.treetips.domain.model") //
        .withDirectory("../base/src/main/java")));
GenerationTool.generate(configuration);

おまけ

droptable if exists java_type;
createtable java_type (
	char_type char(10)default'char'
	,varchar_type varchar(10)default'varchar'
	,tinytext_type tinytext
	,text_type text
	,mediumtext_type mediumtext
	,longtext_type longtext
	,tinyint_type tinyintdefault1
	,smallint_type smallintdefault1
	,mediumint_type mediumintdefault1
	,int_type intdefault1
	,bigint_type bigintdefault1
	,float_type float default1.1
	,double_type double default1.1
	,date_type datedefault'2001-01-01'
	,datetime_type datetimedefault'2001-01-01 00:00:00'
	,timestamp_type timestamp default'2001-01-01 00:00:00'
	,time_stype timedefault'00:00:00'
	,year_type year default'2001'
	,binary_type binary
	,varbinary_type varbinary(10)
	,tinyblob_type tinyblob
	,blob_type blob
	,mediumblob_type mediumblob
	,longblog_type longblob
	,enum_type enum('red','blue','yellow')default'red'
	,set_type set('green', 'orange', 'pink')default'green'
	,geometry_type geometry
	,point_type point
	,linestring_type linestring
	,polygon_type polygon
	,multipoint_type multipoint
	,multilinestring_type multilinestring
	,multipolygon_type multipolygon
	,geometrycollection_type geometrycollection
) engine=innodb charset=utf8mb4 row_format=dynamic comment='java型確認マスタ';

/** * This class is generated by jOOQ. */@Generated(
    value = {
        "http://www.jooq.org",
        "jOOQ version:3.7.3"
    },
    comments = "This class is generated by jOOQ"
)
@SuppressWarnings({ "all", "unchecked", "rawtypes" })
publicenum JavaTypeEnumType implements EnumType {

    red("red"),
    blue("blue"),
    yellow("yellow");

    privatefinal String literal;

    private JavaTypeEnumType(String literal) {
        this.literal = literal;
    }

    @Overridepublic Schema getSchema() {
        returnnull;
    }

    @Overridepublic String getName() {
        return"java_type_enum_type";
    }

    @Overridepublic String getLiteral() {
        return literal;
    }
}

雑感

複雑なSQLを書こうとすると大変になりそうなデメリットを持つ一方で、DDLが書けてしまうメリットもある。そんな良い点と悪い点の両方を併せ持つJooq。使い所さえ間違わなければかなり使えそうな感じですね。

私は業務で未だにS2JDBCを使っていますが、DSLで集約関数は書けないし、truncateも書けないし、SQLファイル内でDDLは書けない、それができてしまうJooqは凄いなと思いました（ｺﾅﾐｶﾝ
ただ、一方でJooqはSQLファイルによる記述ができないので、そこが業務ではデメリットになりそうです。そう考えるとS2JDBCはDSLもそこそこ書けるしSQLファイルで2way SQLもいけるし、結構バランスがいいんだなあと思いました（更にｺﾅﾐｶﾝ

Jooqの記事を書いておいてアレですが、seasarプロダクトのDomaはSQLファイルオンリーで高機能なORMですが、個人的には次に業務で使うならdoma2がいいなと思っています。例えばS2JDBCの場合、generatorでentityとnamesクラスを自動生成しますが、カラムが変更された時にコンパイルエラーが出るから変更に追従し易い、といったメリットがありますが、私は一度もカラム名変更に追従できて助かった記憶が無いのです。そもそもカラム名を変更する機会が無いのです。そう考えると、もういっそ全部SQLファイルの方がいいんじゃない？とか思いました。

ただ、全部SQLファイルになると、どんなSQLを発行しようとしてるのかはSQLファイルを1件づつ開いてみないと確認できない点だけが不安ですね。

ん？Hibernate？なにそれぼくしらない