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
Organize Your Code Gists are like long-term memory for the professional software developer. Use GistBox's color-coded labels to curate your personal gist library. Collaborate With Team Share your knowledge with the rest of the team. GistBox Groups are the perfect way to build a social library of useful code snippets.
Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 対象としているソフトウェアは、GitHubやGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス(の部品)やオープンソースプロジェクトです。 まず、以下の2点を原則として考えています。 origin masterを壊さない origin masterの(1st parentをたどるツリー)にテストを通らないcommitを入れないよう努めます 変更の主題を常に明確にする 前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ
NJKWebViewProgress 実装 • UIWebViewDelegateからロードが完了したリソース の数を数える - (void)webViewDidStartLoad:(UIWebView *)webView { _loadingCount++; _maxLoadCount= fmax(_maxLoadCount, _loadingCount); ! [self startProgress]; } ! - (void)webViewDidFinishLoad:(UIWebView *)webView { _loadingCount--; [self incrementProgress]; }
つい先日、GitHubで管理していたテスト用中央ブランチに、チームメンバーが誤ってgit push --forceしてしまい、 一部の歴史が消失するという事件が起きました。 ぎゃあああ!なんばしよっとね!うっかりでしたじゃ済まんばい! とか思っていたらJenkinsの開発者みたいなスゴい人でもやらかしちゃうみたいです。 Jenkinsの開発者、間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまう http://cpplover.blogspot.jp/2013/11/jenkinsgit-push-force.html スゴい人でもやらかすんだから、平民の我々もそのうちやらかすに違いない。 緊急バグ修正などで慌てていたら尚更ですね。(というか自分が一番やりかねない) というわけで、何とか仕組みの上で防くことができればと思って仕掛けることにしました。 以下のスクリ
SaaSのCIと言えばTravis CIやCircle CIといったサービスが有名ですが、いずれにしてもプライベートリポジトリを使う場合は有料なのです。しょうがないよね、商売だもんね。でもCI入れたいなぁ。 そんな中、GithubだろうがBitbucketだろうがプライベートリポジトリでも無料で使っていいよ!というβ期間中のCI、Werckerが僕の周辺で話題になっていたので、触ってみました。画面もスゲー使いやすい上に、ハマりどころもなく、これはひょっとしてひょっとするんじゃないの?という期待を込めて、rails newからRailsアプリをHerokuにデプロイするまえのチュートリアルを作ってみました。みなさんもこの記事を参考に、ぜひ使ってみてください。 この記事のゴール Githubにpushしたら自動的にWercker上でRSpecのテストが動くこと Werckerでのテストに成功し
2013-12-18 ブラウザ開発で使用した超絶便利なオープンソースライブラリ10選 こんにちはnasustです。Showrtpathブラウザ( http://showrtpath.com )の開発で使用したオープンソースを全て紹介したいと思います。 正直言って、このオープンソースが無ければ3倍近くの開発期間が延びたでしょう。ちなみにShowrtpathブラウザの開発期間は、大凡2人月ぐらいです。 BlocksKit https://github.com/pandamonia/BlocksKit このライブラリが無ければ、iOS開発の面白さは半減するでしょう。iOSのクラスにあるデリゲータと対応するBlocksのメソッドを追加してくれます。 [Button addEventHandler:^(id sender) { //Buttonが押された時の処理 } forControlEvents
GitHubのブログおよび国内の報道によると、GitHubに対して大規模な不正ログインが試みられたようです。 GitHubは米国時間の2013年11月19日、ブルートフォース攻撃を受けたことを明らかにした。攻撃の時期や被害を受けたアカウント数は公にしていないが、今回の攻撃を踏まえ、より強固なパスワードや二要素認証などを利用するようユーザーに呼び掛けている。 GitHubにブルートフォース攻撃、一部のパスワードが破られるより引用 私もGitHubアカウントがありますのでSecurity Historyページを確認したところ、不正ログインの試行が確認されました。IPアドレスは、ベネズエラ、タイ、ブラジルのものです。 GitHubアカウントをお持ちの方は、念のためSecurity Historyを確認することを推奨します。 今回の不正ログインの特徴は以下のようなものです。 少数の「弱いパスワード
前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。 この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。 コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。 コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req
2013/10/16: Githubのhelp「Remove sensitive data」について追記 先日、初めて知ったのですが、GithubのプルリクをCloseは出来ても、削除は出来ない。(*1) 普段使う上では困らないのですが、パスワードなどの公開すべきでない情報がプルリクに含まれると、結構ヤバい事になる。 結論 結論を先に書くと「リポジトリを作り直すしかない」 試したこと プルリクしてるブランチを上書きする パスワードなどの情報をコミットから(rebase -iなどで)消してからブランチを上書きしてみた。 $ git push -f origin topic_branch プルリクに上書き前後の履歴が全て表示される... プルリクエストしたブランチを削除する 実はGithubでプルリク中のブランチを削除すると、自動的にプルリクがCloseになる。 Closeになるだけだった..
GitHub創設者が語る"立ち上げから利用者300万人までの軌跡" に行ってきた。 GitHub創設者が語る"立ち上げから利用者300万人までの軌跡" | PeaTiX togetterはこちら。 GitHub創設者が語る"立ち上げから利用者300万人までの軌跡" - Togetter 印象に残ったことだけピックアップして書く。 立ち上げから利用者300万人までの軌跡 PJ Hyett(Github, Inc. COO) Scott Chacon (Github, Inc. CIO) Err the blog クリスと一緒に立ち上げたブログ。これを通じてRubyコミュニティのなかでは有名になった。 大企業が嫌で Err Free というRubyのコンサルをやる会社を起こした。でもコンサルはクライントが上司になるようなものだった。 dogtimeという犬向けのソーシャル・ネットワークを作った
今日はkonyがお送りします。 前回の投稿の編集履歴に続く大きな機能追加をしましたのでお知らせします! 投稿に編集をリクエストできるようになりました編集リクエストとは、「Qiitaに投稿された情報を修正したり情報を追記して本体へのマージを依頼できる仕組み」です。 これまではコメントで情報を追加したり修正箇所を指摘しあったりなど、あまり効率的ではない方法が取られていました。そこで今回、GitHubのPull Requestのように変更を直接提案できる、精度の高い正しい情報が蓄積できる仕組みとして編集リクエスト機能をリリースいたしました。 編集リクエストの使い方(リクエスト送信編)1. 投稿ページで、「編集リクエストを作成する」をクリック 2. 編集リクエストフォームで内容を編集する 3. コメントを入力して、「送信する」ボタンをクリック 4. 編集リクエストの送信が完了しました! もし間違え
白石 俊平 ニュース jquery 0 Comment 2013年1月17日、jQuery「公式」のプラグイン・レジストリ(プラグインの集積場)が公開されました! URLはこちらになります。 http://plugins.jquery.com/ このプラグイン・レジストリの目的は、従来のプラグインサイトでは解決できなかった、「断片化」と「配布」の問題を解決することだそうです。 「断片化」・・・「jQuery プラグインがWeb上の至る所にあり、探すのが面倒」という、現在の状況 「配布」・・・作成したプラグインを配布するためのサイト作成や宣伝に手間がかかる、従来のプラグインサイトでは登録が面倒だった 新しいプラグイン・レジストリは、GitHubと連携することを前提として、こうした問題をエレガントに解決し、従来のプラグインサイトを完全に置き換えるものです。 開発者にとっては、プラグインを公開
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く