I was pretty excited to get the opportunity to do this course, because there is a large amount of misunderstanding out there about:

• Inversion of Control
• Dependency Injection
• Dependency Inversion Principle
• Inversion of Control Containers

I cover each of these topics in this course and then we even build our own IoC container.

If you liked the Back to Basics series, you’ll like this course.  I go and dive a pretty deep into the real meat of the patterns and principles behind IoC containers.  Then I cover using Unity and Castle Windsor.

I think it is pretty important that we understand clearly why we are using a particular technology or pattern and what problem it is trying to solve.

I see too many people jumping on the bandwagon of so many popular technologies without really taking the time to learn the background about the technology to understand why it is an effective solution to a problem and what problems it attempts to address.

As always I welcome any feedback or suggestions for future courses.

This course was designed to help someone that is familiar with .NET get up to speed and start building an iOS application quickly.

Having gone through the learning process myself, I tried to distill what I thought was the most essential things to learn from someone having more of a C# background like myself.

It can be really hard to learn a new operating system, technology, programming language and IDE all at the same time, so I try to break it down and really spend some quality time discussing each of these things.

I think the end result turned out really good.  I am already started on part 2 of this course, which will dive a bit deeper into actually writing code and implementing features, while this course was designed more to lay a good foundation.

If you have already taken my Android development for .NET developers course you’ll notice I am trying to take the same kind of approach as we even build the same protein tracking application.

I found it pretty difficult to map some of the concepts in Android to iOS when I was first porting my PaceMaker application to the iPhone, so I tried to create a pretty good mapping between the two courses.  It definitely can be frustrating when you know how to do something in one technology, but can’t even find the words to Google for that same concept in another technology.

I also wanted to take a minutes in this post to highlight value of a video training site like Pluralsight.  I definitely think it is something every developer should have access to. 

Having watched many of the courses on Pluralsight, and developed 2 courses for the site myself, I have come to realized that the true value in these courses is that you are getting a distilled and practical knowledge as opposed to many books that really are more reference based trying to cover all of a technology.

Obviously I am affiliated with Pluralsight, so I am going to say they are great, but I definitely think these kind of real world focused videos are a great way to learn a new technology or enhance your skills.

Anyway, I hope you like the course and if you have any questions or comments about it, feel free to email me or ask them here.

Look for part 2 to be coming in the near future.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

You can find it on your android market by searching for “PaceMaker” or using this AppBrain link.

Or if you are reading this on your phone, try this link.

If you have seen a few of my posts on Android development, you might have guessed it is an Android application.

If you have seen my post on fitness, you might have guessed it is a fitness app.

Why another running app?

You probably are already familiar with the running applications that are out there, and several of them are really good.

So the question remains, why would I create another running application?

Let me tell you about my own experience trying to get back into shape and when I starting running and see if that answers the question.

Early last year, I decided to start running to get back into shape.  I used a running program called Couch to 5k to get up to being able to run 5k.

I was able to use several of the running applications available for my phone at the time to chart my runs and even post them online.  This was great, but one of the big things I was struggling with was knowing if I was running at the right pace.

On a treadmill this is easy, you can set the MPH you would like to run or the pace and the treadmill will hum along at that pace.  If you want to be running at a 10:00 minute / mile pace, you can easily do it.

When you are outside running, you can’t just run at 10:00 minutes per mile.  You can guess that you are running about that fast, but it is very hard to know.

It’s pretty important to be able to run at a desired pace, for two main reasons:

1. Making it the whole distance (you don’t want to run too fast or you will die out)
2. Improving your running (you need to start running at a faster pace gradually in order to get faster)

So as I was running I found that I needed to know what pace I was running, so that I could speed up or slow down if I was running too far above or below that pace.

Once I could run 5k, this became really important, because I wanted to improve my time, but I didn’t want to increase my distance.  (Most experts say running more than about 5k tends to lead to muscle loss, I don’t want to lose muscle, just fat!)

I tried using a Garmin watch to monitor my pace, but that didn’t work out well for a few reasons:

• It’s clunky and you have to keep trying to look at your wrist while running which causes you to slow down.
• It’s hard to read small numbers on your bobbing wrist, especially in bright light.
• The GPS on it took forever to get a lock.
• The batteries were always dead when I wanted to run.

I set out to make a running application that was mainly geared around tracking your pace.  What I wanted was audio notifications or vibrations which indicated when I was over or under my desired pace by a certain amount.  I couldn’t find any application that would do this, so I created one.

PaceMaker is designed to solve a very specific problem, running at a desired pace outside.  Sure, it tracks your run and will show it on a map, but the primary focus of this application is to help you run at your desired pace.

How does it work?

Once you download the application, it is very simple to use.

The main screen shows your current pace, your target pace, how long you have been running, the distance you have run so far and how many seconds below or above the current pace you are.

