gregoryyoung is the Page Editor for two of Experts Exchange's programming topic areas. He was recently named a Microsoft Most Valuable Professional; this article is reprinted from his blog.

A few weeks ago I attended the beta version of Dunn Consulting's BizTalk Boot Camp. I wanted to write a review on the course and to let others know about it because BizTalk is quickly gaining in popularity and is likely something you will have to deal with in the next few years.

The course was taught mainly by Mark Berry with the assistance of Mark Dunn during labs (and a few hours of lecturing). Both Marks are highly regarded as teachers and have more experience teaching than I do writing code. Mark Berry in particular not only knows the material being taught but is also quite good with "other" material that undoubtedly will come up. If you do a bit of background checking on Mark Berry you can also see that many hold him in high regard; he has also spoken on BizTalk in such events as TechEd and MS livemeetings. The fact that every student has given the Marks high marks (pun intended) should also go a long way.

As for the materials, let me just say that this is not BizTalk for bozos; expect to be challenged during the boot camp. I don't know about you but one of my major anxieties about any training course is that it will cover approximately the first four chapters of a book with an instructor who has read the first five.

On our first day we spent most of our time setting up our Virtual Machines (while discussing general concepts on another thread). I feel this was a very important area of the class as if I had had everything setup for me I would have been staring at the computer for a while at home to get everything setup. The setup for BizTalk including SharePoint and other tools is not a trivial process (especially trying to do it and make sure things are fairly secure).

On a poor note the place hosting the class must have had some issues with their machines as some were very slow (even though they were running the same VM on supposedly the same hardware) so some of the installations took a very long time. This was an issue for some throughout the class but I wager this would not be the same the next time the course was taught.

On the first and second days we also spent some time going over the general layout of BizTalk. We learned the overall architecture of both BizTalk and competing solutions. The discussion that was had going over the pros and cons of BizTalk and the comparison to other similar products on the market was worth going to the course alone if you are in any type of decision-making position.

During the middle of the week we focused on the "meat" of BizTalk, starting with setting up a basic pipeline that was "the most expensive file copy of all time" and ending with a complex set of orchestrations. This material flew by; I would wager more was covered than in a BizTalk book.

My personal favorite in this area was learning about the schema mappings. I will be the first one to admit that I am an XML idiot. Somehow I managed to make it through this section without completely killing my BizTalk installation and eventually I even got the right data to show up. Note that in this section we did not just do simple mappings but also got to the level of writing our own functoids.

What I would deem the most important item was the focus on debugging and solving problems. BizTalk often does not fail in such a way that the problem is immediately apparent if you are not very familiar with it. Loads of time is spent on how to troubleshoot the work that you do. When a student had a problem, the problem was put up onto the projector in order to have the class help with the debugging process. In fact in some cases bugs are deliberately introduced just so you can see how to fix them. For me the ability to understand what is going on and how to debug it is far more important than learning any particular feature; I don't really want to learn about features as much as I want to learn how to fix them when they break.

The last day, although I missed a bit of the morning, we went through business rules engine, performance topics, and one of my favorite discussions: versioning. When dealing with BizTalk in an enterprise level app versioning is of the utmost importance; it is not as simple as one may think and can in fact become quite complex. Some of the versioning does require forethought in order to be able to successfully versionize later. Isn't it great when you learn about these "gotchas" ahead of time as opposed to when you later need to versionize something?

Overall, the mastery labs are really what made the boot camp for me. Basically the mastery labs are done individually (with Marks walking around the room in case you have questions). The masteries were not simply reproducing what you had just learned; they often times included items that were natural extensions of what you had done. Best said, you had to understand what you just learned in order to complete the mastery assignments.

The other nice thing about the mastery labs is that they are given to you in much the same way that you would be handed an assignment at work. You are expected to work from a list of functional requirements to create a working piece of software. Obviously, in trying to do so you hit many roadblocks and things you thought you understood but really did not. These masteries help show those weaknesses and give the instructor a chance to work through them with you.

The only real negatives that I saw, including the slow computers, were items that should be expected in a beta class. I came across a few times where instructions were incorrect or where something took a bit longer than had been planned for. In my book this is what a beta class is supposed to find and the Marks did a great job of handling any of the situations that did come up -- whether taking notes to alter the instructions, rescheduling the estimated times for sections, or even staying late on their own time to discuss further items they did not expect heavy interest in.

I won't say that I left the class a BizTalk expert but I did leave with a general understanding and feel ready to join a team with a more experienced member without feeling completely lost.

Overall I give it a 4.5 out of 5 which, if you know me at all, is very high as I am usually a tough grader.

