Author Archives: Peter

About Peter

Husband, father, developer. I enjoy life, love to talk about all things IT, and I run mostly on coffee and pizza.

AWS assume role with Fog

Posted on by

Amazon Web Services (AWS) provides users with a wealth of services and a suite of ways in which to keep those services secure. Unfortunately, software libraries are not always able to keep up with all the new features available. While wiring up our Rails application to deposit files into an AWS S3 bucket we ran into such a problem. AWS has developed an extensive role-based security structure; and as part of their Ruby AWS SDK they allow a person, or role, to assume another role which may have completely different access.

money-patch-croppedOur troubles came in the fact that the interface provided by the fog-aws gem does not currently have any way to tell it to assume a different role. It does provide a way to use a role your server may already have been assigned, and a nice mechanism to re-negotiate your credentials when they are about to expire. So what do we do when something doesn’t quite work the way we want? Monkey patch!

Below is a link to a Gist showing how we were able to leverage the things fog-aws did the way we wanted, and overwrite the one thing we needed to be done differently.

https://gist.github.com/peterwells/39a5c31d934fa8eb0f2c

 

We are poets!

Posted on by

So I just finished day two of RailsConf, and I had a very interesting experience. My final session of the day was held by an actor-turned-programmer by the name of Adam Cuppy. He started things off with a quote by DHH from last years conference, where David challenged everyone to see themselves not as software engineers, but as software writers. However, he showed how the term writer has no purpose behind it; simply a description of things a writer has done. Taking a look at synonyms leads to the word poet. Examining poet shows us that a poet has super-powers! Now who doesn’t want super-powers? And one thing everyone knows is that a person with super powers has the responsibility to use them for the betterment of others.

Through this super-power of expression, poets are able to relay meaning and feeling with their words. They are able to use the syntax if a language to convey feeling, and paint a picture in the reader’s mind. And so too are we challenged to paint a picture with the language we are writing in. Just imagine for a minute, how easy it would be for a new programmer to a project to on-board if the application code they were looking at read like a play? What if we could engage this new person and made it not only easy, but enjoyable for them to learn the application?

Think about the last time you began on an existing code base. What did you spend the most time trying to learn: the how of the program, or the why of the program? With forethought and planning, we can develop conventions that make it easy to discern the meaning of our code. If we can make it easy for someone reading it to know how this method fits into the application, they will be able to see the while picture much more quickly. And think how beautiful that picture could look.

So I echo his enthusiasm: go forth and be poets! Give meaning to your code, and do something great.

Lessons in Rails: Email is slow

Posted on by

Now that my first Rails application is in production, there are many things I wish I would have know at the onset. Not the least of these is how slow (to send) and tedious (to implement) email messages are within the framework. Snail Mail Firstly, the creation and maintenance of mailers is just tiresome. Having multiple views for each message; not to mention keeping the text up to date. Second, being new to pretty much all things web based, I initially inserted all of the sending of emails into the main request/response cycle of the controllers. Needless to say, once we began load testing we started to see terrible performance. A lot of timeouts, and ugly blank screens coming back. Upon investigation, we determined that the emails were the culprits. Being a functional requirement, and therefore unable to be done away with, what were we to do?

We decided to do the same thing you do with anything that is slow and bothersome: we made it someone else’s problem. To address the maintenance issue we created one mailer to rule them all, and pushed all aspects of all the messages into a database table. This, combined with a nice variable substitution object, allows the end users to maintain the emails their system is sending out. This simple move made everyone on both sides extremely happy (and happy customers make happy bosses).

Next, we farmed the sending of the messages off to a queue background job. Since we are using a Postgres database, we decided on the Que gem. The setup for this was super easy, and can even be configured to work with your testing framework so as not to invalidate that wonderful suite you have going. Implementation was straight forward and we instantly saw improved performance.

I plan to use this paradigm for every application I have in the future, and I hope this helps another new RoR developer avoid learning this lesson the hard way.

Enthusiasm – it’s contagious

Posted on by

I just interviewed a guy today for a position as a Ruby on Rails developer. This would be his first software development position, having previously worked as a customer service rep for an insurance company. His background includes a degree in film, so not your typical coder back story. He was a confident guy, well-spoken and quite personable. While speaking with him I could feel how excited he was at the prospect of continuing to work with the platform. But it wasn’t just what he would be doing, but also where he would be doing it. He complimented the campus (something you hear a lot about Notre Dame), was even happy about the color in the trees, but he stated that he couldn’t wait to help work on things that would influence change. To him working in a higher education setting, having the ability to impact the students and make a positive change for the world as a whole was quite invigorating.

I found myself coming out of that interview with a new energy for my position. I think too often we start to take for granted where we are in life, and forget to really appreciate what we are doing and the influence we can actually have in the world. I have a really cool career, get the opportunity to work with some really great people, and no matter how long the walk is in to work everyday the view is always incredible. So as we look to the future in our careers, trying always to get somewhere better, remember to take a moment and remember what made you so excited when you first started down the path you are on.

