Bayonetta2 開発ブログ 『ベヨネッタ２』発売２周年＆amiibo初公開！ 2016.09.20
Bayonetta2 開発ブログ 『ベヨネッタ２』発売２周年＆amiibo初公開！ 2016.09.20
DevLove関西に行ったので、「課題をテストで解決する」という発表をしてきました。 内容はスライドに書いてあるとおりです。以下のことを特に話したくて、今回の発表をしました。 何度も起こる課題があったときに人が気をつけようとしない 最悪のケースでは根本原因を知ろうとせず、間違えた人を怒ることで解決しようとしてしまう 何度も起こる課題なら、機械に自動的にやらせる その例として今回はテストでやりましょうという話をした あとテストいろいろあって始め方がわからないという時は、こういう課題をテストにするというところから始めるとやりやすいかもしれない 参考 この資料作るにあたってひたすらブログ書いたので参考にどうぞ 設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog; ドキュメントの場所を知らせるために、落ちるテストを作る - $shibayu36->b
テストの時に時間を止めるか、特定日時に変更できたら色々捗るよなーと思いました。 Google先生に頼んで探してみたら、やっぱりありました。 php-timecop というPHP拡張です。 http://www.slideshare.net/hnw/php-13502189 http://www.slideshare.net/hnw/phptimecop makeとかphp.iniを触ったりとかがあるので自前のサーバが必要ですが、面白そうですね。 https://github.com/hnw/php-timecop …うっ、公式の情報が圧倒的に少ない（白目） という事で、簡単にまとめてみました。 （この記事の情報は、「version 1.0.4, 2013/03/11」を基にしています。） GitHubのREADME.mdを読んでインストールとphp.iniの設定を行うと、 「timecop
Coveralls は Github に置いているソースコードのテストカバレッジを git push の度に調査して報告してくれるクラウドサービス。「カバー率100%を維持したいなら継続的インテグレーション (CI) のレポーティングにテストカバレッジも含めちゃえばいいじゃない」という貴族向けのサービスです。いえ、貴族はフィクションです。 こんな感じでモダンなデザインで色々教えてくれる。各行が何回テストされたかみたいな詳細なレポーティングもある。 Travis CI と同じく Github の README なんかに貼り付けるバッジがあります。というか Travis CI なんかのCIツールと連携して Coveralls にレポートを投げるのが前提になっているようです。 つい最近 プロトタイプ開発用のRailsプラグイン「Chanko」を2.0.0にアップデートしました - クックパッド開
「恐怖」を知ること 35歳が目前に迫りつつある中、ぼちぼちスピリチュアルなことも書いていこうかと思う今日この頃です。 これまで十数年、小さな会社やフリーランス、大企業（はすぐ辞めたけど）を渡り歩いてきて改めてベンチャーの面白さを実感しています。 様々な要素がありますが、その最たる物は「エンジニアが会社の命運を握っている」という紛れもない事実です。自社でプロダクトを開発しているベンチャーにおいて、どんなに立派な経営理念やビジネスモデルも動かないシステムの前ではクソの役にも立ちません。 そして、それはそのままエンジニアの過ちが会社を危機に陥れるリスクを意味します。言ってしまえば「ワンクリックデプロイ」が「ワンクリック倒産」へと直結するかもしれないのです。省力化そのものは目指すべきですが、自分の行為が内包するリスクは忘れてはならないのです。 「何か」が起きてしまった時に上長の責任だ、確認ミスだと
例えばログインしてるか確認する処理などbefore_filterで共通して使われそうなメソッドをテストする際に上手いことテストする方法。 Anonymous Controllerを使うと良い。 Anonymous Controllerを使うとテスト内でactionを定義することが出来るのでこのactionにリクエストを投げると良い。また、paramsの値によってテスト内容が変わる場合などもこの方法を取るとget,post呼び出し時にクエリストリングを渡す事が出来るので便利。 describe ApplicationController do describe "#login?" do controller do # index actionを定義 def index login? render :text => 'dummy message' end end it '' do … # 上で
みなさん、 timecop 使ってますか？timecop は、テストで時間を扱う時に必須と言えるライブラリです。テスト中の時間を止めたり(Timecop.freeze)時間を移動させたり(Timecop.travel)できます。似たようなライブラリとして delorean があります。RailsCasts でも紹介されています。 さて、timecop の README には下記のようなコード例が書いてあります。 t = Time.local(2008, 9, 1, 10, 5, 0) Timecop.travel(t) 僕はこれまで上記のように書くしか方法が無いと思っていたのですが、今日下記のようにも書けることに気づきました。 Timecop.travel(2008, 9, 1, 10, 5, 0) また、ブロックを使うこともできます。 Timecop.travel(2008, 9, 1,
先日 Evergreen を導入したけど Evergreen は今メンテされてないってコメントで教えてもらった。確かに、README よく見たら書いてあるし…。完全に見落としてた。不覚。 README のリンク先、Google グループのスレッドでは Konacha っていう Rails エンジンが勧められていた。コメントで教えてもらったのもコレ。 jfirebaugh/konacha · GitHub Evergreen 入れたばかりだけど、Konacha に移行しよう。 Konacha をインストール Gemfile に group :development, :test do gem "konacha" gem "capybara-webkit" end を記述して、 bundle を実行してインストール。 Headless テストも試すから、capybara-webkit もインス
このウェブサイトは販売用です！ twiwt.org は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、twiwt.orgが全てとなります。あなたがお探しの内容が見つかることを願っています！
内容：「疑似個人情報データ生成サービス」は、ダミーの個人情報を大量に出力できるウェブサービスだ。かんたんな操作で郵便番号や住所を含む最大5000件の個人情報を作成してダウンロードできるので、会員制サイトのテストなどで実在しない個人情報が大量に必要になった場合に便利に使える。 「疑似個人情報データ生成サービス」は、ダミーの個人情報を大量に出力できるウェブサービスだ。かんたんな操作で郵便番号や住所を含む最大5000件の個人情報を作成してダウンロードできるので、会員制サイトのテストなどで実在しない個人情報が大量に必要になった場合に便利に使える。 使い方は簡単で、一覧から必要な項目を選び、ボタンを押して生成するだけ。あらかじめ用意されているデータをランダムに掛け合わせた個人情報が出力される。出力数は最大5000件で、画面上にそのままHTMLで出力するほか、XML、Excel、CSVの4形式での出力
TDDがアジャイル開発では前提 ここまでに説明した、アジャイル開発を支えるエンジニアリングのプラクティスをまとめておこう。 ユニットテスト リファクタリング テスト駆動開発（TDD） 継続的インテグレーション これら4つを実践することなしにアジャイル開発を成功させることはかなり難しい。たちまち「書いて直す」だけの日々に逆戻りすることになるだろう。 アジャイルサムライでは成功させることはかなり難しいと甘い表現をされているが、ほぼ不可能であるといえる。 プラクティスとは習慣である。つまり、やることが当たり前なのである。やるべきことなのです。 テスト駆動開発を推し進めれば、必然とここにあげられている4つのプラクティスを実践することになる。 注意しなければいけないことは、テスト駆動開発をおこなうこと事態ががアジャイルソフトウェア開発ではありません。 アジャイルにソフトウェアを開発するためにエンジニ
状況はかなり改善した 非同期、setTimeout, Ajax系はSinonJSで簡単に Swarm系のツールでDOMのテストも容易に 環境構築も非常に楽になった PhantomJSはバイナリもあるし、ビルドも簡単 Swarm系のツールならブラウザでURLへアクセスすればすぐテスト開始
こんにちは、エンジニアの岡崎(@watermint)です。今回はGREEにおけるJenkinsをつかった品質管理について紹介します。 hourlyビルド 岡崎がGREEに入社したのは1年半前ですが、そのときから感じているのがGREEの開発速度は非常に速いことです。ソースコードレポジトリには多くの優秀なエンジニアが日々数百以上のコミットしています。 GREEのシステムは多くのサブシステムを組み合わせたものですが、手元の些細な変更が全く予想しない別のプロジェクトで問題を起こすことがあります。こういった問題は通常、リリース前の結合テスト等の段階で検出します。 リリース前のテストで問題が発覚すると、当然その修正をして再度修正をリリースプロセスにのせるということになるのですが、これには他のエンジニアの作業を止めてしまったりリリースの順序を調整が必要になることがあります。 こういった事態を防ぐために単
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
[http://d.hatena.ne.jp/uk-ar/20120720/p1:title]にて機能追加をおこないました。そちらも参照ください。 Emacs Lispでrspec*1のように前処理などをネストして定義できるテストフレームワーク(el-spec)が欲しくて作ってみました。 https://github.com/uk-ar/el-spec 実用になりそうなレベルになったのでリリースします。 きっかけ、が欲しいです。 Emacs Lispにもいくつかテストフレームワークがあり、今まではid:rubikitch さんのel-expectation*2を使ってました。使い勝手が良くてテスト数の少ないうちは満足していたのですが、テストが多くなると複数のテストで同じような前処理をしているのが目立ってきました。 このような場合マクロや関数で対応するのが常套手段です。しかし、前処理の内容も
2016/07/11 追記しています 皆さん負荷テストツールって普段使ってますか？ WEBシステムを開発する際には、1人〜十数人で開発をすると思いますが、 受諾案件では要件を満たす開発ばかりしていて速度やパフォーマンスのチューニングを行う事が少ないと思います。 いざ運用が始まって、サーバーが落ちた・・とならないように負荷テストを事前にやっておきましょう。 Apache Benchでのサーバーパフォーマンスのチェック方法をメモしておきますので、どなたかの役に立てれば幸いです。 負荷テストとは 負荷テストって何ですか？という方のために簡単に説明をすると 低い負荷ではシステム上問題が無くても、高負荷での動作だと不具合を起こす現象を回避するためのテストです。 アクセスが集中して落ちてるサイトがありますよね。。 想定されるアクセスがあっても落ちないサイトにするための負荷テストです。 Webサーバーの
もう何回目かわからなくなってきた8時間耐久シリーズですが、今回は新作となるPHPUnitの教室を下北沢オープンソースカフェで開催してきました。初物という事もあり色々と試行錯誤な部分もありましたが、参加者の皆さんのご協力のおかげで楽しい時間を過ごすことができました。開催してみて思ったのが、PEARのセットアップ方法が環境ごとにカオスすぎるという事です。Macの場合はPHPの導入方法がOSバンドル、MAMP、MacPorts、自力ビルドと豊富かつ、重複して導入されている可能性が極めて高いのでパスの解決などが人によって違っています。PEARのinclude_pathを基準とした動作スタイルは実習の手順にはかなり影響が大きかったです。（セッションの為にphp.iniを変更させるというのは極力避けたいですし）またユニットテストは強制的に触る機会がないとなかなか始められないという事もあり、こういった内
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
