OO For Humans Part 2

Outline:

• Introduction
• Inheritance
• Polymorphism
• Abstraction
• Encapsulation

Introduction

  In the last post in this series, I talked about Object Oriented Programming in less technical terms. We’re going to jump into the deep end here though. You see, I’ve already explained this stuff. Now I’m just telling you the technical terms for it. Hopefully even if you are not already a programmer, you will understand this stuff after.

Inheritance

  Ok, the first one is a curve ball. I haven’t clearly talked about inheritance (technical term, not financial). It’s not hard though. Going back to the Hammer example we’ve been using, let’s say you want to make another hammer that does everything exactly the same but doesn’t smah your fingers if you miss the nail. You can do that, and you don’t have to build a whole new hammer. Just use the same one as before, but add a smarter new case around it. Like this in c#:

   1:   

   2:  public class SmartHammer : Hammer

   3:  {  

   4:    public override void OwwThatReallyHurts()

   5:    {

   6:    }

   7:  }

   8:   

   9:  //from our old hammer...

  10:  public virtual class Hammer : IHammer

  11:  {

  12:    public string Color = "red";

  13:    public virtual void Swing()

  14:    {

  15:    }

  16:    public virtual void Nail()

  17:    {

  18:    }

  19:    public virtual void Break()

  20:    {

  21:    }

  22:    public virtual void OwwThatReallyHurts()

  23:    {

  24:    }

  25:  }

  Some of you may notice the extra word in the old hammer code: virtual. That’s just a C# keyword that tells the computer that the new hammer can do something different.

  So we have our new hammer, and we can make it better by changing OwwThatReallyHurts(). Like this:

   1:  public override void OwwThatReallyHurts()

   2:  {

   3:    DontHitMyFingers();

   4:  }

  That’s hit.. I mean, it. (Yes I really did type “hit” at first, and decided to roll with it.) You made a better hammer with minimal work, and it does all the same things as the old hammer with the exception of that one change.

Polymorphism

  So by some magical coincidence, that altered method, OwwThatReallyHurts, happens to be an example of Polymorphism. Polymorphism is the the ability to override a default and make it do something else. That is exactly what we just did. We took the Hammer class and all it already did, but changed one method by overriding it. This is what “virtual” and “override” are for in the above samples. Virtual tells the code that, yes, you can change me. Override tells the code that, yes, I am going to change this code.

Abstraction

  An abstraction is basically hiding details so you don’t have to think about too many things too deeply all at the same time. The fact that I’m using sample code which doesn’t define every single piece of code is an abstraction. Specifically, DontHitMyFingers() is an abstract placeholder for some undefined code. It doesn’t really matter what it does, as long is it does it correctly. I could have used sample code like this:

   1:  public override void OwwThatReallyHurts()

   2:  {

   3:    if(hammer.location - fingers.location < 100)

   4:      hammer.move(-10, "feet");

   5:  }

  It really just doesn’t matter though, not in order to understand what polymorphism is or the other points made here. For this point it does matter. It is exactly the point, and so is the fact the Hammer has the code for Swing() but SmartHammer doesn’t. SmartHammer doesn’t need or want to have that code, it’s only purpose is to not hit your fingers while doing everything else the same. So the code which performs Swing() is abstracted out of the code for SmartHammer; even though SmartHammer can still perform a Swing() action.

Encapsulation

  Encapsulation (define) means to enclose in a capsule or small container. Honestly, it’s easy to confuse it with abstraction. Abstraction is the representation of features while encapsulation is hiding those things which aren’t essential. When you use a hammer, you don’t need to know the physics of how it works in order to use it. That’s encapsulation. You do need to know how use it to swing it. Knowing about the Swing() action without needing to know how it works is abstraction.

   1:  public interface IHammer

   2:  {

   3:  void Swing();

   4:  void Nail();

   5:  void Break();

   6:  void OwwThatReallyHurts();

   7:  }

   8:   

   9:  public class Hammer : IHammer

  10:  {

  11:    public string Color = "red";

  12:    public void Swing()

  13:    {

  14:    }

  15:    public void Nail()

  16:    {

  17:    }

  18:    public void Break()

  19:    {

  20:    }

  21:    public void OwwThatReallyHurts()

  22:    {

  23:    }

  24:  }

  25:   

  26:  void Main()

  27:  {

  28:    //IHammer is the encapsulation. we can still swing it but not know that the color is Red

  29:    IHammer hammer = new Hammer();

  30:    hammer.Swing();

  31:  }

