GitHub、パブリックリポジトリのユーザーに4vCPU/16GBメモリ/150GBストレージのホステッドランナーを無償提供、従来よりも2倍のスペックに強化 GitHubは、コードのビルドやテスト環境などで使えるホステッドランナーを、パブリックリポジトリで開発をしているオープンソースの開発者向けに無償で提供しています。 今回、その無償のホステッドランナーが2倍のスペックに強化されたことが発表されました。 GitHub Hosted Runners for public repositories are now DOUBLE the size! Run your CI/CD Actions workflows with a 20% performance boost today. https://t.co/S9Dy9tHVB3 — GitHub (@github) January 17, 2
1Passwordはパスワードマネージャーであるが、パスワード管理以外にもSSHエージェントとしても使用可能である。1PasswordのSSHエージェント機能の概要は、以下の公式ブログ記事で確認できる。 この記事では、1PasswordをSSHマネージャーとして使う方法については割愛する。t_o_d氏の「Github等で利用するSSH keyの作成及び管理を1Passwordで行う」にその方法が詳しく記載されているので、そちらを参照いただきたい。 コミットにUnverifiedマークが表示されてしまう .sshディレクトリに鍵を保管する代わりに1Passwordを使用するメリットとしては、t_o_d氏の記事にも書かれているようにセキュリティと管理の容易さにある。しかし、1PasswordのSSHエージェントを利用し始めてから、コミットに対して「Unverified」と表示される問題が発生し
GitHub でシークレットスキャニングのプッシュ保護機能が個人アカウントごとの設定で有効化可能になりました(Beta機能) こんにちは、CX事業本部 Delivery部の若槻です。 GitHub ではシークレットスキャニングの「プッシュ保護(push protection)」機能により、シークレットが含まれたコミットをブロックするさせることができます。 今回のアップデートにより、以前まではリポジトリ、組織またはエンタープライズレベルでのみ有効化できたプッシュ保護機能が、ユーザー自身が個人のアカウント設定で有効化できるようになりました。 ちなみに本アップデートは現在は Beta 機能ですが、2024年1月にすべての GitHub Free 個人アカウントに対してプッシュ保護をデフォルトで有効にする予定とのことです。 試してみた Permission を何も付与していない AWS IAM ユ
本記事について GitHub Copilotを2ヶ月使用し、その便利さを体感しました。 本記事では便利さを感じた活用事例を紹介します。 (本記事で示すコードは全て本記事のために作った適当なサンプルです。) ■ 書く 活用事例 使用感 ■ 書かない 導入方法 他ツールとの比較 Rails以外での使用感 Copilot for Businessについて 対象 Railsエンジニアの方 (※GitHub CopilotはRuby以外の言語でも活用できます) AIを用いた開発に興味のある方 使ったことないけど、自分で書いたほうが早いだろうと思っている方(過去の私) 環境 Mac (M1 Pro) Visual Studio Code Copilot for Individuals GitHub Copilotとは 一言でいうと「スーパー予測変換」です。 「こういうコード書きたいんですよね?」ってい
プログラマー育成を支援するInitial Commitが、ローカルリポジトリにおけるGitの動作をシミュレート可能なコマンドラインツール「git-sim」を2023年1月22日にリリースしました。git-simを使うことで、Gitコマンドがリポジトリに及ぼす影響を視覚化した画像やアニメーションを生成できます。 git-sim - Visually simulate Git operations in your own repos with a single terminal command. https://initialcommit.com/tools/git-sim GitHub - initialcommit-com/git-sim: Visually simulate Git operations in your own repos with a single terminal c
はじめに こんにちは、クラウド&ネットワークサービス部で SDPF のベアメタルサーバー・ハイパーバイザーの開発をしている山中です。 先日 GitHub Actions self-hosted runners のオートスケーリング構成の紹介(クラウドサービス開発を支える CI の裏側) の記事で、自作の runner controller と Docker を用いた、オンプレミスでの CI 環境構成についてご紹介しました。 今回の記事では、構築した CI 環境上で動かしている workflow の紹介をしながら、workflow 作成についての Tips をいくつかご紹介したいと思います。 engineers.ntt.com 記事を書いたモチベーション 実際の業務で GitHub Actions を使用するにあたって、ありがちな悩みを解決するための workflow の作成事例や工夫などの
gitにおけるコミットログ/メッセージ例文集100の転載 例文を組み込んだAlfred Workflowを作りました: Alfred Git Commit Message Example 以下転載: gitにおけるコミットログ/メッセージ例文集100 私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじ
お元気ですか。watura です。 最近、キーボードを自作しました。その上キーの配列を QWERTY 以外のものにするという暴挙をしたため、驚くほどゆっくりこの文章を書いています。 ところで、GitHub の「ラベル」って使っていますか? Zaim では、フルカスタマイズしてラベルを活用しています。この記事では、ラベルの実務的な運用をまとめていきます。ちなみに今回は iOS リポジトリのラベルを例としましたが、他もほとんど同じラベルを使っています。 ネーミングの基本まず、ラベルの一覧です。 具体的には以下のように、 0. 優先度 (高) 0. 優先度 (中) 0. 優先度 (低) 1. 不具合 1. 機能追加 1. 機能変更 1. デザイン 1. 相談 1. リファクタリング 1. その他 2. Asana 2. Crashlytics 2. 要望 99. Asana行き 99. タスケテ
お知らせ ソーシャル認証に頼らず安全にログインしていただくため、すべてのユーザーに対してパスワードの設定を必須といたしました。まだパスワードを設定されていない方は、パスワード設定画面よりご設定をお願い申し上げます。 機能改善 領収データ発行機能にてインボイス制度の書式での出力に対応しました。 詳しくはこちらをご覧ください。 新機能 参加者によるオンライン出席機能をリリースしました。今までは主催者による出席管理機能はありましたが、大規模イベント等での受付処理が大変とのフィードバックをいただいてました。今後はイベント作成時に発行される「出席コード」を会場現地や配信で共有してもらうことで、参加者自身でイベント出席登録を行うことができるようになります。これにより受付処理が容易になりますので、イベント主催者の皆様はぜひご活用ください。詳しくはこちらのニュース や 特集ページ をご確認ください。
イベント概要 開催日時 2018年7月12日(木) 19:00〜21:00 (開場 18:30) 会場 hoops link tokyo 東京都渋谷区宇田川町28-4三井住友銀行 渋谷西ビル6階 Google Maps プログラム 開場 (18:30~) Opening (19:00~19:10) 主催者よりご挨拶 Talk Session 1 (19:10~19:30) タイトル:リーガルテックの全体像と、クラウドサインが担う未来 登 壇 :橘 大地 (弁護士ドットコム株式会社) Talk Session 2 (19:30~19:50) タイトル:Gitで変わる!これからの契約業務 登 壇 :早川 晋平 (RUC株式会社) Talk Session 3 (19:50~20:10) タイトル:訴訟のシェアリングで被害者を救う!リーガルテックの可能性 登 壇 :伊澤 文平 (株式会社クラスア
はじめに さまよえるアラフォー男子 @artifactsauce です。 突然ですが、弊社は「外資就活ドットコム」というWebサービスを開発・運営している会社です。サービスイン当初はイケイケガンガンで高速開発・高速リリースをうたっていましたが、開発者が増えるにしたがって様々な問題が発生してきました。今回はプロダクトのリリースにまつわる問題を解決するために弊社で採用した開発ワークフローについて紹介します。 どんな問題が起こっていたのか? Capistranoによる自動デプロイは実現していた我々ですが、それですべてがうまくいったわけではありませんでした。具体的には以下の様な問題が発生していました。 デプロイできる環境を用意するのが面倒である。 各デプロイ担当者がデプロイツールをインストールする必要がある。 デプロイツールを更新していない場合には失敗する。 デプロイ対象サーバーにデプロイ担当者の
概要 背景 複数人数で一つの環境をコードで管理する場合の移行期と運用期の特性 移行期 運用期 Terraformの採用理由 実際の運用 ディレクトリ構成 stateファイルの配置 環境の定義 tfvarsによる切り替え 環境固有のリソース定義 GitHubのPRフロー よかったこと・課題 よかったこと 課題 概要 どうも。篠田です。 「特定の"インフラ担当"・"開発メンバー"」や「古の記憶」に頼らず、『開発メンバー全員が拡張や移行作業を気軽にできるインフラ』を実現するために、私のチームで採用しているTerraformを使ったAWS環境運用フローをご紹介いたします。 Terraformで移行および運用するフローにしたことで、構成全体に対する変更の柔軟性が高まり、コードがあることで運用および拡張期において設計の変更や手戻りを恐れずに開発を進められるようになりました。 次は概要図です。 背景 先
トレタで使っている、チャットで勤怠管理する「みやもとさん」をオープンソースでリリースしました。 https://github.com/masuidrive/miyamoto Slackの#timesheetsという部屋で、「おはようございます」と書き込みと出勤が記録され、「お疲れまでした」と書き込むことで退勤となります。「明日はお休みさせて頂きます」と書き込むと、休暇の届け出になります。 チャットで勤怠管理する最大のメリットは、オフィスに居なくても誰がいつ出勤・退勤したのか全員が分かることにあります。出退勤管理アプリは色々出ていますが、営業で直行直帰する人や、リモートワーカーなどは、帰った時間がリアルタイムでわかりにくいという欠点があります。 「みやもとさん」では、チャットでやりとりする事でみんなの見える形で出退勤が記録され「あ、帰る前にあれも!」など、ありがちなコミュニケーションがスムー
検索しているとなにかとNetflixのgithubリポジトリがヒットするので、全部(2015/07/18現在分)調査してみた。 github APIで https://github.com/Netflix のリストを全部取得して、名前・概要・URL・最終更新日時 (なんの更新だ?) を抽出。 AWS用のプロダクトが多かったのでまずそれらと、その他という分類にした。その他はほとんどがJavaライブラリ・システムだが、一部WebアプリケーションやPythonライブラリがある。 日本語での説明はReadmeやWikiを見て書いているが、理解が正しくないかもしれない。 AWS用 aws-autoscaling Tools and Documentation about using Auto Scaling URL: https://github.com/Netflix/aws-autoscalin
はじめに こんにちは、6月からAndroidの開発を担当している荒川です。 この記事は以下の方を対象にしています。 リモートリポジトリにGitHubを使っている タスクや課題の管理を小〜中規模のプロジェクトで行っている 複数の開発タスクが並行して進むプロジェクトにアサインされている 開発者のみのタスク管理を主体的に行いたい タスク管理ツールを使っているがイマイチうまくいっていない この記事では、私が実践して良かった経験則を紹介します。誰でも真似すれば必ずうまく行くという保証はありません。この記事の読者の方が、担当しているプロジェクトに合わせてアレンジを加えるとより効果が増すかと思います。 開発者のタスク管理 モバイルアプリサービス部では、コミュニケーションツールにBacklogやTrello、Pivotal Trackerを用いている事を突撃!隣の開発環境 パート3【クラスメソッド編】の記
プログラミングが好きな学生のためのGitHub勉強会 2015 | SEゼミ で、クックパッドでの基本的な開発プロセスについて話しました。 また当日はメンターとしても参加しました。 今回はGitHubを使ったこと無かったり、プルリ(Pull Requst)をしたことが無い学生の方々が主な参加者で、 GitHub実践入門の著者が講師を務め、いくつかのWeb系企業のエンジニアがメンターを務めました。 だいたい4人くらいの様子を見ていましたが、プルリを送り合うあたりまではスムーズに。 プルリするために、相手のリポジトリをForkして、ブランチを作って、push して、と ちょっと複雑になると、大変そうでした。 私も最初にgitを使い始めたころは、origin とか master とか、わけがわからなかったのを覚えています。 特に、当時は Subversion を主に使っていたこともあり。 発表内
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く