Cybozu Productivity News

#6 - 2023.02.09

Cybozu Productivity Weekly 100 回記念

共有担当: @miyajan

文章作成の頼れるアシスタント、AI搭載のDeepL Writeが新登場

共有担当: @miyajan

  • 文法の間違いを修正するだけでなく、言い回しなども提案してくれます
  • ベータ版、無料
  • DeepLの個人情報保護方針によると、DeepL Pro でログインしているユーザーは、DeepL と同様に、DeepL Write で入力したテキストは保存されず学習にも使われないようです

コンテナ開発用のオープンソースクライアント「Finch」のご紹介 | Amazon Web Services ブログ

共有担当: @ganta0087

Unlock any CLI using Biometrics with 1Password Shell Plugins | 1Password

共有担当: @ganta0087

  • 1Password CLIのShell Pluginによる各種CLIへシークレットを渡すしくみの紹介
  • 1Password CLI 2.0でサポートされたTouch IDを、他のCLIでも認証が必要な場面で利用したいという要望が多くあり、それが実現された
  • 例えば、GitHub CLIで利用するパーソナルアクセストークンを1Passwordに保存しておき、ghコマンド実行時にそれを参照するようにできる
    • GitHub CLI側でOAuthトークンも対応しているが、トークンを安全に保存しておきたい場合や、OAuthのスコープ外のAPIを使いたくてPATを使うときに有用
  • op plugin listで対応ツールが一覧できる
  • 原理としては、ユーザーがシェル起動時にプラグイン用のスクリプトを読むように設定、そのスクリプト内で元のコマンドで1Password CLIへのエイリアスを張っている
    • 例: alias gh="op plugin run -- gh"

Amazon Virtual Private Cloud (VPC) は AWS アカウント間の Elastic IP アドレス転送のサポートを開始

共有担当: @defaultcf

  • 今まで AWS アカウント間で Elastic IP アドレスを転送するには、転送する側と受け取る側それぞれでサポートに依頼する必要がありました
  • または Elastic IP アドレスを新しく割り当てることになり、ファイアウォールなどに新しく登録する手間などがありました
  • 今後はサポートへの連絡は不要で、次の手順でアカウント間の Elastic IP アドレスの移行が可能です
  • 注意！
    • Elastic IP アドレスは同じ AWS リージョン内にしか転送できません
    • 7時間以内に転送先の AWS アカウントで Elastic IP アドレスの転送を受け入れなければ、Elastic IP アドレスは元のアカウントの所有に戻ります
    • 転送後、その Elastic IP アドレスに関連付けられたタグは削除されます
  • 意外とアカウント間の Elastic IP アドレス転送は需要が高い気がするので、ありがたく使っていきましょう

AWS上で開発環境一式、フレームワーク、初期コード、IDE、ビルド環境、CI/CDなど提供する「Amazon CodeCatalyst」発表

共有担当: @defaultcf

  • 無料枠があり、次の範囲で利用可能です（参考: https://codecatalyst.aws/explore/pricing ）
    • 1月1スペースあたり2,000分のビルド時間
    • マシンスペックは 2 vCPU/4GB (Linux only)
    • 開発に使える時間は60時間
    • ストレージは64GB
  • 現在のところ、米国西部(オレゴン) us-west-2 リージョンしかサポートされていません
  • プロジェクト作成してみました
    • codecatalyst.aws からアカウントを作成し、既存の AWS アカウントと紐付けることで環境を作成できます
      • AWS アカウント ID を入力し、verify のリンクがクリックすると AWS Console に遷移するので、そこで accept をクリックすると紐付けが完了します
    • プロジェクト作成時にロールを割り当てます
      • 数クリックでロール作成と必要な権限の付与が完了します
      • プロジェクト作成時に Amazon Catalyst がどのような権限を要求するのかが表示されるので、安心できます
    • Web IDE はデフォルトで Cloud9 ですが、他に Visual Studio Code, Intellij IDEA Ultimate, GoLand, PyCharm Professional が選択可能です
    • ソースコードは CodeCatalyst でホストできる他、GitHub, Jira Software 上のリポジトリのものを使用できます
  • CI/CD をプロジェクト上で実行できます
  • GitHub Codespaces といい勝負になりそうな感じがしています
    • エディタの機能差は見つけられませんでした
    • CI/CD について、
      • GitHub Codespaces なら Actions を使えば良いので資産がそのまま活かせます
      • Amazon CodeCatalyst の場合、新しいスキーマでワークフローを構築する必要があるので多少学習コストがかかりそうです

Node.js 18.x runtime now available in AWS Lambda | AWS Compute Blog

共有担当: @defaultcf

  • AWS Lambda で Node.js 18.x が使えるようになりました
  • Graviton2 プロセッサなら最大34%性能向上が見込めるそうです
  • AWS Lambda の Node.js 18 のランタイムには AWS SDK v3 が同梱されています
  • Node.js 18.x でどのような変更が入ったかまとめてみました
    • fetch 関数がフラグ無しに使えるようになりました
      • ただし Experimental のため注意
    • class fields と private class methods が使えるようになりました
    • 他に JSON import assertions, Test Runner module, Web Streams API が使えるようになりました
  • パフォーマンスは向上し、使えるようになった機能も増えましたので、この機会に是非アップデートしましょう

GitHub Actions: larger hosted runners are now automatically created for customers | GitHub Changelog

