Hjertnes.blog

The Power Broker

June 22, 2018

The Power Broker is one of my all time favourite books. It is very long, but still a fantastic read. I have dragged myself through the audio book three or four times. And I love it.

What makes a biography a good biography is that the person it is about is interesting but also that the author presents good and the bad sides of a person and manages to tie them together.

Robert Carro does this masterfully in The Power Broker.

Here is the thing, there are sides regarding Robert Moses that I hate, while at the same time I respect a lot of what he was trying to do and appreciate how much he did get done and how much power he managed to build up.

It’s weird to sit here without being able to say if I like him or hate him or anything between.

My next MacBook.

June 21, 2018

I think my MacBook Pro is something like a year and a half now. And it still works pretty great. Except for the keyboard. There are many things about this machine I don’t like. But there are also some stuff that isn’t good enough.

What I don’t like:

  • Not enough USB-C Ports
  • No SD slot
  • Nothing like MagSafe

These are things I’d love to see fixed. And it would make the computer more usable to me. But they are in no way a “must”. But there is one thing Apple have to fix: the keyboard. I don’t love it. But that’s not the point. It is unacceptable to have a unreliable keyboard on any computer. I don’t care if it costs $50 or $3000 the keyboard should be reliable. Your computer sucks if it doesn’t.

If Apple doesn’t fix the damn keyboards on their MacBooks in the next couple of years, I think I have to either go for a Hackintosh setup or a Linux + iPad setup. Because I’m not buying another laptop with a unreliable keyboard.

#

June 20, 2018

Ordered a 144 pack of Golden Bears.

Picking the right language for your project.

June 20, 2018

Languages like Python are very easy to develop in. That means that you can do a lot more in it, in a shorter period than with something like C# or Java. There are a lot of reasons for this. The awesome thing about Python is how productive you are while using it. But there are a reason many of us use them at home, and pick other languages for our work projects. At work I use C#.

The reason I pick languages like C# for large work projects even though the productivity coding in it is way worse is simple: Types.

All languages have types, some of them give you more control over them than others. When you deal with compiled languages things can either fail in the run time or in build time. This is one of the bigger differences between Swift and Objective C. Obj-C is a very dynamic language, this means that more stuff happens I the run time while Swift is less dynamic, which means more validation and type conversion have to be done before you get it to compile. There are good and bad sides to both; dynamic are easier and more flexible, while the other side crash less often but takes longer time. ¨

The way it works is that every value has a type, and if you try to pass a value to somewhere that can’t deal with that type it won’t build. And there are also standard checks and error handling anywhere you might get data that don’t match. What I enjoy about working with languages like C# above everything else is that when I run “dotnet build” and it succeeds I know that all of it will run. If it does what I think it will is another case. But I do at least know that there are no syntax mistakes or someone using the wrong values.

It takes more time than it would take. But the result is that we write a lot less “make sure this really is a number” code. And often we write something once and don’t touch it in a very long time. That almost never happens with Python or PHP.

Making Code Faster

June 19, 2018

The basic idea behind optimising code is to make what it does today by doing “less”. When you do less, it takes shorter time. That doesn’t mean less code however.

  1. Figure out what takes the most time.
  2. Start at the top and find ways to make it go faster.
  3. Change one thing and test.
  4. Repeat.

Things like writing to disk, output (like printing) or committing write queries to databases are slow. When I write code I often first focus on getting it to work, and then I try to make it fast later. One of the first things I always do is to limit how often I commit transactions to the database. With complicated background jobs, you can take it from hours (with large data sets) to minutes if you limit how often you write to the database. By using transactions. The ideal is once.

Everything on GitHub

June 18, 2018

If you are a software developer, you probably have a lot of code laying around. Because you needed something or wanted to learn something. But having something that you can use and having something other people can use are two different things. Because you have to make sure it is at least kind of easy to install it, run it, configure it etc.

One thing I have focused on doing since the start of 2017 is to put as much as possible on GitHub. I’ve had a rule: either I start making money on it, or it goes up on GitHub. If it is something I coded on my spare time.

There are many reasons for it, but the two most important ones are: if I put it up on GitHub, I make sure that it is easy “enough” to install and get started with it, that means that I don’t have to study the source code to figure out how it works between each time I use it. And it is awesome if someone else finds it either useful or can learn something from it.

#

June 16, 2018

The keybase logo is too cute

#

June 15, 2018

Seems like Spacemacs is much less of a dumpster fire since the last time I checked it out.

#

June 15, 2018

I’d love it if micro.blog sent out some follow recommendation once a week, based on who those I follow follow that I don’t follow