Google Maps、Earth、Search……と、ものすごい数のAPIを公開しているグーグル。それらをマッシュアップして新しいサービスを作ったり、Webページに埋め込んで呼び出したりといった作業をするときに、それぞれのドキュメントやサンプルをいちいち調べるのは面倒だ。そこで活用したいのが、グーグル謹製の「AJAX APIs Playground」だ。 AJAX APIs Playgroundは、ブラウザー上でGoogle AJAX APIのサンプルコードを試せるサービス。単にコードを見るだけではなく、その場で編集してすぐに実行結果をプレビューできるスグレモノだ。 使い方は簡単だ。まず、「Pick」と書かれている左カラムから使いたいAPIを選択する。ツリー状に分類されているリストから選べるほか、検索窓にキーワードを入れても探せる。APIを選択すると、今度は右カラムの「Edit」にJav

オーベルジーヌ実食レポ 食べ物の鼻塩塩(未だに通じるのかな) オーベルジーヌというカレーをご存知だろうか 都内にあるデリバリー専門のカレー屋で、 ロケ弁などで大人気の本格欧風カレーが楽しめるらしい いいな〜 いいな〜オブザイヤー 都内の奴らはこんな良いモン食ってんのか 許せねえよ………

Rails勉強会@東京第42回に行ってきました。 RSpec 前半はまだあまり慣れていないRSpecののセッションに参加しました！ 概要 Rubyで、Specification（仕様）を先に書く開発手法だからRSpecという名前なのかな。 RSpecを一言でいえば「printlnの代わり」。 動作確認するときにprintlnの代わりにRSpec使うと便利という意味。 Rails開発では、controllerのロジックは薄く、modelに機能を集約するのがよいので、RSpecはmodelだけに使うのがよいとのこと。 コード 後半は id:moro さんに、Skip Wikiのspecファイルのnote_spec.rbのソースコードを見せて頂きながら、説明して頂きました。 RSpecは自明な部分とか全部をテストするときりがないので、キモになる部分をテストする。 id:moro もろはしさんのキ

個人から法人まで幅広い主催者の方にご活用いただいています。 イベント主催者8万人以上 チケット販売550万枚以上

現在ネットショップを作っているのですが、やや複雑なビジネスロジックを持っています。当然モデルはRSpecを書いて仕様の確認(テスト)しているのですが、開発中に注文の確認画面の表示がおかしい問題がよく発生しました。 View自身はモデルやヘルパーの呼び出しが主ですが if で表示を変えたりする部分もありモデルが正しいからといって表示も大丈夫とはなりません。 さらに、注文の確認画面はお客様に、お買い物の金額を伝える大切な画面です。ここにバグがあるとネットショップとしてはたいへんな問題になります。ということで 注文の確認画面 View にもテスト・RSpecを書く事にしました。 ViewのRSpecの書き方 RSpecのページに View Example がありますが、これだけでは良く解りません ^^; しかし、RDocの中のサンプルがとても参考になります。 モデルやコントロラーのRSpecでは

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

休んでいるうちにずいぶん時間が経ってしまいましたが、10/31のOSCにてお時間をいただき、Railsの昨今のテスト事情について紹介させていただきました。普段から申しているようにCucumberとRSpecをぐいっと推しています。 Rails testing environment, 2009 fallView more documents from Kyosuke MOROHASHI.あとはRSpec方面で、subjectやitsの使い方について、使いながら考えているようなことを書いています。 前にオブラブ方面でCuctomMatcherの話をしたときに、簡単なCustomMatcherを量産するのはだるいんじゃない?という懸念があったんですが、その一つの解としてits()はありかなー、と。使い分けはこんな風になると思います。 CustomMatcher作る 検証内容が複雑になるとき エ

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

原文(投稿日：2009/11/19)へのリンク Alan Beljeu 氏は古い (レガシー) C++ コードベースで TDD を行っていて，トラブルに見舞われた。その理由はこうだ。 機能を完全に実装できていないクラスが最後に残ります。いつか必要になるかも知れない，というやつです。他のクラスからそれを利用しようとして，実装を完成させる時がきた，まさにその時になって当初の設計不足が明らかになるのです。設計は新たにやり直し，外部仕様(とそのテスト)も修正が必要。そのクラスを使っていた既存コードも変更しなければなりません。 そして彼は，"事前の大規模設計 (Big Design Up Front)" がこの問題の解決策ではないか，と考えるのだが，アジャイルコーチである George Dinwiddie 氏は，Alan のこの例が訴えているものを指摘する。すなわち，きれいなコード (clean c