10 things you should know about SQL Server 2005 Management Studio

Takeaway: SQL Server 2005 Management Studio is a phenomenal advance over the tools provided with SQL Server 2000. Check out the improvements in SQL Server Management Studio, which makes it easier to locate errors in your code and allows you to keep tabs on your reports.

By Arthur Fuller and Stephen Giles

Microsoft SQL Server 2005 contains a number of major new features, but the feature that we like the most is the SQL Server Management Studio. This tool is leaps and bounds beyond what was available in earlier versions of SQL Server. Here is a list of the 10 things that we find most useful about SQL Server Management Studio.

1. Combines the best features of many tools
In earlier versions of SQL Server, you had two main tools: a graphical administration tool (Enterprise Manager) and a Transact SQL Editor (Query Analyzer). The problem with this split is that we do development and administration on SQL Server (sometimes at the same time) and often have to flip back and forth between the two. In SQL Server Management Studio, the Enterprise Manager and Query Analyzer are combined into one common interface, allowing you to manage your servers graphically and to write Transact SQL.

SQL Server Management Studio also allows you to access an Object Browser for all registered servers, which combines the features of the Object Browser from Query Analyzer with the Server tree view from Enterprise Manager. In addition, it provides a workspace similar to Query Analyzer, with the expected tools like the Language Parser and the Graphical Show plan. Now you can write queries and scripts and manipulate objects with Wizards and Property sheets in the same tool at the same time.

SQL Server Management Studio's interface has a separate Registered Servers view that allows you to work with multiple servers at the same time. You can do this in Enterprise Manager; however, SQL Server Management Studio allows you to register server instances as well as all Analysis Services, Reporting Services, SQL Server Integration Services, and Mobile SQL instances. Thus, you can obtain an enterprise view or concentrate on the particular instances and objects of interest.

2. Work with projects and solutions
If you have worked with Visual Studio, then you are familiar with the concept of projects and solutions. In a nutshell, projects allow you to group files together and access them as a unit. A solution is a series of projects, enabling you to drill down to projects just as OLAP users can drill down to the data dimension of interest.

A project can contain .sql, .mdx, .xmla, and .dmx scripts. You can also add other files (such as XML or CSV files) to a project. Therefore, the project itself is a drill-down object.

To create a new project, follow these steps:
1. Click File | New | Project.
2. Choose the type of project you want to create (SQL Server Scripts, Analysis Services Scripts, or SQL Mobile Scripts).
3. Give your project and solution a name.
4. Select the path where you want to store the files.
5. Click OK.

Now you can define various data sources (if your project touches more than one database) and add files effortlessly (simply right-click the Scripts folder in the Solution Explorer and select the items to add). You can also import scripts into a project if you have done some work already.

