“If you got soft eyes, you can see the whole thing. If you got hard eyes — you staring at the same tree missing the forest” -Detective Bunk, The Wire S-4, EP-2

My First Post as an Automation Engineer

As a QA/SDET I have a hybrid role. For the SDET part we essentially write internal software for our team using the Ruby programming language and various web-driver libraries.

This software automatically runs a suite of test scenarios that we created to mimic a user interacting with our apps page, or our back end API where applicable.

Whenever our developers check in code to our dev environment (its first stop on its way to production) the suite runs against everything with their new code included.

The dev environment can be named anything, often it’s something like dev, qa1, integrationOne, or Silo_1.

QA

This post is about the QA part of my job, and how I first approach new features that are given to me to test. This part of my job I would argue is much more complicated than the automation part.

For starters the execution is far more abstract, while the consequences of “bad” QA is most certainly NOT abstract.

Imagine data being blown away never to be recovered, or a single customer receiving hundreds of thousands of emails for things they did not purchase.

We could go deeper and talk about how the QA process informs what will be done at the automation step of my job (SDET), but that seems like a future topic.

Object Names are for Humans

I love to write code, particularly code that tries to bring order to chaos, or my real favorite….code that tries to solve a problem that really does not have a clear right answer. Which is why the process I’m going describe is important to me.

When I’m writing programs in Ruby, I think of it as defining objects and then defining the behavior of those objects. I like to think that the object name is for humans while the behavior defined is for the machine.

In keeping with the theme of the quote at the top, we will define some objects as trees. All together those trees make a patch of forest someone ordered, which makes the forest the feature.

The Trees in the Forest

As an engineer what really interests me are the elements that make up the forest and the things that affect them individually.

Things like- leaves (light and moister absorption rate), the type and quality of the soil (nutrient and sediment makeup), level of light pollution, prevailing winds and erosion….you can see the pattern. Changing any one of those things will have an impact, could be small, could be big.

Maybe changing the type of soil causes the tress to fair better in the summer but is worse for the grass, and maybe all the flowers die off and never come back (which no-one saw coming!)

I am not a biologist but before I decide those things are not important I will need to observe them not being important, and that observation would be useless if done exclusively up close..in the “weeds” as the coder in me would.

Know something has been added. Assume nothing has changed.

My goal would be to interact with the environment knowing something has been added, but assuming nothing has changed.

If you read that and think that’s a pretty naive way for quality assurance to go about observing something, you are right, we are approaching the addition of this feature with “Soft” eyes.

In approaching the forest assuming that nothing has changed allows us to have a clean slate…which is good because the list of observed changes will grow fast!

Down from the clouds

I believe its good to start from a simple place, as it helps me to ask the questions that matter.

However it has been well documented that no plan survives the first few minutes of battle. In future posts we will see how that can play out in real life.

Names and details will be changed to protect the innocent :)

Post From December 2015

Reflections on TIY ATL

I got to meet tons of amazing and very very smart people here….not that there were not smart people in my life before…but once you walk through the glass doors at The Iron Yard….you can rest assured that the instructors and staff are very good at what they do. And your peers…your fellow students are going to be amazing problem solvers. We had many guest lecturers that are at the top of their fields.

To be successful here you must have the attitude that you will never give up…that there is always a way. And most importantly you must know how to work with people….I learned quite a lot by helping others de bug their code or fix their crashed server….probably some of my biggest highs were when I was able to help a friend that in turn would help me out with some gem or configuration I wasn’t used too. It’s telling the kind of experience one will have here when at the end of it, we all wish we could get jobs at the same place.

Reflections on Becoming a Junior Developer

One of our guest lecturers asked us if we could remember what it was like not knowing what we know now. For myself that is a definite no. While it was only three months ago the world looks a bit different. At the Iron Yard we spent countless hours of googling errors, reading documentation, and ploping our laptops in front of each other in an attempt to make sure we are not crazy and get some fresh eyes on our code. I’m not going say this was some spiritual awakening or anything, but doing those things day after day after day is bound to make you look at world differently, it will make you look at a problem and know there is a solution.

Getting lost to Help People

The immersive program at the Iron Yard first introduces you, and gets you comfortable with the “ecosystem” of programming. It’s a vast, beautiful, and scary world, full of libraries, and gems, and open-source code….good and bad documentation, and of course programming languages. It’s easy to get lost in all this and forget that this ecosystem exists to solve problems for people. It reminds me of my days as a music teacher when I would tell students that as soon as you decide that you are making music for a living, you give up your right to decide what good music is…the people that listen to your music will decide that. We could easily say the same thing about our code…that our code is good if it solves a problem for humans.

Reflections on What I’ve learned

This is definitely just the tip of the iceberg for the world of programming, and I am far from mastering any of these things…but here is a run down on the high level skills the Iron Yard has managed to cram into our brains.

