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にしちゃダメだ。 迷うコストや頭を切り替えるコストは思ったよりデカい。

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

KPTが出てこないケース

カイゼン・ジャーニー読んでたら、ふと思い出したので。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

Keep Problem Try の頭文字で、スプリントの最後に、「こう言う事良かったね続けようか」「こういう所問題だったよね」「なら問題解決にこう言う事やってみようか」を行うのが agile では定例。
これをチームによって期間はまちまちだけど、こちらは 2 週間に1回やった。

で、問題があったプロジェクトは、これが全く回らなかった。
どういうことかというと、problem がその場限りの問題解決になってしまったのだ。

そもそもイテレーションの運用内部「このプラクティス無駄だよね、こうしてみない？」とかそもそもプロジェクト運用に関わる問題が出てきてくれる方が望ましい。
でないと取り組みが改しないのだ。

これが 2-4 イテレーション位なら疑問にお思わないのだけど、結局最終スプリントでもそんなだった。
問題がなかった？というのは考えにくい、大なり小なり問題はあったハズだ。

何が問題だったのだろう？そう考えた

心理安全が確保されてない？

これはあったかもしれない。
そのプロジェクトは遠隔地 2 拠点での開発だった。
当然情報の粒度や格差の問題は大なり小なり出る。

何より、相手の姿が直接的に見えない。
もっと言うと気づいていないだけで、各拠点が排他的な村になっていた可能性はある。

Agile のプラクティスには大体鉄則がある。
同じ場所でやること とアジャイル・サムライにはあり、実にその通りと実感する。

そうでなくとも、そうした事を理解したキーマンを両拠点に常駐させておくべきだったのかもしれない。

そもそもプロセスに無頓着

元々 SIer のニアショア拠点。言われた事への作業に慣れ切ってる。
果たしてその状況で開発プロセス自体が改善できただろうか？

そりゃ温度感が違うのにプロセスを見直す発想を求めるのは酷というものだ

後からなら何とでも言えるケースだが、こうした拠点でアジャイルするなら、有識者を常駐させ、好きに言える土壌を作らなければいかなかったのかもしれない。

改善の糸口が分からない

problem を出すときのコツは、自分がやってて詰まらないと思った作業、ド嵌りした事象だ。
ド嵌り事象は情報共有で済む場合もあれば、プロセスを変える事でそのポイントをそもそも回避できる場合がある。

何にしても言ってみる事が重要だったりする。

作業中とは面白いもので、上記のような事があっても喉元過ぎると熱さを忘れるものだ。
良くアプリが思ったように動かなくてイライラしているユーザも、どうすれば良いか分かった瞬間から問題に思わなくなる事象と一緒だ。
（いやそれユーザビリティが悪いんだからね？（汗）

SI 現場でそういうシーンは結構ある。

• テストを手動で回してテストデータでひーひー言う
  テストそのものを自動化する運用とするか、テストデータ生成を自動化する
• リリース作業で、手続きにチェックを入れながら…
  いや CI で自動化できる
• 仕様書を探してディレクトリを右往左往
  検索エンジン入れましょう、運用的にドキュメントの配置をルール化しよう…etc

みたいなことが往々にしてある。
これらを解決可能だと思ってないか、過小評価して（だから改善するまでもないと思って）いるケースが多い。

どうすればわかるのだろう？
個々人が、30分以上同じ作業をしたらとりあえず紙に書いてみるという、要するに時間の使い方の見える化だろうと思う。