Add Reactions to Pull Requests, Issues, and Comments
ProductAdd Reactions to Pull Requests, Issues, and CommentsEvery day, thousands of people are having conversations on GitHub around code, design, bugs, and new ideas. Sometimes there are complex and nuanced points to be made, but other times… Every day, thousands of people are having conversations on GitHub around code, design, bugs, and new ideas. Sometimes there are complex and nuanced points to
チャットサービス「Idobata」のオンプレ版 提供をはじめました - 株式会社永和システムマネジメント アジャイル事業部
永和システムマネジメント アジャイル事業部では、2016年3月1日より「Idobata」のオンプレ版 提供を開始しました。 サービスの提供ではなく、ソースコード使用許諾権の販売という形態になります。具体的には、GitHub の Idobata リポジトリのコラボレータになる権利を販売します。 利用者 (使う側) と開発者 (作る側) という関係ではなく、ともに Idobata を育てていくパートナーになっていただける企業や組織、あるいは個人の方にご利用いただくことを想定しています。 価格、許諾事項、導入の流れ等に関しては、以下のページをご覧ください。 https://github.com/idobata/idobata-info/blob/master/onpremise.md
Issue and Pull Request templates
ProductIssue and Pull Request templatesIt's hard to solve a problem when important details are missing. Now project maintainers can add templates for Issues and Pull Requests to projects, helping contributors share the right details… It’s hard to solve a problem when important details are missing. Now project maintainers can add templates for Issues and Pull Requests to projects, helping contribut
GithubでTILというリポジトリが流行りつつあるのかもしれない - 生涯未熟
Githubで海外のエンジニアさんをフォローしているのですが、あるエンジニアさんがtilというリポジトリをstarしていました。 github.com 「なんか新しいツールか何かかな？」と思ったのですが、覗いてみたらdescriptionに"Today I learned"の文字が。 どうもtilというリポジトリを作成してそこに"今日覚えたこと"を書いていくのがプチ流行している様子。 ・ 色んなTILが 今までだと同じような感じでベストプラクティス等をまとめた"◯◯-awesome"が流行ってましたが、 自分が何を学んでいっているのか自分も他人にも知ってもらうためにこういうリポジトリを作って書いていくのも面白そうですね。 関連したWebサービスとかが作成されたらそれはそれでまた面白いのかも。
Investigate switching away from GitHub · Issue #5205 · eslint/eslint
As ESLint has continued to grow, we've started to outgrow the GitHub ecosystem. Team members spend hours each day triaging issues, many of which have incomplete information or are otherwise unclear. As such, we spend a lot of time just asking for more information ("what do you mean?", "what version are you using?", etc.). This has become increasingly frustrating for everyone on the team and ultima
GitHub is undergoing a full-blown overhaul as execs and employees depart — and we have the full inside story
GitHub cofounder and CEO Chris Wanstrath Flickr/by DaveFayram Cofounder CEO Chris Wanstrath, with support from the board, is radically changing the company's culture: Out with flat org structure based purely on meritocracy, in with supervisors and middle managers. This has ticked off many people in the old guard.Its once famous remote-employee culture has been rolled back. Senior managers are no l
OSS開発に参加する人を増やす取り組み「OSS Gate」を開始 - 2015-10-20 - ククログ
クリアコードは去年からSEゼミという企画に協力していました。SEゼミというのは技術的なテーマを軸にして工学系の学生と企業を結びつける就職支援系の企画です。（明示的にそう書かれているページを見つけられませんでしたが、そんなに間違っていないはず。） 去年はリーダブルコードというテーマで協力し、今年はOSSというテーマで協力しました。運営のSEプラスさんは、クリアコードが提案した（チャレンジングな）内容を最大限に活かしてくれました。幸い、参加してくれた学生の方にも企業の方にも楽しんでもらえたようです。クリアコードとしても非常に学ぶことが多いステキな機会でした。ただ、残念ながらお金の面でSEゼミを継続することはできないことが決まりました。 事業としては継続できないのですが、今年のSEゼミで得られた次の知見を活かして「OSS開発に参加する人を増やす取り組み」を始めます。 OSS開発に未参加の人は参加
GitBucket 3.7をリリースしました - たけぞう瀕死ブログ
Scalaで実装されたオープンソースのGitHubクローン、GitBucket 3.7をリリースしました。 https://github.com/takezoe/gitbucket/releases/tag/3.7 Markdownプロセッサの変更 Markdownプロセッサをこれまで使用していたpegdownから独自実装のmarkedjに変更しました。 markedjはJavaScriptで実装されたmarked.jsをJavaにポーティングしたもので、GitHub Flavored Markdownのより良いサポートを提供します。これによってこれまで問題となっていたGitHubとGitBucketのMarkdown記法の違いはかなり解決されています。 また、markedjはGitBucketで使うためにポーティングされたものではありますが、単なるJavaライブラリなので他のアプリケーシ
GitHub : ノマドなエンジニア達とRubyをスケールさせる | Yakst
GitHubの技術ディレクターが語る、GitHubのインフラの特徴と、社員の6割がリモート勤務という社風、Hubotを使った協力的かつ新しい働き方。 Sam Lambertは、2013年にGitHubの最初のデータベース管理者として入社し、現在はGitHubの技術ディレクターを務めています。このインタビューで彼は、今や1000万以上のユーザと2500万以上のプロジェクトを誇るサービスが、比較的シンプルな技術的スタックの上でどのようにスケールし続けてきたのかを考察しています。また、自作のパワフルなチャットボットであるHubotを使ってコラボレーションしつつ、従業員の約6割がリモートで働いているという、GitHubの大規模なオフィスレスな仕事環境についても触れています。 SCALE: 私としては、GitHubはテクノロジーのユーザーというよりは主にテクノロジーの提供者であると思っていますが、そ
1443641775
よく「どうやって情報手に入れてるの？」みたいに聞かれますが、そんなの、ひたすら時間かけてgithubみたりメーリングリスト読んだり最近ではgitterの会話読んでるに決まってます。 どうやって(How)ではなく、なぜ(Why)、自分がそんなことをするようになったのかを、あらためて書いてみる気になったので書いてみたいと思います。 書こうと思ったのは、Howだけ書いても、Why書かないとあまり意味ないと思うことが多くなったからですかね。(この件に関しては) 無責任に大雑把にいうと、(どんな理由であれ)情熱みたいなものがあれば、Howは自然に身につきます、たぶん。 なお、少し長くなるし、自分語りっぽくなるし、いつも書いてるようなものとは少し方向性が違い、具体的なすぐ役に立つ技術的な内容*1は基本出てこないので、期待してるものが違うと思う人は、ここで読むのやめたほうがいいと思います。 どれほどコー
Git（GitHub）の運用で気をつけていること - えいのうにっき
ある日、 PR の内容を見ずにマージすることを岡島（ピッチャーの）というらしい 笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね！— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。 #ブログ待ってます— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、本当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基本
githubの特定ブランチへのgit push --forceをprotectしてエンジニアの精神崩壊を防ぐ( ꒪﹃ ꒪)ﾌﾞｸﾌﾞｸ - Qiita
githubの特定ブランチへのgit push --forceをprotectしてエンジニアの精神崩壊を防ぐ( ꒪﹃ ꒪)ﾌﾞｸﾌﾞｸGitGitHub Protected branches and required status checks もうお済みですか！？ 9月4日のことですがgithubより以下の機能がリリースされています。 特定ブランチへのforce pushを無効する 特定ブランチへのマージ時にステータスチェックを必須にする(CIと連携している場合は、テストが通るまでマージできないようにできる) これを実施することで、ある日新人が謎の空のコミットをmasterブランチにforce pushして来たり、ある日途中からJOINした人がpull reqもせずにdevelopブランチに謎コミットをforce pushして来たり、ある日とあるOSSで間違えて一ヶ月前のローカルレポジト
プログラマの履歴書
「コードを書け。それが履歴書だ」という昔の名台詞が目に留まったので、常日頃感じていることを書き出してみることに。 コードが GitHubで公開してあると、まず採用する側の視点としては非常に助かります。プロジェクトを２、３つ眺めるだけでも、この人が普段どんなことを意識してプログラミングしているのかが見えてきます。例えば、性能を重視しているとか、拡張のしやすさを意識してインターフェースをデザインしているとか。さらに本人の興味の方向性、得意な言語などがわかるが何より嬉しい。過去の経験から、自己申告でJavaができます、C++ができますなどと言うだけの人が期待したレベルでコードを書けた試しがありません。 その次にわかるのがコミュニケーションスキル。基礎的な英語力の判断材料にもなるし、チームを組んだ時のイメージがしやすい。問題を共有する能力も大事。自分一人の頭の中でたくさん難しいことを理解して解決で
Pull Requestのレビューが辛くて会社をやめたい
私はプログラマに向いていないのかもしれない。 うちのチームではコミットをmasterブランチへマージする前に、Pull Requestを出してそれをリーダーや他の人がレビューすることになっている。（たぶんよくあるフロー？） そのPull Requestでもらうコメントを見ると死にたくなってくる。特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「（こんな実装は）有り得ない」といった言葉だ。 レビューにおいてそういった強い言葉がときとして必要なことは理解している（そういえばこなものもあったなと思い出した http://cpplover.blogspot.jp/2013/07/linuxml.html ）。またそういったコメントを残す相手との仲が険悪なわけでもない。またよいと思ってくれたらしいところは褒めてくれたりLGTMしてくれたりもする。 だけどそれでも辛い。きつい言葉を向けられる
Read-only deploy keys
EngineeringRead-only deploy keysYou can now create deploy keys with read-only access. A deploy key is an SSH key that is stored on your server and grants access to a single GitHub repository.… You can now create deploy keys with read-only access. A deploy key is an SSH key that is stored on your server and grants access to a single GitHub repository. They are often used to clone repositories durin
Node.js／JavaScriptの情報収集手段 ～変化が激しいOSSは、直接GitHubをウォッチする
はじめに 初めまして。Node.js日本ユーザーグループ代表の古川（@yosuke_furukawa）です。日本ユーザーグループ代表としての活動は二ヶ月に一度開催されるNode学園のオーガナイズと、一年に一度開催されるNode学園祭の開催です。また、io.jsエヴァンジェリストとして、毎週のio.js newsの記述やロードマップの公開等、io.jsを広める活動もしています。このような私が、Node.jsについて普段どんな風に情報収集を行っているかを紹介します。 Node.jsの現在 Node／io.jsは変化が激しいコミュニティであると言われております。一つその例を示すグラフを見てみましょう。 このグラフは、npmと、RubyGemsやPyPI、Mavenといった他のパッケージマネージャのライブラリの登録数を時系列で表したものです。緑のグラフがnpmですが、飛び抜けて増えているのが分かる
われわれは、いかにして変更点を追うか
われわれは、いかにして変更点を追うか ChangeLog/Issueを追う技術 自己紹介 azu @azu_re Web scratch, JSer.info アジェンダ 変更点を ChangeLogで知る Issue/Pull Requestで知る Commitで知る アジェンダ 変更点を Commitに書く Issue/Pull Requestを扱う ChangeLogにまとめる 変更点を追う :mouse: ChangeLogの追い方 ChangeLogを追うにはまずChangeLogの更新に気づく事が必要 GitHubでライブラリのリリースを見ていくためのツールや方法に書いた 更新検知の仕組みや補助ツールについて リポジトリのWatch => azu/github-reader タイムライン => azu/github-reader Star => starseeker GitHu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - tallesl/Rich-Hickey-fanclub: "every time I watch one of his talks I feel like someone has gone in and organized my brain"
Dear Open Source Maintainers by bkeepers · Pull Request #115 · dear-github/dear-github
JPCERT Coordination Center
