I believe that test-first and continuous-deployment are important characteristics of Agile Web Development. That’s why it bothers me that Testing isn’t properly introduced until page 205 of AWDwR3, and deployment until page 651. I am also aware that not everybody who comes to this book has the same background and experience.
I’m experimenting with a number of ways to address this, and this is my current iteration. The basic idea is a section that goes immediately after the Instant Gratification chapter (or replaces it) which can be skimmed or skipped by people who simply want to get on with learning Rails. The section is heavy on testing, git, and Capistrano, and touches lightly on ActiveRecord and Rack and Whenever, the latter because I wanted to do something useful and demonstrate deployment without introducing something that wouldn’t be relevant once we get to the point where we are talking about Rails.
A secondary consideration is that I feel it is important to provide a contrasting alternative so that people can see the tangible benefits that Rails provides. I touch on some of these points in the overview to the Rails section. In particular, sections on raw sqlite3 insert and update could be dropped. For the moment, they are there as they also provide additional motivation for migration.
A third consideration is that I prefer a scenario that naturally flows into the subsequent chapters where the Depot application is introduced.
A byproduct of my script is that it produces a git repository that one can pull. Over time, I can add tags so that people can advance to specific points in the scenario and examine the code at that point.
Feedback welcome.
Awesome - this is something over half the things I wished were in the book, all addressed in one blog post!
Also, I love the idea of learning to develop a ruby webapp directly on top of Rack. That would give people some exposure to the actual api all these ruby web frameworks are being written to.
Seems like a good idea, enjoying reading through this.
A couple of thoughts: in step 1.1 you could use File#open(path) {|input| #read file here} since that automatically closes the file handle at the end of the block. good ruby practice, I think.
You could then use open-uri instead of ‘net/http’ in step 2.3
That will also fix another problem: the moment its not obvious that you actually removed the “input.close” call at the end of the code, that will lead to “undefined method” errors for your readers that forget to remove it
As an extra bonus, it would simplify the implementation of Product.import in 3.1 to
def self.import(source)
open(source) do |input|
#load xml
end
end
(which will also, incidentally, fix the bug where input wouldn’t be closed in Product.import if it was a file)
you could use File#open(path) {|input| #read file here}
I like the use of the block on the File.open call. The reason why I did not originally do that is that by passing a file handle to REXML there isn’t the need to read the entire file into memory before proceeding. Of course, by not being consistent and using a StreamListener, I completely destroyed my credibility. :-)
You could then use open-uri instead of ‘net/http’ in step 2.3
I’m loathe to use open-uri. Don’t get me wrong, open-uri is a great thing, and I use it all the time: in applications. I just don’t think it belongs in frameworks as it creates the potential for unintended consequences and potentially even security issues.
So... my preference at the moment is change everything to read into a string, and to include one paragraph each on open-uri and StreamListener, with the latter perhaps even being an exercise for the student.
We have often a few more environments for developing and deploying.
local: the machine of the developer
latest: automatic deployment on a common server of all commits
qa: environment for internal testing
preprod: environment for client validation (not accessible to devs)
staging: a hidden prod so we can test with real data and traffic
prod: The actual site.
When developing the first version of a Web site including a CMS with a DB. There is mostly no issue.
The first issues appear when the content is edited by a third party (the client and/or a marketing agency for the client). This can be solved if the planning is alright and the development is finished before the content editing.
But the most interesting issue is when dev and content editing are happening at the same time. There will be a point where merging will be mandatory. And that makes it very difficult. We have to freeze and reimport parts of the DB.
This issue is becoming even more interesting when the site is mostly a platform for social networking. A lot of editing is happening in real time any time. There is the concurrency of new features development for the new version (with change of models, architecture sometimes), the bug fixing in the current version and the edits of Web site users.
Deployment scripts and strategies have to take into account that.