By Glenn Goodrich

Loccasions: Retrospective

By Glenn Goodrich
Last chance to win! You'll get a... FREE 6-Month Subscription to SitePoint Premium Plus you'll go in the draw to WIN a new Macbook SitePoint 2017 Survey Yes, let's Do this It only takes 5 min


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.
Login or Create Account to Comment
Login Create Account
Get the most important and interesting stories in tech. Straight to your inbox, daily.Is it good?