サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
この記事は ドメイン駆動設計 Advent Calendarの記事です。 今年の9月にログラスというスタートアップに転職しました。 ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。 入社時の状況 なにをしたか テストの話が多い理由 実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにした レイヤーごとのオブジェクトの依存関係を整理 レイヤーごとのテスト方針 クラス名の重要性 参照実装を作成した 「責務」と「テスト」の重要性
![ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab](/image.pl?url=https%3a%2f%2fcdn-ak-scissors.b.st-hatena.com%2fimage%2fsquare%2faf7afb371080ebffd6049566e694a560f315052d%2fheight%3d288%3bversion%3d1%3bwidth%3d512%2fhttps%253A%252F%252Fcdn.image.st-hatena.com%252Fimage%252Fscale%252Fe72d4368c74e3a248a45b6b48a5b152ef5555594%252Fbackend%253Dimagemagick%253Bversion%253D1%253Bwidth%253D1300%252Fhttps%25253A%25252F%25252Fcdn-ak.f.st-hatena.com%25252Fimages%25252Ffotolife%25252Fl%25252Flittle_hands%25252F20201221%25252F20201221103037.png&f=jpg&w=240)
こんにちは。技術部平山です。 この記事では、雑にベンチマークプログラムを作ってみたことと、それに付随して、 ベンチマークプログラムを作りたくなるような事情 テストの設計と、その背後にあるハードウェア といった点について書きます。 なお、実行はこちらからWeb上で可能です(上のスクショを押しても飛べます)。UnityのWebGLにすることで、余計な手間なく多くの機械で測れるようにしています。 ただし、WebAssemblyを使っている関係上、iOS9以前では動きません。ご容赦ください。 測ってくださった方は、twitterで結果(スクショ)を頂けると大変うれしいです。ゲーム機、ハイエンドPC、古いスマホ、などは特に歓迎です! なお、ソースコードもgithubにあります。 測定方法 「ALL」を押し、元の画面に戻ってくるまで(キャラクターの絵が出てくるまで)放っておきます。 途中でスリー
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
GC（ガベージコレクション）はコードに紛れひっそりと忍び込みます。 今回はソレを見つけるのに便利なAPIが追加されていたので試してみました。 AllocatingGCMemoryでGCの発生を監視する 実際に使ってみる 関連 AllocatingGCMemoryでGCの発生を監視するUnity 2018.3からAllocatingGCMemoryが新しく追加されました。 このコードとAssert.Thatを使用すると、実装の中でGCが発生しているかどうかをテストすることが出来ます。Unity - ScriptingAPI: AllocatingGCMemoryConstraint 例えば下のコードはマニュアルのコードです。int aを定義し代入する処理がGCを発生するかといった点をテストしています。 ここで少し注意したいのが、IsがNUnit.Framework.IsではなくUnit
【Unite 2017 Tokyo】バグを殲滅！Unityにおける実践テスト手法Description améliorée par l'IA Le document aborde des problèmes courants rencontrés dansUnity, notamment concernant le démarrage des testeurs dans l'éditeur et la fenêtre de test. Il inclut des liens vers des ressources externes pour des informations supplémentaires. Les sites mentionnés semblent être liés à des entreprises et des projets associés.
世の中は一周まわってエンジニアリングの手法に溢れている。 テストを書け、ドキュメントを書いて冗長化しろ、コミットはわかりやすく、コーディング規約が、安定性が─── でも、それって本質なんだろうか？ 新規サービスを作る際に肝だと思っていることをまとめてみた。 おことわり 以下は少人数で"普通"のアプリやWebサービスを自社で新規開発するときのことを想定しています。大人数で重厚なソシャゲを作るとか、ガチガチの金融系サービスを作るとか、コンシューマーゲーム開発とか、個人で好きなものを作るとか、受託とかは全く想定していません。 基本的に一通り現場をこなした中級以上のエンジニア向けに書いています。 アンチテーゼとして、ややキツめに断定する箇所が多いです、こういう意見もあるんだな程度に受け止めてください。 所属する団体の意見とかは一切関係ありません。 目次 おことわり 目次 ユーザーのことだけ考える
ちくしょう、プロジェクトまるごと書き直したい 自分で作り始めたプロジェクトであっても、途中から相乗りしたプロジェクトであっても、誰もが一度は体験する気持ちではないでしょうか。 私が携わっている「おいしい健康」も例外ではありません。プロジェクトを全て書き直したいと思う一方で、全てのコードを書き換えようとするアプローチは、これまで作ってきた見た目や機能、ビジネスロジックを再現しきれずに潰えてしまう。という話しも良く聞きます。 実は全て書き直したいのではなく、その大きな目的としては以下のようなモノがあるのではないでしょうか。 シンプルな作りに変えたい 不要なコードが重なり、動作が遅くなっているところを解消したい 新しいライブラリ、新しい技術を取り込めるようにしたい 今回は、このような目的を達成しつつ、プロジェクトの書き換えを行った私達の話をしたいと思います。 cookpad本体からのプロジェク
買物情報事業部の八木です。クックパッド特売情報のAndroid部分を担当しています。普段はクックパッドのAndroid版（以後、本体アプリとします）の開発プロセスの中で特売情報の機能を開発しています。本エントリでは細かな技術的負債を解消する為に本体アプリの開発チームが行っている朝Lint活動を紹介します。 2年近く経つ本体アプリのコードベース 私が買物情報事業部に所属する前は本体アプリを1から書き直すチームで働いていました。書き直し始めたのは2013年10月からなのでそろそろ2年が経とうとしています。2年前に設計された本体アプリは現在ではおよそ17万行を越え、日々どんどん変更が加えられています。 それらの変更の中には残念ながら悪いコードが含まれている場合があります。テストしづらいコードやテストがないコード、レビューに対する場当たりな対応や緊急のbug fixのために追加された汚いコード、
Photo byGonzalo Baeza |Flickr - Photo Sharing!RailsでJSONを返すAPIを作成し、また、APIのテスト方法も説明します。 JSONを返すAPIは、RailsのActiveSupportより拡張されたto_jsonメソッドとDMMが開発したjbuilderというGemを使います。APIのテストにはおなじみのRSpec3を使います。 動作確認Rails 4.1.7 jbuilder 2.2.6 rspec-rails 3.1.0 factory_girl 4.5.0 目次 1. 前提条件 2.APIの作成 2.1. 1つのコントローラーでHTMLやJSONを返すAPI 2.2. JSONのみを返すAPI 2.3.APIのバージョニング 3.APIのテスト 3.1. テストファイルの準備 3.2. 一覧(index)APIのテス
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマ
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間
前書き 「一緒に働いている以上、プログラマのことを理解して仕事をしたい」そう考えている企画・ディレクションの方は経験則的に少なくない。 ノンプログラマから見て、プログラマの仕事はイメージが湧きづらく、何故その工程にそこまでのコストをかける必要があるのかわからない事が多い。 プログラマは作業の必要性を説明してくれるかもしれないけれど、専門用語も多いしイマイチピンとこなかったりする。 ここで重要なのはまさに「イメージ」だと思う。すなわちイメージを提供するための良質なメタファーだと思う。メタファーが良質であれば より直感的に理解できる。 実際メタファーの力はバカにならない。「Chef」も「Jenkins」も それぞれ 統一的な世界観が学習者の直感的な理解を後押ししてくれる。 というわけで、今回から数回に分けて なるべく「技術的な話」をせずに イメージを想起しやすいストーリーを導入することで プロ
はじめに Xcode 5 で XCTest という新しいテストフレームワークが投入されました。OCUnitを使ったプロジェクトからのコンバートもできるので、それを置き換えるものと考えて良さそうです。また Test Navigator という新しいナビゲータが導入され、テストターゲットとの親和性が高くなっているようです。さらにコマンドラインからのテスト実行もサポートされました。 導入 何も考えなくてもプロジェクトを作成すると勝手にTestターゲットが作成されます。素敵です。 メニューからProduct -> Test 又は Command + U でテストが実行されます。Testクラス新規作成時はXCFailが1つ設定されているので必ずテストが失敗します。この辺はOCUnitと変わりません。 Test Navigator で動作させる ナビゲータから↓のアイコンを選択します。 最後に実行した
![[Xcode 5] Test Navigator と XCTestを使ってみる | DevelopersIO](/image.pl?url=https%3a%2f%2fcdn-ak-scissors.b.st-hatena.com%2fimage%2fsquare%2fd6d42bb8eb763a9d4914eebb951bc5e3e7718d03%2fheight%3d288%3bversion%3d1%3bwidth%3d512%2fhttps%253A%252F%252Fdevio2023-media.developers.io%252Fwp-content%252Fuploads%252F2013%252F09%252Fios7_logo_xcode5.png&f=jpg&w=240){kind=logo}
iOSのアプリケーションではモデル周りのテストと同じぐらいUI周りのテストが重要な気がするのですが、画面のテストってちょっと面倒ですよね。その上Xcode標準のテストフレームワークでは画面遷移などのテストができません。そこで、統合テスト用のテストフレームワークを使う必要がでてきます。 選択肢はいくつかありますが、使い方がシンプルで導入も容易なKIF Frameworkを紹介します。 KIF FrameworkGitHub - kif-framework/KIF: KeepIt Functional - An iOS Functional Testing Framework KIFは決済サービスSquareが自社アプリケーションの統合テストのために開発したフレームワークだそうです。KIFを使ったテストではボタンをタップして画面遷移したり、画面遷移した先のUIの存在を確認したりといったこと
久しぶりにテストを書く このブログも独自ドメインではてなブログに移行して読者数が一気に減ってしまいましたが、半年以上前のホッテントリぶりにブログ書きます。 前回は iOS 開発環境における CI 導入についてでしたが、今回はもう一度テストに戻って、その中でも iOS における Integration Test の実行方法について書きたいと思います。 Integration Test って？ 日本語では良く結合テストと呼ばれていますが、iOS 開発ガイドなどでは単体テストをロジックテストと呼び、結合テストはアプリケーションテストと呼んでいます。 結合テストはUI テストとも呼ばれる場合もあったり、このブログで紹介した GHUnit でも最近では ViewController のテストができたりと境界は結構曖昧です。 僕の iOS におけるテストのイメージとしては、 Unit Test はコ
2012/4/26に行われた第38回HTML5とか勉強会「Webアプリ×テスト最新事情」に参加してきました。JavaScriptのテストフレームワークについていろいろな話を聞くことができました。 遅れて参加したうえに、ノートパソコンの電源入れたとたんに電池切れ orz 途中の休憩時間にコンセントのある席へ移動したのですが、前半はメモれてないですｗ メモとるのが全然追いつけなかったので、コードとか省略してたり間違ってたりすると思いますが、雰囲気だけでも感じて頂ければと。 Sinon.jS 外村和仁さん テストしにくいもののダミーを作成する。 spy メソッドの代わりにダミーを作成できる。 // オブジェクト作成。spyはメソッドオブジェクト // これをテストしたいメソッドを上書きする感じで。 var spy = sinon.spy(); // 試しにメソッド読んでみる spy('foo'
東京Node学園祭2012 アドベントカレンダーの9日目です。Node.jsとほとんど関係ないうえに内容がけっこう薄い感じなった気がするんですけど気にせずいこうと思います。フロントエンドのJavaScriptをテストするとき最近はいつもmochaを使ってるんですが、やはりJenkinsとかtravis-ciを使って自動テストもしたいと思って試してみました。 hokaccha/mocha-phantom-travis-test ここではよくあるjQueryで画像のロールオーバーをするというプラグインを作ってそのライブラリに対してテストを書いています。ソースコードはこんな感じです。 $.fn.rollover = function() { return this.each(function() { var $img = $(this); var src = $img.attr('src');
レーベでもAndroidアプリの開発を行っていまして、最近ではカメラアプリを開発しました。沢山ダウンロードされると「○○で動かない」といったレビューがGoogle Playに入る事も多々あり、逐一各機種でテストする必要があります。 最近まで私たちも実機を事あるごとに購入していたのですが、良いレンタルサービスを発見したので、簡単な動作検証の場合は実機を買わずに済ませるようになりました。 Remote Testkit forAndroidについて http://appkitbox.com/testkit Remote Testkit forAndroidとはNTTレゾナントが提供するリモートによるスマートフォン実機検証のためのサービスです。端末のレンタルはチケット制で3チケットで30分利用可能となっています。6チケット（1時間分）945円（税込）で販売しています。 エミュレータではなく、実
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
