サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
はじめまして。2019年1月に入社したSREスペシャリストのsonotsです。最近MLOpsチームのリーダーになりました。今回の記事はMLOpsの業務とは関係がないのですが、3月に弊社で実施した会社用GitHub個人アカウントの廃止について事例報告します。 TL;DR 会社用GitHubアカウントを作るべきか否か問題 会社用GitHubアカウントの利用で抱えた問題 1. OSS活動時にアカウントを切り替える必要があり面倒 2.GitHubの規約に準拠していない 会社用アカウントを廃止した場合にセキュリティをどのように担保するかGitHubのSAML single sign-on (SSO)機能について 会社用アカウントの廃止およびSSO有効化の実施 会社用GitHubアカウントを使い続ける場合 私用GitHubアカウントに切り替える場合 Botアカウントの場合 Outside Coll
🤔 前書き 稀によくある 、AWS を不正利用されちゃう話、AWSで不正利用され80000ドルの請求が来た話 - Qiita 初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。 - QiitaAWSが不正利用され300万円の請求が届いてから免除までの一部始終 - Qiita ブコメ等でGitHub にはアクセスキーを検索するBOTが常に動いていて、公開するとすぐに抜かれて不正利用される 的なコメントがつくのを何度か目にしたのですが、本当にそんな BOT が動いているの？ どのくらいの時間でキーを抜かれて、不正利用が始まるの？ というのが気になったので、検証してみました。GitHub にそれっぽいパブリックリポジトリを作成、権限が一つもついてないAWS のアクセスキー＆シークレットアクセスキーをうっかり公開、外部から利用されるまでの時間を計測します。
こんにちは。デザイナーの大橋です。 今日は、私が担当している “（しら）ずにお金が（たま）る”自動貯金アプリ『しらたま』 で導入してました、デザインのバージョン管理の話を紹介します。 デザインのバージョン管理といえば、AbstractやKactusがありますが、今回はあえてGit Sketch Pluginを試してみました。 デザインデータをGitHubで管理しようと思ったキッカケ 私以外のチームメンバーがみんなエンジニアだから、間違いなくGitHubに寄せたほうが効率いいんじゃないか。 新しいツールを導入すると、プロジェクトに関する情報が分散してしまいがちで、エンジニアも招待したり登録してもらったりしなきゃいけないのかなという印象。※あくまで印象です。 Kactusはプライベートレポジトリが有料。 こんな感じでなんかファイルが増えてく。。。(忙しいと放置しがちでよくない。。GitHub
Kasino online terpercaya di Indonesia
いくつかのオープンソースプロジェクトを公開している筆者からの、読みやすくユーザーにやさしいREADMEを書くためのアドバイス。 この記事は、Rowan Manning氏による「Writing a Friendly README」(2016/3/14)を翻訳したものです。 あなたのプロジェクトのREADMEは、かなり重要です。そこはプロジェクトに初めて来た人が大抵最初に見るであろう場所であり、唯一のドキュメントであることもよくあります。あなたのオープンソースプロジェクトにとってのREADMEは、企業にとってのウェブサイトのようなものです。ウェブサイトはユーザーエクスペリエンスの注目を集めるところですが、READMEがユーザー観点で考えられることはほとんどありません。 この記事では、分かりやすいREADMEを書くために役立ち、開発者(ユーザー)の要求に見合い、開発者がプロジェクトを初めて見たの
GitHub の草を絶やさないための姑息な裏技。 gitlog --amend --date というコマンドで、直前のコミットの日時を変更できる。 $ git add sample.txt $ git commit -m "サンプルのコミット。" $ gitlog --pretty=fuller commit a75cc…… Author: Neos21 <mail@example.com> AuthorDate: Wed Jul 13 00:07:05 2016 +0900 Commit: Neos21 <mail@example.com> CommitDate: Wed Jul 13 00:07:05 2016 +0900 上のように何らかのコミットを行ったあと、gitlog --pretty=fuller というコマンドを打つと、AuthorDate と CommitDate
本書は、さまざまな言語とGitHubAPIを使って、いろいろなツールを作るアイデアを紹介する書籍です。オープンソースのWikiであるGollumを使う画像整理ツール、PythonとSearchAPIを使ってレポジトリを検索するGUIツール、GistAPIを使ったRubyサーバーを作成します。またJavaScriptのチャットロボットHubotを使ってGitHubの通知を行う方法、JavaScriptとGit DataAPIを使ってGitHubにシングルページアプリケーションをホストする方法なども紹介します。多彩なGitHubAPIを使いながらツールを作ることで、ワークフロー構築のアイデアを得ることができる一冊です。 目次 監訳者まえがき まえがき 1章 GitHubAPI 1.1cURL 1.2 後続のAPIパスへの目印 1.3 JSON（JavaScript Object
こんにちは、投稿開発部の森川 (@morishin127) です。クックパッド、お料理アルバム、みんなのお弁当の iOS アプリの開発等に携わっています。クックパッドでの開発はGitHub Enterprise 上で行われており、書いたコードをプロダクトに取り込む前には基本的に第三者のコードレビューが必須です。コードレビューはプロダクトの品質向上に貢献していますが、往々にして結構な時間と労力がかかるものです。Pull-Request を出してレビューをしてもらい指摘の修正を繰り返していると、場合によってはマージに数日〜1週間ほどかかってしまうこともあります。自分の開発速度を速めるため、また周りのエンジニアの開発速度を下げないためにレビューしやすい Pull-Request を出すことは重要です。この記事ではレビューしやすい Pull-Request のために心がけていることを紹介したい
.gitignore ファイルを手動で書くのは面倒だし、漏れもありそうです。GitHub の人気プロジェクトの1つであるgithub/gitignore にはさまざまなプロジェクト・環境に合わせた.gitignore ファイルのテンプレートが置いてあり、ここを参考にファイルを作る人も多いでしょう。 gitignore.io はこのプロジェクトのテンプレートを Web から見やすくした感じのサービスです。開発環境に使うものを指定すると自動で .gitignore ファイルのテンプレートを生成してくれます。 これをブラウザから使うのもいいのですが、API が用意されているのでそこから使うこともできます。つまりターミナルから以下のようにコマンドを叩くとOSX とLinux で開発するRuby のプロジェクトにあわせた .gitignore テンプレートを生成してくれます。 $ cur
AI & MLLearn about artificial intelligence andmachine learning across theGitHub ecosystem and the wider industry. GenerativeAILearn how tobuild with generativeAI.GitHub CopilotChange how you work withGitHub Copilot. LLMsEverything developers need to know about LLMs.Machine learningMachine learning tips, tricks, and best practices. HowAI code generation worksExplore the capabilities and be
GitやGitHubの使い方を学習することができるデスクトップアプリ「Git-it」。Electronで作られていて、Mac /Windows /Linux用の実行ファイルをGitHubよりダウンロードすることができます。英語表記のみだけでなく、日本語に対応しているところもありがたいところです。 使用方法 Git-it自体は問題集のようなもので特別な仕掛けはありません。画面の指示に従いローカルの環境でGitを使いながら学習を進めていきます。Git-itではGitHub Desktopの使用を推奨していますが、実際の運用を考えてターミナルでGitを勉強してみるのも良いでしょう(Windowsの場合若干めんどくさいですが)。 Git-itでは、Gitのインストールから始まり、リポジトリの作成やコミット、GitHubの使い方、最終的にはプルリクエストの送信方法まで学ぶことができます。 プルリ
木戸です。入社して２ヶ月が経ちました。ブログの投稿本数も１１本（５．５／月）と比較的順調なペースで書いています。 社内のブログの執筆環境は人それぞれのようで、Wordpress で直接書いている人や、Mac でMarkdown エディタを使って書いている人など様々なようです。 試行錯誤して、なんとなく自分にあったブログ執筆環境が整ってきたのでブログで紹介してみたいと思います。 参考になれば幸いです。 ブログ執筆環境要件 私のブログ執筆環境要件を以下にまとめました。 執筆 フォーマットはMarkdown 形式で書きたい。 修正履歴を残したいMac とiPhone の両方で書けるようにしたい。 Elasticsearch の記事は自動的に電子書籍化（PDF ePub）してまとめて読めるようにしたい。 文章の校正ルールの検査を自動化したい。 公開WordPress へはそのままコピペし
今さらですがXcodeでGitを使ったバージョン管理の仕方をいろいろ調べたので調査結果をまとめたいと思います。調査した環境は以下になります。Mac OS X 10.8 Mountain Lion Xcode 5.0 XcodeでのGitの使い方の記事なので、Gitって何？もしくは バージョン管理って何？という方は以下の記事を見た後でご覧ください。 ガチで5分で分かる分散型バージョン管理システムGit 目次 ローカルリポジトリ 準備：ローカルリポジトリの作成 ローカルリポジトリにコミットする ソースコードの変更を破棄する ローカルリポジトリの変更履歴を確認する 以前のバージョンとの差分を確認する リモートリポジトリ 準備：リモートリポジトリの作成 リモートリポジトリを複製する(Clone) リモートリポジトリを更新する(Push) リモートリポジトリから変更を取り込む(Pull) リモート
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
