How to tell git to use a specific private key

When setting up automatic deployment on a software project using git, you may want your server to be able to automatically pull changes from the repository. Popular repo hosts like Github and Bitbucket will usually need your server’s public SSH key to allow access. Assuming you have a server with multiple SSH keys, it may become important for you to specify which SSH key to use for specific users when using git. Here I explain how to make git use a specific private key when accessing Github.

In ~/.ssh/config, add:

host github.com
 HostName github.com
 IdentityFile <path to id rsa file>
 User git

Now you can do git clone git@github.com:username/repo.git.

Make sure the permissions on IdentityFile are 400.

Sources

ssh – How to tell git which private key to use? – Super User. http://superuser.com/questions/232373/how-to-tell-git-which-private-key-to-use

How to disable Root Login via SSH on Ubuntu

Disabling root access via SSH is a good security measure for any public-facing web server. This is because some hackers targeting linux servers know that there’s always a root user and often try to gain access to a server using brute force for that user. So here’s how to disable root login via SSH on ubuntu.

First, make sure there’s at least one other user with sudo privilege. If none exists, create one with the command:

sudo adduser <someuser>

sudo adduser <someuser> sudo

Next, edit /etc/ssh/sshd_config using your favourite editor.

Find the line:

PermitRootLogin yes

and change it to

PermitRootLogin no

Save and close the file.

Restart SSH daemon using the command

sudo service ssh restart

Lessons From a Successful Hackathon

I was part of a group that took part in the World Port Hackathon in Rotterdam from September 4 to 5. The theme of the event was to develop apps or concepts that improve Logistics and Connectivity, Infrastructure or Safety & Security at the port. There were about twenty teams participating in the event and our group Captain Co & Co won the Overall first prize as well as a nomination to participate in Innovation Lab. This article discusses some things I learnt by participating in this event.

You can see my team members with the €1.500 and Nomination Launchlab placards.
You can see my team members with the €1.500 and Nomination Launchlab placards.

First, have a good idea. Our group came up with the idea of making a chat app for port workers. It was an exciting idea. I didn’t know of any other such application on the market and chatting is something we do ubiquitously in the IT world. It was great to introduce such a concept to the shipping industry.

Second, it is important to delegate tasks effectively among team members. There were eight members from my team taking part in the event, four of whom were developers. Among us developers, we split the task of creating the app fairly quickly as the project started. For example two developers developed bots, one took care of the back end server and one handled the front end. The remaining team members handled other aspects like graphics design, testing, idea generation, some programming, getting information from relevant officials at the port concerning data, port processes, etc. and feeding that back to the team.

Third, plan your work carefully. Good communication is essentially when hacking. For example, I remember going away with one of my colleagues to a quiet place to discuss chat APIs, including what format to put data in when communicating between the server and the front end. We did this before starting to code. As such, we both knew how data will flow and could create our parts of the app in parallel, integrating the finished results fairly quickly afterwards. I believe other members had similar plans.

Fourth, you must work hard! Good things come with effort. We put in a good chunk of hours into our app. I remember seeing some other teams looking so relaxed and wondering what kind of apps they were building. As an official at the event later mentioned to us after the event, we looked like a CSI team while we worked. We spent several hours on the project on that Friday and even when the port closed for the night, we went back to our hotel and continued working on the project late into the night. It was rigorous, but fun!

Fifth, do not try to write pretty code. Write it fast and make it work! A hackathon is a hackathon, it’s not a time to write the best looking code. We developers had to create a chat app from scratch that met certain specification, including pulling port-related data, in a relatively short time span. As such on my part I had to write the shortest possible amount of code to get my part of the app working and nothing more. There was no time for fancy things like elaborate frameworks, automated tests, etc. Testing was manual.

Sixth, keep it simple and clean but make sure it works. This is very important in succeeding in a hackathon. Our team had to think carefully of what features we would be able to to our chat app add given the time constraint and available man power. Also, while we produced several interesting features in our app, there were times when we found that a proposed feature didn’t look or work as good as wanted it to. In such situations, we simply left out the feature. So, very important: If you are hacking together an app and one of your features doesn’t look nice, don’t be afraid to remove it. In short, we had to make sure that every feature presented worked. Our chat app was one of the few apps in the entire competition that actually did something; i.e. we could actually chat with it. Many other competitors just presented concepts, diagrams and so on.

Seventh and finally, present your product enthusiastically. We were very cheerful in our presentation of the end product. Our presenter spoke with confidence and all of us team members participated in the presentation by taking part in the chat right there and then.

