Migrating SVN Repositories to Git

I’ve recently had to migrate a few SVN repositories to Git (can you believe there are people out there still using SVN in 2014?). This is a quick guide that walks you through all the steps you’ll need to migrate your repositories including all the history, branches and tags.

The steps below will perform a one-way migration, which is what you want to do when moving permanently off SVN to use Git. There are ways to keep both the SVN and Git repositories synchronized with each other, which I won’t be discussing here.

This short guide is based on Atlassian’s excellent 6-page guide, which you should refer to if you want a more in-depth explanation.

I’ve performed the migration using Git version 1.9.3 (Apple Git) and SVN version 1.7.17. Commands may vary slightly with different versions.

1. Download Tools

The migration can mostly be performed using the Git’s build-in tools, but for convenience, Atlassian has created a set of tools that would make the migration easier.

Download Atlassian migration tools from their BitBucket repository.

2. Mount a Case-Sensitive Disk Image

Skip this steps if you are not doing the migration on OS X.

Migration needs to be performed on a case-sensitive file system. Since OS X isn’t case-sensitive, we will need to mount a case-sensitive disk image to use for the migration.

$ java -jar ~/svn-migration-scripts.jar create-disk-image 5 GitMigration
$ cd ~/GitMigration

This will create a 5 GB disk image called GitMigration.

3. Create Authors File

Next, we need to extract all the usernames that made commits to the SVN repository and convert them to Git’s format of a full name and an email address.

$ java -jar ~/svn-migration-scripts.jar authors http://svnserver/path/to/repository > authors.txt

Open the newly created authors.txt file and modify the generated placeholder names and email addresses to match their actual values.

4. Clone Repository

This will do a svn checkout and convert the repository locally to a Git repository. We are also passing in the authors file we’ve just created to use while converting the repository commits history.

This assumes that your SVN repository uses the standard layout of trunk, branches and tags.

$ git svn clone --stdlayout --authors-file=authors.txt http://svnserver/path/to/repository <git-repo-name>

$ cd ~/GitMigration/<git-repo-name>

5. Clean Repository, Branches and Tags

This will convert SVN branches and tags into standard Git branches and tags.

$ java -Dfile.encoding=utf-8 -jar ~/svn-migration-scripts.jar clean-git --force

6. Add Remote and Push

Add a new remote to the local Git repository.

$ git remote add origin https://username@github.com/team/<git-repo-name>.git

Now push all branches to the newly added remote.

$ git push -u origin --all

And finally, push all tags.

$ git push --tags

Your repository has now been completely migrated to Git. The final step is to forget SVN ever existed and enjoy using Git.


Staying Productive at Home

I hate going to the office everyday. It’s noisy, full of distractions and my home workspace is far more cozy and comfortable to me than the office. I also hate the time and energy wasted on commuting everyday, and there’s no real value of being at the office when most of our work is done online anyway.

Recently I’ve been going to the office less and working from home more. While my experience with working from home has generally been positive and enjoyable, there are some things I had to take care of to make sure that my productivity is actually increasing compared to being at the office.

Every office has a lot of distractions, but your home can have many too. The television, your bed/comfy couch, family and even the fridge can be quite distracting at times. And just like when you’re at the office and you find yourself sitting in front of the computer for hours without getting any real work done, that’s even easier to happen to home.

Here are a few technique that I have been using to keep myself productive at home.

  1. Dedicate an area to be your workspace. Invest in a nice desk and an ergonomic chair. Make sure your workspace is free of distractions and away from noise. Mine looks like this.
  2. Put some structure to your day. While a nice thing about working from home is that you get to have a lot of flexibility around when to start and finish work, and when to have breaks, you still need to design a structured daily routine and try to follow it as much as possible. It surprising how much more productive people can be when they follow a daily routine.
  3. Analyze how you spend your time. Use RescueTime to analyze how much time you spend on each app/website on your computer. You’ll be amazed when you realize that yesterday’s 8 hours of coding where actually 5 and a half hours of coding, 1 hour of communication, 30 minutes of Twitter and 30 minutes of using other random apps and websites.
  4. Block distracting websites/apps. Based on your horrific findings from RescueTime, use SelfControl to set a blacklist of websites to block during your working hours. You’ll be thankful every time you try to check Twitter and have SelfControl kindly remind you that you should be coding instead.
  5. Turns off all notifications. Put both your phone and computer on Do Not Disturb. Email can wait.
  6. Schedule regular breaks. Use BreakTime to schedule regular breaks. I schedule mine every 30 minutes. During that break I get to check email and other things that were blocked using SelfControl. Most importantly I must get up from my desk and walk around for a couple of minutes to release the strain put on my body from sitting.

