なぜ我々は GitHub Copilot Enterprise の導入を見送ったのか - 一休.com Developers Blog
CTO 室の恩田です。 今回は GitHub Copilot Enterprise を評価してみて、現時点ではまだ採用しないことを決めた、というお話をご紹介したいと思います。 きっかけ とあるエンジニアが Slack で自身の times チャネルに時雨堂さんの GitHub Copilot Enterprise のススメという記事を投稿したことが発端でした。特に感想はなく URL に 👀 だけが添えられていたので、後で見るぐらいのメモだったんだと思います。 それを見かけた別のエンジニアが技術雑談チャネルにその投稿を共有して、これは凄そうと話題を向けたところ、CTO の「評価してみる？」の一言で、有志が集って評価プロジェクトが始まりました。 雑談チャネルできっかけとなる投稿が共有されてから、30分足らずの出来事でした（笑）。 この話題が出たのは金曜日でしたが、週明け早々に稟議を終え、火曜
［速報］GitHub、組織のコードやドキュメントを学習しカスタマイズやファインチューニングが可能な「Copilot Enterprise」発表。GitHub Universe 2023
［速報］GitHub、組織のコードやドキュメントを学習しカスタマイズやファインチューニングが可能な「Copilot Enterprise」発表。GitHub Universe 2023 GitHubの年次イベント「GitHub Universe 2023」が米サンフランシスコで開幕しました。 1日目の基調講演で、Copilotが組織のコードやドキュメントを学習することで、カスタマイズやファインチューニングが可能になる「GitHub Enterprise」が発表されました。 Copilot Enterpriseは、外部に公開されていない組織内のコードやドキュメント、プルリクエストなどを追加でCopilotに学習させることで、組織内のコードベースに基づいたCopilotによるコードの生成や、Copilot Chatでの質問に対する回答が可能になるというものです。 さらに言語モデルそのものを組織
［速報］「GitHub Copilot X」発表、GPT-4ベースで大幅強化。AIにバグの調査依頼と修正案を指示、ドキュメントを学習し回答も
［速報］「GitHub Copilot X」発表、GPT-4ベースで大幅強化。AIにバグの調査依頼と修正案を指示、ドキュメントを学習し回答も GitHubは、GTP-4をベースに「GitHub Copilot」の機能を大幅に強化した「GitHub Copilot X」を発表しました。 GitHub Copilot is already helping developers code faster in their IDEs. But what’s next? Our answer is GitHub Copilot X. It’s our vision for the future of AI-powered software development. Check it out https://t.co/3Xrn7dAPgi — GitHub (@github) March 22, 202
ドキュメント駆動開発v2
前提 ここで言っているドキュメントは仕様書ではなく、顧客向け製品ドキュメント。 ミドルウェア製品を開発 小さなチーム パッケージ製品とパッケージ製品のクラウド版 そのため顧客に提供するドキュメントが必ず必要 GitHub を利用 自分で開発する場合のフロー 作りたい機能をぼんやりでいいので GitHub Issue に追加する feature ブランチを切る デザインドキュメントをリポジトリの doc/ 以下に書く デザインドキュメントに合わせてコーディングを進めてなんとなく動くところまで作る 動かなくてもいいのでイメージを膨らませるためにコードを書いてみる デザインドキュメントは書き捨て前提で、とにかくメモを書く 製品ドキュメントを書き始めて、一旦書き終える ブランチマージに向けてコーディングを進める 書ける範囲でテストを書く ドキュメントを平行して修正する プルリクエストをだしてレビュ
オープンソースドキュメント翻訳プラットフォームとしての GitHub (React 日本語ドキュメントの例)
はじめに ひょんなことから React 公式ドキュメント日本語版のメンテナをやらせていただいています smikitky です。 この記事は、React 公式ドキュメントの翻訳作業が GitHub ベースでどのように行われているのかを解説したものです。ドキュメントの翻訳には色々な方法がありますが、React の現アプローチは非常に上手く行っていると個人的に考えています。部分的には似たアプローチを説明している既存記事も探せばありますが、少し詳しめに書くことで事前の不安を取り除き、「思ったより簡単そうだから、自分もあのライブラリのドキュメント翻訳をやってオープンソースに貢献してみよう」と思えるようになることを目標にしています。 想定読者は Git、GitHub、Markdown（ないし類似の軽量マークアップ言語）、および基本的な HTML の仕組みがわかる開発者です。何らかの静的サイトジェネレー
GitLab的ドキュメント文化を組織にインストールする（実践編:スタートアップMNTSQの事例）｜Anno Takahiro
会社組織にドキュメント文化をインストールすることの有用性や、GitLabのような企業がどのようにドキュメントを運用しているかを、前回記事で書いた（スケールする組織を支えるドキュメンテーションの技術を”GitLab Handbook”から学ぶ）。今回は、私のいるスタートアップのMNTSQ（モンテスキュー、と読みます）でどのようにそれを実践しているか、実際のところどのような成果が出ているのかについて書いてみたい。 MNTSQでは、当初からドキュメンテーションの重要性を経営メンバー全員で認識しており、社内ドキュメントをGitHub管理でメンテナンスしながら作り上げていくようにしていた。この大枠の仕組みの設計部分は弊社のデザイナーの生谷(@ikutani41)が初期に考案/メンテしたものである。デザイナー視点からこのような仕組みが設計され稼働されることは珍しいと思う。この辺については本人からもどう
ドキュメントを書くときの「メンタルモデルの原則」 - クックパッド開発者ブログ
こんにちは。クリエイション開発部の丸山@h13i32maruです。 みなさんドキュメント書いてますか？私はドキュメントを書くのは結構好きです。最近もプライベートで開発しているJasperというGitHub用Issueリーダーのユーザ向けドキュメント（マニュアル）を書きました。でも良いドキュメントを書くのって難しいですよね。 そこで、本記事では「ツールやライブラリなどを対象にしたユーザ向けドキュメント」を書くときに私が考える原則を紹介します。ちなみに私はテクニカルライティングの専門家ではなく、普通のソフトウェアエンジニアです。そのあたりはいい感じに汲み取っていただけると🙏 🕵️メンタルモデルの原則 良いドキュメントとはどのようなものなのでしょうか？私は「そのツールやライブラリに対して読者がメンタルモデルを構築できる」のが良いドキュメントだと考えています。これを「メンタルモデルの原則」と呼
ビジネス資料のGitHub化ーーNotion2.0が目指す「テンプレ図書館」の衝撃 - BRIDGE（ブリッジ）テクノロジー＆スタートアップ情報
Almanacウェブサイト プログラミングをせずとも、ウェブもしくはモバイルアプリを直感的に構築できるノーコードサービス分野が成長してきました。「Bubble」や「AppGyver」のようなアプリ開発、日本の「STUDIO」や「Strikingly」に代表されるLP開発など、領域は様々です。ノーコードの本質は、時間やコストを圧倒的に削減することにあります。そして今、ノーコードトレンドの考えが新たな体験として企業で広く使われるドキュメント作成分野にも広がりつつあります。 「Almanac」は、ビジネスドキュメントテンプレートのクラウドライブラリを提供。マーケティング、人事、法務テンプレートなど、専門家によって公開された、磨き上げられた1万件の文書を提供しています。各資料をコピペすれば、ユーザーは手軽にプロのドキュメント内容をトレースできます。UIはノートツール「Notion」にとても似ていま
新 GitHub Actions 入門 - 生産性向上ブログ
github.blog GitHub Actions の新バージョンが 8/8 に発表されました。 www.kaizenprogrammer.com 自分は過去にも旧バージョン時に GitHub Actions の入門記事を書いていたのですが、新バージョンがこれまでと大きく変わってしまっているので、この記事ではあらためて GitHub Actions についていろいろ調べたり動かしてみたりした内容をまとめます。 目次 注意事項 GitHub Actions とは これまでの GitHub Actions とどこが変わったか コンセプト マルチプラットフォーム対応 HCL から YAML へ 料金 その他 GitHub Actions と Azure Pipelines 簡単な例 (Hello, World) ワークフローの設定 ワークフローとは ワークフローを実行するイベント ワークフロー
マチマチとOSSの関わりをGitHubで振り返る
ご近所SNS「マチマチ」を作っている武者(@knu)です。今回はマチマチとOSSとの関わりについて紹介したいと思います。 マチマチのエンジニア達はもっぱらRuby/RailsやReactのコードを書いていますが、そうしたフレームワークや周辺ライブラリ、そして言語実装はすべてOSSとなっていますし、データベースエンジン（PostgreSQL/PostGIS）、RedisやMemcached、それらを稼働するOS、ビルドやテストに使うツール、エディタ、等々に至るまでの多くがOSS、またはOSSをベースとしたものとなっています。今や、OSSなくしてはこの世界で何もなし得ないと言っても過言ではありません。 私自身も長らくOSS開発に携わっており、前世紀からFreeBSDやRubyのコミッターを務め、自作のOSSもたくさん書き、周辺のエコシステムにパッチをフィードバックしたりしてきました。そんな中で
React 公式ドキュメントの日本語翻訳を経験して感じた公式ドキュメント翻訳の魅力 - Qiita
はじめに 先日、React 公式ドキュメントの日本語化プロジェクトに参加し、僕が担当した ReactDOM というパートの翻訳をマージいただきました。細かくレビューいただき、ありがとうございました！ Translate react-dom by gotchane · Pull Request #45 · reactjs/ja.reactjs.org · GitHub 貴重な経験ができたのでその内容を共有したいと思い、今回のプロジェクトや公式ドキュメント翻訳の魅力についてまとめようと思います。 本記事のアウトライン 本記事では、まず React 公式ドキュメントの日本語化について僕が知ったきっかけから、実際に翻訳達成するまでの経緯をざっくりなぞります。 その後、今回の経験を通して感じた公式ドキュメント翻訳の魅力についてまとめます。 tl;dr 公式ドキュメント翻訳の魅力は以下 2 点あるかな
Microsoftのドキュメントの誤訳を報告したら炎上した件について(当事者目線での話) - 水まんじゅう2
この件について改善がなされるとの発表がMicrosoft DOCS International Teamからありました。 少なくとも、誤訳の報告についてはやりやすくなるそうです。 ご担当者様及びに尽力してくださった方々には感謝いたします。 https://github.com/dotnet/docs.ja-jp/issues/118#issuecomment-408283458 今回の私の記事に憤ってる人たちは改善されたことを確認するためにドキュメントフィードバックを送りまくってそれをブログにでもまとめればいいと思うんですよ。— 軒先のネコ (@megascus) 2018年7月28日 -----------------------------------追記ここまで---------------------------------------------- ということで、おとといぐらいか
GitHubでポータルサイトドキュメントを運営して幸せになる話
WebRTC is secure,� or not secure? - WebRTC セキュリティ概説 -
【今日からできる】コミットメッセージに 「プレフィックス」 をつけるだけで、開発効率が上がった話 - Qiita
はじめに 今まで commit message を「なんとなく」書いていたが、プレフィックスをつけることで、コミットメッセージに対する考え方が変わった。 そのおかげで開発効率が上がったので、その内容をシェア。 プレフィックスをつけるってどういうこと？ 以下のようにコミットメッセージの先頭に、なんらかの文字をつけること。 feat: xxx という機能を追加 fix: yyy で発生するバグを修正 refactor: zzz の機能をリファクタ のように feat, fix, refactor などがプレフィックスです。 最近 OSS の Contribution Guide などでよく見かけます。 導入したプレフィックスルール Angular.js/DEVELOPERS.md Angular.js の開発者ガイドに書いてあるメッセージを参考にしました。 以前のコミットメッセージ（例 ちなみ
GitHub で公開されているドキュメントを継続的に翻訳する - Qiita
オープンソースに関わっている関係で、これまでいろいろな GitHub 上のドキュメントを翻訳してきました。 たとえば、WP-CLIのドキュメンテーション とか、WP-APIのドキュメンテーション とか、ベクトルタイルの仕様書などなどです。 多くの場合、オリジナルのドキュメントがそれほど頻繁にアップデートされることがないため、一度翻訳を行えばそれっきりなことが多いのですが、WP-CLIのドキュメントのように頻繁に更新され、それを追いかける必要があるケースがあります。 ところがこれ結構大変で、オリジナルで軽微な修正がはいっても、その修正箇所を探すために全文を確認する必要がでてきてしまいます。 そんなわけで、WP-CLIでは、メンテナーに頼んで変更の度にタグをつけてもらい、追従するときにはタグ間の差分を確認することで、更新箇所を確認するというワークフローをとっています。 例: WP-CLI v1
esaの話をしよう - てくすた
10年の複雑 開発部の総務みたいな存在のさとうといいます。 得意技は床下のケーブリングです。 PIXTAは来年、最初のサイトリリースから10周年を迎えます。サービスが始まって9年、10年と経つと相当のナレッジが溜まるのですが、そうなると管理が大変なことになります。業務知識・サービスの概要・構成管理・手順書・設計・議事録など、ドキュメントをどこかにわかりやすい形でおいておきたいものですが、これまではどのように管理していくのか方針やルールが定まっていませんでした。 そんな状況だったので、ピクスタでは「esa」というサービスに集約することにしました。 esaについては検索するだけでもたくさんのレビューエントリが見つかるのですが、今回はそのドキュメントを管理するためのサービスesaをピクスタでどのように使っているかご紹介したいと思います。中の人は先日東京ビッグサイトで開催されたYAPC::Asia
Markdownドキュメントをgithubで管理して、はてなブログでホストする ~ Mackerelの場合 - Hatena Developer Blog
はてなチーフエンジニアの Songmu です。この記事ははてなデベロッパーアドベントカレンダー2015の7日目の記事です。昨日は id:mazco による デザインにおける個性のつけ方 でした。 今日は Mackerel の公開ドキュメントについてのお話です。 Mackerelは以下で公式ドキュメントを英語と日本語で提供しています。 help.mackerel.io help-ja.mackerel.io これらは実ははてなブログでホストしています。 翻訳は日本語を先に書いて、それをチームのネイティブ翻訳者が翻訳するフローになっています。 ドキュメントの運営 告知ブログのようなものなら良いのですが、ドキュメントはその性質上定期的なメンテナンスが必要になります。特に以下の様な点がドキュメントを運営する際に難しいところです。 なんらかの一括修正が必要になった場合に修正点を洗い出して一括で反映す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
pip/.github/ISSUE_TEMPLATE/bug-report.yml at main · pypa/pip
Blogger