Moving Up, Part 1 (or Development Environmentalism)
Disclaimer: I fully acknowledge that in electronic media like blogs, multi-part posts are pretentious and lame, but it's late and I'm sleepy -- deal with it. At least I wasn't pretentious enough to use Roman numerals instead of 1 and 2.
Interesting juxtaposition this week between programming at work and programming at home.
Several things going on at work. One is that we've been updating lots of the 3rd party components that we license for our product (mostly things like interface controls and database tools). The other big thing that's going on is that we're taking the first steps toward moving our code from .NET 1.1 to .NET 2.0, which also entails moving from Visual Studio 2003 to 2005, and from C# 1.0 to C# 2.0. Neither of these transitions is as easy as you might expect, and they've brought to mind two issues.
One thing that we've long discussed -- indeed, earnestly dreamt of -- is establishing a standard development environment. Our last shot at that consisted of just buying five identical computers from Dell, and it has served us reasonably well, but it doesn't scale up, nor is it easily expandable. Our ultimate goal is to sit someone down in front of a brand new computer and give them the ability to write code in just a few minutes, and right now Virtual PC seems like the best approach to this. Except for some technical limitations (monitor spanning, for instance), we'd probably already be doing it.
That would be a big win for us, since instead of having to install Visual Studio, several development tools, and over a dozen components, then get a copy of all the latest source code, and start trying to build it to see what we forgot, all we would have to do would be load the current standard image into a virtual machine, get the latest code, and know that it would all work. No more problems with setup. No more problems with component versions getting out of sync on different machines. No more worries that installing a seemingly-unrelated program will hose our development system. It would all "just work."
For the most part, we manage a loose approximation of that arrangement via an amalgam of source control, daily system backups, and a few other tools, but we have mostly concluded that the nirvana described above is something of an unattainable goal.
One thing I'm quickly learning from Smalltalk, though, is that not only is that ideal attainable, it has already been attained! If we were working in Smalltalk, we would just install our version of Smalltalk, load up the current image, and start working. Windows guy? You're covered. Prefer a Mac? No problem! Taking your laptop on the road? Load 'er up and off you go!
By no stretch of the imagination are we even remotely close to exchanging Visual Studio for VisualWorks (for reasons which are both varied and good), and I still feel kind of lost in Squeak, but it does force me to wonder why truly integrated development environments haven't caught on in the mainstream. It's just so...nice!
----
In Moving Up, Part 2, I'll try to articulate why C# 2.0 is no more C# 1.0 than Java is Pascal, but that will have to wait for tomorrow.
Interesting juxtaposition this week between programming at work and programming at home.
Several things going on at work. One is that we've been updating lots of the 3rd party components that we license for our product (mostly things like interface controls and database tools). The other big thing that's going on is that we're taking the first steps toward moving our code from .NET 1.1 to .NET 2.0, which also entails moving from Visual Studio 2003 to 2005, and from C# 1.0 to C# 2.0. Neither of these transitions is as easy as you might expect, and they've brought to mind two issues.
One thing that we've long discussed -- indeed, earnestly dreamt of -- is establishing a standard development environment. Our last shot at that consisted of just buying five identical computers from Dell, and it has served us reasonably well, but it doesn't scale up, nor is it easily expandable. Our ultimate goal is to sit someone down in front of a brand new computer and give them the ability to write code in just a few minutes, and right now Virtual PC seems like the best approach to this. Except for some technical limitations (monitor spanning, for instance), we'd probably already be doing it.
That would be a big win for us, since instead of having to install Visual Studio, several development tools, and over a dozen components, then get a copy of all the latest source code, and start trying to build it to see what we forgot, all we would have to do would be load the current standard image into a virtual machine, get the latest code, and know that it would all work. No more problems with setup. No more problems with component versions getting out of sync on different machines. No more worries that installing a seemingly-unrelated program will hose our development system. It would all "just work."
For the most part, we manage a loose approximation of that arrangement via an amalgam of source control, daily system backups, and a few other tools, but we have mostly concluded that the nirvana described above is something of an unattainable goal.
One thing I'm quickly learning from Smalltalk, though, is that not only is that ideal attainable, it has already been attained! If we were working in Smalltalk, we would just install our version of Smalltalk, load up the current image, and start working. Windows guy? You're covered. Prefer a Mac? No problem! Taking your laptop on the road? Load 'er up and off you go!
By no stretch of the imagination are we even remotely close to exchanging Visual Studio for VisualWorks (for reasons which are both varied and good), and I still feel kind of lost in Squeak, but it does force me to wonder why truly integrated development environments haven't caught on in the mainstream. It's just so...nice!
----
In Moving Up, Part 2, I'll try to articulate why C# 2.0 is no more C# 1.0 than Java is Pascal, but that will have to wait for tomorrow.
0 Comments:
Post a Comment
<< Home