Another small one on time precision that I’ve noticed.
package main
import (
"fmt"
"math"
"time"
)
func main() {
now := time.Now().Add(time.Hour)
seconds = time.Now().Sub(now).Seconds()
fmt.Println(int(seconds))
fmt.Println(int(math.Floor(seconds)))
}
Line 12 will print -3599, line 13 will print -3600 (tested on Ubuntu). So watch out when converting the number of seconds to an integer, you might not always get what you need.
Unit tests were needed on a new project I’m working on and a few weeks ago I wrote some. Last week, a colleague wrote some more, and when he ran all of them, mine were failing. Same code base, up to date, same tests. On my machine they were still passing. We jumped on the situation and saw math.Floor was giving a result on my machine, which runs on Ubuntu, and another one on his, on Windows.
The code is larger, but I’ve extracted and adapted what’s needed:
package main
import (
"time"
"math"
)
func main() {
datetime := time.Now().Add(time.Hour * 24 * 7 * 4 * 12 * 3)
seconds := -1 * int(time.Now().Sub(datetime).Seconds())
a := 29030400
x := float64(seconds)/float64(a)
println("input:", x, "floor:", math.Floor(x))
}
Result on Ubuntu:
input: +3.000000e+000 floor: +2.000000e+000
Result on Windows:
input: +3.000000e+000 floor: +3.000000e+000
I’ve heard “it’s easy to switch to a new language, it’s just a language, you just learn a new syntax”.
Well, I partially disagree. While you’ll may be able to learn the syntax fast, each language has its own particularities that you don’t just understand in a few days. Some languages have other best practices than others.
I believe that if you jump on writing code in a new language without understanding its philosophy, you’ll miss a lot of edge cases that will lead to undesired situations. Most probably no one will die, but time will be lost.
“We chose Node because we already had JavaScript developers, and it’s the same thing” – Yeah, server side optimization is the same thing. Same for concurrency. Or properly handling the file system.
“I took a look at Go and it’s trivial” – And a few months later you’ll end up tangled in your own work, refactoring each step.
While onboarding to the new project you have with that new language, I suggest reading the docs, understanding the language’s best use, maybe right from the authors.
Since last year I’ve followed the announcements on Letsencrypt support for wildcard certificates. At the beginning of this year I was checking their website every few days, and just about a month after I took a break, here they are.
Read the official announcement and the technical details.
Waiting for Certbot to offer support.
Those SOLID principles many talk about are really helpful. But why use solid principles, why is SOLID important? Because they were stated and tested by advanced programmers in real situations? I say this is an enforcement, a reason to trust them, but not the reason to jump on them. It’s actually about understanding the benefits of using them and being able to identify when you need them.
All of them help in the way of having clean code. But why would you need clean code? You can really have messy code which does the same thing as the clean one. Except when you aim for long term healthy business. Solid code makes solid business.
Each of the SOLID principles comes with its ideology, but does not guarantee a 100% benefit, because there could be other factors which more or less collide with them, the first one being when you play around the principles, but do not apply them properly.
While the benefits you get from these principles are well known, I’d like to state some of them which for me are more real, more close to the business side. Continue reading Real benefits of SOLID principles
Today I read a very good article about some mistakes that one can do as a programmer, and the only idea that made me a little bit uncomfortable was the one about best practices. The author was talking about “Obsessing About Best Practices”. While I agree obsessing is not healthy, I consider his statement “There are no best practices.” is too strong. I think it’s something that one could hear and get too confident about their decisions.
Thinking the things you know today are the best there can be is wrong. Trying to apply everything you’re hyped about is wrong. Giving the same 2 or 3 methods you know as solutions to any problem is wrong. Not being curios to find out what else exists beyond any best practice and beyond your knowledge is fatal.
Still, there are some general best practices that you should at least think of before writing code. There are those SOLID principles that some have no idea about, some guide themselves through them, and for sure some are not very happy about. And many design patterns which were tested for years and years. Again, I agree about not being obsessed with them, but try to understand where they can come in need. And stay up to date. The Singleton was a rock star some years ago, now it smells like a dead body in many misused cases.
Because “There are no best practices.”, projects can take on a really, really unwanted highway. I say they do exist. Just open your mind to see which are the proper ones for your case.
If you’re using Libvirt Python library on Ubuntu, watch out for the 4.1.0 version. When trying to install, you’re gonna have this beauty:
Command "/usr/bin/python -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-6nHyGT/libvirt-python/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /tmp/pip-v9fxvX-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-build-6nHyGT/libvirt-python/
It’a fresh known bug: https://bugs.launchpad.net/openstack-requirements/+bug/1753539
Until the patch is released, you can use an older stable version:
pip install libvirt-python==4.0.0
It’s easy to talk about SOLID principles, design patterns, testing, moral expectations, self responsibility, and any other guide lines for a better world. Sometimes it’s even easy to adhere to those ideas, to put them in practice, no matter how may times some people repeat “there wasn’t/isn’t time”.
Although, there are situations that really stand against all best practices, like big legacy products which are already on the market, used by many clients, developed by many people who are managed very strict, in order to maintain… order. Or you need to get fast on the market.
The minimum that can be done is isolation. The least you can do is to throw your code in its own corner and use it only from there, then go back to change it whenever you want, without fear, with minimum cost and risk.
The past days I’ve practiced Go by writing a package for Apixu weather service. They have a a straightforward REST service to offer their weather information.
Their service also returns an error response if it can’t offer data based on your needs, if you use an invalid API key, or for other cases. Of course, the Go package should also return errors if the case.
No problem with returning data, but I had some issues handling errors. There can be general errors that have nothing to do with Apixu (but with the package internals) and errors returned by them. My first approach was to return three values for each API method:
Search(q string) (Search, ApixuError, error)
But it smelled right away. There had to be another way. Continue reading Handling API errors
There are some ways to automatically reload Go apps while developing, to not have to manually stop your app, build it, run it. Recently I ran into this article about a nice tool called Fresh.
I wanted to start using live reload (or hot reload) for a project of mine, but it had a particularity which gave me troubles when I tried Fresh. My case was:
Continue reading Reloading Go apps automatically while developing