GitHub - seratch/ChatGPT-in-Slack: Swift demonstration of how to build a Slack app that enables end-users to interact with a ChatGPT bot
# Create an app-level token with connections:write scope export SLACK_APP_TOKEN=xapp-1-... # Install the app into your workspace to grab this token export SLACK_BOT_TOKEN=xoxb-... # Visit https://platform.openai.com/account/api-keys for this token export OPENAI_API_KEY=sk-... # Optional: gpt-3.5-turbo and gpt-4 are currently supported (default: gpt-3.5-turbo) export OPENAI_MODEL=gpt-4 # Optional:
gh auth loginで作成されたクレデンシャルだけで生活するためにgh-doを作った - Copy/Cut/Paste/Hatena
やっとgh auth loginで得たクレデンシャル（OSのセキュアストレージに保存されているもの）のみを使う生活になったぞ— k1LoW (@k1LoW) 2023年5月15日 GitHub CLIの gh auth login で作成されたクレデンシャルはOSのセキュアストレージに保存されるようになりました。 次のエントリが詳しいです。 blog.kyanny.me 「じゃあ、もう全部セキュアストレージに保存されたクレデンシャルを使えばOK」となるのですが、なかなかそうはいきません。 なぜかというとGitHubのクレデンシャルを使うツールによって環境変数の扱いが異なるからです。 GitHubのクレデンシャル設定の歴史（私の記憶版） 注意: 以下は、あくまで私の記憶であって実際と異なるかもしれません。 前史 GitHub CLI（ gh ）やGitHub Actionsの登場以前は、クレ
GitHub Actions - Sharing actions and reusable workflows from private repositories is now GA
GitHub Actions – Sharing actions and reusable workflows from private repositories is now GA actionsapienterpriseprivaterepositories December 14, 2022 The actions and reusable workflows from private repositories can now be shared with other private repositories within the same organization, user account, or enterprise. See managing the repository settings and managing the enterprise repository sett
GitHub Apps + GitHub Actionsで必要なアクセス権限のみ付与した一時的なアクセストークンを発行する | DevelopersIO
GitHub Apps + GitHub Actionsで必要なアクセス権限のみ付与した一時的なアクセストークンを発行する こんにちは、CX事業本部 IoT事業部の若槻です。 今回は、GitHub Apps + GitHub Actionsで必要なアクセス権限のみ付与した一時的なアクセストークンを発行してみました。 なぜGitHub Appsを使うのか GitHubではPersonal access tokensを使えばアクセストークンを簡単に発行することが出来ますが、スコープの粒度が粗く、操作可能なRepositoryの制限も出来ないため、必要以上のアクセス権限を付与してしまいがちです。 一方で、GitHub Appsを使用すれば、アクセス権限を細かく設定したアクセストークンを発行することが可能です。 About GitHub Apps - About apps - GitHub Doc
markuplintを開発し始めて5年経った
現在の数字 最新バージョン: v2.10.1 コミット数: 2,122 IssueとPull Request: 530件（クローズ含む） npmダウンロード: 11,179（週間） テストコード数: 916 テストカバレッジ: 74% GitHubスター: 315ユーザー スポンサー: 1ユーザー ふりかえり ライトニングトークでのお披露目 最初のコミットから約4ヶ月後、VS Code拡張も用意できて業務でもドッグフーディングしてある程度機能するようなったので、開発の動機と楽しんで開発できている旨をライトニングトークした。SNSを中心にそこそこ広まってくれたのもあって、GitHubのスターが増えたり、「使ってみよう」という声をぼちぼちと聞くようになった。最初のアピールとしては良い滑り出しだったとは思う。 当然ながらスライドは日本語だしSNSの広がりも国内にとどまったので、GitHubのスタ
令和時代のページネーションを考える (REST API編) - Sweet Escape
今回はバックエンドAPIでページネーションをどうやるかについての話なので、よくある無限スクロールUIのようなフロントエンド側の実装に関する話はしない。あくまでもAPI、もっと言えばRESTfulなAPIのリクエスト・レスポンスにおけるページネーションの話。 本気で深く考えるというよりざっくり検討したときの話です。 はじめに REST APIを実装するにあたってリスト系のAPIを提供する場合に必須といっても過言ではないのがページネーション。大量のリソースをレスポンスする場合にそれらを一気に返してしまうことは応答速度、転送量、クライアントサイドでの扱いづらさなどなどに繋がるので必須と言える。 最近、新たなAPIを開発するにあたってページネーションをする必要があったこともあり、今回はこのページネーションをどうやって提供するか整理して改めて検討してみた。 前提 TypeScript Nest.js
GitHub API を使ったリポジトリの監査を始めました - Techtouch Developers Blog
ヒアリングから見えた課題 定義したブランチ保護ルール GitHub API を利用した監査スクリプトの作成 終わりに こんにちは。SRE チームの izzii です。 つい先日、テックタッチでは GitHub リポジトリの利用ポリシーを定めました。創業から数年間、アクセル全開で開発して気がついたら、Owner 権限を持つ人間が増えてしまっていたことへの違和感を解消するためです。 ヒアリングを通して問題を分析し、リポジトリ利用ポリシーを定め、最終的には GitHub API を使って監査結果を Slack に通知する仕組みを作りました。 本記事はあくまで「リポジトリの利用ポリシー」の話に閉じます。GitHub の利用全般に及ぶ話に興味がある方は、Flatt Security さんが最近公開されたスライドが良さげなのでオススメしておきます。 https://blog.flatt.tech/en
Node.js v18 の主な変更点 - 別にしんどくないブログ
Node.js v18がリリースされました 🎉 nodejs.org この記事では Node.js v18 の主な変更点を抜粋して紹介します！ fetch() がフラグ無しで実行可能に (experimental) HTTP requestTiemout()のデフォルト値の変更 node:test モジュール（テストランナー）の追加 (experimental) V8 アップデートによる新しい JavaScript の API の追加 Array#findLast(), Array#findLastIndex() Intl.supportedValuesOf() その他の改善 Web Streams API のグローバルへの追加、実行時の警告の削除 (experimental) まとめ fetch() がフラグ無しで実行可能に (experimental) github.com Node
Reactベストプラクティスの宝庫！「bulletproof-react」が勉強になりすぎる件
Reactアプリケーションのアーキテクチャの一例として公開されているGitHubリポジトリ「bulletproof-react」が大変勉強になるので、私自身の見解を交えつつシェアします。 ※2022年11月追記 記事リリースから1年ほど経過して、新しく出てきた情報や考え方を盛り込んだ続編記事を書いていただいているので、こちらも併せて読んでいただければと想います（@t_keshiさんありがとうございます！）。 ディレクトリ構造が勉強になる まずはプロジェクトごとにバラつきがちなディレクトリ構造について。 ソースコードはsrc以下に入れる bulletproof-reactでは、Reactに関するソースコードはsrcディレクトリ以下に格納されています。逆に言えば、ルートディレクトリにcomponentsやutilsといったディレクトリはありません。 たとえばCreate Next Appで作成
GitHub GraphQL のノードIDフォーマットが変わるらしい
弊社では Terraform GitHub Provider を使って GitHub のレポジトリ管理・権限管理などを行っているのですが、 プロバイダーが repository_id を認識してくれない問題に遭遇しました。 原因を探ってみると GitHub GraphQL API に かなり大きな変更が入ること を知ったので、メモとして残しておきます。 グローバルノードID GraphQL API から扱えるすべてのオブジェクト (レポジトリ、ユーザー、etc) にはIDが振ってあります。 Using global node IDs 例えば僕 (@shogo82148) のノードIDは MDQ6VXNlcjExNTczNDQ= です。 $ curl https://api.github.com/users/shogo82148 | jq .node_id "MDQ6VXNlcjExNTcz
GitHub上にあるリポジトリに対してAPIを通じてgit grepライクに走査できるツール gh-grep (gh grep) を作った - Copy/Cut/Paste/Hatena
git grep 便利ですよね。 私は git grep と git gsub は本当によく使います。 ところで git grep はローカルリポジトリがないと実行できません。 ローカルにリポジトリがなければ git clone して、 git grep すればいいのですが、もう少し簡単にgrepするために gh-grep を作りました。 github.com gh-grep gh-grepはGitHub APIを使ってGitHub上のリポジトリに対してgrepをするツールです。 特徴は、全てGitHub APIを通じて実行するためローカルに git clone することなくgrepできることです。 また、APIを使っている特徴を活用して複数リポジトリに対してgrepすることなども可能になっています。 あと実行が遅いです。ひたすらGitHub APIを叩いているので...*1。 インストー
proto定義や成果物の管理用レポジトリを構築した話 - Kyash Product Blog
こんにちは、Fundsチームの @convto です。Kyashでは銀行入金やコンビニ入金などの残高の入出金に関わる部分の開発をしています。 Fundsチームではその業務の性質上多数の外部ベンダとやり取りをしています。 それぞれベンダごとに仕様なども異なるため、その接続部分のいくつかはマイクロサービスとして切り出されています。 Fundsチームの管理しているサービス間の通信でgRPCを導入する際、今後の社内の別サービスなどにも汎用的に使えるようなproto管理レポジトリを構築したのでその紹介をしたいと思います。 proto管理レポジトリで満たしたい要件について はじめに、他社の事例も参考にしつつ、自分たちがprotoを管理するにあたってどのような要件を満たせれば良いのか整理しました。 他社の事例を調査したところ、以下のような構成が多かったように思います。 名称は app-proto や p
GitHub - contiamo/restful-react: A consistent, declarative way of interacting with RESTful backends, featuring code-generation from Swagger and OpenAPI specs 🔥
⚠️ restful-react has been deprecated: We are focusing on a new open api generator that generates react-query components: https://github.com/fabien0102/openapi-codegen ⚠️ Building React apps that interact with a RESTful API presents a set of questions, challenges and potential gotchas. This project aims to remove such pitfalls, and provide a pleasant developer experience when crafting such applicat
COCOAのオープンプロセス化の現状と、今後について｜Hal Seki
以前、note にて、「オープンプロセスによって、COCOAの信頼を再構築する」という記事を書かせていただきました。本来、その内容の趣旨からしても、もっと早く取り組みの推移等をお伝えすべきではありましたが、まずは事態の把握や今後の見通しの策定のほか、様々な事情から流動的な状況が続き、なかなかそれも容易には叶わず、結果として皆様への情報や状況の共有等ができておりませんでした。誠に申し訳ありません。 本記事では、進捗状況や今後の見通しなどについてご報告させていただきます。 これまでの経緯2月18日：厚生労働省、内閣官房IT総合戦略室（IT室）との連携チームが発足される 平井大臣の指示で、私がチームの一員としてCOCOAに関する事態の収拾のためにIT室のCIO補佐官として正式に関わることになりました。それを受けて、今後の進め方について書いたのが前述の私の note 記事です。 2月26日：Git
SlackとGitHub Deployments APIで疎結合なChatOpsを実現する - Sexually Knowing
下記で紹介している /github deploy というコマンドは2021年4月9日の更新で現行のSlack連携からは削除された。 Removed deploy command and notification support: Today, the functionality provided by deploy command is very limited and doesn't address all the scenarios. We are removing deploy command and notifications support as part of this version. We want to relook at the scenarios and build a more holistic experience that customers need. int
SWRとReact Queryどっち使おうか検討したメモ
const { isLoading, error, data } = useQuery('repoData', () => fetch('https://api.github.com/repos/tannerlinsley/react-query').then(res => res.json() ) ) 一見、ほとんど一緒じゃん、となるが、SWRは「キーをfetcheの実行するためのパラメータ」になっている。 一方、react-queryは「キーと実行APIは独立している」。これはイメージとしてReduxのActionなどのconstantのような印象を受ける APIの違い Core API RQ : https://react-query.tanstack.com/docs/api SWR https://swr.vercel.app/docs/options#parameters これ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - rolldown/rolldown: Fast Rust bundler for JavaScript with Rollup-compatible API.
GitHub - shroominic/codeinterpreter-api: 👾 Open source implementation of the ChatGPT Code Interpreter
GitHub - based-ghost/react-functional-select: Micro-sized & micro-optimized select component for React.js
GitHub - mikewest/purification
