Docker コマンド備忘録

Docker + Go + Gin の開発環境を準備する - Qiita
を書いた時に学んだことを残しておきます。

参考サイトから必要最小限だけ抽出しただけなので、
Qiita ではなく自ブログに記載してます(汗)

イメージビルド

# --no-cache 構築時にイメージのキャッシュを使わない
# --pull 常に新しいバージョンのイメージ取得を試みる
# --force-rm 常に中間コンテナを削除
docker-compose build

イメージ一覧

docker images

イメージ削除

docker rmi <イメージ名>

# 全削除
docker images | awk 'NR>1 {print $3}' | xargs docker rmi

# タグなしのイメージをすべて削除する
docker images | grep '<none>' | awk '{print$3}' | xargs docker rmi

コンテナ作成・起動

# -d バックグラウンド実行
docker-compose up -d

コンテナ一覧

# -a 全コンテナ表示(デフォルトは起動しているコンテナのみ)
docker ps -a

コンテナ起動

# 再起動も出来る
docker-compose start
# docker-compose restart

コンテナ停止

# 削除しません
docker-compose stop

コンテナ削除

# -v ボリューム削除
docker-compose down

# 全削除
docker ps -a | awk 'NR>1 {print $1}' | xargs docker rm

コンテナログ確認

# -f 表示しつづける
# -t タイムスタンプの表示
docker-compose logs

コンテナ接続

# コンテナ名、コマンドは docker ps -a で確認出来る
docker exec -it <コンテナ名> <コマンド>
# 例 docker exec -it ubuntu_bash bash

ボリューム確認

docker volume ls

ボリューム削除

docker volume rm <ボリューム名>

# リンク切れ削除
docker volume ls -qf dangling=true | xargs docker volume rm

PlantUML を導入するのに適したケースとは

半年ほど PlantUML を触った感想をまとめています。

結論

以下のいずれかに当てはまる場合、PlantUML はプロジェクトの生産性を向上させます。

  • 一人で利用する場合
  • 少数精鋭、もしくは統制(教育)されたチームで共有したい場合
  • 情報共有ツールがすでに浸透している場合

PlantUML が解決している課題

  • UML を理解していなくてもそれっぽい図が書ける
  • 誰が書いても体裁が揃う
  • 検索が可能
  • バージョン管理システムと合わせると履歴管理の生産性が向上する

PlantUML は「書く」こと、また適切なツールと併用することで「調べる」ことの生産性を向上させます。

PlantUML の課題

  • 学習コスト
  • 環境構築

学習コスト

最大の課題は学習コストです。

公式サイトから和訳されたリファレンスが PDF でダウンロードできますが、100ページを超えています。( 大変ありがたいことです。) また、先日話題に上がった Real World PlantUML を見て回るにしてもベストプラクティスに迷います。( 素晴らしいサイトです。)

その他によく参照するチートシート(記事)を記載します。

環境構築

環境構築については、情報共有ツールやエディター、ブラウザのプラグインなど充実してきています。PlantUMLサーバーも公式・非公式とも選択肢があります。これは昨年夏以降ほぼ解決したと言って良いのでは?とさえ感じています。

gitbook etc...

PlantUML 以外の課題

  • 個々人のスキル
  • 円滑なコミュニケーション
  • 文化・慣習・雰囲気
  • 怠惰
  • 置かれているステージ
  • 最終的な成果・結果

etc

導入フローを検討してみる

gist.github.com

PlantUML と向き合うポイント

  • 頑張らない
  • 気にしない
  • 抱えている課題が PlantUML で解决できる課題かどうか見極める

2017年の振り返り、そして 2018年へ

JET STREAM を聞きながらブログを書いています。

今年は人生の中で忘れられない年になりました。

新しい家族

春をすぎる頃に二人目が生まれ、生活が180度変わりました。そんななか会社やチームメンバーにも支えられ、奥さんが体力的に一番厳しい時期をサポートすることが出来ました。( 自分は出来たと思ってるだけで、直接評価を聞くのは怖いです^^; )

大仕事を終えた奥さんには感謝しかありません。

退職、フリーランス

前職はとても素晴らしい環境でした。できればもう一つか二つ、新しいプロダクトを作りたいという気持ちもありました。ただ 2016年に起きた熊本地震以降、熊本の両親、家族を大切にしたいという気持ちが強くなり、家族を連れて帰郷する決心をしました。

引っ越しはこれからですが、前職のプロダクトのお手伝いをさせてもらいながら、熊本での新しい生活の準備をしています。

個人開発

Android アプリ黎明期に、カメラアプリ を作って公開していましたが、その手の仕事につくこともなく、Google Play での公開も終え、5年ほど仕事一筋な生活を送っておりました。

