How to create a new branch from a tag on GIT

It's pretty simple:

git checkout -b [NEW-BRANCH] [TAG-NAME]

TFS Git Basics - Delete a remote branch

You can delete a remote branch on TFS Git using the following command:

git push origin --delete [BRANCH NAME]

TFS Git Basics - Tagging

Tagging

Like most VCSs, Git has the ability to tag specific points in history as being important. Typically people use this functionality to mark release points (v1.0, and so on).

In this post, you will learn how to tag using TFS Git.

Before You Start

In order to use tags, you have to open "Command Prompt" from "Unsynced Commits".

Listing Your Tags

Listing the available tags in Git is straightforward. Just type git tag.

Creating Annotated Tags

Git uses two main types of tags: lightweight and annotated. I’ll focus on annotated tags using the following command as an example:

git tag -a v1.4 9fceb02

• To specify an annotated tag, you have to specify –a When you run the tag command.
• v1.4: is the tag name.
• 9fceb02: is a part of the commit identifier you want to tag (Part of the commit identifier is enough).

You’ll then find a VM window asking you to enter the message, write down the message then press ESC then write :wq then press Enter.

Sharing Tags

By default, the git push command doesn't transfer tags to remote servers. You will have to explicitly push tags to a shared server after you have created them. This process is just like sharing remote branches – you can run:

git push origin [tagname]

If you have a lot of tags that you want to push up at once, you can also use the --tags option to the git push command. This will transfer all of your tags to the remote server that are not already there.

git push origin --tags

In order to be able to view pushed tags as a different team member, you have to run the following command from command prompt:

git fetch --tags

[SQL] How to access remote data in a Transact-SQL

I was facing an issue with a friend of mine who need to perform a select statement that selects data from a remote SQL instance.

All  I was thinking about is how to use something like connection string on the execute command to have a permission that could be used to connect to the remote server.

I found that I might use the following syntax:

 OPENDATASOURCE ( provider_name, init_string )

where,

provider_name
Is the name registered as the PROGID of the OLE DB provider used to access the data source. provider_name is a char data type, with no default value.

init_string
Is the connection string passed to the IDataInitialize interface of the destination provider. The provider string syntax is based on keyword-value pairs separated by semicolons, such as: 'keyword1=value; keyword2=value'. 

In order to use OPENDATASOURCE for connection I found that OPENDATASOURCE can be used to access remote data from OLE DB data sources only when the DisallowAdhocAccess registry option is explicitly set to 0 for the specified provider, and the Ad Hoc Distributed Queries advanced configuration option is enabled. When these options are not set, the default behavior does not allow for ad hoc access.

The OPENDATASOURCE function can be used in the same Transact-SQL syntax locations as a linked-server name. Therefore, OPENDATASOURCE can be used as the first part of a four-part name that refers to a table or view name in a SELECT, INSERT, UPDATE, or DELETE statement, or to a remote stored procedure in an EXECUTE statement. When executing remote stored procedures, OPENDATASOURCE should refer to another instance of SQL Server. OPENDATASOURCE does not accept variables for its arguments.

Like the OPENROWSET function, OPENDATASOURCE should only reference OLE DB data sources that are accessed infrequently. Define a linked server for any data sources accessed more than several times. Neither OPENDATASOURCE nor OPENROWSET provide all the functionality of linked-server definitions, such as security management and the ability to query catalog information. All connection information, including passwords, must be provided every time that OPENDATASOURCE is called.

I used the following testing procedure and it works:

sp_configure 'show advanced options', 1;
RECONFIGURE;
GO
sp_configure 'Ad Hoc Distributed Queries', 1;
RECONFIGURE;
GO
select *
from opendatasource('SQLOLEDB.1','Data Source=xxxxx;Password=xxxxx;User ID=xxxxx;Initial Catalog=DATABASE_NAME').[DATABASENAME].[dbo].[TABLE_NAME]

As you see, in order to enable 'Ad Hoc Distributed Queries', you have at first to enable 'show advanced options'.

Hope it could help :)

Software Development Crises Management

On this post, I am going to talk about how to manage a crises inside a software development project.

In order to manage a crisis, you have to know at first that there is a problem. Knowing that there is or there will be a problem is the first step to get it solved.

