Monday, September 28, 2015

Node.js and MEAN stack tutorial reviewed

Staying on top of tech trends is part of our jobs.  The days of just knowing say... COBOL and that is all you know are long gone.  If you are not expanding your skill set through regular if not daily learning you a falling behind.  Everyone has there own method of learning and you should find what works best for you.  If it is reading books then check out https://www.safaribooksonline.com/. If it is taking online classes there are sites like https://www.udemy.com/.  Do what works for you but always be learning because not only it is cool learn new stuff but your career as a programmer requires it.

...Rant about continuous education over...

First off I am not a Node.js rock star, but I know the power of Node.js and the rising popularity of it.  Being able to say I was a master of the JavaScript and Node.js universe would would be amazing.  Which is why I learn about it even though my day job doesn't have anything to do with node.  Although I do like to throw in some Node.js from time to time for utility applications.

When you see charts like this on Indeed.com there is no denying that there is demand for people who learn Node.js:




So along comes this Node.js Tutorial which I of course have to read and follow:
https://blog.udemy.com/node-js-tutorial/


The author, Moshfegh, clearly knows he stuff and is passionate about helping people join him in the Node.js ecosystem.  He doesn't just write about Node.js but also covers the entire MEAN stack. (MongoDB Express.js Angular.js Node.js)  Before Node.js JavaScript only executed in browsers but then in 2009 that barrier was shattered.  With JavaScript on the back-end and the front-end engineers can become experts in one language and create quality code that follows the same standards on both tiers.  While I am tempted to go more into the wonders of Node.js and the MEAN stack I must defer to the tutorial because he is better at it then I am.  Hopefully with his tutorial and a little practice I will be able to teach others.  The blog post is just the beginning.  The author is creating his own course on https://www.udemy.com/ to expand upon the material he was able to cover in a blog post.  So if you enjoyed the post like I did you will be able to learn more with a course of the same level of quality.


Happy Learning.

Friday, September 25, 2015

Programmer turned Home DIY Enthusiast

Programmers are smart, educated, and logical so hammering a couple nails should be no problem for us.  That was part of my mindset when I took on a massive home renovation this summer.  We were running out of space for our growing family so we needed to expand.  The plan was to gut the second floor and reclaim some storage space and in the process add a third bedroom on that floor.  I know I didn't have time to it all myself so there would be subcontractors hired but I was convinced I wouldn't need a general contractor because I could take care of that myself.  After all I was smart guy and had done a few projects around the house... I could do it.

Being your own general contractor is like starting a new job as a project manager in a field you just have a vague idea about. The project you are assigned to is also one of the most important in the history of the company so there is little room for error.  That is what it is like being your own general contractor on the side.  Oh did I mention that being your own general contractor also means you have to get your hands dirty doing the parts of the project you don't have "staff" to fill?

So what is a savvy coder to do when faced with such a challenge?  As a programmer what do you do when you have a vague idea what to do but are not sure of the details? Google. 

What I hired people to do:
  • demo existing space
  • frame the dormer
  • put the roof on
  • put siding on
  • electrical
  • plumbing for heat
  • carpet
What I did:
  • insulation
  • drywall
  • sub floor
  • paint
  • trim
  • baseboards
  • window casings
  • hang doors
  • and many more odds and ends

The biggest lesson learned was to find a mentor and don't be afraid to ask questions.  There is a lot of know and frankly a lot of the techniques and tips are unwritten and you either learn the hard way by doing it wrong or you ask questions.   Just like in programming google can only get you so far.  You need to have a mentor, a proper teacher, or a quality book on the subject to understand how to do it without a lot of growing pains.

Inspections!! There are a lot of inspections, permits, and plans required with this type of a project.  The regulations and red tape can grind everything to a halt if you don't stay on time of it.   This is just like in the coding world.  Your project can be crushed if you do not know how to operate within your companies policies and know who to go to get sign off on things and overcome road blocks.

Coordination was critical to getting this project done.  Every step has several preconditions that need to be fulfilled.  So for example to hang drywall you need the drywall delivered, rent a drywall jack, insulation inspection complete, rough electrical done, rough plumbing done, and stuff like that.  Just like in the software project management world if one precondition isn't fulfilled things grind to a halt.

I cannot express enough how great of a learning experience this was not just as a homeowner but as a project manager.  The struggles were real and stressful but in those struggles there was personal growth.  Next time I don't know if I would rather hire someone to do it but this time I was glad I did it.  So if you are looking to grow your skill set for your career look around you and maybe you can find something outside your field to help you like volunteering, joining a club, or side projects even including home improvements. 

