とにかくケチりたい、そんな気持ちで作ったツールの話です。 元々開発にCline(Claude Dev)やAiderなどの開発ツールを駆使していました。 ただ、APIの料金が常に心配で、できる限り安く済ませたい気持ちもあり、Claude Proを契約してWeb版にファイルを1つ1つアップロードする日々を過ごしていました。 ある日それが面倒になってきて「全部1ファイルにしたらいい感じに読み込んでくれるのでは？」と思い、作ってみたら思いのほかうまくいったので公開しました。 百聞は一見にしかずということで、 こちらのデモにお気に入りのGitHubリポジトリ(例: honojs/hono)を入力してみてください。 Claudeが得意とするXMLっぽいフォーマットで出力し、そのままClaudeにアップロードすることができます。 完全にAIバブルの波に乗ったとも言えるのですが、多くの競合がいる中でスター
こういうのが欲しかったんだよ。マジで。 コマンドラインからLLMを呼び出せるgptmeというツールがアツい これは、gptmeコマンドを追加するというもの。 環境変数としてOPENAI_API_KEYとかAnthropicのキーとかを設定しておくと勝手にAPIを呼び出してくれる。もちろん、クラウドに送信するとかけしからんという勢にはローカルLLMでも対応できる。 こいつはコマンドライン版ChatGPTのようなものなので、コマンドラインで動くのだが、その真価は例えばパイプで繋いだ時とかに発揮される。 $ du -d 1|gptme "一番容量を食ってるフォル ダは何Gバイト使ってんの?" Found OpenAI API key, using OpenAI provider [10:13:32] No model specified, using recommended model for
この記事は Vim 駅伝 の 07/15 の記事です。 前回の記事は staticWagomU さんによる、 06/12 の「mini.nvimを使って環境構築したら優勝した」という記事でした。 次回は 07/17 に投稿される予定です。 はじめに 1ヶ月ほど前に Vim のマイナーなテクニックを紹介する記事を公開し、ありがたいことに非常に多くの方に読んでいただきました。 この記事では特にデモ動画を多く載せることを意識していました。数えてみると8つもの GIF 動画が例に用いられています。Vim を用いた編集のスピート感を視覚的に示すことで、紹介したテクニックの魅力がより効果的に伝わったのではないでしょうか。 元記事の末尾に書いた通り、「中級 Vim 操作」では VHS というコマンドラインツール (CLI) と Neovim、そして nvim-keycastr というプラグインを用いてデ
はじめに 以前紹介させていただき、2022年Qiitaのいいねランキング18位、ストックランキング20位を記録したこちらの記事の続編です！ DevToysはリリース後しばらく定期的なバージョンアップが続けられていましたが、去年の7月からぱったりとアップデートが止まっている状態でした。 リポジトリや作者のXを見るとバージョン２の開発を行っているようで、今か今かと待ち続けていましたが数日前リリース予告のポストを見つけて、今日ついにプレリリースされました！ ということで早速紹介していきます！ DevToysとは DevToysは「開発者のためのスイスアーミーナイフ」の紹介文の通り、開発時によく使うツールを十徳ナイフのようにまとめたアプリとなっています。 JSONの整形とかエンコードデコードetc... プログラミングや保守運用の調査でやりがちな作業をいちいち変換サイトを探したり、エディター拡張機
最初に3行でまとめ AWS CLIは便利です。しかし起動が遅いので、Goで実装された高速な(ただし機能は少ない)代替品を作りました。awslim といいます リリースバイナリは無駄に大きいので、必要な機能だけを組み込んだビルドを簡単にできるようにしてあります。ビルドして使うのがお勧めです どうぞご利用下さい github.com 以下はこれに至るまでの経緯とか、実装や使い方の話とかです。長いです。 作成の経緯 AWSの各種サービスにアクセスするための AWS CLI は、スクリプトやコマンドラインから処理を自動化するために大変便利なツールです。AWSでサーバーサイドの開発、運用している人であれば、ほぼ全員がお世話になっているんじゃないかと思います。 しかし、AWS CLI (コマンド名aws) には「起動が重い」という問題があるなとずっと思っていました。具体的には、aws --versio
めちゃくちゃ良い記事でした。 「OSS は使っていることを公言するだけでも貢献になる」と songmu さんが言っていたので、私も貢献したいと思います。 僕も貢献したいのでよく使うコマンドラインツールを紹介していきます。 特定のプログラミング言語等に依存するツールは省いています。 actionlint - GitHub Actions の Workflow ファイルの静的検査 GitHub Actions の Workflow ファイルの静的検査ツールです。 かなり精度が高く、色々な設定ミスを検知してくれます。 エラーメッセージも見やすくて助かります。 aicommits - コミットメッセージを自動生成 変更内容を元に自動でコミットメッセージを AI が生成してくれるツールです。 コミットをする前にちゃんと確認してくれるのも安心感があって良いです。 cLive - ターミナル操作を自動化
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
deno で CLI ツールを作っていたら楽しくなって色々作っていた。 課題: モノレポの諸々の操作がだるい npm/pnpm/yarn の workspace を使っていると、次のようなディレクトリ移動が段々面倒になってくる。 foo を build して bar を build してルートから bar のテストを流す、みたいなことをするとこういう感じになる。 $ cd packages/foo $ pnpm build $ cd ../bar $ pnpm build $ cd ../.. ## コマンドの中身を確認 $ cat package.json | jq ".scripts" { "test": "pnpm test:foo && pnpm test:bar", "test:foo": "cd packages/foo && pnpm test", "test:bar": "
tl;dr fig starship zsh fzf sheldon なぜ vscode の .vscode/tasks.json が fishと非常に相性が悪い。とくに fish-nvm を使っていると、fish 経由のパス実行時に node と npm へパスが通らない。 そもそも fish を使っていた理由は autocomplete を快適にするためだったが、1年ぐらい Fig を使っていて、補完はこれを任せていいと気づいた。 Fig はこういうやつ そもそも fish の拡張コマンドを使わないように生活していた。方言を覚えたくない。というか bash 拡張や zsh 拡張もあんまり覚えたくない。
WatchmanA file watching service Watches files and records, or triggers actions, when they change. Watchman exists to watch files and record when they change. It can also trigger actions (such as rebuilding assets) when matching files change. ConceptsWatchman can recursively watch one or more directory trees (we call them roots).Watchman does not follow symlinks. It knows they exist, but they show
chat-hatenablogをpip installでインストール可能にした - $shibayu36->blog;にてchat-hatenablogをpip installできるようにするとき、ユーザー設定ファイルやデータをどこに配置するかに迷った。このツールでは、環境変数の設定として.envファイルを、ブログデータのインデックスとしてindex.pickleファイルを使っている。 これらのファイルの置き場所について少しだけ調べたので、現状分かったことをメモしておく。 まず選択肢としては二つありそうだった。 ~/.chat-hatenablog/.envと~/.chat-hatenablog/index.pickle 例) ~/.asdf、~/.docker、~/.gemなど XDG Base Directoryの仕様に沿って、~/.config/chat-hatenablog/.en
はじめに 現代のアプリケーションは外部サービスのAPIキーなど様々なクレデンシャルを持つことが多いです。 これらを開発者間で安全に共有するには sops、 doppler、 git-crypt などのツールが使えます。 また、開発時はこれらのクレデンシャルを direnv などを使って環境変数に設定することも多いのではないでしょうか。 しかし、これらはどれも追加のツールをインストールする必要があります。 もし1Passwordを使っているチームに属しているなら1Passwordでクレデンシャルを管理して、それを環境変数にセットできると新たなツールを導入する必要がなくて楽です。 この記事ではそれを実現する手順を紹介します。 CLIの設定 まず1PasswordのCLIをインストールします。これで op コマンドが使えるようになります。
1PasswordにはVS Code拡張があって、.env ファイルなどにハードコードされたシークレットを1Passwordに保存して、secret reference というURL形式に置き換えてくれる。 ちなみにコミュニティ製のJetBrains IDE用の拡張もある。 これを使って .env.local.template を作る。 TWITTER_CONSUMER_KEY='op://Private/Twitter/API Key/consumer_key' TWITTER_CONSUMER_SECRET='op://Private/Twitter/API Key/consumer_secret' op:// のところがsecret reference。 .gitignore ファイルでは .env.local は無視しているけど、.env.local.template はリポジトリ
LayerX の Enabling Team でソフトウエアエンジニアをやっている suguru です。LayerX Tech Advent Calendar 2022 の 12/12 のの記事になります。 今日は、入社して最初に開発した社内ツールの話をしようと思います。 LayerX のバクラク事業部では、バクラク請求書、バクラク申請・経費精算、バクラク電子帳簿保存、バクラクカードなど、複数のプロダクトを運用しています。 內部のアーキテクチャとしては、プロダクトごとに独立したAPIが環境で稼働しており、プロダクト間連携は、お互いの Private API を通じて連携しています。そのため、バクラクの開発用環境をローカルで構築するには、複数のプロダクトのAPIサーバーを稼働させる必要があります。 バクラクのサービスアーキテクチャについては、下記のスライドを参照してください。 お客様に対して
AWSアカウントを組織で管理していると複数アカウント利用するケースは多いかと思う。別のアカウントに切り替えるには、WebコンソールからSwitch Roleすればよい。そして以下のように $HOME/.aws/config と $HOME/.aws/credentials を設定すればAWS CLIからもSwitch Roleできる。 $ cat $HOME/.aws/credentials [main-account] aws_access_key_id = ACCESS_KEY_ID aws_secret_access_key = SECRET_ACCESS_KEY $ cat $HOME/.aws/config [profile sub-account] source_profile = main-account role_arn = ROLE_ARN mfa_serial = MF
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