(If you don't see the Solution Explorer in your SQL Server Management Studio, select View | Solution Explorer or hit [Ctrl][Alt]L.)

3. The tool is a data analyst's best friend
Thanks to the integration of the OLAP tools, SQL Server Management Studio is a great tool for working with your cubes. The object browser allows you to access Analysis Services objects to graphically manage your cubes. It also lets you write and execute MDX and DMX and XMLA statements from within the editor window, allowing you to run both OLTP and OLAP queries from the same tool and even from within the same project.

4. You can display line numbers

How many times within Query Analyzer have you had to walk down the lines to count up to the line flagged with an error? With SQL Server Management Studio, you can display line numbers in the code editor, which is extremely helpful when you're parsing code to locate the problem line and inevitable typos.

This feature is not turned on by default. Here's how to enable line numbers:
1. Select Tool | Options.
2. Expand Text Editor in the Options Tree and select All Languages.
3. In the property pane on the right, select the Line Numbers check box under the Display heading.

There is one "feature" with line numbering. If you have batch statements in your script (Begin...End or Go statements), the results page will recalculate line numbering within the block (i.e., it will start counting from line 1).

5. It's easier to find errors
SQL Server Management Studio has retained one of our favorite features of Query Analysis: linking to errors in the body of your script from the error message in the Message pane. Note that the line number referenced in the error message may not correspond to the line numbering if a script contains multiple batches. You can, however, find the line causing the error simply by double-clicking the error (the red text) in the Message pane. This action will highlight the offending line in the body of the script. (You may want to use the pre-parse function with this feature to clean up all syntax errors before running a script.)

6. Get started faster with an expanded Template Explorer
Transact SQL is the language of SQL Server, and (as with other versions of SQL Server) you can perform all tasks from queries to object creation through Transact SQL. We like scripting objects primarily because it allows us to have absolute control over what we create, and we can save scripts to document objects and move them easily from a test to a production environment.

However, new features mean new syntax, and thus much more to remember. To make life easier, the SQL Server Management Studio includes an updated Template Explorer (View | Template Explorer or [Ctrl][Alt]T) that lays out the structure of more than 100 objects and tasks in Transact SQL, including administrative tasks like backing up and restoring databases.

Due to the integration of formerly disparate tools, the Template Explorer now includes templates for both Analysis Services and SQL Mobile commands. This means that you can drive DMX, MDX, and XMLA expressions through script templates the same way you could create objects in earlier versions of Query Analyzer.

7. It (sort of) plays well with previous versions
SQL Server Management Studio can run through the SQL Server Distributed Management Objects (DMO) as well as the SQL Management Objects (SMO), which are the preferred management objects for SQL Server 2005. This means that you can administer SQL Server 2000 and MSDE databases using the SQL Server Management Studio. This allows you to keep your databases in previous versions while administering them from SQL Server 2005. One caveat is that SQL Server Management Studio's version of DMO will not allow you to administer SQL Server 7.0 servers. You should consider this yet another good reason to upgrade.

8. Name that registered server
When registering our databases (both in Enterprise Manager and SQL Server Management Studio), we like to use an IP address rather than a server name; this approach facilitates remote connections across a VPN, and name resolution can sometimes be a problem. In Enterprise Manager, we had to remember the IP address for each particular server for which we work. For this purpose, we kept a text file listing all the connection parameters.

In SQL Server Management Studio, you can register by IP address but still give the computer a more recognizable name and even add a description of the server. The name and description will show up on the Registered Servers pane (View | Registered Servers or press [Ctrl][Alt]G), so you always know which server you are working on.

9. Manage your SQL Server Integration Services pages
Microsoft intended for SQL Server Management Studio to enable you to manage all services in one consistent UI, which is the case with the SQL Server Integration Services (SSIS). SSIS is the replacement for DTS in earlier versions of SQL Server and is also utilized by the new Maintenance Plan Wizard.

In SQL Server Management Studio, you can view all packages on a server and see which packages are currently running. You can also Import and Export packages using this tool (which is something that was not easy to do in earlier versions of SQL Server), and run packages from within the SQL Server Management Studio. To access SSIS through SQL Server Management Studio, follow these steps:
1. Register a server through the Integration Services tab in Registered Servers.
2. Right-click the Server and select Connect | Object Explorer.
3. Manage your packages through the tree that appears in the Object Explorer.

10. Keep tabs on your reports
As with Analysis Services and SSIS, you can use SQL Server Management Studio to manage your Reporting Services. In the SQL Server 2000 version of Reporting Services, all administration was carried out through a Web-based administrator that was installed as part of Reporting Services. If you managed several report servers, you had to manage each one through separate admin sites.

In SQL Server Management Studio, you can register all of your Reporting Services and administer them through the Object Explorer. You can also perform all tasks that were available on the Reporting Services admin site through the Object Explorer.

To access Reporting Services through SQL Server Management Studio, follow these steps:
1. Register a server through the Reporting Services tab in Registered Servers.
2. Right-click the Server and select Connect | Object Explorer.
3. Manage your packages through the tree that appears in the Object Explorer.

Conclusion
SQL Server 2005 Management Studio is a phenomenal advance over the tools provided with SQL Server 2000. We have gone so far as to remove the SQL Server 2000 tools, and we now do everything in SQL Server 2005. This version of SQL Server provides great leaps forward plus backward compatibility, which in our book is a winning combination.

12 common mistakes done by programmers

Most often, software developers seem locked into certain failure modes that can't be avoided and such is the frequency with which they fall prey to a particular poor programming practice.Peter Wayner of Computerworld writes about twelve most common programming mistakes, each of which is accompanied by its opposing pair. Below are the twelve programming pitfalls developers should stay away from.

Playing it fast and loose
Failing to prop up the basics is the easiest way to make errors in coding. There are a lot of small places where a developer may make a mistake which causes software to fail. And the worst part about sloppy programming is that advances in language design aimed to fix these problems don't do their job. There have been improvements in syntax in programming languages. For instance, the latest version of Java tries to make null-pointer checking easier by offering shorthand syntax for the endless pointer testing. But such syntax improvements can only prevent code from crashing. They don't eliminate the root of the problem: the proliferation of null values due to fast and loose programming.

Overcommitting to details
On the flip side, overly buttoned-up software can slow to a crawl. Relentless devotion to detail can even lock up software if the obsessive checking requires communicating with a distant website over the network. Here, the challenge is to design the layers of code to check the data when it first appears, which is much easier said than done.

Not simplifying control
Not simplifying control over tasks in their code may invite disaster for developers. The software assumes that if someone creates an object of type Name with two fields first and last, then it should immediately create a database table called Name with two columns, first and last. The names are specified in only one place, avoiding any problems that might come if someone fails to keep all of the layers of configuration in sync.

Delegating too much to frameworks
Sometimes the magic tools lead only to confusion. By abstracting functionality and assuming what we want, frameworks can all too often leave developers at a loss for what's gone wrong in their code. The rules are, while quite reasonable, not entirely trivial. As the app grows, it depends on more and more of these almost-trivial bits of external knowledge.

Trusting the client
Many of the worst security bugs appear when developers assume the client device will do the right thing. For example, code written to run in a browser can be rewritten by the browser to execute any arbitrary action. If the developer doesn't double-check all of the data coming back, anything can go wrong.

Not trusting the client enough
Sometimes too much security can lead paradoxically to gaping holes. Because of this, many Web developers are looking to reduce security as much as possible, not only to make it easy for people to engage with their products but also to save them the trouble of defending more than the minimum amount of data necessary to set up an account.

Relying too heavily on magic boxes
Many programmers assume they can link in the encryption library, push a button, and have iron-clad security. But many of these magic algorithms have subtle weaknesses, and avoiding these weaknesses requires learning more than what's in the Quick Start section of the manual.

Reinventing the wheel
Then again, writing your own libraries just because you think you know a better way to code can come back to haunt you. But grow-your-own cryptography is a welcome sight to attackers. Many libraries don't need to be perfect, so grabbing a magic box is more likely to be better than the code you write yourself.

Opening up too much to the user
Placing the onus on users to customize functionality they do not fully understand can invite disaster in the form of inadvertent security holes and privacy violations. When making purchasing decisions, most users can't handle the breadth of features offered by any given piece of software.

Overdetermining the user experience
Some developers decide to avoid the trouble of too many features by offering exactly one solution. But if users don't like the idea, they will look for ways to work around these limitations, and it will lead to an outcome that could translate into security vulnerabilities.

Closing the source
The decision to not distribute code works against the integrity of that code and it can discourage innovation and fixing bugs. Just opening up the code forces you to make the info more accessible, understandable, and thus better.

Assuming openness is a cure-all
While openness can make it possible for others to pitch in and, thus, improve your code, the mere fact that it's open won't do much unless there's another incentive for outside contributors to put in the work. Opening up a project can also add new overhead for communications and documentation. Moreover, a good open source project comes with extensive documentation of the API and road maps for future development.

10 mistakes every programmer makes

By Julian M Bucknall

When you start programming, you get disillusioned quickly. No longer is the computer the allinfallible perfect machine – "do as I mean, not as I say" becomes a frequent cry.

At night, when the blasted hobgoblins finally go to bed, you lie there and ruminate on the errors you made that day, and they're worse than any horror movie. So when the editor of PC Plus asked me to write this article, I reacted with both fear and knowing obedience.

I was confident that I could dash this off in a couple of hours and nip down to the pub without the usual resultant night terrors. The problem with such a request is, well, which language are we talking about?

I can't just trot out the top 10 mistakes you could make in C#, Delphi, JavaScript or whatever – somehow my top ten list has to encompass every language. Suddenly, the task seemed more difficult. The hobgoblins started cackling in my head. Nevertheless, here goes…

1. Writing for the compiler, not for people

When they use a compiler to create their applications, people tend to forget that the verbose grammar and syntax required to make programming easier is tossed aside in the process of converting prose to machine code.

A compiler doesn't care if you use a single-letter identifier or a more human-readable one. The compiler doesn't care if you write optimised expressions or whether you envelop sub-expressions with parentheses. It takes your human-readable code, parses it into abstract syntax trees and converts those trees into machine code, or some kind of intermediate language. Your names are by then history.

So why not use more readable or semantically significant identifiers than just i, j or x? These days, the extra time you would spend waiting for the compiler to complete translating longer identifiers is minuscule. However, the much-reduced time it takes you or another programmer to read your source code when the code is expressly written to be self-explanatory, to be more easily understandable, is quite remarkable.

Another similar point: you may have memorised the operator precedence to such a level that you can omit needless parentheses in your expressions, but consider the next programmer to look at your code. Does he? Will he know the precedence of operators in some other language better than this one and thereby misread your code and make invalid assumptions about how it works?

Personally, I assume that everyone knows that multiplication (or division) is done before addition and subtraction, but that's about it. Anything else in an expression and I throw in parentheses to make sure that I'm writing what I intend to write, and that other people will read what I intended to say.

The compiler just doesn't care. Studies have shown that the proportion of some code's lifecycle spent being maintained is easily five times more than was spent initially writing it. It makes sense to write your code for someone else to read and understand.

2. Writing big routines

Back when I was starting out, there was a rule of thumb where I worked that routines should never be longer than one printed page of fan-fold paper – and that included the comment box at the top that was fashionable back then. Since then, and especially in the past few years, methods tend to be much smaller – merely a few lines of code.

In essence, just enough code that you can grasp its significance and understand it in a short time. Long methods are frowned upon and tend to be broken up.

The reason is extremely simple: long methods are hard to understand and therefore hard to maintain. They're also hard to test properly. If you consider that testing is a function of the number of possible paths through a method, the longer the method, the more tests you'll have to write and the more involved those tests will have to be.

There's actually a pretty good measurement you can make of your code that indicates how complex it is, and therefore how probable it is to have bugs – the cyclomatic complexity.

Developed by Thomas J. McCabe Sr in 1976, cyclomatic complexity has a big equation linked to it if you're going to run through it properly, but there's an easy, basic method you can use on the fly. Just count the number of 'if' statements and loops in your code. Add 1 and this is the CC value of the method.

It's a rough count of the number of execution paths through the code. If your method has a value greater than 10, I'd recommend you rewrite it.

3. Premature optimisation

This one's simple. When we write code, sometimes we have a niggling devil on our shoulder pointing out that this clever code would be a bit faster than the code you just wrote. Ignore the fact that the clever code is harder to read or harder to comprehend; you're shaving off milliseconds from this loop. This is known as premature optimisation.

The famous computer scientist Donald Knuth said, "We should forget about small efficiencies, say about 97 per cent of the time: premature optimisation is the root of all evil."

In other words: write your code clearly and cleanly, then profile to find out where the real bottlenecks are and optimise them. Don't try to guess beforehand.

4. Using global variables

Back when I started, lots of languages had no concept of local variables at all and so I was forced to use global variables. Subroutines were available and encouraged but you couldn't declare a variable just for use within that routine – you had to use one that was visible from all your code. Still, they're so enticing, you almost feel as if you're being green and environmentally conscious by using them. You only declare them once, and use them all over the place, so it seems you're saving all that precious memory.

But it's that "using all over the place" that trips you up. The great thing about global variables is that they're visible everywhere. This is also the worst thing about global variables: you have no way of controlling who changes it or when the variable is accessed. Assume a global has a particular value before a call to a routine and it may be different after you get control back and you don't notice.

Of course, once people had worked out that globals were bad, something came along with a different name that was really a global variable in a different guise. This was the singleton, an object that's supposed to represent something of which there can only be one in a given program.

A classic example, perhaps, is an object that contains information about your program's window, its position on the screen, its size, its caption and the like. The main problem with the singleton object is testability. Because they are global objects, they're created when first used, and destroyed only when the program itself terminates. This persistence makes them extremely difficult to test.

Later tests will be written implicitly assuming that previous tests have been run, which set up the internal state of the singleton. Another problem is that a singleton is a complex global object, a reference to which is passed around your program's code. Your code is now dependent on some other class.

Worse than that, it's coupled to that singleton. In testing, you would have to use that singleton. Your tests would then become dependent on its state, much as the problem you had in testing the singleton in the first place. So, don't use globals and avoid singletons.

5. Not making estimates

You're just about to write an application. You're so excited about it that you just go ahead and start designing and writing it. You release and suddenly you're beset with performance issues, or out-of-memory problems.

Further investigations show that, although your design works well with small number of users, or records, or items, it does not scale – think of the early days of Twitter for a good example. Or it works great on your super-duper developer 3GHz PC with 8GB of RAM and an SSD, but on a run-of-the-mill PC, it's slower than a Greenland glacier in January.

Part of your design process should have been some estimates, some back-back-of- the-envelope calculations. How many simultaneous users are you going to cater for? How many records? What response time are you targeting?

Try to provide estimates to these types of questions and you'll be able to make further decisions about techniques you can build into your application, such as different algorithms or caching. Don't run pell-mell into development – take some time to estimate your goals.

6. Off by one

This mistake is made by everyone, regularly, all the time. It's writing a loop with an index in such a way that the index incremented once too often or once too little. Consequently, the loop is traversed an incorrect number of times.

If the code in the loop is visiting elements of an array one by one, a non-existent element of the array may be accessed – or, worse, written to – or an element may be missed altogether. One reason why you might get an off-by one error is forgetting whether indexes for array elements are zero-based or one-based.

Some languages even have cases where some object is zero-based and others where the assumption is one-based. There are so many variants of this kind of error that modern languages or their runtimes have features such as 'foreach loops' to avoid the need to count through elements of an array or list.

Others use functional programming techniques called map, reduce and filter to avoid the need to iterate over collections. Use modern 'functional' loops rather than iterative loops.

7. Suppressing exceptions

Modern languages use an exception system as an error-reporting technique, rather than the old traditional passing and checking of error numbers. The language incorporates new keywords to dispatch and trap exceptions, using names such as throw, try, finally and catch.

The remarkable thing about exceptions is their ability to unwind the stack, automatically returning from nested routines until the exception is trapped and dealt with. No longer do you have to check for error conditions, making your code into a morass of error tests.

All in all, exceptions make for more robust software, providing that they're used properly. Catch is the interesting one: it allows you to trap an exception that was thrown and perform some kind of action based upon the type of the exception.

The biggest mistakes programmers make with exceptions are twofold. The first is that the programmer is not specific enough in the type of exception they catch. Catching too general an exception type means that they may be inadvertently dealing with particular exceptions that would be best left to other code, higher up the call chain. Those exceptions would, in effect, be suppressed and possibly lost.

The second mistake is more pernicious: the programmer doesn't want any exceptions leaving their code and so catches them all and ignores them. This is known as the empty catch block. They may think, for example, that only certain types of exceptions might be thrown in his code; ones that they could justifiably ignore.

In reality, other deadly runtime exceptions could happen – things such as out-of-memory exceptions, invalid code exceptions and the like, for which the program shouldn't continue running at all. Tune your exception catch blocks to be as specific as possible.

8. Storing secrets in plain text

A long time ago, I worked in a bank. We purchased a new computer system for the back office to manage some kind of workflow dealing with bond settlements. Part of my job was to check this system to see whether it worked as described and whether it was foolproof. After all, it dealt with millions of pounds daily and then, as now, a company is more likely to be defrauded by an employee than an outsider.

After 15 minutes with a rudimentary hex editor, I'd found the administrator's password stored in plain text. Data security is one of those topics that deserves more coverage than I can justifiably provide here, but you should never, ever store passwords in plain text.

The standard for passwords is to store the salted hash of the original password, and then do the same salting and hashing of an entered password to see if they match.

Here's a handy hint: if a website promises to email you your original password should you forget it, walk away from the site. This is a huge security issue. One day that site will be hacked. You'll read about how many logins were compromised, and you'll swallow hard and feel the panic rising. Don't be one of the people whose information has been compromised and, equally, don't store passwords or other 'secrets' in plain text in your apps.

9. Not validating user input

In the good old days, our programs were run by individuals, one at a time. We grew complacent about user input: after all, if the program crashed, only one person would be inconvenienced – the one user of the program at that time. Our input validation was limited to number validation, or date checking, or other kinds of verification of input.

Text input tended not to be validated particularly. Then came the web. Suddenly your program is being used all over the world and you've lost that connection with the user. Malicious users could be entering data into your program with the express intent of trying to take over your application or your servers.

A whole crop of devious new attacks were devised that took advantage of the lack of checking of user input. The most famous one is SQL injection, although unsanitised user input could precipitate an XSS attack (crosssite scripting) through markup injection.

Both types rely on the user providing, as part of normal form input, some text that contains either SQL or HTML fragments. If the application does not validate the user input, it may just use it as is and either cause some hacked SQl to execute, or some hacked HTML/JavaScript to be produced.

This in turn could crash the app or allow it to be taken over by the hacker. So, always assume the user is a hacker trying to crash or take over your application and validate or sanitise user input.

10. Not being up to date

All of the previous mistakes have been covered in depth online and in various books. I haven't discovered anything new – they and others have been known for years. These days you have to work pretty hard to avoid coming into contact with various modern design and programming techniques.

I'd say that not spending enough time becoming knowledgeable about programming – and maintaining that expertise – is in fact the biggest mistake that programmers make. They should be learning about techniques such as TDD or BDD, about what SLAP or SOLID means, about various agile techniques.

These skills are of equal or greater importance than understanding how a loop is written in your language of choice. So don't be like them: read McConnell and Beck and Martin and Jeffries and the Gang of Four and Fowler and Hunt & Thomas and so on. Make sure you stay up to date with the art and practice of programming.

And that concludes my top 10 list of mistakes programmers make, no matter what their language stripe. There are others, to be sure, perhaps more disastrous than mine, but I would say that their degree of dread is proportional to the consequences of making them.

All of the above were pretty dire for me the last time I made them. If you have further suggestions or calamities of your own, don't hesitate to contact me and let me know.

Three ways to minimize your project budget exposure

Date: November 19th, 2010
Author: Brad Egeland

Keeping the project budget in line is one of the most difficult things that a project manager does — and yet it's a huge factor in determining the overall success of the project when the engagement winds down. The goal is to keep the budget in line throughout the project and avoid falling into emergency mode at any point with a huge overrun.

The three processes I'll talk about here are extremely helpful to me as I try to keep my project budgets in check. Developing good processes and habits will help you significantly reduce the likelihood that your project budget will turn into a catastrophe. Let's review each of the three ways that will help you minimize your project budget exposure.
Review and revise the project budget at least weekly

The first thing you can do to protect your project budget is probably the easiest thing you can do, and it's definitely the least invasive thing you can do. Get weekly information from Accounting concerning the charges to your project and revise your information diligently every week. This may seem simple, even mundane. But it always amazes me how many project managers get lazy and let this slide for a week or two and then, eventually, longer. "Hey, it wasn't a problem three weeks ago and nothing significant has happened on the project, so why should my budget be in jeopardy now?"

Well, little things build up — and they can build up fast. Stay on top of the budget; don't let a week go by without comparing forecasts to actuals and reforecasting, if necessary. It's much easier to fix a 10% budget overrun now before it gets out of control than it is to fix a 40% budget overrun a month from now after it's already out of control. And which one is management going to be more pleased about hearing? Which one will the customer be more understanding of and more flexible about?
Make your project budget high profile

This is also a fairly easy process and has worked well for me. If your organization is a matrix organization with everyone working on multiple projects at once, it works even better. Here's the scenario:

You are a project manager running five projects at once. On average, each of your technical team members are on three different projects at the same time. In all honesty, 80%-90% of all employees calculate their project charges for the week at the last minute, usually on Friday. Very few accurately document their time during or at the end of each workday.

We all remember most of what we did in a particular week, but there are always those four or five hours of activity that we really can't pinpoint. We know we worked 50 hours that week, but can accurately account for only 45 of them. Those hours have to go somewhere, but where? They go to the project where they'll be least noticed–the project that we know is not being monitored closely.

So don't let that be your project. Make sure your team members know you're watching your project budget — and the hours that they charge to it — like a hawk. Discuss the budget with them at every weekly internal team meeting and give them a status update on how the project budget is standing up to the original forecast. Share your concerns with them. Periodically question them on charges just to keep them on their toes. Don't be accusing, just ask them questions about the charges and the work that was being performed. If they know you're that aware, it's highly unlikely that any of your projects will be recipients of the "gray" hours at the end of each work week.
Manage scope closely

This is probably the hardest one to do and can have the most devastating affect on the project budget. The problem here can be two-fold. You have the issue of managing the project scope from your project manager perspective and negotiating changes and change orders with the customer. But you also have the task of managing your project team members closely as they work with the customer.

On at least a third of my projects I've run across potential scope issues through discussions I've had with my project team members who were in close communication with the customer. Those team members develop a relationship with the customer, which results in their agreeing to any small request the customer makes. This "small" request ends up costing your developer a few hours (which can mean a few thousand dollars) of your precious project budget.

Inform your team members, warn them of these kinds of situations, and then, when you meet with them every week, ask them about any customer requests that may have been made in the interim.

How to market your internal IT department

Date: November 22nd, 2010
Author: Patrick Gray

Marketing their organization is something most CIOs spend little time considering. While no one likes a shameless promoter, many of the most successful IT organizations I have worked for actively market themselves around the corporation, even if they may not use the term "marketing" to describe their activities. Without some element of marketing, IT will often be neither seen nor heard, unless summoned, save for the rumor-mill rehashing of its most recent stumble or failure. With some simple marketing efforts, the company as a whole can be reminded of the services IT can offer, informed of recent successes, and be seen as a home to thought leadership on technology. Here are a few simple ways to market your internal IT organization with little to no marketing budget and a minimal investment of time.
Change your attitude

The most effective leaders in any organization are those who can sell their vision. While it may seem crass to call every great leader an effective salesperson, it is largely true. Effective leaders can pitch their point, expound on the benefits that are most likely to appeal to the current listener, and then "close the deal" with the support of much of the organization.

This "sales" attitude permeates everything from management presentations, to structuring organizational efforts that appeal directly to potential "customers." IT especially is a group that peddles ideas, and considering every interaction with other business units as a chance to pitch your most compelling ideas can do wonders for how you structure a proposal and present its benefits. While something like enterprise software might affect the whole organization, a change in attitude will cause you to present the package differently to operations than you might to finance and will cause you to have laser-like focus on appealing to the listener's interests, rather than self-centered technical discussions or questionable and unconvincing "benefits."
Drop the jargon

The most effective marketing reaches us in a language we can easily understand. The same product description will use different language and imagery when targeted at one group versus another, but in each case will appeal to those groups in their own terms. While we in IT may get excited by talk of virtualized cloud services and ITIL frameworks, the people impacted by these technologies usually care less about the fancy verbal footwork and simply want to know how their working lives will be improved by what we are peddling. When we can separate the benefits from the technologies that deliver them and effectively articulate those benefits, then IT will be best presented and most easily accepted and embraced.
Become a thought leader

Technology, especially in the consumer space, is changing at a record pace. Most of us have been cornered and asked for an opinion on some new gadget or technology making the press's rounds. Rather than waiting for these ad hoc "hallway moments," publish an informal newsletter that talks about some of IT's recent successes and addresses current technology trends. There's no shame in having a young staffer who is passionate about the latest mobile technology pen a couple of paragraphs about how Android could affect the company or about some apps that could help the iPad become a productivity tool. If you as CIO are not presenting this information, executives may be looking to teenage children or staffers outside IT, making corporate IT look like a dated dinosaur rather than a trend spotter.

An IT newsletter need not be an overwrought, ten-page affair with marvelous graphics. It can start as a simple four or five paragraphs that are e-mailed to a handful of colleagues. The best are informal and informational that address the concerns of readers. Ask a trusted colleague or two what technologies they are following and interested in learning more about. Combine this with short and subtle promotional features about IT's recent successes, and you have a winning formula that presents IT as competent and knowledgeable. Old-fashioned e-mail is usually a better tool than a blog buried on an internal Web site that few will read, and if you are comfortable with it, self-effacing humor and an informal style will gain more readers than a staid yawner that reads like a master's thesis.

While marketing is probably one of the last things you thought you would need to worry about as an IT executive, any organization, whether it is a Fortune 100 company or an IT department of five people at a small company, can benefit from being presented in the best possible light. Dedicating four or five hours each month to these activities can build trust in the IT department, improve its image, and even make the next budget-approval process far less painful.

Five tips for teaching database concepts to clueless users

Author: Susan Harkins

Investing a little time in helping your users understand database fundamentals will make them more productive and self-reliant. Their understanding and insights may even help you improve your applications.

If you're managing or developing custom applications, chances are you have a few users updating at least one database. These users need to know how to interact with the database, but they don't need to understand what's going on behind all those forms, right? Actually, a little knowledge in concepts could lead to improvements in performance, efficiency, and even value-added features that often, only the users down in the trenches can fully appreciate. A basic understanding of database concepts can help otherwise-clueless users offer innovative suggestions and even point out potential hotspots before they turn into real problems.
1: Hire someone with an expertise in teaching beginners

You might have been the professor's favorite student, but that doesn't mean you're a good teacher. Teaching database concepts to most users isn't for the faint of heart. Users aren't stupid. In fact, many are not only able but also quite eager to learn. You just need easy-to-understand examples and scenarios. And for better or worse, most developers and managers just don't think that way. Your would-be scholars don't care about Codd or cubes — one will bore them, the other will totally undermine their confidence! If you really think you can do it, go ahead and try, but be mindful of that deer-caught-in-headlights stare. It means they don't understand you, not that they're stupid.
2: Work with associations

It's okay to acknowledge E.F. Codd, but your goal is to introduce users to relational database theory and possibly even the SQL language. You could easily provide slides of bulleted rules and guidelines, but don't. Information provided that way won't mean much to most users. Instead, take advantage of their familiarity with other common tools, such as spreadsheets and file cabinets. You know that a spreadsheet is not a database, but a sheet is a good way to introduce rows as records, columns as fields, and sheets as tables. Compare what they already know to what they have to learn. You might think this method is old and worn out, but don't push it aside just because it's old. It's old because it works.
3: Avoid development tools while learning

You'll probably want to use an actual database while teaching concepts to run simple examples. Although you could supply a set of client management tools, don't. All you'll do is teach your students bad habits — habits that rely on a specific set of management tools rather than concepts. It's important that your students understand the basics before they learn to interact with the data via visual tools. If you want to apply examples to data, use a command-line interface. In the long run, learning how to type query requests directly will benefit them far more than learning how to use a specific set of tools. Once your students understand the concepts, then introduce them to the visual interface tools.
4: Use familiar data

Your users are already working with data that in some way relates to your business. If possible, work with simple examples that rely on that familiar data. It may not seem like much to you, but you'll eliminate time needed to introduce example data and give users a boost up the learning curve.
5: Set aside enough time for implementation and study

Your users won't retain much if they don't have an opportunity to put what they've learned into action. Assign additional time outside of classroom training for individual experimentation and further learning. Assign homework by presenting a real-world problem and give students a little lab time to find a workable solution. I realize that it might be difficult to get upper management to agree to this request, but nothing can replace hands-on experience.

Five tips for securing mobile data

Author: Shun Chen

As more and more company data moves onto mobile devices, IT faces a host of new security concerns. Here are some issues to consider as you develop your mobile security model.

More and more corporate data is being moved onto mobile devices through email and cloud-based mobile applications, so securing mobile data is becoming increasingly critical. However, traditional security models break down when it comes to mobile. Mobile devices can't be managed autonomously by IT because IT can't enforce upgrades or install applications or programs without the end users' consent. Therefore, an effective mobile security model needs to be based on visibility and mitigation, not command and control. Based on our experience working with enterprises around the world, here are five tips for securing your mobile data.
1: Ensure visibility

The request to get email on new devices such as iPhones and iPads often comes from the CEO, and IT responds by turning on ActiveSync. However, the problem is that once you've turned on ActiveSync, anyone can get onto the network. As different mobile platforms provide different capabilities for device security and control, the first step in mobile security is to find out exactly who is accessing your network and what devices they are using to do so. Then you want to be able to set access control policies that can determine whether to allow or block access based on hardware type, OS version, or compliance status. ActiveSync is a great technology to set some baseline controls, but it's important to complement it with the right tools to ensure the security of your network.
2: Make sure you can do the basics

Any mobile device management and security technology you evaluate needs to be able to handle core mobile security functions:
Remote lock and wipe
Password policy
Encryption monitoring
Jailbreak and root detection
Device restrictions, such as denying access to certain apps (e.g., password spoofers) and explicit content

Keep in mind these are the minimum requirements that should be on your checklist.
3: Create clear policies and communicate them to employees

One major decision that many enterprises are struggling with today is whether they should allow employees to use their own devices. Whether the phone is owned by the company or the employee, it's inevitable that it will end up with both corporate and personal data on it. Therefore, it's essential to actively communicate your data security policies to your employees and to make sure that the information is in a place where it can be easily found. You will need to make decisions about two big areas. The first is how you handle personal versus corporate data — for example, what gets stored or archived on company servers, such as SMS? What gets wiped or removed if an employee violates policies? The second area of concern is privacy and who sees what. Regardless of your policy, the most critical factor to consider is transparency. It should be easy for an employee to find your corporate data security and privacy policies. They should know exactly what IT tracks, monitors, and archives. Then they can make decisions about their own device usage.
4: Make sure you're securing everything — not just email

Mobile security is no longer just about email. Through the use of mobile apps, more and more company data is moving onto mobile devices, so you need to have visibility into apps, as well. You must have a central view of all the apps employees are using, and you need to be able to blacklist apps that pose a threat to security or compliance.
5: Stay flexible

It's important to remember that enterprise mobility is really new. Be prepared to evolve because everything will keep changing. New OS releases will have new features and functionality. New devices are going to keep coming (consider  the iPad-led tablet computing wave), and there will be more mobile apps and data to secure. You need to be alert to all of these developments because many will have implications for the policies you've established. The most important thing is to maintain complete visibility into your mobile environment and regularly evaluate your security policies to make sure they align with your mobile reality.

Shun Chen is director of product management for MobileIron.

Five tips for designing a small business network

Author: Brien Posey

When you design a network for a small business, you have to address different issues from those you face in an enterprise environment. Brien Posey offers some tips for handling the special considerations that come with the SMB territory.

Over the years, I have designed numerous networks for various organizations. In doing so, one thing I have learned is that you have to use a different mindset when you are designing a small business network than you would use when developing an enterprise grade network. Here are five simple tips to keep in mind when you build a small business network.
1: Determine whether you want to host services locally or in the cloud

I have to admit that I have never been a big fan of hosted services. Over the last year, I have received letters from several network administrators who have found themselves unemployed after the companies they worked for began outsourcing network services to cloud providers. Even so, using hosted services may be ideal for smaller organizations.

Cloud service providers take care of configuring, maintaining, and backing up network services. An organization that is using a hosted service may not need a dedicated IT staff. Hosted services may also save smaller organizations from having to make a large investment in server hardware and software. Instead, they can pay a monthly subscription fee. Over time, the subscription fees can add up to more than the cost of purchasing server hardware and software, but the startup costs are much lower.
2: Look for ways to control costs

Small businesses typically have to watch every penny, so if an organization does decide to host its own network, it's important to look for ways of controlling costs. Using server virtualization is one obvious way of reducing the costs of server hardware, but sometimes you have to get a little creative. For example, in extreme situations, you may have to settle for using high-end PCs instead of true server hardware. Likewise, you may be able to control costs by using Linux operating systems instead of Windows.
3: Have a support plan in place before you need it

Small businesses often lack the resources to deal with any major technical issues. When I have done consulting projects in the past, I have found that a lot of small businesses don't have a dedicated IT staff. They often have one employee who knows a little bit about networking and becomes the go-to person for computer problems.

I have also seen a few small businesses hire someone to provide full-time IT support. In these situations, though, budgetary limitations have prevented the organization from hiring someone with a lot of experience.

Don't get me wrong. I'm not bashing the way small businesses do things. Organizations have to work within their financial limitations. But problems will occasionally occur that are beyond the staff's abilities to fix. So organizations should have a plan in place ahead of time for how they will deal with such problems when they occur. These plans might involve calling a technical support line or bringing in a consultant. Regardless, when you build a network for a small business, be sure you take up the issue of long-term support with the company's owner.
4: Plan for future growth

When you design a small business network, remember that the business may not stay small forever. Make sure you design the network in a way that allows for growth.

I have known consultants who automatically use Microsoft's Small Business Server 2008 any time they build a network for a small business. I don't deny that Small Business Server is a good choice for some organizations, but it has a limit of 75 client access licenses. Furthermore, it does not allow for the creation of child domains or inner forest trusts. The products that make up Small Business Server are not licensed in a way that allows them to be installed on separate servers.

So while Small Business Server may be a good choice for an organization with 10 employees, an organization that already has 50 employees could end up outgrowing Small Business Server fairly quickly. It may be better for such an organization to spend a little extra money up front so that it doesn't have to pay for an expensive migration later on.
5: Never underestimate the importance of a good backup

I couldn't even begin to guess how many times I have done consulting projects for small businesses only to discover that they had no backup or that their backups were inadequate. (Running a backup every Friday night just doesn't cut it.) When you design a small business network, disaster recovery planning should be part of the design process, not an afterthought.

