Revising Stories with Rails

I love rails. I love that I can sit do and just sweep through the model layer, building out all that abstraction for an applicaiton within a couple hours at most. Likewise with the view layer, using the prebuilt urls (new,create,show,edit...). Reusing partials throughout, so I can take a static site and use some of the partials to build a dynamic one. It's fucking beautiful.

That said, when I first got into Scrum and was looking out building stories within the rails framework, it occurred to me that a lot of what made rails fast for development didn't exactly work for how I was writing stories. So I had two choices - change how I developed in rails, or changed how I wrote stories. 

Well, it was obviously not going to be the first, so I changed the second. The main change wasn't so much the stories themselves, but the expectations that followed teh stories.

For example: "User can save a new contact." Off the cuff, this sounds like it would require a build from the model to the view layer, especially if the contact form was actually a lightbox or some pop-out, which would require some JS/CSS magic. Rails exposes that this may be a too big of story, or maybe that I need more backlog items in order to actually cover it.

Here's what I built instead:

- A new contact can be saved.
- A user can save a contact through a webform.
- Webform is integrated into the dashboard and a user can save there dynamically. 

How the last two make sense as added features and they fit with my eulogy to rails above. First I build a form using the standard new template, then I render that as a partial once I get to dashboard integration. In this situation, I can do tests against the form, and leave all the work of the final feature to template/visual work rather than submission/controller work. 

Finally, the first feature, segregates the model work to its own feature. A great way to confirm this functionality is to lean on the Unit test system that comes with rails. Now I could theoretically put all of my model tasks into one sprint and have verification of my feature, with the additional benefit of always having the ability to easily do regression testing. 

Clients may not find this as sexy, but I think most folks get that setting up saving is the first step in building an application and the UI comes next, even if all you have to show (if required) is the console confirming save and data retrieval. 

Why I switched my team to Sass after about 15 minutes

Chris Coyier | TXJS 2013 from SlexAxton on Vimeo.

After one of my team members sent my company's dev crew this link the other day, I decided to spend some time this weekend incoprorating Sass into my workflow for an upcoming web app. 

As my spoilers in the title indicate, I have now decided that my team is going to be required to use these tools. There was initially, not a lot of resistance, but just a plain lack of interest in these tools at my company. All but one of us really didn't feel much push to start using a tool that we felt saved us very little time and could possibly screw up our workflow. 

Well, here I'll say that I was wrong. Sass is excellent and I'll just bullet point this:

- I can continue to use CSS the same way as before, especially with automated compilers. There are other tools like CoffeeScript that yeah sure I type less, but now I can't work in JS.

- It's intuitive as hell. I only spent a little time with the documentation and the code was doing exactly what I expected even when I simply guessed its style.

- Sass allows me to have a base variable to store things like color definitions in one place. Now if only I could get object classes in Sass.

For me, the biggest issue was that Sass meant processing got added to realm that previously didn't have it. Processing adds complexity, which adds the likelihood for bugs. The reason this doesn't matter is that CSS is already pretty screwy in that small typos already completely fuck up entire sheets, and the processing with Sass is so low level that anyone who has programmed for a shortwhile won't be confused by method. 

The biggest point is that Sass is tooling done right - turning a shorthand into actually workable commands within the existing CSS framework. Other modifiers tend to force your hand to only work in shorthand, but as a coder, you want both availble. Sass does exactly that. So if you don't work for me, you may not be required to use Sass, but I would recommend you try it.

Godspeed coders. 



Subscribe to Coding