Ka-Freakin-Boom

http://www.desconstrutora.com/

Okay, this web site literally rocked my browser's world.

I remember doing this with VBScript by changing the window position; but then with IE 5, I thought the commands had been removed. Nonetheless, I never choreographed it as well as it on this site. Very nice.

Microsoft WSYP (We Share Your Pain)

I was recently reminded of a funny (and fake) video Microsoft made and presented at TechEd a few years back. It's where the error dialog on the desktop sends a shock directly to the developer responsible for the specific flaw. Pretty funny video; although I would have gone SO much farther with it.

Here's a link.

Refactor versus Redesign

Many people misunderstand refactoring. So, let Wikipedia explain it:

Code refactoring is any change to a computer program's code that improves its readability or simplifies its structure without changing its results. In agile methodologies, refactoring is an integral part of software development.

I heard a guy label refactoring as redesign. As “clean up” occurred (by me), he called it redesign – poisoning the project with foolish misnomers. Although “rewrite” might be closer, it shows a misunderstanding of refactoring and its purpose.

Refactoring is a responsibility.

Refactoring is essential to software development – end of debate. Code is not created equally. Just because code works does not mean code is not a candidate for refactoring. Just because timelines are lean does not mean refactoring should be skipped.

The refactoring beneficiary is the business owner, bringing maintainability, longevity, performance, and reduced errors to their software investment. In many ways, it is too expensive not to refactor.

As a developer, I desire function and delivery. I am measured on accomplishment and velocity. As an architect, I desire form and consistency. I am measured on performance and maintainability. These are in conflict. Developers are predisposed. Analysts are confused. The architect must be dedicated to his discrete responsibilities, typically swimming upstream near a project’s end.

Refactoring is not redesign.

Here are examples of redesign. Change in tiers, change in security, change in technologies, change in patterns, change in tools, change in transport, change in inheritance, and change in interfaces. In some cases even those can be “tweaked” without introducing a redesign.

Here are examples of refactoring. Reworking flow logic, reworking looping logic, relocating classes, adding members to base classes, renaming variables, extending a method’s signature, adding trace logic, increasing exception handling, changing label fonts, and resizing a form.

Refactoring is typically a result of personal or peer code review. Like proofing documents, edits (event significant ones) are sometimes necessary. The information may be present, but the usability and readability may be diminished by a simple first draft.

Solution Design should be worked out near the project’s start. As no one is perfect, tweaks may be necessary. As no one is clairvoyant, amendments may be necessary. Still, design precedes significant development – which is the implementation of the design.

Refactoring corrects, simplifies and synchronizes implementations. Errors are caught in testing, complexity comes from iterative requirements, and discontinuity occurs with multiple developers. None can be worked out until after development is considerably accomplished.

If you think refactoring is the same as redesign, think again.

Provider supports the interface, but returns a failure code when it is used

If you are trying to link sql2000 from the new 64bit 2005 servers and get a message similar to this - “provider supports the interface, but returns a failure code when it is used” you may need to apply the fix below.

c:\Program Files\Microsoft SQL Server\MSSQL\Install>osql -pUSER -pPASSWORD -s[SERVER] -iinstcat.sql

http://support.microsoft.com/kb/906954