こんにちは、鈴木です。 GitHub Enterprise Cloud が使えるようになりました！ オンプレミス版の Enterprise Server とは異なり、バージョンアップ作業やサーバ保守などの運用がないので快適です。 GitHub Enterprise Cloud の導入は、サービスを導入する経験として多くの学びがありました。知見をまとめて社内のテックカンファレンスで発表したので、その資料を公開します。 発散させる役割と収束させる役割の両方が必要なのだと思います。 こういうこと、ありますよね。いわゆる「タバコ部屋の会話」ですが、少人数が集まり雑談が発生する場（休憩スペースや昼食、飲み会など）では発散する方向の会話が生まれやすいです。 こう思ったんです。「今は発散する方向に話が偏っている状態なので、収束させる方向の行動が必要ではないか」と。 勢いはあるけど、勢いしかない気運案件。
はじめに 愛車をリフォーム・アップグレードできるサービスKINTO FACTORYプロジェクトに参画している金谷です。今回は、JIRAとGitHub Actionsを活用し、複数環境へのデプロイのトレーサビリティを向上した取り組みを紹介します。 なお前回は、決済チームでリモートモブプログラミングに関する記事を書きました。 背景と課題 私はKINTO FACTORYプロジェクトの開発工程の後半から参画しました。プロジェクトのうちECサイトのフロントエンドチームリーダーを担当することになりましたが、担当する中で以下の課題があると考えました。 GitHub issues, JIRA, Excelがタスク管理に使われており進捗が管理しにくい どのタスクがどの環境にデプロイされているか分かりにくい テスト環境へのデプロイ時のリリースノート作成が面倒 ExcelのWBS+ガントチャートの例 はじめに進
GitHub Actionsでdocker buildすることが多い。このときのキャッシュをどうするかという話題。 基本 GitHub Actionsでdocker buildしてAmazon ECRにdocker pushする、典型的な.github/workflow/docker-push-to-ecr.ymlはこういう感じ。 name: Push to Amazon ECR on: push: branches: [ 'main' ] jobs: docker: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: docker/setup-buildx-action@v1 - name: Configure AWS credentials uses: aws-actions/configure-aws-c
Githubに主戦場を移した世界のIT人材獲得競争 The software, be open or die 2016.01.08 Updated by Ryo Shimizu on January 8, 2016, 07:00 am JST 今後、おそらくもはや疑いようもないことは、数少ない例外を覗いては、ソフトウェアはオープンソースでなければ生き残れないということです。特にプロが使うものほどそうです。 2015年はそれが決定的になった年でした。 昨年はPFI(Preferred Infrastructure)社のChainerや、GoogleのTensorFlow、Facebookのtorch7といったディープラーニング(深層学習)向けのフレームワークがオープンソースになりました。 筆者らが開発したディープラーニング用のGUI環境、DEEPstation(https://github.
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
Answering the Question: “How Can I Get More Followers on Instagram?” the Straightforward Way Why Instagram and why you absolutely need to buy Instagram followers as quickly as you possibly can You’re probably wondering why I recommend that you jump aboard Instagram over all of the other social media networks that you could purchase followers four – especially Facebook and Twitter in particular. Th
2013.01.31 ITニュース いまやプログラマーの「必須プラットフォーム」となりつつあるGitHub。サービス開始からわずか5年で全世界にユーザーを獲得してきた同社は、独自の経営理念によって「プログラマー天国」を築き上げていると評判だ。その根底にある考え方や、組織運営のこだわりとは何なのか？ 来日中のGitHub経営陣に、編集長の伊藤健吾が話を聞いた。 GitHub COOのPJ Hyett氏（左）と、CIOのScott Chacon氏（右）。多忙なスケジュールの中で取材に応じてくれた 「これからの時代、プログラマーをやりたい人にとって、GitHubアカウントを持たなくて済むのは小学生までとなるでしょう」 弊誌対談「小飼弾×増井雄一郎が大激論！ 開発者「大増殖時代」の到来で、プログラマーの存在意義はどう変わる？」で小飼氏がこう述べるほど、世界中のプログラマーに利用されるようになった開
Github Notification API が出ました。 Notifications API - GitHub Recent posts in this category Notifications API technoweenie on October 26, 2012 Latest commit per d... https://github.com/blog/1306-notifications-api github の通知を取得する場合、これまでは miyagawa さんが github growler でやっていた様に、ダッシュボードのRSSを使って自分のイベントを抽出しなければなりませんでしたが、Notification API を使う事で Github 上と同じ通知メッセージが取れる様になりました。 今日は Perl で Github のメッセージを通知するアプリケーショ
[Travis CI](travis-ci.org) というGithubと連動してGithubにコミットすると勝手にテストが走ってテスト結果を通知してくれる、ようするにJenkins as a Serviceみたいなやつがあって、とても便利なので知らなかった人はこの際使いましょう。 そんでTravisの設定ファイルが.travis.ymlで、プロジェクトのディレクトリに置いておくだけでいいんだけど、ごく最近rubyの.travis.ymlを書き直したので、そのときに調べたものを開陳しておこうというエントリ。 * https://github.com/ruby/ruby/blob/trunk/.travis.yml これが最終的に今のRubyの.travis.ymlで、俺の趣味によるやりすぎ気味のコメントと、`language: c`の例としてはもっとも網羅的な(つまり微に入り際に穿った)記
tl;dr - 通常のHookではなくPubSubHubbubのほうのHookを使えばGithubのすべてのイベントをひとつのWebHookで受け取ることができる。 Github の WebHook ではレポジトリの更新しか受け取れず、issue とかも受け取れたら便利なのになーと思いつつ API ドキュメントを見てみると Hook を API から登録したりすることができるようになっていた。 だがこれは所詮は Web から登録できる Hook をいじるもので、このリストにあるものしか登録できない。 また、それぞれの Hook について登録できるイベントはリストで定義されている物に制限されているようで、たとえば WebHook だと push イベントしか設定することはできないみたい。（API 経由でも設定できなかった） 一方、それとは別に用意されている PubSubHubbub の Ho
趣味プログラマです、こんにちわ。一応生きてます。 さて、Pythonista各位におかれましてはmoratoriumをエンジョイされていますでしょうか。そろそろライブラリも著名なものはPython3に対応してきましたし、そろそろ本格的にPython3、となっているころ合いですね。というか、Python3に対応してないとちょっと恥ずかしくなってきましたね。 とはいえ、Python2は根強く残るでしょう。というわけでPython2とPython3両方で動くコードを書きましょう。テストも書くのは当たり前ですし、せっかくなのでCIもしましょう。 と私も最近思ったので快適に開発を進めるための環境についてメモです。 github : 言わずもがなですね。 travis : githubと連携してCIできるサービス。P言語にも対応していて、最近アツいです。 tox : 複数のPython処理系でvirt
時代がWindowsハッカーに追いついてきた。 GitHub for Windows sync Stay in sync The sync button turns the complex workflow of pulling and pushing into a single op... http://windows.github.com/ GitHub for Windows - GitHub Ever wish there was an easy way to get up and running with Git and GitHub on your Windows computer? ... https://github.com/blog/1127-github-for-windows 待ってたよ。 ダウンロードしてインストールしてみた。 この後、PC内から存在するリポジトリを
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
GitHubにリポジトリを置いてる人はみんなプルリクエストを待っています。けどプルリクエスト用にフォークした自分のリポジトリを保守する方法が途中でわからなくなって...という人が案外多いんじゃないかなと思ったり。なので、ちょっとメモ置いときます。って、人のためみたいな言い方ですが、まあ自分用のメモです。 まずこうしたほうがいいという原則。masterブランチはフォーク元から変更せず、かならず自分用のブランチを作る。これは、masterを作業の同期用に置いておくためです。 自分のブランチでコミットしたあと、フォーク元のmasterが進んでないかのチェックは必ずすること。 もし進んでいたら自分のmasterに元作者のコミットを取り込んで自分のGitHubでのフォークが最新と同期してる状態にしましょう。で、元作者のコミットログを確認して何が起こったのかを理解しましょう。 $ git checko
前回、GitHub Pages 活用の概要を書きましたが、実際に運用していくと、master と gh-pages をどう使い分けるか、また両者の同期をどう行うかなど、いくつかの課題が浮かび上がってくると思います。 そこで今回は、実際に GitHub Pages 上で運用されている Dive Into HTML5 をよく知る立場から書かれた記事 「GitHub Pages Workflow and deleting git’s `master` branch – Oli.jp」 の翻訳を中心に、関連するいくつかの記事から、ユースケースと運用のシナリオ、及びそれに応じたワークフローをまとめてみました。 以下は、その参考記事です。 Git post-commit hook to keep master and gh-pages branch in sync by Paul Irish 2011
GitHubは12月19日、継続的インテグレーション（CI）サーバー「Janky」をMITライセンスで公開した。チャットを利用する自動化ツール「Hubot」を利用して動作し、チャット経由で通知を受け取ったり、操作を行える機能などを備えている。 Jankyは、オープンソースの継続的インテグレーションシステム「Jenkins」をベースとしたCIサーバー。GitHubでホスティングするプロジェクトが利用できるように設計したという。 Jenkinsは「Hudson」からフォークしたソフトウェアで、ビルドやテストなどの継続的なジョブを監視できる。プラグイン機構を備えており、サードパーティの拡張機能を利用できるなどのメリットがある。JankyもJenkinsコミュニティからのメリットを享受できるという。日々のオペレーションは、GitHubが先にオープンソースにしたチャット自動化ツールの「Hubot」で
Bazaar のホスティングサイトとして、 Launchpad があります。これはプロジェクトをまたぐ Issue Tracker やオンラインの翻訳システムが含まれており、 Ubuntu の開発に大活躍しています。 しかし、 Launchpad は github や BitBucket とは異なり、ユーザー主体ではなくプロジェクト主体になっています。ユーザーディレクトリ配下にブランチを作ることも可能なのですが、それだとマージリクエストなどの管理ができないので、本当に他人に使ってもらいたいならまずプロジェクトを作るところから始めないといけなくて面倒です。 その他にも、 Ubuntu の開発には Launchpad の機能が必要なんだろうけど、個人ユーザーには github の機能のほうが魅力的という場面がよくあります。 Launchpad で満足していたとしても、 github で開発され
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
