I will be presenting a free webinar on Tuesday, March 16 at 11 a.m. Pacific time. This presentation will consider 5 common Web usability problems and how to avoid them. You’ll learn ASP.NET techniques to improve input validation, avoid confirmation alerts, simplify complex forms, and more!
To register, visit http://my.dimdim.com/philweber/. Thanks!
I closed the polls on my contest at midnight (Pacific Time; apologies to my readers in Hawaii who thought they had three more hours to enter) on February 1. Next, I went through the 100+ entries and disqualified those that were over 100 words or lacked originality. I forwarded the remaining 26 to my boss, who volunteered to help me judge (she’s a sucker for a good contest: she also loves American Idol). She narrowed it down to eight, and from there I agonized over three. The winner of the free copy of Visual Studio 2005 Team Suite with MSDN Premium Subscription is...
John Dukovich of Green Moon Solutions!
It was a difficult decision. I like that John works for non-profit and socially-responsible organizations, and his company may actually be able to take advantage of Team System’s features.
Congratulations to John, and thanks to everyone who entered. Just a reminder that if you’re a teacher or student, you may qualify for free or dramatically discounted Microsoft developer tools through the MSDN Academic Alliance program, and if you run a software company, you can join the Empower for ISVs program.
Several co-workers and I have volunteered to present lunch-hour sessions for Advanced Placement computer science students at a local high school. Mine is on January 30 and I need to choose a topic. Games and gadgets would probably go over well; maybe something about how chicks dig geeks? :-)
Seriously, if you have any ideas, please share them!
It’s been three days since I announced my Visual Studio Team Suite / MSDN Premium giveaway. Since then, I’ve noticed that several other MVPs are planning similar giveaways. Come back often (or subscribe); I’ll alert you to any additional contests I discover.
I’ve received 67 comments so far and I have to say, I’m a little disappointed. The majority of comments say, essentially, “I really want it but I can’t afford it.” Come on, people! This isn’t a raffle; you need to give us a reason to choose you over someone else. A few have resorted to threats (“Choose me or else I’ll use Java/Linux”), promises (“Choose me and I promise to learn how to use it”), or pity (“Choose me or my children will starve.”) I was hoping to hear, “I work for this charity/non-profit” (I did get a couple of those) and/or, “I could really use these specific features of VSTS...”
There have been a few standouts: Aidan is working on an innovative Web project that deserves some attention. And I enjoyed Adam Wright’s poem. No promises, guys, but you made a favorable impression.
FYI, if you want the software because you’re a starving student or running a startup, Microsoft offers significant discounts to both academic institutions and software companies. If you don’t score a free copy from an MVP, you should check those out.
Update: Patrick Santry, owner of WWWCoder.com, is giving away several VSTS/MSDN licenses.
Update 2: XML guru Oleg Tkachenko has licenses to give away and is looking for ideas.
Microsoft has generously given me (and, presumably, other MVPs) a few licenses to Visual Studio 2005 Team Suite with MSDN Premium Subscription “to share with other individuals of [my] choosing in the community.” Now, I’m under no delusion that this is sheer altruism on Microsoft’s part; I’m sure they want to drive adoption of VSTS (and I want more readers!) Regardless of the motives involved, however, I have cool software to give away, and that’s where you come in.
In the comments to this post, tell me in 100 words or less why you should receive one of these licenses. I’ll keep the comments open until January 31, at which time a panel of judges (to be determined) will select a winner.
So, make us laugh, make us cry, give us goosebumps. Convince us that you deserve a free copy of this $10,000 software package (and in case you don’t win, start sucking up to other developer MVPs you know!)
The Classic VB petitioners have posted a FAQ page explaining their goals and the motivations behind them. (Hint: Contrary to what you may have read elsewhere, the impending end of mainstream support for VB6 is not the primary issue!) On the lower portion of that page is a section titled, “Myth Busting” which includes a myth of its own:
To take a trivial example, there is no defensible reason why a QuickSort algorithm should need to be rewritten because you have a new compiler for a language targeting a new platform.
Is it true that a VB6 QuickSort algorithm must be rewritten in order to recompile it for .NET? Let’s see…
Here’s a VB6 QuickSort implementation I found on the Web:
Public Sub Quicksort(ByRef list() As Integer, ByVal min As Long, _
ByVal max As Long)
Dim med_value As Long
Dim hi As Long
Dim lo As Long
Dim I As Long
' If min >= max, the list contains 0 or 1 items so it is sorted
If min >= max Then Exit Sub
' Pick the dividing value
I = Int((max - min + 1) * Rnd() + min)
med_value = list(I)
' Swap it to the front
list(I) = list(min)
lo = min
hi = max
Do
' Look down from hi for a value < med_value
do while list(hi) >= med_value
hi = hi - 1
If hi <="" lo then exit do
loop
if hi <="" lo then
list(lo) ="" med_value
exit do
end if
' swap the lo and hi values
list(lo) ="" list(hi)
' look up from lo for a value >= med_value
lo = lo + 1
Do While list(lo) < med_value
lo ="" lo + 1
if lo >= hi Then Exit Do
Loop
If lo >= hi Then
lo = hi
list(hi) = med_value
Exit Do
End If
' Swap the lo and hi values
list(hi) = list(lo)
Loop
' Sort the two sublists
Call Quicksort(list, min, lo - 1)
Call Quicksort(list, lo + 1, max)
End Sub
And here’s the same implementation in VB.NET:
Public Sub Quicksort(ByRef list() As Integer, ByVal min As Long, _
ByVal max As Long)
Dim med_value As Long
Dim hi As Long
Dim lo As Long
Dim i As Long
' If min >= max, the list contains 0 or 1 items so it is sorted
If min >= max Then Exit Sub
' Pick the dividing value
i = Int((max - min + 1) * Rnd() + min)
med_value = list(i)
' Swap it to the front
list(i) = list(min)
lo = min
hi = max
Do
' Look down from hi for a value < med_value
do while list(hi) >= med_value
hi = hi - 1
If hi <="" lo then exit do
loop
if hi <="" lo then
list(lo) ="" med_value
exit do
end if
' swap the lo and hi values
list(lo) ="" list(hi)
' look up from lo for a value >= med_value
lo = lo + 1
Do While list(lo) < med_value
lo ="" lo + 1
if lo >= hi Then Exit Do
Loop
If lo >= hi Then
lo = hi
list(hi) = med_value
Exit Do
End If
' Swap the lo and hi values
list(hi) = list(lo)
Loop
' Sort the two sublists
Call Quicksort(list, min, lo - 1)
Call Quicksort(list, lo + 1, max)
End Sub
Can you spot the difference? (If you intend to point out that Integers and Longs are different sizes in VB6 and VB.NET, please include an example demonstrating how that difference affects the algorithm’s behavior.)
Here’s another:
Why not leave functioning code in VB6, and write new code in VB.NET?
That's a fine solution for the problems it fits. Many developers can indeed let existing applications linger in VB6 forever (assuming future OS changes don't break them), and concentrate all their efforts on developing new VB.NET-based applications. For the great majority of VB developers, however, there is continuing need to revisit and revise legacy applications. While Microsoft may no longer want to support VB6, great numbers of VB6 developers still intend to support their customers with ongoing bug fixes and application enhancements.
Ahem. What prevents VB6 developers from supporting their customers with bug fixes and application enhancements in VB6? Nothing. That’s exactly how my employer is supporting its customers’ VB6 code.
Much has been written over the past week regarding a petition asking Microsoft to continue development of “Classic VB.” I have chosen not to sign the petition; here’s why:
First of all, let me emphasize that I am not unsympathetic to the difficult choices faced by those with a large investment in pre-.NET VB code. Some people have built entire companies around products written in VB; the future of that code is quite literally the future of their livelihood. Microsoft has put them in the unenviable position of having to choose whether to leave their code in VB6 and hope that it remains viable, or to rewrite it some other language, which will cost time and money.
If I had been in charge when VB.NET was being designed several years ago, I would certainly have kept those developers in mind, and not broken compatibility with VB6 unless it were absolutely necessary. But wait: Microsoft is full of brilliant people; don’t you think the VB team thought of this? It’s the height of arrogance to believe that we’re aware of considerations that have never occurred to them.
VB.NET is a product of conflicting goals: On one hand, the VB team sought to maintain backward compatibility with VB6. On the other hand, they needed to make VB.NET a first-class .NET citizen, or risk further accusations that it’s a “toy language.” On a third hand, they needed to ship .NET and its key languages as quickly as possible in order to compete with Java and other tools that were nipping at Microsoft’s heels. While there were undoubtedly features the VB.NET team would like to have delivered in version 1.0 (such as edit-and-continue and closer compatibility with VB6), the tight schedule simply didn’t allow it.
How should Microsoft have handled cases in which “the .NET way” and “the VB6 way” were at odds (such as the size of the default integer data type)? The “correct” answer depends upon your point of view; the VB team was damned either way. I’m sure there were many spirited discussions on issues like this one. We may not agree with the final decision, but that doesn’t mean Microsoft didn’t seriously weigh both sides of the issue.
This is one problem I have with the Classic VB petitioners: They focus solely on the goal of VB6 compatibility, while ignoring the perhaps equally important goal of parity with other .NET languages. Any proposal which Microsoft is to take seriously must consider VB’s future, as well as its past.
Another issue: Microsoft doesn’t create development tools out of the goodness of its heart. The business case for tools like Visual Basic and Visual Studio is to drive adoption of Microsoft’s platform du jour. (Remember Steve Ballmer’s “developers, developers, developers” chant?) In the last decade, that platform was Win32, and versions 4 through 6 of VB helped a lot of people create a lot of software for that platform.
Today, the target platform is .NET. Company representatives have stated that Microsoft has “bet the company” on it. But here’s the problem: Some of the Classic VB petitioners — in fact, many of the driving forces behind the petition — have made no secret of the fact that they have little interest in learning or using .NET. They would have Microsoft keep cranking out new versions of COM-based VB for as long as it’s willing to do so. What’s the incentive for Microsoft to spend millions of its dollars and years of its developers’ time, if it won’t help drive adoption of its current platform?
Now, if the petition had said, ‘We want Microsoft to help us migrate our VB6 applications to .NET as easily as we were able to move our code from, say, VB3 to VB4,’ I would have signed in a heartbeat. Classic VB developers could preserve their code assets, and Microsoft would get potentially millions of additional developers creating .NET applications. Everybody wins.
Of course, nothing prevents the Classic VB petitioners from working on their own compiler/conversion tool/compatibility library to ease migration of VB6 code to .NET. This would be an ideal project for the 2,000+ signers of the petition, and I have repeatedly suggested and offered to contribute to such a project. I have also pointed out that the source code for two “nearly-VB” .NET compilers is readily available. If you’re interested in contributing to such a project, please post a comment below.
I'll be speaking on the above subject at a meeting of the .NET Developers Association in Redmond, WA next Monday, July 12. Here's the blurb:
Even the most beautifully coded application will flop if people hate to use it. And they will, if its user interface is not designed with their goals in mind. What makes a great UI? How can you apply the principles that work so well for the guts of an application to its front end? I'll show you specific techniques (with code!) that you can use immediately to reduce complexity for your users and improve your presentation layer's efficiency and maintainability.
More details here. Next Monday is also my first day at a new job, so it'll be a busy day: work until 3 p.m., drive to Redmond, give my talk, drive home, and go to work Tuesday. Yikes!
I first learned of the release of Visual Studio 2005 Beta 1, as well as Express Editions and the MSDN Feedback Center, shortly after midnight this morning. Since then, I've seen it reported by dozens of bloggers, and the day is young. ('We blog more by 8 a.m. than most people do all day.') If you're a .NET blogger and you haven't yet written about today's new releases, please don't!
What is the thought process that leads one to blog about an event of this magnitude? 'If I don't blog this, nobody will hear about it!' Or perhaps, 'Ooh, if I hurry and blog this, I'll be the first, and I'll get lots of links and notoriety!' Please.
Before you post (not just today, every day), I urge you to peruse the home page at weblogs.asp.net or do a search at Technorati. If you don't have anything to say that hasn't already been said several times, do us all a favor and step away from the keyboard. Thank you.
Julia Lerman laments the VB.NET stigma and C# elitism being perpetuated by the trade press. In particular, she refers to this editorial in asp.netPRO magazine. I found that editorial troubling as well. In it, Elden Nelson writes:
Whether it's just or not, C# developers make more money, get work more easily, and enjoy more prestige than VB developers.
He then recommends that VB.NET developers learn C# at their earliest opportunity, presumably to cash in on the cachet.
Now, I don't disagree that it's a good idea for VB developers to learn C#. But I do object to asp.netPRO's tacit endorsement of language bigotry. What if the editorial had said:
Whether it's just or not, white developers make more money, get work more easily, and enjoy more prestige than minority developers
(Or, as one of the commenters on Julia's blog suggests, "...male developers make more money, etc. than female developers")? If the situation is 'not just,' as Nelson implies, why isn't he working to change it?
Unhappy with the state of VB.NET? Here are two things you can do about it:
Here's another cool tip from Andy Smith: Don't like all those tool windows cluttering up your VS.NET workspace? Shift+Alt+Enter, baby!
My long-time colleague Keith Pleas (remind me to tell you about the trip we took together to South Africa...) has started blogging, and he's off to a good start: I particularly enjoyed this post, defending lowly VB programmers against the condescending attitude of certain self-important semi-colon jockies. ;-)
Go, Keith!
In the vb.dotnet.discussion group at DevX, .NOT-regular Mike Mitchell rants that VB.NET is too complex to be considered "BASIC." Not surprisingly, I disagree:
Just this past week,...my employer wanted a simple app for importing data from flat files into a relational database. I decided that a "Wizard" UI made the most sense (Step 1: Select data source; Step 2: Select destination; Step 3: Perform import).
Now, I've created plenty of wizard-type apps in VB3 through 6: In 1996, I wrote a VBPJ article about how to create efficient, maintainable multi-page UIs, and I gave VBITS presentations in 2000 and 2001 which featured an updated technique for VB6 based on UserControls.
Guess what? VB.NET was much less complex, but just as efficient, as the techniques (read: hacks) I had devised for VB3-6. I wrote the entire app in less than one day.
How do you explain that, Mike? If VB.NET is so inherently complex, how could I have developed a polished VB.NET UI in a fraction of the time it took me to create the same UI in VB6?
The technique I used for this app, incidentally, is visual inheritance: I created a generic wizard form to serve as a base class, then I inherited from this form to create each page of the wizard. Cake!
J2EE vs .NET: In a piece for Java Pro Magazine, Budi Kurniawan compares and contrasts J2EE with .NET, and concludes that J2EE had better watch its back. I'm curious whether other Java programmers feel it's a fair comparison?
Manipulating data is a primary capability of any dynamic Web app. Unlike rich clients, providing a user-friendly interface to do so can be painful. Users want dropdowns, checkboxes, radio buttons... and ASP.NET has made it easy!
See how using the TemplateColumn provides a richer UI when working with the ASP.NET DataGrid control.
[Ironically, Chris' article on the virtues of ASP.NET appears on a JSP page! :-) -- PW]
Source: Chris Goldfarb's Radio Weblog
I've been meaning for some time to post an overview of ASP.NET page-template techniques; Adrian Bateman has saved me the trouble:
Page template techniques with ASP.NET:
Mike Borromeo describes another clever technique in this article: He uses a UserControl for the page template, and exposes an ITemplate property (the same interface ASP.NET uses for templated items in the DataGrid and DataList controls) for the page-specific content. This is the approach I've used in my content management system.
Update: Paul Wilson has a fairly comprehensive list of page template resources here.
Interesting feedback to my post on Microsoft's preferential treatment of C++ developers: Over at DevX, the post spawned a thread containing several dozen messages. Larry Serflaten believes that it's easier for C++ to maintain long-term compatibility, because it's closer to the hardware and doesn't depend upon ever-changing abstraction layers. VB's problem, he says, is that MS pulled the COM rug out from under it, and created a new, incompatible abstraction layer (the .NET Framework). Since C# (which has been submitted to various standards bodies and which MS allegedly uses internally) depends upon the same framework, Larry believes VB.NET will remain more stable going forward than "Classic" VB has.
Well, Larry, I hope you're right, but changing the underlying framework should not have required major changes to VB's syntax. That's the very purpose of an abstraction layer: to isolate higher-level elements (such as syntax) from lower-level ones (such as hardware and the OS). As I stated in my reply to Sam Gentile, MS BASIC has remained relatively stable as it has progressed from CP/M to MS-DOS to 16-bit Windows to 32-bit COM. Changing the platform does not require wholesale syntax changes.
Meanwhile, over at Fawcette.com, Dennis suggests that VB had to change in order to become more object-oriented. That makes sense, but MS could have added OO features while keeping legacy syntax (e.g., GoSub, file I/O statements, etc. -- clearly marked as "deprecated") for compatibility purposes, just as it did with the String object vs. InStr, Left, Mid, etc.
Finally, Bill McCarthy suggests that the .NET situation for C++ developers is not as rosy as Sam Gentile suggests. Is this true? As long as C++ programmers have to suffer as much as VB devs do, I guess I have nothing to complain about. ;-)
I think the best solution for moving VB6 code to .NET would be to create a VB6.NET compiler: a tool that reads VB6 source code and emits MSIL. Would anyone be interested in participating in an open source project to create such a beast? Failing that, my second choice would be an improved Upgrade Wizard (along with several additions to the Microsoft.VisualBasic.Compatibility namespace) that generates cleaner VB.NET code and knows how to convert GoSubs into standalone procedures.
More ASP.NET goodness: Another library of cool [and free!] ASP.NET controls: http://www.metabuilders.com
Source: Sean 'Early' Campbell & Scott 'Adopter' Swigart's Radio Weblog
Sam Gentile suggests that Microsoft could not make VB.NET source-compatible with VB6 due to the latter's COM underpinnings. A nice theory, Sam, but I'm not buying it: MS had little trouble maintaining source compatibility when it re-plumbed VB4 to use COM; I don't see why it couldn't have done the same when it replaced COM with .NET. Certainly a few changes (such as ref counting vs. GC) were unavoidable, but many (most?) of the items on Karl's list could have been avoided.
I understand that MS had to make difficult decisions in the face of tight deadlines and limited resources; it had to get VB.NET out the door as quickly as possible. But now that it's shipped, why not improve VB.NET's compatibility with VB6, even if only by means of a deprecated compatibility namespace? This would undoubtedly spur increased adoption of .NET, and underscore Microsoft's commitment to VB as a serious development tool.
Karl Peterson says that my characterization of his list of Visual Fred incompatibilities is "uncalled for", and invites me to "enlighten us" if I am "aware of actual inaccuracies." OK, Karl, here are a few:
60. The MsgBox function is not supported.
Wrong. Both the statement and function forms of MsgBox(Prompt, [Buttons], [Title]) are supported in VB.NET.
49. LSet is not supported.
50. RSet is not supported.
Misleading. While the syntax has, admittedly, changed, LSet and RSet are both supported in VB.NET:
Dim sBuffer As String
sBuffer = LSet("Hello", 30)
sBuffer = RSet("Hello", 30)
52. UDTs are not by default contiguous blocks of memory, but are objects.
Misleading. If you remove the weasel words "by default," it's simply incorrect. See http://discuss.develop.com/archives/wa.exe?A2=ind0201D&L=DOTNET&P=R58908.
61. The DoEvents function is not supported.
Misleading. While technically correct that the DoEvents function (which returns the number of open forms in VB6 and earlier) is no longer supported, the DoEvents statement, which processes all Windows messages in the message queue, is alive and well in VB.NET.
114. Debug.Assert is not supported.
Wrong. Debug.Assert is supported in VB.NET.
There may be others; those were just the ones that immediately jumped out at me. I hope those examples are sufficient to support my characterization of "several items at this link [as] misleading or inaccurate."
Enumerating the advantages of .NET's Managed Extensions for C++ (MC++), Sam Gentile writes:
Though not a member of the "VB.NOT" 1 contingent, I am dismayed by the above list: Why should C++ developers enjoy such ease of migration to .NET, while VB developers (of whom there are arguably many more) are forced to rewrite their code? I disagree with the opinion that VB is a "dead language" -- there are plenty of apps with limited life spans (say, up to 10 years) for which VB has been and continues to be ideal -- but it would have been nice if Microsoft had demonstrated its commitment to VB by making it as effortless to migrate "Classic" VB code to .NET as it did to migrate C++ code. The message seems clear: If your application is "mission-critical" 2, don't use VB.
1. For the record, several items at this link are misleading or inaccurate.
2. I don't consider most of my apps to merit that description -- I think many developers flatter themselves by believing that their code must live forever -- but there are clearly apps that do. For these, VB would seem to be a questionable choice.
Here's a cool ASP.NET tip from Sean 'Early' Campbell & Scott 'Adopter' Swigart (actually from their associate, Richard Hundhausen):
If you've got a password textbox name txtPassword, you cannot assign the Text property to it in code, or via DataBinding. This is by design. Here's a workaround, however:
txtPassword.Attributes.Add("value", "abc")
Now keep in mind, just because you can do this, doesn't mean you should. This is "by design" for a reason.
This is very cool: Assign attributes (e.g., NotEmpty, MaxLength) to Class fields, then validate them with a single method call. Wish I'd thought of it!
My ASP.NET app suddenly began to "forget" information I was saving in the Session object. Turns out my personal firewall was set to block cookies by default; ASP.NET uses a cookie to track the session ID. Changing the firewall setting fixed the "bug."
I've received some good feedback from my article, "Is Inheritance Overrated?" The real issue, it seems, isn't inheritance, but rather strong typing. One of the requirements of this project is that it be more or less self-maintaining: new content types will be added fairly often; my bosses don't want me to have to go spelunking in the code every time that happens. An advantage of my generic framework is that the app's users can maintain the system simply by creating templates and editing data; few (if any) changes to the underlying code will be required. David Bayley thinks the generic framework will be more difficult to maintain than a strongly-typed object model. What do you think?
Speaking of user experience (see below), what do you think of this article on Microsoft's "inductive" user interface guidelines? Essentially, it argues that a good UI helps the user answer two fundamental questions when looking at a screen: "What am I supposed to do now?" and, "Where do I go from here to accomplish my next task?" The UI helps answer these questions by focusing each screen on a single task, and by providing clear links in consistent locations to secondary tasks.
I've tried to apply these guidelines in the design of my current project (a browser-based content management system), but I wonder if the principles apply primarily to infrequently-used apps? Will frequent/experienced users become annoyed at the "one screen per task" hand-holding approach of the inductive user interface? Joel Spolsky makes an interesting point about the difference between learnability and usability. I'm having a difficult time finding the right balance between the two.
OK, here's a nugget that could have saved me several hours: XML is case-sensitive!
I'm working on a content management system which saves content objects as XML in a SQL Server database. A typical content object might look something like this:
<?xml version="1.0"?>
<Content>
<Items>
<Item Name="Title">Document Title</Item>
<Item Name="Author">Phil Weber</Item>
<Item Name="Publication">Visual Studio Magazine</Item>
<Item Name="Issue">December, 2002</Item>
<Item Name="Body">Document Body</Item>
...etc.
</Items>
</Content>
So, I wrote some code (in VB.NET, which is not case-sensitive) to extract individual content elements, and it wouldn't work -- kept returning empty strings! I spent hours poring over the code, tweaking the XML, banging my head against my desk... Turns out I was looking for an Item whose Name attribute was equal to title instead of Title. GRRRR!
Go ahead and laugh, but if you ever make a similar mistake, you'll thank me!