TSVInporter を H2 で動くようにしてみた

github.com

TSV インポーターを作ってみた。
とりあえず H2SQL だけ対応した。

非常に残念なことに、java.sql.Types の中に定義してある型を、各 DB がどんな型として扱うのかは、JDBC の実装依存らしい。
そのため、極論するとデータの型変換は、DB の種類分必要ということになってしまう |||orz

https://www.cis.upenn.edu/~bcpierce/courses/629/jdkdocs/guide/jdbc/getstart/mapping.doc.html

ここのドキュメントの 8.2 章がその内容だ。

仕方がないので、変換用 IF だけ置いて、使うとき実装してもらうスタイルに…誰か他の DB とか書いてくれないかなぁ（トオイメ
まぁもともと、DB を使った UT で、Java コードで事前準備レコードなんて書きたくないから用意したわけで、それさえできればよしとしよう（汗

追記: How To Use をリポジトリに追加したのであとは野となれ山となれ。ライセンスに WTFPL としようか一瞬迷った。

TSV からテーブルインサートするライブラリ作成中

github.com

まだ未完成。

• UT してない。
• テーブルカラムに対応したデータ変換ロジックが書かれていない。
• H2SQL しか見てない。（できれば SQLServer は個人的にやっときたい）

突貫工事でバグとかありそうで怖いけどとりあえずコミット。

速攻で Jenkins を練習する環境を用意する

目的は Jenkins を試すことのみ。
それも構築/設定をメインに試すので、なるだけ最短ルートを通る。

Jenkins インストール

今回は Jenkins のセットアップ手順を知るために、Linux にガチで入れます。
Docker コンテナもあるにはあるのですが、今回そっちには逃げません。

とはいえ、Ubuntu のインストールは今回の目的ではないので、こっちは Docker でやってしまいます。

$ docker run --name jenkins-example -it -p 8080:8080 -p 8000:80 ubuntu

Ubuntu にログインしたら

$ apt update -y
$ apt upgrade -y
$ apt install wget git gnupg openjdk-8-jdk -y
$ wget -q -O - https://pkg.jenkins.io/debian/jenkins-ci.org.key | apt-key add -
$ sh -c 'echo deb http://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list'
$ apt update
$ apt install jenkins -y
$ /etc/init.d/jenkins start

そこそこ長い…
ここまで来たら、 http://localhost:8080/ を開くと

ヒャッホイ。
画面の指示にしたがってサジェストプラグインをとりあえず入れてしまう。

管理者アカウントも作成して

起動しました

ビルドプロジェクトの作成

「新規ジョブの作成」から、「フリースタイルジョブ」で適当な名前で作成します。

設定が始まりますが、上の方は表示とかメタ情報の類です。
入れたければお好みで

重要なのはリポジトリ設定以降です。
git を指定して、以下の URL を突っ込みます

https://github.com/Sunao-Yoshii/spring-boot-web-example.git

その後の設定ですが

• ビルドトリガ
  定期的に git リポジトリを調べて、新しかったら自動実行…とかできます。
• ビルド環境
  選択肢の通りでしょう。今回は放置します

「ビルド」の欄で、どんどん手順を追加していきます。最悪のケースでも shell を直接設定できるので、Linux の手順はだいたい設定できます。
まずは gradle コマンドを追加してしまいます「Invoke gradle script」を選択して

「test」とだけ打ってみましょうか。

そしたらプロジェクト名を別タブで開きます

サイドメニューから「ビルドを実行」とすると、リポジトリからのチェックアウト、テストが実行されます。
ちなみに「ワークスペース」を開くと、ビルド後のプロジェクトディレクトリの中身がみれます。

そしたらプロジェクトの設定に戻り、「ビルド後の処理の追加」から「JUnit 結果の集計」あたりを選びましょう。
これは JUnit の結果 XML を集計するので、フォーマットが一緒なら他の Unit 系でも使えます。

