The Daily Module

Typed DataSets versus Domain Model

2008-10-07T21:14:00.005-05:00

Recently I worked on a project that used typed DataSets as a domain model. Because of my experiences on the project, I decided to post about the usage of typed DataSets for domain modeling. I personally didn't have much experience with typed DataSets since I always preferred classic domain modeling using good OO principles and user-defined types, so this was a nice new task.

Initial Thoughts
When I started on the project, my first task was to create a WCF persistence service. This persistence service would interact directly with two typed DataSets in the way of classic CRUD.

My initial thoughts were the use of typed DataSets were pretty nice. It was quite easy to populate them from a resultset retrieved from a SQL Server database. The built-in support within the ADO.NET API was nice. Built-in support for simple data validation (not allow DBNull and such) was nice. Overall, my first impression was that typed DataSets are nice to work with, almost fun.

Reality Set In
Those thoughts quickly waned. What I started to find is that typed DataSets allowed inconsistent behavior when using them; for example, you can set a column's AllowDbNull property to false but then set its default value to DBNull.

Continuing on, I discovered other problems that I consider serious. One is a very simple modeling issue: multiplicity. Simply stated, you cannot enforce a 1:1 relationship between two tables in a dataset. More accurately stated, you cannot control the multiplicity of relationships. That is, if you're modeling automobiles, and you have a Car table, you cannot enforce that the Engine table only has one record; by nature in relational models, a foreign key is 1:M, and with typed DataSets, this is no different. With classic domain modeling, this is of course trivial. There are also problems with aggregation, composition and generalization with typed DataSets as well; this will be discussed later.

