August 2004 - Posts
Yep, that's possible.
My machine had crashed yesterday, and is in the lab right now. Looks like the vent has gone crazy.
As usual, I had a really urgent .NET thingy to finish, so I wanted to use my wife's laptop (IBM R40, cute little machine) for this.
There was no problem installng the VS.NET. Since it went so well, I though to myself: "Well, why won't we try to install a web server?".
I started with Cassini, but the VS.NET didn't get used to it.
I then found this article, and voila! after 15 mins I had IIS on my wife's machine up and running.
I'm sure she is very happy about it.
I may be the last one to hear about it, but in case there is someone who didn't know that:
1. From VB's View Menu, select toolbar, then customize......
2. In the resulting dialog, click on the command tab.
3. In the Categories List, select Help.
4. Select "About Microsoft Visual Basic" in the Command List, and drag it to any
menu or the toolbar.
5. Right-click on the item you just dragged and rename it to "Show VB Credits"
(without quotes).
6. Then close the "Customize" dialog and click on the "Show VB Credits" item
found here.
... is .NET.
I know it sounds a bit strange, but I really think that's true.
Before the .NET era, the world was divided between two groups: The USA and the USSR.
Ok, just joking: The programming world was divided between two groups: The VB group, and the Java group. There were some smaller groups, such as the Delphinians, the Perlians, and even some Cobolists, but the major ones where, undoubtly, the VB'ers and the Java-ists.
Those two groups almost didn't communicate between them. The Javaists regarded the VB'ers as novice programmers, whose programming skills are limited to dragging fancy UI object in their toyish RAD environment (of M$, of course!), while the VB'ers looked at the Javaists as some ultra-geeks who prefer hand coding the RDBMS itself, if that was possible, and who actually hand coded the whole OS.
Those two groups lived quite happily beside each other, and continued to grow and flourish.
And then came .NET.
Suddenly, the VB'ers exposed to java-like terms such as CLR (=JVM. Yes, I know you can't really compare them, but still...), MSIL (=Bytecode), OOP (=OOP), Patterns and Practices (=Design Patterns) and so on. While assimilating this huge pile of knowledge, it was discovered that there is some high-end language that has some of these features already - Java!
If, four years ago, it was almost impossible to "convert" a VB'er to the Java world, it is now much easier. The basic concepts are exactly the same. Of course, there are important differences, but it is not something you can't teach yourself in 21, or even less, days. All in once, the Java world gained a ten of millions potential developers.
And it looks like they know that. In a heated discussion in TSS.COM about the Current State of JSF (which is the Java's answer to ASP.NET), the following post appears:
"What I see happening is that non-gurus are literally driven off by the complexity and weirdness of JSF (and JSP custom tags and JSP expression language). The Java community is off on ivory tower framework tangents and losing sight of the simple elegance principles behind Java. Rather than competing with ASP.NET the web applications infrastructure is making Java LESS competitive and giving Microsoft a free ride with their existing developer customers who cannot begin to fathom what the heck is going on in Java web app land."
A few years ago, no one at Java Land would consider it important to compete with MS products. In fact, they may be humiliated just by mentioning it. But the .NET is a very legitimate competitor, and Java responds accordingly (or, more accurately, tries to respond accordingly.)
We saw this close relations recently in our company. We answered an RFP, and suggested using .NET in our solution. The customer liked our proposal, but wanted it to be a Java solution. Now, if we were in the VB6 era, this was the point where we would say "T'was nice to meet you. See you at the next project.". But since we were familiar with .NET, we felt quite comfortable migrating to Java.
One of the first things I've checked in Beta 1 of VS 2005 was the way to customize its item templates.
I think this feature in general is one of the best productivity boosters around, and once implemented correctly can reduce development time remarkably. The reason most organizations don't use this feature is that in order to use it one would have to dive into complex ASCII files and obscure directories, without any reasonable debugging mechanism and sparse docs. There are some tools in the market for this purpose (such as my Merlin), but still - most developers don't use this feature.
When I looked in VS 2005 after this feature, I've got a surprise. Looks like the good guys at MS introduced a new mechanism which makes it more convenient to add / customize item templates. The new mechanism uses XML files (at last!) called vstemplates, which make the whole process a lot more human-readable. There are even already some articles about the new mechanism (like this and this). But, it looks like the job is not done yet. The new mechanism is applied only to the Winforms application. The web based projects still uses the (not so) good old vsdir & vsz files.
Does anybody know whether this will be the situation in the final product, or is it only in the Beta? Will the web guys enjoy the vstemplate file, or will they keep struggle with the older files?
If someone knows the answer - please drop me a line.
I couldn't overcome my curiosity, and I donwloaded the source code used by SUN for their comparison of the .NET vs Java web service performance.
The first thing that striked me was, that out of 208 files in the ZIP file, only 44 are related to .NET. All the rest are required by the Java implementation.
I think that's also means something when comparing those technologies.
I've started diving into the VS2005 beta 1 a few days ago (I hope I'm not the last one...), and naturally started looking at the new features it provides.
While browsing, I've stubmled accross this article in MSDN, which explains the new concept of the DataSource controls. This article made me wonder about this whole new concept.
The SQLDataSource control looks really nice, not to say sexy, but I woner how useful it is going to be in real, full blown applications. I mean, you're not going to write your SQL in its full glory on the ASPX page, don't you? Not to mention the connection string itself. What happened to the n-tier architecture? I don't really see a scenario in my company when I'm going to use this control, except maybe for some really tiny make-it-done-in-two-days applications.
The ObjectDataSource looked more promising, until I've read the small letters. The source object has so many restrictions (default, parameterless constructor, stateless, easily mapped to update, insert and delete actions), but what really caught my eyes are those two:
1. The update / insert methods in the object are expected to accept named parameters. Hey, where did that come from? I've been taught that the best way to pass parameters between layers is by using some general purpose package, may it be XML, named value collection, or even arraylist. If I'm going to add new parameter - why do I have to change my object interface?
2. The method execution is done by reflection. I don't remember where I've read it first time, but AFAIK execution by reflection can be 400 times slower than regular one. OK, when you think of it, there is no really other way of performing this databinding, but if I'm going to use reflection just to update the business layer, why won't I use some third party's professional O/R mapper, which will update my data layer?
So, am I missing something? I guess it's a bit too early to ask for other's exerience on this subject, but what do you think of it? Which DataSource control will be the real hit? Will this concept be widely used?
More Posts