Look again at our Interface and a sample Hammer class (above). If we look at and instance of the Hammer class, we know its red. However, IHammer hides that detail because you don’t need to know it just to swing it.

Conclusion

  Hopefully you can see this stuff just isn’t hard. I hope my explanation has helped you to understand if you didn’t already. There is so much more depth to this and the other areas I’ve covered, but would be overwhelming to both the reader and myself to try to cover all at once. I hope you’ll continue to read my posts and other blogs. If you have any interested, then I encourage you to read a book or take a class. For those already programming or technical, I will be covering topics directed at you soon.

Links:

• http://en.wikipedia.org/wiki/Object_oriented
• http://en.wikipedia.org/wiki/Inheritance_(computer_science)
• http://www.astahost.com/C-Tutorial-Lesson-5-Encapsulation-and-Abstraction-t15427.html
• http://gpwiki.org/index.php/Object_Oriented_Programming:Abstraction
• http://en.wikipedia.org/wiki/Abstraction_(computer_science)
• http://en.wikipedia.org/wiki/Information_hiding
• http://en.wikipedia.org/wiki/Polymorphism_(computer_science)

-j

OO for Humans Part 1

Introduction
I've been working at introducing programming concepts in a way that is, hopefully, easy to understand for the general public. It would help to go back and read previous posts in this series.  You can find them here. I am going to continue using the hammer metaphor in this series. I should also note that code samples are written in C#, but I don't promise they will compile as-is. It's just sample code.
 
Goals:

• define class
• define object
• define OO (OO is an abbreviation of Object Oriented)
• explain reasons

Class:
http://en.wikipedia.org/wiki/Class_(computer_science)
 
OK. You could read the wiki article I've linked, or just take my word for it. I think you'll want to if you take a look at the wiki explanation. A Class is how we define the data and behavior for an object (defined below). It's really just the code that holds data values and performs various actions. If you think of it like the hammer I talked about last time (read it if the next piece isn't clear), it can do a few different things and tell you about itself like this:

   1:  public class Hammer : IHammer

   2:  {

   3:    public string Color = "red";

   4:    public void Swing()

   5:    {

   6:    }

   7:    public void Nail()

   8:    {

   9:    }

  10:    public void Break()

  11:    {

  12:    }

  13:    public void OwwThatReallyHurts()

  14:    {

  15:    }

  16:  }

The above Hammer class will tells us it is Red, and let us perform the usual things you do with a hammer. When you want to use the Hammer in your code, you create an instance (explained in the next section).


Object:
http://en.wikipedia.org/wiki/Object_(computer_science)

