As a follow-up to my post from last night, I thought it fair to mention that one of the responses to Jeff Atwood that I read via Hacker News led me to some incredible free and/or cheap online resources for aspiring programmers.

The author of the rebuttal, Zed Shaw, has produced several books on Python, Ruby, C and even general use of a command line interface (CLI) such as Unix/Linux bash and Windows PowerShell. I've already dived in myself and have decided to improve my skills with the CLI first and then move on to either Python or Ruby...or maybe C???

Maybe all three??? Yikes. I might be a real hakz0r after that.

All of the learning resources can be found at Zed's site at: learncodethehardway.org. Thanks for all the hard work, Zed.

Jeff Atwood of CodingHorror.com, true-to-form, set of yet another proverbial dev flame-war, by taking a stand against the recent notion that everyone should "learn to code."

Hacker News was filled to the brim today with dev blogger responses about how they agreed or disagreed with Jeff. I read a lot of the responses. The subject has been so thoroughly beaten to death that I can't imagine a sound rationale for why I should add my two cents worth.

Yet, I'm going to do it anyway...but I promise to be brief.

If you think it would be a fun or intellectually stimulating exercise to learn to program, then I think that's awesome. By all means do it. But if you think you are going to go buy a book on Javascript or Objective C and that that will put you on the road to becoming the next Mark Zuckerberg within a couple of years, you are not being realistic. As Jeff pointed out, research has shown that it takes 10,000 hours to become an expert in any field. I have certainly not reached that benchmark yet...but I'm getting there one line of code at a time.

I think Jeff's main message got lost in his somewhat condescending tone. For me the message is this: if you want to learn to code, then go get yourself a real world project and solve a real world problem. Doing anything else is just an intellectual exercise. There's nothing wrong with engaging in an intellectual exercise just for the sake of it. Whether building your understanding of plumbing or coding or French Impressionism, intellectual pursuits give you experience that you can apply to seemingly unrelated parts of your life.

Learning about programming is bound to improve your understanding of the evolving high-tech world around you and that it is a good thing. But let's call it what it is...

Coding as an intellectual exercise is less "Learning to Code" and more about "Coding to Learn." Semantics? Maybe. But that's how I see it.

Over the past several months I have learned the joys of Git, the distributed source code management program. I have used SVN in the past and liked it, but...I don't know exactly why...I find Git to be so much more flexible. Every day I learn something new that makes my coding life easier and more productive.

I'm now using Git on my current work contract (an ASP.Net web forms application) and have moved all of my past customers' projects to Git as well. I've even set up my own Debian Linux server as the ultimate repository for all of my Git projects. I used the "Gitosis" project to do this if you are interested.

I've even joined GitHub and started a few public repos to share with the world. There's not much to see there yet, but I have big hopes to develop some cool things to "push" there in the near future.

In my last post I wrote about my odyssey of migrating from VirtueMart 1 to VirtueMart 2.  The journey has not been an easy one, but  I made great progress and learned a lot about VirtueMart, Joomla! and even PHP in the process. But in the end, none of that stuff was enough to justify the time I have invested. The bottom line is this: I give up.

I love technology. In particular, I love developing, configuring and deploying software. When I start with something IT related, I can't stand to give up until I figure out the shit that needs to be figured out. But it's time to face reality: VirtueMart 2 is just not yet ready for prime time and I am wasting my time.

I know the developers have good intentions. For years they have produced a free, open source product and asked for little in return. But now they are trying to move to a different business model where they actually hope to make money. For eample, the UPS shipping module was included in the core VirtueMart product for free. In VirtueMart 2, you have to buy the UPS shipping module for about $65 or else roll your own.  I don't blame them. I like to be paid for my development efforts too.

However, in their haste to monetize it feels like they have "thrown the baby out with the bath water." When I look at posts for help in the VirtueMart forums and the pace at which the developers are pushing out bug fixes I have to conclude that VM 2 is not even beta software yet. It's an alpha product at best. Others may disagree, but that's what my experience tells me. Again, I empathize with the developers and I appreciate their efforts, but good intentions aren't enough for me and my customer.

The whole reason I was even attempting this migration was because some of my customer's shoppers were experiencing seemingly random problems with the checkout progress. When the customers got to the shipping method selection step, they were unable to get a shipping quote and proceed to the final step.  To make a long story short, since I had been unable to troubleshoot this problem or even reproduce it myself, I ultimately assumed this was a bug in VirtueMart 1, or the UPS shipping module. Since the developers were nearing end of life for support of VM 1, I decided that migrating to VM 2 was my best hope to resolve the checkout issue. But in the middle of my migration I discovered that the whole problem was caused by a cultural anomaly in the US. When filling out shipping addresses in the US, the average user expects the field order to be: City, State, Zip. VM's shipping address order is City, Zip/Postal Code, State/Province. I discovered that when I put in my own test order (one of many previous test orders) that I had entered my home state of NC in the Zip Code field in my haste to enter the address. When I tried to check out, I got the error mentioned earlier. 