In conclusion, I had a lovely time taking part in my first hackathon and being on the winning team. I learnt quite a few things about successfully hacking together an app within a short time including the importance of a good idea, delegating tasks effectively, careful planning, putting in your 100%, coding quickly, keeping it simple and effective presentation. Hope you enjoyed the read.

How to check if an ip address matches a CIDR

When working in the area of application security, you may come across situations where you need to make sure that only certain servers are allowed to access your web service. Usually checking the ip address is a decent way of making such guarantees.

You can use a function as follows:

function cidr_match($ip, $cidr)
{
    list($subnet, $mask) = explode('/', $cidr);

    if ((ip2long($ip) & ~((1 << (32 - $mask)) - 1) ) == 
ip2long($subnet))
    { 
        return true;
    }

    return false;
}

Example results

cidr_match("1.2.3.4", "0.0.0.0/0"): true
cidr_match("127.0.0.1", "127.0.0.1/32"): true
cidr_match("127.0.0.1", "127.0.0.2/32"): false

Sources:

http://www.php.net/manual/en/function.ip2long.php#82397

http://stackoverflow.com/questions/594112/matching-an-ip-to-a-cidr-mask-in-php5

Some Cool Operations with SVN

How to add all untracked files in SVN:

svn st | awk '/\?/ {print $2}' | xargs svn add

How to remove deleted files from version control:

svn st | awk '/\?/ {print $2}' | xargs svn add

Note: the add command above may not work if the file name has space in it. A command to use instead may be:

svn st | grep '^?' | sed 's/^[? ]*/"/' | sed 's/$/"/' | xargs svn add

Sources

version control – How do you add all untracked files in svn? Something like git add -i? – Stack Overflow. http://stackoverflow.com/questions/160104/how-do-you-add-all-untracked-files-in-svn-something-like-git-add-i

How to run benchmark with Siege

From time to time, as a web developer you may want to run http load tests against a website to make sure it can handle adequate traffic. An excellent software for this is Siege. So, first, install Siege. On a Mac you can do this using brew as follows:

brew install siege

Once installed, run your test using a command like:

siege -c 10 -r 5 -b http://somesite.com

This runs 5 requests on 10 concurrent connections against somesite.com.

Using Nose Clips

While having a leisurely swim at the pools a few weeks ago, I came across a girl, Ashley, who swam so well I thought she must be good friends with fishes. So, as we talked a bit, I asked her for some swimming tips. She recommended a few things including the use of nose clips. She explained that when you clip your nose shut, it forces you to concentrate on breathing properly through the mouth while swimming. Also, it prevents water from running up your nose. She told me I could get these from a sports shop.

The next time I swam, I noticed that one of my biggest discomforts was that I sometimes accidentally let in water through my nose, causing fits of coughing. Remembering what Ashley said earlier, I made up my mind right there and then that the next time I visited the pool, it will be with my nose clips. So, I hit Sports Direct and bought a fine nose clip.

A few days later it was time for swimming lessons and I was ready to try out my trusty nose clips. First tip, for those of you with oily noses, you may have a hard time wearing nose clips right away as they may keep slipping off. It’s advisable to first take a swim for a few minutes to get that oil off your nose. Then try on nose clips. Once I had the nose clips on, I noticed that I had to breath in deeper through the mouth to get comfortable. It was amazing to see that even with my nose completely blocked I could breath steadily through the mouth. With this improved depth of breathing, I found that I could cover greater distances during front crawl before needing to face outwards for breath. Furthermore, there was no longer the case of water running up my nose. So, indeed nose clips are a good investment for the neophyte swimmer.

Now, please note, they are good just to help you learn to breath well through the mouth and reduce discomfort of water getting up the nose. Once you learn how to breath sufficiently deeply and properly (blowing bubbles in water for example) and are able to float well, there should be no problems with water getting up your nose and you can safely discard nose clips.

Managing Expectations at Work

Managing expectations is something a Software Engineer needs to practice routinely. In fact, this applies to all careers, not just Software Engineering. Being a Software Engineer though, it’s easier for me to relate this to you from that perspective.

So, what does it mean to manage expectations? It means that before promising to provide a service or do something for someone, you and that person must have a clear understanding of what exactly is to be delivered and that you deliver on your promise. In this article I will discuss a few qualities Software Engineers must have in order to manage expectations more easily.

As an ambitious Software Engineer new to the trade, there’s a tendency to over-promise. When confronted with a project/task/problem, etc. there’s an urge to look at it and quickly go “Oh, that looks easy. I can do it in one hour.” What then happens is the Engineer gives the company management an estimate of one hour. The company could then give its clients or customers an ETA based on the employee’s estimate. Then the project starts. Now that the employee has to write serious code for it, he/she takes a thorough look at the requirements and discovers to his/her utter bewilderment that it may take a day! What happens then? Assuming all available resources have been expended, the project will generally get delivered late, breaking trust of the client/customer in the company and the company in the employee in question. In this scenario, the employee has not managed expectations properly. So what can Software Engineers do to manage expectations better?

