Centralize your team’s knowledge, sync with your codebase, and create beautiful documentation your customers and teams will love
![GitBook – Knowledge management for technical teams](https://cdn-ak-scissors.b.st-hatena.com/image/square/309286d783c8825cf822cca033962f22cc42b1b5/height=288;version=1;width=512/https%3A%2F%2Fframerusercontent.com%2Fimages%2FzlGUDsxOhDseDbUkyYaNkpCbM.png)
はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu
Joel Spolsky / 青木靖 訳 2010年3月17日 水曜 しばらく前に、ジェフと私はStack Overflowポッドキャストにエリック・シンクを迎え、バージョン管理について騒がしく議論し、とくにトレンディな分散バージョン管理システムであるMercurialやGitのことを取り上げた。 そのポッドキャストで私はこんなことを言った。「私に言わせれば、ブランチやマージが簡単にできるようになるというのは、単に同僚たちがもっとブランチやマージをするようになるということで、余計混乱させられるだけのことだよ」 わかると思うけど、あのポッドキャストは前もって入念に準備したりはしていない。単に2、3人集まって、いい加減なおしゃべりをしているだけだ。そのため、しばしば我々の主張する内容が、少し専門的な言い方をするなら、「ちげーよ」ということになる。間違っているのはたいてい細かい部分か趣旨のどちら
(注:2017/02/06、いただいたフィードバックを元に翻訳を修正いたしました。修正内容については、 こちら を参照ください。) Dependency HellはNP完全ですが、この状況から脱却できるかもしれません。 パッケージにおけるバージョン選択の問題とは、完全である(全ての依存関係を満たしている)かつ互換性のある(互換性のない2つのパッケージが選択されていない)トップレベルパッケージPをビルドするために使われる依存関係の集合を見つけることです。ただし、菱形依存問題があるので、このようなセットは存在しない可能性があります。菱形依存問題とは、AはBとCが必要、BはDのバージョン2ではなくバージョン1が必要、CはDのバージョン1ではなくバージョン2が必要といったような問題のことです。この場合、Dの両方のバージョンを選択することはできないため、Aをビルドすることができないわけです。 パッケ
アルゴリズムはどれも異なる計算量を持ちます。Nサイズの入力が与えられたとすると、それらは以下のように表現されます: 名前 早さ 概要 数式 例
計算複雑性の話の中で、P、NP、NP完全、NP困難というキーワードが登場する。 それぞれの違いを、字面だけから判断するのは、少し無理そう。 それで、詳しい説明を Wikipedia に求めると・・・。 ・P(Wikipedai) ・NP(Wikipedai) ・NP完全(Wikipedai) ・NP困難(Wikipedai) 大学などで正確な定義を学習していない場合には、軽く絶望することになる。 そこで、厳密ではないことをあらかじめ断ったうえで、これらを簡単に説明してみる。 (証明されていないが、前提としてNP≠P とする。これが証明できたら100万ドルもらえる。) まず、それぞれの関係は下図のように表すことができる。 図では、上のものほど難しい問題で「P≦NP≦NP完全≦NP困難」と言うことができる。 さらに次のことが言える。 ・ P は現実的な時間で解を求めることができる問題。 ・ N
Google、オンプレミス版のGoogle Earth、「Google Earth Enterprise」のオープンソース化を発表。独自のバーチャル地球儀を構築可能に Googleは、オンプレミス版のGoogle Earthとして以前商品として販売していた「Google Earth Enterprise」を、今年3月にApache2ライセンスでオープンソースとして公開することを発表しました。 Google Earth Enterpriseは、Google Earth用のデータベース構築ツール「Google Earth Fusion」、データ配信用のサーバである「Google Earth Server」、データベースの一部を切り出してオフライン環境でも持ち運ぶことができる「Google Earth Enterprise Portable Server」から構成されます。 クライアントとしては
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く