Please don’t leave old out-of-date code commented out; just delete it

If you replace code, and commit out the original while you are working, please delete the commented out code before you commit.

Code such as:

int x = foo() + 1;
// int x = foo() + 2;

Becomes pretty unreadable after a time.

It makes sense to you while you write it, but in 2 years, and looked at by another developer, it will probably not make any sense.

We all use Subversion or git etc., so if you do realize you need the old version at any point in the future, it’s still there.

And this is a good point too:

If it’s commented out, then it may rot: when you suddenly decide that you need it again, you realise that it no longer compiles, or needs to be rewritten to make it fit with other things that have changed in the meantime.

So you can delete away without fear :)

Windows Phone onenote size limit

onenote is a great tool, my favourite note taking app I’ve ever used. It works great on my Windows Phone 8.0 and the web version is OK too. I’ve been using it for a few years and it’s always worked flawlessly.

Recently, when I added something to a note on the phone then pressed “back” the app would crash, and the change would be gone. Changes I’d made on the web to the note would not be synchronized. Trying to synchronize manually on the phone (up until then not necessary) simply said the synchronization had been successful (without the changes from the web version showing up).

All other “notes” (pages) were not affected, just this one.

The solution: delete content from the note. It seems that a note beyond a certain size (about 10 pages on my phone) just won’t synchronize.

Persistent Login (the “remember me” checkbox)

It is a requirement of many customer projects of mine to have a “remember me” or “keep me logged in” checkbox on the log-in form. I am not aware of any standard approach to the subject; I suspect every company invents their own (and then blogs about it?) Here’s what I do when asked to implement this feature.

Here are the requirements as I see them:

  • Users should be able to use the “remember me” function from one computer (e.g. home) but not from others (e.g. internet cafe)
  • Users should be able to use the “remember me” function from as many computers as they like (e.g. home, their phone, ..)
  • Typing the user name, password and “remember me” should remember only this user name and password; thus, if they change their password using another computer, this “remember me” should stop working.

Here are some thoughts on various options:

  • One possibility would be to store the user’s password in a browser cookie. We shouldn’t do that, because although stealing any form of persistent login cookie would mean the thief could log in, if the password is in plain text in the cookie then the thief could also do certain operations protected by the password such as delete account, change email address, password, etc.
  • We store the password hashed with bcrypt in the database; one possibility would be to store the hashed password in a browser cookie. But then, if someone stole our database, they would have the bcrypt versions of every password in our database, they would be able to imitate any user by setting the bcrypt password in their cookies. That’s why we use bcrypt at all, to prevent being able to immediately log in as any account if the DB gets stolen. (One could argue they have already stolen our db in this case, so the extra harm of imitating a user would arguably be marginal; but they might still be able to e.g. send messages to other users by using the site)
  • We should not bcrypt the bcrypt and store that in the cookie. Because then, as above, anyone who stole our bcrypt passwords can just bcrypt them and again impersonate any user.
  • If we generate any “code” or “token”, we should store it bcrypted in the database. Otherwise, once again, any user who steals our db, has all tokens, and can impersonate any user.
  • Because we store the token bcrypted, even we can’t get back to the original token. The user must have “persistent login” capability from more than one computer. Therefore, we would need to store one “token” per user’s computer. (Otherwise e.g. user logs on on computer A, token generated, stored in client, bcrypted stored in DB. User logs on on computer B, cannot send token to client, we don’t know what it is. If we overwrote it, computer A couldn’t log on any more).

So this is the approach we take:

  • If the user logs in and clicks “remember me” then we
    1. Create a random:
      • client_id (= representing their computer)
      • random token (= representing their authorization on this computer)
    2. Set these in long-term cookies:
      • persistent_login_id (the ID of the user trying to log in, or email address thereof, or whatever)
      • persistent_login_client_id
      • persistent_login_token
    3. Insert a new row to the new table “persistent_login”, with fields or similar with fields: login_id, client_id, token_bcrypt, last_used_utc
      • login_id
      • client_id
      • token_bcrypt is bcrypt of (current password in bcrypt form (it’s the only form of the password we have at this point), and the token)
      • last_used_utc = now
  • If the user comes to our site and has no session or is logged out, and all three of these cookies are set, we:
    1. Find the row in the table for the (login_id, client_id) as according to the cookies
    2. Check to see if the token from the cookie is correct, against the bcrypted version in the row
    3. Log the user in silently if the values are correct
    4. Set “last_used_utc” in the db row to be now.
  • If the user changes their password, next time a computer attempts to log in using this mechanism, the “password_token_bcrypt” will not match, therefore this has the effect that changing the password invalidates all persistent logins across all devices. (Another alternative would be to to not use the password when hashing the token and simply delete all rows if the user changes their password; but I fear there will be a password change facility somewhere which will forget this deletion; with this approach there is nothing to remember to do and thus nothing to forget to do.)
  • Cleanup process cleaning up rows which haven’t been used e.g. in one month.

