タイトルに惹かれて「限りある時間の使い方」を読んだ．僕は日常的に "忙しく時間がないなぁ..." と感じることが多い（忙しいフリをしているだけの可能性もある）．やりたいことは多いけど全然処理しきれず，常に何かしらを犠牲にしているというモヤモヤもあって，本書を読んでみることにした． 僕自身は "意識高い" 自己啓発本が大好きではあるけど，本書はそういった「ライフハック本」ではなく，○○をしろ！○○はするな！という内容ではなかった．もっと哲学的な内容が多く，根本的な "何か" を気付かせてくれる感じで，人生や時間について考えながら読み進めることができた．また本書で繰り返し出てくる「生産性オタク」や「完璧主義者」はまさに僕自身のことを揶揄しているようにも感じられて，時間をコントロールしているはずなのに常に何かに追われているという点は非常に刺さった．他にも刺さった箇所は「読書メモ」に箇条書きにして

ID を採番するときによく使われる UUID Version 4 の課題として「順序性がなくソートしにくい」という側面があり，ULID (Universally Unique Lexicographically Sortable Identifier) を使えばソートできるようになるという記事を前に書いた． kakakakakku.hatenablog.com 関連して調査をしていたら，標準化団体 IETF (Internet Engineering Task Force) によって，UUID Version 6, 7, 8 という新しい仕様が提案（ドラフト段階）されていることを発見した❗️UUID Version 6, 7, 8 の目的を簡単にまとめると「タイムスタンプ情報を使ってソートできる ID を採番できるようにする」となり，もしこの仕様が取り込まれると，UUID を活用する幅がさ

個人で使っている Git リポジトリ（GitHub リポジトリ）の中に「複数ブランチを並行して操作する頻度が高いリポジトリ」がある．例えば，以下のように「4個」のブランチがあり，どれも操作する可能性がある場合など．今までは頻繁にコミット（git commit コマンド）をしてからブランチを切り替えたり，一時的に退避（git stash コマンド）をしていたけど，頻度が高くなると少し面倒だった． master or main ブランチ branch-a ブランチ branch-b ブランチ branch-c ブランチ git-worktree（git worktree コマンド） 操作を改善するために調べたところ「git-worktree」という機能があった．今まで知らなかった！そして Git 2.5（2015年7月リリース）から使える機能だった📣「git-worktree（git wor

2020年12月に出版された「モノリスからマイクロサービスへ」を読んだ．本書はタイトルの通り「マイクロサービス移行」に関連するトピックにフォーカスしている．マイクロサービスを学ぶならこの本！とよく紹介している「マイクロサービスアーキテクチャ」の著者 Sam Newman の続編となる．原著「Monolith To Microservices」は，2019年12月に出版されている． 僕自身は技術講師として「マイクロサービス」に関連した研修を担当していることもあり，本書は絶対に読もう！と楽しみにしていた（原著は読もう読もうと積読していた😇）．今回は本書の翻訳を担当された島田さん (@snoozer05) とレビューを担当されたこまさん(@koma_koma_d) からご連絡をいただき，本書を献本していただいた．本当にありがとうございます！ モノリスからマイクロサービスへ ―モノリスを進化させ

「n8n.io」を使うと GitHub / Slack / Google Sheets など多くのサービス（ドキュメントを見ると 240 以上もインテグレーションできる！）を組み合わせて自由に「ワークフロー」を構築できる．関連サービスで言えば IFTTT のような感じ！例えば IFTTT Pro に課金せずにセルフホスティングできたりする．今回は「n8n.io 入門」を目的として Mac で Docker を使って「n8n.io」を試す．現状だと Docker と npm (npx) で試せる．なお，SaaS として使える「n8n.cloud」もある（最近まで coming soon になっていた）． n8n.io n8n.io 入門 : 完成形 今回は「GitHub リポジトリに対する Star⭐/ Unstar⭐をトリガーに Slack 通知とコマンド実行に条件分岐をするワークフロー」

研修中に「マイクロサービス」の解説をしていると，たまに「モノリス分割」に関する質問が出てディスカッションをすることがある．当然ながら万能な分割アプローチはないけど，例えば DDD (Domain-driven design) などのアプローチを選択するなど，選択肢はいろいろある．そして最近「モノリス分割」に役立つアプローチを紹介した martinfowler.com の記事「How to break a Monolith into Microservices」を読んだ． 具体的には以下の「計8種類」のアプローチが紹介されている．原著を翻訳するのではなく，あくまで個人的なメモとしてまとめる．なお，日本語も個人的に載せているため，参考程度にしてもらればと！ Warm Up with a Simple and Fairly Decoupled Capability（シンプルかつ分離された機能で準

Agile Alliance の Experience Reports として公開されている記事「Harvesting Mob Programming Patterns: Observing how we work」を読んだ．本記事は「モブプログラミング」で遭遇する「振る舞い」を「モブプログラミングパターン」として紹介している．モブプログラミングは何よりも「楽しさを増幅」する．しかし，実際にモブプログラミングを効果的に行うのは簡単ではなく，だからこそ「パターン」を知っておくことに意味がある．本記事を読んでいくと「あるあるー！」という「パターン」も多かったけど，名前を付けることに価値があると思う．今回は本記事の翻訳ではなく，読んだ個人的な感想をまとめる！ www.agilealliance.org Pattern Map（パターンマップ） まず，本記事に載っている「Pattern Map（パ