"an object is an allocated region of storage" which is programming speak for code the represents a thing of some sort. It could be a real thing or an abstract idea. I think its easy to understand real things, which is why I use the hammer example. A class defines the thing in code; an object is an instance of that class. By instance, we mean a particular real hammer that you can use, hold, and knock some sense into that driver who cut you off. (No, don't really do that)

   1:  Hammer myHammer = new Hammer();

Above is how we might create an instance of the Hammer class, which would be an object. An object is an instance of your class, just like it is one particular hammer you've picked up from the bin at Home Depot. Once you've got your hammer(class instance or real thing), you use it exactly how would expect. Look at the color, swing it, nail something, break something else, and maybe smash your fingers.
 

OO:
http://en.wikipedia.org/wiki/Object_oriented
 
So OO (or Object Oriented Design/Principles/Programming/whatever) is what we're talking about with the hammer color and its actions. There are some specific techinical terms, but those are going to be talked about in Part 2. We are talking about the concepts today: the concept of data continained in an object which tells you something about it (such as color), and the concept of different actions you can do with your object. Heck, you may already have realized that hammers come in different sizes, styles, and colors. That's part of OO as well. This stuff isn't hard after all!


Reasons:
Wikipedia tells us that OO has its root in 1960's era programming and has developed from there. True. It's just taking real world concepts and expressing them in terms of programming so your code can be organized in a way that makes sense. Being organized in code is very helpful. You avoid stupid mistakes, typing the same thing over & over again, and help keep your program working. Being organized is an excellent reason to use OO principles.
 
Having clarity is another good reason for OOP (OO principles/programming). It's pretty obvious what a hammer does, and it should be pretty obvious what a Hammer class does even if its a slightly different style. Going back to our interface talk, you can have a hammer that is red, plastic, or whatever as long as it does the same thing a hammer needs to do.
 
Testing is not an ends but a means, and a good reason to use OOP. Using testing helps build applications with less bugs which is easier to understand and work with. You can test code that doesn't use OOP, but testing code that uses OOP is much easier. In the end it yields code and design which is just more stable. (Read the unit testing post if you haven't already)
 
Next time: What OO terms we've talked about in concept here

-j

Interfaces For Humans

Everyone in the developed world knows what a hammer is and how it looks. We can all operate one to varying degrees regardless of the color, shape variation, or size. You swing it. It pounds nails or breaks drywall/etc. It hurts your finger when you miss and hit your hand by mistake. Pretty standard and easy to understand.

You should try to view your code in the same way. You want it to be easy to use, easy to maintain, and very understandable by the right audience. Using an interface to define what it "looks like" is how to do that. Instead of saying "this is a hammer", you are saying "this is a hammer class." That tells the user that he can swing, nail things, break things, and hurt fingers.

public interface IHammer
{
void Swing();
void Nail();
void Break();
void OwwThatReallyHurts();
}

That is an example of an interface in c# to tell us what a hammer class would look like.  It has methods (aka actions) for swinging, nailing, breaking, and getting your fingers hurt. But I don't recommend the last one. At all. So, OK, great but what good does that do? Well, we now know exactly what something does and how to use it no matter what color/shape/size it is. So let's make a couple hammers. Please notice the use of ": IHammer" in the following code, which is saying this is a hammer.

public class YellowHammer : IHammer
{
   private int swingCount = 0;
 
   public void Swing()
   {
      swingCount++; //just tracking how many times you swing this
   }
 
   public void Nail()
   {
      //thud
   }
 
   public void Break()
   {
      //bam
   }
 
   public void OwwThatReallyHurts()
   {
      throw new HostpitalException("you need reconstructive surgery");
   }
}
 
public class PlasticHammer : IHammer
{
   
private int swingCount = 0;
 
   public void Swing()
   {
      swingCount++; //just tracking how many times you swing this
 
      if(swingCount>10) throw new TopOfHammerFallsOffException("you cant really use plastic hammers, buddy!");
   }
 
   public void Nail()
   {
      //plink
   }
 
   public void Break()
   {
      //tap
   }
 
   public void OwwThatReallyHurts()
   {
      throw new PansyException("it doesnt hurt that much. its just a plastic kids toy.");
   }
 
}

So now you have two hammers, and you know exactly how to user them. BUT. They don't behave exactly the same. One is plastic and one is a nice, solid yellow hammer. The plastic one falls apart if you swing it too many times, and the metal leaves a mark if you hit your fingers. At this point, its all obvious to me that this is good and useful, but I don't know that everyone sees it that way. Since the goal is to explain it simply and clearly, Let's look an example of how to use it.

IHammer hammerInstance = new YellowHammer();

hammerInstance.Swing();
 
IHammer hammerInstance = new PlasticHammer();
hammerInstance.Swing();

You see in the above code you can do the same thing with both hammers. It doesn't matter if one is yellow and one is plastic. Now let's get a hammer without paying attention to what kind, and then use it.

IHammer hammerInstance = MyHammerStore.GetNewHammer();
hammerInstance.Swing();

