By Glenn Goodrich

Loccasions: Retrospective

By Glenn Goodrich


The Loccasions application now allows most of the basic functionality that I wanted to produce.  In the first post of the series that mentions Locassions (here), I set out with the following user stories:

  • As an unregistered user, I want to see the home/landing page
  • As an administrator, I want to be able to invite users to Loccasions
  • As an invited user, I want to be able to create an account
  • As a registered user, I want to be able to create Events
  • As a registered user, I want to be able to create Occasions
  • As a registered user, I want to see Occasions on a map
We did them all, except the second story dealing with inviting users. Since the first round of user stories is complete, I think it’s time for a retrospective. Also, this will be the last post in the Loccasions series for a while (if not, forever) as I am anxious to free myself of the shackles of this series and move on to other topics in Ruby.

What is a Retrospective?

If you’ve never been a part of a real retrospective, this post is not going to change that. While there are many definitions of the term in the context of software development, I take “retrospective” to mean a “short or time-boxed meeting where you discuss what went well, what went not so well, what we can do better, and how have our priorities changed.”  Usually, you have a team made of of product owners, developers, and other stakeholders to help review the latest iteration of your application. In this case, it’s just little ol’ me and 15 or so articles. In both cases, however, a retrospective is very useful and should be a mandatory part of any development process.

If you are the kind of person that is down with more formal definitions and the like, here’s a few to get you going:

I’d be lying if I said I did more than just randomly pick a few from a quick Google search, but looking through each of these, I saw the common ingredients:
  • A cup of How’d We Do? But not too much, it’ll ruin the dish.
  • A cup of What Went Wrong?
  • A dash of What Went Right?
  • A smidgeon of Planning Our Next Iteration.
That’s it.  If you put in too much of any of these ingredients, it is likely your retrospective will come out burnt, raw, or in some other inedible form. Under no circumstances are any of the following ingredients to be used:
  • Blame
  • Anger
  • Hyperbole (“Since X went right we should use it for everything!”)
In the end, the retrospective is about getting better, not assigning blame. We get better by learning from our mistakes and planning (“Plans are worthless, but planning is everything.” – Dwight D. Eisenhower) a bit better. Also, if your retrospective is more than 4 hours long, I would seriously question the value of anything beyond that time. Remember, the one time you aren’t improving the app is when you’re all sitting in a meeting overanalyzing/fighting/etc.

What Went Wrong?

I set out to make the Loccasions series an expose on developing a “real” Rails application, as opposed to the many contrived examples we see on the web. After my first “iteration”, I don’t think I fulfilled this goal. First off, it is the rare application that is the brainchild and work of a single developer.  Also, I made many decisions on technology, gems, and the like based on shaky rationale. If you remember, I chose MongoDB, basically, because I wanted to play with it. If this were a “real” app, I would have never made a decision like that.

In many cases, I became a bit careless with the code and the examples. This caused some of the articles to be very difficult to follow and me to end up with the dreaded “Well, It Runs on MY Laptop” type of application. It was only through the efforts of some Alert Readers (especially, Nicholas Henry…that guy is a machine) that this issue was mitigated somewhat.

I think I should have selected a deployment platform (which would have been Heroku, because it is how-you-say? SUPERFANTASTIC) early on and continuously deployed the application to it. That may have encouraged some more participation from the community, as well as made sure my technical decisions weren’t tromping all over deployment.

Also, towards the end, I all but forgot about the use cases. In a real application, I would have constantly been checking the user scenarios to make sure I wasn’t deviating from the path. At the end of this series, Loccasions may have turned out to simply be a more complicated contrived example of a Rails app, rather than the real app that I had initially put in my sights.

What Went Right?

With the negative out of the way, I think a lot of things went well with Loccasions. First, and most important, I learned a ton and had a good time writing the series. As developers, when we are enjoying our craft and we care about the problem we are solving, life is good. Also, I think the choice of Backbone for the client-side code was a perfect choice. The more I use Backbone, the more I like it. It’s just enough framework and just enough out of the way, resulting in a great coding experience.

I echo that sentiment about Jasmine. I have been hooked on Jasmine since I first found it, and it continues to impress. Again, Jasmine focuses on the bits that I don’t want to worry about, so I can just test my application. Furthermore, I think Jasmine encourages good javascript design, exactly like a testing framework should.

