I’ve been programming since I was 15 and I’ve loved technology and programming every since, during that period I’ve learned some lessons that i would like to share.
I Wrote here my most memorable 15 lessons so far: http://www.jaftalks.com/Home/Show/memorable%20programming%20lessons
Software Developers phobia is code optimization, how to write faster codes? How to make programs runs faster at the same hardware? How to make your client happy?
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
Windows 7 God Mode, a cool workaround which will give you access to all the features of the OS. A pity about the name (it certainly wasn’t an official decision rather an unauthorized extra, so blaming Microsoft isn’t really fair).
Getting past the naming, ‘God mode’ can be very useful for finding options in Windows 7.
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.
Based on the goal of the letter that you’re sending, you choose the one of the three correspondence letters approaches.
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.
Before writing any correspondence, you should plan what should be included in this correspondence and why it’s being sent.
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.
Effective business correspondence can be ensured by applying the five “C” principles, the letter should be:
* To test the completeness of a correspondence you can ask the 5 W and the H ( Who, Why, Where, What and How)
Job skills alone are not sufficient to ensure your success in business, if you have lack in the communication skills.
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
When I was looking for a standard convention for generics, I came across a 50-page manual for coding standards for C#. I am sure that, apart from the author, there are few who actually go through and read all of them. So, I thought of coming up with this article. I have tried to comprehend the essential facts which we developers sometimes neglect in C#. I will also discuss some common pitfalls.
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:
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:
Iteration
Post-iteration
What is source control?
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:
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:
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:
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:
Followers of the “checkout-edit-checkin” doctrine are effectively submitting to live according to the following rules:
The edit-merge-commit rules:
There are several reasons why we may need to merge two modified versions of a file:
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 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
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.
