【翻訳】Gitをボトムアップから理解する
John Wiegleyさんの "Git from the bottom up" を翻訳しました。 元PDFはこちらからダウンロードできます： http://newartisans.com/2008/04/git-from-the-bottom-up/ 元記事のライセンスがクリエイティブコモンズのBY-SAであったため、この翻訳もBY-SAとなります。 ライセンスを守って自由にご利用ください。（詳しくは記事内の最初にも書いてあります） 翻訳ミスの指摘や改善の提案等があればブログコメントやTwitter(@oshow)などで遠慮なくどうぞ。 Git をボトムアップから理解する Wed, 2 Dec 2009 by John Wiegley 私が Git を理解しようと調査した時、高級なコマンドの視点から眺めるよりボトムアップ式に理解することが役立った。そしてボトムアップ視点で見る Git が
Japanese character recognition
Japanese character recognition - beta >> 日本語ページへ Since: Oct. 1, 2008 Updated: Jan 13, 2010 This server recognizes Japanese characters in a document image using OCRopus and NHocr. The server can handle only machine-printed, horizontal text lines. Dirts and rules (lines) around characters may cause recognition failure. The recognition performance is still limited. Do not send any confidential images
Amazonほしい物リストを一緒に編集しましょう
商品に購入済みのマークを付けるには、以下の情報を入力します。 このリストの所有者は、自分自身で購入を試みない限り、その商品が購入されたことが分かりません。
『アメーバで利用しているLuceneのMergePolicyについて』
こんにちは。アメーバで検索を担当しているYASUDAです。 今日は、アメーバで利用しているオープンソースの検索エンジンであるLucene/Solr の新機能の一つをご紹介します。いつもLucene/Solrの恩恵を受けているので、少しでも普及に繋がると嬉しいです。 紹介するのはLucene 3.2以降のバージョンで利用可能となるTieredMergePolicyです。 以下に、LuceneにおけるインデックスのSegment構成、MergePolicyの概要、TieredMergePolicyの特徴とアメーバの対応について記述します。 ■ Luceneにおける転置インデックスのSegment構成 Luceneの転置インデックスは、各々が独立したSegmentという単位で構成されており、ドキュメントの追加分をflushする際、新しい世代番号を付けたSegmentを生成していきます（図1）。
PRML 4.1 の最小二乗法＆フィッシャーの線形判別を試してみた - 木曜不足
社内でやってる PRML 読書会が4章に入って、Fisher の線形判別分析(LDA)とかをちょうどやっつけたところ。 4.1.5 で Fisher's LDA と「最小二乗との関連」をわざわざ述べているのはどうして？ というあたりで、最小二乗と互換性があるということはそれだけで理論的裏付けになるし(分散最小化)、あるいは(もしも)確率化したいときに加法性のガウスノイズを想定することもできたりするよね、的な話をしたりしてた(的外れなら乞うツッコミ)。 で、ぶっちゃけ単純な最小二乗と Fisher's LDA だと具体的にどれくらい違うんだろうねえ、という話になって、そりゃあデータ数の多いクラスタに決定面が寄るんだろうねえ、と推測。 それくらいなら簡単に確かめられるんだから、ちょっこり R でスクリプトを書いてみた。 library(MASS); blue <- 50 red <- 100
TDDプロセスデータ収集 - Wiki - Redmine
なるべく自信のある言語で行ってください(複数言語可)。 記録方法¶ 記録にはgit-nowを利用します。 git-nowとは神速さん発案、川西さん実装の、テンポラリ用コミットを作成するための非標準コマンドです。 今回の記録への利用を考えた理由としては、git nowはTDD との相性が良いためです。 インストール方法や使い方についてはこちら を参照ください。 作業順序例としては、 git init 各種作業(テスト作成や実装) テスト実行 git now 2.～4.を繰り返す １つの課題が終了した時点でタグを打つ git now --rebaseでゴミ(タイプミスなど)の除去 2.～7.を繰り返して各課題について実装を行う のような感じにと思います(テスト実行直前or直後にgit nowされていれば基本的に問題ないです)。 注意点としては、 テスト実行ごとにテスト結果をXMLフォーマットで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
