はてなブックマーク

GitHub Copilot WorkspaceのTechnical PreviewがGitHub有償ユーザ向けに公開されました。GitHub Copilotを有償で利用している方は、すぐに使える状況になっていると思います。 僕も少しだけ使ってみたのですが、今後の開発プロセスを大きく変えていくだろうなという感触を持ったので、ではその「変わった先」というのがどういうものになると思っているのかを書いてみます。 GitHub Copilot Workspaceとは GitHub Copilot Workspaceの苦手なところ 僕たちのプロセスをどう変えるのか 課題はプロンプト生成 設計仕様とテスト工程の連携 では開発フローは？ 設計との向き合い方 GitHub Copilot Workspaceとは GitHub Copilot Workspaceを一言で言うと、AIを活用したコーディング支援

概観 ツール定義 処理の流れ 処理主体 Clineの処理の流れ タスクの初期化 recursivelyMakeClineRequestsでどうやってタスクの計画を行うのか ツールを使うサブタスクに分割するためのtool use まとめ Clineは、ユーザの指示を実現する「計画と実行」を行う自律型コーディングエージェントです。コーディングエージェントとしてはNo.1の地位を築いているのではないでしょうか。 このエントリでは、Clineの内部構造とその動作の流れを、ソースコードの実際の箇所を交えながら書いてみます。対象バージョンは今日リリースされたばかりのCline v3.1.0です。ホヤホヤですね。 概観 ClineはいくつかのToolを内部で定義しており、ユーザの指示を実現するためにどのToolをどのような順で使っていくかを「計画」し、実行すると言うのが基本的な流れになります。 ツール定

Dockerfileにも当然ベストプラクティスが存在し、それをチェックするLinterも存在します。 Best practices | Docker Docs GitHub - hadolint/hadolint: Dockerfile linter, validate inline bash, written in Haskell そのベストプラクティスと呼ばれる1つに、apt-get installでのversion pinがあります。 version pinとは 一言で言えば、apt-get installでパッケージをインストールする際、明示的にパッケージバージョンを指定することです。 Datadogのブログ記事にも、このベストプラクティスが紹介されています。 version pinといっても具体的にどういうものか、となるので、ベストプラクティスに則った例を上記エントリから引用しま

従来の検索エンジン Perplexity.aiの検索 RAGとの関係 perplexity.aiでリサーチするときのプラクティス 英語で検索しよう しっかり調べたい時はPage機能を使う ちょっとした調べ物 今使えるモデル まとめ Perplexity.aiがすごく良かったです。何か知りたいことが出てきたら、Google検索するよりもPerplexity.aiで検索している。 Perplexity.aiは、生成AIを用いた検索エンジンと見なすことができるサービスで、情報収集の効率を劇的に向上させてくれます。ユーザーの質問に対してWebをクローリングし、関連情報を要約し、それらの参照リンクとともに高精度な回答を提供してくれる。 最初にネタバレしておくと、このエントリ自体もかなりの部分をperplexity.aiの要約と回答生成能力に頼りました（Github Copilotにもわずかに頼ってい

「先送り0」を読みました。 先送り0（ゼロ）―「今日もできなかった」から抜け出す［1日3分！］最強時間術 作者:jMatsuzaki,佐々木 正悟技術評論社Amazon タスク管理とTaskChuteCloud 先送り０ タスク管理の罠 順算のアプローチはアジャイル的 終わらせるより始めることが大事 まとめ タスク管理とTaskChuteCloud タスク管理というやつは本当にいつまで経ってもついてくる未解決の課題であって、まぁ人生続く限り解決することはなさそうです。 それでも何かに縋らなければ、自分を支えるフレームワークみたいなものを見つなければただ一人苦しむだけなので、皆さんもそれを探すのに一生懸命なことでしょう。 僕はこの辺りのタスク管理フレームワークはGTD (Get Things Done)から入り、 そのあとはずっと、佐々木正悟さん、大橋悦夫さんのタスク管理本に感銘を受けてタス

Golangで作ったプロダクトを公開・配布するとき、課題となるのが利用するモジュールのライセンスです。 MITライセンスであれ、MPLライセンスであれ、利用するモジュールのLICENSEやNOTICEファイルを同梱することになるでしょう。 goxzとgo-licensesを使うと、クロスビルドした実行バイナリと利用モジュールのLICENSE等を含め頒布物を作成できるようになります。 最終イメージ 同梱されていることの確認 go-licenses ハマりポイント goxz まとめ 最終イメージ 最終イメージですが、以下のようなMakefileを用意しました。 プロダクトに設定したライセンスで利用できないモジュールがあるかどうかをlicense-checkで確認した後、cross-build.shを呼び出します。 .PHONY: license-check license-check: go-

