JibでDockerイメージビルド時にエントリポイントを設定する

今従事しているプロジェクトでは Jib が使われており、ビルド時にエントリポイントするにはどうしたらいいかを調べたので備忘録として残します。
(Kotlin を使ったアプリケーションで jib-gradle-plugin を使っています)

結論のみ述べると container で entrypoint を設定し、extraDirectories でパーミッションの変更を行います。
ただ一点注意が必要で、Jib のデフォルトのイメージは distroless/java なので shell を実行したい場合はイメージを変える必要があります

1
2
3
4
5
6
7
8
9
10
jib {
container {
entrypoint = ['docker/entrypoint.sh']
}
extraDirectories {
permissions = [
'/docker/entrypoint.sh': '755'
]
}
}

手軽にDocker イメージを作るのに Jib は便利ですが、USE_CURRENT_TIMESTAMP をつけないと昭和なイメージになるなどちゃんとドキュメントを読み込まないとハマる点が多いと感じました

Ref

アウトプットしないのは知的な便秘

1月に開催された ssmonline#6 のテポさんの発表「アウトプットしないのは知的な便秘」に刺激を受けての更新です。
更新できませんでした、みたいな内容の更新は嫌だと思っていたら2年経っていました…

最近個人的に勉強しているもの

最近は Golang と Kotlin を勉強しています。

Golang

Golang はチームメンバーと Golang 書けるようになりたいね、という話になり勉強会を開くことになったことがきっかけです。
せっかくなら実用的なものにしたいと、既存プロダクトの API を Golang で作り替えることを目的に週に1回30分~1時間程度とりくんでいました。
API 1本完成したくらいでその勉強会は終わってしまったのですが、その後は個人で機会を見つけて書くようにしています。

年末年始は learn-go-with-tests写経していました。
「TDD、なんとなく知ってはいるけれど実践したことはない」という状態だったので TDD と Golang が両方学べるとてもありがたいレポジトリでした。
社内で Golang 勉強していると聞いたらこちらのレポジトリをおすすめしています。

最近だと、新しいプロジェクトが始まり実装タスクごとに Github 上に issue を立てる必要があったので issue を作るアプリケーションを Golang で書いてみました。
今は JSON で指定された内容から issue を作る機能しかないので、追々拡張していけたらいいなと考えています。

Kotlin

Kotlin は上述の新しいプロジェクトで使われている言語なのでキャッチアップも兼ねて勉強しています。
(昔、勉強がてら書いた覚えがあったのでレポジトリを探したら2年前でした。早いなぁ…)

Java と違ってメソッドを変数みたいに書けるのは面白いなぁと思います。

1
2
3
public String hello() {
return "Hello Java";
}
1
fun hello() :String = "Hello Kotlin"

さいごに

アウトプットしないのは知的な便秘 は私にとって身が引き締まるいい言葉でした。
前ほどではなくても何かアウトプットしていきたいと思います。

来週は Java 16 リリースですね

久しぶりの更新

Qiita 投稿一覧サイトを2系にしました

以前作ったQiita 投稿一覧サイトを2系(v2.8.1)にしました(最初のコミットしたの2年前になるのか…)
機能が少ないこともあり、基本的には2系で変更された設定回りを変更するだけで済みました。
対応ついでにテストフレームをavaからjestに変え、CircleCiと連携するように。少しモダンになった…!

3系がリリースされたら、storeの見直し/変更と併せてもうちょっとテストを書く予定です(Qiitaは3系がきたら更新しようかな、、)

最近教えてもらったんですが、テストケースをスキップしたり、todoとしてディスクリプションだけ書けるのはとても便利ですね!

VueFes 2019

昨年はチケットが即完売して参加できずに終わったVueFesですが、今年はご縁がありスタッフとして携われることになりました。
(ティザーサイト、一部実装を担当させてもらいました)
会社以外でチームを組んで何かに取り組むというのはいい経験だなと有難く思っています。
いいカンファレンスになるように準備、頑張ります。

体重の推移を可視化するリポジトリのアーカイブ

こちらも以前作ったものですが、メンテできそうにないのでインデントと使用ライブラリのマイナーバージョンアップのみ行い、アーカイブすることにしました。
今見れば「これ、コンポーネントに切り出さなあかんやつや…」と思うくらい密結合しているページなんですが、そう思えるようになったのは成長した証かな
可視化するのはテンションがあがるので、またこのリポジトリをメンテするか、この構想を元に別の何かに繋げられたらいいなーと思っています。

ref: nuxtとbuefyを使って日々の体重の推移をグラフで可視化する

もう8月

先月は更新できなかった…

更新はなかったものの、インプットがとても多く新たな気づきがあり、実りの多い月でした。
関わってくださった全ての方に感謝です。
時間をかけて咀嚼/補強していきます。

これからの取り組み

