Installing & configuring Git on Fedora

First thing first - Let's install git. There are two major ways we can install git 

• install from an existing package
• install it from source or

installing from an existing package: Easy, Open up Terminal and type the following command:

$ sudo yum install git-core ~/.ssh
$ sudo password for username: type your password here 

installing from source: It’s generally useful to install Git from source, because you’ll get the most recent version. Each version of Git tends to include useful UI enhancements, so getting the latest version is often the best route if you feel comfortable compiling software from source. It is also the case that many Linux distributions contain very old packages; so unless you’re on a very up-to-date distro or are using backports, installing from source may be the best bet.

To install Git, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you’re on a system that has yum (such as Fedora), you can use the following command:

$ sudo yum install curl-devel expat-devel gettext-devel\
openssl-develzlib-devel

Once the installation is done you can do

$ git --version

this will show the version of Git you are using.

Now that you have Git on your system, you'll need to configure Git to use it. Following step you need to follow for configuring but before we start I am assuming that you already have a github account, if not please create an account in github.

Step 1: Check for SSH keys

First, we need to check for existing ssh keys on your computer. In the Terminal, type:

cd ~/.ssh
ls
# Lists the files in your .ssh directory

Check the directory listing to see if you have a file named either id_rsa.pub or id_dsa.pub. If you don't have either of those files go to step 2. Otherwise, you already have an existing keypair, and you can skip to step 3.

Step 2: Generate a new SSH key

To generate a new SSH key, enter the code below. We want the default settings so when asked to enter a file in which to save the key, just press enter.

ssh-keygen -t rsa -C "your_email@example.com"
# Creates a new ssh key, using the provided email as a label
# Generating public/private rsa key pair.
# Enter file in which to save the key (/home/you/.ssh/id_rsa):
ssh-add id_rsa

Now you need to enter a passphrase.

Enter passphrase (empty for no passphrase): [Type a passphrase]
# Enter same passphrase again: [Type passphrase again]

Which should give you something like this:

# Your identification has been saved in /home/you/.ssh/id_rsa.
# Your public key has been saved in /home/you/.ssh/id_rsa.pub.
# The key fingerprint is:
# 01:0f:f4:3b:ca:85:d6:17:a1:7d:f0:68:9d:f0:a2:db your_email@example.com

Step 3: Add your SSH key to GitHub

Run the following code to copy the key to your clipboard.

sudo yum install xclip
# Downloads and installs xclip. 

xclip -sel clip < ~/.ssh/id_rsa.pub
# Copies the contents of the id_rsa.pub file to your clipboard

Alternatively, using your favorite text editor, you can open the ~/.ssh/id_rsa.pub file and copy the contents of the file manually.

Now you to open the Browser and perform the following steps 

1. Go to Github Account Settings
2. Click SSH Keys in the left sidebar
3. Click Add SSH Key
4. Paste your Key into the Key field
5. Click Add Key
6. Now Github will prompt you for your github password to Confirm the action.

Step 4: Test everything out

To make sure everything is working you'll now SSH to GitHub. When you do this, you will be asked to authenticate this action using your password, which for this purpose is the passphrase you created earlier. Don't change the git@github.com part. That's supposed to be there.

ssh -T git@github.com
# Attempts to ssh to github

You may see this warning:

# The authenticity of host 'github.com (207.97.227.239)' can't be established.
# RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
# Are you sure you want to continue connecting (yes/no)?

Don't worry, this is supposed to happen. Verify that the fingerprint matches the one here and type "yes".

# Hi username! You've successfully authenticated, but GitHub does not
# provide shell access.

If that username is correct, you've successfully set up your SSH key. Don't worry about the shell access thing, you don't want that anyway.

Well we are done! Hope this helps.

A Practical Guide: Story Points-Based Estimation

Glad to see that my article made it +Scrum Alliance

http://www.scrumalliance.org/community/articles/2014/january/a-practical-guide-story-points-based-estimation

The road to Continuous Delivery

Continuous Delivery it's a software development practice where you make sure that your application is ready to be deployed to production at any time. You’re not only making sure that when a developer commits a change is, it is correctly integrated by building and unit testing your application (Continuous Integration). You’re also making sure that your application is always ready to be deployed by running automated and/or acceptance tests on it and testing the release process itself.

Practicing Continuous Delivery gives you several advantages:

+The time from idea to deployment to production (cycle time), is shortened.

+By shipping the product early you are encouraging early feedback. The faster you get your software to your end-user, the faster you get feedback.

+You’re always ready to deploy to production. You do not have to spend time making and testing a release.

+Because you’ve already tested the release process itself, deploying to production is simple and error-free.

+You are getting ahead of the competition and making your release process a business advantage.

How to implement ?

