blog moved

this blog moved to WordPress @
http://usmanshaheen.wordpress.com/

Quitting? Do it Professionally

http://greenwhite.org/2007/07/17/quitting-do-it-professionally/

we all learn from our experience

Powered by ScribeFire.

Deploying ReportViewer web control inside Reporting Services 2005 website

if your web application is using ReportViewer web control, it will throw the exception:

The type Microsoft.ReportingServices.UI.WebControlConnection,
ReportingServicesWebUserInterface, Version=9.0.242.0, Culture=neutral,
PublicKeyToken=89845dcd8080cc91 does not implement
IReportServerConnection or could not be found

its your application inheriting appSettings from parent's site web.config.
To resolve this, modify your applications' web.config as

<appSettings>
<remove key ="ReportViewerServerConnection"/>
<remove key ="ReportViewerTemporaryStorage"/>
</appSettings>

Powered by ScribeFire.

10 Developers For The Price Of One

from: http://haacked.com/archive/2007/06/25/understanding-productivity-differences-between-developers.aspx

In the The Mythical Man-Month, Fred Brooks highlights an eye opening disparity in productivity between good and poor programmers (emphasis mine).

Programming
managers have long recognized wide productivity variations between good
programmers and poor ones. But the actual measured magnitudes have
astounded all of us. In one of their studies, Sackman, Erickson, and
Grant were measuring performance of a group of experienced programmers. Within
just this group the ratios between the best and worst performances
averaged about 10:1 on productivity measurements and an amazing 5:1 on
program speed and space measurements!

Robert Glass cites research that puts this disparity even higher in his book Facts and Fallacies of Software Engineering.

The best programmers are up to 28 times better than the worst programmers,
according to “individual differences” research. Given that their pay is
never commensurate, they are the biggest bargains in the software field.

In other words, the best developers are generally underpaid and the worst developers overpaid.

But
don’t leave your job just yet. This is not to say that there should be
a 1 to 1 correlation between productivity and pay. People should be
paid by the value they bring and productivity is only part of the value
proposition, albeit a big part of it. Even so, we’d expect to see some
amount of correlation in pay with such a drastic productivity
difference. But in general, we don’t. Why is that?

It’s because most managers don’t believe this productivity disparity despite repeated verification by multiple studies. Why should they let facts get in the way of their beliefs? That would only mean the factonistas have won.

Kidding
aside, why is this productivity difference so hard to believe? Allow me
to put words in the mouth of a straw-man manager.

Well how in the world can one developer write code 28 times faster than another developer?

This sort of thinking represents a common fallacy when it comes to measuring developer productivity. Productivity is not about the lines of code.
A huge steaming pile of code that doesn’t get the job done is not
productive. There are many aspects to developer productivity, but they
all fall under one main principle (borrowing a term from the finance industry), TCO.

TCO - Total Cost Of Ownership.

In general, I’ve tried to always hire the best developers I can find. But I’ve made mistakes before. Yes, even me.

One situation
that comes to mind was with a developer I had hired (under a lot of
pressure to staff up I might add) at a former company. I handed off a
project to this erstwhile coworker to take over. A few days go by and I
don’t hear anything from the guy, so I assume things are humming along
nicely.

Fast forward another few days and I swing by to see how
it’s going and the developer tells me he doesn’t understand a few
requirements and has been spinning his wheels trying to figure it out
this whole time.

Good Developers take Ownership so You Don’t Have To

This
is one of the first ways that good developers are more productive than
average developers. They take ownership of a project. Rather than spend
a week spinning wheels because they don’t understand a requirement, a
good developer will go and grab the decision maker and squeeze out some
clarity.

Likewise, a good developer doesn’t require you to prod
them every few moments to make sure they are progressing. If they get
overly stuck on a problem, they’ll come to you or their coworkers and
resolve the problem.

A developer who can write code fast, but
doesn’t take ownership of their projects is not very productive because
they end up wasting your time.

Good Developers Write Code With Less Bugs

I
once worked with a developer who was praised by my boss for being
extremely fast at writing code. He sure was fast! He was also fast at
introducing bugs into code. His code was sloppy and hard to understand.

The
key measure that wasn’t figured into his productivity measurement was
the amount of productivity lost by the QA team attempting to reproduce
bugs introduced by his code, along with the time spent fixing those
bugs by this developer or other developers.

Everyone focused on
his time to "completion", but not on the total cost of ownership of
that code. Code is not complete when a developer says it is complete.
That is not the time to stop the stopwatch. It’s when QA has had its say that you can put the stopwatch away for the moment.

