Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ
平素よりYahoo!知恵袋をご利用いただきありがとうございます。 2017年11月30日をもちまして、「知恵ノート」機能の提供を終了いたしました。 これまでご利用いただきました皆様にはご迷惑をおかけすることとなり、誠に申し訳ございません。 長年のご愛顧、心よりお礼申しあげます。 引き続き、Yahoo!知恵袋の「Q&A」機能をご利用ください。 Yahoo!知恵袋トップ 知恵ノートサービス終了のお知らせ プライバシー - 利用規約 - メディアステートメント - ガイドライン - ご意見・ご要望 - ヘルプ・お問い合わせ JASRAC許諾番号:9008249113Y38200 Copyright (C) 2018 Yahoo Japan Corporation. All Rights Reserved.
Bazaarでござ~る。猿でもできる分散バージョン管理“超”入門:ユカイ、ツーカイ、カイハツ環境!(20)(1/4 ページ) 「“分散”バージョン管理は難しい」という人こそ 最近、GitやMercurialが注目を浴び、SubversionやCVSなどの中央型のバージョン管理システムに代わり分散型のバージョン管理システムの普及が進んでいます。本稿では、GitやMercurialに比べ、いま一歩マイナーな分散バージョン管理システムである「Bazaar」を紹介します。 本稿は、想定読者層としてはSubversionやCVSを、すでに使っており、分散バージョン管理システムに興味がある方を対象としています。「分散バージョン管理システムって何?」と思われる方は、連載第3回の「分散バージョン管理Git/Mercurial/Bazaar徹底比較」を参照しておくとスムーズに読み進められると思います。 なお
「GitHub トレーニングチームから学ぶ Git の内部構造」に行ってきました!Gitの中・上級者向けの素晴らしい勉強会でした。おもしろかった! 今回の勉強会で一番面白かったのは、「とりあえずコミットをしろ。そうすりゃあとでなんとでもなる」です。git reset --hard によって消えたはずのコミットが git reflog から復元できるなんて目から鱗でした。現在の変更を破棄したい場合でもとりあえずコミットしておけ、という教訓の意味がやっと分かりました。 末尾に勉強会のノートを添えておきます。 このイベントは、その場で図を書くような説明などアドリブが多く、とてもわかりやすかったのですが、まとまった資料を貼るのが難しそうな発表でした。したがって、資料は公開されないかもしれません。とすると、このノートはいまのところ唯一の資料です! ちなみに、会場の様子はこんな感じでした。勉強会の後の
コードのインデントはタブ?スペース? クォートはシングル?ダブル? 人気のあるコーディングルールの統計 -Popular Coding Convention
Reference Manual OpenCV-2.x(svn) C: リファレンス日本語訳 C++: リファレンス日本語訳 OpenCVチートシート(C++)(訳) OpenCVユーザガイド(訳) Python: リファレンス日本語訳 Google Test-1.6 Google Test ドキュメント日本語訳 Google Mock(svn) Google Mock ドキュメント日本語訳 OpenCV-2.2(r4295相当) C: リファレンス日本語訳 C++: リファレンス日本語訳 OpenCVチートシート(C++) (訳) Python: リファレンス日本語訳 OpenCV-2.1(r2997相当) C: リファレンス日本語訳 C++: リファレンス日本語訳 OpenCVチートシート(C++) (訳) Python: リファレンス日本語訳 OpenCV-1.1pre C/C++:
お久しぶりです。@at_grandpa です。 今回、Model View Controller について再考する機会があったので、自分なりに整理してみました。 勘違い MVCの勘違いに関しては、以下のSlideShareが有名かと思います。 やはりお前らのMVCは間違っている @mugeso これにはドキッとしたことを覚えています。 このスライドで「間違っている!」と指摘されている形式を、そういうものだと理解していたからです。 上記で指摘されている勘違い形式を、自分なりにわかりやすく噛み砕き、図にしてみました。 Userからの入力をControllerが受け取る Controllerはデータ置き場であるModelからデータを取得する 取得したデータをControllerが加工する 加工したデータをViewに転送する Viewは、受け取ったデータを視覚表現しディスプレイに表示する 自分の中
Github GlobeはHTML5/WebGL製のオープンソース・ソフトウェア(GPL v3)です。 世界中にいるGitHubユーザをビジュアル化するソフトウェアがWebGL Globeです。みんながどこで生活し、コミットしているかが分かるのは面白いですよ。 アクセスするとWebGLを使って地球を描き出します。 マウスを使って回転できます。 Github Globeで見る限り、多いのはカリフォルニアやヨーロッパのようです。とは言え日本も負けておらず相当数のユーザが東京周辺に存在するようです。こういった可視化によってユーザがどこにいるか分かるのは面白そうです。 GitHubはプログラマーやデザイナーが殆どであり、オープンソースへの関わりが強い人たちが多いです。そういったユーザが世界レベルで見た時にどの地域にいるか分かると、グローバルでの求人に役立つのではないでしょうか。 また同じ仕組みを使
tlogはRuby製のオープンソース・ソフトウェア(GPL)です。 開発プロジェクトにおけるタイムトラッキング、チケットトラッキングは大事なことです。その履歴を管理するという点において、コードと一緒にGitで管理してしまおうというのがtlogです。 インストールしました。 GitリポジトリでトラッキングIDを作成します。 スタートでトラッキングを開始、ストップで終了します。 displayでトラッキングした情報が確認できるようになります。 tlogではコミット時のログにtlogのログを使えます。なのでログを残しておいても決してムダにはなりません。そしてポイントという値を設定しておくことでしきい値のように指定したフィルタリングも可能になります。 MOONGIFTはこう見る プロジェクトは流動的なもので、つい作業に追われてログをとるのを忘れがちです。しかし現在のプロジェクトは良くとも、次回に活
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード(または実行結果)を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
こんにちは、id:shiba_yu36です。「はてな教科書」更新のお知らせです。 今年のはてなインターンでは更に充実したインターンを経験してもらうため、http://developer.hatenastaff.com/entry/2012/04/11/104325 で公開されたテキストを刷新し、新しくiOSアプリ開発のドキュメントの追加などを行いました。そしてPerlやそれと連携したiOSアプリの開発に役立てばと思い、刷新した内容をgithub上で公開しました。 はてな教科書 これらのはてな教科書は、クリエイティブ・コモンズ 表示 - 非営利 - 継承 2.1 日本 ライセンスの下に提供されています。 はてな教科書をPerlでのウェブアプリケーション開発やWeb APIを利用したiOSアプリの勉強などに是非ご利用ください。何かご指摘などありましたら、GitHub上のissuesやpull
あるプログラミング言語で実際にWebAppを開発できるようになるまで、何が必要だろうか。言語仕様の習得は終えているとしよう。おそらく、最低限以下のような知識が必要だと思われる。とりあえずHaskellについて知っていることを書いた。 ← ここまで引用。 パッケージマネージャ Cabal 1.18を使おう。以上。 アプリケーションサーバ WSGIとかRackとかの流れでHaskellでもwebアプリのサーバインタフェースを統一化する動きがいくつかあった。その中で一番市民権を得たのはwaiと呼ばれるものだ。 ただ、残念なことにHaskell界でここ数年ずっと続いているI/Oストリーミングライブラリ戦争の決着がついていないため、統一化の状況は思わしくない。waiはconduitというライブラリに依存しているが、フレームワークによっては別のI/Oストリーミングライブラリを基盤にしている。 現状の3
ツール 個人的には Vim を好むようだが、Henneke 氏がこのプロジェクトで使用したツールについて以下のように述べてくれた。 「Eclipse内で検索するのは、びっくりするほど遅く煩わしいものです。」 「Xcodeのオーガナイザでドキュメントを検索するのは、腹立たしいほど遅いです。」彼は後に検索を速くする方法を発見した。 「Eclipse(および Androidプラグインの logcat 統合機能)のタグによるログの絞り込みはとても役に立ちます。」 「双方のIDEとも、コード補完機能は、本当に素晴らしいものです。」 「Xcodeのインターフェイス・ビルダは使い物になりません」 「Xcodeのインスツルメント機能は、プロファイリング、計測、デバッグに極めて有効です。」 「Androidエミュレータは完全なる時間の無駄です。その遅さときたら、ほとんど冗談のような代物です。私の開発サイクル
あるファイルに大量のコンフリクトが発生し解決が面倒なとき、パッチを使ってファイルに1コミットずつ変更を適用する方法を示す。この方法のメリットは: ファイルへの変更を1コミットずつ適用・コンフリクト解決することができる それぞれのコミットを適用する前に、コミットをパッチファイルの形で編集できる 注目するファイル以外への変更をいったん無視し、そのファイルに関係する変更に集中できる の3点である。複数コミットの変更が混ざった大量のコンフリクトマーカーを手作業で消すような状況に陥ったとき、この方法を使えばいくぶんかは楽にマージ作業を進められる。 概要 マージ中に特定のファイルに大量のコンフリクトが起きたら、マージを中止する。一時作業用ブランチを作り、そのファイルに1コミットずつパッチを当てて編集する。パッチを当て終わったらマージをやり直し、コンフリクト解決作業中に、コンフリクトしたファイルを一時作
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く