25 Ways to Speed Up your Website

By Justin Palmer - December 4th, 2007

Speed kills. In the case of website usability, the lack of speed kills. Many have erroneously assumed the advent of high speed internet connections would make website performance optimization irrelevant. On the contrary, it seems as internet connection speeds increase, users simply become more impatient and demand faster browsing. Below, some simple (and advanced) ways to speed up your site.

Before making any changes, I would recommend benchmarking your download time with WebSite Optimization's webpage optimization tool.

Image Optimizing Tips:

1. Compress .jpg and .gif images: If you use photoshop, always use the "Save for Web" feature. If you don't have access to PS, there's a ton of free image compressing freeware out there.
2. Compress or eliminate unnecessary Flash elements: In my opinion, flash is over-rated, slow, and buggy. It has it's benefits, but make sure you don't rely on it for navigation or other necessary site elements.
3. Don't Resize Images within HTML: Don't use the width or height attribute in the IMG tag to resize larger options. For example, if you resize an image that was originally 300 x 300 to 100 x 100, the user still has to download the full size one. Instead, use thumbnails.
4. Specify Image Dimensions: Don't leave the width or height attributes blank. By doing so, you'll slow down the browser rendering of the page, since it doesn't know how much space to give for each image.
5. Slice Your Images: Slicing doesn't actually reduce image size (in fact, it increases the overall size). However, it does increase the apparent load time by making each slice appear one at a time rather than one big image popping up after it downloads.
6. Avoid Too Many Slices: Don't use too much of a good thing. As mentioned above, each slice actually increases the total size. I would recommend using no more than 4 slices, unless you are dealing with a huge image.

