Have you ever faced a compiler crash experience before?! Do you have any idea about how to recover form this situation??
I've already passed with such an experience :D, and while I was searching for some help on the internet, I found this cool article. It's really great one, I liked the idea of using Binary Search in tracing the program to find out the error. I think it is a good way to trace any kind of program apart way from crashing ;)
Here's the article, enjoy!
Monday, September 22, 2008
Monday, September 15, 2008
Motivation, motivation, and motivation!! Personally speaking, it's the biggest and heaviest load on leaders. Motivating people is not an easy job, and when a team works without any kind of motivations it becomes like machines!! Rusty machines !!!
I've been working in a charity organization and many volunteering communities since 2006. That let me live great experiences with too many leaders. Some of them ware amazing, others ware just carrying the title, but having nothing to do with its responsibilities!!! Also, those days I've been on charge of a great team (my graduations project team :D ), so I became more interesting in leadership in addition to my old admiration to management.
So, I found this great article titled with "10 things you can do to motivate your team", and I liked it a lot. It sums up the most important things leaders should do to motivate their teams. So, please, enjoy :)
To get things done these days, working in teams is almost imperative. But how can you, as a leader, motivate a team to accomplish your objectives? How can you avoid common mistakes that can kill performance and morale?
Believe in your team's objectives
Do you believe in what you want the team to accomplish? Do you think your goals are realistic? If not, rethink your position, because your team will sense your uncertainty. You may say the right words, but your body language and overall demeanor will give you away. On the other hand, if you truly are dedicated and believe in your goals, your team will sense it and will react accordingly.
Model the behavior you want from the team
Don't be a hypocrite -- lead by example. You want your team to interact courteously and professionally with others, but do you do so yourself? If you ask them to put in extra hours, are you there along with them?
Keep a positive attitude
If you model a negative attitude, your team will pick it up. I know it sounds trite, but try to stay upbeat. Doing so doesn't mean being unrealistic. It does mean, however, that you try to look at the glass as being half full rather than half empty.
Instead of saying, for example, "This project will never succeed because of issues 1, 2, and 3," consider saying, "If we want this project to succeed, it's critical that we resolve issues 1, 2, and 3."
Be clear about your goals
It's hard for your team to accomplish its goals if those goals are unclear or unknown to them. More important, it's hard to get them even to agree with those goals if they don't know what they are. Make sure your team knows what you are expecting of them. If you can quantify your goals so that you can measure how well you did compared to what you expected, so much the better.
Get feedback from the team members
Unless you hear from your team members, you may have little or no idea of how effective or clear you are. Few of us enjoy hearing bad news or criticism, but if there's a problem in what we're doing, it's important that we hear it.
When discussing issues with the team, don't shoot the messenger. When listening to a team member, try to separate the message and issue from the person. Similarly, when someone is offering suggestions or discussing issues, try to separate your own self and ego from the discussion. If you do shoot the messenger, all you will have done is make your team even more reluctant to talk frankly with you in the future.
Make sure your team knows what to expect of you. If they do, there's less chance that they'll be unpleasantly surprised or disappointed. Suppose, from the previous point, you had a discussion with a team member, who made a few suggestions. Some of them are workable (so that you could act on them), but others aren't.
Before having this discussion, it would be good to let your team know that while you will listen to them, you may or may not adopt all of their suggestions. One would hope they'd realize this already, but it's best to be explicit. Furthermore, if you do adopt a suggestion, make sure everyone knows about it.
Avoid mixed messages
To encourage desirable behavior, there must be positive rewards for it. Conversely, to discourage undesirable behavior, there must be consequences that result from it. Believe it or not, some people mix up these two points.
Have you, as a parent, ever said to your child, "Any time you have problem, you can talk to Mommy or Daddy"? What happens when they do? You become irritated and yell at them, "Come back later! Can't you see I'm busy?!" If you send similar mixed messages to your staff, you will make it harder for them to act the way you want.
Know the difference between exhorting and belittling
It's fine and good for you to want greater and higher quality results from your team. However, be aware of the line between exhorting someone to do better and belittling them because they aren't right now. The latter might work, but the chances are greater that it might only create resentment and turn out to be counterproductive.
In other words, in keeping with the positive/negative point discussed earlier, focus on where you wanted them to be, rather than on the fact that they weren't there right now.
Correct in private
If personal issues of a team member are becoming a problem, address them with the person in private. Don't embarrass the person by bringing it up in public. Such issues include attendance and punctuality, dress, and general professionalism.
Praise in public
When someone does something right, you probably are happy and want that person to continue doing it. You also probably want to make that person look good in front of the others, and for the others to be motivated to improve their own performance. For those reasons, recognize good work in public, rather than in private.
However, praise alone still can motivate, as long as you're sincere and specific in what you're praising. Generalities are unhelpful. Rather, focus on the specific action, and how it benefited the group.
It can be rewarding to see a team come together and execute the way you want. It's even more rewarding to see people develop the way you want. However, try to be realistic.
Sunday, September 7, 2008
The solution proposed by .NET is “Change everything” (sorry, you can’t blame the messenger for the message). The .NET Framework is a completely new model for building systems on the Windows family of operating systems, as well as on numerous non-Microsoft operating systems such as Mac OS X and various Unix/Linux distributions.
To set the stage, here is a quick rundown of some core features provided courtesy of .NET:
• Comprehensive interoperability with existing code:
This is (of course) a good thing. Existing COM binaries can commingle (i.e., interop) with newer .NET binaries and vice versa. Also, Platform Invocation Services (PInvoke) allows you to call C-based libraries (including the underlying API of the operating system) from .NET code.
• Complete and total language integration:
.NET supports cross-language inheritance, cross language exception handling, and cross-language debugging of code.
• A common runtime engine shared by all .NET-aware languages:
One aspect of this engine is a well-defined set of types that each .NET-aware language “understands.”
• A comprehensive base class library:
This library provides shelter from the complexities of raw API calls and offers a consistent object model used by all .NET-aware languages.
• No more COM plumbing:
IClassFactory, IUnknown, IDispatch, IDL code, and the evil variant compliant data types (BSTR, SAFEARRAY, and so forth) have no place in a .NET binary.
• A truly simplified deployment model:
Under .NET, there is no need to register a binary unit into the system registry. Furthermore, .NET allows multiple versions of the same *.dll to exist in harmony on a single machine.
As you can most likely gather from the previous bullet points, the .NET platform has nothing to
do with COM (beyond the fact that both frameworks originated from Microsoft). In fact, the only
way .NET and COM types can interact with each other is using the interoperability layer.
Apress Pro C Sharp 2008 and the dotNET 3.5 Platform 4th Edition Nov. 2007, Andrew Troelsen