ericpete is the editor of the Experts Exchange newsletter. He considers the main benefit to doing that job to be the opportunity to write -- something he has done professionally since he was a young boy.

We're looking for someone with about $50 million or so they want to invest.

An article that appeared in the Boston Globe earlier this month detailed the plan of a Spanish company to sell a million wireless routers for $5 each. The catch: you have to share the connection with pretty much anyone who wants to use it.

FON Technology's routers are equipped with software that allows other FON members to connect to it, building, eventually, a nationwide wireless network. The business plan allows non-members to connect for $3 a day -- cheaper than the $10 a day that it costs at a Starbucks -- and half of that goes to the person whose router is being used.

We have to admit that the idea is intriguing, given the debate on Net Neutrality for the hearts, minds and dollars of US Internet users. Consider the possibilities:

For some time now, people have been using distributed computing systems for processing-intensive, albeit somewhat marginal tasks, like searching for extraterrestrial life or finding Mersenne prime numbers. Now, let's have a little fun with the idea.

Let's say we own a social networking site -- there's at least one that recently was knocked offline for 12 hours because of a heat-related power failure in California. Instead of concentrating all of our systems -- operating, data, indexing -- in one place, we build a whole bunch of "thin servers" that are pre-programmed, dedicated machines. We sell those boxes for a few dollars more than what a standard home network router (wireless or otherwise) costs.

We have some machines that do nothing but store profiles, pictures, video -- whatever the members of our site upload. We have some machines that do nothing but act as traffic cops; they keep an index of which profiles are located on whose machines, and direct requests appropriately. We might even have a few machines out there which contain portions of our database. We have some machines that serve the templates into which all of our data fits. And if we're really smart, we build in redundancy. The technology, at least in a simple form, already exists; the ads you see on most websites don't reside on that site's servers -- they are actually sent from someplace else based on a request sent by the page when it is served to the end user.

We sell the machines to Joe Smartuser and his buddies. They plug the servers in, and instead of connecting to a little Netgear wireless cable modem, they connect to the server, which connects directly to the cable or DSL line. We let him have some of the space for storage or whatever, and we can share revenues based on advertising or registrations or sales; the important thing is to provide some kind of incentive for him to use our equipment instead of someone else's. Think of it as the Internet's answer to Milo Minderbinder.

From his perspective, it isn't much different from the box he is currently using to connect. He doesn't see the activity to the thin server, except maybe at a blinking light. His browsing is seamless; he gets a different IP address than that part of the server being used for our site.

Because there's no one single set of servers responding to requests, and no one single broadband provider whose pipelines are being used, there's no way for the broadband providers to subject us to the two-tier pricing structure they would love to implement. Just as importantly, while something like an equipment failure or power outage might shut down a segment of our system, because we have redundancy, and because we're spread out all over the place, our site doesn't go offline completely.

All we do is constantly monitor to make sure that each box is working, and if it isn't, we get on the horn to find out why. Joe Smartuser will love it; instead of having to drive down to the local computer store to buy a new modem, we're FedExing him one right now.

We'll take a check.

Gene Roddenberry, the man who created Star Trek, once said "They say that ninety per cent of TV is junk. But, ninety per cent of everything is junk." Apparently, it's closer to 95 per cent of email. So maybe what we should be doing isn't filtering out the junk -- we should be filtering out the useful stuff. And do you know what the fastest growing part of it is? It isn't the prescriptions, and it isn't the African generals. It's what the government calls "Hype and Dump" schemes.

A Hype and Dump (also called a Pump and Dump) is when someone pushes a penny stock -- a stock that costs only a few cents to buy -- so that the price goes up, and then they dump it. Sometimes it doesn't take much to make quite a bit of money; since the amount per share isn't very high, a lot of shares can change hands fairly quickly.

Not all of the stocks you see in those emails are bogus -- most of them aren't. But what is phony is the assertion that by buying it now "before the price goes up" is worth doing, because if it were, the price would go up anyway. What the scam artists -- who use those lists of "8 million valid email address for $149" -- are counting on is that a bunch of people will be willing to part with $1,000 to make money quickly. That "creates" demand for the stock, and the price goes up... and the people who put their $1,000 up get to watch the price fall back down to what it was in the first place.

Of course, it's not always the small investor that pays too much for something. And it's not always the little guy that gives someone a boost. The day a Microsoft-Nortel alliance was announced, Nortel was selling for $1.94 a share.

Finally, I came across this a couple of weeks ago: a list of the 10 biggest security risks that most people don't know about. But don't worry -- there will be more coming along.