iOS For .NET Developers Course Published

(Cross posted from my personal blog)

It has been quite a bit of work and a learning experience, but today my course on iOS development for .NET developers course was published on Pluralsight!

Pluralsight

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 elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

Why Software Development Will Never be Engineering

I always find it rather interesting when academics try to quantify generalized metrics about software development.

Things like: per lines of code, there will be X number of bugs.

Statements like: it has been empirically proven that “blah” affects the development of software in some way “blah.”

These are all interesting thoughts, but software development will never conform to rigid engineering principles like many other engineering practices.  The longer I work in the field, the more and more I realize that software development has nothing to do with engineering.  We just happen to attend some of the same math classes in school.

Building bridges

One of the main arguments I hear people make about the current state of software development as an engineering practice is based around its relative maturity to other engineering fields.

There is a huge problem with this line of thinking.

The argument goes something like this:  “Engineering has been around for hundreds of years and has matured to the point where it is a measurable science, but software development has only been around in earnest for the last few decades or so, therefore it is relatively immature as an engineering discipline.”

On the surface this argument seems sounds.  And certainly in 50 years software development will be different than it is now.  Heck, it is much more different than it was just 10 years ago.

But, here is the problem.  We build much more software than we do bridges.

 

Let me give you an example that came to light in another area of my interest… poker.

The poker quickening

An interesting thing happened in the poker community in the last 10 years; poker pros with decades of experience started getting beat time and time again by 19 year old poker prodigies.

From an outside perspective it looks like the poker world opening up just widened the search for talent and there it was.  But, a closer examination of the evidence leads to the truth.

Before the online poker industry was born, poker was played in card rooms and casinos in states where it was legal and occasionally at small home games throughout the US.

A poker pro might play poker tournaments perhaps 100 times to 150 times a year.  The sum knowledge of the poker community and the meta game around it was based on this base of professional poker players playing tournaments and gaining experience at this mediocre rate.

Once the internet poker rooms started opening up, things changed, and they changed rapidly.  Now anyone could play poker from their home PC.  Not only could they play poker, they could play poker tournaments at all hours of the day.

Here is a list of some of the major changes that took place:

  • Hands are dealt at 60-80 hands per hour instead of 10-30
  • Players can play in many tournaments at one time, 10 tournaments at once is not unheard of
  • Players can analyze hand histories and historical data about their play and opponents play through the use of software
  • Age requirements are out the window, technically any one of any age could be playing online
  • Players can play 24 hours a day
  • The professional online tournament player could easily play over 3000 tournaments in a year, while a brick and mortar pro would be lucky to reach 100 in a year.

 

So where am I going with all this?

The point is that as a whole more hands were dealt and more poker knowledge and experience was obtained in 1 year of online poker than probably the entire history of poker before that.  We reached such an accelerated pace of play that all previous knowledge of poker became obsolete. 

The strategy of tournament poker completely changed.  The game evolved perhaps 500 years into the future in a matter of 5 years time.

The same has happened with software development.

Back to the bridge building

So let’s take that poker example and look at it through the lens of software development.

Let us compare the engineering maturity to software development to the engineering maturity of the engineering discipline of building bridges.

I think most people would agree that bridge building is a very mature engineering discipline but many people would argue that software development is not.

How many bridges do you think have been built in the world?

Well there are about 600,000 bridges in the United States alone, so the world figure must be at least somewhere around 10 times that number perhaps 20.

How many software programs have been written?

This is a very hard number to estimate, but lets take a rough guess based on how many software developers there are in the world

If we say there are about 12 million software developers and each software developer has written approximately 3 programs, we can estimate that a large amount more programs have been written than bridges built.

My point is not to knock bridge building, we are pretty good at it as a whole, but rather to show that collectively, even though we have been building bridges for hundreds of years, we have probably devoted an equivalent amount of time to building software.

This line of thinking may lead you to argue back that software development and bridge building are very different.  Bridge building has a fixed set of requirements that are pretty close to the the same for each bridge you build, but software development is a big open void of whims and ambiguously contradictory statements.