After much cursing that I had been toiling with an unnecessary shopping cart migration, I have resolved that I am going to keep both Joomla and VM on the current version and start looking for another long term solution for my customer's shopping cart.  I have looked at a few ASP.Net solutions, but I have a feeling that in the end, that I will roll my own.  Third party solutions can be real time savers, but if I can come up with a home-grown solution that exactly meets my customer's needs, I think we will all be better off in the long run.

So VirtueMart...it's been real. Happy trails!

As I mentioned in my last post, I have been working for weeks, on and off, to migrate a client site from Joomla 1.5.X to 2.5. At the same time I have to perform an additional migration of the integrated shopping cart VirtueMart from version 1.X to 2.X.

After multiple attempts, with varying degrees of success in each attempt, I have reached some conclusions on the approach that I think is best to ensure a successful migration of all parts of my site. The first conclusion is that I need to tackle the VirtueMart (VM) migration first. This conclusion is based largely on the fact that I am going to have to use a brand new Joomla template for version 2.5. My current Joomla 1.5 template can be modified to work with 2.5, but my analysis tells me that I am better off just buying a new template that is designed specifically for Joomla 2.5. The amount of work required to modify the old template does not seem like a good use of my time. So, as far as VM is concerned, I've decided to do that migration first. That way, once my VM Shop data is converted to VM 2, I can immediately judge if my shop data looks correct without having to worry too much about layout issues. That's not to say that there aren't layout issues to address with VM2, but the issues aren't as drastic as the re would be if I combine the layout customization I will need to eventually do for Joomla itself. In short, I am breaking my overall migration into manageable chunks.

But first a few things about both my production and development environments that may or not apply to your situation.

• I'm a Microsoft web app developer for the most part, so both my production and development sites are running on IIS 7.5. I realize that my life would be much easier with regard to Joomla if I deployed on Linux and Apache, or XAMP on Windows, but IIS is the server that I have chosen for various reasons that I don't care to debate.
• I am, however, running PHP (of course) version 5.3.X and MySQL on both prod and dev. I don't recall the specific version of MySQL I am running, but it's fairly recent in my dev environment, because I installed via the MS Platform Installer a couple of months ago. The WPI is actually a great product and has made life much easier for developing with PHP and other open source technologies on Windows. If you develop on Windows, you should check it out if have not already done so.
• Even though I installed PHP via WPI with the recommended configuration, I have found there are a few additional tweaks that are worth considering. Read this article on optimizing PHP on IIS if you are using IIS in your environment.
• There are also some file permissions on Windows that you need to address before you start trying to do Joomla extension installation through the UI. If you don't address them before you get started with the migration, Joomla will likely barf all over you at some point. A helpful article for setting the right permissions can be found here.

With all the above in mind, let's get to the VM migration steps that worked well for me in my latest attempt.

1. Rename the following folders, so that the installer has a clean slate to work with:
Uninstall all old VirtueMart extensions (components and modules)
• [siteroot]/administrator/components/com_virtuemart
• [siteroot]/components/com_virtuemart
2. Move shop images from folders "category", "product", "manufacturer" and "vendor" (if they exist) within the main VM component (folder from 2nd bullet above) /shopimages folder, to [siteroot]/images/stories/virtuemart (you have to create the destination virtuemart sub-folder yourself).
3. Disable Joomla Debug option in Joomla Global Configuration, if enabled.
4. Uninstall all old VirtueMart extensions (components and modules). You could just disable or unpublish the extensions, but I found that this confused me once I got the new version of VM installed. I found it hard to tell which version of the modules were new and which were old.
5. Download latest VM (2.0.6 on date of my migration) and extract files from zip file to separate folder.
6. In Joomla Extension Manager, upload and install file com_virtuemart.2.0.6.tar.gz.
7. Repeat above step for file com_virtuemart.2.0.6_ext_aio.tar.gz.
8. Upon successful installation, go to the VirtueMart administrative area and choose the VirtueMart "Configuration" section under the "Shop" accordion control on the left side of the admin menu. Check the box for "Enable database Update tools".
9. Go to Tools accordion, then click Tools & Migration, then "Migration" Tab. Choose "Everything" and click "Start Migration".
10. Pray to your God/Higher Power or maybe call your Mom.
11. After the migration, before doing anything else, make sure that your default Joomla administrative user is identified as a vendor (no other shop configuration will be possible until you do this) as detailed here.
12. Go to the Shop accordion and click on "Shop". Some of your shop info from the old VM version will be filled in, but you must choose your default currency and fill in all required fields on the "Additional Information" tab. "Additional Information" is relative to the admin account you set as the "Vendor" in the previous step. Once you have done all of this, click save.