Read More about Soft Skills:

Friday, September 11, 2015

If I only knew Javascript...

If I only knew JavaScript what a wonderful world it would be.



Created by Daniele Rossi


Now do not get me wrong I have written tens of thousands of lines of JavaScript code in my career but do I really know  Javascript? No. Have I ever been taught how to do JavaScript ? No, like the comic indicates like most people I learned from finding snippets that solved a need I had and modified it.  Do I think it would be incredibly valuable to be good at core Javascript? Heck Yeah!

We have seen processing move from mainframes with client terminals, to fat clients, to thin clients with the bulk of the work happening on servers, and now things are moving back to the clients.  JavaScript framework flavor of the months a dime a dozen but a lot of exciting development is going on in the JavaScript world.  Making a career focusing on JavaScript is becoming more common.


JavaScript was originally created in just 10 days.  Brendan Eich while working at Netscape was told to go create a language to do things in the browser. Obviously 10 days isn't much time so some of the syntax was borrowed from Java and several other places and originally called Mocha.  Then it was called LiveScript, then ECMAScript when it was standardized, but it eventually became called JavaScript mostly as a marketing ploy. JavaScript and Java share almost nothing in common besides a name.  However this little language hacked together in just over a week has become one of the most popular and wide reaching languages in the world. With Node.js it has even moved off of the browser and has started running server side applications for itself. 


JavaScript has a spec! BOOKMARK IT ASAP  It was just updated in June so it constantly evolving to fit our development needs.

There are many quirks in JavaScript so while it is an pretty easy language to get started in it is difficult to master. Coercion for example is something I have often struggled with and the JavaScript concept of 'falsey'.  Fundamentally coercion is like Java autoboxing when variables of different types are often not so gently coerced into an type the is equivalent enough to be compared.  It is this type flexibility that is at the same time both an asset of JavaScript's and a point of mystifying behavior.

Examples of Coercion madness:

(true == 1) => true
(true === 1) => false

or

if ('true') {
    'true' == true  // returns false
    'true' == false // returns false
}


Popular JavaScript frameworks:

Learning resources:
Code School - Fun quick online classes without a lot of depth but a great overview
You don't know JS books - Free high quality books by Kyle Simpson

Links to JavaScript posts:

Thursday, September 10, 2015

24 hour challenge

I just read this great post by John Sonmez about a 24 hour $100 challenge entrepreneurial challenge.  This is a fairly old post but the content on www.simpleprogrammer.com has rarely failed to be valuable.  It is a three part post that I was hooked on after the first couple paragraphs.

It is inspirational.  Go read it and come back to this post. I will wait.

...

... read it

...

...

... no faking



Okay so now you have read it or are just a cheating yourself but I like the idea of a challenge like this.  Do you want to try something like this? It doesn't have to be the same thing but it could be or it could be something like generate as many hits as possible in one day to an entirely new blog or hack together a side coding project.  If you are interesting is something like that comment on this post or send me an email.

Please think about it.  I can do it myself against only myself but that cuts back on the pressure that makes you sharper.

Recipe - How to start a new job poorly

So you passed the interview, negotiated a salary you are happy with, and are leaving your current position for greener pastures.  It is time to coast for the next six months or so when people stop thinking of you as the newbie.

New Job Cookbook:


Dress as comfortably as you can get away with

Dressing purely for comfort and not caring what people think of you is not professional.  Unless it would be totally out of place I recommend dressing at least as nice as the best dressed person you encountered while interviewing.  Some people may have been walking around the office in shorts and flip flops but unless that is how everyone is dressing that is not a good tone to set.  If you are not sure then error on the side of dressing up rather than down.  No one will take note if you start dressing more casually later but if randomly you start coming in a dress shirt and tie people prepare for the half joking questions asking if you have an interview later.

Find a way to prove yourself to the team and so them that is was good their good fortune to have hired you.

They offered you the job and wanted you to join the team.  You have nothing to prove. You have already proved it. Looking for a way to make a mark day one will just add stress and get in the way of learning your new work ecosystem.  Relax.  Build relationships and get a lay of the land.  Only then can you carve out our niche and add value.

Do not ask for help.  That will make it seem like it was a mistake to hire you.