I agree with you 100%!  And in essence that is my point.

Software development is different

And we have had enough time to realize that.  Waiting for software development to gel into some kind of engineering discipline like other engineering disciplines is like waiting for water without gelatin mix to turn into Jello. 

It’s just not going to happen!

In my mind it is clear that the argument that we haven’t given it enough time is just wishful thinking.  The nature of software development, just like online poker, leads itself to rapid evolution.

Consider what direction software development is evolving.  Is it even evolving in the direction of rigid engineering practices or is it evolving in the exact OPPOSITE direction?

Ten years ago, we tried to use UML diagrams and CASE tools to develop software.  Ten years ago waterfall was all the rage.  Ten years ago, we thought that ten years in the future we would have programs that would allow us to build software in the same way that CAD tools allow for building machine parts.

Not only did it not happen.  It went completely the other way.  Now we are all talking about Agile.  Now people don’t even remember what CASE tools are.  Now we are building software without trying to define the whole system in UML diagrams.

The fact of the matter is software systems are unruly beasts!

In my mind it comes down to one simple distinction.  Software is living, bridges aren’t.  When you are done building a bridge, you are done building the bridge. 

Sure someone, probably not you, will have to come along and do some routine maintenance on it.  Sure, some small things might change about it, but for all intents and purposes the work is done.

In most software development scenarios, this is not the case.  In most software development scenarios, releasing V1 is not even close to the end.  Sometimes V1 and V2 don’t even look that same at all.  Software development is about operating on a living breathing thing and all the while keeping it alive.

The truth is, we software developers have more in common with surgeons than with other engineers.

As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

PaceMaker for iPhone Released

(Cross post with my personal blog)

Earlier this year I announced the release of an app I had been working on for Android called PaceMaker.

Finally, I have succeeded in porting the application over to iPhone and it was definitely much harder than I had anticipated.

But I am glad to announce that as of today you can find PaceMaker for iPhone in the Apple App Store.

If you don’t know what PaceMaker is, you can read about it in my original post above or in the description in the app store, but to sum it up briefly, it helps you run at a desired pace by telling you to speed up or slow down when you are running too fast or too slow.

Default@2x

A unique perspective

Having originally written the application and then porting it over to iPhone gives me a kind of unique perspective on mobile development platforms.

Although it was a bit painful at times to basically recreate the same thing I already spent so much time and energy creating, I was able to very realistically contrast the two development platforms in many areas.

One of the major pain points I experienced was in documentation.  Google’s documentation on the Android platform is sometimes lacking, but is much more complete and descriptive than Apple’s iOS documentation.

I am still quite a bit torn on which platform I like more and which platform I think will win out in the end.  I do believe that if Apple improved their developer tools and moved to a new, more modern development language, that they would have a distinct advantage.

It seems to me though that whoever integrates the best across multiple devices and gets the highest quality applications built for their platform will be the winner.  iCloud could be a huge step in that direction for Apple.

Sharing the knowledge

I’ve just talked with my curriculum director at Pluralsight and I will be doing a beginning iPhone development for .NET developers course just like the Android Development for .NET Developers course I did earlier this year.

I’m pretty excited to do this because I am going to try and draw some major parallels between the two platforms and also from the .NET perspective.

I hope to create the course just like the Android one, where we will step by step create an application from scratch and then publish it to the Apple App Store.

Look for that in the next few months on Pluralsight.net.

Dailymile.com integration

Also included with this release for iPhone and Android is Dailymile.com integration.  I think this feature is pretty cool!  So I am really excited about it!

Dailymile.com is basically a social site for runners and cyclists.  It is basically a Facebook for runners.

I have added a feature to the Android and iPhone versions of PaceMaker to allow you to post your run details, including the GPX map of your run, up to the Dailymile.com server on your wall.

So when you go for a run you can capture all the information from your run and see it on Dailymile.com.

This was quite a pain to implement as I had to implement OAuth2 authentication in both platforms and integrate with a REST API.  But what a great learning experience!

