オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
美容内服薬ラボットメディカルクリニック【公式】
オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。
Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません 少し古い記事になるが、 Linus Torvalds 氏 の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない（後述）が、 別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とする git の開発フローを考察した上で、整理してみたい。 Linus 氏の理想 結論からいうと、 「意味あるコミットを作れ」「コミットを大事にしろ」 という思想が伺える。 では 「意味あるコミット」「大事にされたコミット」 とは何なのか。 筆者な
GitHub上のsensitive dataを削除するための手順と道のり | メルカリエンジニアリング
Advent Calendar day 7 担当の vvakame です。 予告では Apollo Federation Gateway Node.js実装についてポイント解説 としていましたが、社内各所のご協力によりAdvent Calendarの私の担当日に間に合う形で公開できる運びとなりました。そのため告知とは異なりますが GitHub上のsensitive data削除の手順と道のり をお届けしていきたいと思います。 メルペイVPoE hidekによるday 1の記事で振り返りがあったように、今年、弊社ではCodecovのBash Uploaderに係る情報流出という事案が発生しました。当該インシデント対応において、プレスリリースにも記載のある通り、ソースコード上に混入してしまった認証情報や一部個人情報などの機密性の高い情報（sensitive data）について調査を実施し、対応
Git / GitHub を使用したチーム開発時のガイドラインを制定しました | DevelopersIO
開発時にはみなさん Git や GitHub を使うと思いますが、使い方についてチームメンバー間で微妙に認識の違いがあると進捗を妨げてしまいます。それを防ぐためにガイドラインを定めてみました。 ちなみにこれは CX 事業本部の Tech Lead のお仕事紹介第 1 弾のポストです。 この記事の英語版も書きました。 前提 CX 事業本部ではクライアントからの開発案件や自社サービスの開発をしていますが、その際に有用な（と考えている）ガイドラインです。 様々な事情でチームメンバーが変更になる可能性があり、新規メンバーの立ち上がりを支援する意味合いも込めています。そのため、開発効率をなるべく落とさずに効果的なスキルトランスファーが実施できることを主眼としています。 ガイドライン 定めたガイドラインの全文を貼ります。 3 つのセクションに分かれています。 commit 時のガイドライン avoid
とほほのDocker入門 トップ > Docker Docker Dockerとは インストール チュートリアル Dockerコマンド docker run/create docker ps/stats docker rm/start/stop... docker exec/attach docker cp/rename/update docker logs/port/top docker pull/push/search/login/logout docker images/rmi/history/commit/tag/build/trust docker volume docker network docker export/import/save/load Dockerfileによるビルド Docker Compose Podman 小技・ノウハウ集 Copyright (C)
📌 はじめに Pythonで開発を行うにあたり、リンタやフォーマッタ、パッケージマネージャ等のツールの選定は非常に重要な問題です。一方で歴史的な経緯もあり、沢山の選択肢から何を選ぶべきか情報がまとまっていないように感じました。この記事では2021年9月時点でモダンと言えるであろう開発環境を紹介します。基本的にはシェアが高いこと、著名なパッケージで使用されていることを主な選定理由としており、また特定のエディタに依存しないことを前提とします。 本記事で紹介する内容は一つのテンプレートに近く、必要に応じてカスタマイズするもよし、そのまま使ってもよし、として参考になればと思います。(CI/CDについてはPythonとは独立した問題なので触れません。またドキュメント生成はSphinxを推しますが、必須ではないので今回は割愛します。) 📄 要約 "モダン"な開発環境を箇条で列挙すると下記の通りです
本記事のモチベーション 約8年前、Gitを使い始めたときに以下の記事を公開したところ、想像以上の反応をいただきました。 当時はSubversionからGitに移行し、試行錯誤をしている中だったこともあり、多くの反応をいただけたことはモチベーションのひとつでした。 ただ、時が経ち、当然かもしれませんが現在は当時と違う書き方をしており、思想として変わっていない部分はあるものの、今でもときどきLikeをいただく中で、アップデートを全くしないのは誠実じゃないなと感じていました。 というわけで、現在のフォーマットも数年後には変わっている可能性が高いですが、その時々のスナップショットを公開することにも何らか意味があるかなと思い、「今の僕はこうコミットメッセージを書いているよ」というのをまとめました。 Gitを使う環境 開発フローやホスティングサービスごとのUIのdiffによって、最適なフォーマットは変
お前らのコミットは汚い - Qiita
お前らのXXXXは<ネガティブな形容詞>シリーズ で失礼します。 日頃gitをお使いの皆様におかれましては、キレイなコミットを心がけていらっしゃいますでしょうか。 私も心がけてはいますが、なかなか難しいものがあります。 参考までにこちら、最近業務で書いたプルリクエストのコミットログです。 控えめに言って汚いと思われたかと思います。 ではキレイなコミットの例を。 プルリクエストというのは、やはり先達の方に見ていただいてご指摘いただこうというものですから、 当然コミットハッシュもゾロ目等でキレイにするというのがマナーです。 では今回はこのキレイなコミットをどうやって作るのか、という話を書きます (ショート)コミットハッシュ コミットハッシュとは、gitのコミットごとに生成される、40桁の[0-9a-f]からなる文字列です。 お手元のリポジトリ上で git log --format=%H を叩く
Python Design Patterns¶ Welcome! I’m Brandon Rhodes (website, Twitter) and this is my evolving guide to design patterns in the Python programming language. This site is letting me collect my ideas about Python and Design Patterns all in one place. My hope is that these pages make the patterns more discoverable — easier to find in web searches, and easier to read — than when they were scattered acr
文章でリストを表示（少し詳細あり） fix: バグ修正 既存の機能の問題を修正する場合に使用します。 hotfix: 緊急対応 稼働中のシステムのバグ修正など、緊急性が高い修正を行う場合に使用します。 add: ファイルや機能の追加 新しいファイルや機能を追加する場合に使用します。 feat: 新機能・新規ファイル追加 新しい機能やファイルを追加する場合に使用します。 update: 機能修正 既存の機能に問題がなく、ただし修正を加えたい場合に使用します。 change: 仕様変更による機能修正 仕様変更により、既存の機能に修正を加えた場合に使用します。 clean・refactor: リファクタリング コードを修正し、改善する場合に使用します。 improve: コードの改善 コードの改善をする場合に使用します。 disable: 機能の無効化 機能を一時的に無効にする場合に使用します。
リリース頻度を毎週から毎日にしてみた - NTT Communications Engineers' Blog
目次 目次 はじめに NeWork とは リリース頻度変更の背景 それまでの運用 課題 実現方法 解説 日次でワークフローが起動するようにする main ブランチの HEAD にタグが付与されていなければ付与する develop に差分があれば main へのマージを自動で行う 細かな工夫点 main の内容を develop に自動で取り込む 祝日はリリースしないようにする 自動リリース・自動 develop → main マージの制御 Slack にリリース結果を通知する stg 環境に変更内容を通知する その他の考慮 上司への事前説明の省略 スプリントレビュー前のリリース リリースノート 品質面 リリース頻度を変えてみて おわりに はじめに こんにちは、NeWork 開発チームの藤野です。普段はオンラインワークスペースサービス NeWork のエンジニアリングマネジメントをしています
自分はこれまでの仕事で、バグ修正や機能追加でPullRequestを送るときに、考慮の抜けもれやケアレスミスが非常に少ない方であると思っている。振り返ってみて、これは自分に課している習慣が大いに効いていると思っているので、メモしておく。 毎回のcommit時 必要な部分だけをgit addし、git diff --cachedによって差分をセルフコードレビューした上でcommitする PullRequest作成時 filesの内容をセルフコードレビューし、直した方が良い部分は直す + わかりにくい部分にGitHub上でラインコメントを行う + コード上にコメントを残した方がいいならコメントする ユーザーの導線に影響するコードなら、必ず自動テストだけでなく、自分自身でユーザーの行動をトレースし、違和感がある部分が存在しないかチェックする。チェックした流れについては、PullRequest上に
Gitのオブジェクトの中身
はじめに Gitのインデックスの中身、Gitのブランチの実装に続く、Gitの中身を見てみようシリーズです。Gitが管理するオブジェクトの種類や中身について見てみます。基本的にはPro Gitの10. Gitの内側をまとめなおしたものです。 オブジェクトの種類 Gitは、内部でファイルやコミットを「オブジェクト」として.git/objects以下に保存しています。オブジェクトには以下の4種類があります。 blobオブジェクト： ファイルを圧縮したもの。ファイルシステムの「ファイル」に対応 treeオブジェクト： Blobオブジェクトや別のTreeオブジェクトを管理する。ファイルシステムの「ディレクトリ」に対応 コミットオブジェクト： Treeオブジェクトを包んだもの。コミットのスナップショットに対応するTreeオブジェクトに、親コミット、コミットメッセージなどを付加する タグオブジェクト：
git checkout の代替としてリリースされた git switch と git restore - kakakakakku blog
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 を使って「ブランチ操作」
始めに 私は最近エンジニアに復帰し、現場で便利に思ったことを今後記事にできたらと思っています。 そして1発目は、gitのオプションについて記事を書いてみようと思います。 --fixup はどんな時に使えるの？ Pull Requestなどで、軽微な指摘や後から気付いた修正など、本来の機能のコミットとは別に修正コミットを残すのは少し嫌な時がありますよね。 コミットが一つ手前であれば、直前のコミットを修正してくれる git commit --amendなどで対応できますが、3つ前のコミットに修正を混ぜ込みたい時などは、少し大変。 そんな時に便利なのが、この git commit --fixupです。 使い方 例えば、下記のコミットの状況で、Fix article pageのコミットに対して、追加の修正をしたいとする。 ❯ git log --oneline 1131338365 (HEAD -
Conventional Commits 人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様 Conventional Commits 1.0.0 概要 Conventional Commits の仕様はコミットメッセージのための軽量の規約です。 明示的なコミット履歴を作成するための簡単なルールを提供します。この規則に従うことで自動化ツールの導入を簡単にします。 コミットメッセージで機能追加・修正・破壊的変更などを説明することで、この規約は SemVer と協調動作します。 コミットメッセージは次のような形にする必要があります: 原文： <type>[optional scope]: <description> [optional body] [optional footer(s)] 訳： <型>[任意 スコープ]: <タイトル> [任意 本文] [任意 フッター] あな
より良いコミットメッセージを残すことは Git を使った開発をする上で重要なことです。優れたコミットメッセージは、それを読んだ人がコードを理解するのに大いに役立ちます。 では、どのようなメッセージが良いもので、どのようなメッセージが悪いものなのでしょうか？ それについて掘り下げていきたいと思います。 基本的な Git Commit Message の書き方 詳しいところは、以下の3サイトを参照してください。特に「How to Write a Git Commit Message」には基本がすべて書かれています。 How to Write a Git Commit Message https://cbea.ms/git-commit/ Gitのコミットメッセージをうまく作成する7つのルール （「How to Write a Git Commit Message」の和訳記事） https://
タイトルがすべて。 思いついたら手を動かしてしまう性質なので、秘蔵のブランチを大量に持っている。 秘蔵のブランチというのは、動いたけどチームメンバーを説得するのが面倒とか、テスト書くのが面倒とか、だいたい動いているけどやりきるのが面倒とかで main にマージしていないヤツ。 例えばフレームワークのメジャーバージョン上げるブランチとか、依存ライブラリをより一般的/現代的なものに交換するブランチや、より良い設計を思いついたのでガッと書き換えてしまうブランチが多いかな。 だいたい 1 年所属していると 80 ブランチぐらい溜まるので、週 1 つ以上は何か作りかけてる計算になる。 ローカルブランチの数、プロンプトに出しておくかな……。(秘蔵のブランチが溜まってる— Takafumi ONAKA (@onk) March 28, 2017 もちろん自分でいいアイディアだと思っているから実装している
ロジカルなコミットメッセージの書き方
チーム開発におけるコミットメッセージの書き方についてアウトプットします。 コミットメッセージに正解はありません。 組織によって最適な手法は異なるため、参考のひとつにしてください。 要点 フォーマット :Emoji: Title / Reason / Specification / Issue 項目 Emoji - 内容・種類をひと目で分かるように Title - タイトル（概要） Reason - このコミットをする理由 Specification - 言い訳ではなく、このコミット内容になった意図や仕様など Issue - 対応するIssue 作業内容はコードを見ればわかるので、「概要」「変更理由」「意図・仕様」を簡潔にまとめる。 例 コミットメッセージを書く理由 そもそも、コミットメッセージを書く理由は以下の通りです。 ひと目でどんなコミットなのか判断するため 簡潔にコミット内容を説明す
個人開発者のためのコマンドラインGit使いこなし術
英語で先に書いてから翻訳しています どうも個人アプリ作家のTAKUYAと申します。 Gitはコードベースや変更履歴の管理に必要不可欠なツールです。たとえ個人でアプリを開発していたとしても。 僕はデスクトップとモバイルの両方で動作する、InkdropというMarkdownのノートアプリを独りで開発しています。 当アプリはデスクトップ版はElectron、モバイル版はReact Nativeで作られています。 僕は開発作業は基本的にtmuxとvimでターミナル上で行っています。vimによるJavaScriptコーディングのためのセットアップについては前回シェアしたとおりです。 本稿では、僕のGitのワークフローについてご紹介したいと思います。 内容はすでにGitの基本をご存知の方向けとなります。 Gitの操作も基本的にはターミナル上で行っています。 色んなGUIベースのGitクライアントアプリ
コミット履歴を綺麗にするときの`git commit --fixup`と`git rebase --autosquash` - 理系学生日記
Pull Request(PR)やMerge Request(MR)を作る中で、コミット履歴はできるだけ綺麗にしておきたいものです。 プルリクエストについて - GitHub Docs Merge requests | GitLab ぼくはあまりコミット履歴の綺麗さを気にしない方でした。 しかし大きめのPRやMRをレビューする側に回ると、「変更のまとまり」が追えないと「なぜこの変更をしたのか」が非常に追いにくくなります。 だからこそ最近は、コミット履歴をかなり意識するようになりました。 その時に活躍しているのが、タイトルの通りgit commit --fixupとgit rebase --autosquashです。 git commit --fixup git rebase --autosquash そのほかおすすめ git commit --fixup git commit --fixu
GitHub ActionsからGitHub wikiを更新する - Islands in the byte stream
GitHub ActionsからGitHub wikiを更新したいことがたまにあります。たとえば、何かのメトリクスを見やすく整形したものなど、repositoryのデータを何らかの形で加工したドキュメントを作りたいときです。コード生成したmarkdownドキュメントをコミットしてもいいですが、それよりはシンプルで運用が楽です。 今回は、GitHub repoで管理する原稿の文字数（など）を継続的に見れるページを作ると便利かなと思って作りました。自分一人だったらローカルで適当なツールを叩けばいいですが、同repoを見れる編集者にも共有したいとなると独立したページがあるほうが便利ですからね。 リポジトリはこんな感じです。 github.com 基本的には、 actions/checkout を使って "${{ github.repository }}.wiki" をcloneして編集してpus
Sapling: Source control that’s user-friendly and scalable
Sapling is a new Git-compatible source control client. Sapling emphasizes usability while also scaling to the largest repositories in the world. ReviewStack is a demonstration code review UI for GitHub pull requests that integrates with Sapling to make reviewing stacks of commits easy. You can get started using Sapling today. Source control is one of the most important tools for modern developers,
JRE しか入ってない Pod で Java の heap dump を取りたい / Get heap dump on JRE container
eBPFでcommit logを調べてみるといろいろと面白そうなものが出てくるな。例えば、TCP-BPF [netdev 2.2]。TCPコネクションのパラメータをBPFで操作できる。さらに最近（バージョン5.5以降）では、輻輳制御もeBPFで実装できるようになっているようだ。eBPFによりカーネルからどんどん機能を追い出してLinuxはマイクロカーネル化するのだという鼻息荒い発表も見かけるが（「eBPF - Rethinking the Linux Kernel」[QCon2020]）、正直これが正しい方向性なのかよくわからない。面白いけど。 eBPFを使っているわけではないが、輻輳制御をユーザレベルで実装するという研究はいくつかある（「Restructuring Endpoint Congestion Control」 [SIGCOMM2018]、「Deploying Safe Use
ContentsBasic project setupThe basic setup consists of four steps: Create the project and source directoriesCreate a package.jsonGet a .gitignore, tsconfig.json, .eslintrc.jsInstall TypeScript & dependenciesNote: This guide uses yarn, but if you prefer npm it has similar commands. # Create project folder mkdir my-project cd my-project # Create source folder and files mkdir src touch src/main.ts sr
はじめに gitのコミットメッセージを記述するとき、内容について悩むことが度々あります。 簡潔に要点をまとめて書きたいけどいちいち記述が面倒だったり、チームで書き方がバラバラだったり・・・ そして結局「fix bug」のひとことだけメッセージを記述するだけになったりします。 この記事ではそんなコミットメッセージを少しでも簡単に有用にするためのツールを紹介します。 Commitizen? コミットメッセージを簡単・簡潔に記述したいときに使えるのがCommitizenです。 Commitizenはインタラクティブにコミットメッセージを作成できるツールで、 このコミットのタイプ スコープ コミットのサマリー コミットの詳細 などについて対話的に記述していくことで、適切なコミットメッセージを作成できます。 ? Select the type of change that you're commit
Formatterを使って、Dockerfileをキレイに書く方法とGitを絡めた使い方 | DevelopersIO
こんにちわ、札幌のヨシエです。 先日、PyCon mini SAPPORO 2019と呼ばれるPythonのイベントに参加しました。 参加セッションのPythonistaのためのコードレビューTips - slideship.comというセッションでFormatterについて触れられる点がありました。 あまりコードを書く機会がない自分ですが、Dockerfileは検証用途で書く頻度が高いのでDockerfileに対応したFormatterであるdockfmtを試してみました。 例として、以下のようなdockerfileを書き出してみます。 やっていることはApacheの公式イメージに対して、パッケージアップデートとgitをインストールして キャッシュ周りを削除してます。 FROM httpd:latest RUN apt-get -y update && apt-get -y upgrad
GitHub Actionsとtfupdateを使ってTerraformおよびTerraform Providerのバージョンアップを自動化する - ZOZO TECH BLOG
はじめに こんにちは。SRE部MLOpsチームの築山（@2kyym）です。 Infrastructure as Code（IaC）が一般的になり、またパブリッククラウドをフル活用したインフラ構築が当たり前となりつつあります。そんな中で、インフラの構成管理にTerraformを用いているチームも多いのではないでしょうか。本記事ではTerraformを用いたインフラ構成管理において避けては通れないTerraformやProviderのバージョンアップを自動化し、IaCの運用負荷を削減する方法をご紹介します。MLOpsチームでの運用を参考に、具体的な設定やハマりどころを交えつつ解説できればと思います。 目次 はじめに 目次 Terraformとは MLOpsチームにおけるTerraform運用の背景 Terraform管理の対象リソース Terraform運用において生じた課題 tfupdate
TL;DR MySQL 8.0.17 でついに俺待望の Cloneプラグイン が追加された CLONE LOCAL DATA DIRECTORY .. で、ローカルファイルシステムにほぼノンブロッキングで物理バックアップを吐き出す CLONE INSTANCE FROM USER@HOST:PORT IDENTIFIED BY 'password' .. でグループレプリケーションの経路を使ってフツーのレプリケーションと同じ3306の経路を使ってインスタンスの丸コピーができるらしい このへんを読んでおくのが良さげ MySQL :: MySQL 8.0 Reference Manual :: 5.6.7 The Clone Plugin MySQL :: MySQL 8.0 Reference Manual :: 5.6.7.13 Clone Plugin Limitations mysql
OSSコントリビュータになろう ― Deno編
Copyright (c) 2018-2020 the Deno authors. MIT License. この記事は Deno Advent Calendar 2020 24日目の記事です。 23日目は -> （あとで埋める） 25日目は -> Deno が Node.js に依存しなくなった はじめに こんにちは、@magurotuna です。 2020年ももうそろそろ終わりですね。みなさんはどのような1年を過ごされたでしょうか？ 僕は、初めての転職をしたり、OSSコントリビュートを始めたり、といった1年でした。 OSSコントリビュートに関しては、去年までは「凄腕のエンジニアがやるものであって、平凡なエンジニアである僕はその恩恵に預かるだけ……」と思っていましたが、いざやってみると、まったくそのようなことはなく、さまざまな方面からOSSに貢献することができるということが分かりました。
Highlights from Git 2.28
EngineeringOpen SourceHighlights from Git 2.28The open source Git project just released Git 2.28 with features and bug fixes from over 58 contributors, 13 of them new. We last caught up with you on the… The open source Git project just released Git 2.28 with features and bug fixes from over 58 contributors, 13 of them new. We last caught up with you on the latest in Git back when 2.26 was released
普段は基本的にMariaDBの動向は全く追って無いです。 でも先日、MariaDB 10.5 のfsync()発行が少なく性能が良いのは何故なのかちょっと見てほしいと言われて、 mariadb-10.5.9.tar.gz をざっと見たらあっという間に原因特定。 「fsync()を待つべきなのに待ってないから」 只の不正と判明。 動作としては、 innodb_flush_log_at_trx_commit = 1 でも innodb_flush_log_at_trx_commit = 2 でも 並列度が上がると多くのトランザクションが innodb_flush_log_at_trx_commit = 0 の動作と同等となってしまうようです。 待たないのだから速いに決まってる。こんな不正なものと比較されるのは腹立たしいです。 指定のLSNまでのwriteやflushを終わらせる log_wri
この記事はpushをトリガーとしたGitHub Actionsのワークフローを前提として書いています。 概要GitHub Actions、簡単便利で良いですね！ ぼくも遅まきながら使いはじめ、先日、Git pushをトリガーにデプロイしてSlackで通知、とよくあるワークフローを追加して運用しはじめました。 Slackへの通知も Marketplace に数ある既存Actionを選んで利用すれば、すぐに実現できました。すごい！ ぼくはこんな感じにしたかったとはいえ、贅沢を言えば、ぼくは レガシーなCustom integrationsのIncoming Webhooksでなく、きちんと新しいIncoming Webhooksでやりたいref: https://api.slack.com/legacy/custom-integrations#incoming-webhooksAction独自
Fork is getting better and better day after day and we are happy to share our results with you.
secretlint を使って機密情報を git commit できない環境を作る | DevelopersIO
AWSアクセスキーセキュリティ意識向上委員会って何？ 昨今、AWSのアクセスキーを漏洩させてしまうことが原因でアカウントへの侵入を受け、 多額の利用費発生・情報漏洩疑いなど重大なセキュリティ事案が発生するケースが実際に多々起きています。 そこで、アクセスキー運用に関する安全向上の取組みをブログでご紹介する企画をはじめました。 アクセスキーを利用する場合は利用する上でのリスクを正しく理解し、 セキュリティ対策を事前に適用した上で適切にご利用ください。 tl;dr 開発をはじめる前に、次の手順を実行しよう シェルスクリプトの保存 次のシェルスクリプトを ~/.git-template/hooks/pre-commit として保存しよう。 #!/bin/sh FILES=$(git diff --cached --name-only --diff-filter=ACMR | sed 's| |\
Conventional CommitsとCHANGELOGの自動生成でリリースのユーザ影響をわかりやすくした話 - ドワンゴ教育サービス開発者ブログ
ドワンゴ教育事業 バックエンドエンジニアのtakuminishです。 現在、私は教材入稿ツールの開発チームに所属しています。 教材入稿ツールは昨年の2023年06月に社内向けに正式リリースされた比較的新しいツールであり、リリース当初はリリースノートに関する運用について検討が進んでいませんでした。 リリースノートは開発メンバーが手動で作成しており、内容も前回リリース後にマージされたPRタイトルとリンクを箇条書きで記載しているだけの簡素なものでした。 また、PRタイトルのフォーマットも存在しなかったため、英語で記載されたタイトルと日本語で記載されたタイトルが混在している、ユーザ影響度がタイトルからわからないといった問題もありました。 そこで、教材入稿ツール開発チームではリリースノートの運用として、Conventional Commitsを導入するとともに、conventional-change
My favourite Git commit
I like Git commit messages. Used well, I think they’re one of the most powerful tools available to document a codebase over its lifetime. I’d like to illustrate that by showing you my favourite ever Git commit. This commit is from my time at the Government Digital Service, working on GOV.UK. It’s from a developer by the name of Dan Carley, and it has the rather unassuming name of “Convert template
written on Thursday, July 14, 2022 When you maintain a project, publishing new releases can quickly become a chore, so naturally one tries to automate it as much as possible. One release step which is often automated is updating the changelog. We already have git commit messages, so let's gather all the messages since the last tag and "Voilà!" changelog entries for the new version! There is howeve
gitでコミット(commit)前にterraform fmtやtflintを実行したい時はpre-commit-terraformが便利 | DevelopersIO
gitでコミット(commit)前にterraform fmtやtflintを実行したい時はpre-commit-terraformが便利 「ローカルでもterraform fmtやtflint・tfsecの実行を自動化したい。」 terraformにはコードのフォーマットやテストに便利なcliツールやコマンドが色々あります。 (terraform fmt、terarform validate、tfsec、tflint等) ただ、このコマンドを毎回手動で実行するのは面倒です。 CI/CDツール上で実行するのもいいですが、CIで失敗する前にローカルで気づけたらより良いですよね。 そんな時に便利なpre-commit-terraformを紹介します。 pre-commit-terraformとは pre-commitフレームワークで使用できる Terraform の git hook スクリプ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linus Torvalds 氏の理想の git 運用と GitHub
とほほのDocker入門 - とほほのWWW入門
【2021】モダンなPython開発環境の紹介 - Qiita
Gitのコミットメッセージの書き方（2023年ver.）
Python Design Patterns
Gitのコミットメッセージの先頭につけた方が良い単語リスト(prefix集) - Qiita
コード変更で抜け漏れやミスを少なくするための習慣 - $shibayu36->blog;
git commit --fixup が便利 - Qiita
Conventional Commits
より良い Git コミットメッセージを書こう - Qiita
branch を寝かせるときは TODO.txt を置いている - id:onk のはてなブログ
How COMMIT Works in CockroachDB
TCP-BPF: Linuxはマイクロカーネルの夢を見るか｜oraccha
Starting a TypeScript Project in 2021
Commitizenを使ってgitのコミットメッセージをしっかり書こう | DevelopersIO
MySQL 8.0.17でついにCloneプラグインが入った
MariaDB 10.5 の性能は不正？
Github ActionsからSlackへ通知するのを良い感じにしたい | Spinners Inc.
Fork - a fast and friendly git client for Mac and Windows
Your git log is not a changelog!
neo.usachannel.info
note.com/hyougakioji
style.kanagawa-u.ac.jp
toushi.xn--w8j1at4m.tokyo
kakimonigoigo1515.blogspot.com
www.webchikuma.jp