パッケージなメガベンチャーから医療機関向けサービスを提供するスタートアップに転職して6ヶ月して感じたこと - Kengo's blog
いよいよ試用期間が終わりまして、ドメイン知識はともかく同僚の働き方はだいぶ掴めてきた気がします。6ヶ月何をやっていたかは会社の方のブログに書いたので、こちらでは感じたことを書いておきます。なお入社2ヶ月時点での所感を別の記事に記載しています。 文脈 人事給与，会計や購買管理といったERPをメインとしたパッケージベンダーから、医療機関向けERPを提供するスタートアップに転職した SaaSを製品ラインナップに加えようという活動に従事した経験があるので、パッケージとウェブサービスと両方それなりに知っているつもりだった 製品開発、製品運用、プロジェクトマネジメントないしピープルマネジメントはわりとわかっているつもりだった ウェブサービスとパッケージはやはり大きく違うという話 ウェブサービスのほうがサポートバージョンを絞って効率よく開発できる、動作環境を掌握できるので細かいサポートが不要になるといっ
2022年に試した開発ワークフロー関係の機能やツール - Kengo's blog
数えてみたら意外と数あったのでまとめます。 release-please Google謹製のリリース自動化ツール。monorepo対応のRelease Drafterという感じですが、リリースはDraft Releaseの安定版への昇格ではなく、PRのマージによって行います。PRでリリースするという点ではgit-pr-releaseぽいですが、ブランチは main だけでリリースブランチは無い感じ。changesetsよりはとっつきやすい印象です。 github.com 例えば↓のようなワークフローを用意すれば、モジュールごとにGitHub Releaseを作成するためのPRを自動作成できます。 初期セットアップでJSONファイルを2つ作る必要があるのが若干面倒ですが、それさえ越えてしまえば考えることは少なさそうです。 # .github/workflows/release-please.
医療向け基幹システムを提供するスタートアップに入社しました - Kengo's blog
前回の退職エントリに続けての入社エントリです。 2022年7月1日より株式会社ヘンリーにSREとして入社しています。Java→Kotlin、AWS→GCP、Ansible→Terraformなど技術的には大きな変化を伴う転職でしたが、SREとしての観点や課題解決プロセスへの習熟、そして持ち前のひとがらのよさ（なぜか変換できない）などのポータブルなアビリティに助けられて2ヶ月生きています。このエントリーでは入社の目的と2ヶ月働いてみての転職の感想を残しておきます。 目標 新卒入社のころと違って自分なりの働き方やプロフェッショナルとしての在り方があるためそこまで厳密な目標は定めなくていいのかなと思う反面、振り返りや内省が成長の糧になることも確かなので、3つほど定めています。 1. 顧客と開発現場から学び、製品とチームを継続的に改善する さすがに14年も経つと、ある程度はITエンジニアとしての基
Gradleのjvm-test-suiteプラグインがテスト周りの定型コードを排除するのに便利そう - Kengo's blog
Gradle v7.5の時点ではまだIncubating段階の機能ではあるのですが、Gradleの新しいプラグイン jvm-test-suite がいい感じなので紹介します。 docs.gradle.org 解きたい課題：サブモジュールや統合テストが出てくるととたんに面倒になるビルドスクリプト Gradleは設定をDSLで記述するので基本的には何でもありなのですが、やはり定形コード（boilerplate）は少ないほうがビルドスクリプトの見通しも良くなります。もちろんGradleは「設定より規約（Convention over Configuration）」の考えを持っているため、ある程度は空気を読んでSourceSetやTaskを自動的に生成してくれます。しかしテスト周りにおいてはこうした自動生成は十分ではなく、次に挙げるような課題がありました： サブプロジェクト全てに対して実行したタス
13年ぶりにストレングスファインダーをやった - Kengo's blog
ストレングスファインダー、今はクリフトンストレングス（CliftonStrengths）と呼んでいるそうですが、13年前に新卒入社したときも本を買ってテストを受けたことがありました。 当時は慎重さ・戦略性・規律性・内省・収集心が強みだという結果が出ていました。「あらゆる道のりには、危険や困難が待ち受けていると考えている。日課や秩序正しい計画に従うことを好み、決定や選択を行う時に細心の注意を払う。あらゆる種類の情報を蓄積したり自分の頭の中で考えるのが好きで、知的な討論が好き。」ということで雑に言うと石橋叩いて計画するタイプだったんですね。 さて新しく入社した会社がクリフトンストレングスをまた受けさせてくれました。今回強みとして出た資質は「学習欲・最上志向・収集心・アレンジ・原点思考」でした。内省は7位、慎重さは15位、戦略性は16位、規律性はなんと27位に落ちています。この変化について考えて
退職エントリ - Kengo's blog
14年勤めたソフトウェアベンダーを今月末で退職します。私が入社したころは新卒が3年で辞めるという話があって、漠然と自分も似たような感じになるのかもと思っていたので、まさかここまで長く在籍することになるとは想像していませんでした。お世話になった皆様、ありがとうございました。 職場近影（2018年1月） 一生に何度もあるイベントではないので、14年前に立てた入社目的を満足できたのかと、14年を経て自分の何が変わったのかを書いてみます。 私は誰？ 手広く働いてきたジェネラリスト寄りのITエンジニアです。研究開発、性能改善、製品開発、要件発掘、品質保証、テクニカルライター、OSPO、セキュリティ、SREなどを色々やってきました。「何やってる人なんです？」と言われてうまく説明できた試しがありません。 OSSプロジェクトではクラスファイル解析ツールSpotBugsやSLF4J向け静的解析ツールのメンテ
オブジェクト指向か関数型か、という話題に私達はどう接するべきか - Kengo's blog
私がコードを書くときには「オブジェクト指向でいくか、それとも関数型か？」みたいなことはほとんど気にしていません。特にオブジェクト指向については人によって定義から違うこともままあるため、この手の議論がとても遠回りになることも多いと感じます。 ただきしださんのLT資料を拝見して、もしかしたらまだ需要があるのかなということで、この話題にどう接するべきか考えていることを書いてみます。 どう書くべきかはコンテキスト次第 結論から書くと、どのようにコードを書くべきかはチームや解決したい課題、利用言語や既存資産などのコンテキストによって変わります。 ので「何がオワコンでこれからは何が来る」みたいな議論は、チーム内という限られたスコープでのみ有効なはずです。 チームよりも広い場で議論する場合は、「どういったコンテキストにおいてどのような書き方をするか」のように若干抽象的なテーマが適切でしょう。 言い換える
「非nullのint配列」をアノテーションで表すのは `＠NonNull int[]` ではない - Kengo's blog
正解は int ＠NonNull [] です。な、なんだってー！ 本当です。Java言語仕様書にも記載がありますが、配列を修飾する場合は [] の手前にアノテーションを書く必要があります。JVM仕様書に記載の例のほうがわかりやすいかもしれません： @Foo String[][] // Annotates the class type String String @Foo [][] // Annotates the array type String[][] String[] @Foo [] // Annotates the array type String[] 組み合わせて考えると、「要素も配列自体も非nullのString配列」は @NonNull String @NonNull [] になります。コレクションは @NonNull List<@NonNull String> みたいにわ
![「非nullのint配列」をアノテーションで表すのは `＠NonNull int[]` ではない - Kengo's blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/7fc20c7fb842fad13d6e4b938ef1084d4dbf5c3c/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F13208692334729908800%2F13574176438081076007%2F1649457525)
リリース自動化の嬉しみとその手法 - Kengo's blog
DevOpsやCIOps、GitOpsなどを通じて生産性向上を突き詰めていくと、コンパイルやテストだけではなくリリースまで自動したくなってきます。リリースには必要な作業が多く、また頻度も高くないため毎回思い出したり間違えたりが発生するためです。 特に変更内容をまとめて文書化する作業は、利用者に対する影響度もその煩雑さも高いため、自動化できれば文書の品質向上やリリース頻度の向上に大きく貢献できます。本記事では、筆者がNode/Java界隈でよく見るリリース自動化手法について紹介することで、リリース自動化の敷居を下げたいと思います。 なお本記事で言う「リリース」は、jarファイルやコンテナイメージなどビルドの成果物をリポジトリやGitHub Releasesにアップロードして他プロジェクトやデプロイ環境で利用できるようにすることを指しています。環境に対する「デプロイ」や、エンドユーザへの公開を
Gradle/Kotlinで開発する私的ベストプラクティス2022 - Kengo's blog
こちらのエントリーが素敵だなと思ったので、最近書いてるKotlinプロジェクトのベストプラクティスをまとめてみます。一部はJavaプロジェクトにおいても利用できるはずです。 zenn.dev 基本方針 参加障壁を下げる。OSSプロジェクトでもプロプライエタリ・ソフトウェアプロジェクトでも、新しい開発者が参加するコストを下げることには大きな意義がある。 環境差異を吸収する。javaにPATHが通ってさえいればOSに関係なくビルドが通るようにする。 プロジェクト固有ルールを作らない。Conventional CommitsやKeep a changelogなど、ひろく世に使われているルールを採用する。 Gradleを設定する Spotlessを使う コードのフォーマットはformatterに任せて人間は細かいことを考えない、というのが不特定多数が参加するソフトウェアプロジェクトのあるべき姿だと
JavaScript Actionsをnode16で動かすようにする - Kengo's blog
この記事はCI/CD Advent Calendar 2021に参加しています。 先日GitHub ActionsがNodeJS v12のみならずv16でも動くようになりました。 github.com 今まではNodeJS v12しかサポートされていませんでしたが、このv12は来年の4月でサポートが切れます。速やかにv16に移行したほうが良さそうですね。必要な作業は actions.yml の runs.using を書き換えるだけではありますが、他に必要になるであろう作業もいくつか紹介します。 package.json の engines.node を更新 package.jsonで実行に利用するNodeJSのバージョンを指定していた場合、それを更新する必要があります。16.13.1 が現在の最新バージョンなので、望ましい設定は以下のようになるでしょう： "engines": { "no
ソフトウェアプロジェクトではないGitHubリポジトリにどのようなライセンスを適用するか - Kengo's blog
ソフトウェアプロジェクトではないGitHubリポジトリにどのようなライセンスを適用するか？という問いを東京都オープン・ソース・ソフトウェア公開ガイドラインのIssueで見かけたので意見を述べてみます。結論を急がれる方は以下のサイトをどうぞ。 choosealicense.com なお筆者は弁護士でも法律家でもないので、ここの記載内容はあくまでも参考に留めるようご注意ください。また本投稿では、Open Source Initiative (OSI)による承認を受けたオープンソースソフトウェアライセンスに限らず、その他のライセンスも含めて「ライセンス」と呼んでいます。 GitHubリポジトリにライセンスを適用しないとどうなるのか GitHubの利用規約には以下の定めがあります： License Grant to Other Users Any User-Generated Content yo
「New Relic実践入門」感想、あるいはなぜ監視SaaS使うんだっけという話 - Kengo's blog
New Relic アニキこと清水さんから共著書「New Relic実践入門」をいただきました。ありがとうございます。清水さんにはかつてRDBMSの性能調査をいかに効率的かつ実践的にするかご教示いただいた恩があるのですが、今もその道を追求し活躍されていると知れて嬉しく思います。 破壊的イノベーションを現場の「あたりまえ」にする本書 さて本書は「Part 1. New Relicを知る」「Part 2. New Relicを始める」「Part 3. New Relicを活用する」の3部で構成されていますが、特に「Part 1. New Relicを知る」が割り切った構成になっています。「監視とは何か？」「既存手法にはどのような限界があったか？」「近年の技術革新による新たな課題は？」といった背景をすべてすっとばし、いきなり「オブザーバビリティとは何か？」の説明から入っているのです。まるでTyp
個人サービスやOSS開発の保守運用から何を学んだか - Kengo's blog
ホビープログラマいいよね🥺（ポジショントーク https://t.co/bkf6Nlnoxx— ㊗転剣アニメ化！ (@Kengo_TODA) September 14, 2021 というようなことを私はよく主に採用の文脈で口走るのですが、ちゃんと内容をまとめておこうと思ったのでメモ。特に保守運用を経験しているというのが強いと思っているので、そこに注力して書いてみます。 障害対応の経験が積める 10年ほど前にTwistoire （ついすとわーる）というサービスを運営した際に、利用想定の甘さから半日程度のサービス停止を招いたことがありました。 blog.kengo-toda.jp 個人が無償で提供していたサービスとはいえ、使ってくれているユーザに対してそれなりの責任を感じた記憶があります。またひとりで使っていたころには発生しなかった障害なので、単純に課題の分析と解決が面白そうに映るのも事実で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【SREとして入社】日々のアウトプットが接点に。3年以上かけて巡り会えた理想の働く環境と社会的意義の大きな事業 - LAPRAS NOTE
GitHub Actions 最近のやらかし一覧（2022年夏） - Kengo's blog
2021年のOSS活動状況まとめ - Kengo's blog
WIP: Gradleの機能でどこまでビルド性能が改善するのか - Kengo's blog
JJUG CCC 2021 FallでLT参加してきました - Kengo's blog
SpotBugs supports SARIF that helps integration with other SAST tools