Notice the pace is in nice large numbers, so you can read it easily while running.  If you tap the overall pace, it will show your current pace and vice versa.

Overall pace is the pace you have run since you started running while current pace is the approximate current pace in the last 30 seconds or so.

Pressing the start button will start your run, and pressing it again will stop your run, saving your run to a GPX file on your SD Card.

While you are running, if you are over or under your target pace by the amount you set, you will get a nice audio notification saying “Speed up!” or “Slow down!”

You can configure all of these settings in the settings screens.

From this screen you can set the target pace in minutes and seconds, and the distance in miles or kilometers.  You can also set up the alerts.

From the alerts screen, you can set the alert to fire if you are running too fast or too slow by 15, 30, 45 or 60 seconds, or choose to not alert you.

You can also choose which sound to play if you are running too fast or slow.  A default is provided, but you can select any ringtone on your phone.

Setting the vibrate function will vibrate the phone in a pattern to notify you if you are too fast or slow.

All the runs on your SD card can be viewed from the history screen.  Selecting an individual run will display that run and the details on a map.

Comments or suggestions

This is my first Android app, so it was quite a learning experience.  I would appreciate any feedback if you end up buying the application, and 5 star ratings are always appreciated.

I intend to fix any bugs or solve any problems that any users report as well as implement many suggestions, so if you have any please let me know.

If you wouldn’t mind sharing this link with anyone you know who is a runner and has an Android phone, I would be appreciative.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

I think this is a dangerous place to be.  It is a place where education and understanding are trumped by blindly following best practices without really thinking about why or when to apply them.

Not to bash Ruby here, but I think that the recent evacuations from C# and Java to Ruby are in many ways due to this degradation of practicality by so many of the experienced C# and Java developers out there.

I have to admit, I am guilty of it myself.  I blindly add interfaces to classes that don’t need them just so I can dependency inject them into my class so that I can write my behavior driven unit tests using a mocking framework.

What am I doing about it?

I thought I would write a series of blog posts with the goal of getting back to the basics.  I want to take a thorough look at:

• Why some of todays best practices exist
• What problems they are trying to solve
• What we did before relying on these techniques
• When they are applicable

I want to get back to a point where I am very clear that when I employ one of these best practices:

• I have a good reason for doing so
• It is solving a specific problem
• It has a net benefit

My goal is to take a “nothing is sacred” approach to software development and pick apart anything and everything.

I want to start by looking at some of the basic things like interfaces and ask questions like “why should we even use an interface?”

Honestly, I don’t know where exactly this path will lead, but I am going to take it and see where it goes.

But what about forward progress?

Aren’t all of todays best practices and techniques the result of years of forward progress in the profession of software development?

Yes they are, but that doesn’t mean they are right.

It’s kind of weird how progress works.  We end up going down one path for a long time thinking we are making progress until it comes to a dead end, but some of the things we learned along that path allow us to go further on a different path, or open up completely new paths altogether.

It is only in developing solutions to problems that we find other problems that are caused by those solutions, which in turn cause us to go back and resolve the original problems in a different way armed with this new knowledge.

Want a good example of this?

Look at how the usage of JavaScript has changed in the past 5 years.  JavaScript has been around for a long long time, but the way it is being used today is completely different than that way it was being used 5 years ago.

The language itself has not changed, but how we use it has changed completely.

My only point in saying this is to open up your mind to the possibility that things we think are completely necessary today, like unit testing for example, may not end up even being considered valuable at all in the future.

Why is this important?

It is good to shake up your beliefs and questions them every once in a while.

Any belief you hold true should be able to hold up to solid reasoning.  It is important to test our own beliefs every once in a while to make sure they are still valid.

Testing our beliefs can help us gain more confidence in the ones that are correct, and stop hanging on to those that are wrong.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

I’ve previously talked about why I think Scrum will eventually die and I am still pretty much convinced of that point.  Scrum has become something you sell through training and consulting.  If you make your living off of doing this, sorry, but you may be part of the problem.

What this post is really about though is the problem of good architecture when implementing Scrum.  In my experience, it is very difficult to create or maintain a good architecture and do Scrum.  There is one very simple reason for this: mobs don’t build good architectures.

Why?

Let me give you an example that helps to illustrate my point.  Let us take a second to think about real physical engineering and architecture.  Let us say we are going to put together a team to design and build a custom home.

So we get together a plumber, an electrician, a couple of framers and an architect.  Now, let’s have them start building the house.  What do you think the architecture of the building will be like?  What if the plumber and electrician know a good amount about architecture, because they studied it in highschool?  They outvote the actual architect.  In general the team is going to benefit from the real architect’s experience and guidance, but when he understands a critical component which the other team members do not see, he is going to be overridden and that will spell trouble down the line.

