タグ

t-wadaに関するmanholeのブックマーク (37)

  • 【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ

    システム開発の世界において「技術的負債Technical Debt)」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham (ウォード・カニンガム)です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました("Shipping first time code is like going into debt")。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開

    【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ
    manhole
    manhole 2020/09/05
    “負債の返済手段はリファクタリングであり、リファクタリングの目的は自分たちのドメイン理解と現時点のプログラムの乖離の解消です。”
  • 27. 論理削除とは何か?どのような解法があるのか? w/ twada | fukabori.fm

    話したネタ 論理削除とはそもそも何か? 物理削除とは? なぜ、論理削除が生まれてくるのか? SQLアンチパターン 幻の第26章「とりあえず削除フラグ」 理由1: 心理的なハードルの高さ、怖さがある 理由2: 削除したデータを検索対象に入れたい場合がある 理由3: ログとしての用途 理由4: 誤操作をすぐに戻したい アンチパターンとは何か? なぜ、論理削除はアンチパターンとして捉えられるのか? 全てのSQL文のWHERE句に削除フラグが必ず入る LIMIT 1などが蔓延していく 論理削除に気づくきっかけは何か? テーブル設計や、規約から気づく 論理削除というアンチパターンをどのように解いていくか? 論理削除という概念は世の中にまずなく、お客様は論理削除という言葉を使っていない 要件をどのように設計すればいいのか? ORMの論理削除プラグインはあまり良くない 状態遷移として捉える方法 Soft

    27. 論理削除とは何か?どのような解法があるのか? w/ twada | fukabori.fm
    manhole
    manhole 2020/03/04
    さすがの聴きごたえ。ところでUMLの状態遷移図って「かつて栄えた文明があった」みたいな扱いなの...?
  • 品質を犠牲にすることでソフトウェア開発のスピードは上がるのか? 和田卓人氏による 「質とスピード」(後編)。デブサミ2020

    品質を犠牲にすることでソフトウェア開発のスピードは上がるのか? 和田卓人氏による 「質とスピード」(後編)。デブサミ2020 ソフトウェア開発のプロジェクトにおいて、リリースに間に合わせるために開発スピードを優先させ、ひとまず質には目をつぶろう、という判断がしばしば行われることがあります。 はたしてその判断は正しいのでしょうか。2020年2月13日と14日の2日間、都内で行われたイベント「Developers Summit 2020」(デブサミ2020)」の和田卓人氏のセッション「質とスピード」は、これを深く考察したものでした。 記事は前編と後編に分かれています。いまお読みの記事は後編です。 品質とコストのトレードオフ関係も一概 ここでちょっと視点を変えて、Philip Crosbyさんの「Quality is Free」を見てみたいと思います。 というのも、今日のテーマでは品質と開発ス

    品質を犠牲にすることでソフトウェア開発のスピードは上がるのか? 和田卓人氏による 「質とスピード」(後編)。デブサミ2020
    manhole
    manhole 2020/02/26
    ]
  • 品質を犠牲にすることでソフトウェア開発のスピードは上がるのか? 和田卓人氏による 「質とスピード」(前編)。デブサミ2020

    品質を犠牲にすることでソフトウェア開発のスピードは上がるのか? 和田卓人氏による 「質とスピード」(前編)。デブサミ2020 ソフトウェア開発のプロジェクトにおいて、リリースに間に合わせるために開発スピードを優先させ、ひとまず質には目をつぶろう、という判断がしばしば行われることがあります。 はたしてその判断は正しいのでしょうか。2020年2月13日と14日の2日間、都内で行われたイベント「Developers Summit 2020」(デブサミ2020)」の和田卓人氏のセッション「質とスピード」は、これを深く考察したものでした。 この記事では、会場に立ち見がでるほど大人気だったセッションの内容をダイジェストで紹介します。記事は前編と後編に分かれています。いまお読みの記事は前編です。

    品質を犠牲にすることでソフトウェア開発のスピードは上がるのか? 和田卓人氏による 「質とスピード」(前編)。デブサミ2020
    manhole
    manhole 2020/02/26
    品質→内部品質→保守性
  • 動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α - t-wadaのブログ

    この文章は、2019年4月18日に開催された国際カンファレンス SeleniumConf Tokyo 2019 で行った基調講演の文字起こしを土台に加筆修正したものです。 当日の講演資料は speakerdeck で、動画は YouTube で公開されています。 Clean code that works - How can we go there? - Takuto Wada | SeleniumConf Tokyo 動作するきれいなコード - どうたどり着くか 日の講演タイトルは「動作するきれいなコード - どうたどり着くか」です。動作するきれいなコードへ至る道の話をさせていただこうと思います。 資料は公開予定で、講演の写真撮影も問題ありません。ツイッター等での実況も大歓迎です。ハッシュタグは #SeConfTokyo です。 改めて自己紹介です。和田卓人(わだたくと)といいまして、

    動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α - t-wadaのブログ
  • 外部に依存したコードもテストで駆動する / Test-Driven Architecture - AWS Dev Day Tokyo 2018 - Speaker Deck

    Oct 31, 2018 at AWS Dev Day Tokyo 2018 #AWSDevDay #AWSTDD

    外部に依存したコードもテストで駆動する / Test-Driven Architecture - AWS Dev Day Tokyo 2018 - Speaker Deck
  • 現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ

    この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY(クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0) で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです(これであなたもテスト駆動開発マスター!?和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します~現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd|CodeIQ MAGAZINE)。旧記事には当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出

    現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
  • ピクスタの技術顧問に和田卓人氏が就任:時事ドットコム

    manhole
    manhole 2019/10/04
    とりあえず写真を保存しました
  • 技術選定の審美眼 / Understanding the Spiral of Technologies

    初演: 2018/02/15 デブサミ2018 15-D-1 ハッシュタグ: #devsumi #devsumiD https://togetter.com/li/1199564

    技術選定の審美眼 / Understanding the Spiral of Technologies
  • 避けてきたWeb開発、仕事激減で正面から取り組む

    「異能」ともいえる際立った能力や実績を持ち、まわりから一目置かれるエンジニアを1カ月に一人ずつ取り上げ、インタビューを掲載する。今月取り上げるのは、テスト駆動開発(TDD)の日での第一人者として知られる和田卓人氏。JavaScriptのテストフレームワーク「power-assert」の作者でもある。今回は、転機になった「チーム角谷」への参加からJavaScriptに関わるようになった経緯などを聞いた。 (前回から続く) 永和システムマネジメントに誘われる形で、2004年7月から同社の受託案件の開発チームに参加することになりました。当時は永和の社員で積極的にコミュニティ活動をしていた角谷信太郎さんのチーム、いわば「チーム角谷」です。それまで在籍していた数千人規模の電子政府のプロジェクトから、4人だけのチームに移ることになりました。 初日にチームの顔合わせをすることになって現れたのが、角谷さ

    避けてきたWeb開発、仕事激減で正面から取り組む
  • 設計だけでコードを書けないなら断る、TDD伝道師の原点

    コンピュータに最初に触れたのは、中学1年のときに家にパソコンが来たことでした。父親がコンピュータソフトウエア開発の会社を立ち上げて、家に開発用のDOS/Vパソコンがやって来たのです。 悔しいことに、その時点ではプログラミングにはあまり興味を持ちませんでした。単なるゲーム機の一種としてDOS/VやWindows 3.1のパソコンに触れていたというのが実情です。高校まではプログラミングは全くやっていませんでした。 世の有名なプログラマーは、たいてい小さい頃から街頭でパソコンを触っていたりマイコン雑誌を読んだりしています。それに比べると、コンピュータにあまり興味を持たなかったことにコンプレックスや一種の後ろめたさを感じています。 留学でコンピュータの重要性に気づく 1996年に国際基督教大学(ICU)に入りました。ICUには教養学部(リベラルアーツ)という一つの学部しかありません。「最初の2年間

    設計だけでコードを書けないなら断る、TDD伝道師の原点
  • 希薄化したTDD、プロダクトの成長のために必要なものは?〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 (6)

    テスト書くのが当たり前、だけど・・・和田:次に意味の希薄化ですね。『Test-Driven Development by Example』の出版から15年経ち、テストコードを書く人はすごく増えました。15年前は啓蒙期で、テストコードを書きましょう、テストコードの書き方はこういう感じですというのを頑張って啓蒙する必要があった。 でも、例えば今の若手プログラマーは普通にテストコードを書く。なぜなら既存システムにはテストコードが書かれているから、開発の継続、不具合の修正とか機能追加を行う際にテストコードを書くのが普通だし、テストコードが無いとレビューは通らないしみたいな話になって、テストコードがあるという生活は普通のものになっている。そうすると、なぜテストコード書くのかとか、来こういうテストコードを書きたかったんだけどとか、こういうテストを書くべきなんだけどみたいな議論はだいぶ土俵から外れてし

    希薄化したTDD、プロダクトの成長のために必要なものは?〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 (6)
    manhole
    manhole 2018/05/07
    「モックオブジェクトが書きにくいなというのは、設計が良くないから設計を良くしていくという原動力になるはず」「道具しか残っていないので、背景や思想、文脈を復活させる必要がある。それが付録Cです」
  • ajito.fm/23 を聴いて:「学びの話」「講演の話」 - なにもわからない

    ajito.fm は VOYAGE GROUP の社内バー AJITO の名を冠したテック系 Podcast です。 今週公開された最新話の23回では、テストの伝道師で講演者としても知られる @t_wada さんが、プレゼンテーションや講演の作り方などについて話されていました。 こんなに価値のある情報を開けっ広げにしていいのか?!と思える内容だったので、個人的にその内容を文字起こししてみました。 (t_wada さんは既に何度かご登場されていて、金言がバンバン出るのは毎回なのですが。ぜひ過去回も聴いてみてください) ajito.fm 目次 学びの話 新入社員研修 t_wada さんの学び方の変化 「教える」ことから得られる学びは多い 「教える」を避けるのはもったいない 類似の情報であっても情報発信には価値がある 「ゴミエントリー」にしない工夫 講演の話 「技術選定の審美眼」 講演の準備/資

    ajito.fm/23 を聴いて:「学びの話」「講演の話」 - なにもわからない
  • 第二回テスト駆動開発読書感想会議事録.md

    第二回テスト駆動開発読書感想会議事録.md 第二回テスト駆動開発読書感想会議事録 リファクタリングとデザインパターンについて デザインパターンを知るキッカケになりそう デザインパターンは知識的に理解しているつもりだが、実践できていない Q.実装方針を考える時にどうしたら良いか? A.パターンに気付くスキルがだいじ パターン志向リファクタリング入門 パターンはリファクタリングの途中で出てくるもの ゴール、中間点がデザインパターン 設計 → リファクタリング → デザインパターンが見えてくる デザインパターン。沢山覚えるのは辛いので、まずはTDDにあるパターンから よく使うものは、自分の手札になる デザインパターンより、リファクタリングの勉強をした方が身につく 「コードの匂い」があった時の解決策がデザインパターン 例: 同じif文がコードの中に複数ある…! → stateパターン ゴールのイ

    第二回テスト駆動開発読書感想会議事録.md
  • 第二回社内読書感想会(テスト駆動開発)に翻訳者の t-wada さんをお招きいたしました! - Feedforce Developer Blog

    ドーモ、社内 ニンジャスレイヤー 推進おじさんの id:kasei_san です。 先日、社内にてテスト駆動開発をお題に読書感想会を実施したところ、翻訳者の id:t-wada さんの目に留まり、なんと、id:t-wada さんをお招きして、第二回読書感想会を実施することになりました!! 素晴らしい取り組みだと思います。たぶんもう終わってしまったとは思いますが、御社内でまた『テスト駆動開発』を取り上げるときには、ぜひお気軽にお声がけください。— Takuto Wada (@t_wada) 2017年11月29日 読書感想会とは? 技術書などチームが読んだについて、知見や疑問を共有する会です。 詳しい解説と前回の様子は、こちらの記事をご覧ください。 developer.feedforce.jp どんなことを話したの? テスト駆動開発の疑問や感想について id:t-wada さんに解説頂いた

    第二回社内読書感想会(テスト駆動開発)に翻訳者の t-wada さんをお招きいたしました! - Feedforce Developer Blog
  • ペアプログラミング ホントのところ

    「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、当のインサイトを見つけるUXデザインUXリサーチYoshiki Hayama

    ペアプログラミング ホントのところ
  • @t_wadaとケントベックのテスト駆動開発 - L'eclat des jours(2017-10-09)

    _ @t_wadaとケントベックのテスト駆動開発 長らく絶版となっていたケントベックのテスト駆動開発(入門)が、オーム社から装いと訳者もあらたに再刊されて、しかも嬉しいことに、編集の森田さんから頂けたので早速紹介する。 くだくだしいことなどは後のほうで書くことにして(このページ群はおれにとってはその時考えたことなどを記す日記でもあるからだ)、まず書の要点について書く。 原著は2003年、書はそれの翻訳なので15年以上の歳月を経た準古典だ。何についての準古典かといえば、題名からわかるように開発についてで、なんの開発かと言えばプログラムだ。 一言で言えば、1人でプログラムを開発するときに、どのように開発へのモチベーションを維持しながら、開発そのものをゲーム化して楽しみながら(まあ、1人でプログラムを開発しようとした時点で、それはゲームなのだが、さらにルールをいくつか導入することでゲーム性を

  • 新訳版『テスト駆動開発』が出ます - t-wadaのブログ

    テスト駆動開発の考案者 Kent Beck が記した原典『Test-Driven Development by Example』を新たに訳し直し、新訳版『テスト駆動開発』としてオーム社から復刊しました。ただ訳し直すだけではなく、初めての方にも旧訳版をお持ちの方にも読んでいただけるための工夫を凝らしました。 テスト駆動開発 作者: Kent Beck,和田卓人出版社/メーカー: オーム社発売日: 2017/10/14メディア: 単行(ソフトカバー)この商品を含むブログ (1件) を見る 電子書籍版は Kindle 版は Amazon Kindle ストア、 PDF 版と EPUB 版は 達人出版会 から発売されています。 テスト駆動開発 作者: KentBeck出版社/メーカー: オーム社発売日: 2017/11/13メディア: Kindle版この商品を含むブログを見る テスト駆動開発【電

    新訳版『テスト駆動開発』が出ます - t-wadaのブログ
    manhole
    manhole 2017/10/14
    訳者解説のために買う!
  • TDDBC Fukuoka Day1

    TDD Boot Camp Fukuoka Day1 - Mar 19, 2011 at Fukuoka

    TDDBC Fukuoka Day1
  • 和田卓人さん、PHPで堅牢なコードを書く—例外処理、表明プログラミング、契約による設計 〜PHPカンファレンス2016 | gihyo.jp

    PHPカンファレンス2016 レポート 和田卓人さん、PHPで堅牢なコードを書く—例外処理、表明プログラミング、契約による設計 〜PHPカンファレンス2016 2016年11月3日にPHPカンファレンス2016が開催されました。稿では、ゲストスピーカーである和田卓人さんによる講演「PHP7で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計」についてレポートします。 PHP7では例外や表明の機能が大幅に見直され、強化されました。この講演では、例外処理を設計する際の基的な考え方や、表明(assertion)の使い方、そして表明と例外を使い分け、堅牢なコードに導くための設計手法「契約による設計(Design by Contract⁠)⁠」の考え方を説明しました。 導入 はじめに、和田さん自身が監訳に関わった『SQLアンチパターン』に掲載されているコードを、よりひどくさせた

    和田卓人さん、PHPで堅牢なコードを書く—例外処理、表明プログラミング、契約による設計 〜PHPカンファレンス2016 | gihyo.jp