I Wrote here my most memorable 15 lessons so far: http://www.jaftalks.com/Home/Show/memorable%20programming%20lessons

Heaving read a few million lines of C# code, I came up with these optimization benchmarks that help to significantly improve code performance through simple changes.

Please go here to read the full article: http://www.jaftalks.com/Home/Show/Code%20optimization%20remarks

Thank you

Getting past the naming, ‘God mode’ can be very useful for finding options in Windows 7.

Entering God mode

Make a new folder called:

GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}

It can be anywhere – I tried it in the Drive C root folder.

If you do it right, the folder icon will change to the Control Panel icon.

Enter the folder and it shows up a long list of control settings that are normally spread across many locations (Action Center, Admin Tools etc).

Note: Don’t try it with Vista, it’ll crash.

1-      Direct approach: you can use this approach when you want to transmit good news to your reader. The main and only rule is to start directly with the good news, and it’s recommended that you leave goodwill and a friendly frame in the mind of the reader at the last paragraph.

2-      Indirect approach: you can use this approach when you’re transmitting bad news to the reader or to say no. the main rule is to put the bad news in the middle of the letter, by putting a buffer between the reader and the bad news, the reader must begin and ends with positive message.

3-      Persuasive approach: Getting the reader to do what you want, to accept what you say, or to agree with you. In the persuasive approach the letter starts with a promise or imply some benefit or reward for the reader, then describe the service pr the product, and finally ask for action.

As you plan your correspondence you should start by:

1-      The person who writes the letter

You represent your organization in the correspondence so never let the client or the receiver feel that you disagree with anyone in the organization or with its policy.

Your job is to put what the organization has to say in terms that your reader can accept.

2-      The person who receives the letter

This is the most important factor, before sending the message you should know as much as you can the mentality of the receiver or the way he thinks. Adapting to the reader means writing with the reader in mind which will help a lot getting to the letter goals.

A business message is successful only if the reader: Reads it – Understands it – Reacts on it.

3-      The purpose of the letter

You write a business letter if you have a need to communicate, to plan the letter effectively, you should know: why the letter is needed and the response it should bring.

* To test the completeness of a correspondence you can ask the 5 W and the  H  ( Who, Why, Where, What and How)

In business it’s not recommended to communicate verbally, written communication is highly recommended, some of the advantages:

1-      Less expensive

2-      More Penetrable (than a phone call)

3-      Written record

4-      Confidential

5-      Contains more details and visual representations (charts and diagrams)

6-      Fast

7-      Spend more time in the preparation, so it’ll be more accurate.

There are three types of sending and receiving written information:

1-      Letters

2-      Memos

3-      Reports

See the full article : http://www.jaftalks.com/Home/Show/Introduction%20to%20Software%20Coding%20Standards

Why we are introducing Agile Methodologies

We use agile development methodologies to improve quality while reducing cost and time-to-market.

Why Agile?

Traditionally, software applications are developed using waterfall methodology. A large percentage of big corporations still continue to follow the waterfall model. As of 2008, surveys show that agile penetration in large enterprise is less than 25%, but growing fast as more and more enterprises understand its benefits. A majority of ISVs and startups already use agile methodologies.

Agile is gaining momentum because of several factors:

• Businesses operate in a fast changing environment, where they have to respond to market changes quickly by introducing new products or changing existing ones. Typical projects are now 3 months or less and not years as it used to be.
• New technologies are coming to market every other day, so if a product takes years to build, it sure will get outdated before it launches.
• The web-based model allows companies to launch a bare bones version of the product first, get feedback from end-users and then incrementally add new features based on that feedback.

Thus launching early, collecting feedback from real users and performing frequent releases is the new way of product development. And agile is closely aligned with this new way.

The Scrum Process

Scrum is the default process we use. A custom-made process for a client is usually a variant of Scrum.

The requirements for the product are collected into what is called the product backlog, which is a prioritized wish list of features. Features may be described using user stories. The Customer maintains the product backlog. The product backlog is never frozen, users can suggest new requirements and the Product Owner can add them to the backlog and prioritize it.

The product is developed iteratively in multiple sprints. A sprint is a time-boxed iteration, which usually lasts 30 days. The duration of a sprint can be fixed based on the nature of the project. Typically a release follows a sprint, though a release can be made after multiple sprints. Each sprint will implement a set of features.

