Memi.Reflection

Private members of memi's thoughts
The best thing to happen to Java...

... 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.

Posted: Aug 15 2004, 05:27 PM by memi | with no comments
Filed under:
Item Templates in Visual Studio 2005

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.

Posted: Aug 15 2004, 02:22 PM by memi | with no comments
Filed under:
SUN vs MS on Web Services - what really matters

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.

Posted: Aug 05 2004, 09:46 AM by memi | with no comments
Filed under:
DataSource controls

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?

VSTO setup issues

While reading the VSTO setup instructions, I found the following paragraph under the “Troubleshooting Setup”:

  • Issue: High contrast mode hides text in the Setup wizard.

If you have your monitor set to use High Contrast, the text in the Setup wizard is not visible.

To view the text in the Setup Wizard

  1. Open the Control Panel, choose Accessibility Options, and then click the Display tab.

  2. Clear the Use High Contrast option.

  3. Click OK.

  4. Run Setup for Visual Studio Tools for the Microsoft Office System again.

It's not the first time I read setup instruction, however this is the first time I see a setup issue regarding the contrast settings of the monitor. But why stop there? Maybe there is a problem in the brightness settings? Or even better - maybe the monitor is not turned on!

MS guys, is there any special reason for listing this problem?

    Posted: Jul 24 2004, 10:51 PM by memi | with 2 comment(s)
    Filed under:
    VSS and ClearCase on same machine

    Since I'm responsible for .NET and J2EE projects, I have two different IDE on my machine: VS.NET and WSAD (WebSphere Studio Application Developer). I use also two different source control tools: VSS for the .NET, Rational ClearCase for the J2EE.

    After I've installed the ClearCase and worked some time on the WSAD, I wanted to switch to the VS.NET. So, naturally, I opened it up and tried to open our project. To my surprise, some strange error messages appeared. Those error messages, which were raised by VSS, stated that “The operation could not be completed.” After the messages - I couldn't open my project, and it was marked as “unavailable”.

    I did some research on google, but couldn't find anything useful, that helped solve the problem. But - I did find some remarks stating that VSS and ClearCase on the same machine could be quite problematic.

    Next station was the registry. After an extensive research, it turned out that there is a specific registry key that the IDE (both of them!) looks into to see whether a specific SourceControl is installed. For some unknown reason (to me), there is no value in there for source safe, only for ClearCase. This value should be removed prior using the VSS. If it is there - the VSS integration in VS.NET won't work.

    So, here is a step by step instructions to re-enable VSS on a machine with ClearCase installed:

    1. Open RegEdit

    (Imagine that all the regular yada yada about the dangers in messing with the Registry is written right here.)

    2. Navigate to: HKEY_LOCAL_MACHINE/SOFTWARE/SourceCodeControlProvider/InstalledSCCProviders

    3. If ClearCase is installed, you should see one entry (besides the “(Default)”) named “ClearCase”, with the value “Software\Atria\ClearCase”. Remove the entry.

    4. Now try to work with VSS under VS.NET. It should work.

    If you would like to re-enable ClearCase later, simply add the entry mentioned above.

    After a few rounds of adding / deleting from the registry, I became quite tired from this procedure, so I wrote a little tool which performs this exact task. If you're interested - email me and I'll send it back to you. Just remember that this tool requires the .NET runtime on your machine (quite obvious, but you can never know...)

    Posted: Jul 21 2004, 03:03 PM by memi | with 6 comment(s)
    Filed under:
    Action Confirmation in web application

    One of the frequent problems we encounter while developing web applications is how to inform the user about an action that has been performed.

    Take, for example, the following (quite common) scenario:

    A user types data in some textboxes on the page, and clicks the “Save” button. The page submits itself, saves the data in the database, and redisplay. What should happen now? How are we going to inform the user that the save completed successfuly? Basically, we have three options, but IMHO each one of them is not good enough:

    1. Display a popup window with the confirmation message - This is a bad alternative, since we force the user to perform some action (clicking the “Ok” button of the popup) without any reason. There was nothing wrong, and nothing should interfere with his regular flow of work.

    2. Display a message in the browser's status bar - Not good. Often the browser decides by itself what would be displayed in the status bar, and our custom text could be quickly replaced by “Done”, “Opening page...”, or even “Error on page”. In addition, there is no control at all on the icon that will be displayed. Because of all the reasons above, the average user does not even looks at the status bar - he thinks he already knows what is in there (unlike dedicated classic client / server app).

    3. Dedicate special area on the screen for messages - Wrong again. Screen area is an expensive resource, and in web environment it is even more scarce, with all the browser's toolbars (again, not a problem in a client / server app). This solution may work well for applications which should run on high res screens (1024 X 768 and above. Unlikely enough, most users still prefer the old 800 X 600 res) and have very few objects on screen, but if your page contains 10 textboxes + 15 tabs containing textboxes, grids and drop downs (as many of are pages are), you'll think twice before sacrificing 2 cm of the screen for messages which will be rarely displayed.

    So, bottom line: we depend on the user to understand that if the page reloaded, and no error message appeared, then everything worked just fine.

    What do you think about that? What is your approach to this issue?

    Posted: Jul 21 2004, 12:03 AM by memi | with 12 comment(s)
    Filed under:
    DLL Hell...In Java?

    I am now functioning (beside the regular technological activities) as a team leader for two parallel projects in our company - one medium (web based) .NET project, and one huge J2EE project. This has been the reason for lack of writing lately.

    This is of course a good opportunity to compare the two technologies, although I'm not going to (re-)open a holy war, nor am I consider myself being Java expert.

    Anyway, one of the (surprising) problems we encounter in the J2EE environment is no less than the Java equivalent to the DLL Hell.

    In both projects, we maintain three environments: Dev, QA and Prod. For each project, the three environments are on the same server (.NET 1.1 on win2003 for the .NET project, WebSphere 5.02 on AS/400 for the J2EE one), and have their own database (SQL Server and DB2, respectively). When we want to deliver new modules to the QA env of the .NET project, we just...well...copy it. Maybe some changes in the web.config to direct to the appropriate database, but that's all, actually.

    To my big surprise, this was not the situation in the J2EE project. This project rely heaviliy on CMP EJB (in short: O/R mapping technology for distributed applications in the J2EE environment. Has some common features with the yet-to-come ObjectSpaces.). Looks like the application server (WAS 5, as mentioned before) cannot maintain two versions of EJB, and the result is the Dev and QA talks to the same database. Once there is one EJB “registered“ in the WebSphere, you cannot hold another one with the same name, but of different version. Sounds familiar?

    I have a full time programmer trying to solve that for already two weeks, and on Thursday last week he was helped by some WebSphere expert.  We'll know tomorrow whether the problem was solved or not.

    Posted: Jul 17 2004, 11:34 PM by memi | with 2 comment(s)
    Filed under:
    Cool JavaScript Magnifier

    We are developing an application which should display map to the user, allowing him to click on a specific regions on it. Problem is - the map is big, the screen is small (relatively, that is...). We didn't want to have a big scroller, because the user won't have a full prespective on the map.

    I've started googling on the net, and found this. Undoubtly, one of the coolest Javascript snippets I've ever seen.

    Posted: Jul 04 2004, 12:48 AM by memi | with no comments
    Filed under:
    VSS - where are we going?

    A recently published article on MSDN talks about the planned roadmap for VSS. I've read through it eagerly, looking for a feature I missed long ago, but to no avail.

    The feature I'm talking about is the (as called in ClearCase terminology) “Streaming” concept.

    Imagine the following situation (which I believe you are all familiar with): Two developers working on the same project. One of them assigned a feature request that should take 4 days. At the end of day 1, the feature is not ready yet, and the application cannot be built with what was written already. Well, our developer want to go home, he Checks-In all the files he has been working on, and leave.

    The next day, the second developer comes, and get the latest version from VSS. But then - SURPRISE! - the application cannot be built!

    So what should the first developer do? Should he not check in the file? but then he might lose it, since it's stored only on his local machine. Should he check in the file? He will then break the whole application!

    The “Streaming” concept says that the application does not have only single version, as in VSS, but as many versions as needed. For example - the first developer will check in the file, but not to the main app version, but to a sub version called “Developer Stream”. This stream holds the version of this developer only. This version will be promoted to the master stream when the whole feature is ready for action.

    This actually raise another question - how are we suppose to treat the source control apps? Should we use them as versioning  AND backup apps, or only versioning? If we'll think of them as versioning products only, then the problem is not even raised. Developer one should not check in the files at all, until he has finished working on them and they can be part of a version. And about the backup issue - there are a lot of 3rd party products that can handle that, regardless of the VSS.

    So, how do you utilize the VSS? Versioning only, or Backup & Versioning? How do you solve the situation described above?

    Posted: Jun 16 2004, 11:08 PM by memi | with 5 comment(s)
    Filed under:
    More Posts « Previous page - Next page »