タグ

関連タグで絞り込む (230)

タグの絞り込みを解除

開発に関するtknzkのブックマーク (336)

  • これであなたもテスト駆動開発マスター!?和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します~現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd|CodeIQ MAGAZINE

    和田卓人さんによるテスト駆動開発問題解説の寄稿です! バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中! by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上

    これであなたもテスト駆動開発マスター!?和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します~現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd|CodeIQ MAGAZINE
  • APIファーストで開発する - ワザノバ | wazanova

    http://blog.pop.co/post/67465239611/why-we-chose-api-first-development POPは、簡単にビジネス/アイデアをかたちにするために、1分でドメイン/スタートページ/メアドを用意できるサービスとのこと。彼らが、「APIファースト」で開発しようとした理由を紹介してます。 1) 将来APIを提供できるように 機能を追加する都度、APIが既に準備できているかたちになるので、将来APIを第三者に提供するときもスムーズ。 2) フロント/バックエンドの分離 バックエンドのテンプレートコードがフロントエンドのクライアントビューとやり取りしない仕様にすることで、将来の開発に負の資産を残さない。 3) スケーラビリティ フロント/バックエンドそれぞれを独立してスケールさせることができるので、将来的にメリットがでるはず。 4) 開発言語のバリア

  • About COOKPAD (2013-11)

    2013年11月にHAL東京・大阪・名古屋でやってきた講義の資料。 クックパッドの働き方や技術の話です。

    About COOKPAD (2013-11)
    tknzk
    tknzk 2013/11/19
    良い資料
  • 3年前の僕へ

    DevLOVE現場甲子園2013にて、3年前の課題とそれに対する現在の気付きについて発表しました。Read less

    3年前の僕へ
  • 状態ではなく、振る舞いをモックせよ

    TL;DR GOOS『実践テスト駆動開発』で触れられている「ロールをモックせよ」について、違った角度で解説ドメインモデルを豊かにすることでコードがシンプルになる例Mock Behaviors, Not Statesユニットテストを記述する際、テスト対象のオブジェクトが利用しているオブジェクト(依存オブジェクト、隣接オブジェクト)はモックオブジェクトにして、テストしたい状況をテストコード側からコントロールします。しかし、闇雲にモックを使ってテストを記述すれば良いわけではありません。今回は、モックが有効に機能するテストとはどういったものなのかを解説します。 サンプルコード簡単なサンプルで説明します。Extract Till You Dropのモデルと近いものを使います。グループ、メンバー、およびグループリポジトリがあります。グループオブジェクトはインメモリでは所属メンバーの情報を保持しておら

    状態ではなく、振る舞いをモックせよ
  • 開発時に出会いたくないパターン - Perl日記

    悩んだりうまくいかなかったり解決したり。だらだら書いた。 手作業症候群 とにかくなんでもかんでも手で確認・作業する必要があると思い込んでしまう病。 そりゃiOSアプリとかAndroidアプリとか最終的には実機確認は必須だけれども。 その前にやれることは多々あるはず。リグレとか。 あと「デプロイ職人」も不要にするべき。わかってる。 自動化できない要素を突っ込んでる方が悪いのだ。なんとかする。 masterブランチぶっこみ志向 masterブランチに直接コミットを重ねていくことにより開発速度をアップさせることができる。 ただし孤独な背水の陣を構えることになる諸刃の剣。 おとなしくtopic branchを切って作業するのが安心への近道であり王道である、 とか言ってたらみんなちゃんと切ってくれるようになった。めでたし。 チケットそっ閉じ症候群 来はリリースしたりデータを修正したりしてチケットと

    開発時に出会いたくないパターン - Perl日記
  • 「真の爆速は速すぎて見えない」 ヤフーにおけるリーンスタートアップの実践。IBM Innovate 2013

    「真の爆速は速すぎて見えない」 ヤフーにおけるリーンスタートアップの実践。IBM Innovate 2013 大規模な組織であってもリーンスタートアップのような方法論は重要である。IBMが10月28日に都内で開催したイベント「Innovate 2013」の基調講演に登壇したヤフーの河合氏は、同社におけるリーンスタートアップの事例を通してこのことを示しました。 エンタープライズ向けのサービスであっても、つねに改善のサイクルを迅速に回すことが不可欠になってきています。ヤフーの取り組みがどのようなものなのか、河合氏の講演内容をダイジェストで紹介しましょう。 大組織におけるリーン・スタートアップ ヤフー株式会社 CMO (Chief Mobile Officer)室。河合太郎氏

    「真の爆速は速すぎて見えない」 ヤフーにおけるリーンスタートアップの実践。IBM Innovate 2013
  • Webのフレームワークの価値ってなんだろなって改めて思う。 | F's Garage

    この記事ね。ちょいと炎上してるけど、言ってることはわかるんですね。 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 タイトルが誤解を生んだので妙な方向になってるようですが、要するにRailsやCakeを使うための学習コストを払おうとして悶々としてるくらいなら、普通のHTMLSQLを使ってPHPなどを書けるようになってから、フレームワーク勉強したほうがいいんじゃね?ということだと思います。 ノーフレームワークのPHPって、ある意味、学びの材料としての粒度として最適なのかなって最近思ったりしています。 例えば個人的にフレームワークで過剰かもなって思うものに「オートリンク作成」「オートフォーム作成」の2つの機能があります。 オートフォーム作成は、それこそSmartyの頃からありますけど使ったことがなくて、何故にHTML生成を特殊な関数に置き換える必

    Webのフレームワークの価値ってなんだろなって改めて思う。 | F's Garage
  • Webサービス開発現場から / 近頃の開発のやり方 ・・・ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー

    先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう

    Webサービス開発現場から / 近頃の開発のやり方 ・・・ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
  • Over&Out その後

    2009 | 08 | 2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 2012 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 2013 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 2014 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 2015 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 2016 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 1

  • はてなインターン2013に参加して参りました、そして与太話がしたい - その手の平は尻もつかめるさ

    幸運にもはてなインターン2013に参加する機会に恵まれましたので、謹んで参加して参りました。 「参りました」っていうのは、「精神的に参ってしまいました」とかそういう意味合いではありません。謙譲語です。 (非常に遺憾な事に、他のインターン参加者のブログを見ると、僕が精神的に参っている人のように描かれているので) さて、エントリの前半でははてなインターンの全般の話を取り上げます。が、このへんは他のインターン参加者のブログの方が詳しいし丁寧だと思うので、そちらを読むと良いでしょう。エントリではできるだけ技術的な部分 (というか、開発プロセスのあたり) に触れて行きたいと現時点では考えていますが、スピリッチャルな内容になるかもわかりません。 エントリの後半は与太話です。それは例えばソフトウェアエンジニアの話かもしれないし、漫画家の話かもしれないし、サラリーマンの話かもしれないし、あるいはそう、

    はてなインターン2013に参加して参りました、そして与太話がしたい - その手の平は尻もつかめるさ
  • 転職サイト【Green】 | IT/Web業界の求人・採用

    お使いのブラウザのバージョンのサポートが終了しました。最新のブラウザにアップデート、またはGoogle Chromeをお使い下さい。

  • サービス終了のお知らせ - NAVER まとめ

    サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。

    サービス終了のお知らせ - NAVER まとめ
  • なぜリリース頻度を上げるのか

    サービスのリリースで書いたようにネットのサービスを提供している企業は新バージョンのリリースの頻度を上げるよう常に努力しています。 リリースの頻度を上げる理由は、サービス開発の方向の軌道修正を細かく行いたいからです。少しずつサービスを改良し、その改良がユーザーにどのように受け入れられたかという反応を元に将来の開発を行っていきます。このフィードバックサイクルを短くすることによりこまめな軌道修正が可能になります。 リリース頻度が低く、リリースサイクルが長いと、その期間に加えられた変更の数が多くなり それぞれのリリースでの変更量が大きくなります。変更が多い分、リリース後の不具合発生の可能性が高くなります。また、リリース後の障害発生時の問題の切り分けも難しくなります。小さなリリースを頻繁に行うことにより、一歩一歩問題がないことを確認して次の一歩を踏み出すように、よりリスクの少ないリリースが可能になり

    tknzk
    tknzk 2013/09/03
  • https://devcenter.me/

  • 超高速開発コミュニティ

  • ゆーすけべー日記

    ユーザーからのPOST等された入力値の妥当性をチェックする Validation をどこでやるか問題が個人的にありまして〜、DBを使わないケースならばいわゆるFomrValidator::*を使ってControllerでやればいいのですが、Modelを経由するようなアプリだとControllerだけじゃ不安よねぇ〜、Modelだけ使う時もあるし、Model単体のテストで再現出来ないよね〜なんて思ってます。で、実際の実装をControllerではFormValidator::Lite、Modelの一部にData::Validatorを使っているのですが、なんかコレも効率悪い感じしてたんで、ちょいと実験的に理想の一つを実装してみました。 こんな条件です。 エラーメッセージを簡単に設定したいのでValidationモジュールにはFormValidator::Liteを使う 色々錯誤していたらOR

    ゆーすけべー日記
  • ルーク、 MongoLab を使え! - @kyanny's blog

    五月の終わりから Quipper で働いている。 Quipper は DeNA の co-founder である渡辺雅之氏がロンドンで創業したモバイル学習プラットフォームの会社で...みたいな話は長くなるし、読者の興味を引きそうにないのでやめておく。このへんの話を詳しく知りたい人は渡辺によるハーバード・ビジネス・レビューの連載をどうぞ。 ソフトウェア開発者にとって一番気になるのは、会社の事業内容とか売上利益よりも、「どんな環境でソフトウェア開発をしているのか」じゃないだろうか。どんなインフラを使っているのか、バージョン管理やタスク管理はどうしているのか、自動テストはどのくらいやっているのか、開発手法はアジャイルなのか、 Mac で開発できるのか、椅子は六万円以上か(冗談ですよ)、などなど。 こういった、ソフトウェア開発者が日々過ごす広義の「環境」について言えば、 Quipper はかなりい

    ルーク、 MongoLab を使え! - @kyanny's blog
  • 「技術的負債」とは何か。原典とその対応策を探る

    負債とは要するに借金のことですが、システム開発においても技術的な借金、つまり「技術的負債」(Technical debt)がある、という表現がしばしば使われます。お金の借金をすると利子を払い続けなければならないのと同じように、技術的負債を抱えると、そのツケを払い続けなければならなくなる、という比喩です。 「技術的負債」という表現は、WikiWikiの発明者で著名なプログラマとして知られるウォード・カニンガム氏が1992年に使ったのが原典とされています。しばしば目にするこの「技術的負債」というのはどういうものなのでしょうか? 調べてみました。 カニンガム氏とファウラー氏による「技術的負債」 カニンガム氏が「技術的負債」という表現をはじめて使ったのは、1992年に行われたACM主催のイベント「OOPSLA '92 」(Object-Oriented Programming, Systems,

    「技術的負債」とは何か。原典とその対応策を探る
  • レガシーマイグレーションという名のシステム移行はデスマーチになりやすい - プログラマの思索

    2005年の古い記事だが、レガシーマイグレーションという名のシステム移行に関して、概念が良くまとまっているのでメモ。 【元ネタ】 ITレポート(動向/解説) - 失敗しないレガシー・マイグレーション(1):ITpro ITレポート(動向/解説) - 失敗しないレガシー・マイグレーション(2):ITpro 【1】レガシー・マイグレーションとは一言で言えば、旧式(レガシー)のシステムを新しいシステムに移行すること。 メインフレーム上のCobolシステムをオープン系のWebシステムに変えたい、VBとSQLServerのクラサバをJavaPHPのWebシステムに変えたい、とか。 レガシーマイグレーションを実施したい理由は、いくつかあるだろう。 保守費用が高い割には、業務ロジックのカスタマイズが追いつかず、既存の業務に影響を与えていること。 あるいは、長年の手パッチによる修正によって、保守性や移植

    レガシーマイグレーションという名のシステム移行はデスマーチになりやすい - プログラマの思索