今月から以下の3つに取り組みます。

  • 既存のアプリケーションのリファクタリング
  • 認証機能のあるWeb APIの勉強
  • このブログのSSL化

既存のアプリケーションのリファクタリング

主にnuxtを使ったアプリケーションを見直そうと思います。

認証機能のあるWeb APIの勉強

これまで自前で実装したことがなかったので勉強がてら挑戦します。
先日JWTを少しだけ触りました。不完全燃焼なので実装完了させたい。。。

このブログのSSL化

「not secure」が出るページがあることに気付きました。
なんでだろう。。。調べます。
こちらが原因でした。
リンク先の画像のURLによって出ていたのでどうかな、対応しないかもしれません。

その他

nuxtの翻訳、年内に一度全てのページの翻訳を終わらせられたらと思い
空き時間にちょこちょこ取り組んでいます。
OSSのドキュメント、新しい技術を知るのにも役立ちますね!
英語力…は向上しているといいなぁ。

そういえば先日、直接プルリクを送りマージして頂けました。(Gitlocalizeはjson形式のファイルをサポートしていないため)緊張しました~

CS

CSの勉強会に参加しました

先日、CSとプロジェクト進行をテーマにした勉強会に参加してきました。

なんで参加したのか

以前、デザインについての勉強会に参加した際に
「カスタマーサクセス」というワードを初めて知り興味を持ったのと
プロジェクトの進め方について情報を得たかったからです。
ワークショップ形式なので参加者と話しやすいだろうという考えもありました。

CSとは

カスタマーサポートまたはカスタマーサクセスを指します。
最近はカスタマーサクセスと呼ばれていることが増えているようです。
UI → UX のような潮流を感じます。

プ譜

「プロジェクト譜」の略でプ譜には以下の5点を記述します。

  1. 獲得目標
  2. 勝利条件
  3. 廟算八要素(人材、予算、技術、品質、納期、環境、競合、外敵)
  4. 中間目的
  5. 施策

プロジェクトの状態に応じてプ譜を改訂し獲得目標を達成に導くという
まさに「プロジェクトの系譜」となるものです。
PDCAを体系的に表せるなと思いながら聞いていました。

詳しいことは以下を参照してください。

ワークショップ(プ譜作成)

架空のカスタマーサポート課に在籍している体で臨みました。

カスタマーサポート課の背景

1
2
3
4
BtoBの会社で、自社製品のお問い合わせサポート窓口となっている。
使い方などに関してはサポート課で回答し、技術的なことは開発に回答をもらっている。
サポート課からの問い合わせに対し、開発のレスポンスが悪い。
近頃、クレームやクレームに発展しそうな問い合わせが増えてきている。

それに対して作成したプ譜の内容

  1. 獲得目標:お客様の問い合わせを通し、会社にいいサイクルをもたらす起点となる。
  2. 勝利条件:
    1. クレームメールの減少
    2. カスタマーサポート課から製品のユーザビリティ向上に寄与
  3. 廟算八要素
    1. 人材:カスタマーサポート課のメンバー(3名)
    2. 予算:特になし
    3. 技術:タスク管理ツール(Redmineなど)
    4. 品質:基本はメールでのやりとりのみ。場合によって電話有
    5. 納期:順次
    6. 環境:同一社内
    7. 競合:-
    8. 外敵:回答/対応の遅い開発チーム
  4. 中間目的
    1. 対応内容の速度の向上
    2. テンプレートなメールを避ける
      • ↑「いい対応」の共有がカスタマーサポート課内で出来ている
  5. 施策
    1. 開発チームと対面で話す場を設ける
      • 温度感の共有
      • 場合によっては開発チームの部長を巻き込む
    2. 自分がプライベートで問い合わせを行った際によかった対応、不愉快だった対応を共有
      • セミナーへの参加
    3. (場合によっては)開発チームの部長を巻き込んで

#書き起こすにあたって文面をキレイにしましたが大筋はズレていません。
短い時間の割には考えられたんじゃないかと。実行できたら素敵。

発表を聞いていると、獲得目標に目標値を明確に打ち出している人が多かったです。
定量的だと評価しやすいもんね。

モデレータの前田さん曰く、獲得目標は定性/定量的どちらでもOKだけど
定性的なほうが自由がきくと話されていました。

個人的には、獲得目標はブレない根幹となるものを定性的に掲げ、
中間目標や勝利条件を評価しやすい定量的な目標にするのがやりやすいかなと感じました。

プロジェクトの過程が体系的に見て取れるのは面白いし大事だと思う。
根気がいるな…

参考

Windows7でiOS11のsafariをデバッグ