You are new and just keeping the lay of the land you should be asking questions to speed up the process.  People also enjoy feeling useful and helpful.  A question can be a good icebreaker and an opportunity to set the tone for the relationship with your new colleague.  Be open and honest about what you don't know and you will be surprised how willing people are to help.

Stay in your cubicle and wait for people to see you out

To be productive at a new company you cannot be an island on to yourself.  Even if it is against your nature you need to get out there and meet people.  Do not have lunch at your desk.  Seek out opportunities to meet people.  A good way to do this is sitting in on other teams stand ups.  Being a fly on the wall for stand ups is a great way to meet people outside of your immediate team and increase the bredth of your knowledge about the company.  To be an effective member of the team people need to know you and you need to make an effort to know them.  For the first couple weeks I like to keep a text files with short bios about people to help me keep track of things and not get overwhelmed. 

There are always a few key people to know that might hold no real power or authority but are the keys to the social network of the company.  For example always be nice to the receptionist, office administrator, and cleaning staff. Just because a person has a less glamorous job than you doesn't mean their position isn't vital to the day to day activities of the company.  You would be surprised how many hurdles can be overcome just by being nice to the unsung heroes.  

Criticize how things are done and offer better ways of doing things

Before you start offering unsolicited advice and criticism learn the details as to why things are that way.  Decisions are not made a whims and likely at one time there was a reason behind the decision that someone felt was a good one.  Even if you don't agree and everything seems totally wrong hold your tongue until you learn how they got to be this way.  Once when I started a new company everything seemed to be anti-pattern and opposite of the way the industry was headed but it would have done me no good to point that out.  The people maintaining the code base built it years ago and were very proud of it.  You would not criticize someone else's child and likewise you should not criticize their code.  Learn how things are and slowly make suggestions and advise who to course correct but only after you understand how things got to this point.  Starting off criticizing the way things are done and showing people a "better" way of doing things will just make you seem arrogant. 

Never talk to your new boss unless spoken to

People are busy and more than likely your boss has more one her plate than just your onboarding.  Make a point of touching base regularly.  John Sonmez from www.simpleprogrammer.com recommends sending a weekly status report.  The status report does not have to be detailed and can just be a bulleted list of what you have done.  These weekly status reports can be a nice way to stay on your bosses radar and provide documentation for future discussions around reviews and why you might deserve a promotion.  Starting this habit week one will show your new boss that you are not a typical employee and you will make their lives better by having you on the team.

You know the technology so you don't need to understand the business to be effective

The technology you are working on is often the easy part.  There are books, blog posts, conferences, and webinars to help you acquire what ever technology you need to learn but there is rarely a book out there about your company.  If you work for an insurance company you should learn about insurance. If you work for an financial services company then you certainly need to learn about investing.  In the vast majority of cases technology is a means to an end not the product itself so you need to learn business domain you are a part of so that the technological decisions you make are in tune with the bigger picture.

Assume your org chart is an accurate reflection of reality

The org chart may tell you the reporting structure according to HR but that rarely defines how things actually are.  Take note of the people who are either friendly with those in charge and the people who teammates fear crossing.  A persons may not have a fancy title but that doesn't mean that they are not a trusted adviser.  Not all people seek to climb the corporate ladder so it is quite possible the rock stars who drive company do so happily from the shadows because they enjoy where they are at.  Most importantly know who you do not want to be mad at you.  There are often a few people around who are in everyone else's business and can make your life difficult if you cross them.  I know it isn't how it should be but there often people you just have keep a wide berth of and try to being friendly with because they will make your life miserable if you don't.



Wrap up:


Clearly this was a recipe for what not to do.  Your first week at your new company will set the tone for your tenure there. The impressions that people make of you will be difficult to change later.  Sure nothing is set in stone and you can turn things around later but a little effort can help help you start off on the right foot.  Determine how you want to be perceived and take action to present that to your colleagues.

Don't coast through your first few weeks at a company. Use that time to build a foundation for your future there. 

Thursday, September 3, 2015

Mutation Testing - 9 Lessons Learned

Mutation testing is amazing.  It still shocks me that it has not caught on despite being around for decades.  This post is in regards to what the value add that comes from doing mutation testing.

Don't know what mutation testing is? Check out these posts:
Mutation Testing 101:

A mutation is a single syntactic change to the code. Each mutant is different from the original by a single mutation. These small changes can have big results; such as changing an operator from addition to subtraction.  Then your unit tests execute against the mutant code and in theory our tests should fail because the code is wrong.

    public int additionOrSubtraction(boolean isAddition, int x, int y) {
        if (isAddition) { //mutant: replace isAddition with !isAddition
            return x + y; //mutants: replace + with -,*,/,%
        } else {
            return x - y; //mutants: replace - with +,*,/,%
        }
    }