Once a sprint starts, the scope of the sprint cannot be changed by adding new features. This allows the developers to complete a sprint without external interference.

Detailed Process

Development is done in 4 week iterations. Prior to the beginning of an iteration, several things happen. We call these pre-iteration planning. The actors involved in this phase are Customer, Project Manager, and Business Analyst and to a lesser extend Developers and QA.

Note that during the pre-iteration phase, the developers are working on the previous iteration.

Pre-iteration:

• Identify features to be implemented in the next iteration from the Product – Customer, Project Manager.
• Write use cases; create wireframes – Business Analyst, Customer.
• Identify sprint tasks for implementing the features / use cases – Project Manager, Team.

Iteration

• Team clarifies use cases with customer and BA. They further elaborate use cases and factor-in exceptional and failure conditions.
• QA comes up with acceptance criteria.
• Customer approves use cases and acceptance criteria.
• Features implementation by development team

Post-iteration

• QA works on test automation (new test cases are automated to the extend possible).
• Release code to live.
• Smoke tests in live environment by QA.

Sometimes we call it “version control”.  Sometimes we call it “SCM”, which stands for either “software configuration management” or “source code management”.  Sometimes we call it “source control”. 

By any of these names, source control is an important practice for any software development team.  The most basic element in software development is our source code.  A source control tool offers a system for managing this source code.

There are many source control tools, and they are all different.  However, regardless of which tool you use, it is likely that your source control tool provides some or all of the following basic features:

• It provides a place to store your source code.
• It provides a historical record of what you have done over time.
• It can provide a way for developers to work on separate tasks in parallel, merging their efforts later.
• It can provide a way for developers to work together without getting in each others’ way.

Repository and working folder

An SCM tool provides a place to store your source code.  We call this place a repository.  The repository exists on a server machine and is shared by everyone on your team.

Each individual developer does her work in a working folder, which is located on a desktop machine and accessed using a client.

Each of these things is basically a hierarchy of folders.  A specific file in the repository is described by its path, just like we describe a specific file on the file system of your local machine. 

For example, the path for a file might look like this:

$/trunk/src/myLibrary/hello.cs

The workflow of a developer is an infinite loop which looks something like this:

• Copy the contents of the repository into a working folder.
• Make changes to the code in the working folder.
• Update the repository to incorporate those changes.
• Repeat.

The repository is the official place where all completed work is stored.

Let’s imagine for a moment what life would be like without this distinction between working folder and repository.  In a single-person team, the situation could be described as tolerable.  However, for any plurality of developers, things can get very messy.

I’ve seen people try it (Rawad & Adel).  They store their code on a file server.  Everyone uses Windows file sharing and edits the source files in place.  When somebody wants to edit main.cpp, they shout across the hall and ask if anybody else is using that file. 

Because of this separation between working folder and repository, the most frequently used features of an SCM tool are the ones which help us move things back and forth between them.  Let’s define some terms:

• Add:  A repository starts out completely empty, so we need to “Add” things to it.  Using the “Add Files” command in Vault you can specify files or folders on your desktop machine which will be added to the repository.
• Get:  When we copy things from the repository to the working folder, we call that operation “Get”.  Note that this operation is usually used when retrieving files that we do not intend to edit.  The files in the working folder will be read-only.
• Checkout:  When we want to retrieve files for the purpose of modifying them, we call that operation “Checkout”.  Those files will be marked writable in our working folder.  The SCM server will keep a record of our intent.
• Checkin:  When we send changes back to the repository, we call that operation “Checkin”.  Our working files will be marked back to read-only and the SCM server will update the repository to contain new versions of the changed files.

The repository is more than just an archive of the current version of your code.  Actually, it is an archive of every version of the code.  The repository contains history.  It contains every version of every file that has ever been checked in to the repository. 

The ability to travel back in time can be extremely useful for a software project.  Suppose we need the ability to retrieve a copy of our source code exactly as it looked on April 28th, 2002.  An SCM tool makes this kind of thing easy to do.

An even more common case is the situation where a piece of code looks goofy and nobody can figure out why.  It’s handy to be able to look back at the history and understand when and why a certain change happened.