Lastly on the client, I really like LeafletJS.  If you need a map in your web application, I can’t recommend Leaflet highly enough. Beautiful maps that are a pleasure to code against make it my current “slippy” map of choice.

On the server, choosing Devise was easy and has proven to be a great choice. Quite often, gems with the popularity of Devise can morph into Sasquatchian mounds of unusable code, but Devise doesn’t feel that way to me.

Foreman, is almost an imperative now, in my opinion. Especially if you are deploying to Heroku, Forman just makes life easier.

Finally, I thought the pair programming episode with Evan Light was, arguably, the highlight of the series. In my new job, I work with Evan quite a bit, and he is every bit the Ruby brain and all-around good chap that I met writing that article.  I wish I had done more of this.

How to Get Better?

The easiest, and likely most effective way, to improve Loccasions is to involve other folks. By adding another developer or two, this application would improve tenfold. One of the mantras I live by is the importance of developer collaboration. My best work has never been done solo.

Another group of people whose involvement would massively improve Loccasions are users. Getting people to actually use the application and give feedback would drive the direction of the app, and of this retrospective. In my many years of developing custom applications, I’ve watched our industry/community evolve from treating users as necessary evils to appropriately putting them in the driver’s seat. I remember reading a blog post (the author of which I cannot find….sorry!) that stated (paraphrasing) “You can always tell when a developer has designed your application.” This is certainly true of Loccasions, it could use a Designer’s Touch.

What’s the Plan?

Whenever I start the next iteration of Loccasions, there will be no shortage of things to do and improvements to make. However, I need to plan where I would focus next. After careful consideration, I think I would focus on:

  • Deployment
  • UX/Design
These are broad terms, obviously. Drilling down a bit, for deployment I would push the app out to Heroku. As a part of it, I think looking into some kind of Continuous Integration server would also help iron out deployment and development scenarios. Investigating CI Servers is also on the immediate planning list.
For the UX/Design tasks, I think recruiting a couple of users and a bonafide web designer would be in the cards. If I could get some users to run through the application, give feedback, and get a designer to give the application a once over, Loccasions would be exponentially better.
Of course, there are specific tasks that go with each of these higher level planning items, but we’ll stop here. Loccasions was a lot of fun to write, and to write about. It may not be a seminal Rails work, but it covered a lot of topics and answered a lot of questions. Thanks for reading the series, for those of you that stuck with it. Maybe I’ll pick it up again in a few months.
  • Glenn, thank you for putting this series together. The whole series represents a lot of work, I know it kept me busy. It’s great that you put this retrospective together and I would like to share my thoughts.

    As you highlighted some of the code examples were difficult to follow, especially with refactorings that happened behind the scenes. Admittedly that made me think harder about what I was doing rather than blindly following along. A good thing. But unfortunately it meant that I abandoned the project on the last post as I had already invested a large amount of time and I needed to move on.

    Writing an application while learning new technologies is definitely difficult — especially writing a blog posts while developing the application. That’s probably why there was so much refactoring behind the scenes which made the code examples in the blog posts disjointed.

    Because of the length of the series, I fear that not many people followed to the very end. An e-book might have been a better format for this type of content, where you could have done a beta, done some refactoring, revised the examples and once it was solid released to the general public.

    Another option would have had someone following along with you to help edit the posts for inconsistencies before they were posted.

    Having said all that, you got me started on some technologies that I have been wanting to try out, and I’m pretty happy with the stack that I managed to get running for Javascript testing, test double framework, and templates etc. And for that I thank you!

  • Ivan

    Glenn, you started Loccasion series so cool and I was so excited when started to learn by your articles. All that TDD and tricky tools! But the far I proceeded, the less I understood. Does your code work at all now? Maps look messy in webkit, some jasmine specs fail and all backbone stuff won’t really work.
    Anyway, thank you, first half chapters of the series are really useful for me.

    • Hey Ivan,

      I am sorry you are having issues. The code still runs fine for me, and the maps look OK (in my opinion) in Chrome (which is webkit). I admit that, later in the series I was more rushed, so it probably shows in the articles.

      I’ll contact you via e-mail to see if we can’t work out the issues you are having.


      • Ivan

        Hey, Glenn,

        I replied on your email, check it out

Get the latest in Ruby, once a week, for free.