GitHub を学ぶときに「GitHub Learning Lab」を使うと便利！という紹介記事を6月に書いた．最近 GitHub Actions を使う機会があり，入門するために「GitHub Learning Lab」の「GitHub Actions: Hello World」コースを受講した．今回も非常に良かった！ kakakakakku.hatenablog.com GitHub Actions: Hello World 「GitHub Actions: Hello World」は GitHub Actions を学ぶ入門コースとなる．現在はまだ日本語に翻訳されてなく，英語を選択する必要はあるけど，Bot / Issue / Pull Request を活用したインタラクティブな構成になっていて，楽しく学べる．以下のステップを進めていくことになり，最終的には GitHub Acti

2019年8月にリリースされた Git 2.23 から，Experimental（実験的機能）として新コマンド git switch と git restore が使える．今までずっと使ってきた git checkout は機能が多すぎたため，機能を分割し git checkout の代替としてリリースされた．個人的にリリースされてから，できる限り git switch と git restore を使うようにしてるけど，まだ無意識に git checkout を使ってしまうこともある．最近 git switch を教える機会があったため，ブログにまとめておく． github.blog なお，以下の検証は Git 2.26.0 を使った． $ git --version git version 2.26.0 1. git switch を使う git switch を使って「ブランチ操作」

2012年に Heroku のエンジニアによって提唱された「The Twelve-Factor App」は素晴らしく，アプリケーションをうまく開発し，うまく運用するための「ベストプラクティス」として知られている．2020年になった現在でもよく引用されていると思う．日本語訳もある． 12factor.net Beyond the Twelve-Factor App とは？ クラウド化が進むなど，提唱された2012年と比較すると技術的な変化もあり，今までの「The Twelve-Factor App」で宣言されていた観点以外にも必要な観点やベストプラクティスがあるのでは？という意見もある．そこで，2016年に Pivotal のエンジニアが「Beyond the Twelve-Factor App」を提唱した．The Twelve-Factor App にあった「12項目をアップデート」し，新

4月に出版された「分散システムデザインパターン」を読んだ．サブタイトルに「コンテナを使ったスケーラブルなサービスの設計」とある通り，コンテナを設計／運用するときに，どのようなデザインパターンを知っておくと良いのか？という点を学べる内容になっている．関連情報と合わせて書評を書きたいと思う．なお，今回は貴重な機会を頂き，本書の出版レビューに参加することができた．オライリー本に自分の名前が載っている！という喜びもある． 分散システムデザインパターン ―コンテナを使ったスケーラブルなサービスの設計 作者: Brendan Burns,松浦隼人出版社/メーカー: オライリージャパン発売日: 2019/04/20メディア: 単行本（ソフトカバー）この商品を含むブログを見る 目次 1章 : はじめに 第 I 部 : シングルノードパターン 2章 : サイドカー 3章 : アンバサダ 4章 : アダプタ

今年1月に出版された「入門 監視」を読んだ．出版前から予約をしていたけど，他に積読もあり，読み始めるのが少し遅れてしまった．評判通り素晴らしく，特に「監視」というテーマをうまく言語化している本だと感じた．目次を見るとわかる通り，「あれも監視！これも監視！」という幅の広さに気付くことができる．本書は1人で読んで終わりにするのではなく，チームで輪読会をしてディスカッションをするなど，改善に繋げるために継続的に読むと良さそう．さらに本書で学んだ内容に Dive Deep するために他の書籍も併読するべきだと思う．今回は関連する書籍も紹介しようと思う． 入門 監視 ―モダンなモニタリングのためのデザインパターン 作者: Mike Julian,松浦隼人出版社/メーカー: オライリージャパン発売日: 2019/01/17メディア: 単行本（ソフトカバー）この商品を含むブログを見る 目次と正誤表 1章

2017年12月から「ブログを楽しく習慣化して書く」ことを支援するために「ブログメンタリング活動（完全無料）」をしている．既に1年以上継続していて，現在メンタリング中のメンティを含めると，計20名を超えている．「ブログを楽しく習慣化して書く」ことを支援するとは言え，メンタリング希望者は経験値によって違う課題意識を持っている．例えば「習慣化したい」というライフスタイルに課題意識を持っている人もいれば，「もっと多くの人にブログを読んで欲しい」という自己ブランディングに課題意識を持っている人もいる．その中でも特に多いのが「ブログ記事のクオリティを上げたい」という課題意識だったりする． 「ブログ記事のクオリティ」とは？ ブログ記事に「正解」はなく，誰が書いても違った良さがある．むしろ，ブロガーとしてオリジナリティを追求することも大切だと思う．さらに「ブログ記事のクオリティ」という言葉も定量的に表現