Now, obviously this parallel does not completely apply.  I am just trying to take one aspect of it for the point of this illustration.  The idea that you don’t want a group of people, as intelligent as they are, to make a decision which could be better left in the hands of an expert. 

At this point you might be thinking “what an arrogant jerk!”  You think a so called “software architect” knows so much better than the average developer?  No, that is not exactly the point.  The point is that there is a difference in level of experience and ability in software people, roles and labels aside, and when you use a democracy of team based decision-making methods, you get an average of the skill level and experience of the whole team as a result.  It is a mouthful, but read that over a few times until you get my point.  I think it is pretty hard to argue against, but let me give one more illustration.

Let us say now that you are going into a hospital to get heart surgery done.  Now, this kind of procedure is not a one man operation.  You would typically have a surgeon, an anesthesiologist, several nurses, and other doctors involved.  But let’s say for this instance that we let this surgical team operate like a Scrum team.  Instead of the surgeon or chief medical officer ultimately calling the shots, the team will make a decision as a whole.  Would you be ok with that?  The nurse has the same vote as the surgeon?  Two nurses can override the surgeon’s decision?  I think I would be a little bit alarmed, especially if I sat in on their design session.

I’m not trying to pick on anyone here or devalue anyone.  I am also not trying to destroy the concept of team.  Teams and teamwork are very important in the development of software.  But I hope you can see the point that Scrum can tend to lean towards a mob built architecture for a system, and that architecture is only as good as the average of the abilities of the team members.  Although more often than not it’s really just as good as the most vocal and assertive member(s) of the team.

Where Scrum and Scrum-like processes fail

I don’t see how a resolution to this problem fits inside of the Scrum framework, and that is a problem.  The idea of a completely self-managing team is ok for making construction type decisions about building the software, but it has no solution for the overall architecture and general best practices for the development of the application.  As much as we can despise hierarchy, it really has a value that is completely missed by Scrum.  You really want to have the more senior highly skilled developers technical people with more power over decisions and direction than your less skilled.  This isn’t mean, it isn’t spiteful or power-mongering, it is common sense.  The problem with the self-managing- everyone-is-equal team is that it levels the field.

So what is the solution?

Would I offer up a problem without offering up a solution?  There are several ways of dealing with this problem.  It depends on how far you are willing to step outside of Scrum.

Solution 1: Scrumminess Factor: 9

Appoint a small team of technical and business architects that have the responsibility of:

• Overseeing the general architecture of the system
• Creating development best practices and guidelines
• Attending design sessions for other teams
• Stepping in when needed to steer a team back on the right course

 This solution works only if you have several Scrum teams on the project, where it would make sense to have a team dedicated to architecture.  This team is also a good one to be creating developer tools.  I have actually been part of a team doing this kind of role, and I think it worked out pretty well.  It doesn’t really violate Scrum, because that team is a separate Scrum team with a different kind of backlog.

Solution 2: Scrumminess Factor: 6

Appoint a technical architect to the project.  This person is in charge of the technical people on all of the teams for technical direction, but not HR duties.  This role would have the ultimate authority on any kind of development and architecture decisions for the project.  They would be a floating resource that could help teams at times where needed.  This person would be thinking about the bigger architecture picture that is being created by each of the teams.

Solution 3: Scrumminess Factor: 3

Appoint technical leads on the teams which are responsible for the architecture and ultimate technical direction of the team they are on.  If you have multiple teams, the technical leads should have a technical lead for the technical leads.  This allows for a unified vision when there is dissent among the technical team leads.  It has a low Scrum factor, because it puts a direct leadership role on the Scrum team, but it allows for the solution to the mob architecture problem, while still keeping the architecture within the team.

One final word here.  If you are still thinking that a central authority is not important to a business, consider this:  every company I know of has either a CEO or a president.  I have never seen a company with a Chief Executive Committee.  Sure, there is a board of directors, whom the CEO ultimately is accountable to, but you have one person setting the vision and business direction of the company.

The project

The project I am working on is mostly written in Java.  It is a case management system which workers use to enter applicants information and then run their eligibility to qualify them for benefits.  The basic use of the system is to create a new case, create people on the case with their information, income, relationships etc, and then run the eligibility and save the results.  One other important piece here I want to mention before I get flamed about technology choices is that the product was a legacy product and only supported on IE.

The tools

Based on most of the developers being versed in Java and the system requiring IE, I chose to use Watij for the framework.  Watij is basically a framework built on top of IE that directly interacts with the browser through the DOM through the COM interface.  When you are testing in Watij you are actually interacting with the browser, but since you are going through the com layer instead of clicking directly through the screens you are able to hide the browser window and run tests with the machine locked.  I also used JUnit as the test driver to execute the tests since it is easy to run from eclipse and can easily be run from an ant build to report the results and run on the build server.