If you work with a team and you need to communicate daily, working from home can present some challenges. Fortunately, there are lot of tools that help you overcome those challenges. Check this post on Medium about tools to keep remote teams together.


Renault Fluence Initial Thoughts

This is not a complete review of the car, but rather some quick thoughts I have after owning it for a month and having driven it for a little less than 2,000 km.

I previously had a Fiat Grande Punto. I’ve always loved small hatchbacks and I never thought I’d buy a sedan, but I grew out of my B-segment Fiat and I felt that it’s time to upgrade to a C-segment car, and the best choice for my budget happened to be a sedan.

Quality

The car is generally well put together except for the gaps between the body panels and how they fit together, which could benefit from some improvement.

The quality of the interior is quite satisfying. The model I have comes with half leather upholstery and wherever you put your hands you feel nice soft-touch plastics and leather trim. Even the hard plastic parts feel solid and not flimsy.

I have one concern though. There’s a clicking noise the comes out of the steering column when turning the steering wheel. Nothing alarming, so I’ll just wait for my first visit to the service center to have it checked.

Ride

The difference between the ride quality between my previous Grande Punto and the Fluence is night and day.

The Grande Punto had a much harder suspension which makes it seem like both the suspension and my spine are going to shatter into pieces when passing over potholes. The Fluence on the other hand feels much softer and less noisy on potholes, with no significant change in how the car grips around corners, probably due to the bigger wheelbase.

Performance

The 1.6L engine is good. Definitely not built for sporty performance, but good enough for decently-fast acceleration and quick overtaking.

What really makes driving the car so special is the CVT transmission. I won’t go into details about how CVT transmissions work but simply put, it’s a transmission without a gearbox. Instead of the gears, the transmission has a pulley system that gives you an infinite number of gear ratios. The pulleys are constantly changing their sizes to match the engine speed.

When driving the car, this results in a really weird-behaving RPM gauge. Put your foot hard on the gas pedal, and the engine will rev up to 5,500 RPM and just stay there till you lift your foot. You don’t feel the gear changes at all because, simply, there aren’t any. The engine revs will just keep jumping up and down or stay on the same number of revs depending on how hard you’re accelerating.

This kind of transmission might not appeal to everyone, but I really love it.

Equipment

The model I have is really well-equipped. It has auto this and auto that, and quite a lot of sensors.

The Renault Key Card is a joy to use. You just keep it in your pocket and you’re able to unlock and start the car. Walk away from the car and it will automatically lock itself.

I just wish it had bigger wheels because the 16″ ones look hideous with too much rubber around them.

Little Annoyances

The car has a number of little annoyances. First world problems that definitely aren’t deal breakers but make you wonder why couldn’t they just do them properly.

The trip computer has a number of these. It doesn’t calculate trip time, you can only track one trip at a time, it displays fuel consumption in the wrong unit (KM/L rather than L/100km) and the fuel range indicator is wildly inaccurate. All of these are things my much cheaper Grande Punto had/did better.

Another thing is that the steering column-mounted media controls don’t have a way to start a phone call. You can pick up a phone call from there but to start one you’ll have to reach to the central unit.

Conclusion

Overall, I’m happy about my decision. My Grande Punto was an awesome little car that was really fun to drive, but the Fluence is not making me miss it.

Hopefully I’ll be posting a more detailed review later on after I’ve driven the car more.


More on Hiring Software Developers

I wrote a blog post a few months ago about hiring software developers. After which I decided I no longer want to do programming puzzles interviews. I believe the best way to show my skills to a potential employer is to either do a task related to what I would be working on and submit for evaluation, or to work with them for a few days on a actual project.

I’ve recently done an interview that involved a task, and it proved to me that even tasks can be screwed up in a way that shows nothing about the potential hire and does not evaluate their skills in any way.

My task was to request a feed, parse it, and display 3 pieces of information and an image in a list. This task was way too simple to prove anything. Any beginner iOS developer can do this and I thought I would finish it in a maximum of 15 to 20 minutes.

That particular company’s APIs use JSON but they can’t give me access to the APIs, which I do understand. So instead I was given a URL to an RSS feed to work with. While that makes the task a bit harder for me since I never had to parse RSS feeds before, it also makes it even more pointless.

To me it was like going for a driving test, and being told that all I need to do to pass the test is to start the car. That doesn’t prove in any way that I can or cannot drive. To make it even worse, instead of giving me a car, they would give me a truck. Now I need to figure out how to start a truck, to prove that I can drive a car.