Here are some non-requirements as I see them, although various blogs and articles on the internet assert they’re very important. I cannot see why they are important, but if anyone would enlighten me, I would be most appreciative.

  • Time limited persistent logins
  • One blog says, each time a persistent login is used, one should overwrite the cookie with a new persistent login. Can’t really see what (realistic) attack that prevents us from.

Apologies for using the term “computer” in the above text rather than the more accurate term “client”, but it seemed to make the whole thing easier to understand.

Further reading:

As a customer, I want to see up-to-date costs I’ve incurred, using a web application

I think it’s important, that in a software development company, as all others, customers get transparent up-to-the-minute information about what costs they have incurred. Alas my company can’t provide that at the moment, due to our tooling (this is a deficiency, or at least difference of opinion, between me and LiquidPlanner, the tool we use for tracking time.) This is the email I sent to LiquidPlanner support explaining my position:

I and my team do work. We use LiquidPlanner to track our done time. I can export the timesheet data and write invoices to my customers once a month. So far so good.

However, imagine half way through the month, a customer thinks “I wonder how much work Adrian and his team have done? My budget is a bit tight, I hope they’re not working too much, and I’m going to get a bill I can’t afford!”.

  • For my cellphone I can log into my cellphone provider’s website and see more-or-less up-to-date information about how many calls I’ve made and what their costs are.
  • With my credit card I can log in and see what I’ve already purchased this month.

I would like that my customers are able to log on somewhere, and see, “what work has Adrian’s company done, that I haven’t been billed for yet?”

My customers currently get a “shock” when they receive the bill at the end of the month.

  • On one side, obviously I want them to be informed, and know how their bill is increasing as each day goes by, for the sake of transparency.
  • On the other side, it’s a good argument for me, if the customer asks us to do lots of work during a month, and then when I send them the bill, says “I didn’t know you were working this much! I can’t pay the bill!” after we’ve already done the work. If I can argue “You could have logged in any time to see how the charges were progressing” then I have a better argument that they have to pay the bill.
  • It’s a good argument to my employees to keep their timesheets up-to-date: if they know customers might use the information without warning at any time. (Employees, otherwise, are not notoriously good at keeping their timesheets up-to-date..)

One company I worked for used Redmine to track time. Their customers could log in to Redmine and see the amount of work done. This was a simpler system, in this case they could only see “Employee X has worked N hours this month”, but as I charge a fixed hourly rate per employee (not per project, not per activity) this would have sufficed for my purpose.

“Facebook Background Task Host” consuming 100% disk bandwidth

The program “Facebook Background Task Host” was consuming the entirety of my disk bandwidth on my Windows 8.1 computer. Further, there seemed to be almost nothing written about this program on the internet according to Google. Rebooting the computer didn’t help: after the reboot it was there again. I did not remember downloading anything from Facebook to run on my computer.

The solution was to go to the Windows start screen, and find the Facebook “app”, and then uninstall it.

“Leaving out the best bit” anti-pattern

When I was at university in the 90s, studying computer science, my final-year bachelor project was a “fractal raytracer”.

My idea was to write a program which could produce pictures of those wonderful artificial worlds one saw on posters of the time, hung in every university dorm room. Raytracers render highly realistic images, and fractals produce interesting shapes to render.

I set about designing the program, with all the features I wanted. In the object-oriented language of the day (Objective-C) I envisaged a Shape class with various subclasses to represent the various objects the program should be able to render: spheres, fractal landscapes, etc. The fractal landscapes would be further subdivided into those more random mountainous landscapes and, the crowning glory, a 3-dimensional landscape based on those particularly recognizable fractal shapes such as the Mandelbrot.

