Automation problems…

Posted by pidtom | Posted in Brogramming | Posted on 21-01-2014-05-2008

0

http://xkcd.com/1319/

 automation

 

This comic can be very true when you are new to automation or just don’t understand what you really need automated.

 

When you are new to automation you tend to not think about lastability of the code you are writing. You tend to whip up your automated workflow as if you are trying to fill in an array the first time in your intro computer science class. It would usually contain a lot of hard coded values and quick hacks in order to get what you want. Sure, this might work the first few times you need it but as soon as variables, names, or ¬†functionality of¬† your work flow changes, or even if you change the work flow itself, you will be putting your “copious” amounts of spare time into maintaining and debugging your code. You will cry in the corner with your bottle of Macallen 12 go back to writing “hello world” scripts to feel confident about programming again.

 

The other side of the coin are those that have experience but don’t really know what needs to be put into the work flow before automating it. This is usually due to assumptions about the environment and lack of proper planning. There is never any shame in mapping it out on a whiteboard and researching questions as you go.

 

In order to reap the benefits of automation it will take you a bit of time (if you ultimately don’t want to update and maintain it every waking hour). It’s worth spending the extra few hours at the end of your coding process to create proper functions, document, and touch up your code. Planing out automation should be given as much care as developing a product, especially if others are going to consume it.

 

Things to consider before beginning your automation:

1. Is the process you are automating subject to a lot of change? Unless you are in QA and need to have regression testing for changes in code, you should rethink what you are automating or just stick to one version of the different products you are working with.

2. Does the products you are automating have APIs? If so use them. Don’t re-invent the wheel. You will also get notices when APIs change so you can adjust code accordingly.

3. Will it take more than a week to automate? If the answer is yes, then make sure what you are automating is really worth your time.

4. Is the automation important enough that you would run the steps manually again? If repetitiveness of what you are trying to automate is high then this is likely to save you time in the future. If not, it might be worth it to take the manual steps as a hit… In other words, there are probably more important things you want to automate and you will be more motivated to do something right that you expect will save you a lot of time.

5. Are you making a lot of assumptions before automating? Are you just saying to yourself “of course that can be done.” While this is true, the complexity of the direction you are going might be exponentially harder than you originally planned. Take time to investigate what you are automating, why you are automating, and the depth of complexity you are undertaking. (unless you are specifically making a product where you automate a ridiculously large workflow).

6. Remember that there is always more than one way to do it.

 

Cheers

Scotch Ale in Carboy

Posted by pidtom | Posted in Uncategorized | Posted on 25-11-2013-05-2008

0

image

I started brewing again and upped NY game. I decided to go with carboys, glass fermenters, from now on in order to prevent infection. I think food grade plastic can get cuts and result in bacteria that can’t be cleansed from the fermenter.

My Recent Experience in Perl Automation

Posted by pidtom | Posted in Brogramming, Perl | Posted on 07-11-2013-05-2008

0

A few months ago I joined a new team and had the opportunity to create their automation framework. Before this I was just contributing to automation and using libraries that other people made. Needless to say it was a blast and a tidal-wave of knowledge which fruits are giving my team logging information and ease of automation that they had never had before. Dealing with my companies internal framework was pretty complex and gave me a lot of insight on how object oriented perl frameworks should be. However being complex in the backend is not a bad thing; it makes the automation flow much easier for implementation and code reviews. A key feature in this framework was keeping the libraries independent from the operating system since this product works on both linux and windows. Basically, by changing a testbed configuration from windows to linux and running the automation, it should not fail due to operating system differences leaving the automation

Even more recently I developed a newer method to create basic regression test cases. Since I work in the SNIA and Open Pegasus world now, it enforces a certain standard of commands that gives you enough information to automate the creation of test cases dynamically. That’s right! When you look at the code there isn’t a single test case present but it builds them based off the current build. If objects are created or removed, the automation would automatically add that new test case during runtime and push the result to the test case database. This way our nightly runs will always have the basic regression test cases for new objects created.

Perl usually has a bad rap for readability and magic variables… the whole “there is more than one way to do it” saying, gives a lot of programmers fear in deciphering the cryptic code and documentation it can carry as baggage. Especially when you see comments like “#black magic beings here”. But proper code reviews and coding standard enforcement can fight a lot of that.

Bottom line, OO Perl is awesome and its flexibility gives you numerous ways to implement new ideas. Having this much control over the framework’s creation is like giving regular automation development steroids.

The Wait for Half-Life 3

Posted by pidtom | Posted in Gaming | Posted on 02-11-2013-05-2008

0

For those that are Half-Life fans and have been waiting for Valve’s installment of the game with a 3 at the end of it know the feeling portrayed in this video. If you are also not a Futurama fan then this won’t make too much sense.

My First Montage Video of Airchairing This Summer

Posted by pidtom | Posted in Boating | Posted on 01-11-2013-05-2008

0

 

 

Cloud9 Programming… A Halloween Scare

Posted by pidtom | Posted in Brogramming | Posted on 31-10-2013-05-2008

0

So I came across this Google chrome extension and it looks awesome with a scary twist. Cloud9 is perhaps the one of the best cloud IDE’s I have seen so far but with one drawback that is pretty scare… real time team collaboration. It allows you to edit code in a format that is similar to Google docs. So everyone can be editing it at the same time. If you haven’t already seen this problem through a programmers eyes, imagine having at least one person who is prone to many syntax errors. Scary indeed.

 

 

 

https://c9.io/

 

Water Skiing Angle

Posted by pidtom | Posted in Boating | Posted on 30-10-2013-05-2008

0

I keep going back and forth between water sports. Lately I have been indulging in water skiing a lot. When you start to get better at water skiing, you start to make the rope length shorter which increases speed across the wake as well as difficulty in the cut. Lately I have been skiing with 28ft off and have been getting wonderful results… as well as some shenanigans:

This is why I put on headphones and look the other way when in deep thought…

Posted by pidtom | Posted in Brogramming | Posted on 29-10-2013-05-2008

0

http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer

Dancing at the Tough Mudder

Posted by pidtom | Posted in Uncategorized | Posted on 31-07-2013-05-2008

0

Watch “Two Air Chair Back Flips in a Row – GoPro Head Mount” on YouTube

Posted by pidtom | Posted in Uncategorized | Posted on 28-07-2013-05-2008

0