共有担当: @r4mimu

  • 2022年9月 GitHub Actions において、より強力な GitHub-hosted Runner が使える機能 larger runners がパブリックベータで登場しました
  • これに加えて、よく使われる OS,スペックの組み合わせを GitHub がデフォルトで用意してくれる Default Larger Runners が登場しました
  • larger runners はユーザがあらかじめカスタムしたランナーを登録しておく必要がありました(参考)
  • Default Larger Runners はランナーグループであり、ワークフローでラベルを指定するだけで larger runners が利用できます
    • 現在 4種類の larger runners が用意されています
      • 4-cores Ubuntu Runner
      • 8-cores Ubuntu Runner
      • 16-cores Ubuntu Runner
      • 8-cores Windows Runner
    • ubuntu-latest-4-cores のようにラベル指定をします
  • GitHub Teams および GitHub Enterprise Cloud ユーザ向けの機能であり、ベータプログラムへのサインアップが必要となります
  • ラベルを指定するだけで、 GitHub-hosted の強いマシンが使えるのは手軽で嬉しいですね

Manage caches in your Actions workflows from Web Interface | GitHub Changelog

共有担当: @r4mimu

  • GitHub Actions のキャッシュが WebUI 上で削除可能になりました
  • 以前までは API または GitHub CLI を利用した削除方法しかなかったので、だいぶお手軽に削除できるようになったと思います
  • 余談ですが何故か GitHub blog の Changelog からは該当記事が消えてました...

Granular control over cache restore and save · Discussion #1020 · actions/cache

共有担当: @r4mimu

  • GitHub Actions の actions/cache アクション v3.2.0 から、restore と save の処理が独立したアクション actions/cache/restore と actions/cache/save が登場しました
  • ブランチごとにキャッシュの制御をするワークフローが作れるようになりました
  • トピックブランチではキャッシュを保存しないといった運用をすることで、GitHub Actionsのキャッシュ容量を節約したりもできそうです

GitHub Actions – Support for organization-wide required workflows public beta

共有担当: @r4mimu

  • GitHub Actions において、Organization 内の指定リポジトリに必須ワークフローを設定できるようにする機能が追加されました
  • Organization 内のリポジトリに対して、同 Organization 内のワークフローファイルのパスを指定して必須ワークフローを設定します
    • 必須ワークフローはリポジトリごとに適用できます
  • 生産性向上チームでは、ライセンスチェックの強制のために使えそうといった印象でした
  • 平木場さんがスクラップで実験や所感を書いているので参考になると思います

GitHub Actions - Support for configuration variables in workflows | GitHub Changelog

共有担当: @r4mimu

  • GitHub Actions において secrets とは別に、variables が登場しました（public beta）
  • secret は暗号化されるため、機密情報でないデータでも値が確認できないので不便でした
  • 一方、variables は secrets とは異なり平文で保存されます
    • variables を使うと、ログに値がそのまま表示されます
    • また、variables の設定画面で現在の値を確認できます
  • ワークフローからは変数を ${{ vars.VARIABLE_NAME }} というコンテキストでアクセスできます
  • これまでは、機密性がないが再利用したい変数でも secrets を利用した場合、マスクされなくてもいいのにマスクされたり現在の値の確認が面倒でしたが、variables で気軽に変数を扱えそうです

Renovate config の変更が想定通りか確認する 〜真の dry-run を求めて〜

共有担当: @korosuke613

  • 依存関係を更新するプルリクエストを自動で作ってくれる Renovate の設定を変更する際に、その設定変更が想定通りかを dry-run で確認する方法です
  • Renovate CLI には --dry-run オプションがありますが、このオプションだけだとリモートリポジトリのデフォルトブランチの config を参照してしまうため、ローカルの config やトピックブランチの config の dry-run はできません
  • RENOVATE_CONFIG_FILE と --require-config=ignored を組み合わせることでデフォルトブランチの設定を無視しつつ、ローカルの Renovate config で動作確認できます
  • 記事ではこの結論に至るまでの道のりと、各オプションの簡単な解説などが載っています
  • ちなみに僕の書いた記事です

Never write a commit message again (with the help of GPT-3) · Roger Zurawicki

共有担当: @korosuke613

  • GPT-3 を使ってコミットメッセージを自動生成するツール、zurawiki/gptcommit の紹介ブログです
  • 記事にはデモ動画や先行研究、仕組みの概要などが載っています
  • OpenAI の API を利用しているため、業務で使う場合は社外費の情報が漏れないよう注意が必要です
  • git hooks を利用する前提となっています
    • 個別のリポジトリ（業務以外の私的リポジトリなど）にのみ使いたい場合はちょっと面倒です
    • 僕は git hooks をいじって特定のリポジトリでのみ動くようにしてみました
  • 実際に、今回自分が書いた差分をgptcommitに食わせてみました
    • その時の diff と生成されたコミットメッセージ
    • Add a section about verifying Renovate configs with dry-run や Add a section about a GPT-3 tool for auto-generating commit messages という風に、いい感じにコミットメッセージを生成できています
    • しかし、Update Node.js EOL date to `2023-12-11` とあるように、今回の変更とは関係ないメッセージも入っちゃってます
      • 実際に変更はしていませんが、diff の結果にギリギリ含まれているのが関係しているかもしれません
  • conventional commit 的なの（fix とか feat とか頭につけるやつ）をしてほしいところですが、現状対応されていません

We are hiring

サイボウズの開発者の生産性を上げる「生産性向上チーム」とは！？