こんにちは、やまなかです。 今回はサーバー上の関数を実行するためのプロトコル(通信規格)であるRPC (Remote Procedure Call) を実現するため、Googleが開発したgRPCについてまとめていきます […]
A interactive Git visualization tool to educate and challenge!
ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. (英語勉強しないと..) 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 (仕事でDeprecateとか滅多に使わんし) 同僚に聞きつつ10つあげてみた. 以下列挙 (例は実際の同僚やOSS上でのコミットメッセージです.) Add *A to *B AをBに加える
This incident affected the database (including issues and merge requests) but not the git repo's (repositories and wikis). Timeline (all times UTC): 2017/01/31 16:00/17:00 - 21:00 YP is working on setting up pgpool and replication in staging, creates an LVM snapshot to get up to date production data to staging, hoping he can re-use this for bootstrapping other replicas. This was done roughly 6 hou
GitHubなどに自分のツールやライブラリを公開するとき,README.mdは重要な役割を担っている.レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている,と言っても過言ではない.実際自分が使う側になったときも,まずREADME.mdを読んで判断していると思う. 成功しているプロジェクトを参考にしつつ,自分が実践していることをまとめておく.ここに書いていることはあくまで(自分の中で)最低限的なものである.プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う. READMEの役割 README.mdには大きく2つの役割がある. プロジェクト,ツールの使い方,インストール方法 プロジェクト,ツールの宣伝 元々READMEは前者の役割しかなかったが,GitHubの仕組み上,後者の役割も徐々に重要になっている. さらに
プレゼン資料を作っている時に「このコミットグラフをMarkdownかテキストで書けたらな」と思ったことがある人、結構いるのではないでしょうか。 GitGraph.js を使うと、JavaScriptで記述したコミットログをcanvasを使って可視化できることを知りました。なかなかおもしろいです。 準備 まず GitGraph.js の JavaScript と CSS ファイルを読み込みます。GitHub からソースをcloneするなり、bowerを使うなり、CDNを使うなり、お好みで。ここではコミットグラフを定義するコードも別ファイル index.js に書くことにします。 <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>GitGraph.js</title> <link rel="stylesheet" type=
ProductSimpler GitHub Pages publishingWe're making it easier to publish a website with GitHub Pages. Now you can select a source in your repository settings and GitHub Pages will look for your content there.… We’re making it easier to publish a website with GitHub Pages. Now you can select a source in your repository settings and GitHub Pages will look for your content there. Selecting master bran
この記事は個人ブログで海外向けに書きかけの記事の日本語版です。そのため、一部日本人向けではない記述が含まれます。 英語版はこちらです Why you must not ask questions on Github issues 現在は GitHub は Discussions を提供しています。 Issue Template から Discussion へと誘導するのがおすすめです。 2023-06-14 追記 TL;DR: Issue Tracker で質問するのは開発者に対する DoS 攻撃になるかもしれない。 Forum がある場合は Issue Tracker で質問してはいけない。 背景 Github の時代になる前は、ある程度の規模のOSSプロジェクトはみんな Issue Tracker と別に フォーラム (BBS, ML など) を持っていました。ユーザーはフォーラムでデ
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
綺麗にコミットしてますか?? はじめまして!Emojineerのnownabeです。グッドパッチではProttのサーバサイドエンジニアをやっています 本記事ではGitのコミットを綺麗に保つためにProttチームで導入しているEmoji Prefixを紹介します。 Emoji Prefixって何? Emoji Prefixは「Gitのコミットメッセージの先頭にEmojiをつけよう」という一種のスタイルガイドです。 GitHubなどEmojiに対応しているGitホスティングサービスの利用を前提としています。 Emoji Prefixをつけてコミットすると、例えばGitHubならこのように表示されます。 基本はコミットメッセージの先頭にEmojiをつけるだけです。 ただし、EmojiはEmoji Prefixのルールに従って決める必要があります。 コミットの種類によってEmojiが決まる、という
2週間ほど前にGitHub社からGitBucketのコミッタ宛てにメールが届きました。 それは「GitBucketはGitHubにあまりにも似すぎているが、GitHub社はGitHubのプロプライエタリなマテリアルをコピーしたり、ユーザインターフェースをクローンすることは許可していない。これはGitHub社の知的所有権を侵害している可能性があり、GitHubのユーザに混乱を引き起こすもので、改善を求める」という趣旨のものでした。 1点目についてはGitBucketはOcticonsやBootstrapテーマなどオープンソースのリソースは活用しているものの、GitHubからいかなるプロプライエタリなマテリアルやソースコードもコピーしていませんので問題ではありませんでした。 2点目については(ユーザインターフェースに関する権利については諸説あるようですが)、GitBucketが「GitHubク
日本時間で1月28日木曜日午前9時過ぎから発生したGitHubのサービス障害は、同社のデータセンター内での一時的な停電をきっかけに連鎖的に発生した障害の影響であることが、GitHubのブログに投稿された記事「Update on 1/28 service outage」で説明されています。 GitHubのブログから引用します。 A brief power disruption at our primary data center caused a cascading failure that impacted several services critical to GitHub.com's operation. 主データセンターにおける一時的な停電が連鎖的な障害を引き起こし、GitHub.comの運用にいくつもの深刻な影響を与えてしまった。 GitHubの説明によると、障害が発生したのは協
タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日本人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(!) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか?」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか?これつけると何が変わるんですか?」と質問がきたのです。 作業ブランチで git pull --rebase origin master
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く