1クリックで始めるGitHubリリース as a ブログ
GitHubリリースという、GitHubでタグに対してリリースノートを書ける機能があります。 このリリースノート機能は、パーマネントリンクもあるし、Markdownも書けるし、画像もアップロードできるし、絵文字でリアクションもできるし、RSSもあるし、通知機能もあるし、GitHub Discussion連携すればコメントも書けるし、全文検索もついてくるしこれブログとして使えるんじゃないかと思いました。 そういう発想から、GitHubリリースノートをブログとして運用するためのちょっとしたブログシステムを作って使っています。 次のリポジトリが実際に動いてるものです。 azu/book-review: 本を読んだ感想を書くブログです。 リリースの一覧を見ると本の感想の記事が並んでいます。 Releases · azu/book-review Release 伴走型支援: 新しい支援と社会のカタチ
地元のGitHubユーザーを探せるサービスを作った & 各地域を比較してみた - Qiita
これは何？ 地元のGitHubユーザーを探せるサービス『地元のGitHubユーザー』を作った。このサービスを使うとなんと、地元のGitHubユーザーを探すことができます。 これ。 こんな感じで各都道府県のGitHubユーザーを一覧表示できます。累計スター数、Githubのフォロワー数、Twitterのフォロワー数などなども確認できます。 上の画像は鹿児島のGitHubユーザーの一覧。画像では自分のアカウント以外はモザイクかけています。 仕組みとしては極々単純で、プロフィールのLocationに都道府県名を設定している人をGitHubの検索APIで取得しています。例えば「Kagoshima, Japan」のように設定していれば、この一覧に載ります。ちなみに一部地域1を除き漢字表記にも対応しています。 デフォルトのソートでは概ねフォロワー数順になってます。 技術的には、フロントをReactで構
Takafumi ONAKA on Twitter: "書類選考時に GitHub アカウントを貰ったら初手で https://t.co/yMLD9XHecn を見ています。次に継続的に手を入れているリポジトリや dotfiles、あとリポジトリ一覧を眺めて興味を引いたヤツ。"
書類選考時に GitHub アカウントを貰ったら初手で https://t.co/yMLD9XHecn を見ています。次に継続的に手を入れているリポジトリや dotfiles、あとリポジトリ一覧を眺めて興味を引いたヤツ。
GitHub、チームでの利用も無料に。プライベートリポジトリ数も制限なく、チームディスカッション、ActionsによるCI/CDも可能
GitHub、チームでの利用も無料に。プライベートリポジトリ数も制限なく、チームディスカッション、ActionsによるCI/CDも可能 GitHubは無料で利用できる「Free」プランを見直し、個人に加えてチームでも無料で利用できる新たなFreeプランを発表しました。 Today we’re announcing free private repositories with unlimited collaborators for teams with GitHub Free, and reducing the price of our paid Team plan to $4 per user/month. All of the core GitHub features are now free for everyone. Learn more: https://t.co/fQ3r2ABt
GitHub now gives free users unlimited private repositories
Celebrate King's Day with TNW 🎟 Use code GEZELLIG40 on your Business, Investor and Startup passes today! This offer ends on April 29 → GitHub is by far the most popular way to build and share software. That said, one weakness of the platform is that it limits who can create private repositories – that is, software projects that aren’t visible to the broader public, and are shared only with a hand
GitHubが障害を総括、43秒間のネットワーク断が1日のサービス障害につながった：データベースの不整合解消に時間 - ＠IT
GitHubが障害を総括、43秒間のネットワーク断が1日のサービス障害につながった：データベースの不整合解消に時間 GitHubは2018年10月30日（米国時間）、2018年10月21日16時頃（米国太平洋時）から約24時間にわたって発生した障害に関する分析報告を、同社のブログに掲載した。これによると、ネットワーク機器の部品交換で生じた43秒のネットワーク接続断が、GitHubのメタデータ管理データベースの不整合を引き起こし、復旧に時間を要したという。 GitHubは2018年10月30日（米国時間）、2018年10月21日16時頃（米国太平洋時）から約24時間にわたって発生した障害に関する分析報告を、同社のブログに掲載した。これによると、ネットワーク機器の部品交換で生じた43秒のネットワーク接続断が、GitHubのメタデータを管理するデータベースの不整合を引き起こし、復旧に時間を要した
Microsoft、GitHubを買収完了 現地時間4日に正式発表へ
▼ iPhone 15/15 Proの予約は公式オンラインショップから！ Apple ドコモ au ソフトバンク 楽天モバイル ここ数日、Microsoftが「GitHub」を買収するのではないかとの憶測が広まっていたが、どうやらこの買収劇はすでに最終局面を迎えていたようだ。 Bloombergによると、GitHubはMicrosoftの買収に合意。この買収に関する発表を、現地時間4日にも正式発表する運びとなっているという。 MicrosoftがGitHubを買収、まもなく正式発表へ GitHubは、ソフトウェア開発プロジェクトのソースコードを複数ユーザーで管理するのに便利な機能が多数備わったGitホスティングサービス。世界で2,400万人が使用しており、JavaScriptやPythonといった多数の言語のソースコードリポジトリーがホストされている。 このGitHubを積極的に利用してい
GitHub に AWS キーペアを上げると抜かれるってほんと？？？試してみよー！ - Qiita
🤔 前書き 稀によくある 、AWS を不正利用されちゃう話、 AWSで不正利用され80000ドルの請求が来た話 - Qiita 初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。 - Qiita AWSが不正利用され300万円の請求が届いてから免除までの一部始終 - Qiita ブコメ等で GitHub にはアクセスキーを検索するBOTが常に動いていて、公開するとすぐに抜かれて不正利用される 的なコメントがつくのを何度か目にしたのですが、 本当にそんな BOT が動いているの？ どのくらいの時間でキーを抜かれて、不正利用が始まるの？ というのが気になったので、検証してみました。 GitHub にそれっぽいパブリックリポジトリを作成、権限が一つもついてない AWS のアクセスキー＆シークレットアクセスキーをうっかり公開、外部から利用されるまでの時間を計測します。
クラウドサービスを活用して README にバッジをペタペタ貼る - Qiita
最近の GitHub に上げてある OSS リポジトリには、README にいろんなバッジが貼られています。リポジトリに連携しているクラウドサービスのステータスを表すものがほとんどです。 自分は README にバッジを貼りたい派です。たとえば dtan4/terraforming だとこういう感じです。 最近はバッジの種類も増えているので、整理のためにもどういうのがあるかまとめてみようと思います。 自分がよく README に貼っているバッジ 自分が書く RubyGems については、以下の6個のバッジを必ずつけるようにしています。 Travis CI 言わずと知れた CI サービス。現在の master が CI 通っている (passing) かコケている (failed) かがわかります。リポジトリのメンテナンス状況を把握するのによいです。 クリックすれば、そのリポジトリのテスト結
Electron + Travis で楽々ビルド・リリースする最強のデスクトップアプリ開発 - Qiita
この記事は古いです。 ぼくが考えた最強のデスクトップアプリ開発環境 Web技術でデスクトップアプリ書いて push するだけの環境を作る。 主に利用するのは Electron + Travis + GitHub の3つ。 Electron でデスクトップアプリ書いて、push するだけでビルドしてリリースまで完結するデスクトップアプリ開発ができる。 もっと簡単に言うと 「ローカルで開発→push」 だけで GitHub Release に自動でリリースできる。 アプリのビルド自体もTravis内で行えるため、開発環境のOSに依存しない開発が可能。 以下は OS X 環境を前提として説明するが、クロスプラットフォームのためのビルドはTravis内で行うため OS は何でも良い。 念のため各種サービス・フレームワークの説明 簡単に説明すると以下。どれもすごく便利。 Electron: みんな大
GitHubに置いてるライブラリをCoverallsに対応した - k-holyのPHPとか諸々メモ
自分のライブラリを Travis CI でのユニットテストに対応しましたが、このたびカバレッジレポートを公開できるサービス Coveralls にも対応したメモです。 恥ずかしながらこれまでカバレッジレポートの意義が理解できてなかったんですが、 php-coveralls を使えば簡単に Travis CI から Coveralls にレポートを転送して可視化してくれるようなので、試しにやってみました。 Coveralls への登録 CoverallsへのサインインはGitHubアカウントがあればOK。 入るとGitHubのリポジトリ一覧が表示されるので、Coverallsへのサービスフックを有効にしたいリポジトリのトグルスイッチを「ON」に設定します。 GitHubへのAPIトークンの設定なども、自動でやってくれます。 以下、 Volcanus_Routing の例 PHPUnit設定フ
Travis CI上でPHPアプリのWebベースのテストを自動化する | Engine Yard Blog JP
PHPなどのさまざまな言語のオープンソースプロジェクトのCI環境として利用されているTravis CIでWebベースのテストを実行してみました。 通常は純粋なコードベースのユニットテストを実行する事が多いかと思いますが、CMSやEコマースエンジンなどオープンソースで配布し、インストールして使うようなソフトウェアではWebブラウザベースでの機能テストを自動化したいというニーズがあるでしょう。Travis CIにはfirefoxがインストールされておりブラウザベースのテストが出来る事は知っていたのですが、今回年末年始の宿題的にテストを実行する為の設定をひと通り行ってみました。 説明を抜きにして動作が見たい方はGitHubとTravis CIへどうぞ yandod/candycane https://github.com/yandod/candycane candycane on Trav
相手の GitHub の ID さえ知っていれば暗号化したメッセージを送れる naisho というのを作った - その手の平は尻もつかめるさ
色々な事情があり，秘密のメッセージを送り合う必要性が今年に入ってから多数発生していて， そのたびに毎度毎度手で暗号化して〜みたいな風にやるのめんどいですね，そうですね， ということでこの度 naisho というものをこさえました．みんなには内緒ですよ． これは何かと言うと，やりとりしたい相手の GitHub の ID を指定するだけで その ID のユーザの ssh-rsa の公開鍵を引っ張ってきて その ID のユーザのメールアドレスを引っ張ってきて そのメールアドレスに対して公開鍵で暗号化したメッセージを添付ファイルにしてメールで送りつける という動きをするコマンドです． golang で書きたかったというのと golang で書くと便利なのではと思ったので golang で書いてあります． Wercker で Go のプロジェクトをクロスコンパイルし、GitHub にリリースする -
GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー
少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ
GitHub を用いた開発フロー テンプレート - ペパボテックブログ
Development (開発の進め方) GitHub Flow の利用 レビューの実施 Testing (テスト) Deployment (リリースの仕方) Releases (リリース後の記録) References(参考文献) Appendix(付録) Release's notes の作成方法 History(更新履歴) 2014/03/15 Development (開発の進め方) GitHub Flow の利用 masterブランチは常にデプロイ可能な状態としなければならない テストが失敗する状態の場合、直ちに修正するべきである テストが失敗する状態の場合、デプロイすることは許されない 「新しい何か」に取り組む際は、 pull request を用いるべきである ブランチは master から作成し、ブランチ名は説明的な名前とすべきである（例: new-oauth2-scope
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
私のソースコードが北極送りに？ “GitHub”アカウントに謎のラベルが付与されたとの報告が多数／めっちゃ長持ちするフィルムに人類の宝を記録し、世界一安全（？）なところに1,000年保存【やじうまの杜】
「マジで胸アツ」台湾の天才IT大臣、東京都の新型コロナ対策サイトの修正に自ら参加し話題に
GithubのREADMEにのせる画像の置き場所 - 素材の味
https://github.com/hail2u/github-cheat-sheet/blob/master/README.ja.md
GitBook – Knowledge management for technical teams