The magical MyHammerStore gave us a hammer. Since we know how to use a hammer, we just use it. It just works. If all you care about it swinging the hammer, then you don't care what it looks like; just that you can swing it. This is an oversimplified example which hopefully makes the principle easy to understand. How, why, and when to use it would take more time to explain. To give you an idea of a real-world-like scenario, imagine you are writing a school grading application. You will want to save a grade for a student. Your code might look a little like this:

IStudent student = MyClass.GetStudent(studentID);
student.SaveGrade("history class", "A+");

You don't care what the student class looks like, just that you can save the grade on the student record. You don't care where or how its saved; only that it is saved and you can look it up later. Simple. Easy to understand and use. Done.

references

• http://msdn.microsoft.com/en-us/library/87d83y5b(VS.80).aspx 
• http://msdn.microsoft.com/en-us/library/aa260635(VS.60).aspx

About For Humans

1. An MVC Argument For Humans
2. Beginning IT Careers For Humans
3. Unit Testing Is For Humans
4. Agile For Humans
   

Agile For Humans

"Be Water my friend" - Bruce Lee 

Wow! Go ahead and watch that again; I'll wait right here.
 
So you might be asking "Why Bruce Lee", and I would answer "because he's accessible/understandable." Also, the quote is somewhat relevant to the topic, which is how to develop software. By that I mean what process you can use to guide a project to completion. Sure you could go all cowboy and make things up as you go, but that doesn't generally work well. I know; I've done it. It is important to have some sort of process to drive things along and check your progress. That's really important if you are working on a schedule.
 
In this "For Humans" series, I'm trying to gently introduce software development in non or less technical terms. This is a bit tougher topic, but I will do my best.
 
There are lots of ways to do lots of things, or as they say where I grew up "there's more than one way to skin a cat." Never did understand why you'd want to skin a cat. You can't sell the pelt, and it might be illegal. Thankfully software development is definitely not illegal. Though some people say managing developers is like herding cats, skinning developers is DEFINITELY illegal. And really creepy. One traditional approach to managing software development is called Waterfall. It is strict although you can implement it in lots of variations; and the basic idea is do all the design up front and then don't veer off course.
 
Waterfall takes a lot of ideas from engineering disciplines, but software development really doesn't fit well into that model. Things change, flaws are discovered, and assumptions turn out to be wrong. To address this, a set of principles has been identified and named "Agile." No process is perfect, but Agile is rather good at adaptation, and can also be implemented however makes sense for your business or project. This is the "be like water" moment.. please pause and let the enlightenment flow from my text to your brain. Software development requires adaptation, and Agile (or XP or Scrum) is a process for managing changes in development.
 
It's a little like learning English. There are rules, but there are also exceptions. "'I' before 'E' except after 'C' and when sound like 'A' as in neighbor and weigh ..or in seize, or weird, or.." It comes down to knowing the principles and practising. In truth, I don't practise all the rules all the time. I'm not an elitist, but a pragmatist. What happens in practising is you naturally get better (obviously) and you develop better intuition about how to apply your practices.
 
Agile core principles can be found here, and core values/manifesto found here. I'll leave it to you to read those, because what's more interesting are the practices.
 