After the design was completed, I set about the implementation. There was the basic algorithm of the ray-tracer to implement. I wrote a small custom DSL programming language based on TCL to allow the user to programatically specify scenes based on the Shapes available. The rendering of landscapes was quite a challenge especially in terms of performance: landscapes were composed of tiny triangles, and to calculate which of them should be displayed per pixel in reasonable time required a more fancy algorithm than just iterating over all of them per pixel: I envisaged an appropriately fancy algorithm then programmed it successfully.

So far so good, but then disaster struck: I ran out of time. The only hope of delivering something by the deadline was reducing functionality somehow. But what could I leave out? I couldn’t create landscapes in memory and have no way to render them, such a program would produce no output and thus look like it didn’t do anything at all, so I needed the raytracing algorithm. I couldn’t just program the part to generate Mandelbrot landscapes but leave out the fancy algorithm to convert their triangles to pixels, so I needed the fancy algorithm.

So in the end I left out the small piece of code to generate the Mandelbrot landscapes. But i had all the supporting software which would be required for the result of that small piece of code to be rendered.

Y U no Mandelbrot? (image produced by my bachelor project)

So what I had I achieved?

  • Created an architecture and algorithms to do what I wanted (= render Mandelbrot landscapes)
  • Spent 95% of the time I would have had to spend to achieve that what I wanted (= render Mandelbrot landscapes)
  • Produced a program which did not do what I wanted (= render Mandelbrot landscapes)

I think this is often the way with software:

  • The “crowning glory” (which is the reason you wrote the program in the first place) is often a tiny piece of work, sitting on a great body of other supporting work
  • You can’t have the “crowning glory” without the other support work. (However, you can have the other support work without the “crowning glory”.)
  • Therefore, if you have to cut something, you have no option but to cut the “crowning glory”.
  • It’s pretty often that software projects go over-budget, forcing you to cut something.

Alas I don’t know what the solution to this problem is.

It’s a bit like spending two hours preparing a curry but then saving 20 seconds by not adding salt, so the result doesn’t actually taste nice.

I think one should bear in mind that if one makes cuts to software, due to the fact one can only realistically cut the “crowning glory” features, one is often cutting 5% of the effort but cutting the main purpose of the software, which is a poor trade-off.

Cutting pointless features

A seeming counter-example to the above, from my professional career, is when a product manager, with little understanding of the costs required to produce software, and little self-restraint, insists on a dizzying array of features that the user “might need” and without which they believe they “cannot ship”.

Cutting such features definitely helps the product, making it easier for the users to find the features they do actually need, without having to wade through said dizzying array of features they do not need. (In addition to allowing the users to continue to use the product at all, due to the company producing it not yet being bankrupt.)

Nevertheless, cutting a feature such as “users see feeds of their activities and their friends’ activities” allows for a great number of supporting elements to be cut as well, for example modelling which activities a user has done or which friends a user has.

So I’d argue cutting features, before implementation has begun (leading to a cleaner user-interface and longer-lived company), is good, vs. simply running out of time and leaving out the crowning-glory feature (for which all the supporting work has been done) is bad.

How to install Percona MySQL 5.6 on Ubuntu 14.04 LTS from a script (i.e. without an interactive prompt for the mysql root password)

Ubuntu 14.04 (and various versions of Debian) come with MySQL 5.5. If you need MySQL 5.6 features (such as better join algorithms) you can install the Percona software, as described here.

However, the installation process prompts you for the database’s root password. This isn’t convenient if you’re running the installation process from a script e.g. a Vagrant or Docker initialization script. Here’s the whole script to install Percona 5.6 and to set the root password to “root” without a prompt:

sudo apt-key adv --keyserver --recv-keys 1C4CBDCDCD2EFD2A
sudo bash -c 'echo deb trusty main >> /etc/apt/sources.list'
sudo bash -c 'echo deb-src trusty main >> /etc/apt/sources.list'
sudo apt-get update
echo "percona-server-server-5.6 percona-server-server/root_password password root" | sudo debconf-set-selections
echo "percona-server-server-5.6 percona-server-server/root_password_again password root" | sudo debconf-set-selections
sudo apt-get install -qq -y percona-server-server-5.6 percona-server-client-5.6

I got to this by finding out what keys exist in debconf uses as follows (after having installed mysql and entering the password interactively):