I took me 2 hours to figure out how to parse the RSS feed, extract the data I need using regex (since it was all inside a single tag) and present it in a table view.

I ended up being rejected. When I enquired more about the reason I got rejected I was told that it was because of my speed. Again, that is totally pointless. Does completing the task in one hour instead of two prove I’m a better engineer? I would have taken far less time if I worked with RSS before. So was the task’s main goal to test whether I can work with RSS or not? Also pointless, since they don’t need that particular skill (which anyone can learn in a very short time anyway).

I thought that programming puzzles interviews make companies miss out on good engineers because they don’t show their real skills, and that tasks were much better. Turns out you can make tasks dumb enough to do the exact same thing.

Join the discussion below or on Hacker News.


Software Estimates Suck

People suck at estimating how long a task will take. We are often off by a factor of two or more when estimating seemingly simple everyday tasks, like running errands, so imagine how bad we are at estimating complicated tasks like building a new software feature.

Now imagine estimating a set of features instead of just one, or even a whole project upfront. Time estimates in such cases quickly become pointless. The biggest challenge in my opinion about estimating a whole project upfront is that you don’t know the complexity of the problems you are trying to solve until you actually start solving them. Moreover, those problems you are trying to solve never stays the same. Requirements change, problems get more complex and projects often suffer from feature creep.

You’ll be inclined to think that if a task is very similar or identical to a task you have done before, then it’s going to take exactly the same time. You’re wrong. It’s very unlikely that 2 tasks are identical. Chances are the requirements are going to be slightly different, design will change a bit, you’ll be working with different people, etc. These are all things that will increase (or decrease) the time required to finish the task.

One more thing that always make time estimates highly inaccurate is the time needed to fix bugs. You can’t leave that time out, but you also can’t estimate how long it will take to fix bugs you don’t have yet, and there’s no one-size-fits-all time frame that you could assign to bug fixing that would work for all tasks. Sometimes you spend days debugging a single nasty bugs, how could you estimate that kind of stuff?

Moreover, people always ignore the time needed for daily communication. A lot of friction may happen in human interaction, especially if it’s across teams. There is usually misunderstanding and confusion that leads to a lot of delays.

So estimates suck, but they are a necessary evil,  so now what? I like to take Jason Fried’s and David Heinemeier Hansson’s advice from Rework. Never estimate a bulk of tasks. It’s much easier to divide into smaller tasks and put estimates separately. So break the project into many small projects. Your estimates will still be wrong but you’ll be a lot less wrong.

Also, if you’re working in a large development team, you’ll often be surprised at how different estimates from multiple people for the same task could be. My favorite way of dealing with those situations is to play a game, a Planning Poker game. In my opinion, it’s the most efficient way to get people to agree on a reasonable estimate for a single task.

One last thing, never give in to your Pointy-haired Boss‘s request to do the same task in half the time because “you’re a smart engineer, you can do it”. It just doesn’t work that way. While your estimates are probably wrong, they are still your guess of how long it would take to finish that task. No one can simply jump in and ask you to finish in less time, unless they have a very good reason, and of course an arbitrary deadline is never a good reason.

How do you deal with estimates in your team? Let me know in the comment below.


Hiring Software Developers

I’ve been reflecting recently on my past few years working as a software developer. During those years I’ve had a lot of job interviews. I got many rejections, a few job offers and never heard back from some companies.

This is a review, from my own perspective, of what works and what doesn’t work when it comes to interviews and hiring processes for software developers.

The Programming Quizzes Interview

In this kind of interview you have to solve ACM kind of problems, brain-teasers, or general Computer Science quizzes. Things like finding the shortest path to traversing a graph. Any good Computer Science fresh graduate will probably be able to go through such interviews with ease. A few years later though you’ll struggle with answering most questions, simply because they have absolutely nothing to do with what you actually do in practice. Can you even remember when was the last time you had to write an algorithm to traverse a graph? Those interviews are the worst as they give absolutely no indication about how good or bad someone is going to be when they get hired.

You Seem Nice, Here’s a Job Offer

No technical interview, no tasks, absolutely nothing. This has actually happened a couple of times with me and they just left me baffled. If that’s how you have picked the rest of the team I will be working with, then thanks, but no thanks, I can’t work for you.

I’m not really sure how some companies decide to hire people entirely based on how nice their CVs look, or based on a short conversation they had. You’d be surprised by how often people make things up in their CVs.

Go Do a Task and Get Back to Us

