私の翻訳のやり方 - capsctrldays(2011-03-26)
■ 私の翻訳のやり方 秋から半年かけて2冊の本の翻訳をしたので、そのやり方をまとめて書いてみる。翻訳本の宣伝はまた後日。 1. テキストデータ化する まずは何はともあれテキストデータにする。 私は、テキストエディタと電子辞書を使って翻訳しているので、 テキストデータがなければ作業ができない。あまりよくない気もするけど、仕方ない。 元の原稿が最初からテキストデータであれば問題ないが、その他のフォーマットだと変換しなくてはいけない。HTMLなら簡単にできる。物理的な紙（原書）なら、OCRするのかなあ。よく知らないが、たぶんそうだろう。よくあるのがPDFで、割と面倒なのもPDFだ。PDFからテキストを抽出するツールはいろいろあるが、ちゃんと正確に抽出できるものは、たぶんない。そこそこうまくいくツールでも、アポストロフィーとかハイフネーションの扱いがうまくできない。が、抽出することが主な目的ではな
Martin Fowler's Bliki in Japanese - ユースケースとストーリー
http://www.martinfowler.com/bliki/UseCasesAndStories.html ユースケースとXPのストーリーとの違いは？ これはよくある質問だが、なかなか答えがまとまらない質問でもある。XPコミュニティの人々は、ストーリーはユースケースを簡単にしたものだと捉えている。私も以前はそう思っていたが、今は別の見方をしている。 ユースケースとストーリーは、どちらも要求をまとめる（organize）方法という意味で一致している。違うのは、まとめる「目的」である。 ユースケースは、ユーザーがシステムにどう携わるか、どう使うか、といったナレーティブ（narrative）を形作るために要求をまとめていく。したがってユースケースは、ユーザーのゴールとシステムとの相互作用がどれだけそのゴールを満たすかに焦点があてられる。 一方、XPストーリー（やよく機能などと呼ばれるもの
Martin Fowler's Bliki in Japanese - 対話的ストーリー
http://martinfowler.com/bliki/ConversationalStories.html 2010/2/4 アジャイル方法論に対するよくある誤解の話をしよう。 アジャイル方法論は、開発のなかでユーザーストーリーを作り、変化させていくことに重点を置いている。 よくある誤解とは、プロダクトオーナー（あるいはビジネスアナリスト）がユーザーストーリーを作り、それを開発者に差し出して実装してもらうというものだ。 この考えでは、流れはプロダクトオーナーから開発者に向かっている。 プロダクトオーナーの責任は何が必要かを決めることであり、開発者の責任はどうやって実現するかを決めることだというのだ。 この考えは、能力に沿った責任の分割をその理由としてる。 プロダクトオーナーはソフトウェアの目的であるビジネスを知っており、何を行うべきかを知っている。 一方、開発者は技術とその方法を知っ
Martin Fowler's Bliki in Japanese - ソフトウェアとオバマの勝利
以下の文章は、Martin FowlerによるSoftware and Obama's Victoryの日本語訳である。 2008年の大統領選挙におけるバラク・オバマの勝利の裏には、ソフトウェアの重要な貢献があった――インターネットの利用である。しかし、最も興味深いのは、ソフトウェアの進歩とオバマ陣営の組織の発達との相互作用だった。 最終更新日：2009/7/30 本稿は、ザック・エクスレイと私のQCon London 2008での基調講演を基にしている。 目次 インターネットキャンペーンの目覚め キャンペーンの組織ダイナミクスの変化 有権者について知る 地方組織の再考 Neighbor to Neighbor（隣人の隣人） 巨大なスパム銃 ビデオ 今後の展望 インターネットがなければ、バラク・オバマは大統領ではなかったでしょう。 --Arianna Huffington 2008年の大
capsctrldays - オブジェクト倶楽部２００９夏イベント , 凡人が最強チームに変わる魔法の営業ミーティング(佐藤 昌弘)
1 [セミナー] オブジェクト倶楽部２００９夏イベント アジャイル開発方法論の現状、課題、未来 "海外では独立コンサルタントが産業界の知的伝搬を行っている。" テスト駆動開発者は三周目で死ぬのか "創発的設計とピラミッド"の説明。いろいろ文句言ってくる奴への説明っぽい。巨人の肩に乗りまくり。日本人の巨人（著者）はいないのかな。 ソフトウェア開発に自働化を導入して、人の力を発揮しよう。 TPSはどうでもいいなあ。"製品コードに安全装置" 鬼に金棒：人文系スキルを身に付けよう ドラッカーが好きらしい 出版業における自動化の事例報告 "ccでコミットしたらpdf生成"。ぜんぜん関係ないけど、http://twitter.com/ctakao がカオス。 格差社会を生き延びるためのiPhoneアプリ開発 iYamatoってのがあるらしい。 JSpecの紹介 何が嬉しいのかわからないけど、"文字列置
翻訳 - 次のアジャイルソフトウェアプロジェクトに使える10の契約
以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 次のアジャイルソフトウェアプロジェクトに使える10の契約 2009/4/29 by peterstev ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。 契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。 ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。 それでは、アジャイルプ
capsctrldays - erase_render_results で render をキャンセル , 人月の価格調査 , 給与とコストで人月計算 , あなたの会社を潰さない最後の戦略..
1 erase_render_results で render をキャンセル ビジネスロジックが複雑になってきたのでafter_filterでいろいろフィルタリングするようにして、問題があったら RecordNotFound を raise するようにしたところ、render2回やっちゃダメって言われたので、「erase_render_results」をつけた。こんなのあったんだーというメモ。 class ApplicationController < ActionController::Base rescue_from ActiveRecord::RecordNotFound, :with => :record_not_found protected def record_not_found erase_render_results # コレ render :file => File.j
capsctrldays - ビジョナリー・カンパニーを改めて読んでみたのでメモを書き散らかす
1 [本] ビジョナリー・カンパニーを改めて読んでみたのでメモを書き散らかす いろいろ思うところがあって、一連の『 ビジョナリー・カンパニー』作品を改めて読んだんですけども、個人的にはやっぱり違和感があるなーという印象。 曰く、企業には基本理念やら基本目的やらが重要で、バスに乗せる人を選ぶのが重要で、システム作り（時計作り）が重要で、あげくはカルト文化を形成するのであーるとかなんとか。カルトといえば一番分かりやすいのはディズニー社ですね。キャストだのステージインだのアウトだの特別の用語を使ったり、独自のトレーニング機関があったり、どう見てもマッチョです本当に〜〜な従業員しかいない。企業文化に合わない奴は辞めればいい（辞めさせればいい）し、そもそも一緒のバスには乗せないことが重要。 そういった基本理念を守ると同時に、進歩を促すAND思考（陰陽の模様）も重要で、熱意を持って取り組むBHAGを設
capsctrldays - 会社を作るときに参考にした本
1 [本] 会社を作るときに参考にした本 すぐに使える!自分でできる株式会社設立(北村 恵) 会社法の説明から設立後の届出まで一通り載ってる。とりあえずこれだけで十分。 不安だったら（あるいは面倒だったら）、司法書士に相談するといい。 平均すると30万円くらいだけど、 電子定款を使って25万円くらいでやってくれるところがあるので、 そゆとこを選ぶといい。 新会社法対応!起業したらまっさきに読む経理の本 (アスカビジネス)(笠原 清明) 設立のところ以外にも社会保険やら労災保険やら給与の支払いやらが載ってる。 あと、簿記3級程度の仕訳の説明とか。こないだまで顧問税理士がいなかったのでかなり重宝してた。とりあえず税理士は早く見つけよう。
capsctrl - T字形ER手法（TM）
お絵かき（構文論）のみに終始している。 その人の価値観で異なるお絵かきをしている。 30年前のインデックス（によるファイルアクセス）の概念でデータベース設計を行っている。 1つの手法を使って、「事業解析」「データ構造設計」「プログラムのI/O化」の3つを同時に実現する。 ここでモデル（データ構造）とは 指示規則（意味論）＋生成規則（構文論） TM構文論 TM'（ダッシュ）意味論 TMの限界 コード体系が悪すぎたらモデルにも影響してしまう。 「プログラムのI/O化」といっても良くて70%の実現。 モデルはプログラムに対して強制力がない NESTED-IFが出たらプログラムを中止させること NULLの存在を認めている コッドの関係モデルは、ドメインの直積でタプルのセットを構築する。 その場合、nullの入ったタプルが存在することになってしまう。 nullの正確な意味は、不定(undefined
JavaからRubyへ ―マネージャのための実践移行ガイド(Bruce A. Tate/角谷 信太郎) - capsctrldays(2007-04-20)
1 [本] JavaからRubyへ ―マネージャのための実践移行ガイド(Bruce A. Tate) 真の本文といわれる訳者あとがきを読んで、初めて角谷さんに会ったときのことを思い出した。「俺、今の会社辞めたらアジャイルやるんだ……」そう言って、渋谷のジョナサンで死亡フラグを立てていた。その言葉の意味するところが、ジョナサン・ジョースターであり、アジャイル言語Rubyであったことは、後の角谷さんの活躍を見れば明らかである。 本書で述べられていることと角谷さんの軌跡は、少なからず一致している（と感じる）。 訳者としてこれほど相応しい人物はいないのではないか。 翻訳レビューに参加させてもらったこともあり、早いうちから原稿を目にすることができたのだけど、正直、具体的な内容についてはよく理解できていない（共感できていない）。だけど、「From A To B」という図式は、自分も含め、すべての人に
Martin Fowler's Bliki 顧客親近性
http://www.martinfowler.com/bliki/CustomerAffinity.html 2006/7/28 トップクラスのエンタープライズソフトウェア開発者になるために必要なものは何かという話になると、だいたいフレームワークや言語の知識や複雑なアルゴリズムやデータ構造を理解する能力だろうという方向に話が進む。 だが、プログラマや開発チームにとって最も重要なのは、私が「顧客親近性」と呼んでいるものだ。 これは、ソフトウェアが対処すべきビジネスの問題、そして、そのビジネスの世界に生きている人々に対する関心および親密さを表すものである。 顧客親近性には様々な側面がある。 まずは、ビジネスへの関心である。ビジネスのプロセス、そしてビジネスルールへの関心だ。 私はこれまでに携わってきたドメイン――医療、金融派生商品、給与管理、リース業務――に常に魅了されてきた。これらは非常に
RDT - Ruby Development Tools
RDT - Ruby Development Toolsのドキュメント翻訳Wikiです。どなたでも編集が可能です。成果物のライセンスは、GNU Free Documentation License に準じます。 現在は、Ruby Development Tools Documentation - 0.5.0 の翻訳を行っています。 そろそろ 0.6.0 の翻訳をしないと。 mixi内にコミュニティがあったりします。 RDTへようこそ RDTは、オープンソースのRuby IDEです。 Eclipseプラットフォーム上で動作します。 サポートしている機能は、 シンタックス強調表示、 即時シンタックスチェック、 グラフィカルアウトライン、 Test::Unit ビューワー／ランナー、 Rubyアプリケーション起動、 コード・アシスト（コンテンツ・アシスト）、 ソース・フォーマット、 Rubyデバ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://capsctrl.que.jp/kdmsnr/diary/20080505.html
http://capsctrl.que.jp/kdmsnr/diary/20080412.html
http://capsctrl.que.jp/kdmsnr/wiki/refactoring/?RefactoringsInAlphabeticalOrder