Jon, you mention in other threads that an application is built throughout the book, building in features from one chapter to the next. What is the application? Also, how much do you cover on testing and do you take the TDD or DDD approach?
The application is a team communication application for sharing messages and files between team members. Essentially by the end of the application users can:
post messages and files
maintain version history of files
tag messages and files
subscribe to an RSS feed
search the application for messages and files
customise their home page by watching for content with certain tags
edit tags in-line with auto suggest
view a tag cloud for messages and files
filter content by tags, using the tag cloud
There is also a RESTful API for creating and listing messages.
I devote an entire chapter to testing, covering unit testing, integration testing and functional testing. I tried to take more of a domain driven approach in the book, because it seemed like an easier way to write about what I was doing. Where there are, relatively, large bits of coding to do before you can see an on-screen result, I use some tests to give the reader something to run to give an indication of progress.
I'm a big fan of TDD in my day to day work, but the driving goal behind writing an application for a book is actually quite different from real world development, for a start you don't have any real users. You also have to spend at least ten times more effort writing than coding!
Sounds very interesting, Jon. Thanks for the info. I go back and forth on TDD vs DDD and Grails seems to support the DDD approach a bit better. Everything you see first on Grails "Getting Started" guides is creating a domain object.
Everybody's invited. Except this tiny ad:
a bit of art, as a gift, the permaculture playing cards