最近 Docker 関連のセキュリティツールを調査する機会があり，今回は「Docker Bench for Security」を試したログを残しておく．「Docker Bench for Security」は Docker から公式に提供されているセキュリティ診断ツールで，具体的には「CIS Docker Community Edition Benchmark v1.1.0」をサポートしている． github.com コンテナ実行 「Docker Bench for Security」を実行する方法は複数ある．1番簡単なのはコンテナを実行する方法で，Docker イメージ「docker/docker-bench-security」が Docker Hub に公開されている． https://hub.docker.com/r/docker/docker-bench-security 注意点と

定期的に CSV からデータを抽出する機会があり，抽出条件によって，今までは以下のような方法を使っていた． CSV を Excel で開いてフィルターを使う方法 CSV を grep / egrep などの Linux コマンドで絞り込む方法 CSV をAmazon S3 にアップロードして Amazon S3 Select でクエリを実行する方法 Rainbow CSV 新しい方法として VS Code の拡張機能「Rainbow CSV」を試すことにした．Rainbow CSV には多くの機能があり，例えば「ハイライト」や「CSVLint」や「RBQL (RainBow Query Language)」がある．データを抽出する用途だけでなく，CSV を確認するときにも便利で，普段から使える最高の拡張機能だった．以下からインストールできる． marketplace.visualstudi

最近 stress コマンドを使って，サーバに負荷をかける方法を紹介する機会があり，よく使っているのに今までブログに書いていなかったなと気付き，今回まとめることにした．CPU に負荷をかけるだけなら yes > /dev/null をコア数に合わせて並列実行すれば良いけど，stress コマンドならメモリとディスクにも負荷をかけることができるので，シナリオのバリエーションを増やすことができる． stress project page インストール 検証環境として CentOS を使った． $ sudo yum install stress $ stress --version stress 1.0.4 共通オプション 以下のような共通オプションが用意されている．よく使うのは --timeout で，秒数を指定して負荷をかけることができる．他はあまり使ったことがないかも． -t, --tim

Vue School の無料コース「Vuex for Everyone」を受講した．Vue.js 初心者でも受講できるレベルになっているし，今まで Vue.js を書いたことはあるけど，Vuex はまだ使ったことがないという人にもオススメできる．進め方にもよるけど，写経するとしても2,3時間あれば終わる． Vuex for Everyone 今回受講した「Vuex for Everyone」の題材は「shopping-cart」で，ステップバイステップに実装を進めていく．動作確認をしながら，機能を追加したり，リファクタリングをしたりする． vueschool.io 動画を見るとわかるけど，とにかく実装スピードが早いので，写経する場合は何度も戻して見直す必要がある．ただ困ったときは Vue School の GitHub にセッションごとにコミットされているので，それを活用すればオッケー．

今日は大阪出張で「DevLOVE 関西」のイベントに参加予定だったけど，豪雨の影響でイベントが中止になってしまった．今回イベントに誘って頂いた @yohhatu さん，本当にありがとうございました！ devlove-kansai.doorkeeper.jp 発表する予定だった資料 せっかく作った資料なので，このままお蔵入りにするのではなく，公開することにした．ストーリーの軸は「なぜアウトプットを習慣化するべきなのか？」という点で，特に今回は「ブログ」にフォーカスを当てている． ブログメンター 去年末から趣味（ボランティア）で取り組んでいる「ブログメンター（アウトプットメンター）」の話もする予定だった．特に「ブログネタ探し」のプロセスは面白いと思っていて，最初にメンティに「最低20個」出してもらって，それをさらにブラッシュアップして「30-50個」まで増やす．重要なのは「これもブログネタにな

GitHub の Releases から tar.gz をダウンロードする場合，普通に展開すると，以下のようにバージョンを含んだディレクトリになる．なお，今回はサンプルとして utils という名前にしている． $ tar zxvf utils-1.2.3.tar.gz x utils-1.2.3/ x utils-1.2.3/README.md x utils-1.2.3/src/ x utils-1.2.3/src/xxx.rb x utils-1.2.3/src/yyy.rb x utils-1.2.3/src/zzz.rb $ tree . . ├── utils-1.2.3 │   ├── README.md │   └── src │   ├── xxx.rb │   ├── yyy.rb │   └── zzz.rb └── utils-1.2.3.tar.gz 2 dire

オライリーから出版されている「プロダクションレディマイクロサービス」を読んだ．「プロダクションレディ」という秀逸なタイトルに惹かれただけじゃなく，章ごとのテーマも非常に惹かれる内容になっていた．仕事でアーキテクチャを考えたり，アーキテクチャレビューを担当する場面も多いけど，ベストプラクティスなアーキテクチャをもっと上手に言語化したいなと思っていて，プロダクションレディなマイクロサービスの標準化を学べる本書に興味を持った． 1章 マイクロサービス 2章 本番対応 3章 安定性と信頼性 4章 スケーラビリティとパフォーマンス 5章 耐障害性と大惨事対応 6章 監視 7章 ドキュメントと組織的な理解 付録A 本番対応のチェックリスト 付録B マイクロサービスの評価基準 プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化 作者: Susan J. Fowler,佐藤直