Good Does Exist
There are some good things about typed DataSets that you get with using them. For one you get free ORM, which in my book is huge (restated, you don't have to do ORM since you can use built-in ADO.NET, and phrased yet another way which is that you only have two choices for ORM: manual property setting and DataAdapter.Fill). Another nicety is Visual Studio will automatically generate strongly-typed query methods on a DataTable for keyed columns when using the DataSet designer, such as GetCarByID().

Another nicety is a DataSet's built-in support for databinding. One concern with using classic domain modeling is the fact that you have to build in data binding support. What I've done to overcome this is create reusable base classes that implement the required interfaces (such as INotifyPropertyChanged), support for undo/redo, and use BindingList for binding entities to a DataGridView, however data binding with domain models is largely a manual (and sometimes complex) effort. However my experience has been that the trade off is worth it from an architectural quality standpoint.

Typed DataSets vs Domain Modeling: Which to Use?
I could probably spend another 10-15 pages about why I always prefer domain modeling over typed DataSets, but it all boils down to what adds real business value.

What I've found is that you will generally spend less time building your data layer when used typed DataSets. This is because of the fact that you can use the ADO.NET API for data access and ORM. That is, you can depend on an IDataAdapter implementation to fill the DataSet. That means in the complete interest of RAD, typed DataSets increase time-to-market.

That being said, for the reasons mentioned above, typed DataSets cannot produce accurate domain models, nor were they ever meant for such a thing. Typed DataSets work like relational databases, which do not support even basic OO principles. Of course typed DataSets are classes, so there is some support for OO (after all, typed DataSets descend from DataSet), but typed DataSets in themselves are not the entity: the tables they contain are, which is why the application of OO fails when modeling a domain.

Simply put: domain modeling with user types are the right approach to domain modeling. With user types, you can support generalization, (accurate) multiplicity, (better) code reuse and other OO principles that improve the overall architectural quality. Development teams can spend lots of time getting products to market, but the simple fact is architectural quality will have a postive or negative impact on long-term and repeatable success, and all too often, not enough time is spent on quality since its ROI is generally not measured. This is often followed by more bad code and bad architectural decisions, but that's a discussion for another day (blog?).

Software Modeling: Why Bother?

2008-10-06T21:32:00.010-05:00

If you've written software for any length of time professionally, or even if you're in school, you have likely come across at least one UML diagram. If not, let's have a quick refresher (or introduction for those under the proverbial rock).

UML is a formal language created to model different aspects of software construction, user interactions with software, activities that code and/or users carry out, and more. The standard UML diagrams are Class, Sequence, Activity, and Use Case diagrams. A quick description of each is below:

Class diagrams - these diagrams are used to present visual models of software classes, and are generally used for languages with some measure of classic OO like C++, C#, Java and others.
Sequence diagrams - a sequence diagram is a high-level diagram used to visually depict the sequence of events for a given software module, IPC/RPC call, a user-initiated event in a software system, and just about anything that contains a sequence of events that can be illustrated (even washing clothes, which I can graph easily but I try to avoid in real life).
Activity diagrams - activity diagrams are used to illustrate a specific activity. This is another high-level diagram that depicts sequences of events, except that an activity diagram is more thorough in illustrating how those sequences are carried out.
Use Case diagrams - use case diagrams are used to visually illustrate what a given item will be used for. This is usually used to depict use cases for a screen in an application, a software module, or anything that has uses and is useful (like a washing machine).

In case you haven't noticed, UML diagrams are used to visually convey information. That means the consumer of a UML diagram should be able to visually grasp the information being conveyed. If this is not possible, the diagram isn't useful, and in practice, this happens all too often (like when a class diagram has a few hundred classes). What this means is there are some good guidelines on what should go into a UML diagram (Martin Fowler has a great book on the subject). For now I hope I've conveyed lexically the visual nature of UML diagrams.

Class Diagram Example
Sometimes the best way to illustrate stuff is visually (are we getting somewhere yet?), so let's look (visually) at an example of how class diagrams provide the ability to convey information about an object model.

Below are 3 classes and an enumeration in C#. Firstly I show the code files for each class, then below that is a UML Class diagram. Which would you say helps you get the full picture more rapidly and definitively?

public abstract class PersonBase{
public string Name{
}
public string Address{
}
}

public class Citizen : PersonBase{
public CarTypes CarType{
}
}

public class Employee : PersonBase{
public double PayRate{
}
public string Department{
}
}

public enum CarTypes{
Car,
Truck,
Van
}

You can see how the object model is depicted much more succinctly and rapidly with the UML class diagram. You can view all classes at the same time, and how they relate to each other. With code files, you only have the language syntax to help you understand the interactions between classes. While developers can be expected to know the language well enough to understand the object model, when discussing architecture and design, thoughts are much more succinct using modelling then they are using code files.

Sequence Diagram Example
Below is a sequence of events that will occur when washing clothes. This sequence of events are listed out using bulleted points.

Wear clothes; dirty 'em up
Load washer with clothes
pour soap in
Set washer
Start washer
Wait for washer to finish
Move to dryer
Set dryer
Start dryer
Wait for dryer to finish
Fold clothes
Put clothes away

Let's take a look at the sequence diagram for the above steps:

Now lets take a look at the above steps in a sequence diagram:

Sequence diagrams are much better at conveying the actual order of steps and the interaction between systems. Another thing sequence diagrams do much better than a bulleted list is looping, which I won't demonstrate here.

UML as Blueprints
When an architect is designing a building, the architect will use blueprints, which is a visual drawing created using complex CAD software. It visually depicts the size of rooms in height/width, the location of pillars in a building, the size and angle (property lines) of the lot the building will reside on, the location of walls, doors, and windows, and many more things that I won't mention. When conveying the design of the building to anyone, the architect will rely on these blueprints to convey every last detail of their building with complete accuracy.

When a construction team is hired to create the building, the construction team will use these blueprints to ensure the architects design is implemented correctly. Along the way, the construction team may point out flaws in the architecture that have to be corrected. In this case, the use of blueprints makes perfect sense. In fact, it could be stated that the use of blueprints is required to construct the building with any level of accuracy in regards to the architect's design.

In the book Code Complete Vol. 2, building software is likened to formal construction of buildings; in fact, the terminology "writing" software is eschewed for "building" software and UML diagrams are likened to software "blueprints". In other words, it is stated that software construction parallels building construction: architects design the software, developers construct the architecture using the architect's output, QA staff perform "building" (quality) inspections, and UAT processes provide the "walk-through".

When thinking about software as construction, it leads you to see the benefit of visual documentation. UML serves this purpose very well, as it allows you to blueprint every aspect of your system, from business requirements down to implementation details such as abstract base classes and descendents, interfaces and realizations (implementors), and so on. It helps you to see how applying development process to building software aids in creating repeatable success; that is, building and shipping software is one thing, being able to do it over and over in a systematic fashion is quite another, and the latter yields more long term success.

Closing
I hope that I've demonstrated how things can be conveyed using visual diagrams much more succinctly and rapidly. I hope that you can see the benefit of class diagrams and sequence diagrams, and I would encourage you to look into activity and use case diagrams. In other words, I hope that you can see the real benefit of UML documentation. It not only provides visual aids in understanding a software system, it can act as a true software blueprint when formal architecture preceeds writing code (and even when it doesn't).