Why test? Simplicity. Security.

Posted on by

One of the biggest complaints I’ve heard about Test Driven Development is that developers don’t feel like they have the time to create the additional code in the tests. I completely understand the feeling. Lets face it, as developers we hardly ever hear from our customers “Take all the time you need.” It always seems like we either need to have the wanted functionality finished yesterday, or we have so many projects going at once that work feels more like a juggling act; doing just enough on each one to keep the wolves at bay.

But I would argue that this time crunch is exactly the reason we need to be writing tests, and letting these tests drive our solutions. A recent example demonstrates how testing creates simpler, better defined code you can feel better about.

A month, or so, back I was tasked with adding a new member class to a new Ruby on Rails application I am working on. This required adding fields to forms, adding entries to some underlying tables, and substantial changes to the object we had backing the forms. All pretty routine stuff. Because I am fairly new to Rails, and I wasn’t completely sure on what behavior I wanted the application to have, I just started writing the application code; figuring I would go back and cover with testing once finished. Adding the needed fields and database entries was pretty straight forward, taking very little time. I then spent the better part of the day putting the needed functionality into the form-backing object (namely adding and updating the new member class).

I started by copying similar behavior already in place for a different type of user in the system. Seems like a logical step, right? Should be pretty safe and straight forward. It wasn’t long before I started getting very uneasy about the code I was writing. There were more than a few conditionals, fragments of code in multiple places, and, most importantly, I wasn’t sure it was even doing the thing I needed to have done! This is a very scary way to feel. I quickly realized this was not going to work and backed out every change I had made to this object, choosing instead to start fresh the next day with some fresh eyes and a partner to do some pair-programming with.

The next morning we started out fresh, being sure not to write a line of application code without first having a test to cover what was being done. In true paired-programming/TDD fashion we alternated writing test and application code. By the time we were done, we had written fewer lines of application code than I had previously, had a nice little suite of tests, and, most importantly, we were confident the application now did the thing we needed it to do! So not only did we achieve better code through testing, but we did it in less time than I had spent by myself doing it the wrong way.

So remember: you may not have a lot of time to get the work done, but you always have a choice in how you do the work. And in the long run, better written code backed by tests will help you sleep better at night.

bear-sleeping-on-rug

What’s in a User Story?

Posted on by

stickies

As I started out in Agile software development, as a lowly intern, I was bombarded by jargon. Terms like ‘scrum’, ‘sprint’, ‘velocity’, and ‘TCC’ came flying at me right from the get-go. With hardly time to create a mental dictionary of these new terms, I found myself in meetings with product owners, a senior developer, and QA person, all talking about how to implement the current ‘user story’. Having little to no background, I more or less mentally checked out until the meeting was over and we had a list of things that actually needed to be done; which meant I could now go and do what I knew, write some code.

Being the intern, I never had much insight into where these magical statements of desired functionality came from. All I knew is that when I was done with my current work, another developer and myself would pull the next user story from backlog into TCC, and schedule a meeting like the one above. I didn’t give any thought as to how these nuggets of work came about; I only viewed  each as the next problem to tackle. And I will admit that I was quite happy in my ignorance. Work was full of doing the thing that I enjoyed, without much distraction.

Skip ahead a few years, and I now find myself on the other side of that coin. Often my days are filled with meetings, attempting to discern what it is a customer really needs; as apposed to what they think they need. This can be a very difficult time for anyone who is very technical in nature as functional users are not very specific in what they need. I mean, why can’t they just tell me how much remote file storage they need? or exactly what firewall rules they need put into place? It’s their application after all, they should know how to make it work! And really I just want to get to coding as soon as possible.

Unfortunately the world is not as such, and we need a way to capture what a customer WANTS not what they NEED. And this is where the user story comes in. User stories are a great way to capture the function that the customer is needing to perform. For example: “As a user I need a place to store uploaded pictures to include in reports later”. Sounds simple, has a straight forward objective, and is easily understood by everyone involved. It does not give any indications as to where to put the pictures, what format the pictures will be stored in, or how many a single person may be able to store. These are all details to be sorted out before implementation. Because we aren’t bogged down at every step by all the details, the project team can spend their time figuring out what they want their program to do. Which is great, because who really knows how an entire system is going to be implemented until you get in and start making it anyway?

The important thing about a user story is to capture WHAT the user needs to do, and WHY they need to do it. During the TCC these two parts serve as the focus for implementation, and getting them down in a clear form makes things much easier going forward. I’ve included links to some other resources below; which elaborate on this topic. Thank you for reading, and happy requirements gathering!

Agile Atlas | User Stories

User Stories and User Story Examples by Mike Cohn

Project Advantages of User Stories as Requirements