SonarQube解析をGitHub Actionsのpull_request_targetイベントで回す - Kengo's blog
SQ解析が現時点ではあまりpull_request_targetイベントをサポートしておらず、ちょいちょい手間が必要だったのでまとめます。 完全なYAMLのサンプルは↓にあります。 github.com checkout する場合はrefを指定する pull_request_target イベントでcheckoutを実行すると標準ではデフォルトブランチをチェックアウトしてしまいます。 よって fetch-depth: 0 に加えて ref の指定も必要です。以下のようにHEADをチェックアウトするか： - uses: actions/checkout@v2 with: fetch-depth: 0 ref: ${{ github.event.pull_request.head.ref || github.ref }} 以下のようにマージコミットをチェックアウトすることで解決できます*1。
勝手を知らないプロジェクトにPull Requestを送るときに気にしていること - Kengo's blog
初心者向けのPull Request（PR）作成方法はopensource.guideをはじめとして数多く見るのですが、もうちょっと突っ込んだというか中級的な内容の記事を読みたかったので自分で書きます。題材として主に直近で書いた大きめの機能追加用PRを使っています： github.com 修正や新機能を入れる利点を明確に伝える 何かを提案する場合、その背景には必ず動機となる利点があるはずです。これはとても単純に伝えられることもあれば、テストやグラフを作成しないと伝わりにくいものもあります。 今回の変更では、GitHub Actions workflowの定義ファイル簡素化とパフォーマンス改善が利点でした。定義ファイルが簡素化されることはドキュメントで簡単に伝えられますが、パフォーマンスは測定しなければわかりません。よってパフォーマンス検証用のリポジトリを作成し測定を行うことで、ビルド時間が
The 2021 State of DevOps Reportが出た - Kengo's blog
みんな大好き、State of DevOpsの2021版が来たぞーhttps://t.co/7yFtAblwFn— Like a Galarian Linoone (@Kengo_TODA) July 21, 2021 ということでスキマ時間に読み進めていたので、感想と面白いと感じた点をまとめときます。網羅性が高く公平なまとめが必要な方は、3〜4ページに掲載のExective Summaryをおすすめします。 テーマは「中間層からの脱出」 6ページ目を見てもらえれば一目瞭然、今回のテーマは生産性が高くできず中間層で留まっているチームに対する処方箋の発見にあるようです。 近年のレポートは「今更それは無いでしょ」って感じのLow levelが5%強、「リアルチートじゃん」って感じのHighが10%強で、ほとんどのチームがMiddleに属していました。ごく少数の上澄みが高いパフォーマンスを出して
Gradleのbaseプラグインに書くべきでないconventionとは何か - Kengo's blog
ひとつ前の記事では「Gradleの設定やコードをどこに書くべきか」のうち、答えが明確な「build.gradleファイルとbuildSrcディレクトリの使い分け」について書きました。この記事ではまだ自分の中でもよくわかっていない「Gradleでbaseプラグインに書くべきでないconventionとは何か」について書きます。 baseプラグインとは ここで言うbaseプラグインは、plugins { id "base" } で使えるThe base pluginのことではありません。Gradleプラグインの設計手法のひとつとして推奨されている「設定より規約」の文脈で登場するものです。「設定より規約」を実現しつつ、（大部分のケースをカバーするであろう）規約が適用できないケースでもプラグインの機能を使えるようにするため、プラグインの規約（conventions）と基本的な機能（capabili
GradleのbuildSrcとどう付き合うべきか - Kengo's blog
Gradleで複数サブプロジェクトをもつプロジェクトを作成する - kdnakt blog を見て、buildSrcディレクトリ周りで混乱した記憶が蘇ってきました。 gradle initでサブプロジェクトを持つプロジェクトを作るとbuildSrcを使ったプロジェクトが生成されるらしい。知らんかった。buildSrcまわりはドキュメントわかりにくいので、実コード読めるのは助かる。 Gradleで複数サブプロジェクトをもつプロジェクトを作成するhttps://t.co/XVozfs9Zqu— 書けない猫はただの猫さ (@Kengo_TODA) July 7, 2021 書く場所がbuildSrcとbuild.gradleの2つに増えるので、何をどこに書けばいいのかよくわかんないんだよね。Gradleはこういう悩みが多い、最近ではbaseプラグインに書くべき処理とそうでないconvention
GitHub Actionsのworkflow_runイベントでテストを回すときの要点 - Kengo's blog
Dependabotの作ったPRがSecretsにアクセスできないためにことごとく失敗していたのを修正しました。 github.com SecretsにアクセスできないのはKeeping your GitHub Actions and workflows secure: Preventing pwn requestsで説明されているようにセキュリティ向上のためです。workflow_run イベントでCheckを回すとワークフロー定義は常にデフォルトブランチのものが使われるため、PRでワークフローファイルが悪意を持って変更されてもマージしなければ悪影響を受けません。ので今後、基本的にはSecretsを必要とするワークフローはworkflow_runイベントで回すことになります。 上記securitylab.github.comの記事で色々説明されていますが、わりと限定的なユースケースについ
SLF4JとLogbackは2021年現在では積極採用しない方が良い（2023年12月 追記） - Kengo's blog
SLF4JとLogbackの中の人はここ数年活発ではないのでLog4j2などを代わりに使いましょう。 SLF4Jの活動は最近活発ではない SLF4JはVCSとしてGitHubを利用しています。最後の変更が2020年2月、最後のリリースが2019年12月となっていることからも、あまり活発ではないことが伺えます。 またBTSとしてJIRAを使っていますが、こちらもメンテナンスされていません。昨夏SLF4J-209が既にクローズ可能な状態であることやSLF4J-186が修正可能であることなどをコメントしましたが、1年近く経った今もすべて返信がない状態です。 2020年12月にイシューを閉じていたりするので全く動きがないわけではないのですが、年間で22つ作成されたのに対して2つしか閉じられていないので、充分にメンテされているとは言い難い状況です。 2021年5月31日時点での過去360日のイシュー
内製化をすすめる知人へのアドバイス - Kengo's blog
ソフトウェアエンジニアとしての働き方を探求してきた経験と、駐在員として文化の狭間でうろちょろしてきた経験、OSSエンジニアとして多数の多様な人材と交流してきた経験をもとに、果敢にも内製化に挑戦する知人へのアドバイスを気持ちまとめます。 前提 主な利用技術にはJava（Spring Framework）やTypeScriptを想定 FaaSを始めとしたManaged Serviceは（いまのところ）積極採用しない構え Digital Transformationを推し進める一環としての内製化に、エンジニアリングの観点から挑む方を読み手として想定 内製化のターゲットは決まっているか心当たりがある状態 既存の開発チームはほぼ無い想定 1. チームビルディング 1.1. スーツとギークの対立を避ける 我々が若かった頃は"スーツ"と"ギーク"の対立を煽る風潮にありました。Rockstar Engin
JJUG CCC 2021 Springでバイトコードの話をしました - Kengo's blog
JJUG CCCで聞きたい内容を募集👇🏻— ｺﾞｰﾙﾄﾞｼｯﾌﾟと同誕の方のトダ (@Kengo_TODA) 2021年3月2日 ということでJava8〜16におけるバイトコード生成の変化について、先日開催されたJJUG CCCで喋ってきました。 動画をYoutubeにて配信していただいているので、よろしければご覧ください： youtu.be 資料はSpeakerdeckにあります。ハイパーリンクを埋めているところは、PDFを落としてもらえれば追えるはずです： speakerdeck.com マイクロベンチマークはGitHubに置いてあります。みんなも手元でレッツJMHだ： github.com なお最後の方に触れたJEP396については、掘り下げたセッションがあったようです： youtu.be 運営の皆様、いつも素敵なイベントを開催いただきありがとうございます！ 昔は息子氏見てもらう
InclusiveなOSS開発体制を作る意味で、GFWの影響をざっくり知ってもらえるとありがたい - Kengo's blog
TL;DR 2021年5月時点では raw.githubusercontent.com や gcr.ioはGFW内からアクセスできません。 開発しているOSSを広いユーザに利用してもらいたい場合は、こうしたドメインへの強い依存は避けることを検討しても良いかもしれません。 中国インターネットから見たOSS開発体制 中国本土でOSS開発をしていると、以下のようにバッジが壊れているGitHubリポジトリによく遭遇します： バッジが表示されないGitHubリポジトリの図 これはバッジが使っているドメイン raw.githubusercontent.com にアクセスできないことから生じます。バッジなら大して影響ないのですが、開発体制構築がこれに依存していると厄介です。 例えばYarn v2のインストール手順は、JSONファイルを raw.githubusercontent.com からダウンロード
JavaのRecordでは配列を使わないほうが良いという話 - Kengo's blog
配列使うとmutableになるから使うべきではない、というのに加えて。生成される hashCode() と equals(Object), toString() が配列を考慮しない実装になっているため、JavaのRecordでは配列を使わないほうが良いようです。 検証コード 生成される hashCode() と equals(Object) の挙動を検証するコードです。 gist.github.com なぜこうなるのか ObjectMethods クラスによって生成されるコードを見ると、 Arrays.hashCode(int[]) ではなくint[].hashCode()が、Arrays.equals(int[], int[]) ではなく int[].equals(Object) が使われているようです。これは考慮漏れというわけではなく、ObjectMethodsクラスのjavadocに
オンラインコミュニティに参加してるまとめ - Kengo's blog
自分のキャリアを考えたときに、FOSSエンジニアであることの比重が高いわりにプレゼンスないんだよね……ということに課題を感じたので改善策を考えてみた。LTやセッションを増やしたりcontributeするプロジェクトを増やしたりするのも必要だけど、他にも継続的にオンラインの知り合いを増やせる・議論の機会を得る手段がほしいと思い、オンラインコミュニティにいくつか参加し始めているところ。 参加コミュニティ Codacy Community OSSの静的解析ツールを複数組み合わせて統一されたUIで解析結果を伝えるSaaS、のコミュニティ。Twitterで見かけてDiscourseに参加。 SonarQubeやLGTMのような自社解析エンジンは持っていないが、CEOが静的解析で修士とった人だったし社員ぽい人もSpotBugsにPR送ってくる。のでマニアが集まるのではと期待してDiscourseに静的
「ドメイン駆動設計入門」付録のGradle向け解釈 - Kengo's blog
ITエンジニア本大賞2021で紹介されていた「ドメイン駆動設計入門」（以下、本書と呼ぶ）が、DDDを学ぶ上でわかりやすかったです。一応他のDDD本も数冊読んではいたのですが、どうしてもユビキタス言語や境界づけられたコンテキストなど”場合による”ものが頻出してしまい、結局どうすればいいんだ……となって手が動きにくかったのです。よくわからない概念の上にさらにわからない概念を積み重ねるので、どんどん混乱する感覚がありました。 定期的にDDD勉強しなきゃ……ってなるんだけどやらない（やれ）— 正月と正月のあいだ (@Kengo_TODA) September 5, 2019 反面、本書では副題の通りボトムアップ形式を採っているため、実際にどう手を動かせば良いのか細かく確認できました。また不明点を最小化しながら進むだけでなく、その概念を導入することでどんな問題が解決されるのかが実例をもって明示されて
最近見かける新しいライセンスについて - Kengo's blog
Elastic社のブログをきっかけに、最近見かける新しいライセンスについて個人的に調べてみた。私は専門家ではないので要注意。公開情報も隅々まで追えているわけではないし。 なお一部ライセンスはOpen Source Initiative (OSI)による承認を受けていないので、ここではオープンソースライセンスではなく単に「ライセンス」と書くことにする。 新しいライセンスが誕生している背景 従来のオープンソースライセンスが再頒布以外の利用をあまり想定していなかった。 Open-core modelないし完全オープンソース戦略を採る企業が自衛策を必要とした。 既存のライセンスが難解なため、理解しやすいライセンスが求められた。 OSS活動を収入に繋げるためのモデルが試行錯誤されている。 新しいライセンスを導入しているプロジェクト（一例） プロジェクト ライセンス Elastic SSPLと独自ライ
マイクロサービス時代のアプリケーションサーバ実装について - Kengo's blog
4年前の下書きが出てきたので、供養のために置いておきます。 SpringOne Platform 2016のKeynoteとSessionを、特にProject Reactor周りについて確認した。 https://www.youtube.com/watch?v=Xm-KjMY_Z_w http://www.slideshare.net/SpringCentral/going-reactive-building-better-microservices-rob-harrop http://www.slideshare.net/SpringCentral/data-microservices-in-the-cloud http://www.slideshare.net/SpringCentral/designing-implementing-and-using-reactive-apis h
Javaライブラリを配布する際のログ周りにおける配慮と実践 2020 - Kengo's blog
この記事は、2013年に書いた記事を現状に合わせてアップデートするものです。結論から言うと、当時から id:miyakawa_taku さんがおっしゃっていた「APIは依存に含めて良い」を支持するものです。あるいは無難にバージョン 1.7.30 を使っておきましょう。 blog.kengo-toda.jp slf4j-apiに1.7, 1.8, 2.0の3バージョンが生まれた 現在slf4j-apiには3つのバージョンが存在します。現在のSLF4Jエコシステムを考える上では、これらの違いを抑える必要があります： 1.7.x Java 1.5から利用できるバージョンです。安定版にこだわるなら未だこのバージョンを使う必要があります。 1.8.x JPMS（a.k.a. jigsaw）を採用しServiceLoaderを使ってBindingを呼び出すようになったバージョンです。Java 1.6が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Java8〜16におけるバイトコード生成の変化 / Changes of Bytecode Generation from Java 8 to 16
外国人永久居留証を取得しました - Kengo's blog
技術書「JavaのビルドとCIのキホン」を公開しました - Kengo's blog
CompletableFutureの何が嬉しいか、そしてReactorへ…… - Kengo's blog