僕自身は、「他の人に任せる」というところが決定的に苦手であることを自覚しています。 これは10年近く自覚している自分の課題であって、緩やかに改善はしてきているんですが、それでもまだ足りない。 そんな悩みを1 on 1で相談した時に紹介いただいたのがこの本でした。 技術者の知的生産性向上―技術KI計画 作者:岡田 幹雄日本能率協会マネジメントセンターAmazon 1993年発刊ということで歴史を感じる一方で、まぁ良くもまぁ自分の悩みをぶち当てているなと。 技術部門における「悪魔のサイクル」 技術KI計画 悪魔のサイクルを断ち切るための「見える計画」 「見えた課題」の解決 計画が決め手 計画の立て方 アウトプットからの逆算 振り返ってみて 技術部門における「悪魔のサイクル」 この本でまず語られているのは、技術部門の課題です。 テーマ数の増大に対して、常に技術者の補充が追いつかず、目先の日常業務

このエントリでは、マルチテナントアプリケーションを構築する場合に、テナントに紐づくデータをどう安全に扱うかという点でRLSについて記載します。 特に、1ユーザが複数テナントに関する権限を持つ場合にRLSをどう適用すべきか、頭を悩ませました。 マルチテナントアーキテクチャ Row Level Securityとは 設定例から読み解くRLSの挙動 CREATE POLICYから読み解くRLS マルチテナント安全性のための単純な設定例 テナントごとにユーザーを切り替える テナントの情報をDBセッションあるいはDBトランザクションに持たせる ログインユーザが複数テナントの権限を持てる場合の対応 テナントIDのリストを文字列化 USINGの中でテナントIDを取得 マルチテナントアーキテクチャ SaaS Storage Strategiesによれば、マルチテナントアプリケーションを実現するためのアーキ

多くのライブラリにはライセンスが付属しています。 利用する側は、当然このライセンスに定められた条件を満たさねば、当該ライブラリを使うことができません。 多くのライセンスでは「頒布」(distribution) 行為に対して条件を課しています。そして、この「頒布」に関し、問題になり得るのがJavaScriptです。 JavaScriptで作成されるWebアプリケーションには、様々なOSSのモジュールがimportされbuildされ、クライアントにダウンロードされるわけです。 果たして、これは「頒布」にあたるのか、というところを懸念していました。 なお、僕はこの界隈の専門家ではないので、それを前提に以下お読みください。 クライアントサイドJavaScriptの利用形態は頒布にあたる ライセンスについて ライセンスのチェック クライアントサイドJavaScriptの利用形態は頒布にあたる 以下は

Lambda関数からRDSを利用する必要が生じ、次世代のO/Rマッパと称されるPrismaを利用することにしました。 Lambda関数自体は、Serverless Frameworkで管理しています。 本エントリでは、Serverless Framework + Prisma + Lambdaの構成におけるノウハウを記述していきます。 Prismaのアーキテクチャ Prisma Engine Prisma Schema Prismaのデプロイ Prisma Engine Serverless Frameworkでのバンドル データベースアクセス 接続 コネクションプール RDS Proxy 感想 Prismaのアーキテクチャ まず前提となるのが、Prismaのアーキテクチャです。 Prismaは以下の3つの要素で構成されますが、今回はPrisma Clientのみを対象とします。 Pris

会社の中でシェルスクリプトについての話をすることにしたので、このエントリはそのためのものです。 個人的な好みとかもいろいろ入ってしまっているので、そのあたりは取捨選択してください。 なぜ今シェルスクリプトを学ぶのか 公開されているSRE本をマルっとPDF化する SpotBugsのViolationレポートをMerge Requestのコメント投稿する ぼくの互換性についての考え方 何で書くか シェルスクリプトをうまく書くには ShellCheckを使う バッドパターンとその修正 line-by-lineの処理が多い lsを使う ls /directory | grep mystring ls | grep -v 'log$' lsの結果をループさせる 良いシェルスクリプトを書くためのTIPS set -euする 文字列は基本的にクオートする 局所変数にはlocalを使う 定数は読み取り専用

MarkdownファイルをPandocでHTML化する際、どのような指定が良いかを迷っていたのですが、いまのところ以下のようなオプションで落ち着きました。 HTMLテンプレート Table of Contents(TOC)の作成 画像ファイルの同梱 $ pandoc \ --standalone \ --self-contained \ --resource-path=/path/to \ --toc \ --toc-depth 2 \ --shift-heading-level-by=-1 \ --metadata title='タイトル' \ --template=html_templates/bootstrap_menu.html \ --fail-if-warnings \ --output=${destdir}/guide.html \ /path/to/target.md HT