UML can be used to get new team members up to speed on the architecture. UML can give help the business players on your team to really understand what developers are doing in that dark room, and can help everyone speak the same language. Finally, UML introduces formal architecture, which gets developers/architects thinking about the solution to the problem (the implementation) prior to writing any code, which lends itself to accurate and quality implementation.

Wow It's Been A While!

2008-08-08T21:37:00.002-05:00

So I can see that it's been quite some time since my last post - it was shortly before I started for TopCoder.

Well here I am posting again. I had actually moved my technical blog to my own site but now I'm moving back. I think it's much better for anybody needing to refer to my technical blog to not have to deal with the noise of my personal blogs :)

So anyway, I'm still working for TopCoder which is awesome. I'm having a blast! Currently I'm implementing a workflow that processes a set of client data and runs some prioprietary calculations against some of the values in that data set. It's a ton of fun.

So this is my triumphant return; though it's highly likely I won't have much time to post. We'll see how it goes?

Funny where life takes you

2007-10-06T17:42:00.000-05:00

About 2 years ago, I was introduced to a website called 'Top Coder' by a guy I worked with. His words to me were "If you ever want to find out who the better programmer is, we can go here and compete". I was very intrigued, but we never did compete. From that point on, I regularly logged in to Top Coder's site and reviewed the available competitions. I thought to myself, "I wonder if I'm good enough to compete against people I don't know". I never did compete, only watching these competitions from a distance. One time I did download a distribution for a development competition that was in progress, but I just decided I hadn't the time to compete, so I didn't. Well, one day I get a call from some one at Top Coder, they were wondering what I was up to currently, as they liked my skillset and was wondering if I'd be interested in interviewing! I had just started a new gig somewhere else, and thought it best to wait it out a bit and see where that gig went.

For the unenlightened, Top Coder hosts the worlds best programming competitions in the world. They use this process to build great software. If you think you've got what it takes to compete, you should do so asap, because not only can you prove it, but you can make money doing it.

Anyway, I couldn't stop thinking about Top Coder, and the allure for working at Top Coder never waned. I went through the interview process, and with great avidity, I accepted an offer to join. My first day was officially October 1st, and I'm never looking back. The feeling I get from everybody so far is this is the best team I've ever joined. I've spent a few years contributing to open source software to build my skill set as a programmer, but after going through the interview process and competing for the first time recently, I now wish I had spent more time competing. That aside, here's to my joining a company I think has the best process in the industry, and a company I am super proud of being associated with.

Wow

2007-08-29T13:00:00.000-05:00

It has been an extremely long time since I've posted on here, but I'm back in the saddle, and will be coming with some new posts very soon; keep checking back.

Answer to What's Wrong With This Code

2007-02-22T10:51:00.000-05:00

I can't believe it's Thursday already!! Yes, I forgot to post the answer to the previous problem yesterday, so here it is:

Looks like 3_4 on 7 got it right:

3_4 on 7 said...: I don't believe this would compile. I'm not sure what the output would be but, since C# does not support optional parameters, I believe you're required to supply a value for all of the parameters, including the optional parameters.

However, the VB developer in this instance should make sure that their code is never going to be in a library that is being used by another language as including a universally unsupported concept like optional parameters would be poor development practice.

C# does NOT (to my dismay and probably the dismay of many other developers) support optional parameters, therefore when referencing the code in C#, it would display the parameter list as having required parameters. See you next time!!

What's Wrong With This Code?

2007-02-19T23:09:00.000-05:00

