SQL Drop All Stored Procedures from Database

DECLARE @SPName varchar(128)
DECLARE @Command varchar(256)

DECLARE SP_Cursor CURSOR SCROLL STATIC READ_ONLY FOR
SELECT SPECIFIC_NAME FROM INFORMATION_SCHEMA.ROUTINES

OPEN SP_Cursor

FETCH NEXT FROM SP_Cursor INTO @SPName

WHILE (@@FETCH_STATUS = 0) BEGIN

-- Use DROP FUNCTION for User-Defined Functions

SET @Command = 'DROP PROCEDURE ' + @SPName

EXEC (@Command)

FETCH NEXT FROM SP_Cursor INTO @SPName

END

CLOSE SP_Cursor
DEALLOCATE SP_Cursor

Read more...

Software Dictionary for Potential Employees

I am compiling a vocabulary list to help programmers better understand what is really being asked of them when they read a job site ad. Please feel free to send me more in the comments section.

Aggressive Schedules - Significantly less time than it will take you to complete the project correctly, if at all. Yes, it will still be your fault.

Fast Paced Environment - High stress shop that makes overseas garment industry sweat shops look like a vacation in the Bahamas. Also see "Aggressive Schedules"

Great Opportunity - You must have a minimum of 5 years experience in the following technologies: .Net (both C# and VB), VB 6.0, ASP.Net, Classic ASP, MVC, LINQ, AGILE Development experience, Java, javascript, AJAX, WCF, WPF, Silverlight, XML, XSLT, HTML, Multi-Threading, Reflection, Generics, Anonymous Types, Serialization, COM Interop, Emitting dynamic assemblies, Asynchronous design patterns, MFC, SQL Server 2008, SSIS, SSRS, Sharepoint, MSMQ, MQ, Linux, J2EE, JMS, JBoss in a clustered environment. In addition an easy going personality, willing to work some overtime as needed, must be available via cell phone weekends. Salary $30,000 with unlimited growth potential.

Strong Verbal and Communication Skills - Sorry, no one from India, China , Russia  or Arkansas need apply.
Read more...

Code Refactoring

"A software application is not complete when there is nothing more to add, but rather, when there is nothing left to take away." (apologies to Voltaire)...

Re-writing and re-organizing your code, known as refactoring, should be the heart and soul of your development process. Your goal is to make the code at each level, have a single purpose, use the most common and simplest toolset, be as straightforward and easy to follow as is possible. You should be able to explain any level of your code to another junior programmer in under 5 minutes.

Your code should exhibit high cohesion. In other words, at any given level, your code should do one thing and one thing only, do it simply, efficiently and effectively. Communications and use of services to accomplish tasks should be easy to follow, obvious and simple.

Variables, classes/objects and methods should be named well. Feel free to agonize over names, it IS important and you will need to live with them for a long time. Good, solid names that are in sync with the business process they support can make a huge difference in the readability of your code and when discussing feature sets and processes with non-IT folks.

Lastly, but still very important, apply the concept of refactoring to your design meetings as well as your coding. Just because someone has a "solution" or can come up with a way to "solve" a problem does NOT make it the correct one.

Re-design your ideas and assumptions as well. Do not be afraid to throw an 8' dry-erase board full of plans out the window and try something new. Walk through your ideas, pick them apart and shoot as many holes in them as you can. Once you adopt them, they become much more difficult to change.


Good Luck and Enjoy your Coding!

Read more...

Pain in the m_*!@#$

Everytime I do work for a client that has internal coding standards I find myself having to change between using the letter "m" or an underscore "_" or, God forbid, both of them "m_", when I need to name some variable that has a public property associated with it.

Here is what I consider to be a better fourth option. Enclose all of your backing variables into a structure. Then create a single instance of that structure and store it in a private variable called "Local".

It's easy to do, easy to read/write and provides a single method that works for everyone.


Public Class Employee
  
    Private Structure backingStore
        Public firstName As String
        Public lastName As String
    End Structure

    Private Local As New backingStore

    Public Property FirstName() As String
        Get
            Return Local.firstName
        End Get
        Set(ByVal value As String)
            Local.firstName = value
        End Set
    End Property

    End Class


Read more...

BrainBench, Prove IT, et. al.

To all recruiters & employers Listen Up!

Online testing services for software developers are useless, please stop using them. These exams do a great disservice both to the developers and the prospective employers who rely on them.

Lest you think that maybe this is a "sour grapes" rant, I can assure you that I have taken these types of exams many times during my career, almost always scoring in the high 90s. In spite of my scores I would still recommend banning their use for the following reasons...

Reason #1 - Not all people are honest! There is a significant group of people who cheat on the exams, they have books open, help files available or they simply copy and paste answers into a live instance of visual studio or SQL server and test each answer to find the correct one. I can't entirely blame them, they are fighting for an opportunity to get a job and these questions can be pretty obscure, not to mention that most developers don't bother committing to memory things that can easily be "looked up".

Reason #2 For those of us who who don't cheat we now risk having a good solid score of 88% looking terrible to employers in comparison to scores of those in group 1 above.

Reason #3 - Over the years I have found "many" questions on the exams that had wrong answers marked as the correct ones. I have had to call the makers of the exams in almost every instance to help them "correct" an answer or explain why their answer was not correct.

[update 6/13/2009 - I once again had to take a Prove-IT exam. I found two incorrectly marked answers, one on the VB.Net exam and another on the SQL 2008 exam. I have spoken with "Prove-IT" and they scrubbed the answers and agreed with me that two of them were "incorrect". They assured me they would fix the exam, but they were "unable" to correct my scores! I am currently working that out between Prove-IT and the recruiter. I also asked Prove-IT whether they were planning to send out letters to past exam takers who might have received lower scores than they were entitled to...I have yet to receive a response]

>[update 6/24/2009 - Prove-IT (Kenexa Inc.) finally agreed to update my scores after several discussions where they tried to convince me that they had no access to the data ...hmm. I would STRONGLY encourage anyone taking an exam to copy the questions and possible answers and check them for accuracy after you complete the test. While waiting for this "correction" I was, of course, unable to submit my scores to clients and to my knowledge, Kenexa did NOT notify other exam takers of the possible scoring mistakes.]

Reason #4 - Many people simply don't "test" well, even though they are excellent developers. Why should they lose an opportunity to get a job for lack of a skill that isn't required in the job?

Reason #5 - Maybe the most important reason ... even if you don't cheat and even if you get 100% correct it is NO indicator that you are a good programmer, only that you have a good memory. Think of it like giving prospective writers of your biography an English grammar and spelling exam. Just because the writer gets a good grade doesn't imply that he is a good writer, it means simply that he is unlikely to make many grammatical or spelling mistakes, but the writing itself could easily still be boring, dull or incomprehensible!

Recruiters, please stop...if you want to weed out people who are incompetent or you want to know the technical knowledge level of a programmer then interview him yourself or work with someone who has the technical expertise to interview candidates in person and stop relying on easy, cheap and inaccurate testing services.

Read more...

Object-Relational Mappers (ORMs)

For 95% of software projects that the average developer works on in a business setting they provide ZERO value and in fact they cause far more problems than you might realize.

They complicate, obfuscate and hinder the performance of the application. In addition, they are frequently misused by developers who now think they can be sloppy in their database modeling and "fix" any problems higher up the chain. It flies in the face of good object-oriented programming (encapsulation) by moving knowledge of a class's data out of the class and into an ORM and it ends up costing significantly more to maintain this type of complexity.

The only benefit derived is that the original programmer gets to add Entity Framework, LLBLGen, NHibernate or any one of a dozen other ORM software packages somewhere on his or her resume while you get to pay for the experience.

Well, that and the huge headache you will have when they leave, because now you need to find someone to maintain that design and the first sentence you will hear from your new programmer will be "Um, well actually I think it would be easier to rewrite the software..."

Remember, only add design complexity when it actualy solves a real problem and when the benefit outweighs the cost.

Read more...

Ultimate Environment

The Monitor(s)

Contrary to what many people in business think, this is not a luxury (ok, maybe some of these are!), but in general a developer requires a minimum of two monitors to be efficient.

For those who may not be familiar with the reasons, a typical developer needs to be able to simultaneously look at the code they are writing, watch the program actually run, monitor debug information screens, view performance metrics on the machine (network activity, memory usage, hard drive access), look at documentation and a variety of other items.

Switching back and forth on the same screen can seriously prolong the development/debugging cycle and depending on the complexity, can at times be virtually impossible without multi-monitor support.
Cine Massive Displays


This company provides large screen (and small) setup including the stands, monitors and software. All monitors are highest quality and come with a zero dead pixel guarentee.

Dell 2709

For the rest of us, here is something a bit more down to earth (and likely) a pair of 27" flat screen monitors. These are Dell's, but choose any that you like. Whatever you do, don't skimp and get an off brand thinking that you are saving a few bucks, it's not worth it.

The Chair

You spend 40-60 hours per week sitting in this thing, so let's at least find a good one.

Herman Miller Aeron Chair


Vision One

The chair(s) are actual car seats (Porsche is top favorite) all hooked up so you can work the controls. I admit, this might be a difficult sell for the office, but if you manage to get one, let me know!

The Keyboard

You type all day long, it's the tool that a programmer uses more than any other. A bad keyboard can effect the quality of your typing and well as the speed. It can also wreck havoc with you fingers, wrist and arm and eyes (for those of us who never passed a touch typing course).

Here are a few of my favorites, most hover around $150 except for the Optimus Maximus which comes in around $1600 and no, that's not a typo!

Das Keyboard

Sets itself apart because of its spectacular build quality. Marketed as the "best mechanical key switches available," the keys are composed of German-engineered, gold-plated key switches: You hear every click. The keys are easily removed and cleaned, and even those with a light touch will love the responsiveness. Not only did the keyboard do away with any unnecessary features (dedicated volume and e-mail buttons, and the like), it even did away with the most basic feature of all: letters on the keys.

Read more...

User Designs

Let's face it, users of software are just that ... users !

They have no human software interaction design skills, they are certainly not familiar with software design tools nor the limitations of any particular language and despite your best efforts, they never will be.

Most user's ideas of design patterns are what you buy at the fabric store to knit sweaters and the gang of four refers to the people responsible for the grafitti on downtown buildings and sidewalks. I don't mean to denegrate users, but lets face it, they are not software developers or designers.

Let's stop wasting valuable company time and resources engaging people who are clearly not qualified to make the decisions that we are asking of them.

Find a subject matter expert, sit at their feet and learn the business and the process. Take what you have learned and find a way to make the process better, then use what you know to create efficient user screens with minimal wasted effort that mimics the improved process and leave the poor users alone until you have something useful.

Remember - fix the process, then fix the software. -

Read more...