タグ

ブックマーク / capsctrl.que.jp (28)

  • 私の翻訳のやり方 - capsctrldays(2011-03-26)

    ■ 私の翻訳のやり方 秋から半年かけて2冊のの翻訳をしたので、そのやり方をまとめて書いてみる。翻訳の宣伝はまた後日。 1. テキストデータ化する まずは何はともあれテキストデータにする。 私は、テキストエディタと電子辞書を使って翻訳しているので、 テキストデータがなければ作業ができない。あまりよくない気もするけど、仕方ない。 元の原稿が最初からテキストデータであれば問題ないが、その他のフォーマットだと変換しなくてはいけない。HTMLなら簡単にできる。物理的な紙(原書)なら、OCRするのかなあ。よく知らないが、たぶんそうだろう。よくあるのがPDFで、割と面倒なのもPDFだ。PDFからテキストを抽出するツールはいろいろあるが、ちゃんと正確に抽出できるものは、たぶんない。そこそこうまくいくツールでも、アポストロフィーとかハイフネーションの扱いがうまくできない。が、抽出することが主な目的ではな

  • http://capsctrl.que.jp/kdmsnr/diary/20090810.html

  • Martin Fowler's Bliki in Japanese - ThoughtWorksでのRuby

    以下の文章は、Martin FowlerによるRuby at ThoughtWorksの日語訳である。 ThoughtWorksは、2006年から格的なプロジェクトRubyを使い始めた。2008年の終わりまでには、Rubyプロジェクトの数は41個になった。この経験から我々は何を学んだのか。QConの講演に備えて、私は調べてみることにした。ここでは、Rubyの生産性、スピード、保守性など、よくある質問に対する現時点での我々の考えについて述べていく。現時点での我々の結論としては、Rubyは十分に使えるプラットフォームであり、様々な形態のアプリケーションに利用することを真剣に考慮すべきである、というものだ。特に、Ruby on Rails を利用したWebアプリケーションにおいてはそうである。最後に、Active Record のテスティングに対する考えなど、技術的な教訓についても触れる。

  • Martin Fowler's Bliki in Japanese - パーサー恐怖症

    http://martinfowler.com/bliki/ParserFear.html 2008/5/20 最近はドメイン特化言語についてみんなと話すことが多いのだが、外部DSLのことになると、だいたい決まって「パーサーを書くのは難しいよ」とか言われる。 外部DSLの構文としてXMLがよく使われるのは、「パーサーが無料で手に入るから」だったりする。 でも、パーサーを書くのは思ったよりも簡単なことなのだよ。いやマジで。 XMLのパースができれば簡単なことだよ。 証拠だってあるのだ……つっても、私の話だけど。 でもでも、十分に証拠となるものだから引き合いに出そうと思う。 現在執筆中の書籍に入門的な例を書いたんだけど、 簡単なステートマシンを作るのに外部DSLを2つ作ったのだ。 1つは(ゲートウェイドラッグ*1として)XMLを使ったもので、もう1つはカスタム構文をAntlrを使ってパースした

    youpy
    youpy 2008/05/24
    パーサージェネレータ Antlr
  • Martin Fowler's Bliki in Japanese - デュプレックス本

    http://martinfowler.com/bliki/DuplexBook.html 2007/6/13 先週、私のシグニチャシリーズの新刊が出た。 Gerard Meszarosによる『xUnit Test Patterns』だ。 Gerardとは数年間この件についてやり取りをしてきたので、 内容についてはよく知っているのだが、 実際のを見てかなりショックを受けた。 なにこの厚さ。883ページて。 シグニチャシリーズのなかでダントツの厚さだ。 私は厚いがあまり好きじゃない。 『UMLモデリングのエッセンス』が薄いのには誇りを持っているくらいだ。 厚いは怖い。一体いつ読めるっつーんだ? だが、『xUnit Test Patterns』は見た目ほど怖くはない。 なぜなら、これは2冊のが1冊になったものだからだ。 私が『PofEAA』で使ったやり方でもある。 1冊目は物語(nar

    youpy
    youpy 2007/06/16
  • capsctrl - プロフェッショナルの条件

    生産性をいかにして高めるか 資技術は生産手段にすぎない 「より賢く」働くことが生産性向上の唯一の要因 ただし、肉体労働と知的労働の場合とでは意味がちがってくる 「何が目的か。何を実現しようとしているか。なぜそれを行うか」を問う 仕事の再定義 仕事の種類(成果の判断) 質のみ 質と量 成果が肉体労働と同様(質は制約条件) 自らが教えるときにもっともよく学ぶ なぜ成果があがらないのか ものごとをなす = 成果をあげること だけど知的労働において、成果とは簡単には上げられない 従来の肉体労働における「成果」とは違う 知的労働で生まれる「成果物(知識、アイデア、情報)」はそれ単体では役に立たない 自らの成果物を、他人に供給する必要がある 成果を求められるが、成果をあげられない環境にいる 時間は他人にとられる 日常業務に追われつづける 組織で働いている 自分の成果を使うのは、組織上で上から横のひ

    youpy
    youpy 2007/05/13
  • Martin Fowler's Bliki in Japanese - 朝会のパターン:立ってるだけじゃないよ

    朝会(デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2)を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく

    youpy
    youpy 2007/04/02
    朝立ち
  • Martin Fowler's Bliki in Japanese - トランザクションレス

    http://martinfowler.com/bliki/Transactionless.html 2007/3/18 (更新:Bill Caputoからも経験談をいただいた) 数年前にeBayで働く友人たちと話していたときのことだ。 大規模サイトで使われる技術の話を聞くのはいつも楽しいが、特に興味深かったのが、eBayでは滅多にデータベーストランザクションを使用しないという話だった。 トランザクションがない環境というのは驚くべきことではないだろうか。 データベースを扱うときにトランザクションを使うのはごくごく一般的なことだ。 多くの人にとって(私もそうだが)トランザクションはデータベースを使う利点のひとつだ。 eBayがトランザクションを使わないのは、あのような規模ではパフォーマンスに影響が出てしまうからだというものだった。 eBayではデータをいくつもの物理的データベースにパーテショ

    youpy
    youpy 2007/03/23
  • ちょwww頭よすぎる - capsctrldays (2007-01-23)

    youpy
    youpy 2007/01/24
  • Martin Fowler's Bliki in Japanese - ヒューメイン・インタフェース

    http://martinfowler.com/bliki/HumaneInterface.html Ruby界隈で「ヒューメイン・インタフェース」という言葉を何度も耳にした。 この言葉は、クラスのインタフェースを記述する際のrubyistたちの姿勢(attitude)の一部を表したものである。 APIの設計については、2つの異なる考え方を対比していくと面白い(もうひとつは最小インタフェースである)。 ヒューメイン・インタフェースの肝は、みんなが何をやりたいかを見つけ出し、何度も起きることを簡単に行えるためのインタフェースを設計することだ。 最小インタフェースとの明確な違いは、ヒューメイン・インタフェースの方が大きくなる傾向があるという点だ。ただ、ヒューメイン・インタフェースの設計者はインタフェースが大きくなることをそれほど気にしてはいない。 以上のことは、ヒューメイン・インタフェースで設

    youpy
    youpy 2006/11/23
  • http://capsctrl.que.jp/kdmsnr/diary/20061026.html

    youpy
    youpy 2006/11/06
  • Martin Fowler's Bliki in Japanese - 守破離

    http://martinfowler.com/bliki/ShuHaRi.html 「守破離」とは技術を学ぶ際の考え方である。その名は合気道に由来する。 Alistair Cockburnがソフトウェア開発の技術・方法論を学ぶ際の考え方として紹介した。 これは、知識を習得するには三つの段階を経るという考えである。 守:最初の段階では、学習者は師の教えを正確に模写する。理論についてあれこれ考える前に、その作法に集中する。作法が複数ある場合でも、師の教えをただ忠実に守る。 破:この段階では、学習者は新しいことに手を出す。基的な実践を身に着けたなら、技術の裏にある原則や理論を学んでいく。また、他の師からも学び、得たものを自身の実践に採り入れていく。 離:この段階では、学習者は、自身の実践を通じて、他者から学んでいく。自身の手法を生み出し、学んだことを自身の環境に適応させていく。 Alista

    youpy
    youpy 2006/10/12
  • Martin Fowler's Bliki in Japanese - アジャイルの押しつけ

    http://martinfowler.com/bliki/AgileImposition.html 2006/10/2 (更新:XPメーリングリストで有益な議論があった。特にKentの返信は読んでおくべきだろう。議論を有益な方向に導いてくれた。) アジャイルアライアンスのボードメンバによると、アジャイル方法論は「キャズムを超えた」そうだ。 つまり、より多くの人に知れ渡ったということだろう。 これはアジャイルの利点だが、同時に問題も起きている。 方法論や設計手法が単なる流行になってしまったために、流行にのみ注目して、使用したり、教えたりする人が多い。 また、アジャイル設立者の原則とは正反対のことをして、アジャイルの名を汚しているという報告もある。 Webを巡回していると、ある開発チームが上層部からアジャイル方法論を押しつけられているというコメントを見つけた。 チームにプロセスを押しつけると

    youpy
    youpy 2006/10/07
  • Martin Fowler's Bliki in Japanese - ドメイン特化言語

    youpy
    youpy 2006/09/05
  • Martin Fowler's Bliki in Japanese - 顧客親近性

    youpy
    youpy 2006/09/05
  • Martin Fowler's Bliki in Japanese - エンタープライズRails

    http://www.martinfowler.com/bliki/EnterpriseRails.html Railsのコミュニティでは「エンタープライズ」という言葉がダーティーワードになりつつある。 多くの人にとってRailsフレームワークとは、貪欲にシンプルさを備えたものであり、複雑になり過ぎた「エンタープライジー」なフレームワークへのアンチテーゼなのだ。 先ごろ開かれたRailsConfでは、オープニングキーノートにおいてPragDaveが「Railsでは解決できない事項」に焦点をあてていた。 その中にはエンタープライジーなことも含まれていた。 たとえば、複合キーを持つような、様々なデータ構造を扱うことが必要だというのだ。 これに対するDHHの反応は、この上なく痛烈な拒絶であった。Wired誌*1の表紙になった画像をうまく編集して、DHHは自らをソフトウェア界のネオ(救世主)として

    youpy
    youpy 2006/07/17
  • Martin Fowler's Bliki in Japanese - Rubyの評価

    http://martinfowler.com/bliki/EvaluatingRuby.html ここの読者なら世の中でRubyが騒ぎになっていることをご存知だと思う。 特にRailsというWebアプリケーションフレームワークは大騒ぎだ。 Railsはプログラミングの未来を表したものだという人もいれば、 危険な流れだという人もいる。 私がRubyに触れたのは数年前のことだ。 達人たちにすすめられて、興味を持つようになった。 そしてすぐにお気に入りのスクリプト言語となった。 そのうちRubyを使ってこのサイトのプロダクトを作るようになった。 たとえばこのblikiがそうだ。 諸君、私はRubyが大好きだ。 ただ、私がRubyを好きなことと、Rubyをクライアントのために使うかというのは別問題だ。 クライアントのために使えるかどうかは、Rubyの機能を評価することによって判断できるだろう。

    youpy
    youpy 2006/05/12
  • http://capsctrl.que.jp/kdmsnr/diary/20060124.html

    youpy
    youpy 2006/02/01
    ジャケがイカす
  • Martin Fowler's Bliki in Japanese - クロージャ

    http://martinfowler.com/bliki/Closure.html 動的言語に興味がでてくると、 クロージャやブロックと呼ばれる概念に出会うと思います。 C/C++/Java/C# などクロージャを持たない言語をご使用の方は、 どういったものなのかご存知ないかもしれません。 ここでは簡単にクロージャについて説明します。 クロージャを持った素晴らしい言語を使ったことある方にとっては、 あまり面白くない話かもしれません。 クロージャは長年使用されてきました。 私が最初に出会ったのは、おそらく Smalltalk だったと思います。 Smalltalk ではブロックと呼んでいました。 Lisp ではクロージャを多用しています。 Ruby でもクロージャが提供されています――多くの rubyist がスクリプト言語に Ruby を選ぶのはこのためです。 基的にクロージャとは、ブ

    youpy
    youpy 2006/01/17
  • Martin Fowler's Bliki in Japanese - Slimp3

    youpy
    youpy 2006/01/17