February 2005 - Posts
Mike Hall has a good response to Mr. Grimes on the .NET Framework.
I'm about 50 pages into The Gang of Four's Design Patterns. I've been reading about design patterns since I finished Agile Software Development recently. The COMPOSITE pattern has been one of my favorites, but I didn't really understand how prevalent it was until last night. I'd mainly considered the use that Robert Martin gave it in his book--the COMPOSITE COMMAND pattern. The GoF use a word-processor to illustrate the concept so you can see it much more broadly. The Range Object in MS Word and MS Excel are both COMPOSITE objects!
This is great--the patterns are starting to Gel for me, and I'm beginning to see coding structures as relations of patterns instead of relations of simple objects. This is going to radically improve my design skills. I feel like Luke Skywalker when Obi Wan says "you have taken your first steps into a larger world."
If you haven't read these two books, I highly suggest that you do.
I'm building a setup project for a windows service, and it has been a matter of some annoyance that I've not been able to debug the custom actions I've written in .NET during the installation process. I've finally hacked together a way to do this which has made the process of developing the custom action enormously easier.
First let me say that I have searched for ways to do this before and have been unable to find them. If anyone has a better way, then I'd be glad to hear it as what I'm about to add is something of a hack.
If you want to debug a custom action during installation, add a modal dialog form to the beginning of the function you wish to test. Place a breakpoint anywhere after the call to the modal dialog form. Run the installation. When the modal dialog form pops up, go to the Debug->processes menu. Look for the msiexec processes, and find the one that refers to your dialog (usually indicated by the form's caption). Attach to the process. Now, close the dialog form, and watch the code execution stop on your breakpoint.
The dialog form serves as a processes interrupt that gives you time to attach to the process at the place your interested in.
While this approach has "hack" written all over it, I can't think of another way to do this. If you know of something better, tell me and I'll post it.
There is a better method here:
... when you know you did something right, it's the best thing in the world.
Step back in time 3 years in my career. I was just getting a command of C, had just written a library of functions that encapsulated some pretty hairy business logic into an easy-to-use API. I was new to C, and this libary involved the use of other things that were new to me as well, such as linked lists and tree structures.
Prior to development of this library, it took on average about 3 weeks to develop a new driver for the system. After the library, the average development time dropped to 3 hours. From then on I was basically implementing a new interface for each new system we connected to.
I left that job about 6 months later, but I still do contract work developing these drivers for this company. Yesterday they emailed me around 3:30 with an emergency. One of these drivers I wrote 3 and a half years ago was suddenly giving them problems in a new installation. They were having a demo the next (this) morning, and needed to correct the problem before then. That was going to be difficult because I had to go to Physics class. I got started on the problem at 9:30 last night. It turns out that they are actually connecting to an older vesion of the same system I wrote the driver for 3 and a half years ago. The newer system used to send a command to clear the communication buffer prior to a new command. The older system, from the data capture I received, did not. Solving the problem was as simple as adding a couple of memset() statements to the beginning of the start_new_command() procedure.
I tested the program against the data they sent me. No problems. Turned the program in. No problems. They tested the program against the original system. No problems. They tested the program on the installation site, no problems.
This is the nectar of the gods. Not only was there no problem in the software I wrote, but because of the way it was designed, I was able to quickly isolate the problem and correct it in such a way that it did not impact the original system I wrote against. This is sense of accomplishment I strive for in my work. This is why I love programming.
This is a great blog on the recent EU rulings against Microsoft. Were it my company, I'd stop selling Windows in Europe altogether. I realize that it would hurt financially, but some principles are more important than money. The aforementioned blog is right--if you observe the principle upon which the ruling is based, then any new feature or addition to the system could be interpreted as "stifling competition." Any new innovation by its nature constitutes "stifling innovation." This inverts the meaning of innovation and causes it to grind to a halt. Hail to the EU, may you get what you've asked for.
Why should it be legal to sell something, but illegal to give it away?
Why should it be legal to give something away, but not to sell it?
Reminds me of an old George Carlin routine. . . .
I think I've found a failure in the Regular Expression validator for ASP .NET.
If you choose US Zipcode from the validation expression list, it gives you the following expression:
The problem is that the expression passes "2961534" as a valid zipcode.
The fix is extremely simple--simply add the beginng and end flags to the existing expression:
This was found by our QA department--way to go guys!
So, does anyone here know where I can go to edit the list of regular expressions offered me by the Regular Expression Validator control?
I've been a programmer for 5 years now, and here is a list of technologies I've used in my on-the-job capacity:
- OOP: C, C++, C#, VB .NET
- Pseudo-OOP languages: VBA, VB5, VB6
- Web Technologies: ASP, ASP .NET
- Client-side rendering: HTML, DHTML, css
- Databases: SQL Server, Access
- Reporting tools: SQL Server Reporting Services, ActiveReports
- Installers: Wise, InstallShield
Additionally, I've build custom server controls for ASP .NET, developed and deployed software for Pocket PC 2003, used SQL Server Merge Replication. Furthermore, I've been responsible for defining, implementing, and maintaining software development processes such as source-control.
I mention all of this because I want to make it clear that I have experience with a wide range of technologies and my preferences are based on experience and taste rather than lack of experience.
I prefer VB .NET to C#. I know that at root they're basically the same--that most of the differences are merely stylistic. I just like the slightly more verbose aspect of VB.
I've noticed however, that Microsoft, in their job postings, mention "x years of experience in C#" but not VB .NET. Is this deliberate? At Microsoft, are the C# and VB .NET experience substitutable? Are VB .NET developers not wanted as Microsoft? I don't mind coding in C# if that's the issue--what I'm getting at is this: does MS have a preference for C# over VB .NET in terms of the background experience that they're looking for in potential employees? If so, why?
One of my dreams is to work for MS in Redmond. Am I painting myself out of that dream because I code mainly in VB .NET?