I have encountered 2 different kinds of tasks that fall under this category. Some companies give you a generic task that they give to all candidates. Those tasks are usually designed to test your understanding about specific parts of the technologies they are using, your coding style, and how scalable and maintainable your code is. I like those kind of tasks as they show my skills in a much better way than answering some stupid questions on the spot.

What’s even better is the second kind. Your task is actual work on one of the company’s projects and your code might be used in production at some point. This not only shows your technical skills more accurately, but also shows how you communicate with the rest of the team, how you approach the problem and understand the logic business behind it. Most companies that do this kind of tasks pay you for it, whether you get accepted or not.

Come Work With Us for a Few Days

Some companies invite you to come work with them for a few days. You don’t have to be at their office 8 hours a day, but you have to show up at least a few hours everyday for 2 to 4 days. I believe this is the best way for a company to get to know candidates and see how they fit with the rest of the team, it’s also great for candidates to know the people they will be working with and see if they are comfortable working together and also get to experience everything about the work environment of the company. The only problem with this is that it’s often hard to do for candidates already working full-time at another company.

Finally…

If you’re hiring a developer, specially in a startup, I urge you to ditch CVs and traditional interviews. Ask people for their Github accounts. Ask them to tell you about a personal project they have been working on recently. Invite them to come work with you for a few days. Whatever you do just make sure it gives you a meaningful indication about their skills, not how good they are with word processors or solving Computer Science quizzes.

Update: Thanks for the tree vs. graph heads up.

There have been some nice discussion about the article over at Hacker News. Make sure you check it out.

Update 2: Sunil Sadasivan has recently published a very interesting article about the hiring process at Buffer. Check it out on Medium.


9 Things I Learned as a Software Developer

I’ve been working as a software developer for a number of Egyptian tech companies for a little over 3 years, both on full-time basis and as a contractor, and I’ve learned a few lessons that I would like to share here.

I’m not in any way claiming to be an expert or that I’ve got software development demystified, so if you disagree with me please leave a comment and let’s discuss it.

Respect the technology

Your company might not be a software development house, and your main product might not be an app, but if you have an in-house development team, chances are your product relies heavily on technology. So respect the technology and learn to do software development properly. Don’t think that you’ll do just fine if you hire a few mediocre developers and a couple of managers with no technical background whatsoever.

Evaluate work properly

The best software developers aren’t the ones who write the biggest amount of code in the least amount of time. Assessing people by how fast they can get a job done with no consideration to quality is just wrong.

Hire product owners with technical backgrounds

In most companies I have worked with, I’ve seen a major problem with the role of product owners. People with no technical backgrounds struggle with this job. They have completely unrealistic expectations, and in many cases they insist on requirements that are just plain wrong for the technologies being used.

I believe those roles should be played by tech savvy people, preferably software developers who have the qualities needed to be product owners.

Project schedule is determined by the people who build it

A project’s schedule should be determined by people who are going to build it, not by project managers or marketing managers.

“But can’t we do better?”, the project managers will wonder as soon as they hear the developers’ estimates. If you’re working with developers who are really good, they will know how long to takes to finish a task, but they can’t change it, at least without compromising quality or changing the specs.

Trust your team

I know trust is earned not given, but you really can’t distrust people with basic stuff like the fact that will actually do work while working remotely. If you don’t trust me with that, just don’t hire me.

Fire people when you need to

I have never seen anyone get fired. Even people that cannot pull their own weight and it’s obvious to everyone that they are slowing the team down. Those should really be fired.

Fast and good is not cheap

Everyone seems to be ignoring the basic fast/good/cheap rule of software development. You can only maximize two of these while compromising on the third. You want a high quality product and you want it fast? That’s going to cost you a lot of money. You want it fast and cheap? It will be buggy. Of course these aren’t binary switches, and you could always find a balance between the 3, but you just can’t have all three.

Don’t give fake titles

Top managers should not be dictators. Hire good people and let them do their job. Don’t hire people that you use as a tool to turn your commands into code or artwork. Don’t give people fake managerial titles when they have no say whatsoever in decisions related to their work or the work of the people they are supervising.

Don’t expect people to use their own hardware

I can’t believe I actually have to include this, but a few companies believe that you should be using your own personal hardware (computer/phones/tablets) to get their work done. Should I pay my electricity bill too? This is completely unacceptable. If you can’t afford to buy your team the hardware they need, then you can’t afford to hire them. So simply don’t.

Don’t let this post make you think that I have had 3 horrible years in my career. These are just the things I don’t like, and I can’t deny that I have learned a lot at each company I have worked at.