There hasn’t ever been any project that didn’t have a crisis, and yours is not going to be an exception. So you cannot avoid having a crisis, but you have to be able to manage them.

1. Customer should be notified as early as possible of the delay

One of the most recurrent situations where expectations need to be managed is when a project is going to be late. What usually happens when the project is late is that the customer is not told about that because the project manager hopes that the deviation can be corrected or because being afraid of disappointing the client. 

What more often happens is that the customer is told too late of the delay, when there’s no other option, and what it could have been a minor, or not so big issue by managing the expectations and postponing the deadline or the scope of the release, becomes a major issue that sometimes puts at risk the entire project.

2. Project Manager have to listen to developers

In software development, programmers are the only source of productivity, and for that reason, there is nothing more important than making sure that they have what they need to do their job.

Unfortunately many project managers prefer to focus on dates, meetings and deadlines, which sometimes is good as it makes the project move forward, but sometimes developer feedback is overlooked causing productivity issues, technical debt, low quality products, etc.


3. Be Transparent

Managing a project is to take responsibility when things go wrong and making sure that all the stakeholders are well informed of what is the current status of the project. Hiding information is never good in the long run.
Unfortunately, one of the most difficult activities is to learn what the real status of the project is. There are many projects that died because it was discovered too late that the project was heading the wrong direction and it was too late.

4. Manage uncertainty

Project uncertainty should be specified on the project -it is called Epics- even if you do not know how to release this uncertainty on the beginning of the project, but it should be identitfied and given a weight to be resolved.

5. Have an Emergency Plan

Every project should have an emergency plan, you need to know who, how and when can be contacted in case of emergency and what availability they are supposed to have. There is nothing that can fully prevent you from having a crisis, os when they do appear, you have to react accordingly.

6. Stop being most of the time under pressure.

When you spend too much time under a high quantity of pressure you will start becoming less productive.

References:

• http://www.makinggoodsoftware.com

Microsoft free Productivity Power Tools

Today, I was reading an article in Visual Studio Magazine. It was representing a guided tour inside Visual Studio 11 from an IDE perspective.

I found that there's a set of IDE productivity improvements that developers across all platforms and languages will notice. Many of these enhancements were available in an update for Visual Studio 2010 under the name 'Productivity Power tools'.

I was really fascinated about the enhancements and was wondering how I did not catch it before!

I installed it and I found that it adds a value to me ,so that I would like to share it to everyone - who might be like me - to use it if he did not.

You could download it (it is 1.37 MB) and read about IDE improvements by clicking here.

Technical Debt

Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase.


No matter how comfortable a schedule looks at the beginning of an iteration, you can't avoid being under pressure some of the time. 
If you find yourself having to choose between "doing it right" and "doing it quick" it is often appealing to "do it quick" on the understanding that you'll come back and fix it later. 


When you make this promise to yourself, your team, and your customer, you mean it. But all too often the next iteration brings new problems or requirements and you become focused on them. 


This sort of deferred work is known as technical debt and it is not your friend, it is a monster that will -on most of the cases- win!


Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. 


In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by re-factoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.

Steve McConnell has a lengthy blog entry examining technical debt. The perils of not ackowledging your debt are clear:

One of the important implications of technical debt is that it must be serviced, i.e., once you incur a debt there will be interest charges. If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets. A common example is a legacy code base in which so much work goes into keeping a production system running (i.e., "servicing the debt") that there is little time left over to add new capabilities to the system. With financial debt, analysts talk about the "debt ratio," which is equal to total debt divided by total assets. Higher debt ratios are seen as more risky, which seems true for technical debt, too.

The tricky thing about technical debt that is unlike money is that it's impossible to measure it effectively. The interest payments hurt a team's productivity, but since we cannot measure productivity, we can't really see the true effect of our technical debt.


References:
- http://en.wikipedia.org/wiki/Technical_debt


- http://www.javacodegeeks.com/2010/12/things-every-programmer-should-know.html


- http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html


- http://martinfowler.com/bliki/TechnicalDebt.html


- http://faheemsohail.com/2011/03/scrum-and-xp-go-hand-in-hand/