Lesson #1: Mutation Testing improves code reviews

Do you do code reviews? I bet they focus 95% on the code that will go to production and maybe a quick peek at the tests.  Despite the fact that a huge portion of the code base are unit tests we really don't review them often due to there being a finite amount of time.  Mutation testing came to my attention when searching for a method to improve the code review process.  With mutation testing the framework adds to the metrics to measure the quality of the tests suite.  Metrics provide an unbiased way of illustrating the tests that add value and the tests that just provide a false sense of security.

Lesson #2: Not all mutations add value

Some mutations are just silly and getting 100% mutation test coverage can be more trouble than it is worth.  The most common example of this I have seen are mutations that remove log statements.  Verifying logging statements add little to no value in 99.9% of cases.  The PIT mutation engine does not differentiate between the different types of void method calls so logger calls are fair game.  These failures can be ignored and maybe the case can be made to try and exclude them from the remove method call mutator.

Lesson #3: Start small

Mutation testing is very CPU and time intensive. For example in a previous post I mentioned how a build that normally takes 30 seconds to compile and run all the unit tests took over 9 minutes with mutation testing.  The first place I start is actually in Eclipse and run a smaller test suite using PitClipse.  This way you can see if your tests even can withstand a mutant onslaught. Also the mutationUnitSize configuration point of PIT allows for the slower ramp up of the number of mutations that are right for your project:

> mvn org.pitest:pitest-maven:mutationCoverage -DmutationUnitSize=2

Lesson #4: Laziness creates surviving mutants

This lesson was learned from the same mutator can caused the example in lesson #2. Not verifying the results of void method calls causes more mutations to fail than almost anything else.  In many cases this is just due to pure laziness.  I just found a project  where all builder method calls to populate POJOs only had an assert to make sure the result was not null.  So the tests did not care what was populated in those beans and just focused on them not being null.  This is a perfect example of having 100% code coverage but the tests themselves being worse then if they did not exists at all.  Do yourself a favor and verify every element in the objects returned. I know it takes time and many asserts but that extra effort may save you from a production bug born from laziness.

Lesson #5: People won't see the value of mutation testing at first and that is okay

Mutation testing sounds interesting to people as a theoretical exercise but the benefits of it are often hard to see.  It takes a mature organization that is already dedicated to a strong unit test base to even consider adopting it.  To get it adopted you, yes you, need to be the zealous advocate for mutation testing.  Just do it.  Update your builds and put a mutation testing job in your continuous integration tool like Jenkins.  If your team hopes to do continuous delivery you need a rock solid test base.  Start pointing out mutations that result from recent commits just like you would if the commits result in bad code coverage.  Do not try to convince people of the value of mutation testing but instead show them the lack of defects that could result from weak tests.

Lesson #6: Mutation Testing is not just for Java

Although the mutation testing tool I am outspoken about is for Java that doesn't mean that there are not frameworks for other languages.

(I have not used any of the following tools and am therefore unable to attest to their value)


Lesson #7: Be relentless in advocating for mutation testing

Mutation testing has been around since 1971.  The days have long passed when the computer power is not available to make make mutation testing a viable tool.  If you don't push for it to be adopted it likely won't because we haven't reached that critical mass to give it a life of its own.  So do it and email out the reports. Do a lightning talk or brown bag session on mutation testing to get the word out.  Honestly I don't care if you even need to borrow heavily from or steal the Mutation Testing Slideshow that I recently created. Get the word out.

Lesson #8: 100% mutation kill score is possible but expensive

As previously stated some mutations are silly not really useful but there are times when there is no margin for error and your code needs to work.  Say for example you are working on code for a medical device.  There is no room for error when someones life is on the line.  You need mutation testing to do everything you can to be defect free in cases such as that. However some mutants just aren't worth the time needed to kill them.  It is similar to writing unit tests to test all getters and setters in POJOs.  Is it really worth your time to write tests for basic getter and setter methods. I don't know that is a personal decision but squashing some mutants might add even less value than those unit tests.

Lesson #9: Mutation testing makes you a better programmer

Knowing the ways your code could break and how good your tests need to be to protect against that is not a skill that is developed overnight. Mutation testing ensures that you don't cut corners and take the easy route.  Write solid code and bombproof unit tests.