Test Driven Development (link)
This is where I do get more serious, and have already blogged on it some here(http://computeristsolutions.com/blog/post/Unit-Testing-is-for-humans.aspx). There are reasons why I'm passionate about this. For one, it really works. By writing tests first, you are really setting expectations of how your code should behave. After that, there's a natural evolution of your code into something that works, has fewer bugs, and becomes a good design. Please go back and read my earlier article for more info.
 
Behavior Driven Development (link)
From test driven development, this was a natural evolution. It's focusing on the expectation part of writing tests first; only it strives to express the intent more clearly using conventions. I'm not really sharp on the distinctions, so I recommend you read more on it yourself. Jean-Paul Boodhoo blogs often about it, and is a good resource.
 
Continuous Integration (link)
Here's another activity that will really help move your development along. Even if you are the only developer, setting up an automated build of your code will help you catch problems sooner. Think of it like driving. You wouldn't want to drive down the road with your eyes closed and only open your eyes every so often to get a peek of what is going. You want your eyes open all the time so you know what's going on around you, which is what continuous integration does for you. Kent Beck's XP books talk about getting early feedback and this is part of how you achieve that.
 
Pair Programming (link)
OK, so here is where I can't pretend to be an expert or anything like it. I don't do pair programming. I'm not saying I wouldn't or you shouldn't; just that I am not in the situation of being able to. Many of those that have swear by it. Even Ayende (everyone should read his blog) pairs up. I've certainly seen the benefit of code review. So I guess I see how this would basically be continuous code review. I do recommend considering it, especially if you are just getting into coding and can pair with someone you can learn from.
 
Agile Planning (link)
This can actually be fun. You divide up your project into small, reasonable tasks. You can use these tasks for estimates. Pick some to get done each week. Let the devs pick which tasks to do. Many agile articles suggest actually have real memo cards with each task on a board or basket to choose from. It certainly helps avoid overlap between developers. You can use the task card to plan and estimate the project to. Just estimate each task, and get help to arrange them in order of which must be done first with the remaining filled in. Simply put, breaking things down to their smallest logical part makes planning, estimating, assigning, and adjusting all easier. It's almost zen-like how it will fall together.
 
Short Meetings
This is more of a Scrum attribute than specifically an Agile attribute, but it's one I find highly useful. Keep the meetings short. Try meeting everyday for 10-15 minutes just to share status. Stand up the whole time to discourage long conversation. If something needs discussed longer, schedule a meeting or casually meet outside of the short meeting; and include the least number of people needed. Less time meeting is more time producing.
 
Conclusion
Hopefully this introduction to Agile wasn't too boring. It's tough to cover this in short and simple terms. My usual stories would take up too much extra space, and I couldn't write an in-depth article on Agile in my few spare minutes over a few nights. To learn more, read online articles and pick up Ken Beck's XP book. I recommend learning Agile if you are just starting in development, or already have but don't yet know it. You should also learn about Waterfall so you understand traditional software life cycles.
 
Those in the know, will probably notice that I mixed information about Agile, Extreme Programming, and Scrum. It's all related, and I don't have the time or space to cover it all in detail. I hope this suffices as a reasonable introduction. If I could beat one thing into your head with a really big, shiny hammer which has a red, non-slip handle, it would be that you should follow some process. I've been down the cowboy coder path, and the waterfall path. I recommend using Agile/XP/Scrum practises in most cases.
 
Additional resources:
A good read in this area is Kent Beck's Extreme Programming Explained 2. Yes it's geared to a technical audience, but I think its readable for everyone.
A little Scrum intro video: http://www.youtube.com/watch?v=Q5k7a9YEoUI&feature=related
Extreme Programming: http://en.wikipedia.org/wiki/Extreme_Programming
XP Practises http://ootips.org/xp.html
Kent Beck on XP http://www.extremeprogramming.org/
Ron Jeffries on XP http://www.xprogramming.com/xpmag/whatisxp.htm

-j

Unit Testing is for humans

Audience note: this is written for non-programmers or beginning programmers. Don't skip it though, it lays out reasons why unit testing is good. Should also be witty and entertaining. I've been practicing this at the Improv. ;)

When I was a kid, I had one of those AM radio kits that you build yourself. My dad told me a little about electronics, and with the instructions I tried to build it. Several times. I would get to a point where I thought it was done, and put it all together. Then I'd find something didn't work or wasn't right. So I would have to take it apart again and try to figure it out. After doing this a few times, I realized it was easier to check the soldering, wires, and knobs as I went along before putting it all together in the cheap case. I got it partly working with a nice, clear static sound before I lost interest and used the parts for something else. It was a good lesson though.

It's a bigger pain to find out later something wasn't working than to take the time right away to check it. In software development, we call this Unit Testing. 

What is this Unit Testing you speak of?

Unit Testing is the practice of breaking software into the smallest logical parts and testing that each small part does what it is supposed to do. This also has the effect of driving you to build pieces that you can test and maintain more easily. Testing your code has some very specific benefits: you know it works. The process of doing this also benefits you by creating a path toward a good application where all those small parts work together well.

Why would I want to do that?

helps with design The resulting design (how things fit together) is naturally easier to maintain and fix. Like water flowing down hill, you can more easily tell where its going and where it came from. This makes following it a lot easier. It also makes changing it a lot easier.

helps solve problems  Sometimes you get stuck on how to build a certain piece. You can write the unit test first, which I recommend anyway, and then start writing code until the test passes. In effect, you are first defining what you want to happen. Then trying to make that happen, and you are done when the test passes.

makes maintenance easier If you have a bunch of tests and discover a bug then you can more easily find and fix the bug. If there is a failing test where the bug should be, then start by fixing the test. If the bug is still there, you write a test that will pass when the bug no longer happens. Now make the test pass. In doing this, you are isolating the part(s) where the bug happens which makes it easier to find. When its easy to find, its much easier to fix.

easier for other dev's to figure out Imagine you just started trying to use that radio I kinda built when I was a kid. You have the manual and a not really working radio. If I had tests to go along with each part, you could check each test to see what it does and make sure its right. Then fix the one (I'm sure it was only one) that wasn't working. Smaller pieces are easier to understand, which is important even if you are an expert with the language its built with. Maybe unsurprising is that it's often your own code. It's easy to forget what you did a few weeks, months, or years ago. Having those tests help.

Why doesn't everyone do that?

never heard of it/don't know about it  This is pretty obvious. You're a new developer who is either self-taught or wasn't taught unit testing in school. You learn, you believe, you test the daylights out of everything forevermore.

takes too much time It's true, sorta. It takes time to add unit tests and it can sometimes feel like its too much time. It will save you time when it comes to fixing bugs or adding features. You will have less bugs, and changing things takes less time because you know immediately if you broke anything.

don't see the point Hopefully you do after reading this far. But just in case, remember the AM radio.

my code is good enough without it It's true some of you and myself have coded without unit testing, and did just fine thank you very much. I remember those days: 80 hour weeks to fix the last bugs before releasing a product. Sleepless nights fixing a broken deployment. Yeah, it was great. But I don't much have to do that anymore. That's partly because of experience, and partly because testing my code as I go helps me find problems sooner.

other people keep deleting my tests anyway OK, I hadn't really heard this one before today. I have some guesses as to what may have happened, but it doesn't really matter. The problem is the team wasn't supporting the unit testing practice. It's hard or impossible to move forward with unit testing in a situation like that. The fix is to have them all read this article so I can tell them how right you are. hehe. Really, discuss why it helps. If this article helps explain that then great because that's my point. 

my app is too hard to test I have a lot of sympathy for this; a big part of my day job is in this situation. The closest we could come is called "integration testing" which is basically like unit testing except we aren't breaking it down into smaller parts to test. You don't get the benefits of real unit tests, but it's better than nothing. Work unit testing in as much as you can and build team support. After that, you have to figure out what's next. Sometimes, it's not even up to you.

MbUnit, nUnit, xUnit are all .Net testing frameworks. They include pretty application to run your tests and show you the results; typically green for pass and red for fail. Everything you'd expect after taking Driver's Ed. class. testdriven.net is a utility which helps make running your test easier. These two powers combine to give you nearly unlimited power less work in building and checking your tests. 

These are a few unit testing tools for the .Net developer. There are so many tools to help make it easier to test your code. It's really a life lesson; check your results instead of assuming the outcome is what you expected. It avoids a lot of problems later on even if its a little trouble right now.

Blah blah blah..

To be clear, I am not a zealot (read with Richard Nixon voice). In fact, I didn't code with unit tests when I decided to learn Ruby on Rails about 2 years ago. I would make a rails app and play around then start over. It didn't really matter because it was just throw away code and I only wanted to see how it worked. Until I stumbled on an idea that was actually useful to me. I've slowly worked on it for the last year since I don't have a lot of time for it; and now its about 90% functional. But no unit tests, which is horrible because rails is big on testing. I may have actually been able to complete it by now if I had unit tests, even if I didn't put any more time into it. Now I have to go back and add them because I know it makes a difference.

Time to get back to work. I'm at a point where I need to write some unit test, and I'm excited.

-j

Beginning IT careers for humans

A friend recently asked my advice on getting started in IT and how to learn more about it. Being the super generous, ever wise person that I am, I told him to take a flying leap.. just kidding.

It made me think because I wasn't sure how to advise him about figuring out what area of IT he might find most interesting. With current market conditions, jobs aren't jumping up and grabbing you but IT has remained better than others. It's probably not as easy for beginners although now is a good time to start learning. You can check monster.com, dice.com, or even craigslist.org to find IT job postings to see what is going on in the job market. BUT before you do that, you should have an idea of what IT field you are interested in, and the key terms to use in searching for that shiny, new IT job.

Pick your flavor

There are quite a few different areas within IT, and Ill name a few. Readers, feel free to comment on any I missed or add details you might give to a friend.

Hardware

    If you like building and putting things together, this might be a good area for you. It's an engineering discipline, but is often combined with the resposiblities of purchasing and tracking assets.

Networking

    This area involves the wiring and connection issues involved in computers talking to each other. It can be for office networks, or meeting communication needs of a high traffic website. It's often rolled up in a hardware position, but both could turn into a high end specialist.

Help Desk / Support

    This is usually helping people solve their problems.  Could be on the phone or in person, but you really need people skills and patience for this field.  A few different paths for this might be internal help desk for a company, help desk for other companies, or contractor who supports local businesses.

Software Testing

    If you like to mess around with programs and figure out how to break things, you'll probably do great and have fun in this area.

Software Development

    It's what we do. It's mainly divided into two areas: Internet/websites, Installed programs (like Mircrosoft Word ot some other programs.) Problem solving is a must, but so is creativity.

Database Development or Management

    The art of managing and manipulating data can be consider it's own special discipline; especially when it comes to dealing with very large or high volumne databases. It's not for everyone, and the only way to figure it out is to try it. Start learning programming and pick projects that use databases; that will introduce you to it. After that, you'd need to read topics specific to database development or management.

Project Management

    Organizational skills. After that it's a mix of different things, and sometimes you might be asked to fill other roles (like Help Desk or hardware)

Product Analysis

    This is making the business rules for software. People skills, creativity, and some knowledge of software will serve you well.

There's a variety of combinations and things are always changing. With so many different tools, languages, and technologies, I couldn't list nearly enough in a reasonable amount of space. Pick which area you like, then start learning about the specific technologies in that area.

It's important to be a good problem solver, be comfortable learning, and have good communication skills. After that, there's a lot to say for experience and determination.

Add your mix-ins

So how do you get started? Well a degree certainly helps and so do professional certifications, but I'd suggest trying some of these before committing. There are plenty of entry level tutorials online. Use a search engine to find them by searching for "tutorial " and your keyword like "website programming". If you're not already aware, there are many different programming languages so start with a common, object-oriented language if you are thinking of going into development. We use C# and Ruby a lot. Java is another good choice.

Even if you don't find a free course or podcast, you should look for an inexpensive introductory class. You don't want to commit a lot of money until you know what you are getting into. I recommend online sources because it is easier to fit into your schedule.

Once you've got a good idea what you are interested in, talk to friends if you know anyone in the industry. Try local user groups or online groups. AZGroups is a local .Net User group with friendly, helpful people. I use Google Groups quite a bit myself for discussing IT topics, and helping people find answers when I can. (Email me if you want suggestions for groups in the Phoenix area.)

If you are truly committed (and being committed to a mental health institution is a requirement for some IT jobs), then go get the training and basic skills you need. There's no reason to spend a lot either. Look at community colleges or certification programs. Being a good problem solver, learning fast, and communicating well is more important that a degree or certificate. Those just show your commitment and some presumptive, basic level of ability.

Lets roll

The next step is landing that first job. As with any job, networking helps a lot. Try LinkedIn.com, which is a professional social networking site. Go back to those friends and user groups you talked to. Check those jobs sites I listed above, and search for others. There are many more than the ones I listed. Even though I'm a seasoned professional, I've been known to go door-to-door in search of work. (There's a good story there which maybe I'll tell later.) You do what it takes, and it usually works out. Especially if you are passionate about your choice.

Blast off

After you've gotten some experience built up, you'll find it easier to pick where you want to go with it. Let's say you become a website programmer and you love cars. Perhaps you build a website focused on small track car racing and earn money selling ads. You'll love it and it pays the bills. Or maybe you land a programming job with an autoparts retailer, or something else related to your passion. Who knows. What I do know is things work out best when you stick to what you like; and the best ideas are ones you would love yourself. Passion is the key to happiness in any career, and is especially true in IT. 

An MVC Argument for Humans

MVC is all the rage it seems. I really didn't get it at first; that is until I started using it. That was a few years ago. Now it's my prefered pattern for web development. It wasn't originally a web pattern, but it turns out to be a great way to keep things clean in a web application. It's a good convention, in my opinion.

Now it's not always the best choice. It depends on your needs. It certainly takes extra work if you're going to build it yourself, but chances are you don't have to. Several frameworks have sprung up to fill that void. Probably the most famous is Ruby on Rails. It's obviously for the Ruby language, and there are others out there for Ruby. There are frameworks for PHP, Java and .Net as well.

We mostly work with .Net (with a dash of Ruby) so let's talk about that for a minute. In my opinion, there are 3 major MVC frameworks for .Net.

• ASP.Net MVC
• Castle Monorail
• Promesh.net

ASP.Net MVC is Microsoft's mvc framework. Castle Monorail is part of the excellent Castle Project, an open source project. Promesh is another open source project, which came from a developer's personal toolbox out or real world use. I'm more familiar with the first two. We use Monorail in our project, so have a little bias. (computeristsolutions.com is built with monorail for example)

Convention

So how often do you look at an old project or old code and think "What was I doing here?" or "What the **** was the other guy thinking? What a moron!" It happens. Sometimes I'm the other moron. It's easy to forget what was going on as time passes. Sticking to a convention helps avoid that. You know the convention, you can follow the code a lot easier. You can find where things are at. Easier maintenance is a big deal, and MVC helps with that. A lot.

Testing

Do you test your code, unit test perhaps? You should. Go. Do it. Now! There are lots of reasons to use unit testing, and its not really my point in this post.. but let's leave it at you KNOW your code works when you commit it to source control. MVC helps and encourages seperation of code so that testing is easier. By doing so you will be able to more properly, fully, and completely test your code. (Also look at Inversion of Conntrol; look at Castle Windsor) The function of a unit test is to test a small unit of code. If everything is lumped together then testing small units gets hard or impossible. It just so happens it makes maintenance hard too.

Design

This isn't really talked about in most MVC articles I've read, but it really is a big time savings in our experience. When you build and maintain a website, you will have to alter or completely change the design and layout. If you're using a MVC framework, it's a lot easier. You typically have a central layout which is used for all or most of your pages. You only have to edit that one layout to change most of the site. If you were careful to make everything CSS friendly, then you have even more power over your site by changing the layout and/or the CSS. Even when a plain HTML site would be fine, I lean towards using an MVC framework for this reason. Site-wide layout and design changes take minutes instead of days or hours.

Conclusion

Hope this brief, humanized argument for MVC on the web makes sense. There are many good choices for frameworks. We recommend Castle, and the upcoming ASP.Net MVC framework looks pretty good. There is a small learning curve in adopting it, but it will payoff big in time and headaches saved. If you need to adapt your current ASP.Net site instead of writing a new one, I'd suggest looking into the MVP pattern. See MVP here, here, and here. Good luck and have fun, which I'm sure you will.

-j