GitHub - kyanny/ghn: List/Open unread GitHub Notifications.You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
ghq: リモートリポジトリのローカルクローンをシンプルに管理する - 詩と創作・思索のひろば
以前紹介したghqというツールで GitHub のリポジトリを手元に簡単クローンしてたのを、環境が新しくなったついでに Go で書き直し、完全リニューアルしました。（前は zsh だったのでなんだかなーと思ってた。） そもそも何をするツールか GitHub や Google Code Project でホストされている Git、Mercurial のリポジトリを手元にクローンすることができます。リポジトリは設定したルート（デフォルトで ~/.ghq）以下に、以下のようなパスで置かれます。 ~/.ghq/github.com/motemen/ghq go get と似てますね。同じような感じで ghq get <URL> します。 % ghq get https://github.com/motemen/ghq clone https://github.com/motemen/ghq ->
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
github kaigi感想 - $shibayu36->blog;
github kaigiに参加して、発表したりとかした。発表内容についてはまた別で紹介するとして、感想だけ書く。 今回かなり印象に残ったのは「How GitHub Works」、「GitHubで 雑誌・書籍を作る」、「pplog.net の作り方( ˘ω˘) 」の三本。 「How GitHub Works」では、GitHubではどうやって良い仕事環境とかやりがいのある仕事を作っていっているか、みたいな話だった。その中でどうやってモチベーションを保ってもらうかみたいな話があって、外的要因と内的要因があって、給料とか設備とかの外的要因も大事だけど、それと同様に仕事の柔軟性とかやりがいみたいな内的要因も大事だよねと言っているのが面白かった。 柔軟性という話題でリモートワークについて触れていたけど、受けた印象として、やはりリモートワークを達成するために、リモートワークを潤滑にするための仕組みづくり
watsonを使って超速issue管理をしてみた | kz-devkz-dev
今回は、issue管理ツールのwatsonを導入してみました。 普段のissue管理は、redmineなどを使って行われている方も多いと思います。 ただ、チケット切るためにいちいちブラウザを開いて、あれこれ入力してという流れに時間がかかってしまうために、面倒だと感じている方も多いと思います。 特に、人が少ないスタートアップなどはこの作業に時間を取られるのは致命的です。 そこで、もうソースコードに直接issueを書いて管理してしまえ！！ということで、今回のwatsonの出番です。 issue自体をソースコードに直接書くので、管理対象もソースコードのみとなります。 これで、毎朝remineから飛んでくるうざい？メールを見なくても済みそうです。 watsonとは？ 冒頭でも述べた通り、ソースコードに直接issueを書き込めるツールです。 これらのissueは、コミット時にgithub上の
GitHub の ATOM が CoffeeScript で書かれているのはどうなの? - ワザノバ | wazanova
http://discuss.atom.io/t/why-coffeescript/131 2 comments | 2 points | by noto ■ comment by noto | 約1時間前 先日 GitHub が発表してエディタ ATOM のディスカッション・フォーラムでなぜ CoffeeScript で書かれていて、EcmaScript 6 (ES6) じゃないの? node.js/V8 を利用するデスクトップアプリケーションなら ES6 をすぐに使うほぼ完璧な機会なのに、という問題提起があり、それについて議論があったようです。 前提として、GitHub の JavaScript Styleguide に 新たに JS を書く時は CoffeeScript で書くこと 新たに .js ファイルを追加することは避けること と書かれていて、GitHub の中の人としては
Welcome to yamaha-webmusic.github.io !
Yamaha-WebMusic へようこそ！ このサイトではヤマハ製品に関わるアプリケーション、Firmwareをオープンソースとして公開しています。公開しているソースコードを改造してオリジナルのアプリ、機器の開発に挑戦してみませんか？
結婚式の二次会をGithubで管理するといろいろ便利って話 | -&-
一定期間更新がないため広告を表示しています
GitHub announces 3D File Diffs
Product3D File DiffsBack in April, we introduced the 3D file viewer. Today we're improving this by displaying diffs of STL files on GitHub. There are two modes to figure out what you're… Back in April, we introduced the 3D file viewer. Today we’re improving this by displaying diffs of STL files on GitHub. There are two modes to figure out what you’re looking at. By default, we select “Highlight”,
研究室でGithub勉強会をしました。 - FromAtoMemo
@10月18日 世はまさに、大ソーシャル時代！ というわけで、研究室でGithub勉強会をしました。 ある日私は、研究室の課題で『もじたま』を作っていました。この課題はグループワークだったのですが、"1台のパソコンにグループメンバーが集まってコーディングやデバッグをする"という、つらぽよ案件が多発していて、「このまま放置しておいたら、人が死ぬぞ……。」と思ったのが、勉強会をしようと思ったきっかけです。 ローカルな不幸を減らす為に 恐らく、学生がよく聞く（言う）セリフとして 「研究室にソースコード忘れて、家でデバッグできない。」 「最新データ入れたUSBメモリ忘れた。」 「パソコンクラッシュして、全データ死んだ。」 があります。これをそのまま放置しては大変に不幸。論文・レポート提出間際に、これらの不幸によって死の覚悟をするのは、精神衛生上でもよろしくないです。 オンラインストレージサービスな
プログラマがGitHubとどう関わっているのか垣間見て感じたこと | Act as Professional
関係各所の協力により実現した1日にとても感謝している@HIROCASTERでございませう。 スタッフとして協力してくれる仲間がいたり、突発LTやってくれたりなど、Agile渋谷のおなじみのの雰囲気がアウェイの銀座も垣間見れたのもよかったです。 1日暇になったからLTやりにきてくれる仲間がいたり、おもしろかった。 Book1st銀座コア店では、Web+DB PRESSを1冊ずつ持った人が7人以上並ぶという光景があったとか。 「The GitHub」イベント詳細発表！話題のあの人が登壇 #Agile渋谷こちらのイベントのまとめです。 感想個人的な感想としては、やはり感じていたとおり、GitHubを使いまくってる人とほとんど使っていない人にグッサリわかれてしまっているのかなと。 仕事じゃ使えないけど、プライベートだと使いまくってるなんて、ケースはあまり聞かない。 そして、GitHubを使っていな
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
GitHub - abraham/twitteroauth: The most popular PHP library for use with the Twitter OAuth REST API.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - voronianski/flux-comparison: :pencil: Practical comparison of different Flux solutions
GitHub - naholyr/github-todos: Git hook to convert your TODOs into Github issues
git configでuser.nameを設定しているのに毎回Usernameを聞かれる場合、remoteのurlを確認する。 - Qiita
How GitHub Works (GitHub Kaigi, Tokyo, 2014)
はてなブログチームの開発フローとGitHub
GitHub - YahooArchive/mojito: [archiving soon] Yahoo! Mojito Framework![GitHub - YahooArchive/mojito: [archiving soon] Yahoo! Mojito Framework](https://cdn-ak-scissors.b.st-hatena.com/image/square/7e587f385639b9cf7dde724de7a23e38dd5b04aa/height=288;version=1;width=512/https%3A%2F%2Fopengraph.githubassets.com%2Fcb6c4a4bde704a8702f2579ba4ce14eecc09dd6e822d74eecc3693311bb62c36%2FYahooArchive%2Fmojito)
GitHub - yui/yui3 at 5aa34d00314bf01aaadbee9bef5d6ba16376f98f