Personally we’ve found RailsCast videos really useful while learning different aspects of Rails. Watching someone guide you through putting all the relevant pieces together is a great way to help understand things. Watching someone doing something is always better than reading about it in a book. Given this, and the fact that Konstantin has been wanting to SinatraCast for a long time, we thought it would be good to make some screencasts of what we ourselves were learning with Sinatra. They could act as a useful tool for others wanting to build a simple Sinatra app :-)
Screencasts, however, take forever to make. They really do. It’s all the finicky setting up of files and windows and timing everything properly and giving good voice over. Not to mention how long it takes to render and export video files and upload them to the web at a decent quality. Before you realise it the day is almost over, and you’ve only managed to record half of what you wanted (and not nearly as well as you’d like).
Take 25 anyone?
Luckily we were able to use Camtasia, an indespensible piece of screen-capturing goodness, and break into some 7 minute workouts while we waited for video to export.
For now, Tutorial Part 1 is finished. It’s somewhat rough and ready, the sound is a bit dodgy, and we used a version of Ruby we shouldn’t have (1.8.something) but it’s a start. You can download a copy of the finished files for the app here. And fyi the best online video wesite for serving screencasts seems to be Screencast.com which doesn’t compress your videos in any way (unlike YouTube or Vimeo). This means that the image doesn’t lose any detail, which is very important when your video is filled with pages of relatively small type/code.
Checking the documentation and looking at the error back trace was the theme of today. We though we’d sucessfully implementing the date validation on Friday afternoon, but we realised over the weekend that it was only working properly when we created a new song, not when we updated a song.
Matt left us in the morning with the task of working out how to fix this. His parting words were “Check the documentation and read the back trace”.
We spent most of the morning doing the following:
The issue (we eventually realised, with Urs’ help) was that we were checking validation not on the newly entered data but on original data in the song. We had to instead make sure we were checking the updated data. This meant changing
song = Song.get(param[:id])
if song.valid?
to
song = Song.get(param[:id])
if song.update(params[:song])
It only took us 3 hours to work this out :/
We then tried to customise the error messages that DataMapper raised. And had some success doing this. But still couldn’t manage to override the default error message on the date field validation. We might look at this again tomorrow.
We switched to preparing for the screencasts we plan to record for our https://github.com/inchworms/songs_by_nancy/tree/Tutorial-Part-2sample app tutorial, changing our outline a little:
Building a Basic Website - Screencast Outline
Part 1 - Installing Sinatra, Basic Requests, Routes,
Inline Views, Using Sinatra Reloader, Dynamic Variables
Part 2 - Layouts, Folder Structure, External Views,
Partials, Instance Variables, Images, CSS
Part 3 - Using Static Data, Deploying to Heroku
Part 4 - Using a Database, Add/Edit/Deleting, Validations
We wrote rough scripts for Parts 1 & 2, and created branches in github where people will be able to download relevant files: Part 1 and Part 2
Tomorrow we’ll start recording screencasts for these…
We got most of our form fields validating but couldn’t work out how to handle the date field.
We did discover that some browsers (eg Chrome) automatically display a funky calender selector input thingy if the html form input type is set to “date”:
<input type="date" name="song[released_on]">
Which looks a little funky, if you ask us:
So since Firefox ignored “date” as an input type, meaning we’d need to reformat whatever was entered with a Firefox browser into something our app would recognise as a date, we decided to make the input type “text”. Less code to write and more uniformity across browsers…
But we still had trouble working out how to code things in a way that would force the user to enter data in the format we needed (dd/mm/yyyy). After several failed attempts we decided we need detailed coaching help, so while we waited for that we went back to version 1 of the app. We tidied it up and deployed it to Heroku. You can now visit a working version online here.
Next week we’ll start recording screencasts to guide viewers through all the steps we took to build the different versions of our apps. Our plan at the moment is to put the relevant code for each step into a seperate github branch - but Carla’s thinking it might be better to simply make a seperate section in our inchworms blog gh-pages for any tutorials we create and embed the code there. We’ll work all this out on Monday.
So, we’re almost at the end of week one, and we’re more-or-less on track. Matt’s due any second to help us crack our date validation conundrum, so hopefully we’ll solve that before today’s close of play.
Locally grown, sumptuously sweet, and the surest sign that summer has arrived in Berlin.
We should have known this was merely a ploy to distract us because shortly thereafter Matt had us refactoring upon what we had already refactored, apparently to make our app better (but which we thought made it more confusing).
So, while we finished the strawberries, we decided (unanimously) to put his suggested changes into a new branch titled matt is evil.
Then we went back to our master branch.
We added error handling, for cases where users try to load dodgy urls (and by dodgy we mean urls pointing to things that don’t exist, like ../songs/1/mattistboese), then we continued with v2 of the app.
irb(main):001 > This is when our love for irb grew even more.
We’re basing our sample app on the one Darren Jones builds in his Jump Start Sinatra book. But while he uses slim (an html rendering engine), we’re sticking with erb. Consequently there are a few differences between his syntax and ours, which meant our app started throwing errors. At one point, for example, we couldn’t work out how to delete one of our database objects. But by using the irb console we were able to test what worked and what didn’t before writing too much application code. It was time efficient and much less annoying than writing code, saving the file, refreshing the browser window, reading through the error message, writing more code, etc…
We spent the rest of the day implementing the ability to create, edit, and delete songs and added a bit of rudimentary styling.
Tomorrow we’ll be adding validation to our form (to make it check for any input errors - like a badly formatted date entry for example) and breaking our screencast outline into bite-sized chunks.
Today we started creating version 2 of our app using DataMapper to implement basic database functionality. But before we could finish this Matt wanted us to improve our initial version of the app by converting our data directly from a csv file into Ruby (thereby circumventing the need for a JSON file altogether).
This was easier said than done.
Four hours later we were bashing our keyboards with traumatised fingertips and jamming our over-clocked irc clients with copy-pasted error messages (Anja uses irssi by the way. She is übergeek).
Anja was in need of ibroprofen or earplugs (or both), and Carla needed to lower her voice a little. What seemed relatively simple with JSON.parse was completly confounding with CSV.parse. Most of it boiled down to the fact that JSON could pretty easily parse an array of hashes, but CSV needed more coaxing. ANYWAY. Urs thankfully indicated a few blindingly obvious syntax errors that had been staring us in the face all along. A missing comma here, a misplaced curly bracket there, you know the drill. It really is true that staring at code for hours can make it impossible to see.
Meanwhile, if that didn’t make the day crazy enough, Konstatine had his own vision impairments, spending most of it searching for a piece of code he just couldn’t find…