Over time, the complete history of a repository can become large and overwhelming, so SCM tools provide ways to cope.  For example, Vault provides a History Explorer which allows the history entries to be queried and searched and sorted.

Editing a single file

Consider the simple situation where a developer needs to make a change to one source file. 

Two methods:

• checkout-edit-checkin

1. Checkout the file
2. Edit the working file as needed
3. Checkin the file

Followers of the “checkout-edit-checkin” doctrine are effectively submitting to live according to the following rules:

• Files in the working folder are read-only unless they are checked out.
• Developers must always checkout a file before editing it.  Therefore, the entire team always knows who is editing which files.
• Checkouts are made with exclusive locks, so only one developer can checkout a file at one time.

• Edit-merge-commit: the following steps to modify a single file:

1. Edit the working file as needed
2. Merge any recent changes from the server into the working file
3. Commit the file to the repository

The edit-merge-commit rules:

• Files in the working folder are always writable.
• Nobody uses checkouts at all, so nobody knows who is editing which files.
• When a developer commits his changes, he is responsible for ensuring that his changes were made against the latest version in the repository.

There are several reasons why we may need to merge two modified versions of a file:

• When using “edit-merge-commit” (sometimes called “optimistic locking”), it is possible for two developers to edit the same file at the same time.
• Even if we use “checkout-edit-checkin”, we may allow multiple checkouts, resulting once again in the possibility of two developers editing the same file.
• When merging between branches, we may have a situation where the file has been modified in both branches.

An example

Let’s call our two developers Jane and Joe.  Both of them have retrieved version 4 of the same file and both of them are working on making changes to it.

One of these developers will checkin before the other one.  Let’s assume it is Jane who gets there first.  When Jane tries to checkin her changes, nothing unusual will happen.  The current version of the file is 4, and that was the version she had when she started making her changes.  In other words, version 4 was her baseline for these changes.  Since her baseline matches the current version, there is no merge necessary.  Her changes are checked in, and a version of the file is created in the repository.  After her checkin, the current version of the file is now 5.

The responsibility for merging is going to fall upon Joe.  When he tries to checkin his changes, the SCM tool will protest.  His baseline version is 4, but the current version in the repository is now 5.  If Joe is allowed to checkin his version of the file, the changes made by Jane in version 5 will be lost.  Therefore, Joe will not be allowed to checkin this file until he convinces the SCM tool that he has merged Jane’s version 5 changes into his working copy of the file.

In order to resolve this situation, Joe effectively needs to do a three-way comparison between the following three versions of the file:

• Version 4 (the baseline from which he and Jane both started)
• Version 5 (Jane’s version)
• Joe’s working file (containing his own changes)

Version 4 is the common ancestor for both Joe’s version and Jane’s version of the file.  By running a diff between version 4 and version 5, Joe can see exactly what changes Jane made.  He can use this information to apply those changes to his own version of the file.  Once he has done so, he can credibly claim that his version is a merge of his changes and Jane’s.

However, most of the time it will be necessary for the merge to actually happen.  In these cases, Joe has the following options:

• Attempt to automerge
• Use a visual merge tool
• Redo one set of changes by hand

Attempt to automerge

A surprising number of cases can be easily handled automatically.  Most source control tools include the ability to attempt an automatic merge.  The algorithm uses all three of the involved versions of the file and attempts to safely produce a merged version.

The reason that automerge is so safe in practice is that the algorithm is extremely conservative.  Automerge will refuse to produce a merged version if Joe’s changes and Jane’s changes appear to be in conflict.  In the most obvious case, if Joe and Jane both modified the same line, automerge will detect this “conflict” and refuse to proceed.  In other cases, automerge may fail with conflicts if two changes are too close to each other.

Use a visual merge tool

In cases where automerge cannot automatically resolve conflicts, we can use a visual merge tool to make the job easier.  These tools provide a visual display which shows all three files and highlights exactly what has changed.  This makes it much easier for the developer to perform the merge, since she can zero in on the conflicts very quickly.

Redo one set of changes by hand

Some situations are so complicated that a visual merge tool just isn’t very helpful.  In the worst case scenario, Joe might have to manually redo one set of changes.