Anyway, if you are a runner out there and you get PaceMaker, feel free to send me an email or drop me a comment.  I am always looking for feedback so I can improve the app.

As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

Why Rules Rule

I have to admit, I love rules.

They go against my nature to the core, but they are some of the most valuable institutions I put into my life, both personally and professionally.

Rules are all around us.  We follow so many of them each day and don’t even recognize how valuable they are, because when rules are doing their job, you don’t even notice them.

The first rule of your day is likely your alarm clock.  This is a self imposed rule that you have created for yourself to get up at a certain time in the morning.  Try to function in any meaningful way by completely removing that rule and see what happens.

Almost all games we play have rules.  Without rules those games wouldn’t be much fun.

We drive on the correct side of the road in our lane, following rules of traffic, which if not obeyed put us in mortal danger and make the road quite a scary place.

It is a gross understatement to say rules are important to our daily life.

Yet, I am constantly amazed how many people seem to oppose any notion of rules when it comes to our craft of software development.

There is this notion that rules somehow preclude judgment

Somehow the idea has crept into many of our brains that rules and good judgment, (what we might call craftsmanship), are diametrically opposed to each other.

There seems to be a pervasive thought that rules suck all the fun out of things and take away creativity, skill and experience, reducing the follower of such rules to a mindless robot, replaceable by any other robot.

Not only do I think this viewpoint is completely wrong, but I think it is downright destructive to the craft of software development.

Let us first dispel the notion that rules destroy creativity and its kin.

Think about a game like Scrabble.  Scrabble is a game that is based on a very restrictive set of rules.  You basically have only two moves you can do.

  1. Make a word using only letters in your rack and letters on the board.
  2. Discard some letters to get some new ones.

Rules dictate how many letters you can have and what ways you can arrange them.  Yet, how much creativity is actually created by these constraints?

Music is often seen as a cousin to coding, and is another great example of constraints which breed creativity.  Music has a huge amount of constraint.  There are many natural rules about sounds and chords.  We only have a small amount of notes to even work with, yet people have been elaborating on those 12 notes for hundreds of years and new creative sounds are produced every single day!

If you really take the time to think about it, I think you will find that constraints actually breed creativity not destroy it.

The truth is rules come from good judgment at the right time

Let me posit you this question.

When is a better time to make a judgment decision of what to do when a bear attacks you?

  • When the bear is actually attacking you
  • Sitting at your computer with a huge amount of reference material available to you about bear attacks and a calm peaceful environment

If you chose when the bear is actually attacking you turn to page 32.

Page 32:

bear-attack

Having no rules in which to operate, in the heat of the moment, you decide to “tickle” the bear.  The bear slays you and munches on your bones.  Your adventure has come to an end.

You are DEAD!

The point is that your judgment is much more likely to be sound when you are removed from the situation which you are making the judgment call about.  Unless you are a close relative of Spock, you’ll probably find that human emotions tends to interfere with sound judgment.

This is why I instead firmly believe that we should use our good judgment to formulate rules that we will use in the situations which they apply to rather than to try and execute good judgment when we are engrossed in the situation.

If you still disagree with me here, let’s ponder the example of the alarm clock one more time.  Better yet, I challenge you to make a judgment call each morning of when you should wake up.  You can’t use an alarm clock or any rules.  (Before you do this, you might want to make sure you get your resume polished up.)

alarm clock

How does this all apply to software development?

I’m not going to attempt to address every way in this blog post, perhaps we’ll revisit this subject in the future, because it is so important.  Instead my goal here is to convince you to embrace rules and to not fear setting them for yourself, for your team or for your code.

Some of the biggest failings of teams that I see is the fear of setting rules.  Teams seem to be so afraid of restricting someone or impairing their ability to make judgment calls that they go the direction of never setting any concrete rules, just guidelines or best practices.

There is a huge difference between guidelines and rules.  Guidelines help you make a decision, rules make it for you.  Don’t be fooled into thinking they are the same thing, and don’t fear rules.  I always prefer rules over guidelines, because they are much more valuable.

You can actually measure the effect of a rule, but you can’t easily measure the effect of a guideline.

Let me give you some examples of areas in software development that I think are great places to enforce some rules:

  • Naming conventions
  • Unit testing
  • Process of starting work
  • Who works on work
  • When work is considered done
  • How defects are handled
  • What changes can be made to work in progress
  • What should be in a backlog
  • Language and library choices
  • Data access strategies
  • Dealing with build failures

Every time you are having a conversation which ends up identifying something to improve upon, you should be thinking about how you can codify it into a rule.  Don’t be afraid to step out here.  It’s ok to make the wrong rule and change it later.  If you do this you learn something.

Having rules in place prevents you from making in-the-moment decisions which you later come to regret.

When I go to a buffet, I set rules for how much food I can eat.  When I decide to start a workout routine, I set rules for how often and what duration I will workout.  When I write code, I set rules for how I will write that code.

In any of those areas, when I fail to set rules, I end up failing.  It is human nature.

But rules impede me and end up making me do silly things

Good.  That is called feedback.

Remember back when you were just making judgment calls all the time instead of following rules you or your team preset ahead of time, you weren’t getting any feedback, now you are.  Be happy about it, celebrate!

You can always change the rules.  You can always tweak the parameters, but if you want to have any success in process improvement, it is much like cooking on the stove.  You are much better off with burner dials that have numbers on them or at least some kind of label, then ones with just a blank dial.  If you don’t know where the dial is, how will you know which way to turn it?

Sometimes rules are going to make you do something silly or seemingly extraneous.  Sometimes rules are going to cause you to possibly even do the wrong thing.

But, if you want to have any chance of learning from your mistakes, if you want to truly improve your process, you must resist the urge to break the rules and instead wait for a time to reflect upon the rules and make appropriate changes at that time.

Learn to embrace rules and you’ll suddenly see an improvement in all areas of life where you apply them, especially your software development!

As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

Introducing PaceMaker for Android

(Cross post with my personal blog)

I’ve been working on a secret side project. 

ic_launcher_pacemaker72x72

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.

qr

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.

Main

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.

settings

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.

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.

history

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.

history_detail

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 elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

Keep Pressing on my Friend (When programming seems bleak)

Do you ever get the feeling that you just want to get a cabin in the woods and never see a computer again?

Do you ever feel like someone stole your motivation and sapped your energy like a mosquito in a bug zapper?

I used to think it just happened to me.  The first time it happened to me, I almost switched my major from CS to CIS.  But, the more and more I work in this field and talk to other programmers, the more and more I see the same exact thing happening.  And guess what?  It is happening to everyone.

Not just you.  You are not alone.

tired_man

I’m not talking about burnout here

This is more than burnout.  This lack of motivation energy-sapping-plague can hit a programmer at any time whether you just finished a week of all nighters or you just came back from a peaceful vacation.

I actually find that it is the time when I am furthest from what should be burn out that this phenomenon is most likely to occur.

So, if it’s not burnout, what is it?

I’ll call it programming lethargy.  It actually happens to two other groups of professionals: athletes and craftsmen.

The truth is it is a perfectly normal cycle.  This “barrier” is actually the reason why there are many apprentices, few journeymen and even fewer masters.

When you hit this phase be glad, it means you are about to be tested and if you come out on the other side, you will end up with a renewed interest and passion and leave behind the others that can’t cut it.

Oh, and it will happen again, probably several more times.

Press on my friend

What can you do about this problem?

Don’t despair, just press on.  Stay the course and all will be well.

I am not sure why this happens, but I do know that it is a true test of your desire for the goal, whether to be a better programmer or a better athlete, or a better singer or musician.

The test is whether or not you can still press on when the motivation and passion is not there.

The reward waiting for you on the other side?

  • A renewed passion and energy. 
  • A new kind of appreciation for what you do. 
  • Experience and true appreciation for your craft.

The question you have to ask yourself, is what do you ultimately want to become?  If what you do is more than just a job to you, then you’ll find the strength to press on.

How to press on when the motivation is gone

If you agree with me, or even think that perhaps what I am saying is worth considering, then you will probably wonder how you can get through this phase or test to see the other side.

We can look at athletics again as a comparison to provide some insight.

Think about a professional track runner, training for competition.  Consider what would happen if that athlete decided to not have a formal training schedule, but instead only train when he felt like it.

What would happen when he didn’t feel like training for a week?

Now let’s say he had a training schedule and he followed it, even on the mornings when he didn’t feel like getting up to train.

What would happen if his training was not planned out?  If he didn’t know what kind of drills to do or have a long term plan for the training sessions?

If you want to make it through the times when you don’t feel the motivation and passion for writing code and solving problems, then you have to have a plan.  A solid plan that will ensure that you will be able to press on.

Here are some tips to make sure that when you get struck by programming lethargy, you do make it through to the other side.

  • I’ve talked about this several times in my blog.  Make sure you are always reading a technical book.  Create a schedule and stick to it.  Even 15-30 minutes a day of reading will let you read around 1-2 books a month.  That is a huge amount of knowledge.
  • When you don’t feel like working, break up your work into small tasks and start accomplishing those tasks.  Figure out exactly what you have to do to move forward and do it.  Don’t give in and waste time.  The time you feel the most like killing time, is the time when you must throw yourself into your work all the more.
  • Set some goals for yourself.  Short term and long term.  The short terms goals should clearly lead to the long term goals.  Review those goals frequently and always try to make progress towards the goals.  Even a little bit of progress adds up over time.
  • Don’t start thinking about changing careers or looking for an easier job.  Don’t start thinking you will feel this way forever.  Realize that what you are experiencing now is a feeling and feelings are not trustworthy.
  • Clean up.  Clean up your workspace.  Clean up your computer.  Get yourself some new equipment if it will help.  Feeling like you have a new and fresh environment can do wonders for motivation.
  • Challenge yourself.  Your gut is going to tell you to slow down and relax, but that road leads to laziness.  When laziness comes your way, the best way to fight it is to push right into it!

Well, that is all the tips I have for you for today.  Just remember that you are not alone and what you are experiencing is normal. 

If you’re in a period now where you are motivated and feel great about your work and what you are doing, you might want to bookmark this post and come back to it when it can benefit you more. 

Remember though, setting up good habits and routines now can help you cruise through the hard times later.

As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

    The Web is Not Platform Independent

    There was a time when you wrote a web site and you targeted IE6.

    That time has long passed.

    When you really only had to target IE6, you could pretend the web was platform independent.

    The truth is now the web is neither, nor will ever be platform independent.  It’s just an illusion based on the simple notion that browsers basically just render HTML.

    pegi

    How many platforms are there then?

    This is a surprisingly difficult question to answer.

    Back before the web really took off there were basically 3 platforms to develop an app for: Windows; Unix/Linux; and Mac.

    When we answer this question for the web, really we have to look at browsers as if they are the operating system.  Since the same browser exists on multiple base OS’s but could be different, we have to count each combination of browser and OS as a potentially separate version.

    Windows: IE6, IE7, IE8, IE9 (beta), Firefox, Chrome, Safari

    OSX: IE, Firefox, Safari (more?)

    Linux: Firefox, Chrome

    Android: Webkit

    iPad, iPhone: Safari

    I don’t have nearly every combination listed, but this is what I would consider a good coverage for any kind of public facing website.

    Oh, don’t forget to cross this again with localization and globalization, because you might have a localization problem that only happens in a certain language in a certain browser on a certain OS.

    Not just rendering level differences

    It is also very interesting to consider that a web developer now has to consider how their site will not just render, but be used on a mobile platform. 

    Consider how Google released an iPad version of Gmail.  And although, you may not really care if your site works on an iPhone or an Android phone, you probably should start caring about how it works on tablets like the iPad, because that market is only growing.

    If you have a website that doesn’t work on someone’s iPad when they are shopping online, do you think they will get up, go turn on the computer, and go to your site to make the purchase or they will buy from a different site with a few touches?

    With a phone size resolution, the considerations are even more important.

    Tools help me make the web platform independent

    No tool exists right now that can handle the non-technical aspects of platform independence for your web application, but let us imagine for a second that a library like JQuery really made your javascript platform independent.

    If we were to hold onto that shaky assumption, we would need to make sure that we never wrote javascript that wasn’t written through the JQuery API.  (Which happens to be an extremely leaky abstraction over javascript, CSS, and the DOM.) We would still have to make sure our HTML and CSS tags were platform independent.

    So even if we could get parts of our development to be mostly platform independent, we would still need to test on all of the major platforms, because we could not rely on the platform independence.

    Now, don’t get me wrong here.  I love JQuery.  It makes the job of a web developer so much easier.  But, there is an important distinction.  APIs and libraries like JQuery make it easier to write platform independent web code, but they don’t make our code platform independent.

    What does all this mean?

    We’ve gotten to the point where the most platform independent technology you can use is either Flash or Silverlight.

    I’m not sure if this is the future of development, but it very well might be.

    One important point to draw from this realization is that we shouldn’t necessarily choose to make our application a web application, because we need it to be platform independent.  It seems like about 5 years ago, the web became the default choice, because it was better to have platform independence than a rich UI.

    Hopefully, for the sake of web developers some of these paths die off or converge, or that standards compliance becomes so good that you could really write code for one browser and expect it to work on all the others.

    As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.

    Don’t Parse That XML!

    I’ve talked a few times about how the best code you can write is code you never write.  One of the major places I end up seeing developer writing code that they don’t need to write is when parsing XML.

    A word of caution before I go into how to not have to parse XML!

    What I am going to describe is not always going to be the best solution.  It is an easy solution that will cover simple processing of XML files.  For a large XML file, the solutions I am going to suggest might be memory intensive and take too long.

    Seems like everyone is doing it

    I’ve walked into so many software development shops and seen code to parse XML files.  It seems to be one of those really common things that not enough developers realize can be completely automated.

    I have started to wonder if it is self-propagating.  If developers have a tendency to see it being manually parsed in one place, assume that there is not a better way, then propagate that manual parsing to the next place they go.

    Why is it so bad?

    First of all, it is not an easy task to parse XML.  Even when using an XML parsing library there is a large amount of code that has to be written, especially for a complex XSD.

    XML parsing code is also very fragile.  If the structure of an XML file changes, the code will have to be modified, and the modification can have cascading effects.

    Manually generated XML parsing code cannot be regenerated if the structure of the XML changes.

    Most importantly, any code you have to write runs the risk of introducing bugs and complexity into the system.

    It’s so simple you wouldn’t believe it

    So, how simple is it to automatically parse XML into objects?

    Very simple.  First I am going to give you the basic pattern, then I am going to tell you how to do it in both C# and Java.

    Basic pattern:

    1. Use a tool to generate an inferred XSD from your XML file.  (You can skip this step if you already have an XSD file.)
    2. Use a code generation tool to generate your classes automatically from the XSD file.
    3. In your code, deserialize your XML file into an object tree using the framework you generated the classes from.

    If you are doing something more complex than this, without a really good reason, you are doing it wrong!

    Learning how to do this in your language of choice is a very important tool to put into your tool bag.  There are many times that I have run into the need to parse XML files, where I have saved many hours of development time, by knowing how to automatically deserialize my XML files into objects.

    There are two main ways in which XML serialization frameworks work.

    1. Serializers that auto-generate the classes from the XSD files.
    2. Serializers that use annotations or attributes on classes.

    Using a serializer that auto-generates the classes from an XSD is the easiest to use and can work in most cases.  If you need more control over the generation of the XML, you might want to use an attribute or annotation based framework.

    One of the biggest barriers in getting started with an XML framework is knowing what to use and how to use it.  I am going to cover 3 options that will get you going for C#, Java SE, and Java Android development.

    C# (XSD.exe)

    XML serialization is so easy in C# because it is built right into the .NET framework.

    The only real piece of magic you need to know is the XSD.exe tool which is installed with Visual Studio.  This one tool can be run to infer an XSD from your XML file and then again to take that XSD and produce fully serializable / deserializable classes.

    If you have an XML file named myFile.xml, you can simply go to the Visual Studio command prompt and type:

    xsd myFile.xml

    Which will produce a myFile.xsd.

    Then type

    xsd myFile.xsd /c

    This will generate a set of classes that you can add to your project, and then you can deserialize an xml file with this simple code:

       1: XmlSerializer serializer = 

       2: new XmlSerializer(typeof(MyFile));

       3:  

       4: Stream reader = new FileStream("myFile.xml",FileMode.Open);

       5:  

       6: MyFile myFile = (MyFile) serializer.Deserialize(reader);

     
    It really is that simple.  There is no excuse for hand writing XML parsing code when you can literally take an XML file you have never seen before and turn it into an object in memory in 10 minutes.
    The serialization framework and XSD tool provide options for using attributes to control how the XML is generated also.

    Java (JAXB)

    The steps are slightly more complicated with JAXB, but it is still fairly easy.

    First we have to generate an XSD file from an XML file.  JAXB doesn’t do this itself as far as I know, but there is another tool we can use called Trang.

    First step, download Trang, then run it like so:

    java –jar trang.jar –I xml –O xsd myFile.xml myFile.xsd

    You can also use the XSD.exe tool from Visual Studio if you have it installed or download it.  There are a few other tools out there as well.

    Once you have the XSD file, or if you already had one you had written, you need to generate Java classes using JAXB’s tool like so:

    xjc –p my.package.name myFile.xsd –d myDirectory

    Running this command will produce Java files that represent the elements in your XML document.

    Finally, to create your objects you can use the JAXB unmarshaller.

       1: JAXBContext jc = JAXBContext.newInstance("my.package.name");

       2: Unmarshaller unmarshaller = jc.createUnmarshaller();

       3: MyFile myFile = (MyFile) unmarshaller.unmarshal(new File( "myFile.xml"));

    Not as simple as the C# example, but really quite simple.  I’ve omitted the steps like downloading JAXB and adding it to your class path, but you can see that the process really is not very painful at all.

    JAXB also provides some options for customizing the serialization and deserialization.

    Android (Simple XML)

    You can’t use JAXB with Android.  It seems like because of the Dalvik VM, the reflection part of JAXB doesn’t work.

    I found a pretty good and small XML framework that I am using in my Android app that seems to do the trick nicely.  You have to annotate your classes and create them by hand, but it is very simple and straightforward to do so.

    The tool is called “Simple XML.”

    You can find lots of examples on the “tutorial” tab on the web page.

    Basically, you download Simple XML, add the jars to you class path, and create class files with some annotations to specify how to deserialize or serialize your XML.

    Here is a small example of an annotated class, from the Simple XML website.

       1: @Root

       2: public class Example {

       3:  

       4:    @Element

       5:    private String text;

       6:  

       7:    @Attribute

       8:    private int index;

       9:  

      10:    public Example() {

      11:       super();

      12:    }  

      13:  

      14:    public Example(String text, int index) {

      15:       this.text = text;

      16:       this.index = index;

      17:    }

      18:  

      19:    public String getMessage() {

      20:       return text;

      21:    }

      22:  

      23:    public int getId() {

      24:       return index;

      25:    }

      26: }

     

    To deserialize this xml you just use the following code.

       1: Serializer serializer = new Persister();

       2: File source = new File("example.xml");

       3:  

       4: Example example = serializer.read(Example.class, source)

    Very simple and straightforward.  The only downside is generating the Java class files yourself, but that isn’t really very hard to do using the annotations.

    No excuses

    So there you have it, XML serialization frameworks abound to make your life easier when dealing with XML.  For most simple cases you should never handwrite XML parsing code, even when using a library to help you do it.

    Now that I’ve shown you how easy it is, there really are no excuses!

    As always, you can subscribe to this RSS feed to follow my posts on elegant code.  Feel free to check out my main personal blog at http://simpleprogrammer.com, which has a wider range of posts, updated 2-3 times a week.  Also, you can follow me on twitter here.