入力するディレクトリは「build/test-results/test/*.xml」で設定します。
build ディレクトリは gradle 標準のアウトプットディレクトリで、test-resulkts/test も言わずもがなですね…

再度実行して成功すると「テスト結果」の項目が出てきます。
ここでエラーになる場合は、gradle コマンドを以下の２行にして再実行してみてください。

clean
test

設定をみてみれば分かりますが、エラー時にメール通知など色々できるようになっています。
最終的にこのプロジェクトではこんな設定を行いました。

チェックスタイルの追加と、ビルド結果の保存です。
Spring の jar はそのまま実行するとサーバになるので、それでもいいですが、頑張って war にするなら、Tomcat へデプロイとか、Azure AppService へのデプロイとか色々やりようがありますね。

LINE BOT 作ろう！

ちょうど明日勉強会で Jenkins セットアップするので、Line BOT で色々通知できないかなーというノリで参加してみました。
結論から言えば方向性が違いましたが、色々サービスに触れて面白かったのでここで紹介してきます！

x-hack.connpass.com

まず最初に使うサービスをザックリ紹介。

codenvy.io

Codenvy はオンライン IDE なんて言う素敵なアイテム。
勉強会でハンズオンするのに、IDE 宗教とか面倒だろうし、何かと重宝しそうですね。

Git リポジトリを選択すると、Docker 上の Linux に clone して色々な編集ができます。
Linux ターミナルが使える所がまたイイ！

関連記事: Codenvy使ってみた - Qiita

jp.heroku.com

Heroku はクラウド黎明期から速攻で PaaS を始めてるクラウドサービス。
昔使った事が一時期あったのだけど、長らく使う機会がありませんでした。

特徴は、ともかくシンプル！
サービス開始までの手順がもっとも少ない PaaS なのではないでしょうか？

developers.line.me

ラストは…説明不要のサービス。
BOT 作成には Developper アカウントが必要ですが、こちらも基本的に LINE の QR ログインで登録できてしまいます。
いやはや便利になったものです。

開始

自己紹介から開始。
今回の講師は、主：桑原さん、ヘルプ：マツダさん、長岡さん

本日の内容。

github.com

X-Hack さんは、非エンジニア向けにプログラミングの啓蒙等をされている会社さんです。
ごめんなさい現役エンジニアが興味本位で枠奪ってしまって（汗

LINE の設定

まず LINE Developper にログインするとこんな画面になります。

「新規プロバイダー作成」からプロバイダー名を入力して

「確認」「作成する」でさっくりプロバイダーを作ります。
次に「チャンネルを作る」に進んで、適当な名前の BOT を作りましょう。

「Developper Trial」ってイイですねー
ジャンルは適当に選びましょう。どうせ作り終わったら消します（汗

メールアドレスは、自動入力だとエラーになります。
必ず手入力で…キーバインドチェックか何かしてるようです。

確認画面などは代わり映えしないので省略します。
ハンズオンだったのでさして読みきれてませんでしたが、改めて読んでも常識的な事が書いてありました。

作ったチャンネルを選択して

チャンネル基本設定から「Channel Secret」と「アクセストークン」をコピーします。
（ここはそこそこ危険なエリアなので、スクショはなしです）

スクロールしていくと、「LINE アプリへの QR コード」があるので、それを経由で登録してしまいましょう。
ちなみに近くにある項目の「自動応答メッセージ」や「友達登録時あいさつ」は邪魔になるので、「利用しない」に設定しておきます。

Heroku

次は Heroku にログインします。
なお、アカウント作成などは特に説明しませんのでご了承ください。

とりあえずこれで放置（笑

Codenvy

Codenvy にログインしたら

Codenvy

サイドメニューから
Workspace > add workspace を選択し、

• select stack : node
• projects : 「git」を選択して、「https://github.com/x-hack-git/line-messaging-api.git」を使わせてもらいます。

先に進むと、勝手に clone していじれるようになります。

terminal で unix コマンド使えるので Docker かなと思ったら Docker のようです。
10 分位放置するとコンテナ消される（汗

ターミナルに、Heroku のコンソールをインストール。プロジェクトルートに移動して

$ curl https://cli-assets.heroku.com/install.sh | sh
$ cd line-messaging-api

そしたら heroku にログイン

$ heroku login --interactive

ID/Pass は登録したものを使いましょう。

$ heroku create azalea-example-bot
$ git push heroku master

その場で heroku アプリ（兼リポジトリ）をこしらえて push 。
このあとで Heroku の画面をみてみると上がってる…

残りの環境変数設定

先ほど LINE から拾った 「Channel Secret」と「アクセストークン」を、Heroku に設定します。
先ほど作ったアプリケーションを開いて、「Setting」から「Config Vars」に設定します。

コラム: この手のパスワードを、ソースコードに絶対に書いてはいけません。github に上げようものなら、十数分でぶっこぬかれれ、最悪うん十万と支払いが飛んできます。

qiita.com

お次は、Heroku の右上の「Open App」を開きます。
おきまりの「Hello World」ですねーこの URL をコピーします。

最後は LINE Developper に戻って

WebHook URL に最後「/callback/」をつけて登録。WebHook 送信を「利用する」に設定します。

なんかバグっぽい挙動で、 WebHook送信の項目を後に設定しないと、なぜか設定が一部リセットされる模様。

ここまで来たら LINE を確認

初期動作仕様は、適当に喋ったらこんにちはで返してくれるのみです。

実際のハンズオンでは、ここから ぐるなびさん API と連携したりとか色々やりました。
とはいえ、中のソースをみる限りはシンプルに JSON でごにょごにょしてるだけ…！

Web 屋さんならお気づきだろう！なんでもできる…と！

というような内容でした。

メモ

リマインダー

明日の勉強会の準備と、昨日夜の勉強会の記事。
Heroku, Codenvy が中心だった。

カンバンを思い出しながらやってみた

単位はデイリーで。

個人でやる分にはいつ導入してもいい。
ということでカジュアルにやってみた。

カンバンのエリア

横方向に4つ、縦方向に二つで区切ってみた。
内容は、横方向に

1. Backlog
2. Todo
3. Doing
4. Done

のシンプル構成。
むしろシンプルで無いと無駄に時間がかかる。

上下方向は、以下の区切り。

• 事前に計画されたタスク
• 突発的に入ったタスク

突発はメールでも電話でも、相談でも打ち合わせでもいい。
30 分を超えたら付箋を貼るようにした。

出社直後

だいたいこんなことをやった。
今日は初回だったので、トータル 1h 程度かかった。

1. 優先度をみながら、その日にやっておくタスクをBacklog から Todo に引っ張る
2. 最大２時間の単位のタスクに区切る（ここで一気に枚数が増える）
3. 朝会で、他にどんなタスクがあるかを確認する
4. その内容を踏まえて今日の範囲を決める

午前の作業開始

ひたすらタスクの消化に専念。

1. Todo から Doing に引っ張っていき、処理する。
2. 決めなきゃいけないところや、時間がかかりそうな部分が見つかれば、迷わず付箋にして Todo に突っ込む。
   今日やるかどうかすらもまずは考えない。そして先に進む。
3. どうしても優先度の高い割り込みが入るようなら、Doing の作業で進んで無いものを思い切って取り消す。
   （中途半端に残ってると無駄に気になる）

昼

飯を食いながら棚卸し。
ここで、午前中に増えた付箋を今日やるかどうか、午後一でどれを相談すべきか決める。

やってて思ったのは、この時点で消化枚数が少ないと、そのヴェロシティ（進捗速度）が無駄に気になる。
気にするだけ無駄になると割り切って、進捗の悪いタスクを放置して、軽いやつから片付ける方針に変更。

午後一

昼に決めた相談物を、早速相談して決めてしまう。
決まらなければバックログに突っ込んで決まるまで放置することを決める。
（他の人のタスクにかぶる場合の方針。時間をかければ決まるというなら、決めるタスクを Backlog に放り込む）

いくつか不要なタスクとわかったので、右下の隅に重ねて放り込んだ。

午後

午前の進捗が微妙だったので、軽いものからさっさと終わらせる。
途中 30 分ほど時間がかかる微妙な点（Problem）が見つかったので、左下の隅っこに付箋を放り込んだ。

あとは午前と同様に付箋のタスクを消化して、Done に放り込む。

定時

今回は集中しすぎて定時に開始してしまったが、定時ちょっと前くらいにスプリントの振り返りを行う。
とりあえず Todo/Doing が空になってるのが理想。
空になってなかったら、何に時間がかかってるかを思い返して try とする。

今回は、他拠点との意思疎通の問題でロスがみられたので、明日以降特定タスクの前に関連箇所と近くの作業者のタスクを確認してからやろう…みたいな振り返りになった。
課題として意思疎通情報共有、空気感、温度感…複数拠点あるあるだよなーと思いつつ（汗

初日目感想

もともとスクラムはやってたので、スムーズに進んだ…というかトラッカーを（主に政治的問題で）思う様に利用できず、Excel ガンチャ管理の現場だったので、やってみる前とは雲泥の差だ。
昔は一人でやってた筈なのになんでやらなくなったのかと本気で思った。

いくつか再確認

• デイリーでやるならタスク粒度は長くて 3 時間で切らないと、ダレる。 2 時間以上かかったら、詰まってる部分を付箋切って Todo に突っ込む事を考える。
• タスクの消化量は精神的にクルので、（優先度が多少低くても）楽なタスクからやるのも十分あり
• 人の脳みそは複数を同時に処理する様にはできてない。それもあるので、同時に Doing できるタスクは二つまでに絞る。 （割り込みがあっても最大 3 が限界。あとは待ってもらう）
• 物理カンバンまホント偉大。
  • 画面切り替えなくていい
  • フォーム画面なんていちいち呼び出さなくても即付箋が書ける （もっと言うと、デイリーで回す粒度なら、既に細かいので詳細まで書く必要も無い）

メモ: 今週末に社内勉強会

今回ハンズオンなので、スムーズに行くように資料作る。

なお内容は、CI 環境構築。
Jenkins 前提にはするけど、もしかしたら CircleCI に鞍替えするかも？

更にメモ：明日LineBOT メイクのハンズオン。

x-hack.connpass.com

何ならCIに連携したいというノリ。

一人デイリースプリント初日目。 わかった事：カンバンは常に表示してる状態を保つか、物理的にあったほうがやはり迷わない。

KPT内容は、常に手元にあった方がいい。 タスク傾向の分析も兼ねて、30分以上作業したものは、付箋にしてみたが、コレチケットだと面倒かもしれない。 ipad 音声入力でカジュアルにできるカンバンあったら受けそう（主に私に

後は目の前に3個以上doingにしちゃダメだ。 迷うコストや頭を切り替えるコストは思ったよりデカい。

あと、面倒な物から片付けたいって心理は確かにあるのだけど、チケットが消化されないのを見ると心理的負荷になる。 そこに来ると、優先度が多少低くても数消費して、優先度の高い重いヤツは腰を落ち着けてやった方が効率が良かった。