A very important quality one needs in order to manage expectations properly is being able to ask questions when in doubt. When you are asked to deliver a feature or do a service and you aren’t really sure of how it is meant to work, don’t quickly cook up some assumption and rush off with it. Rather, ask a question or two. Don’t be afraid to look stupid for not understanding what is required. Even if you feel your question may seem naive, you should still ask it up front and gain understanding, rather than assume and potentially fail to meet expectations. Pardon my French here, but there’s a very good saying that sums this up. It goes as follows: Assumption is the mother of all fuck ups. So, in short, always ask questions when in doubt.

Also, you must be able to raise flags ASAP. When you promise to deliver something at a particular time, e.g. say you want to create a website X and have promised to deliver it in 2 days. What happens if after the first hour you discover a big problem with the task which you didn’t anticipate? Do you panic and start figuring out how to fix it on your own? No! A good communicator must raise flags with appropriate stake holders as soon as problems are found during task execution. As such, you should let your manager know as soon as you run into non-trivial obstacles. When you do this, it is easier to agree quicker on an appropriate course of action perhaps in terms of finding an alternate solution or letting a client know early that a project may be delayed. The earlier you raise flags, the better.

Furthermore, you need to know your strengths and weaknesses and be honest about it to others. If you don’t know about how to go about satisfying a need or approaching a problem, don’t act like you know. For example, what do you do if you are asked to say how long it will take to create some feature X, Y, Z which you have never even heard of or are only very vaguely familiar with? A wrong approach will be to take a superficial look and say, “Well, I sort of think it might take X days.” A more appropriate response should be “Well, I’m not familiar with this feature. Let us allocate some time to research on it and figure out how best to approach it and how long it will take.” Another example of this is in the aspect of deciding if to take on a task at all or not. If your boss asks you to perform a certain task and you know that you are weak at doing tasks like that and also know a colleague who is stronger at that sort of task, rather than say “Yes sir!,” do the task and complete it badly, a smarter response is “I can work on this task, but it may take me a while to do it. Person X here may be more suitable to do the job as he/she is better at this sort of task.”

In addition, you need to be able to give yourself a margin of error. If you are asked to quote how long it will take to perform a task and you have a gut feeling it could take say 2 hours to do it. Do not for the love of God say it will take 2 hours. What if there is some aspect of the task you haven’t yet considered and will only see once you start working on it? You need to be able to account for uncertainty. So a smarter estimate might be 3 or even 4 hours. So, don’t try to impress your boss with how quickly you think a task can be done, only to fail at it when actually asked to do it. In short, you need to give yourself a margin of error. This is especially important when estimating tasks on the fly in sprint planning meetings. Now, don’t go around doubling all your estimates in meetings. The margin of error you add to your estimates should be commensurate to how much uncertainty you have about the task at hand. So, for trivial tasks, you can afford to give estimates that match your gut feeling, but for bigger or unfamiliar tasks, you should increase your estimate by a larger factor. When you make a habit of accounting for uncertainty, you will find it significantly easier to complete tasks within your given time estimates and keep everyone happy.

One more things that is very important in managing expectations is being thorough. Before you promise to deliver something in a certain time, you need to make sure as much as possible that you have thoroughly analysed the task, thinking not just of regular use cases, but edge cases. In short you need to learn to ask lots of “What if” questions.

Another important point is that you need to be empathetic. Put yourself in the shoes of the person you want to perform a service for and honestly think about what he/or she will expect. Then, think of what effort it will take to perform the task and let that guide you on your promise to such client. Empathy is very important especially in places where you need to make assumptions for yourself because even though I have mentioned earlier that you should try not to make assumptions, we know there’re always some places where we Software Engineers must use our best judgement to assume things. So, if you must assume something about a service you provide to your client, think about it from your client’s point of view.

A final point is that you need to be willing to go an extra mile to complete tasks promised. When everything mentioned above fails, you must be ready to put in extra effort to get things done on time. This may be in the form of working longer, harder, faster or smarter. Ideally we should be able to deliver on our promise without too much extra work, but we know that sometimes things just don’t pan out that way. So, when the going gets tough as they say, the tough gets going.

In conclusion, I’ve talked about ways people, especially Software Engineers can manage expectations at work. This includes things like asking questions when in doubt, raising flags early, understanding one’s strength and weaknesses, giving margin for error before making promises, being empathetic and going the extra mile to deliver on promises. I hope you find some of these useful. Take care!