Everyone is addicted to something: be it success, sex or just coffee. Some time ago I noticed that drinking a coffee too early after the previous one makes me hot-tempered to the point of being irritated. So, I tried to go one week completely caffeine-free. After two days of terrible headaches and being overall tired as hell my abstinence lasted for two weeks before giving up. This gave me an idea: how about, instead of the silly New Year’s resolutions, I try to abstain from my addictions, one month at a time?
This is just basic theory of probability, and it’s overly simplified, but it goes like this:
Suppose an event has probability of occurring, say, 1%. So, on average, let’s say it happens on 1 out of a hundred attempts. What’s the probability it happens at least once in 10 attempts? Well, it’s (1 – probability it never happens), that is 1 – 0.99 ^ 10 ~ 10%. In 20 attempts, the probability goes up to 1 – 0.99 ^ 20 ~ 18%.
This post will start with some handwaving and claim that the most costly errors you can do while developing your application are:
- Forget about localization (they speak what language?).
- This means, among others: translating the UI, formatting names, dates, numbers and currencies, and even outright horrifically complicated stuff like right-to-left languages.
- Forget about permissions (the janitor needs to log in where?).
- Forget about time zones (they live there?).
Follows a list of DevOps-style problems we had in realPad, along with solutions to each of them.
My boss asked me to document the various sources of information I get my daily dose from. Well, I never understood sharing articles on Twitter and such, I follow only friends on Facebook, so no social sources for me.
I am an old guy, that means one thing only: RSS! Here goes my list:
- IT News
- Gizmodo (once I subscribed to Engadget as well, but it seemed duplicate, and Gizmodo didn’t fill my screen with huge images directly in the feed)
- Ars Technica – good for longer in-depth articles.
- TechCrunch – every once in a while, something good comes out of it.
- InfoQ – the articles are not worth much, but the presentation recorded in conferences are great.
- Local IT News (Czech, Slovak)
- DSL.sk – this is a mystery to me: no idea who is writing it, but I read 90+% of the articles and the overall quality is incredibly high.
- PCTuning.cz – every Friday, the legendary Michal Rybka has a great article mixing tons of experience with the slightest drop of paranoia.
- Lupa.cz – my teacher from Matfyz (Jiri Peterka) writes great in-depth articles every once in a while.
- Technet.cz – considering this is a part of iDnes.cz imperium, the articles are strongly above the average.
- Diit.cz – everyone has to read something from the opposing camp, and I prefer Diit to Radek Hulan 😉
- Your code should look nice and be legible. Use an automated code formatter. Keep your functions short (under a page of text) and your classes/files reasonably long (1000+ LOC should ring an alarm). Always delete commented-out code – it’s already in the Git repository if it’s ever needed again.
- Respect the Single Responsibility Principe. One class/file should either talk to the DB, or output GUI, not both.
- Give clear, descriptive names to your classes, functions and variables. This is art (and it’s really hard), so practice it.
- Extract commonly used numbers, strings etc. into (well named) constants. “Magic numbers” in code are bad.
- Respect the Don’t Repeat Yourself principle. Reuse existing code, refactor code that looks similar or performs similar tasks. Copy-paste is worse than plague.
- Write documentation with common sense. Prefer good names and short functions to comments. Document your public APIs/interfaces.
- Prefer functional style of programming, avoid side-effects.
- Treat any warnings from your compiler/toolchain as important and helpful information.
- Crash early, once you detect a problem throw an exception and log some data to help you fix it later. Set up the application so that any errors will be sent to you by mail.
- Use a build/dependency management system, such as Maven, CocoaPods or similar.
Any code deployed to production (be it a web application, mobile application, …) must have been committed into the repository earlier. Commits should deal with one thing (~1 issue) and one thing only. Commit early, polish later.
Write an English sentence describing the commit. If a commit deals with an issue from the issue tracker, start the sentence with the issue key.
Example: “#1234 fixing the froboozle”
- Don’t commit “only at the end of the day”.
- Never commit a configuration file or any other file that would disclose a password or some secret key.
We use 3 environments: development, testing and production.
Application will know which database to connect to, which resources to use, etc from a configuration file, or better, environment variables (http://12factor.net/config).
Application code always lives in Git. It is deployed to the various environments either as a Git checkout, or using a specialized tool (Jenkins + rsync or such).
Typically, this is the localhost of each of the developers. This is the only environment where code changes are allowed. It’s possible for the database structure or resources configuration to get temporarily out of sync with the code base.
Testing & Production
Testing serves to allow testers (internal or external with customer) to try out changes in the application before it hits the production. The purpose of production is probably clear
One important rule: application changes should (must) be deployed atomically. This means that if I change some code that needs an updated database schema, I must upgrade the schema at the same time (atomically) as I deploy the updated code – otherwise the application could crash or even corrupt data.
Of course, never deploy to production anything that was not previously verified on testing.
- Take the application down – redirect to static server, other instance, …
- Upgrade the database (execute the SQL patch).
- Upgrade the code base (git pull or rsync or whatever).
- Start the application.
Upgrading your operating system could be a harrowing experience. However, with some forward thinking, you can survive it quite unharmed.
Allocate around 1 man-day for the upgrade, the same as for migrating to another computer or such. You might think it will be less, but just in case – make sure you won’t need to be productive on the day of the upgrade. Pick Saturday if you can.