• Ensure both your developers and system administrators are responsible for deployment. Traditionally, the system administrator is responsible for deploying to production. By making your developers responsible too for deployment you are encouraging a culture of collaboration (DevOps) and lowers the chance of errors due to miscommunication.
• Find out what your release process looks like, make it reliable and repeatable and automate as much as possible. Make every step of the process reliable and repeatable. When your steps are reliable and repeatable, then they can also be automated. As our goal is to automate each step.
• Setup one single way of deployment to an environment. Make sure that you define a single way to deploy a release to an environment, whether is it the test environment or to production. If you do this, then you’re also testing your deployment process itself.
• Test on a production-like environment. If you test on a different environment than your production environment, then there is a risk that your deployment to production doesn’t work or worse: your end-users experience runtime problems due to different software versions of third-party software and libraries.
• Quality first Keeping your application deployable should get higher priority than adding new features. If an error in your release process occurs, fix it as soon as possible.

Where do I start ?

It takes effort to fully practice Continuous Delivery. But you may start slowly by:

• Let your developers and system administrators work together on deploying your application.
• Visualize your release process.
• Make steps of your release process reliable and repeatable

Get Real

An introduction to Smaller, faster, better way to build software. Well then, it's time to skip all the unnecessary stuff and focus on build the real thing. Some of it I have listed here which you can stop doing and build the real thing.

Let's get rid of >>>>

Timelines that take months or even years

Pie-in-the-sky functional specs

Scalability debates

Interminable staff meetings

Useless paperwork E.g. charts, graphs, boxes, arrows, schematics etc.

The “need” to hire dozens of employees

Meaningless version numbers

Pristine roadmaps that predict the perfect future

Endless preference options

Outsourced support

Unrealistic user testing

Top-down hierarchy

Let me know if above these helped you anyway ever to build the real thing.

***Then how to build the real thing!

Do you remember Agile Manifesto(s) ? Read more

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer Collaboration over contract negotiation

• Responding to change over following a plan

Interestingly if you follow what I have listed above and get rid of the ones I mentioned, you will see how quickly you be adapting to these new changes and start building the real thing early before your competitor builds it :-) Sounds easy ! Well then it's time to Be Agile and follow Scrum !

With the advent of Object Oriented Software development methods it became easy to break large software projects into very small components and therefore able to take advantage of the building incrementally during Sprint, build the MOST important feature first. Since each sprint outcome is working element of the product this ensures rapid feedback and adjustment to the changing needs to the marketplaces.

Let me provide you an quick introduction to Scrum Vocabulary (Note: this is probably the smallest introduction I have ever written :-) So feel free to read other relevant ones you will find in my blog)

What is it ? 

Scrum provides a language for this common sense way of organizing, performing, and managing work.

Product Backlog:

All work to be performed in the foreseeable future, both well-defined and requiring further definition.

Sprint:

A period of 30 days or less where a set of work will be performed to create a deliverable.

Sprint Backlog:

That work that is well enough defined that it can be worked on with relatively little change over a period of 30 days or less and will result in a tangible, incremental deliverable.

Scrum:

A daily meeting at which progress and impediments to progress is reviewed.

Do you agree with me with the benefits of Getting Real ?

Getting Real delivers better results because it forces you to deal with the actual problems you’re trying to solve instead of your ideas about those problems. It forces you to deal with reality.

Getting Real foregoes functional specs and other transitory documentation in favor of building real screens. A functional spec is make-believe, an illusion of agreement, while an actual web page is reality. That’s what your customers (whether internal or external) are going to see and use. That’s what matters. Getting Real gets you there faster. That means you’re making software decisions based on the real thing instead of abstract notions.

Finally, Getting Real is an approach ideally suited to web or mobile-based software. The old school model of shipping software in a box and then waiting a year or two to deliver an update is fading away. Unlike installed software, web apps can constantly evolve on a day-to-day basis. So far it I have taken advantage of this approach of Getting Real. Are you thinking ? I think it's worth a try! 

"Agile"

I know you may have read many articles and probably tried picturing the definition of "Agile". But if you are confused by complicated terms then this post may help you. I have tried to put it in simpler terms.

Let's go over what is Agile ?

Agile is a philosophy that uses organizational models based on people, collaboration and shared values. Agile promotes three core values : trust, transparency and collaboration.

How it works!

Agile uses rolling wave planning; iterative and incremental delivery; rapid and flexible response to change; and open communication between teams, stakeholders and customers. There are many agile methodologies that adhere to these tenets, such as Scrum, XP, Lean and Test-driven Development (TDD), etc.

How it helps!

Agile principles and practices are topics of growing importance in project management and used by most successful companies. Project management practitioners, software development teams can use agile principles and practices to successfully manage change,improve communication, reduce cost, increase efficiency and demonstrate value to customers and stakeholders.

Let's go over few core agile principles and practices (tried putting together in simpler terms)

• Early, measurable return on investment through defined, iterative delivery of product increments.
• High visibility of project progress allows early identification and resolution or monitoring of problems.
• Continuous involvement of the customer throughout the product development cycle.
• Empowerment of the business owner to make decisions needed to meet goals.
• Adaptation to changing business needs, giving more influence over requirement changes.
• Reduce product and process waste.

Hopefully this helps you understanding the principles and practices agile proposes. I will post about Agile Manifesto on my next post.