特定の文字列がある行から、別の特定の文字列がある行までを抽出したいということがよくあります。 これgrep等を使うと苦労する話なんですが、flip-flop演算子を使ったPerlのone-linerで可能です。 例えば昨日の記事ではgit help commitの中から--no-edit/オプションの説明を抽出しました。 これは--no-editという文字列が出てくるところから空行までを抽出すれば良い。これは以下のようにすれば可能です。 $ git help commit | perl -nle 'print if /--no-edit/ ... /^\s*$/' 解説自体に空行が混じるケースでは以下のようにすれば良いでしょう。 この例では、--cleanupという文字列が出現してから、次のオプション(-文字列形式)が出るまでを抽出しています。 $ git help commit | pe

Golangのツールをチームで開発しているのですが、Merge Requestをmergeする度にgo.sumとのconflictが発生する。つらい。 実のところは「つらすぎる」というほどつらくはないのですが、毎回conflict markerの<<<<<<<を消していく作業で人生を浪費するのはつらい。 というわけで、暫定的に.gitattributesでunion merge driverを指定する運用をはじめてみました。 $ grep go.sum .gitattributes go.sum merge=union .gitattributesについてはここでも書いた。 理屈 テキスト系ファイルに対しGitで利用されるデフォルトのmerge driverはtextです。 このmerge driverでconflictが検出されると<<<<<<<や>>>>>>>でconflictしている

Trunk-based developmentという開発手法があります。 State of DevOps 2019では、ソフトウェアのデリバリ能力、ひいては組織パフォーマンスをドライブする要素の1つであるとされています。 (図もState of DevOps 2019から引用) Trunk-based Developmentとは Trunk-based Developmentは、各コミッタが直接trunkにコードをプッシュするか、あるいは短命なbranchを作ってガンガンtrunkにマージ1するという戦略です。 (図はIntroductionより引用) その狙いは以下の2点で、その効果はDORAのレポートで立証されています。 マージするコード量が少ないため、マージに伴うリスクが小さい 開発タスクのサイズが大きくても数日サイズとなり、バッチサイズが小さくなる 2016 年（PDF）と 201

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

OSSのライセンスをどう設定したものかと悩むことがあり紹介いただいて読みました。 OSSライセンスの教科書 作者:上田 理技術評論社Amazon ぼくのこれまでのOSSライセンスへの理解が小学生並だったこともあり、読んで非常によかったです。 もはやOSS利用のないソフトウェア開発はほぼ無いという認識なので、こういったライセンスの話は新人研修などで取り上げても良いのではないでしょうか。 書籍の概要 感想 書籍の概要 大きく分けて「基本編」「実務編」「戦略編」に分かれています。 「基本編」は、そもそもOSSを利用する意義が何かから始まり、ソフトウェアと著作権の関係、ソフトウェアを利用・頒布するためのOSSライセンスの種類とその概要が示されます。私が読んでよかったと思ったのはまさにこの編でした。 ソフトウェア開発のプロフェッショナルが持つべき最低限の常識として、ソフトウェアを利用するときには著作

様々なドキュメントが Markdown で表現される今日このごろです。 多数の人が関わりつつドキュメントを成長させるのであれば、 Markdown ドキュメントについてもフォーマットを統一させたいものですね。 Markdown についても当然のように linter があるので、こちらを GitLab CI/CD で回せるようにします。 とはいえ、語ることはほとんどなくて、あまり悩むことなく設定できます。 今回はリポジトリ配下の全 .md ファイルに対して lint をかけるようにしてみました。 唯一悩んだのは「どの Docker Image を使用するか」でしたが、Terraform の公式で使っている Docker Image を使うようにしました。 stages: - lint variables: MARKDOWNLINT_VERSION: 0.23.0-alpine markdow

AWS においてはマルチアカウント戦略が重要とされています。 たとえば、開発環境/ステージング環境/本番環境といった各環境は、セキュリティ、ガバナンス面で分離すべきです。 メンバーの権限管理がすっきりする 特定の環境の作業が他環境に影響しない このようなマルチアカウント管理を実現するためのベストプラクティスとして、AWS Organizations の利用が挙げられます。 AWS Organizations は複数の AWS アカウントを統合できるサービスで、アカウントを作成できるだけでなく、それらの階層化や一括したポリシー管理も可能です。 今日はこれを試してみました。 AWS Control Tower のマルチアカウント構成 terraform 参考文献 AWS Control Tower のマルチアカウント構成 AWS Organizations を有効にしたアカウントは「マスタアカ