Coding Tips

7. Use CSS instead of Images: Cascading style sheets can do more than you think. Many sites make effective use of CSS formatting and eliminate the need for excessive images. Even effective brand logos can be created with CSS. CSS Zen Garden has some examples of creative use of CSS.
8. Convert from Table to CSS based layout: Tables are ok for displaying data in columns and rows, but is grossly inefficient for designing web page layouts. By using DIV tags with CSS, you can cleanup your code extensively, which will reduce page load time and also offer SEO benefits.
9. Use External Style Sheets: Rather than formatting through embedded inline styles in pages or html elements, reference an external css files that the entire site can reference. The browser will cache this page on the first visit, so it won't need to download it repeatedly.
10. Use External Javascript: Simliar to above, put all of your JavaScript functions in an external file for caching benefits.
11. Remove Unnecessary White Space in HTML: Surprisingly, white space hogs
    a lot of disk space. Remove unnecessary space and other code clutter with this handy tool called HTML Tidy.
12. Use Shorthand CSS: Instead of putting each CSS attribute on its own line, use shorthand CSS to prevent extra line breaks in your external CSS file.
13. Use CSS Images instead of IMG tag: An easy way to speed up the rendering of an image is to simply call as a background of a div tag.
14. Use Relative Links: Removing the " http://www.yoursite.com " from the beginning of every link will shed some weight. Just be careful not to allow people to jump back and forth between secure and insecure pages, which will generate one of those annoying "insecure items" errors in the
    browser.