In the first day you will get introduced to:

• The terminal
• The text editor of your choice
• Version control and how to push things to github

Here is some screen shots of my terminal with the “homebrew” theme (top), and my text editor called sublime (bottom).

Not all programming languages are complicated or hard to learn, but you need to know a few to be able to deploy an application. I’m listing these in a more or less hard to easy to learn top to bottom.

• Ruby
• CSS
• HTML
• SQL
• Markdown (which what is I’m using to make this blog post)

And here are some of the random technologies we have been introduced too

• Rails (Active Record)
• Heroku (Amazon Web Service)
• S3 (AWS storage for file uploads)

It’s humbling to think of all the very smart people that created these tools. All these things can talk to each other to create stuff. One of the coolest feelings is when you’re about to start a new project and you type into your terminal…

rails new [application name3]

and all sorts of files explode on to your screen

After this first step you have all the tools listed and many many more that put you well on your way to creating an actual web application that if coded correctly will always run and have safe and secure data.

This has been an amazing experience with amazing people, and I can’t wait to see what in store for us.

Postman Rocks!

So in the past 3 or 4 weeks we have been building apps with teams of front end engineers, and my workflow goes like this. Come hell or high water GET registration and login working and deploy to heroku. The front end hackers can get plenty of things working in theory but very little meaningful progress can be made until signup/login is working. Once the app is deployed we are not so dependent on each-other to start some meaningful hacking. On the back end I can then begin to build out my controllers and test them using postman which does an awesome job of simulating requests from the front end (user interface). However…. in order to simulate arrays, or an array of hashes or whatever, there is a few formatting things you need to know about using postman.

The Postkraken

Sending data to our local server, or our app is a pretty straight forward process. Postman has a very easy to use gui to get most tasks done.But… what happens when you need to test a method like this

def creates
  @words = params[:words]
  @words.map do |word|
    current_user.words.create!(word: word, category: params[:category])
  end
  @words= current_user.words
  render "word_create.json.jbuilder"
end

This method is dealing with a bit of json that looks like this

{
  word: => [dog, cat, bird, chicken, honeybadger],
  category: => animals
}

The method works just fine, but I held off deploying the change because I could not figure out how to test it locally. Copying and pasting the horrendous errors postman was throwing out when I tried to pass a variable of an array with the key word: actually broke google. Fortunatly one of my classmates Teri had run into a similar problem and showed me how to properly format the postman request, which looks like this.

Notice the brackets after word:? This tells postman to insert the value into an array, and will perfectly simulate the json from above.

Victory!!!

So yeah I got to strut around for like ten minutes…feeling like a computer ninja! Front end can add as many words into a category as they want with a single request and my code will take care of the rest.

The Next Postkraken

Ok so my team can create words with a single request…great. Now they want to edit in a single request. In theory for me not so difficult to figure out…maybe. Long story short here is the javascript object (json) they would send me and the way to simulate such a request in postman.

{
 words: => [
            {id: => 1, new: => "kola"},
            {id: => 2, new: => "kangaroo"},
            {id: => 3, new: => "tiger"},
            {id: => 4, new: => "dragon"},
            {id: => 5, new: => "python"},
]}

Which will hit this method in my controller

def edit
  params[words:].each do |new_word|
    word = Word.find(new_word[:id])
    word.update(word: new_word[:new])
  end
end

And here is the way to properly format this

Again more brackets in the key side on postman. Also notice that it matters the order you list them in on postman. It has to go words[][id], words[][new], and so on.

Link to My old Blog

Since starting to make my portfolio last week I’ve decided to start using Jekyll for my posts. If you would like to read about my earlier weeks learning to code you can click here. I have some screen shots of old code and the problems I encountered with the weekend projects during the first weeks at the Iron Yard.

Started Final Project

My team started our final project on monday. By noon I had sign-up, and log-in working and deployed as a heroku app. Before I left for the day I also had create words up and running for the 2 man front end team to start making words. Yesterday (Tuesday) I got all the search and matching functionality working. If your curious I have the API DOCS here. Tomorrow if the front end has more of the functionality set up I will likely work through whatever issues they might have, if not I plan on getting either twillio or mandrill integration up, or at the very least get some tests written. Ive also been putting in quite a bit of work on portfolio (including this blog and learning how to use jekyll), here is my piktograph link.

Final projects week

So we are about to end our break and tear into our final projects. I did not pitch any of my ideas, not through lack of ambition but more from my desire to tackle someone elses problem and make a working back end that handles what they need. The app I will be working on has a working title of “5-words”. A user will starts out by selecting 5 interests in a “Golden” category. The user can than search for matches in that category based on the 5 words they put in as their interests. This presents a few challanges for me that I have not encountered. For one the database design is not something I’ve encountered yet, I’m thinking it will require a 3 way join table, however there are other options and I will start to see which is the best way to go tomorrow.