As
I like to say, productivity is not about speed. It’s about velocity.
You can be fast, but if you’re going in the wrong direction, you’re not
helping anyone.

Good Developers Write Maintainable Code

Hand
in hand with writing less bugs is writing understandable maintainable
code. As soon as a line of code is laid on the screen, you’re in
maintenance mode on that piece of code.

Code that is brittle and
difficult to change wastes hours and hours of developer cycles when
trying to amend a system with updates and new features. By writing
maintainable code, a good developer can make these changes more quickly
and also improves the productivity of his or her team members who later
have to work on such code.

Good Developers Do More With Less Code

Another hallmark of a good developer is that they know when not to write code. As a friend always tells me

Why build what you can buy? Why buy what you can borrow? Why borrow what you can steal?

With
a few exceptions, the NIH (Not Invented Here) syndrome is a
pathological productivity killer. I’ve seen developers start out to
write their own form validation framework until I point out that there
is already one built in to ASP.NET that does the job (It’s not perfect,
but it’s better than the one I saw being written).

All of that
time spent reinventing the wheel is wasted because someone else has
already written that code for you. And in many cases, did a better job
as it was their only focus. In such a situation, finding an existing
library that gets the job done can provide a huge productivity boost.

The
caveat in this case is to be careful to avoid non-extensible and rigid
3rd party libraries, especially for very specialized requirements. You
might a lot of time trying to fit a round peg in a square box.

Even
when you must invent here, good developers tend to write less (but
still readable) code that does more. For example, rather than build a
state machine to parse out text from a big string, a good developer
might use a regular expression (ok, some will say that a regex is not readable. Still more readable than hundreds of lines of text parsing code).

Back to TCO

Each of these characteristics I’ve listed keeps the total cost of ownership of a good developer low. Please don’t let the term ownership distract you. What I mean here is the cost to the company for having such a developer on the payroll.

By
writing less code that does more, and by writing maintainable code that
has fewer bugs, a good developer takes pressure off of the QA staff,
coworkers, and management, increasing productivity for everyone around.
This is why numbers such as 28 times productivity are possible and
might even seem low when you look at the big picture.

Hopefully
seeing this perspective will convince managers that good developers
really are as productive as the studies show. Negotiating a 28x pay
increase on the other hand, is an exercise left to the reader.

Powered by ScribeFire.

Speaking as a Performing Art

from Guy Kawasaki Blog: http://blog.guykawasaki.com/2007/06/speaking_as_a_p.html

Singing and speaking have everything in common—except for maybe really
good tunes. The main goal is to engage your audience and make them
listen to you, so everything a singer does, a speaker ought to do too.
Here are the absolute necessities of an engaging performance or
presentation that Doug compiled for me:

1. Circulate with your audience. Before every concert,
   speech, and seminar, I try to mingle with the crowd, ask questions, and
   let them know I’m glad they came. This isn’t always possible in the
   real world, but when it is, I have an opportunity to feel a bond with
   the people I’m about to perform for and undo some of the jitters that
   are a natural part of being “on.”

2. Command attention. The breastbone (sternum) has to be
   high if you want to project authority. You might want to pretend you’re
   a rooster showing off. Relaxed sternum = loser, high sternum = winner!

3. Snarl. If people can’t hear you, they won’t listen to
   you. Add some nasal resonance to your voice, but keep smiling. Snarl is
   that nasal sound you get when you speak partially from your nose
   instead of your mouth. It generates overtones above 2,800 cycles per
   second that make any room “sing.” Pretend you’re trying to yell/warn a
   child that’s about to run out in front of a bus—like yelling, “STOP!”
   This works whether you’re using a microphone or speaking without one

4. Bite your tongue. If your mouth gets dry in the middle of
   your presentation, try gently biting your tongue. Opera singers use
   this all the time to release saliva which moistens your mouth.

5. Always perform a sound check before you speak. A good
   sound person will adjust the EQ to your voice and its idiosyncrasies.
   If you’re comfortable using a hand mike, do so—work close to the mike
   and you’ll have a better chance of being heard. If you turn your head,
   make sure you turn the mike with your head. Lapel mikes usually work
   fine, but for softer speakers they’re very frustrating. Wrap-around
   mikes (such as the AKG C520L—$159) that fit over your ear are the best
   for intelligibility. If you speak often and you know your venues will
   support this technology, buy a really good one and take it with you.