15. Specify the DocType: Pages that have the DocType specified tend to load faster than those that don't.

Server & Database Tips

16. Reduce Http requests from other sites: Try to eliminate connecting to other servers to retrive images, audio, or video. Each http:// connection only slows things down.
17. Don't Use Https://: Don't use secure pages if you don't have to. Connecting through secure http is about 3 times slower than regular http. Obviously, your checkout process needs to be secure, but your product pages most likely do not. In addition, make sure your navigation doesn't use relative links which forces users to flip flop between secure and non-secure pages.
18. Upgrade your Web Server: Just like that old PC you bought 5 years ago, web servers can go down hill and become outdated.
19. Use Gzip Compression to Reduce HTML Size: Gzip is great for compressing html code, however it does nothing for images, flash, or other embedded files. Many open source programs such as Wordpress and Joomla already support it.
20. Upgrade Server Memory: A boost in memory resources on your server can reduce processing time and greatly increase performance.
21. Upgrade your Database Server Hard Drive: The faster your server's hard drive is able to access data, the faster it can serve up files. A fast hard drive is especially important for your database server.
22. Separate Content and Database Servers: If you have a high traffic, database driven website, you can benefit by placing your content on one server and your database on another. In addition to the speed benefits, it is more secure.

Other Tips

23. Loading Progress Indicators: By letting users know that you are processing their request, you can assuage their impatient fears. This won't necessarily speed things up, but it will update them on the progress.
24. Use AJAX instead of Page Refreshes: Interacting with a web page is far different than interacting with your computer OS. Imagine if Windows XP had to refresh the whole screen ever time you perform an action like websites do? In the next few years, we will probably see more adoption of AJAX technology, which will make page refreshing uncessary.
25. Reduce Size & Number of Cookies: Each time a browser makes a request, cookies must be transmitted. Keep an eye on the total number and size of the cookies your site uses.