sudo debconf-show --listowners
sudo debconf-show percona-server-server-5.6

Avoid adding “drive-by formatting changes” to commits

Recently, when reviewing code, I saw a commit resembling the following:

- if (x) foo();
- if (y) bar();
+ if (y) {
+    bar();
+ }

It’s not easy to see that of the two “if” statements, only one was actually deleted. The other had its formatting changed, but was otherwise not altered.

To prevent this, go through the “diff” before doing the commit. Revert any changes which have happened which haven’t changed the functionality of the code.

Committing not only the things you meant to change, but a bunch of other changes that don’t change the code’s functionality, has the following negative consequences:

  • The “blame” commands of the VCS will now show this new commit as the “last changer” of the “if (y)” line above. If you’re trying to find out why that code was written, this formatting change isn’t the commit you’re interested in. (And the commit message “removed X” won’t help you understand why the “if (y)” line is there.)
  • Conflicts. We love feature branches. If two people do such a drive-by change, in inconsistent ways, in different feature branches, when it comes to merge, that will be a conflict, that some person is going to have to spend valuable time and energy fixing.
  • The diff is more difficult to read than it needs to be. In the above commit, it takes longer to see that only the first line has been removed. Code reviews are important.

I think there are the following reasons why such changes might get introduced in the first place:

  • The developer felt like they wanted to make the code “nicer”. It’s a good intention, but leave that for special “code cleanup” commits. Each commit should have one purpose.
  • IDEs often auto-format code. In that case, the developer might not even realize they were making the formatting change? (But a “diff” before commit will show it to you and allow you to revert it.)
  • Java IDEs have “organize imports automatically” differently. IntelliJ lays out the “import” statements differently to Eclipse. So, a trivial change to a piece of code, and “organize imports” will completely change the import section, for no functional difference. If you see such needless import changes in the diff before commit, revert them.
  • Some text editors chop off trailing spaces in a line. This is a noble cause, but, again, it makes it difficult to see what the programmer has actually changed in the commit. In the most pathological case I’ve seen a commit with hundreds of files altered, for only a single line of actual change. This is going to be a nightmare to review and a nightmare to merge. Turn this feature of your editor off.
  • Tabs vs Spaces inconsistency. IDEs often change the file to their preferred settings. You can’t even see these changes! Again the “diff” tool before commit will make you aware of them.

Business and Work 2014

I went to a lecture recently and the CEO of Runtastic spoke. He said: you don’t “win or lose”, you “win or learn”. 2014 was a year of learning for me. Some of it was good, but some of it was definitely in the “you win or learn” sense of learning.

Collecting on debts

Many customers thought they would just order software from me and worry about paying it later. (The word “later” in the sense of tomorrow in “Alice in Wonderland”, i.e. not that indistinguishable from “never”.)

Here are two approaches I discovered which worked well:

  1. I developed a website for one customer, and she refused to pay, on the grounds she didn’t need the website any more. I took her to KSV (debt collection agency) and they did manage to collect the entire amount. It took 6-9 months but was pretty painless. I didn’t have a contract with her, but I had emails saying she was happy with the work, and this whole process only kicked off after 3 months of non-payment. I understand, in Austria, f you don’t dispute an invoice within one month the invoice is considered “accepted”. So because she “accepted” the invoice, she had to pay.
  2. With one other customer, who “definitely” wanted to pay according to him, but “later”, I finally stumbled upon the following approach which was successful. Building off his assertion he “definitely” wanted to pay, I asked him until when he wanted to pay. He said a year thence. I said “OK, take your entire debt, divide by 12, what you’re saying is, you’re happy to pay this on a monthly basis for the next 12 months?”. He couldn’t really say no.

Debts are going well, I hardly have any debt owed to me left. (And even if the customers were to stop repaying, at least I’ve collected a significant portion of the debt, which I wouldn’t have done had I not acted.)

Q1/Q2: Merging then un-merging (catastrophe)

I went into 2014 with two employees (MartinL, DavidZ) and not a great deal of work. And the work I did have, was for customers who were enthusiastic about the word “payment” only when combined with the word “later”.

