Sorry, no longish postings those days, as I am in release crunch mode right now. In the meantime, you might want to check out what I consider some of the most interesting software technology webcats / podcasts out there:
I listen to them on a daily basis using an iPOD shuffle during my way from / to work.
Sunday, November 27, 2005
Saturday, November 19, 2005
ADO.NET Transactions, DataAdapter.Update() And DataRow.RowState
I guess that almost every ADO.NET developer stumbles upon this sooner or later... as we all know, DataAdapter.Update() invokes DataRow.AcceptChanges() after a successful DB-update/-insert/-delete. But what if that whole operation happened within a transaction, and a rollback occurs later on during that process? Our DataRow's RowState has already changed from Modified/Added/Deleted to Unchanged (resp. Detached in case of a delete), our DataRowVersions are lost, hence our DataSet does not reflect the rollback that happened on the database.
What we are doing so far in our projects is to work on a copy of the original DataSet, so we can perform a "rollback" in memory as well. In detail, we merge back DataRow by DataRow, which allows us to keep not only its original RowState, but also different DataRowVersions (Original, Current, Proposed and the like). This is essential for subsequent updates to work properly.
But merging thousands of DataRows has a huge performance penalty (esp. if you got Guids as primary keys - this might be caused by a huge number of primary key comparisons, but I am not really sure about that), which sometimes forces us to disable that whole feature, and do a complete reload from the DB after an update instead (but then again, this will wipe pending updates which were rolled back).
So right now I am looking for a faster alternative. ADO.NET 2.0 provides a new DataAdapter property, namely DataAdapter.AcceptChangesDuringUpdate. This is exactly what we need, but we are still running under .NET 1.1.
Microsoft ADO.NET guru David Sceppa came up with another approach:
If you want to keep the DataAdapter from implicitly calling AcceptChanges after submitting the pending changes in a row, handle the DataAdapter's RowUpdated event and set RowUpdatedEventArgs to UpdateStatus.SkipCurrentRow.
That is actually what I will try to do next.
What we are doing so far in our projects is to work on a copy of the original DataSet, so we can perform a "rollback" in memory as well. In detail, we merge back DataRow by DataRow, which allows us to keep not only its original RowState, but also different DataRowVersions (Original, Current, Proposed and the like). This is essential for subsequent updates to work properly.
But merging thousands of DataRows has a huge performance penalty (esp. if you got Guids as primary keys - this might be caused by a huge number of primary key comparisons, but I am not really sure about that), which sometimes forces us to disable that whole feature, and do a complete reload from the DB after an update instead (but then again, this will wipe pending updates which were rolled back).
So right now I am looking for a faster alternative. ADO.NET 2.0 provides a new DataAdapter property, namely DataAdapter.AcceptChangesDuringUpdate. This is exactly what we need, but we are still running under .NET 1.1.
Microsoft ADO.NET guru David Sceppa came up with another approach:
If you want to keep the DataAdapter from implicitly calling AcceptChanges after submitting the pending changes in a row, handle the DataAdapter's RowUpdated event and set RowUpdatedEventArgs to UpdateStatus.SkipCurrentRow.
That is actually what I will try to do next.
Friday, November 18, 2005
Tuesday, November 15, 2005
Latest Purchase On Thinkgeek.Com
The "Binary Dad" t-shirt
In order to save on overseas shipping costs, we always pool our orders. Top item among my friends' orders this time was the "Schrödinger's Cat Is Dead" t-shirt.
In order to save on overseas shipping costs, we always pool our orders. Top item among my friends' orders this time was the "Schrödinger's Cat Is Dead" t-shirt.
Friday, November 11, 2005
Is MS Windows Ready For The Desktop?
No offense intended, I am myself a very Windows-centric developer, but "Is MS Windows Ready For The Desktop" is just too funny!
So now comes partitioning. Since I know from Linux that NTFS is a buggy file system (never got it to work smooth under Linux), I choose the more advanced FAT-fs, since there's no other option, this should be right for me. It's a disappointment I can't implement volume management tools like LVM or EVMS, or an initrd, but I decide to forget about this and go on, believing the Windows-team has made the right decision by not supporting this cumbersome features. So this means, I can forget about software-RAID and hard disk encryption supported by the kernel. But what about resizing partitions? Steve explains, this can be done in Windows. You go to your software-supplier, ask for the free Partition Magic 8.0, and after paying your €55 NVC, the Partition Magic CD can do a (tiny) part of the stuff EVMS can, like resizing.
So now comes partitioning. Since I know from Linux that NTFS is a buggy file system (never got it to work smooth under Linux), I choose the more advanced FAT-fs, since there's no other option, this should be right for me. It's a disappointment I can't implement volume management tools like LVM or EVMS, or an initrd, but I decide to forget about this and go on, believing the Windows-team has made the right decision by not supporting this cumbersome features. So this means, I can forget about software-RAID and hard disk encryption supported by the kernel. But what about resizing partitions? Steve explains, this can be done in Windows. You go to your software-supplier, ask for the free Partition Magic 8.0, and after paying your €55 NVC, the Partition Magic CD can do a (tiny) part of the stuff EVMS can, like resizing.
Wednesday, November 09, 2005
Lotus Notes
Let me talk about Lotus Notes today (the client only, as this is all I know about - and by the way, this is why the UI matters so much: users just don't care about fancy server stuff like sophisticated data replication, they care about their experience on the frontend side of things). I mean some people have learned to swallow the bitter pill, quietly launching their little KillNotes.exe in order to restart Notes after each crash without having to reboot the whole system. Others may curse on a daily basis (Survival of the Unfittest, Lotus Notes Sucks, "Software Tools of Dirt"-Page (in German), I hate Notes, Interface Hall of Shame or Notes Sucks come to mind). As for myself, I am just going to calmly describe how working with Lotus Notes looks like:
This screenshot shows a typical Lotus Notes 4.5 workplace as of 1996. Notes 5.0, which shipped in 1999, looks pretty much the same and is still widely used today.
As far as I have heard some things have been improved in Notes 6.5, while others haven't. But you know, large corporations sometimes skip one major release on their installation base, because of the effort involved in updating all the clients or because they couldn't migrate their applications built on top of it or whatever. This just proves that software tends to stay around longer than some vendors originally anticipated.
Jeff Atwood - as usual - sums things up pretty accurately:
This screenshot shows a typical Lotus Notes 4.5 workplace as of 1996. Notes 5.0, which shipped in 1999, looks pretty much the same and is still widely used today.
- The Notes client crashes when doing a search, it crashes when inserting data from the clipboard, it crashes on all kinds of occasions, and the stuff you worked on is gone. No draft folder, nothing.
- After Notes crashes, there is no way to restart it, because some processes remain in a zombie-like state. Luckily there is KillNotes. It is even available from an IBM download site. Think about it, instead of fixing those crashes, or instead of avoiding zombie processes being left behind after crashing, they did the third-best thing: provide a tool to clean up those zombie-processes. Of course out of the 100 million Lotus Notes users worldwide, maybe 1% have ever heard of that tool at all.
- The UI is... special. The Look & Feel is incomparable to anything else you might know. Most famous: The "You have mail"-Messagebox - pops up, even when you are typing in another application. Makes you switch to your inbox, where you find - nothing. No new mail. UI controls that look and behave completely different than what the standards of the underlying operating system would suggest. Modeless dialogs for text formatting. Undo rarely ever works. Pasting some HTML or RichText data from the clipboard blocks the system for several seconds. There is no toolbar icon for refreshing the current list of documents (e.g. mail inbox) - refreshing happens when you click into a grey window area (you'd better know about it!). Forms do not provide comboboxes for listing values to choose from, only modal dialogs that open up and contain listboxes. Icons don't comply with the desktop's standard, e.g. the icon for clipboard pasting is a a pin, the icon for saving is a book. Grids are not interactive, e.g. no way to change column order, only rudimentary grid sorting. And so on and so on...
- When sent to the background, the client sometimes starts consuming CPU power (up to 90%) - slowing down the foreground application, doing I don't know what. As soon as you bring it to the front - back to 0%. Like a little child saying "It wasn't me". "Un-cooperative multitasking" at its best (I wonder what would have happened during the non-preemptive days of 16bit-Windows).
- Text search: Runs in the main UI thread, so it blocks the whole application until it's done - and this might take a looong time. I don't know for sure, but it's so slow I suspect it has no fulltext index, thus has to scan each and every document again and again. And if that's not the case, its index seek implementation must be bogus. Anyway, more often than not the search result is just plainly wrong - documents that clearly should appear simply don't show up. Searches are only possible for one criteria, not more than that.
- From time to time Notes causes flickering by senselessly repeated window repainting.
- There are those constant security messages popping up, that keep on asking whether to create a counter certificate or whatever in order to be able to access certain documents. I have a degree in computer science, but I find these messages completely incomprehensible. Go figure how much the average end-user will enjoy that.
- All those weaknesses are - per-definitionem - inherited by most Lotus Notes applications.
As far as I have heard some things have been improved in Notes 6.5, while others haven't. But you know, large corporations sometimes skip one major release on their installation base, because of the effort involved in updating all the clients or because they couldn't migrate their applications built on top of it or whatever. This just proves that software tends to stay around longer than some vendors originally anticipated.
Jeff Atwood - as usual - sums things up pretty accurately:
We've all had bad software experiences. However, at my last job, our corporate email client of choice was Lotus Notes. And until you've used Lotus Notes, you haven't truly experienced bad software. It is death by a thousand tiny annoyances - the digital equivalent of being kicked in the groin upon arrival at work every day.
Lotus Notes is a trainwreck of epic (enterprise?) proportions, but it's worth studying to learn what not to do when developing software.
Thank You McAfee
So second level support calls in: "Listen, one customer installed our application, but he keeps on insisting that the user interface is all empty". "Yeah right", you think, thanking god that you don't have to answer hotline calls.
A quick Google search brings up a well-known suspect: McAfee AntiVirus. According to this Microsoft knowledge base article, McAfee's buffer overflow protection feature can screw WinForms applications - and that's exactly what had happened at the customer's site. Luckily there is a patch available.
BTW, I stopped using McAfee privately when they changed their virus definition subscription model - I hate to pay for a program that literally expires after 12 months.
A quick Google search brings up a well-known suspect: McAfee AntiVirus. According to this Microsoft knowledge base article, McAfee's buffer overflow protection feature can screw WinForms applications - and that's exactly what had happened at the customer's site. Luckily there is a patch available.
BTW, I stopped using McAfee privately when they changed their virus definition subscription model - I hate to pay for a program that literally expires after 12 months.
Friday, November 04, 2005
First Impressions Of Visual Studio 2005 RTM
I installed Visual Studio 2005 RTM yesterday, and - as a first endurance test - tried to convert one of our larger Visual Studio 2003 projects to the new environment. The conversion finished successfully, but the compilation raised several errors:
After fixing those issues, our application could be built. But I faced runtime problems as well, e.g. a third party library (for XML encryption) which suddenly produced invalid hash results (sidenote: XML encryption is now supported by .NET 2.0 - my colleagues and me were joking that this might be just another case of DOS Ain't Done 'Til Lotus Won't Run).
Don't get me wrong, Visual Studio 2005 is a cool product with lots of long-awaited features. When starting a project from scratch, I would be tempted to jump board on 2005. But with .NET 1.1 legacy projects lying around, there is just no way we can migrate to 2005 yet.
By the way, wiping an old Visual Studio 2005 Beta or CTP version is a nightmare (you are expected to manually uninstall up to 23 components in the correct order)! Luckily Dan Fernandez helped out with the Pre-RTM Visual Studio 2005 Automatic Uninstall Tool.
- One self-assignment ("a = a") caused an error (this was not even a warning under .NET 1.1), I guess this can be toggled by lowering the compiler warning level. Anyway it is a good thing the compiler pointed that out, as the developer's intention clearly was to write "this.a = a". Luckily the assignment to "this.a" happened already in the base class as well.
- Typed Datasets generated by the IDE are not backward compatible, as the access modifiers for InitClass() have changed to "private". We had a subclass which tried to invoke base.InitClass(), hence broke the build.
- The new compiler spit out several naming collision errors, when equally named third party components were not access through their fully qualified names (although in the code context, due to the type they were assigned to, it was clear which type to use) The .NET 1.1 compiler used to have no problem with that.
- Visual Studio 2005 also crashed once during compilation. I had to compile one project individually in order to get ahead.
After fixing those issues, our application could be built. But I faced runtime problems as well, e.g. a third party library (for XML encryption) which suddenly produced invalid hash results (sidenote: XML encryption is now supported by .NET 2.0 - my colleagues and me were joking that this might be just another case of DOS Ain't Done 'Til Lotus Won't Run).
Don't get me wrong, Visual Studio 2005 is a cool product with lots of long-awaited features. When starting a project from scratch, I would be tempted to jump board on 2005. But with .NET 1.1 legacy projects lying around, there is just no way we can migrate to 2005 yet.
By the way, wiping an old Visual Studio 2005 Beta or CTP version is a nightmare (you are expected to manually uninstall up to 23 components in the correct order)! Luckily Dan Fernandez helped out with the Pre-RTM Visual Studio 2005 Automatic Uninstall Tool.
Thursday, November 03, 2005
J2EE Inhouse Frameworks
Spring Framework lead developers Rod Johnson and Juergen Hoeller have their own opinion about J2EE Inhouse Frameworks (taken from their JavaOne 2005 presentation):
Tuesday, November 01, 2005
In The Kingdom Of The Blind, The One-Eyed Man Is King
Don't you also sometimes wonder where all the top-notch developers are gone? As more and more unskilled novices enter the scene while simultaneously some old veterans are losing the edge, chances are there are not too many star programmers left to steer the ship through difficult waters. Not that this is happening everywhere, it's just that it seems to be happening at some of the software shops I know, so I am quite sure the same is true for other places as well...
The combination of newcomers on one hand, who have some theoretical knowledge about new technology, but at the same time no idea how to turn that knowledge into working products, and long-serving developers on the other hand, who are not willing to relearn their profession on each single day, is particularly dangerous.
The greenhorns often load a pile of tech buzzwords upon their more-experienced peers along with poorly engineered, homebrewn frameworks (notwithstanding they might know about third party software platform and component markets, they tend to suffer the Not-Invented-Here Syndrome). After that, they endlessly keep on theorizing whether to favor the Abstract Factory Pattern over the Factory Method Pattern or not.
At the same time their seasoned colleagues - overwhelmed with all that new stuff - just want to turn back time to the good old days when all they had to worry about was whether the Visual Basic interpreter swallowed their code or their mainframe batch jobs produced a valid result. In the kingdom of the blind, the one-eyed man is king.
Really it's weird - the people who are smart AND experienced AND get something done, they seem to be an endangered species. Some of them waft away to middle management (which is often a frustrating experience, as they cannot do any more what they do best), others are still around but because of one reason or another they are not in charge any more of taking the lead on the technology frontier. It's the architecture astronauts who took over. And it's the MBAs who allowed them to. Pity.
The combination of newcomers on one hand, who have some theoretical knowledge about new technology, but at the same time no idea how to turn that knowledge into working products, and long-serving developers on the other hand, who are not willing to relearn their profession on each single day, is particularly dangerous.
The greenhorns often load a pile of tech buzzwords upon their more-experienced peers along with poorly engineered, homebrewn frameworks (notwithstanding they might know about third party software platform and component markets, they tend to suffer the Not-Invented-Here Syndrome). After that, they endlessly keep on theorizing whether to favor the Abstract Factory Pattern over the Factory Method Pattern or not.
At the same time their seasoned colleagues - overwhelmed with all that new stuff - just want to turn back time to the good old days when all they had to worry about was whether the Visual Basic interpreter swallowed their code or their mainframe batch jobs produced a valid result. In the kingdom of the blind, the one-eyed man is king.
Really it's weird - the people who are smart AND experienced AND get something done, they seem to be an endangered species. Some of them waft away to middle management (which is often a frustrating experience, as they cannot do any more what they do best), others are still around but because of one reason or another they are not in charge any more of taking the lead on the technology frontier. It's the architecture astronauts who took over. And it's the MBAs who allowed them to. Pity.
Subscribe to:
Posts (Atom)