Four steps for selecting your development technologies

Author: Justin James

One my friends is thinking about starting a programming project, and he asked me "how do I pick my technologies?" with an eye towards performance as well as getting the project done. This person has been writing code on and off for a while, but he hasn't worked on any substantial projects. He isn't wedded to any particular technology, and he has the luxury of a clean slate for this project. While he does have a preference for deploying to Linux due to his experience with it, this is not a final decision.

In this column, I share the advice I gave him. I am not going to recommend any particular technologies, but rather show you my approach for making technology and architectural decisions.

Step 1: Loosely design your application

Agile methodologies have become very popular, and some folks believe that means you don't try to think beyond a two week timeline. But there is a lot of value in preparing a loose design of your project. All you need to do is use a tool that has flowchart capabilities (such as Visio) to provide a high level overview of the logic. You do not need to get bogged down in details like "validate that this field contains at least five characters" or data layouts. But you do need a general idea of what parts of the application will be handling what responsibilities.

Some examples of things that should appear in this diagram include:

• Any major batch processing tasks.
• Where data is stored (files, databases, "the cloud," etc.) and which components retrieve it and expose it to the rest of the application.
• Where significant processing occurs (in the database, in a business logic layer, a Web service, the client, and so on) and what it does.

Step 2: Identify resource usage and characteristics

Once your diagram is complete, we can use it to identify resource usage. The resources that you want to be aware of are CPU, RAM, drive space, and bandwidth. Are you transferring a large amount of data to or from an external Web service? That is going to be a bandwidth resource on the connection between your application and that service. Perhaps you are doing an intense calculation within your database — that would be CPU use within the database. And so on.

Step 3: Determine performance critical areas

Once you know where the resources will be used, you have found your potential performance bottlenecks. These are the places where your technology choices will have the biggest impact. If it turns out that you are storing very little in a database, you have more options for the database. Perhaps you will be performing CPU heavy algorithms in the business logic layer, which points out that you will need a language and platform that supports high-speed calculations. This is a chart I've made which will help you see how this affects your decision making.

	CPU	RAM	Disk space	Bandwidth
