「それは、本当に安全なんですか？」 セキュリティ専門家が「GitHub Copilot」の全社一斉導入時に考えたあれこれ
「GitHub Copilot 導入時に考えたセキュリティのあれこれ」というタイトルで登壇したのは、freee株式会社のただただし氏。タイミー社主催の「GitHub Copilotで拓く開発生産性」で、「GitHub Copilot 」を全社一斉導入する際に考えるべきセキュリティリスクについて発表しました。 freee株式会社 PSIRT マネージャーのただただし氏 ただただし氏：freee株式会社のただただしと申します。 今日は、「GitHub Copilot 導入時に考えたセキュリティのあれこれ」ということで、Copilotのセキュリティリスクについて語るわけですが、考えてみたら、GitHubの中の人を前にこんなことをしゃべるのは相当大胆な話だと思います。最後にいいことで締めるのでちょっと我慢してください。 自己紹介をいたします。ただただしと申します。PSIRTという組織でマネージャー
GitHub Actions 逆引きリファレンス
1.この記事の立ち位置#自分がいつも調べていること、忘れがちな Tips や小ネタを列挙していく。そのため、網羅性は重視しない。 というのも、なにか調べていていろいろ読み漁った挙げ句、1周回って行き着くところは GitHub Actions の公式ドキュメントであり、たとえば Workflow の書き方は以下のページをよく開いている。 Workflow syntax for GitHub Actions - GitHub Docs それでも、公式ドキュメントで参照したい箇所を引っ張るための用語を知るまでに苦労することが往々にあり、この記事が、公式ドキュメントで参照したい箇所を導くための助けとなればと思い、書いていく。 2.Step と Job と Workflowの違いアレコレ#2-1.Step と Job と Workflow の違いの一行まとめ#Step < Job < Workflo
Navigating code on GitHub - GitHub Docs
You do not need to configure anything in your repository to enable code navigation. We will automatically extract search-based and precise code navigation information for these supported languages in all repositories and you can switch between the two supported code navigation approaches if your programming language is supported by both. GitHub has developed two code navigation approaches based on
君は GitHub の Suggested change を知っているか？ - BASEプロダクトチームブログ
これは「BASE Advent Calendar 2018」の2日目の記事です。 devblog.thebase.in Native Application Group の右京です。 ネットショップ作成サービス「BASE」では日々機能追加や改善の為、無数の Pull Request が作成され、レビューされています。今日はそんな中で知っているととっても便利な機能を紹介します。 レビューをしていたら typo をみつけてしまった... ありませんか？前後に真面目なレビューがあるとなんとなく指摘するのを躊躇してしまいますね...。シレッと修正するにも編集するなりブランチを切るなりして...はコンフリクトの可能性などもあり、コストが高く面倒ですよね。 そんなときはこれ、「Suggested change」です。 Incorporating feedback in your pull reques
What is Atomic Design
atomic-design.md この記事ではAtomic Designについて、Atomic Designとは？といったところから実例まで書いていきます。 Atomic Designとは Atomic Designはデザインシステムを作る方法論となります。 デザインシステムというのはスタイルガイドやブランドのガイドラインなどを指すようです。 どこで使われている？ 日本だとAbemaTV（アベマTV）で使われています（Atomic Design を実案件に導入 - UI コンポーネントの粒度を明確化した結果と副産物 | ygoto3.comからの情報）。 今までのデザインとの違い Atomic Designはページ単位でデザインしないで、コンポーネント単位でデザインして組み合わせてページを作るという考え方になります。 Atomic Designはコンポーネントの単位を5つに分けています。
ファミコンのエミュレータを書いた - undefined
概要 ファミコンのエミュレータをJSでだらだらと作ってた。そこそこ遊べるようになったので公開しておく。技術的な内容は、またどこかで発表したり、Qiitaなどにまとめたい。（忘れないうちに。需要があるかは怪しいが。） 随分昔に作ってみたいなーと思いFPGAでの実装を開始したんだけど、早々に挫折した覚えがある。今思うとFPGAの場合タイミングの問題が付き纏うのでJSで書くより圧倒的に難易度も高いし、ハードエミュレータを実装するにしても前段階としてソフトウェミュレータを実装するのが定石っぽいので無謀だったっぽい。 ひとまずMapper0という基本的なカセット形式のみに対応し、スーパーマリオブラザーズがそこそこ遊べるくらいを目標とした。 成果物 github.com ファミコンのスペック MPU 6502(RP2A03), 8bit WRAM2KB VRAM 2KB 最大発色数 52色 画面解像度
GitHubをコーディング以外で活用する７つの方法 | readwrite.jp
「GitHub」はコーディング・プロジェクトのためのツールとしては良く知られているが、その他様々な用途に対しても非常に有効な手段であることは忘れてられてしまいがちだ。 GitHubの核心は２つのコラボレーション機能、「フォーク」と「ブランチ」である。これらはコーディング専用の機能という訳ではない。フォークとは、他の誰かが作業したデータの別バージョンを作成するために、クローンを生成することを意味する。ブランチは、グループで共同編集を行う際に各人用の一時的なクローンを作成し、更新結果を再びグループ・プロジェクトにプッシュバックする手法だ。 GitHubの機能の多くは複雑なバージョン管理言語である「Git」についての知識を要求されるが、フォークとブランチはどちらもGitHubアカウントといくつかのクリック操作で簡単に利用できる。またGitHubにはリベラルな利用規約という付加的なメリットがあり、
github-pr-releaseが最高に便利だった件について - Masteries
uiureoさんが開発されたnpmのパッケージ, github-pr-releaseが便利すぎて脳汁がドバドバ溢れでたので紹介します. リリース時のチェックリスト 何かしらのリリースをする際, 大抵の場合｢今回, どのような内容のリリースを行うのか?｣についてチェックリストを作るのではないでしょうか. そしてチェックリストを見ながら, ステージング環境などで動作確認を行い, リリースする内容が期待通り動作するかを確認したりするのではないでしょうか. 自分が開発に携わっているReactioの開発チームでは, これまでリリース時に手動でチェックリストを作っていたのですが, そもそも手動でチェックリストを作るということそのものが面倒ですし, 手動でチェックリストを作る場合, 本来リリースするのでチェックリストに入れるべき内容がチェックリストから漏れてしまう事があったりして, 非常に大変でした.
Pull Requestのレビューが辛くて会社をやめたい
私はプログラマに向いていないのかもしれない。 うちのチームではコミットをmasterブランチへマージする前に、Pull Requestを出してそれをリーダーや他の人がレビューすることになっている。（たぶんよくあるフロー？） そのPull Requestでもらうコメントを見ると死にたくなってくる。特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「（こんな実装は）有り得ない」といった言葉だ。 レビューにおいてそういった強い言葉がときとして必要なことは理解している（そういえばこなものもあったなと思い出した http://cpplover.blogspot.jp/2013/07/linuxml.html ）。またそういったコメントを残す相手との仲が険悪なわけでもない。またよいと思ってくれたらしいところは褒めてくれたりLGTMしてくれたりもする。 だけどそれでも辛い。きつい言葉を向けられる
クソコードでも公開した方がいいんじゃないかって話 - Konifar's WIP
昨日のDroidKaigiの@operandoOSさんのセッション Android学ぶを君へ。生き抜くためのナレッジ共有の中で『ひたすらクソコードを書く』という話がありました。 もちろんこの話はほんの一部でしかないんですが、とても印象に残りました。 誰と話したか忘れてしまったんですが、懇親会で 「クソコードでも公開した方がいいんじゃないか」みたいな話が出て、なるほどなぁと思ったのでちょっと思考を整理しておきます。 書けば何がクソコードかわかってくる 何も書かないよりクソコードでもいいからまず書いてみる方がいいと思います。 そもそもクソコードっていうのはよいコードの基準があってこその価値観なんですよね。書かなくても何がよくて何がクソかわかるよって人もいると思うんですけど、自分はやっぱり頭で理解するより書いて理解する方が腹落ちしやすいです。 例えば、GoFのデザインパターンはよくある問題を
Gitでやらかさないための事前予防策 - Qiita
Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある
Github を使って雑誌原稿を書く - naoyaのはてなダイアリー
今日はこのあと Github の Tokyo Drinkup January 2014 に行くのだが、先方から、もしかしたら 10分ほど Github について話してもらうかも、と打診された。話すか話さないかわからないが、もし話すとしたらと仮定し内容の整理も兼ねて以下「Github を使って雑誌原稿を書く」ということについて書いてみようと思う。 「Github を使って雑誌原稿を書く」もしくは「Github を使った雑誌編集者とのコラボレーション」について、である。 Web+DB PRESS の連載 ご存知の方もいるかもしれないが、このところ技術評論社の Web+DB PRESS で連載をしている。連載を始めて、もう一年近く経った。以前にも Perl に関する連載をしていて、そのときも数年ぐらい続けたので、間があきつつも、なんだかんだでそれぐらいの付き合いになる。 最近は特にテーマは決めず
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - ealush/vest: Vest ✅ Declarative validations framework
GitHub - gothinkster/realworld: "The mother of all demo apps" — Exemplary fullstack Medium.com clone powered by React, Angular, Node, Django, and many more
Awesome Repository - GitHubでスターを獲得している注目のリポジトリを見つけよう
スタートアップ/企業の調べ方
GitHub - ruby-grape/grape-entity: An API focused facade that sits on top of an object model.
GitHub - vasanthk/react-bits: ✨ React patterns, techniques, tips and tricks ✨
GitHub - flyerhzm/rails_best_practices: a code metric tool for rails projects
はてなブログチームの開発フローとGitHub