In this (hopefully) multi-part series, I will be presenting challenging (maybe to over-glorified web developers or egocentric re-implementers like previous developers I've worked with, you know who you are! =^) programming problems that readers can solve via comments, and I will respond either with the winning comment or just the answer because nobody responded, in which case I will cry.

What's Wrong With This Code?

Say you have the following VB code:

Public Class Adder
Public Shared Function Add( ByVal a As Integer, ByVal b As Integer, Optional ByVal c As Integer = 0) As Integer
Return a + b + c
End Function
End Class

Then you have the following C# code referencing the previous VB code:

public class AdderClient{
public static void CallAdder(){
Console.WriteLine(Adder.Add( 1, 2 ));
}
}

Will this compile? Why/why not? What would the output be?

The answer will come Wednesday!

Favorite UML Tool

2007-02-16T11:51:00.000-05:00

I didn't post yesterday in this (psuedo) daily blog; I'm a baaaaad man!!

Anyway, I wanted to share what has become my official favorite UML/Design tool - Enterprise Architect.

As you know, I'm leaving my current post and moving on to new ventures, and it's been quite some time since I updated my UML diagrams with the code I've been working with. Well, I figured up Enterprise Architect, created a new project for each programming project I had been working on, and imported them into EA. This is where EA is absolutely awesome: it reverse-engineered all of my code and generated class diagrams! This feature alone must have saved me hours of work.

Also, a few months ago when I had started one of the projects I was working on, I fired up EA, and did a lot of visual design using UML models. EA also generated the code for me in my desired language (it currently supports enough language to be useable in almost any shop like Java, C#, Python, PHP, and more), and it allowed me to specify namespaces and other rules when code was generated (I used it for C#).

Check out Enterprise Architect, along with its sweet Visual Studio integration at http://www.sparxsystems.com/ea.htm.

Anonymous Methods - Perfect Stranger Or Close Relative?

2007-02-14T08:37:00.000-05:00

Since most of the world (minus those currently under rocks or archaic cave dwellers) knows what anonymous methods are, I won't spend too much time analyzing them here. I did however come across something interesting when analyzing the IL of an assembly with a class that uses an anonymous method for sorting a collection. First we'll take a look at code and it's IL after compilation without an anonymous method, and then we'll try to put a face on the anonymity of anonymous methods.

Here's the code without anonymous methods:

using System;
using System.Collections.Generic;

public class SortMan{
public static void Main( string[] args ){
SortMan s = new SortMan();
s.Test_Sort();
}

public void Test_Sort(){
List dates = new List();

dates.Add( DateTime.Now );
dates.Add( DateTime.Now.AddDays( -30 ) );
dates.Add( DateTime.Now.AddDays( -120 ) );
dates.Add( DateTime.Now.AddDays( -5 ) );

/*delegate( DateTime d1, DateTime d2 ){
return d1.CompareTo( d2 );
}*/
dates.Sort( this.Sort );
}

private int Sort( DateTime d1, DateTime d2 ){
return d1.CompareTo( d2 );
}
}

And here's its IL (ildasm.exe):

Obviously our 'Sort' method is a member of our 'SortMan' class, just like any other method we would write in any other normal class. What about using an anonymous method?

Here's the code for our 'SortMan' class with an anonymous method:

using System;
using System.Collections.Generic;

public class SortMan{
public static void Main( string[] args ){
SortMan s = new SortMan();
s.Test_Sort();
}

public void Test_Sort(){
List dates = new List();

dates.Add( DateTime.Now );
dates.Add( DateTime.Now.AddDays( -30 ) );
dates.Add( DateTime.Now.AddDays( -120 ) );
dates.Add( DateTime.Now.AddDays( -5 ) );

dates.Sort( delegate( DateTime d1, DateTime d2 ){ return d1.CompareTo( d2 ); });
}
}

And finally here's the IL for this compiled assembly:

It's quite interesting to note that our "anonymous" method actually compiles as a static field in our SortMan class, with a local static method as its target! This "anonymity" appears to be nothing more than syntactical sugar to make it appear is if you don't really need a delegate instance, when in fact the compiler is creating a static delegate field variable for you, with a local static method as its target.

Anonymous methods make for clean syntax, but they are far from anonymous, and actually become a relative of the class they live inside.

Great Book

2007-02-13T13:56:00.000-05:00

In this series of Great Book posts, I'll try to provide enough information that will hopefully deem a book worthy of reading or worthy of your campfire, including three rating systems: General Rating (*-***** - 1-5 stars), Preponderance (*-***** - 1-5 stars relative to other books that should be in your collection), and Skill Level (or target for what type of skill level you should have when reading this book; this rating will be taken directly from the book if it has one).

A great book I recently picked up was Applied Micorosft .NET Framework Programming, by Jeffrey Richter. This book dives deep into the .NET Framework (v. 1.0) and succinctly covers topics such as header information written into .NET Assemblies (which really drives a point made in Effective C# about small assemblies), type fundamentals like the difference between a primitive, value and reference type and the differences between an instance and type constructor, and many more low-level .NET Framework topics. Even though this book is based on a more archaic version of the .NET Framework, much of the information is applicable to .NET Framework programming today. It's definitely a must read for novice and expert alike.

General Rating: ****
Preponderance: ****
Skill Level: Novice->Expert

Demistifying Recursion

2007-02-12T16:04:00.000-05:00

One of those "how deep does the rabbit hole go" issues you encounter along your programming journey can be recursion. At first it makes sense, then it's confusing, then it makes sense, then it ....

Moving on! I'll try to provide some of the basic things you'll need to be aware of when you think recursion is the way to go, as well as some pointers and caveats implementing recursion within the .NET Framework. We'll use C# as the language for this article.

Recursion Defined

Let's describe function recursion as simple as possible: say you have an arbitrary function (SimpleMindedAndDumbNonCoolNonRecursiveFunction(), or FunctionA()), and it has some complex calculation that it hands off to another arbitrary (this time recursive) function that performs this calculation recursively (WayCoolAndRockinRecursiveFunction(), or FunctionB()). FunctionB() performs this calculation by "recursing", or calling itself multiple times. Let's analyze a better example.

Recursion Analyzed

Say FunctionA() contains a binary tree that you would like to traverse in pre-order fashion. The only way to achieve pre-order tree traversal is to do so recursively. Let's look at the definition of our binary tree:

public class Node{
private Node left;
private Node right;
private int val;

public Node(){}

public Node( Node Left, Node Right, int Val ){
this.left = Left;
this.right = Right;
this.val = Val;
}

public Node Left{
get{
return this.left;
}
set{
this.left = value;
}
}

public Node Right{
get{
return this.right;
}
set{
this.right = value;
}
}

public int Value{
get{
return this.val;
}
set{
this.val = value;
}
}
}

And here's the code for FunctionA():

public void FunctionA(){
Node parentNode = new Node();
parentNode.Value = 1;

parentNode.Left = new Node();
parentNode.Left.Value = 2;

parentNode.Left.Left = new Node();
parentNode.Left.Left.Value = 3;

parentNode.Right = new Node();
parentNode.Right.Value = 4;
parentNode.Right.Right = new Node();
parentNode.Right.Right.Value = 5;
//you get the point ...

FunctionB( parentNode, 1 );
}

We can simply write code to traverse this binary tree that spans all levels of nodes without recursion. But that can only be done reliably (and IMHO very ugly) if all the levels of the tree are known. But what if we add more nodes? Or remove nodes? Writing code based on this assumption would be a great failure on our part. There is a better way. Enter Recursion:

private void FunctionB( Node parentNode, int counter ){
//This function walks a binary tree in pre-order fashion

Console.WriteLine( parentNode.Value );
Console.WriteLine( string.Concat( "Recursive calls so far: ", counter++ ) );

if ( parentNode.Left != null )
FunctionB( parentNode.Left, counter );
if ( parentNode.Right != null )
FunctionB( parentNode.Right, counter );
}

10 lines of elegant simplicity. Here's how this function works:

It gets called (originally by FunctionA, with a value of 0 for 'counter'), and the value of parentNode is written to the Console. Then FunctionB determines if the left and right nodes are null. If Left is not null, FunctionB calls FunctionB (itself), passing parentNode.Left as the argument. If Right is not null, FunctionB then calls FunctionB (itself) with parentNode.Right as the argument. The entire process starts all over, and the same code is excuted, as if parentNode were the first node in the tree, even though FunctionB at this point is processing parentNode.Left and parentNode.Right.

FunctionB basically does not "care" what node it is currently working on; only that it is a Node, and that the Node contains a Value, and optionally Left and Right nodes. This is happening 'recursively', because FunctionB is calling FunctionB is calling FunctionB (...) until the bottom-most node in the tree is reached, at which point the "bottom-most" call to FunctionB returns control to the previous FunctionB, all the way back up to the top.

Note: If too many recursive calls occur, an ugly 'System.StackOverflowException' will be thrown, because there will be too many function calls on the stack, so use recursion wisely.

Let's look at the output from the recursive call, perhaps this will shed some more light on what exactly is happening when the function calls are made.

1
Recursive calls so far: 1
2
Recursive calls so far: 2
3
Recursive calls so far: 3
4
Recursive calls so far: 2
5
Recursive calls so far: 3
Finished!

FunctionA calls FunctionB, with parentNode, and a value of 1 for counter (which gets printed first as the value for parentNode), then the current counter value is printed, to keep track of how many recursive calls we've made. You may notice that the amount of recursive calls follows the pattern 1->2->3->2->3. This is because 'counter', being incremented, is passed to the next call FunctionB along with parentNode.Left, then 'counter' is incremented again, and FunctionB is called with parentNode.Right. Since 'Right' is the last node on this path, control is returned, and 'counter's previous value (2) is back in place.

This is where recursion can be difficult to understand. Remember this rule of thumb: variables that have one value within a method body may have a different value at the same point in the same method body, when that variable's scope is within a recursive method. This is because when FunctionB is called again, this is a NEW method call, and when that method call is complete, the previous method call picks back up where it left off. FunctionB may as well have called FunctionC or even FunctionD.

As you can see though, the output of the current nodes value follows the pattern we set when we originally set up our tree, in FunctionA (parent=1, parentNode.Left=2, parentNode.Left.Left=3 etc.).

Another benefit of the recursive FunctionB is we can add or remove nodes on a whim, and FunctionB can handle this automatically without any code change whatsoever.

I hope this post has helped you obtain a better understanding of function recursion. Recursion is simple to implement, and can empower a developer to perform complex calculations with great ease, while maintaining a clean codebase, and minimalist class sizes.

How To Be A Great Programmer

2007-02-09T10:18:00.000-05:00

When first starting out as a programmer, it can be quite difficult to discern what steps to take to grow your skills and flourish. This difficutly is compounded when working around others who have radical, pernicious ideas of how to write software. How does one overcome this? How can you continue to grow as a developer, even while working around others who can perpetuate bad habits? How can one identify when the ideas of those around them are actually "bad"?

Well, as it turns out, there's a method to the madness. In this multipart series, I plan on covering many steps to unravel the mystery behind becoming great, especially since it's really always a work in progress, and never a desitination (did I just say that greatness can never be achieved?). But in this particular post, we'll start with some of the more basic steps I took to help my skills flourish.

How To Choose A Language

The language you finally settle on dictates what path you should follow, but your choice of languages should start with a solid, low level language. I started with C (via K&R/CC classes). Learning C first laid an excellent foundation for what has so far become a great journey in the world of writing software. There is lot's of great software originally written (and still maintained) in C. If you're gonna learn C, make sure to have the K&R book handy (it was co-authored by the creator of the C language, Dennis Ritche, who is one of the greatest contributors to computing in general). Even if you've been a programmer for a number of years, and even if you have no use for C, learn it anyway.

Note: Whatever you do in software, it all comes down to one thing: hard work. If you're unwilling to put in the hard work necessary to be good at writing software, then you will waste the time and money of many people (including yourself). The hard work never really ends, and you must be able to persevere.

This is the path I chose when I decided I wanted to write software:

Learned C: I attended a class at my local CC, read K&R, and wrote as much code as I could.
Learned C++: I mostly read C++ Primer Plus (great book on C++), and wrote more code.
Learned VB6: I again attended a class at my local CC, and wrote more code still.
Learned C#: I started learning C# around the time I was attending classes for VB6, shortly before the .NETFX 1.0 was released (pre-beta+).
Learned Java: Because of my familiarity with C based languages, I figured I would have an easy time with this, and I did. Syntactically, Java is very similar to C# (some would say C# was derived from Java), and so for me Java was like learning European English while already knowing American (U.S.) English (in other words, a rather easy transition).
Learning(ed) Python: This is a work in progress, though I have written a calculator with some minor scientific calculations.

Currently, I work mostly in C# and .NET 2.0 professionally, with most free time spent in Python. A great book, Pragmatic Programmer, says you should learn one language every year; I tend to think this is great advice.

My next step was to join and actively participate in the Open Source community. I feel this was one of the best steps I ever made. My skills grew tremendously, as I was reading code written by others (two of the best I found in C# were the Jabber library for C# - jabber-net, and the MySQL .NET Connector), and I was writing code to be viewed by others (now the world is really watching!). I also participated in as many C# and Java forums as I could register for and still get work done throughout the day.

In my next post, I plan on discussing more about learning programming languages, as well as beginning discussion on more advanced topics, like design patterns, methodologies, and so on.