You are currently browsing the archives for the Technology category.

2 weeks 5 days

Posted In: Technology, Everyday life — November 12, 2005 @ 11:25 am — Peter

Last night I took some time to update a few broken items on our website. A few days ago Chris pointed out that RSS feeds were not working quite right. I simply reloaded the latest Wordpress code and the problem has gone away.

Also, I’ve added code to support annotations above photos in our gallery. So far we’ve only gone through and commented on a few… Here is an example of what it looks like.

Out of curiosity, last night I setup Mono on this server to see how it handles web service projects developed in Visual Studio .NET. After a few minutes of hacking the configuration, I deployed simple hello world service that I was running off my laptop to test with a PHP NuSOAP consumer. When I repointed the WSDL reference of the PHP NuSOAP consumer, it crashed with a SOAP error. I guess Mono has a slight variation in the way it fullfils SOAP requests… I’ll be playing with Mono some more over the weekend and follow up with my thoughts on it.

No concrete plans for today. Weather.com reports 62 degrees Fahrenheit and windy. Sounds like a nice fall day and perhaps a walk in City Park is a good idea. Most of the trees around here are naked and I have lots of leaves to rake up. I’m also hoping to find some time this weekend to get through some more of the book I’m reading.

Comments (6)

Does Visual Studio Rot the Mind?

Posted In: Technology, Editorial — October 27, 2005 @ 10:52 am — Peter

http://charlespetzold.com/etc/DoesVisualStudioRotTheMind.html

I came across an essay/talk (linked above) via Slashdot.org the other day and it really hit close to home since I’ve become increasingly familiar with the Visual Studio development environment at my new job. While I’m by no means a code purist, I do however, like to know the function of every line of code in an application I’m responsible for. In previous environments I’ve worked in, you start with a blank workspace and start building a program via whatever approach you chose. However, like the author of this essay mentions, Visual Studio forces you into the approach that Microsoft deems to be the best practice. Along with the guidance offered by Visual Studio comes a volume of generated boilerplate code that obfuscates the intricate details of the program you’re implementing. A perfect example of this behavior is web service development using Visual Studio. While I enjoy the rather painless implementation of web services via the .NET framework, you’re out of luck if you’d like to see the actual SOAP messages being exchanged. Sure there are convoluted hacks that can add tunnels and listeners to the environment stack, but their configuration isn’t exactly straightforward. Even the SOAP trace tool from the MSSOAP Tookit 3 is crap. I’ve ended up using Etherreal to capture HTTP packets generated by web service calls to reassemble a SOAP conversation in a way that satisfies my debugging needs. I’d love to hear some suggestions on a better way to inspect the raw XML content of the <soap :fault> element when using .NET. Anyway, the point of my rant is, the Visual Studio environment hides vital details of web services that could be useful during the debugging of interoperability issues and such.

Regarding Intelisense (aka code insight), I’m quite fond of this feature. I’d love to know all the members and methods of my most frequently used classes, however, I simply don’t have room for this type of information in my brain. Also, code insight has been a feature I’ve grown to love long before using Visual Studio. Eclipse, for example, does a lovely job of when building Java application. To be quite honest, the thing I love most about code insight is the amount of typing is saves me. Unfortunately, when using Visual Studio’s Intelisense to cruise through coding, it tends to insert annoying spaces between things.

One issue that wasn’t raised by the essay is the visual debugging component of Visual Studio. I’m convinced that this “feature” has resulted in a culture of hack and debug programmers that are unable to think through a problem start to finish. I’ve witnessed developers throw together a minimal amount of code and logic and immediately being stepping through the code using the debugger to determine what the next logical steps should be. Not only is this approach time consuming, it often results in a program that just barely works. Forget data validation and exception handling… just make the code work under ideal circumstances!

No Comments »

  Next Entries »