はてなブックマーク

Loading... Page: / folder_open Download share

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

4〜6月は研修が殺到する時期でして、おかげさまでいろいろな会社さんからお声がけいただいているわけですが……本当は研修とかしなくてもですね、社内でやったほうがいいと思うんですよ（でも、私の仕事がなくなる!!）。 私の仕事がなくなる……ことはさておき（お仕事お待ちしています!!）、人事の方からも社内講師を増やしたいという話をよく聞きます。で、ワークショップってどうやって作ればいいんですか？という質問につながるわけですけども、そんなの私が知りたいですよ。とはいえ、参考にしている作り方がありまして、あまり知られてないみたいなので紹介しますね。「4C」というフレームワークです。でも、アジャイルコーチ界隈では有名な手法みたいですよ。 元ネタはこの本ですね。詳しく知りたい方はこちらを読んでください。 「4C」というのは、 Connections Concepts Concrete Practice Co

以下の文章は、Edd Dumbillによる「Ruby on Rails: An Interview with David Heinemeier Hansson」の日本語訳である。 O’Reilly Media, Inc.の許可を得て、ここに掲載する。 by Edd Dumbill 08/30/2005 プログラミングの世界で誰も無視できない最新のスタープラットフォーム——Ruby on Rails。そして、そのRailsの作者であるDavid Heinemeier Hansson。彼は、今年のOSCONで観衆を大興奮の渦に巻き込んだ。10月にはアムステルダムで開かれるEuropean O’Reilly Opensource Conventionで基調講演を行う予定だ。 Heinemeier Hanssonはデンマークのコペンハーゲンに住んでいる。彼は、革新的な企業37signalsのパート

2016-04-13 Wed 東京工業大学での企画いろいろ あまり外向きには話していませんでしたが、昨年から東京工業大学で特任講師をしています。「エンジニアリングデザインプロジェクト」というデザイン思考とモノづくりを一体化させたアントレプレナー教育の講座が担当です。メインの先生は別にいらっしゃいまして、私はソフトウェア開発で困ったことがあれば手伝ったり、リーンスタートアップやアジャイル開発で使えそうなプラクティスがあったらコッソリ導入したり、みんなにSlackを使ってもらったりと、企業のクライアント先でもやってるようなことを大学でもやってる感じです。とはいっても、みんな優秀なので手伝うことなんかそんなになくて、基本的には温かく見守る役ですね。 それとは別に、今年から予算をいただきまして、いくつか企画を担当することになりました。現時点で公開できるのは、以下の2つです。 1. TdX講演会シリ

角 征典（かど まさのり）@kdmsnr ワイクル株式会社 代表取締役、東京工業大学 環境・社会理工学院 特任講師。アジャイル開発やリーンスタートアップに関する書籍の翻訳を数多く担当し、それらの手法を企業に導入するコンサルティングに従事。主な訳書に『リーダブルコード』（オライリー・ジャパン）、『エクストリームプログラミング』（オーム社）、『Clean Craftsmanship』（KADOKAWA）、『モダン・ソフトウェアエンジニアリング』（翔泳社）、『図解リーンスタートアップ成長戦略』（日経BP社）、『プロダクトリサーチ・ルールズ』（BNN）、共著書に『エンジニアのためのデザイン思考入門』（翔泳社）がある。大学では、企業と連携したPBL型講義「エンジニアリングデザインプロジェクト」を共同で担当。 Mail | Bluesky | Twitter | Facebook | Github R

以下の文章は、Kent Beck、Ward Cunninghamによる「Using Pattern Languages for Object-Oriented Programs」の日本語訳である。Ward Cunningham氏の許可を得て、ここに掲載する。 Kent Beck, Apple Computer, Inc. Ward Cunningham, Tektronix, Inc. Technical Report No. CR-87-43 September 17, 1987 Submitted to the OOPSLA-87 workshop on the Specification and Design for Object-Oriented Programming. 概要 オブジェクト指向プログラミングへのパターンランゲージの適合について概説する。ウィンドウベースのユーザーイ

2009/4/29 by peterstev 以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 ソフトウェア開発プロジェクトの最初の頃というのは、顧客であれサプライヤ であれ、口約束だけでいろんな仕事をやらなくちゃいけない。契約書とは、言っ てしまえば、競技のルールがだらだらと書かれてあるものにすぎない。ルール が正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げ てしまう。それでは、アジャイルプロジェクトに使える競技ルールにはどんな ものがあるのだろうか？そして、最も適したルー

ちょいちょい小ネタを挟んでくるので大変読みにくいけど……それでもわかりやすい。上の本で概要をつかんでから、IDEOの人たちと一緒にうんぬんという昔話のところは読み流すとよさそう。 哲学（望むこと）→ビジョン（やりたいこと）の構築 技術の棚卸し（実現可能性の拡大）とフィールドワーク（経験の拡大） ※このときに5モデル分析 + ペルソナとシナリオの構築も含めてる……ちょっとプロセスの区切りが雑だと思う。 コンセプト→モデルの構築（作りながらコンセプトメイキング） デザイン（コンセプトを実際に使えるようにプロトタイピング） 実証（実際に制作して、試してもらう） ビジネスモデル構築 オペレーション（運営方法）

Team Geek ―Googleのギークたちはいかにしてチームを作るのか著者: Brian W. Fitzpatrick, Ben Collins-Sussman 出版日: 2013-07-20 出版社/メーカー: オライリージャパン カテゴリ: Book ギークが思い描く理想のチーム像は、自己啓発のそれとよく似ている。ソフトウェア開発はチームスポーツである。HRT（謙虚・尊敬・信頼）の原則が大切。有害な人に対処するには？など。

Agile42に「Five books every ScrumMaster should read」というエントリがありました。 タイトルだけ引用しておきます。 Mike Cohn, Succeeding with Agile Software Development Lyssa Adkins, Coaching Agile Teams Derby and Larsen, Agile Retrospectives: Making Good Teams Great Geoff Watts, Scrum Mastery: From Good To Great Servant-Leadership Sam Kaner, Facilitator’s Guide to Participatory Decision-Making (3)の『アジャイルレトロスペクティブズ』以外は翻訳がありませんね。もし