Archive for the ‘Agile Engineering’ Category

3 RSpec Book chapter-5 “output” solutions

Monday, September 15th, 2014

I’m doing some volunteer work for an organization as a Ruby Programmer and as such, I’m having to come up to speed on RSpec in a hurry.

 

Well today I got stuck in the middle of chapter 5.  I’m talking “thrashing all over the internet” kind of stuck here.  Sadly my google-foo was failing me until just a moment ago (about 1am on a Saturday night, Sunday morning.)

 

Thankfully Carmen Berros not only had my exact problem, she took the time to write up and link to her friends suggestion.

 

If you are looking to understand what all the big deal is with BDD, even if you are not a ruby programmer, “The RSpec book” (affiliate link) is wonderful, and well worth your time

 

 

Another problem I ended up having with this chapter were my RSpec tests passing, but my Cucumber tests failing.

That solution turned out to be to change the name of “output” to “terminal_output” in

features/step_definitions/codebreaker_steps.rb

 

Lastly, if you haven’t found the solution to the dreaded “should is depreciated” messages, the solution is hinted at here  (this also goes in features/step_definitions/codebreaker_steps.rb)

I’ve included the two lines that I tested

#output.should_receive(:puts).with(‘Welcome to Codebreaker!’)
expect(output).to receive(:puts).with(‘Welcome to Codebreaker!’)

#output.should_receive(:puts).with(‘Enter guess:’)
expect(output).to receive(:puts).with(‘Enter guess:’)

 

If this helps you in your RSpec journey, think about leaving a comment to let us know why you’re taking the time to learn RSpec.

Mobile Apps & TDD – It doesn’t have to be that hard.

Tuesday, September 2nd, 2014
Was having a conversation a couple of days ago and the subject of TDD with Mobile Development came up.
The bottom line was that, “most companies that are doing mobile apps could use TDD training.”

What happens is, they hear that “mobile is different” and then don’t write their code in a way that is testable.

This leaves them with an app who’s internal logic can only be validated by white box testing on as many different devices and operating systems as possible.

There are even people making the case that TDD doesn’t work for mobile because TDD only tests your code’s internal logic.

That’s a punch line.  Testing your code’s internal logic is what Test Driven Design  is intended to provide.

For those of you who would like to dig deeper on why TDD in the mobile space, read Robert van Loghem’s article “Why TDD + Continuous Testing is Imperative for Mobile Apps”

Robert references an old Object Mentor article that is no longer available except through the “Wayback Machine.”  You can read “Continuous Testing Explained” here

 

Three 20 year-olds create a healthcare.gov miracle

Tuesday, November 12th, 2013

Up until the lurching non-roll out of Healthcare.gov, no one outside of the software community had ever heard of “Agile Development.”

The Wall Street JournalThe New Yorker, and Bloomberg have changed that.

Well, that and the miracle in San Francisco.

You see three 20 year-olds, in only 3 days, built a usable front-end to Healthcare.gov.

Miracle?

Yes, 3 people, in 3 days did what 55 independent contracting companies couldn’t do in 3 years with over 500 million lines of code.

There’s a miracle in there somewhere.

If nothing else, if you could get that kind of productivity out of your programmers, you would call it a miracle too.

Over the next couple of days and weeks, there’s going to be a lot of made of these 3, but how many smart business owners are stopping to ask, “How can I get that kind of productivity from my teams?”

In the coming days and weeks, I’ll be exploring that smart question.

Please pass this on to the smart business owners in your life.

Is your Continuous Integration tool doing to much?

Friday, March 22nd, 2013

Welcome to Agile Slices; a series of quick pragmatic articles of about 200 words, intended to help you, your team and your business, harness the power of agility.

 

Is your Continuous Integration tool doing to much?

 

Yesterday I said that a CI tool should only do 3 things, Poll, Initiate and Update.

 

Period. No more, no less.

 

I can hear you saying, “But my CI tool will do my checkouts, my compiles, run my tests and a bunch of other stuff too.”

 

You’re right, it can, and you don’t want it doing that for one big reason. You only want your build done one way.

 

Your build server, your developers, and your testers should all use the same build process. Unless you want your team to have your CI server installed on all their machines (and there are some decent reasons for doing just that) then they all need to be able to run the same single one line of code to do their local build, and run their unit tests.

 

When the build machine does the build and runs the unit tests, you want it to use the very same single line of code.

 

If the build is being created in different ways by different people or processes, sooner or later you are going to get bit by the differences.

 

Ask yourself, are all my developers, and my automated build process using the exact same steps to create the build?

Or conversely, have you ever had to figure out why the build on the build box was different that the developer build?

 

Stay On Mission.

 

If you have already used this slice, please add your voice to the conversation. If it sounds silly, please take some actions to test a particular idea’s validity, and then share your results, good or bad, with the community. If something strikes you as golden, then I’m glad I was able to provide value to your life, please let us know what difference it has made for you or your company.

Continuous Integration for Managers – Poll, Initiate, Update

Thursday, March 21st, 2013

Welcome to Agile Slices; a series of quick pragmatic articles of about 200 words, intended to help you, your team and your business, harness the power of agility.

 

Continuous Integration for Managers – Poll, Initiate, Update

 

I’m not going to get into how important Continuous Integration is to your Agile Development process. We’re going to take that as a given.

 

The point of this slice is to give you a 30,000 foot view of CI so that you have a better idea of what is actually going on.

 

Your overall CI system is composed of 4 basic parts.

 

1) The CI Server

2) The Version Control System

3) The Build System

4) The CI Dashboard

 

The CI server sits in the middle of the other 3 parts and acts like an orchestra conductor.

 

The CI server does 3 and only 3 things.

 

1) Poll the version control system for changes

2) If a change exists, initiate the build

3) On completion of the build, update the CI dashboard with a simple Pass or Fail.

 

There, you’re done.

 

Don’t get me wrong, that second step can get amazingly sophisticated and there is a temptation to let the CI system get it’s hands dirty in doing the build. This is because CI systems compete on how well their product can handle the creation of the build.

 

Tomorrow I’ll get into why you want to avoid letting your CI server do more than poll, initiate, and update.

 

Stay On Mission.

 

If you have already used this slice, please add your voice to the conversation. If it sounds silly, please take some actions to test a particular idea’s validity, and then share your results, good or bad, with the community. If something strikes you as golden, then I’m glad I was able to provide value to your life, please let us know what difference it has made for you or your company.