仕事で iOS の safari をデバッグする機会があったので手順を備忘録として残します。

  1. (未インストールの場合) iTunes をダウンロードする
  2. (未インストールの場合) Node.js をインストールする
  3. コマンドプロンプトを管理者権限で起動する
  4. コマンドプロンプト上で npm i -g remotedebug-ios-webkit-adapter を実行
  5. remotedebug-ios-webkit-adapter の zip をダウンロード
  6. %AppData%\npm\node_modules\remotedebug-ios-webkit-adapter\node_modules\vs-libimobile\ios-webkit-debug-proxy-1.8-win64-binという名前のフォルダを作成
  7. 6 で作成したフォルダの中に zip の中身を展開
  8. %AppData%\npm\node_modules\remotedebug-ios-webkit-adapter\out\adapters\にあるiosAdapter.jsファイルの 132 行目あたりのconst proxy=...を以下の値に修正
1
2
3
4
const proxy = path.resolve(
__dirname,
"../../node_modules/vs-libimobile/ios-webkit-debug-proxy-1.8-win64-bin/ios_webkit_debug_proxy.exe"
);
  1. 確認したいデバイス(iPad など)を接続
  2. コマンドプロンプト上でremotedebug_ios_webkit_adapter --port=9000を実行
  3. Chrome を開き、アドレスバーにchrome://inspect/#devicesと入力
  4. 設定を開き、localhost:9000を追加
  5. 確認したいデバイスの safari の設定(設定 > Safari > 詳細)の
    「Web インスペクタ」を有効化
  6. safari でデバッグしたい url を開く
  7. Chrome の Remote Target に safari で開いた url が表示されるので inspect をクリック
  8. 表出したウィンドウでデバッグ

ブラウザ間の挙動の違いには、いつも泣かされます。。。

参考

Debug a Website in iOS Safari on Windows 10

新しい言語に挑戦してみる

5月に突入しました。
来月で2018年の半分が終る…いつもながら時の経過の早さに驚きます。

4月は新入社員と覚しき人達を見かけることが多く
初初しいなぁと微笑ましく見ていました。
そんなフレッシュさに触発され、新しいことを始めるにはいい季節!ということで
先月は新しい言語と経験言語の復習に挑戦しました。

ProgateでRuby,Pthon,Saas,Java,SQLを、
Goは公式サイトでチュートリアル(Basicsまで)をこなし、
AidemyでPython入門に取り組みました。

Progateは各言語で題材が似ているので
途中、食傷気味になりつつも表現の違いが比較しやすく、楽しく学べました。
Saasについて理解していなかったのでやってよかったです。

Golangはなんと言っても速い。
ポインタがあることにびっくりしました。

たまには入門もいいですね。
今後もちょこちょこ続けていこうと思います:)


このブログについてですが、masterブランチが更新されたら
firebaseにデプロイされるようGitlab CIと連携させました。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#.gitlab-ci.yml

image: node:latest

cache:
paths:
- node_modules/

deploy_production:
stage: deploy
environment: Production
only:
- master
script:
- npm install -g firebase-tools hexo-cli
- npm install
- hexo generate
- firebase use --token $FIREBASE_DEPLOY_KEY production
- firebase deploy -m "Pipeline $CI_PIPELINE_ID, build $CI_BUILD_ID" --non-interactive --token $FIREBASE_DEPLOY_KEY

これで更新が楽になりました〜

【参考】
Automatically deploy to Firebase with Gitlab CI

ブログ移行しました

はてなブログから移行しました。

レイアウトやコンテンツは調整中なのですが
今後はこちらを更新していこうと思います。

先日、VuePressを知りました。
ブログは今後対応予定とのことで楽しみ。

それからNuxt.jsの翻訳、guide部分完了しました!

なぜか102%になっているパートがあるけど、気持ちの現れとして気にしない(`・ω・´)

GitLabはじめました

遅ればせながらあけましておめでとうございます。
もう1月が終わるなんて・・・。
1月は往く、2月は逃げる、3月は去るとはよく言ったものだなぁと思います。

ゆるりスタートでしたが、旧友と再会したり
今後取り組みたいことの具現化を勉強会でしてもらったり
今月は刺激を貰えた月でした。

今年も張り切って進めそうです (´◡`*)

さて、タイトルにあるとおり、GitLabをはじめました。
理由としては、プライベートリポジトリやCIが無料で行えるためです。
手探り状態ですが、少しずつ進めていこうと思います。
#当初、タイトルを「GitHubからGitLabへ移行しました。」としていましたが、並走して使うことにしました。

今年も1ヶ月に1回程度ゆるりペースで更新していけたらと思います。
どうぞよろしくお願いします。

2017年の振り返り

2017年も残すところあと数日。
この一年を振り返ろうと思います。

インプット、アウトプット

昨年は会社が変わり案件を進めながら言語やフレームワークを学ぶ日々だったので
いろんな意味で毎日がエキサイティング、1年があっという間でした。

今年は余裕が出てきた分、いろんな面で
周りに目を向けられるようになったと思います。

外部の勉強会(JJUG CCC 2017 Spring)への参加や、
このブログを始めることができました。

Qiitaにも記事を投稿しました。

ビュー数もかなり異なると思いますし
ブログは主に自分向けのメモ、Qiitaは他の人へ説明する場、
問いかける場として使い分けたらいいかなと思っています。

いいねを押してくださった方、Starを下さった方 ありがとうございます!
とても励みになりますm(*_ _)m

働き方

いろんな職場を見たい、もっと経験を積みたい、リモートワークをしてみたいと思い
秋ごろから副業やフリーランス向けのサービスに複数登録、話を聞きに行きました。
一つの選択肢として来年も模索したいと思います。

来年の抱負

今年はどちらかといえば単体の技術(vueやkotlin、spring boot)について
学ぶことが多かったので来年はもう少し複数のサービスを組み合わせた
システムを構築したいと思います。
継続的インテグレーションを行いたいし、ガジェットにも手を出したい。
OSSのコミッターも目指したいし、勉強会等にも もっと顔を出して社外のつながりを作りたい。

「人生は何事をも為なさぬには余りに長いが、何事かを為すには余りに短い」
何事も楽しみながら取り組みたいです:)

モダンなフロントエンドの開発についていきたい

元々CやC++がメイン言語のスタンドアローンな
サードパーティー(デスクトップ)アプリを作っておりweb業界歴は1年と半年未満。

最初はjavaのガベージコレクションに戸惑い、
javascriptの変数定義で厳密な型定義をしないことに落ち着かず
コードレビューでは「いかにもCっぽい書き方だねぇw」といわれドギマギし
デプロイ後には原因不明のエラーがインフラ側に問題があるのか、問題の切り分けに混乱してました。

頭が固いのと視野が狭かったので
ライブラリなし、ボイラープレートコード満載の自前実装が多いのが悩み。
最近ようやくライブラリに目を向けたり
作りを見直したり改善へ目を向けられるようになってきました。

そんな中、大きく立ちはだかるのはフロント側の実装。
正直、何がなんだかよくわからないw

今はほとんど一人で担当しているので問題ないと言えばないけど
今時なフロントエンドの開発は出来るようになっておきたいなぁ。
目下の目標はwebpackとvueあたりが
使えるようになることでしょうか。

インフラの知識も欲しいし、やりたいことが沢山。
目標を語るだけではなく、インプット/アウトプットもしていかないと。

それにしてもその内、バックエンドやフロントエンド等の
垣根はなくなっていくんだろうなぁ。

GallupのStrengthsFinder

友人に勧められて受けたGallupのStrengthsFinder
企業によっては入社時に受けられるそうです

TOP5の資質は以下のようになりました

1
2
3
4
5
学習欲
責任感
回復志向
分析思考
ポジティブ

自分としては8割程度 的中しているかな(*´-`)

今の職業は自分の資質に合っているようです

とりあえず現状のスタイルで問題なさそうなので
興味のあることはどんどん取り組んでいきたいと思います(`・ω・´)

Spring BootとThymeleaf、lombokに触れてみる(2)

昨日は一覧表示部分のみ作成したので
ボタン押下遷移先などを引き続き制作します。

ボタンのリンク先設定でつまりました。
みんなformのacitionで送ってるけど、
ボタン押下で飛ばしたい場合は表記をどうすれば・・・

いろいろ検索してボタンをaタグで括る方法を見つけました。

1
2
3
<a href="" data-th-href="@{/show/__${user.id}__}">
<button class="btn btn-info" >Query</button>
</a>

いけた・・・!

思うところがあり、最終的にこうしました。

1
<button class="btn btn-info" th:attr="onclick='location.href=\\'/show/__${user.id}__\\''">Query</button>

エスケープ処理の多さよ。。。
もっといい書き方あるんだろうけど、今はこれが限界。

Thymeleafのタグの理解がまだまだ浅いなぁ。

Spring BootとThymeleaf、lombokに触れてみる

MkyongさんのMVC解説「Spring MVC form handling example」の
ソースをベースにSpring BootとThymeleaf、lombokに触れてみる。

具体的には以下4つに取り組みます。

  1. Spring Boot使用
  2. jspをThymeleafを用いたhtmlへ変換
  3. lombok使用
  4. O/RマッパーにDomaを使用

これまでSpringはMVCを扱っていたので、流行のBootを触ってみたい、
画面もjspを扱っていたので、Thymeleaf使ってみたいという衝動に駆られ。
lombokも扱ったことがないので(ry

Domaはlombok相性が悪いと聞いたけれど
公式にサポート概要が出ていたので実践!

一覧だけ作成。
ちゃんと表示できた:)

今日の所感:
lombokすごい。
bootも楽ちん。
Thymeleafはまだよく分からない・・・。