AWS で環境を構築する際はマルチアカウントになることが多い、これは理解していたつもりでした。 stg 環境と prod 環境は AWS アカウントごと分ける。dev 環境も分ける。 しかし、世の中のベストプラクティスはもっと先を行っていました。 なぜアカウントを分けるのか isolation authz & authn auditing and reporting 世の中のマルチアカウント構成 各企業の事例 AWS が提供するベストプラクティス Gruntwork から見た AWS ベストプラクティス 各社のプラクティスから読み取れること なぜアカウントを分けるのか AWS アカウントを分ける理由は 3 つあります。 isolation authz & anthn auditing and reporting isolation そもそもとして、環境は分離しないと、というものです。 st

TCP レベルの疎通確認のときにはよく telnet を使っていたのですが、最近いろいろな OS で telnet が入っていません。 こういうときに、実は curl で telnet を代替できます。 telnet をプロトコルとして指定するだけです。 以下の例では、google に 80 番ポートで接続して、 HEAD リクエストを送っています。 $ curl -s telnet://www.google.com:80 HEAD / HTTP/1.0 HTTP/1.0 200 OK Date: Sun, 05 Apr 2020 07:15:31 GMT Expires: -1 Cache-Control: private, max-age=0 Content-Type: text/html; charset=ISO-8859-1 P3P: CP="This is not a P3P p

新しいことを始めようとしていて、仮想プレスリリースを書くことを求められています。なにぶん初めての経験ではあるので、なぜ仮想プレスリリースが必要なのか、今後の自分のためにきちんと明文化しておきます。 仮想プレスリリースを書く目的 仮想プレスリリースに何を書くのか 参考文献 仮想プレスリリースを書く目的 仮想プレスリリースを書く目的を調べるときに多く出てきた文章があります。 "We work backwards from the customer, rather than starting with an idea for a product and trying to bolt customers onto it." つまりは、プロダクトのアイデアからはじめてそこに顧客を当てはめようとするのではなく、顧客から逆算して考えるというアプローチを取る。この文意を噛み締めながらプレスリリースを書く意

先述の通り、新年を迎えたことをきっかけに Mac を初期化しました。 面倒なのは、使っているソフトウェアのインストールなのですが、皆さんと同様 homebrew を使っています。 そういえばと思い立ったのですが、この homebrew で各種 CUI アプリケーションとともに AppStore で配布されているソフトウェア（例えば LINE や Evernote など) も一気にインストールできることはイマイチ知られていません。というわけで、本エントリではそのあたりをご紹介します。 GUI アプリケーションのインストール 野良アプリのインストール (cask) AppStore 配布のアプリケーションのインストール (mas) いちいちコマンド発行するのも面倒 (Brewfile) Brewfile のみでアプリを管理する (brew bundle cleanup --force) GUI

昨日 Linuc 303 (Security) を受験してきました。いわゆる資格試験はかなり久しぶり、特に Linux 系の試験となると 5 年ぶりになります。そう、なぜ 5 年ぶりに Linux 系試験を受けたのかというと、ぼくの LPIC Level 3 の有意性期限が迫っているためでした。 LPIC は認定制ですが、その有意性は 5 年間の期限があり、それ以降も当該の有意性を維持しようと思うと、同レベルあるいはより上位のレベルの試験に合格する必要があります。 ぼくは 2014 年に LPIC 304 (Virtualization & High Availability) を取得して以降、完全に放置してしまっており、あーそういえば LPIC そろそろ受けないとなぁと思ってマイページを見ると、もはや期限切れの瀬戸際でした。 試験予約を入れた当日に台風 19 号が到来した結果、LPI-J

k8s を本格的に使うことになり、プロジェクト内でも、Helm だの Spinnaker だの Kustomize - Kubernetes native configuration management だの Skaffoldという言葉がどんどん slack 上に登場してきています。 しかしですね、ぼくは時代を読み間違えておりまして、ぜんぜん k8s を勉強してこなかったわけですよ。一年以上前にちょっとこれ読んだだけ。 kiririmode.hatenablog.jp もう何が何やらわからんくなってきたし、スプリントプランニングでファシリテーションしてたら helm と kustomize 間違えて赤っ恥をかくし、まずは体系を押さえないとダメ! 話にならない!! ついていけない!!! 死ぬ!!!!! ということで、id:ZYPRESSEN さんに参考になるオススメ書籍聞いて、とりあえず読