If all went well and you performed all of the steps above, you should now be able to browse your live site and VirtueMart shop. I went back and deleted those backup copies of the old VM component folders from before the migration. There's no sense in cluttering up our fresh new site.

If you're like me, you have a few hours ahead of you in making your product and category pages look right in the new VM template. But before I do that, I'm going to go ahead and bite the bullet and do the migration to Joomla 2.5, because there is every chance that I will just end up having to do the template changes all over again. I don't want to do that.

I will write about the recipe I followed for the Joomla migration in my next post…assuming I make it through the process with my wits intact.

Update: Okay, I give up...

I'm in the middle of migrating a Joomla site from version 1.5 to 2.5 and I have to say it has been a bit of a nightmare. It probably wouldn't be so bad but the site also utilizes the VirtueMart shopping cart component for my client's e-commerce business. This component also has To be migrated from version 1.7 to 2.0. Both migrations are what I would call a "forklift" upgrade.

There are some migration tools available, but I would estimate they make a mess of things about 20% of the time. When you are dealing with a database migration, a 20% failure rate obviously just won't cut it.

In spite of all this, I have learned a great deal about what to do and what not to do. Eventually, I will figure it all out and when I do, I will post my recommended approach here so that others can benefit from my experience.

For now, it's back to the drawing board.

It looks like Joomla 2.5 has hit the virtual shelves and there is a piece of great news if you are a Microsoft dev like me. It looks like 2.5 will run on SQL Server backends in addition to MySQL.

I'm guessing that a transition to SQL Server is not going to be all that easy, but it's nice to finally have the option.  It will sure make database backups a lot easier for me once I make the switch though. I've already got my other SQL Server DB backup jobs locked and loaded. Not being as familiar with MySQL tools, I don't have the process very automated, so it's largely a manual kind of deal for now.

The bad news for me is that I am going to have to migrate from Joomla! 1.5.X to 1.6, and then from 1.6 to 1.7 before I can even think about 2.5. There is no direct upgrade path to 2.5 from 1.5.X!

Grrrrrrrrrrrr!

Update 4/11/2012: It turns out that there are now migration tools to move directly from Joomla! 1.5 to 2.5. However, I have had very mixed results in using these tools. In addition, once you have the database migrated, you still have to rework your site template to work with the new framework. That has been a major pain in the ass.

If you think I'm going to introduce moving to a completely new DB system on top of all the other hassles, you are smoking something. I have no love for MySQL, but I'm not a masochist. I've got enough to worry about.

I'm an ASP.Net and SQL Server developer, not a DBA. Sure, I can write very complex select statements, stored procs and even SSIS packages that do lots of really cool stuff.   However, when it comes to the wheres and whys of database administration (tasks like creating and managing indexes), I'm a little out of my element...

...okay, a lot out of my element.

Today, I was looking at the schema for a table used in my current web app project; call it table "Clubs." Now, table Clubs only has about 400 records in it, but it does contain three "Officer" columns that reference a much larger table (table "Members" with 300,000+ records and counting). Since I inherited this database from multiple other solo contract developers spanning 10 years or so with little to no design consistency over that term, I was not surprised to see that the three Officer columns in table Clubs did not have foreign key relationships established with table Members.  Well, fixing that oversight is a no-brainer even for me.

After I created the foreign keys, I further noticed that indexes were not created for the foreign keys automatically. I just assumed that since you generally want an index for a foreign key to aid in query performance, that the indexes would be created automatically. Nope. Not with SQL Server, anyway.

So after a quick Google, and a brief stop at Stack Overflow (a useful post in and of itself), I was pointed towards this article on SQL Server Index practices by Diane McNurlan. Not only did it set me straight on the foreign key index issue mentioned above, but I gleaned several other interesting things to keep in mind when I find myself in the surrogate DBA role (a pretty common situation when a developer finds himself or herself working in small companies).

I won't go into all the gory details (a lot of it is, quite frankly, still over my head: Non-Sargable Where Clauses, WTF?!!). It's a short article. Check it out for yourself.

Thanks, Diane!

My current client has been gracious enough to provide me with a nice 20", 1280x1024 monitor for my day-to-day use in my luxury office cubicle.

Yesterday, I happened to notice that the monitor can rotate 90 degrees for use in a "portrait" orientation. So on a whim a flipped the monitor and changed my display settings in Windows to match (1024x1280) and...

Holy Crap!

An unexpected productivity boost..

This is really helpful in writing jQuery and HTML markup because I can split the screen in half in Visual Studio  and view jQuery at the top and HTML at the bottom. Then I still have a great deal of screen real estate allocated for each pane.

FTW!