I acquired a new customer, who were a general software development house, partly owned by their main customer, which was basically run by the same people. This main customer was developing Java Enterprise software, with a huge stack of server-VMs, Maven, ORMs, Spring, C# Windows thick-clients, Lua mobile client, and so on. Not surprisingly, despite having modest functional requirements, it (a) was large and complex software, and, as a consequence, (b) didn’t work. They needed our help. So far so good.

The software development house suggested merging their company with mine. They had 4-5 people, 2-3 customers (incl. this main customer with the Java software). I had 2 people, 3-4 customers. If we merge our resources, all customers would have access to a larger team, all employees would have access to a larger pool of customers. In principle this sounded good to me.

They insisted I become salaried at their company. The new company would continue to have the name of their old company before the merge. I suppose one might describe these as “red flags” in retrospect, that this wasn’t as much of a “merge” as had been originally proposed.

Not only was it a takeover (not a merge), they really were only interested in us working for their main customer. They weren’t interested in my customers (who I’d taken to the company in good faith), nor any employees of mine who were working for my customers (who I’d taken to the company in good faith). The boss even said that MartinL had “produced no value” (because he had only been working hard for months satisfying the customers I’d brought to the “merge”.)

I didn’t negotiate hard for them to pay me for the “merge” because I felt if they hadn’t paid, they hadn’t actually “bought anything”. This meant, from my perspective, I could exit any time I wanted and take all customers and employees who wanted to come with me, effectively un-merging. So that’s what I did.

Q3: Employed at CCA

I worked for “Control Center Apps” from August for a few months, which is a company run by a friend of mine. I developed a small Javascript demo, and worked on-site at Sepura (a CCA customer).

I used JQuery for the Javascript demo. Both JQuery and Javascript were somewhat new to me. JQuery seems so easy to use, and is so well documented, using it was really a pleasure. JavaScript less so, but I suppose it was about time that I really understood it better.

For that project I initially tried to get into AngularJS myself, but without much success. There were a lot of examples on the website, which were nice, and if I typed them in exactly as they were, they worked, but with examples alone it’s difficult to progress to changing the example into your own application. Some of the examples also had HTML as strings inside Javascript source, which didn’t strike me as particularly nice, and put me off it.

Q4: Running my business again

I decided to leave CCA and focus on running my own business again. I am still on good terms with CCA and do work for them still, but self-employed and with my team.

I did some training for the first time this year. Three days of Perl and one day of MySQL. Was an interesting experience. Training institute gave me no indication of the experience of the participants. It turns out the three participants were experienced sysadmins. I used my laptop connected to a projector and let them guide me through the areas they wanted to learn about.

I am working in cooperation with SebastianK since Q4 and he has developed software for CCA based on AngularJS as a Single-Page App (SPA), communicating with a Java back-end. Project isn’t delivered yet, but is going well. This is in contrast to our normal stack of Wicket in Java (not SPA).

I have a philosophy of, for each new project, using the stack that seems appropriate for the project, i.e. I don’t have the policy of using the same stack for all projects. If all teams must use the same stack, then the advantage is code-reuse and knowledge-reuse. The disadvantage is, that as the company grows, it gets stuck in a stack which is perhaps not appropriate for the future, as the world outside the company has a habit of changing and moving forward. The more projects use the same stack, the harder it is to change. At some point you just get stuck. We avoid that.

Other than that, MartinL and I supported our old customers (mobilreport, firstbird, Offer Ready), we did a few small website projects (using outsourced designers), and I did few pieces of consultancy (mainly database and Java software optimization).


Other than a certain unavoidable quantity of “learning” which is no doubt ahead of us all, I have the following objectives for my company in the coming year:

  • Build up more of a brand, so that people can recognize us (and it gets a bit annoying to refer to Adrian Smith in offers, which has two meanings, my company including all employees, and me as a person e.g. working on-site)
  • Build up more of a website, so that people who don’t already know us can find information on me and perhaps decide to work with us
  • Not merge with anyone: remain running my business
  • Make sure that our customers are satisfied
  • Make sure that employees consider my company a great place to work
  • Acquire more customers, acquire more employees

Parameter ordering: Destinations on the left

Most (all?) programming languages write assignment with the destination variable on the left hand side, i.e.

a = b+c;

Therefore most (all?) programmers are familiar with the destination for an operation being on the left hand side. Therefore, I think, when designing functions or commands doing copying or assignment, the result should also be on the left hand side.