Database	DB must be a high performance system like PostgreSQL or Oracle.	All major databases should be able to work with lots of RAM.	Skip the low-end DBs with size limits, like SQL Server Express.	Locate your application in the same server room as the database.
Business layer	Language must be fast, and may need excellent multithreading support.	N/A	Locate the application in the same server room as the disks.	Locate your application in the same server room as the database.
API that you expose to clients	Language must be fast, and may need excellent multithreading support.	N/A	Reconsider your architecture.	Reconsider your strategy.
Client-side software	Language must be fast, and may need excellent multithreading support.	Carefully consider your target market and their client capabilities.	Carefully consider your target market and their client capabilities.	Ensure that target market has the bandwidth (don't sell to consumers in rural areas, for example).
Third-party service	Pick vendor carefully.	N/A	Choose a vendor with low cost storage.	Reconsider your strategy.

Step 4: Scale your needs

Another thing that you can learn from your diagram is where your application needs to scale. If the bulk of your processing needs occur in the client piece of the application, your server architecture can be much more modest, for example.

You will also be able to see what kind of scaling you need. Most databases have clustering capabilities, so if you have a choice, it is often easier and better to push things that need to scale (especially if they require a shared state between requests) into the database where scaling is already handled, or to consider technologies higher up in the stack that also have clustering or scaling built in.

Conclusion

By starting your development process with a lightweight sketch of the application's logic, you will be on the right path to select the best technologies for your needs. There are lots of non-technical considerations (such as your budget, experience in particular technologies, and so on), but you need to start somewhere, and this decision making process will help you narrow down your choices and highlight any problem areas before they come up.

I'd love to hear from you in the comments section below to get your experiences with these kinds of issues.

J.Ja

Fixing a hang while opening ASPX files in Visual Studio

Author: Justin James

The strangest bug I've seen all year was with Visual Studio, a program that I ordinarily find to be quite stable and reliable, at least in versions 2008 and 2010. The problem that I faced was that, every time I opened an ASPX file from a particular solution, Visual Studio would hang and give the dreaded "Visual Studio is busy" error message. Usually when you see this error, it is a one-time event, and it really means "Visual Studio is dead." In this case, though, if I left it alone for 5 to 90 minutes, the program would suddenly come back to life.

Digging deeper into the problem, I discovered all sorts of clues, but nothing that lead to a solution. These are some of the things that were happening:

• It would hang when adding an empty ASPX to the solution.
• It would hang if you opened an ASPX in that solution directly from Windows Explorer.
• It would hang if I copied the solution's contents outside of my TFS working directories.
• It did not hang with any other projects.
• It hung on Visual Studio 2010 on another person's machine, but not on a third developer's machine (the one who had originally been working with the project).
• When it was hung, CPU usage was 0%, RAM usage was not changing, and there was no network traffic occurring, so it did not look like an ordinary deadlock.
• The problem was random; sometimes you could open an ASPX file just fine, and other times the hang would occur.
• The problem would not occur if I copied one of the "problem ASPX" files outside of the solution's file structure and opened it.

I ruled out TFS issues, problems specifically with a reference to a particular Web Part, a library, or the Master Page, or issues specific to those ASPX files, since the problem would come up even with a blank ASPX file.

After a few days of being completely paralyzed by this problem (the project had been handed off to me, and we had a ton of things for me to do), I eventually opened a ticket with Microsoft. It pains me to do this because I'm admitting that I can't solve the problem. In this case, there were so many different reasons to see this message, and none of them quite fit my situation, that it was simply quicker to engage Microsoft. And given what my time is worth to my employer and what a Microsoft ticket costs, the ticket is usually a bargain compared to wasting my time.

The Microsoft technician I worked with was quickly stumped. We went through all of the scenarios where it would occur and where it wouldn't. Eventually, he worked with me to generate a dump file. The very next day, he found the problem!

Visual Studio's Design mode requires that the components on a page be initialized so that they can be rendered properly. Some of the components on some of the pages were trying to access a database that was not available from my machine (or the other machine with the problems) during their initialization. When these components underwent initialization, Visual Studio would hang trying to connect to the database, and it would hang for a very long time instead of having a timeout around that initialization. In addition, Visual Studio will pre-initialize components, and that is why it was hanging even when working with an empty ASPX file.

Lesson learned

I am passing on this information in case any TechRepublic readers encounter this bug. If opening ASPX files hangs Visual Studio (versions 2008 or 2010), look carefully at the initialization code of the components in your project because this could very well be the culprit.

I hope this helps someone else before they lose days of work to this issue.

J.Ja

Five tips for solving software problems

Date: October 18th, 2010
Author: Chip Camden

When you're trying to troubleshoot a problem with your software — especially if the client isn't being at all helpful — these tactics will help you zero in on what's going wrong.

---

Do you ever have trouble getting information out of your clients? Even when they could give you that information with just a little effort?

"It's broken," the client said.

"Broken?" I responded. "In what way?"

"It's not doing what it's supposed to do."

"Could you describe for me what it's supposed to do that it isn't?"

"You know — it compiles fine, but when you run it, it just dies."

"Dies how?"

"It gets an error and quits."

"What's the error message?"

"I didn't write it down."

Naturally, the problem doesn't reproduce on my test system. So I have to keep the client involved at least enough to give me access to their system. The client, however, doesn't want to be involved. They just want it fixed. Without saying so, they're probably thinking "Doesn't this software quack ever test this stuff? We're paying him the big bucks just to have this blow up in our users' faces and then paying more to have him fix it!" They're not feeling at all like helping me, but I really need some information if I'm going to help them, because when I try it on their system it doesn't reproduce there, either.

Most of my clients are software developers, and it puzzles me how frequently they plop huge haystacks of code in my lap and ask me to find the needle. I often try to teach them good problem-solving techniques — you know, teach a man to fish — but I'm amazed at the resistance I sometimes encounter. Oh well, more billable hours for Yours Truly.

Here are some general problem-solving techniques I use. Many of these apply to all sorts of problems, not just software bugs.

Note: These tips are based on an entry in our IT Consultant blog.

1: Make it smaller

Distill the problem down to the minimum amount of code required to reproduce it. Eliminate anything extraneous. Why go to all that trouble? One of the easiest ways to find the needle in the haystack is to get rid of most of the haystack. Sometimes, the problem goes away when you cut something out, which should give you an idea where it's hiding. Besides, if you get into an iterative debugging cycle, you'll be able to cycle much faster with less code and fewer steps.

2: Question your assumptions

I had a client call me the other day to report a problem in which static data was supposedly being modified by a return statement. Ah, I know what you're thinking. But there were no objects involved in this code, so no destructors were being called. To believe him would mean that there was a horrible bug in the runtime environment for the language he was using, which didn't seem at all likely to me. So I asked him how he examined the data before and after the return. The data was stored in a library module for which he did not have debug symbols, so he added calls in his code to a standard routine to query the data. But he didn't realize that this routine (in the way it was called) also had the unfortunate side effect of modifying the data, creating an instant Heisenbug. He had been moving these calls around, trying to isolate the statement that changed the data, when the debugging statement itself was doing just as much damage.

3: Beware of false causation

How many times have you heard, "The only thing that changed is X, so the problem must be related to X." No, no, no, no, no, no, NO! More than half the time, something else changed that they forgot about — or didn't even know about. When the "obvious" cause turns out to be a red herring, or even before, I always echo the famous words of Sgt. Schulz: "I know nothing… NOTHING!" Okay, so it's intended more in the spirit of Socrates. But no cause should be assumed until proven. That doesn't mean you shouldn't check out your hunches first, though. We have intuition for a reason.

4: Start at the result and work backwards

I often see programmers start a debug session and then step through routine after routine, examining variables along the way, hoping to stumble across the moment when things go wrong. Usually that doesn't work at all, because problems have a knack for resulting from seemingly innocuous beginnings. It may seem counterproductive because code doesn't execute backwards, but it's more efficient to start at the moment of the failure's epiphany (an error message, for instance) and examine what's wrong at that instant. Then go back to the code that led up to that point to see where it went wrong, backing up routine by routine until you find the culprit. Ideally, debuggers should be made able to step backwards, but even if you have to restart your debug session a hundred times, you'll save time over trying to perceive the cause from the top.

5: Refactor

Sometimes, the complexity of the situation is part of the problem. Maybe the definition of what the "plugh" function does is not entirely consistent, and that's what's leading to a failure. By simplifying and clarifying the design, those inconsistencies often reveal themselves. But use this judiciously — once you get started down that road, you might not be able to stop for a long, long time.

Five tips for working efficiently in the Visual Basic Editor

Date: October 4th, 2010
Author: Susan Harkins

If you spend much time in the VBE, you'll appreciate any shortcuts that streamline your work. Susan Harkins shares the tricks she finds most useful.

---

When you add code to an Office application, you do so in the Visual Basic Editor. That's where you'll find all the tools you need to write and manage your code. There are numerous shortcuts and tricks for working in the editor, but here are the five I seem to use the most.

1: Copy quickly

Copying portions of procedures (or entire procedures) is a common task for many developers. You can select the code, right-click the selection, and choose Copy, pretty much the same way you'd copy anything in a Windows application. But you can save a few steps using drag and drop. Select the code you want to copy, hold down the [Ctrl] key, and drag the selection. You can even drag from one module to another. Simply open and restore the modules so they're both visible. Then, drag code from one and drop into the other. You can also use drag and drop to move, rather than copy, code. Hold down the [Alt] key while dragging.

2: Double-click title bars to dock and float

To move a docked window, just double-click its title bar. Doing so toggles the window between the docked and floating state. A quick double-click restores the window to its last docked position.

3: Avoid docking madness

Many tips for redocking a window are a bit awkward. The truth is, there are only two easy steps:

• Right-click the window and check Dockable (if necessary).
• Using the title bar, drag the window to the appropriate border.

Here's the secret: The VBE will redock the window when the cursor (the white arrow) — not the window's border — touches a border. In addition, when docking, the VBE will stretch the window between opposite borders, either horizontally or vertically. Dock to the left or right border to dock vertically. Dock to the top or bottom borders to dock horizontally. Even if you're heading toward the left border, if the pointer touches the top border first, the VBE will dock the window horizontally.

4: Get the Project Explorer and the Properties Window to play nice

By default, the VBE window docks and stacks the Project Explorer and Properties Window to the left of the container window (with the Project Explorer in the top-left corner and the Properties window in the bottom-left corner). If you undock and move one of them, you might have trouble restacking them. You'll probably try #3, but it won't work — the VBE will simply dock them both to the same border and position one over the other instead of stacking them.

To restack the windows, redock one of them, if necessary. Then, drag the floating window to the upper-left corner to position the floating window on top. (The position is relative to the docked window's position, but most people seem to prefer the left.) When the cursor — not the window — touches the top-center of the docked window, release the mouse. The editor will dock and stack the floating window on top of the currently docked window. To position the floating window at the bottom, drag it down until the cursor touches the bottom-center of the currently docked window.

5: Toggle between windows

If you use the VBE at all, you probably know that you can quickly launch the editor by pressing [Alt] [F11]. What you might not know is that this keyboard shortcut is a toggle between the application window and the editor. Once you're in the editor, press [Alt] [F11] to return to the application.

Five tips for managing a dispersed project team

Date: October 6th, 2010
Author: Tom Mochal

IT leaders who oversee teams of remote workers have some obstacles to overcome. Tom Mochal offers some practical advice for successfully managing a distributed workforce.

---

In the past, a project team usually resided in one location. The reason is obvious: it wasn't easy to communicate and collaborate with people who were not in the same physical location. But now, it's common to have team members physically located in many places. In some cases, you may have team members teleworking from home. In other cases, you may be partnering with a third-party company — perhaps even internationally.

All of this is more common today because of advances in technology and software. People can access your company's computer network remotely with almost the same speed as if they were in the office. Software is available to share documents and make updates available real-time to the rest of the team. The team can get together as needed using phone conferencing, teleconferencing, or video technology over the Web.

That's all good news. The not-so-good news is that it is still easier to manage a team when the members are located together. But even though no technology can take the place of talking face to face, the following ideas can help you better manage a dispersed project team.

Note: These tips are based on an entry in our IT Consultant blog.

1: Make sure people have the right attitude

Both the project manager and team members must be especially diligent and sensitive to collaboration and teamwork concerns when part of the team is remote. It's easy for a remote worker to feel isolated from what's going on with the rest of the team. People who are working remotely must be proactive communicators and must be especially good at working independently and meeting their deadlines.

2: Establish good communication processes

The project manager needs to develop a proactive Communication Plan to ensure that the dispersed team works well together. For instance, if possible, there should be regularly scheduled meetings where the remote workers attend in person. If the team members are in different cities or different countries, look for common times when you can have a video or audio conference.

3: Plan the handoffs

Sometimes, multiple people in different locations are working on the same, or related, deliverables. In these cases, the project manager may need to establish rules for handoffs, especially if different time zones are involved. Don't leave the handoffs to chance. Set up processes to ensure that work on shared deliverables can transition smoothly from one person (or team) to another person (or team).

4: Make sure everyone has the right technology

Provide your remote team members with the right hardware, software, and other equipment to get their work done. For instance, if some team members are working from home, a slow dial-up modem probably won't cut it. Each remote location needs communication equipment, printers, fax machines, phones, and the other basic equipment needed to communicate effectively.

5: Take advantage of collaborative technology

Many products on the market, much of it Web-based, allow for easier collaboration among people who are in different locations. For example, you can get software that facilitates Web meetings, common document editing, discussion boards, and remote testing.

Meeting the challenge

Project managers must recognize that there is inherent risk associated with remote team members. To a certain degree, the risk increases the farther away the team members are because you run into time differences. However, a proactive project manager can work through the difficulties by looking holistically at the people concerns, process concerns, and technology concerns. You can set up a plan to mitigate the risk and ensure that the dispersed team works well together for the common good of the project and the team.

10 hot up-and-coming computer careers

Date: October 6th, 2010
Author: Toni Bowers

Reports from the U.S. Dept of Labor (DoL) and Bureau of Labor Statistics (BLS) indicate that the top ten fastest growing, high-demand careers between 2000-2014 show a significant number of IT-related jobs.

In addition to the usual tech career areas–network administrator, tech support person, security expert–some more are popping up in unusual places.

Computermajors.com lists some these areas of tech that they think will grow in the next few years:

Environmental Simulations Developer–This is a developer who will both develop accurate environmental models, run simulations, and collect data.

Video Game Developer–This area can only grow. Also, computermajors says that video games will be entering new domains, such as the health and education industries, on much larger scales.

Bioinformatics Simulations Modeling. Bioinformatics is the study of genomes, gene sequencing, protein structures, etc., all of which help advance medical discoveries.

3D Animation Technician–If James Cameron and the likes of his Avatar are any indication, the demand for this kind of technician will grow.

Medical Modeling Systems Developer and Technician–The ever-evolving world of medical science needs advanced computer systems to model new technology.

Digital Film Production Assistant and Technician–According to the computermajors site, "While actual reel film might have its advantages and still be in use, post production-wise the trend is digital - both for movies and TV - using sophisticated computer systems that require a specialized training to use. Add to this the pending widespread use of HDTV (High-Def) broadcasting, and the distribution of content online, and additional technical careers will no doubt be available to be filled."

Training Software Developer–There are opportunities for digital entrepreneurs in building paid membership websites that teach specific topics.

Visual and Audio Content Producers–Online businesses are going to increase the creation of compelling visual and audio content, therefore familiarity with high-level codes like Action Script and the ability to use video screen capture software such as Camtasia Studio will be very marketable.

Additional T-SQL operations in SQL Server 2008

Scalar Operators

Scalar operators are used for operations with scalar values. Transact-SQL supports numeric and Boolean operators as well as concatenation.

There are unary and binary arithmetic operators. Unary operators are + and – (as signs). Binary arithmetic operators are +, –, *, /, and %. (The first four binary operators have their respective mathematical meanings, whereas % is the modulo operator.)

You are reading part 4 from "The basic objects of T-SQL in SQL Server 2008," excerpted from Microsoft SQL Server 2008: A Beginner's Guide, by Dusan Petkovic, copyright 2008, printed with permission from McGraw-Hill Osborne Media.

Boolean operators have two different notations depending on whether they are applied to bit strings or to other data types. The operators NOT, AND, and OR are applied to all data types (except BIT). They are described in detail in Chapter 6.

The bitwise operators for manipulating bit strings are listed here, and Example 4.8 shows how they are used:

• ~ Complement (i.e., NOT)
• & Conjunction of bit strings (i.e., AND)
• | Disjunction of bit strings (i.e., OR)
• ^ Exclusive disjunction (i.e., XOR or Exclusive OR)

Example 4.8
~(1001001) = (0110110)
(11001001) | (10101101) = (11101101)
(11001001) & (10101101) = (10001001)
(11001001) ^ (10101101) = (01100100)

The concatenation operator + can be used to concatenate two character strings or bit strings.

Global Variables

Global variables are special system variables that can be used as if they were scalar constants. Transact-SQL supports many global variables, which have to be preceded by the prefix @@. The following table describes several global variables. (For the complete list of all global variables, see Books Online.)

Variable	Explanation
@@CONNECTIONS	Returns the number of login attempts since starting the system.
@@CPU_BUSY	Returns the total CPU time (in units of milliseconds) used since starting the system.
@@ERROR	Returns the information about the return value of the last executed Transact-SQL statement.
@@IDENTITY	Returns the last inserted value for the column with the IDENTITY property (see Chapter 6).
@@LANGID	Returns the identifier of the language that is currently used by the database system.
@@LANGUAGE	Returns the name of the language that is currently used by the database system.
@@MAX_CONNECTIONS	Returns the maximum number of actual connections to the system.
@@PROCID	Returns the identifier for the stored procedure currently being executed.
@@ROWCOUNT	Returns the number of rows that have been affected by the last Transact-SQL statement executed by the system.
@@SERVERNAME	Retrieves the information concerning the local database server. This information contains, among other things, the name of the server and the name of the instance.
@@SPID	Returns the identifier of the server process.
@@VERSION	Returns the current version of the database system software.

NULL Values

A NULL value is a special value that may be assigned to a column. This value is normally used when information in a column is unknown or not applicable. For example, in the case of an unknown home telephone number for a company's employee, it is recommended that the NULL value be assigned to the home_telephone column.

Any arithmetic expression results in a NULL if any operand of that expression is itself a NULL value. Therefore, in unary arithmetic expressions (if A is an expression with a NULL value), both +A and –A return NULL. In binary expressions, if one (or both) of the operands A or B has the NULL value, A + B, A – B, A * B, A / B, and A % B also result in a NULL. (The operands A and B have to be numerical expressions.)

If an expression contains a relational operation and one (or both) of the operands has (have) the NULL value, the result of this operation will be NULL. Hence, each of the expressions A = B, A <> B, A < B, and A > B also returns NULL.

In the Boolean AND, OR, and NOT, the behavior of the NULL values is specified by the following truth tables, where T stands for true, U for unknown (NULL), and F for false. In these tables, follow the row and column represented by the values of the Boolean expressions that the operator works on, and the value where they intersect represents the resulting value.

AND	T	U	F		OR	T	U	F		NOT
T	T	U	F		T	T	T	T		T	F
U	U	U	F		U	T	U	U		U	U
F	F	F	F		F	T	U	F		F	T

Any NULL value in the argument of aggregate functions AVG, SUM, MAX, MIN, and COUNT is eliminated before the respective function is calculated (except for the function COUNT(*)). If a column contains only NULL values, the function returns NULL. The aggregate function COUNT(*) handles all NULL values the same as non-NULL values. If the column contains only NULL values, the result of the function COUNT(DISTINCT column_name) is 0.

A NULL value has to be different from all other values. For numeric data types, there is a distinction between the value zero and NULL. The same is true for the empty string and NULL for character data types.

A column of a table allows NULL values if its definition explicitly contains NULL. On the other hand, NULL values are not permitted if the definition of a column explicitly contains NOT NULL. If the user does not specify NULL or NOT NULL for a column with a data type (except TIMESTAMP), the following values are assigned:

• NULL - If the ANSI_NULL_DFLT_ON option of the SET statement is set to ON
• NOT NULL - If the ANSI_NULL_DFLT_OFF option of the SET statement is set to ON

If the SET statement isn't activated, a column will contain the value NOT NULL by default. (The columns of TIMESTAMP data type can only be declared as NOT NULL columns.)

There is also another option of the SET statement: CONCAT_NULL_YIELDS_ NULL. This option influences the concatenation operation with a NULL value so that anything you concatenate to a NULL value will yield NULL again. For instance:

'San Francisco' + NULL = NULL

Conclusion

The basic features of Transact-SQL consist of data types, predicates, and functions. Data types comply with data types of the ANSI SQL92 standard. Transact-SQL supports a variety of useful system functions.

The next chapter introduces you to Transact-SQL statements in relation to SQL's data definition language. This part of Transact-SQL comprises all the statements needed for creating, altering, and removing database objects.

Exercises

E.4.1
What is the difference between the numeric data types INT, SMALLINT, and TINYINT?

E.4.2
What is the difference between the data types CHAR and VARCHAR? When should you use the latter (instead of the former) and vice versa?

E.4.3
How can you set the format of a column with the DATE data type so that its values can be entered in the form 'yyyy/mm/dd'?

In the following two exercises, use the SELECT statement in the Query Editor component window of SQL Server Management Studio to display the result of all system functions and global variables. (For instance, SELECT host_id() displays the ID number of the current host.)

E.4.4
Using system functions, find the ID number of the test database (Exercise 2.1).

E.4.5
Using the system variables, display the current version of the database system software and the language that is used by this software.

E.4.6
Using the bitwise operators &, |, and ^, calculate the following operations with the bit strings:
(11100101) & (01010111)
(10011011) | (11001001)
(10110111) ^ (10110001)

E.4.7
What is the result of the following expressions? (A is a numerical and B a logical expression.)
A + NULL
NULL = NULL
B OR NULL
B AND NULL

E.4.8
When can you use both single and double quotation marks to define string and temporal constants?

E.4.9
What is a delimited identifier and when do you need it?