6. Use your eyes all the time. Hand gestures, pacing around
   the platform can all be useful tools in presentation, but the eyes…ah,
   the eyes have it! If you can’t engage people with your eyes you will
   eventually lose your audience’s attention. Your eyes always tell people
   whether or not you believe in what you’re saying! Scan the room, select
   a person to make a point to, and look right at them. It’s a little
   intimidating for them, but it keeps you focused on the individuals who
   make up your audience. Keep moving to new people—right, left, middle—it
   works! If all else fails, look at each person as though you’ve loved
   him or her all your life—like mom, or your child.

7. Move away from center to make your point. When you come
   to a place in your presentation where you really want people’s
   attention, move to the left or right of your primary speaking position.
   This will always make people look up at you. If you are a constant
   mover or shaker, stand still for a few moments—it will have the same
   effect.

8. Get quiet. If you really want to get people’s attention,
   get quiet suddenly. It will scare the sound guy to death, but I
   guarantee the audience will pay attention. Singers use this trick all
   the time. That’s the “you could hear a pin drop” effect. Believe me,
   that’s what sells your talk!

9. “Underline” certain words with a pause or repetition. If
   you really want to make a point, slow down, pause, and say the word or
   phrase that you most want people to hear with a calculated emphasis on
   each word. The sudden switch in style gets attention. Also try
   repeating a word or phrase before you make your big point. For example:
   “You know (pause) you know (pause) you know, the thing I want you to
   remember is…” Songs are full of repeated text, a device that locks down
   meaning!

10. Take a risk and be vulnerable. Say or do something that’s
    totally out of character for you. Use a “pretend” voice like Mickey
    Mouse or Barry White for effect while you’re telling a joke or saying
    something shocking or humorous. Whether your persona is reserved or
    funny, it’s endearing to have a little fun. This trick humanizes the
    most serious topics.

11. Tee it higher. Raising the overall pitch of your voice
    for a few seconds will create urgency. It shows your passion for the
    subject matter and also relaxes your exhausted larynx. Low pitched
    voices relax the room—high pitched voices increase the adrenaline flow
    of the audience.

12. Know when it’s time to go. You don’t have to be a genius
    to know you’ve overstayed your welcome. Check your “presentation
    barometer” often to see if everyone is still with you. Change
    something—anything—if you’re starting to lose the crowd. If all else
    fails, stop talking, start thanking, and get off the platform. People
    will love you more for knowing when to stop than for all the wonderful
    content you brought to your topic!

13. Use Q and A as an “encore.” Singers usually prepare an
    encore because this practice makes the audience feel special and makes
    them think you like them more than other audiences you’ve encountered.
    Q and A functions something like an encore. You may think you told them
    stuff they needed to know, but questions often reveal the important
    things you left out of your content. Where this opportunity exists, use
    it as a tool for picking up the pieces you left dangling in your talk
    and warm the crowd to your candor and self-effacing graciousness.
    

14. Rehearse, rehearse, rehearse. That’s how I got to
    Carnegie Hall! Where possible, memorize your material like singers
    memorize their songs. Remember, the more you rehearse, the freer you
    will be to make your talk fresh and engaging.

15. Perform for a hero. Several years ago I was asked to sing
    a command performance for the Queen of Spain. I worked harder on that
    concert than any I have ever sung. It was very successful and I was
    proud of my preparation. From that time on I imagined I was about to
    sing for the queen, it made me twice the performer I had been
    previously. Pick a hero, and give them your best shot!

regex: match a value between two strings

how to capture a value, by group name, between two known string patterns
regex :

Regex re = new Regex("str1(?.*?)str2",RegexOptions.Singleline);

foreach (Match m in re.Matches(data)) {
Console.WriteLine(m.Groups["val"].Value );
}

Article : Two Factor Theory

Two Factor Theory (also known as Herzberg's Motivation-Hygiene Theory) - job satisfaction and job dissatisfaction acted independently of each other. Two Factor Theory states that there are certain factors in the workplace that cause job satisfaction, while a separate set of factors cause dissatisfaction. (Herzberg, Mausner & Snyderman 1959)

Two Factor Theory distinguishes between:

• Motivators; (e.g. challenging work, recognition, responsibility) which give positive satisfaction, and

• Hygiene factors; (e.g. status, job security, salary and fringe benefits) which do not give positive satisfaction, although dissatisfaction results from their absence.

Essentially, hygiene factors are needed to ensure an employee is not dissatisfied. Motivation factors are needed in order to motivate an employee to higher performance, Herzberg also further classified our actions and how and why we do them, for example, if you perform a work related action because you have to then that is classed as movement, but if you perform a work related action because you want to then that is classed as motivation.

Ref: http://en.wikipedia.org/wiki/Two_factor_theory