TracKit 1.0

I’ve shipped the first version of my new app, TracKit, today. It’s a little tool that I personally love to use.

iOS Simulator Screen shot Sep 11, 2013 10.27.39 PM

I  love tracking things, lots of things. I might even be guilty of overdoing it. I like to track the number of hours I sleep, how many kilometers I manage to get out of each tank of gas, the time I spend commuting and lots of other stuff. If at this point you think I’m weird then this app is definitely not for you.

The reason I track this kind of stuff is to be able to get a quick overview of how I’m doing at anytime, and try to optimise it. I built an iPad app a long time ago that I used for this purpose, but it was far from perfect, even for my own needs. So I never even thought about releasing it. A few weeks before WWDC when iOS 7 was announced, I was seriously considering building a new version which does the same thing with a few extra features. By the time iOS was first previewed I had already made up my mind and started building it as soon as I was able to download the new SDK after the keynote was finished.

The goal was simple. Build an app that would help me track all the crazy things I like to track, visualise my performance with a graph, and show me stats that would give me a quick overview about how I’m doing with what I’m tracking. And the result was TracKit.

I might be the only crazy person that likes to track things happening in their life, or their might be a lot of other people who also need this app. In either cases, I’ll keep building TracKit until I’m personally satisfied about it. So I have a lot of exciting features planned for the next few months. In the mean time, go get it from the App Store and let me know what you think.

button-downloadontheappstore-flat


Mobile Operators Spam Has to Stop

If you live in Egypt you have probably received numerous unsolicited commercial advertisements through SMS. This has got to be the worst form of advertising and it has to stop.

You might think that the phone numbers that receive these messages are picked randomly, or through curated lists of phone numbers like what happens with spam email, but it’s much more than that. This service is actually provided by mobile network operators in Egypt. They sell your information to advertisers to send you spam SMS based on your location, the value of you phone bills, your interests – which you are asked about when you open your online account – and other criteria. So advertisers are not only spamming you with unwanted messages, but they are also doing it through the mobile network operators, which you as a subscriber never gave them permission to sell your information or to send you unsolicited promotional SMS.

It’s not like mobile network operators are providing you a free service that they have to somehow cover its cost with an alternative source of revenue. You pay monthly subscription fees and service charges to the mobile network operator and you have the right to demand this to stop. This kind of messages should be opt-in, if they exist at all, and as far as I know there’s currently no way to opt-out of it.

In the United States, EU and Australia SMS spam is criminalised and violators may face substantial costs which has reached up to $175 in some cases for each spam SMS sent. Operators like AT&T, T-Mobile, Verizon and Spring in the US allow you to report any spam SMS you receive by forwarding it to a number. Reported spammers are then disconnected from the network and faced with legal charges.

I can’t see this being criminalised in Egypt anytime soon as the mobile network operators could easily lobby the government out of making such rules and regulations, but at least we should get a way to opt-out of it.

What are your thoughts on SMS spam. Does it really bother you? And what can we do about it? Leave a comment below.

Update

Turns out that on Vodafone you can call customer support and request to be unsubscribed from all the promotional messages and calls sent by Vodafone. This only solves a small part of the problem, but still worth doing.

Not sure if this is available on other networks or not.


5 Essential Apps for Every iOS Developer's Toolbelt

I believe the 5 apps below should be in every serious iOS developer’s toolbelt. They save a lot of time and frustration and help you produce apps with a higher quality. Some of them might be a bit pricy but, trust me, they are worth the investment.

Spark Inspector – $39.99

Debug your app’s interface in a three-dimensional view and change views properties at runtime. This has proven to be an amazing tool to debug complex UIs.

screen_0

 

Kaleidoscope – $ 69.99

Kaleidoscope is a diffing tool on steroids. It compares differences between text, images or folder and lets you merge changes in seconds in an elegant way.

3UP_Fluid

PaintCode – $99.99

PaintCode is a vector drawing app that generates Objective-C code in real time. Use the vector drawing tools to draw your UI components and PaintCode will generate the Objective-C drawing code. Great for writing reusable components.

 

titlescreenshot

 

 

Deploymate – $19.99

Before releasing your app, Deploymate will come in handy in helping you identify unavailable, deprecated and obsolete APIs in your code. Great to prevent embarrassing crashes from using APIs that aren’t available in your deployment target.

ss5

Tokens for Mac – $29

When you’re finally ready to release your app, Tokens for Mac is the easiest way to generate, share and track promo codes. It even makes the redemption easier for people you’re sending out the promo codes to.

2012-11-20_211814-tokensmain