今年はフリーランスになるということで、触る機会がなかった Vue と React で Webアプリケーションを作ってみました。

PlantUML Editor

plantuml-editor.kkeisuke.com

これは Qiitaブログ にも記事を書いていますが、仕事や個人開発で大活躍しています。

初めての Vue でしたが、公式サイト が充実していて、楽しんで構築ができました。Vuex も学習コストが低く、もっと早く使いたかったなと。直近では CodeMirror を導入したり、2018年も開発を続けて行きます。

Utility

utility.kkeisuke.com

二つ目は SQLJSON をフォーマットするアプリです。これは React、MobX という構成で、UI には Semantic UI React を採用しています。仕事で API の吐き出す JSON や、SQL のログを漁ることが多いので、こちらも自分専用アプリになってます。

Semantic UI React はもはや HTML ではない感じで、input タグでアプリケーションを作るという苦行も後数年かなと希望が持てました。

PlantUML Editor、Utility 共に Netlify で運用しています。プランが寛大すぎて、大変素晴らしいです。

GitHub Pages から カスタムドメインで HTTPS 対応したくて Netlify に引っ越した際に検討した内容 · GitHub

その他

qiita.com

Qiita にも5件ほど記事を書いたり、ブログも2件ほど書きました。

来年も時間を作ってアウトプットしていきたいです。( 寝かしつけを引き受けてくれている奥さんに感謝です。)

2018年

2017年は家族や将来のことを考えに考えた1年でした。また、改めてプロダクトを作ることが自分のやりたいことだと実感した1年でもありました。2013年から4年かけて立ち上げから運用まで行ったプロダクトも第一線を譲り、また新しい目標を探してもがいてみようかと思います。できればもっともっとユーザーの近くでプロダクトを作っていきたいなと考えています。

PlantUML Editor の要求/要件定義

細々と作っていた PlantUML Editor ですが、公式アカウント?から「Nice」を頂いたので、改めて要求や要件などを必要最低限まとめておきたいと思います

概要

PlantUML Editor はブラウザ上で PlantUML を試すことができるWebアプリです

背景

  • esaKibelaDocBase などの情報共有サービスや、Crowi、GitLab など PlantUML 対応が充実してきている
  • エディターについても atomvscode の PlantUML プラグインが普及している
  • フロントエンド分野でも DDD の機運が高まりつつあり(国内)、今後も UML の需要が維持もしくは向上することが見込める

一方、課題も見えてきている

  • 未経験者が手軽に PlantUML を試せる環境がない
  • 各種情報共有サービスが利用できない。あるいは Crowi、GitLab などの運用もままならない場合
    • 小規模、社内規定、予算都合 etc

技術的な要因等は Qiita にまとめています。
vue-cli (vuex) で PlantUML エディターを作ってみた - Qiita

コンセプト

  • 未経験者、初心者が手軽に PlantUML を試せること
  • 各種情報共有サービス等に移行しやすいこと
  • 小規模、個人の場合は継続して利用できること
  • PlantUML の良さを広めることに寄与できること
    • 上司、チームメンバー etc

対象ユーザー

  • PlantUML 未経験者、初心者
  • 各種情報共有サービス等の導入を検討している人
  • 個人アプリ制作などで PlantUML を利用したい人
  • これから PlantUML を社内で広めていきたい人

ユースケース

PlantUML Editor ユースケース図

競合

機能要求

  • テンプレートを準備する
    • 新規作成をできるだけ簡単にする
  • チートシート機能
    • note や direction など
  • 画面サイズを超える UML にも対応
    • 拡大縮小
    • 画像スクロール(縦横)
  • 出力は SVGPNG に対応
  • UML の出力はキーバインドとボタンを用意する
    • 最初はボタン。慣れてきたらキーバインドと使い分ける
    • リアルタイム処理は PlantUML サーバーへの負荷が怖いので避ける
  • 保存機能(履歴機能)
    • 継続利用するため。オリジナルのテンプレートとしても使える
  • SVG, PNG のダウンロードに対応
    • Excel 添付などしやすいようにする
  • Gist 投稿機能
    • secret 対応し共有しやすくする

非機能要求

個人アプリなので、運用に費用や労力を掛けることができない。できる範囲で運用を行う

  • 永続化
    • localStorage, indexedDB
    • DBサーバーなどは用意しない
  • アプリケーションサーバ
    • GitHub Pages で運用する。リポジトリGitHub に準備するので、デプロイも効率化される
    • HTTPS 対応するため Netlify で運用する。GitHub 連携機能があるので、デプロイも効率化される
  • PlantUML サーバー
    • PaaS の無料範囲内で運用する。今回は Heroku を採用する

テスト

これから準備していく

  • 複雑な業務ロジック等がないため、単体テストより E2E テストを整備していく
  • UML図(画像)の比較も行いたい

最後に

2017年8月末で6年勤めた現職を退職し、個人事業主になります。
2018年には宮崎から地元の熊本へ拠点を移し活動予定です。(退職理由は引っ越しです。)
少しでも興味をもって頂けましたら、ご連絡いただけると幸いです。
宜しくお願い致します。

PM するときに必ず見返すスライド、ブログ記事

今(2017/02/19)はBtoBで5名~10名程度(時期変動)のプロジェクトマネージャー兼プロダクトマネージャー兼SE,PG,雑用 etc 的なポジションで仕事をしています。折に触れてよく見返すスライド、ブログ記事があるのでまとめておきます。(人におすすめするときに毎回探さなくて良いように)

  • 2017/03/05 参考記事を追加しました。
  • 2017/03/17 参考スライドを追加しました。

参考スライド

開発組織のマネジメント // Speaker Deck

以下、メモ (感想とか、日々の反省とか)

  • 全体最適
    • ステークホルダーからの短期的な意見に対して、中長期的な目線を必ず入れること。また、説明し説得すること。
    • ともすると自チームの利益だけ考えすぎだが、もっと広範囲で有益であればやる。誰かがやらないといけないことは自分たちでやる。(自分たちが標準になる。結果さえ出せばそれが標準になりうる。)
  • 自己組織化チーム
    • アサイン権限がなくとも、ステークホルダーを自チームに引きずりこむこと。
    • なんでも自分たちでやってみる。企画、カスタマーサポート、営業。(それでも専門家がチームにいてくれるにこしたことはないけれど。リソース的にも辛いので。)
    • 人の出入りが多い場合もそれを想定したプロジェクト運営を日頃から行う。ナレッジを残し共有する工夫をチームでやり続けること。逆に思い切ってやらないことを決めてリソースを捻出する

開発組織マネジメントのコツ // Speaker Deck

以下、メモ (感想とか、日々の反省とか)

  • 問題発見
  • 対メンバー
    • メンバー同士だけで議論できるように持っていく。うまくいっているときは口を出さない。
  • コントロールできる対象をマネジメントする
    • 文化は結果であり、コントロールできない。日々の小さな意思決定を少しづつ変えていく。
  • 心理的安全性と責任
    • 無関心領域にいる人をどう引き上げればよいか。。。
  • 期待値調整 (フレーミング)
    • チーム内もそうだけど、ステークホルダーとの期待値調整も難しい。でもやらないと確実に失敗する。
  • 信頼を勝ち取る
    • 実績、結果を出さないと得られないけれど。。。
  • 指示待ちが得
    • 反面教師。待っててもいいマネージャーだと思われてる。
    • 逆に一挙手一投足ほうれんそうする人。これも反面教師。
  • 良いプロダクトと良いチーム
    • 「君のチーム、社内では技術力ある方だけど結果出てないよね」と遠回しに言われたこともある。

不確実さとうまく付きあうサービス開発 // Speaker Deck

以下、メモ (感想とか、日々の反省とか)

  • ユーザーを知る
    • 行動、価値観、文脈(背景)
  • チームで発想する
  • サービスのリリースはスタート
    • という期待値をステークホルダーと事前に合意しておくこと。スタートだと思ってるのがエンジニアだけだと灰になってしまう。
    • 営業組織に影響力がある場合(BtoB)、まずそこにファンになってもらえないと、ユーザーまで届かない。(売れない以前に売ってもらえない。)
    • 営業組織への営業力が必要。
  • コンパス
    • ユーザー(課題)、価値、体験、機能
  • 確かめながら作る
    • フィードバックが多すぎて納期に間に合わなかったらどうしようという不安との戦い
    • 「売れない、売ってもらえない」「ユーザーにガッカリされる」よりは納期が多少遅れて非難されるほうがマシ。(と腹をくくる。程度やケースの問題でもあるが。)

Qiitaの作り方 〜Incrementsのチーム開発とプロダクトマネージメント〜

参考記事

seleck.cc

  • 書いてある通りにやる。

blog.kentarok.org

  • 書いてある通りにやる。

techlife.cookpad.com

ozyozyo.hatenablog.com

  • 今どの段階か説明したり、俯瞰的にみて現在置を確認したり

blog.kentarok.org

  • 戒め

http://blog.yamotty.com/entry/20161228/1482881400blog.yamotty.com

  • 売上は全てを癒す
    • 戒めその2

yappy727.hatenablog.com

  • 2017/03/05 追記
  • 身につけるべきスキル一覧
  • 全然足りて無くて凹みます。また、プロダクトマネージャーの必要性、重要性が分かる資料。(専任が必要)

yappy727.hatenablog.com

  • 2017/03/05 追記
  • 各フェーズ毎の解説