The framework

The basic idea behind this framework is that I wanted to make it so a non programmer could write the tests and maintain the tests without having to know much about Java or Watij.  Even though Watij happens to be being used behind the scenes, I wanted the person writing the test scripts to only need to have domain knowledge of the application.  With that in mind, here is a picture of the stack.

You can see in the diagram that I show a technology and how you interact with it.  IE uses HTML and CSS, Watij is built on top of IE and lets you work against the DOM.  My application framework is build on top of Watij and lets you work with domain specific concepts such as specific screen, work flows and navigation.  The test scripts are written against the domain specific application framework.

Using this type of a framework, most tests can be written in as few a 5 lines of code.  Here is an example of a test:

@Before
     public void SetUp()
     {
          this.caseNumber = CaseCreator.createCase( IBESDate.currentMonth(),
                                                    false,
                                                    false,
                                                    People.ADULT_MALE_1.onPrograms( Program.MEDICAID ) );
     }

     @Test
     public void taskCanBeSelected()
     {
          Tasks.addTask( TaskType.RECEIVED_458, IBESDate.monthsInFuture( 3 ) );
          WorkQueue.search( TaskType.RECEIVED_458,
                            IBESDate.monthsInFuture( 3 ),
                            IBESDate.monthsInFuture( 3 ) );

          Assert.assertTrue( WorkQueue.searchResultsHasCase( this.caseNumber ) );

     }

Now this isn’t going to make much sense to most people who read it and I actually consider that a good thing.  If you looked at the screens in the application it would make much more sense.  Someone writing these tests only needs to know about the screens and they can figure out how to do something.  There is actually a large amount of things going on in the background when you run this test.  It will create a complete case, add the person to the case, then click through a task workflow to add a specific task, then it will go through another workflow to search by the task to see that it was added.  There are probably about 20-25 different screen that this test ends up going through with these very few and simple lines of code.

The secret behind these kinds of a simple UI automation tests is abstraction.  The framework is designed to essentially be a domain specific language.  By abstracting away anything that has to do with the browser, html and even the dom, I am able to present a simple and stable interface for the tester to do exactly what they want and not know about all the other technology going on behind the wheel.  Think about how complex a motor vehicle is, yet how simple the interface to the user is.  I see many automation strategies that require the person writing the test scripts to know about all nuances of browsers and html.

What about change?

Most automation strategies break down when encountering UI changes.  I welcome UI changes.  Go ahead and change the UI, it won’t break all my tests, it will break one specific place in the framework that knows about what kind of things are on a particular screen.  With this framework it is very easy to fix a broken UI in one place and all the tests will work again.  Contrast this to many of the automation scenarios you have seen where a single renaming of a button requires 50 tests to be reworked.  All of the Watij interaction is in one namespace called “UI”.  All of the screens use UI to interact with Watij, so that I could even swap out Watij for another browser automation framework.

Back to the snake oil

I do have to say I agree with many of the points Michael made in his post, but I have seen them overcome.  A tool is never going to be a magic bullet.  Yet at the same time we should not run away from UI automation.   We just need to correctly apply the same principles we apply to create good abstractions in our source code to our automation code.

What do I mean by making the complex simple?

In my mind this is the single most important quality of a software developer.  The ability to take something that is complicated and to large to fit inside a skull and make it simple and understandable.  This concept is applicable at many different levels of abstraction, just as the practice is.

For example:  When we are writing code, what we are doing is taking a complex world and dissolving it to a simpler abstraction of rules which govern how it works.  The world is often “fuzzy” and requires judgement an intuition.  As developers we take that “fuzzy” world and make generalizations about it and make it concrete for our problem domain.

Taking it a step further, simply writing software or code, is simplifying the complex world into black and white, but even that is complex.  I can write a bunch of assembler code or even machine language, and I may have technically made the complex world simple, but I may have actually made it more complex to the next programmer to read my code.  As a good developer I would strive to make the expression of those rules of the system to be simple itself so that another developer or myself could easily understand this complex concept.  This is what I mean when I say elegant code.

Being able to write code that is easy to understand or “fit in your head” is such a quintessential part to development that without that skill even the most genius developer is bound for failure.  I would equate this with the difference between writing intelligent code versus wise code.

Simple vs complex is such an important concept that it transcends programming and really touches many areas of our lives.  Think about your car?  How simple is it to use such a complicated piece of machinery?  There is a large amount going on which we don’t know or care about when we drive a car, but someone came up with a simple interface which makes this really complex thing to do very simple.  Consider Apple’s success.  I have had a smart phone since HP first came out with the IPac phone, but did I ever really use any of the features on the phone?  Apple came a long took this complex interface for most of the competing phones, and didn’t make it stupider, they just made it simpler.  In fact they gave it more capabilities, but made the user interface so simple to use.