Links to other posts related to Unit Testing and Mutation Testing:











Tuesday, September 1, 2015

13 steps to make TDD actually work

Why TDD doesn't work for you?

This is one of those situations where being brutally with yourself will help.  Test Driven Development (TDD) does not work because you are not doing it.  It is as simple as that.  You gave up on TDD because it was it was sounded good but it was hard.


What is TDD?

At its core TDD is thinking about your unit tests before you write the implementation code.  When you write the code first you are likely focusing on one happy path end result and coding to try to reach generate that result.  That closes your mind off to all the possible outcomes, all the possible input scenarios, and all the possible things that could go wrong.  So in TDD you think about the tests first so you do not have blinders on to scenarios beyond the happy path through your code.


What is so appealing about TDD?

When you were first introduced to TDD you were likely shown a hello world like feature then you were told how to write the tests for it and then shown you write the code to make your test pass a little at a time.  It was glorious.  The solution to better tests was just writing your tests first! Your tests could be better by thinking about everything and not just the happy path.  It is such a simple concept you can do that! No problem.  Less bugs means more time doing fun coding and less time doing support work.


So why aren't you doing TDD now?

You ran off to your project base code and tried to implement the feature using TDD and it was not as easy as that hello world example.  You tests required mock objects which you had to just guess about it because you were not sure exactly how you would implement the code.  After some struggles you either just gave up because you had a deadline and this was slow or you banged out some hard won tests and started on the "real" functional coding.  After you wrote some real code you figured out that tests you guessed about still weren't passing because the guesses you made about the mock objects and service calls were just tiny bit off so you needed to fix those to even some of your tests to pass.  How is disheartening! You spent all that time writing those tests first and they were not really adding value and you weren't "writing your tests first."  So you gave up on TDD.  It was hard. It wasn't the solution to your problems like you were told and all it did was slow you down.


Why should you give TDD another chance?

Because you were doing it the hard way and you didn't even know it.  Doing TDD is a mindset which you aren't going to develop just because you watched one presentation about it and tried it once.  You were sold on the concept but it practice it was hard.  TDD is not as black and white, not as all or nothing, as you were told.


How should you being doing TDD:

  1. Get your feature ticket from Jira, a post it note, or wherever
  2. Do not open up your IDE
  3. Think about the feature and do a quick design of it either in your head or on a whiteboard
  4. Write down some test scenarios
  5. Now open up your IDE
  6. Create your "real code" class and method signature
  7. Create your unit test class
  8. Create a unit test but instead of writing the test case just stub out the unit tests and create comments about what the test scenario you want to cover (see sample below)
    • Include both the input, expected results
  9. If possible write the assert statement for those expected results
  10. Repeat steps 8 and 9 until you have covered every scenario you can think of
  11. Go write your "real code"
    • pause occasionally if you think of a new scenario and update the unit test class to include it
  12. Now fill in the unit test to cover those test scenarios including all the inputs, mock objects, and even better assert statements
  13. Tell your coworker about how you actually did TDD and it made your code better


Sample Stubbed out Test Class

public class AdditionHelperTest {

 /**
  * test basic addition
  *
  * input: 1, 2
  * 
  * expected: output 3
  * 
  */
 @Test
 public void testAdditionHappyPath() {
  fail("Not yet implemented");
 }

 /**
  * test null input
  *
  * input: null, 2
  * 
  * expected: output illegal argument exception
  * 
  */
 @Test
 public void testAdditionNullFirstArg() {
  fail("Not yet implemented");
 }

 /**
  * test null input
  *
  * input: 1, null
  * 
  * expected: output illegal argument exception
  * 
  */
 @Test
 public void testAdditionNullSecondArg() {
  fail("Not yet implemented");
 }

 /**
  * test negative numbers addition
  *
  * input: 1, -2
  * 
  * expected: output -1
  * 
  */
 @Test
 public void testAdditionNegative() {
  fail("Not yet implemented");
 }

 /**
  * test addition large numbers
  *
  * input: Integer.MAX_VALUE, Integer.MAX_VALUE
  * 
  * expected: exception
  * 
  */
 @Test
 public void testAdditionLargeNumbers() {
  fail("Not yet implemented");
 }
}


What is next?

As you get better at thinking about TDD you may be able to create more of the test code first, for some features, and you will get faster at generating those test scenarios.  You will have less bugs in your code. You will then have more time to do fun new development and spend less time doing boring production support.

Other Testing Magic: