William (Bill) Vaughn's Musings

One of the "inside" aliases that I monitor posed the question: What should a (very) introductory Visual Basic .NET course (for college students) contain? At least one response went into some detail that (IMHO) missed what students getting started as programmers really need to know.
My answer:
____________________________________________________________________________________________
I might start (a very introductory course) in much the same way as I did when I taught CS101 to college students. Let’s assume, that these students know these foundational concepts—what’s a CPU, what’s RAM, disk, and the rest. Can we assume that these students are going to need know how to solve business problems with a computer program they have written themselves—as opposed to doing it with ledgers, 3x5 cards or Excel?

To do so they will need to know how to:
• Learn what needs to be done. This might mean interviewing customers those that will use the application and understanding the problem they are trying to solve. Too many developers come up with a solution to problems that don’t exist or don’t address the customer’s problems.
• Learn how to design before coding.

Continue reading "What Should a (Very) Introductory Visual Basic Course Contain?" »

Posted by William Vaughn at 12:03 PM | Permalink | Comments (2)

A recent question on the newsgroups asked about the life-expectancy of DAO and if it makes sense to transition to ADO to access their database.

The problem here is not DAO or even ADO classic (COM-based ADO). The problem here is the JET engine.
When you write an application using JET whether you you Access or VB6 or VB.NET or any other language, you are limited by the capacity and architecture of the shared-file architecture of JET. Your security is limited by JET's inability to be encrypted and since by its very nature it's designed to be passed around as a file and accessed by whomever receives it, it should not contain private data. Sure, there are lots of situations where a DBMS as simple as JET is okay--as in the home or for some non-secure office applications. But IMHO, JET is really not suitable for businesses that need to pass manage secure data. We've talked about and debated the merits and foibles of JET for many years here on this newsgroup and in other forums.

Continue reading "Question of the Day: DAO to ADO to ADO.NET" »

Posted by William Vaughn at 08:39 AM | Permalink | Comments (0)

I met with Microsoft last week over dim sun where we chatted about what’s right and what’s wrong with the documentation and help system. I said that the search engine is just busted. When I ask for an in-context topic I still get flooded with irrelevant topics. If I add more information to narrow the search, it seems to widen the search. I guess I’m just spoiled by Google that seems to get it right far more often.
So, I revert to the index trying to find something that’s close to what I want. This works better but still there are topics where the work selected takes me to Cleveland when I wanted Boston—and who would want Cleveland anyway?
When in the IDE, I make the mistake of selecting the term to search for—this works sometimes, but other times I just get “Form” or a suburb of Cleveland again.
After the talk, Microsoft wanted me to give them specific cases where I get sent off into the ozone. I’m building a log of all of these hits in an attempt to get them to see what’s going wrong.
Incidentally, they said that all of those little comments we put at the bottom of help topics are being kept by the Visual Studio people—and not passed to the help writers. Sigh.

If you have problems finding stuff with help in Visual Studio 2005, could you post these issues here? I expect that everyone is working with Visual Studio in ways that are far different than what I’m doing. Let’s see if we can help them help us (so to speak).
Bill

Posted by William Vaughn at 09:24 AM | Permalink | Comments (5)

As I have talked about many times here, in newsgroups and in my sessions, books and articles, IMHO JET/Access is not suitable in a business application. I've detailed the problems that include its physical IO over the network (which makes it prone to data loss), its inability to be backed up while any application is still connected, its need to be periodically compressed, it's lack of scalability (which means you have to start over when the customer outgrows it), it's (very) limited capacity and the number of users it can support. It should never be used as a web host unless you don't mind terrible performance--that's because it's a "client" engine--not a service designed to support parallel operations. One of the most serious problems is its inability to encrypt data in place and its fragile security system. This makes it "officially" unsuitable to manage HIPA-compliant data. The fact that you access JET over a very problematic MDAC stack is and always has been another problem. Each time the stack is changed, your application might or might not work. Jet is also accessed over a COM-based OLE DB interface--in unmanaged code.

Continue reading "JET? Are developers still considering it?" »

Posted by William Vaughn at 09:43 AM | Permalink | Comments (0)