hjertnes.blog

Getting into web development

26.06.2018 02:00

1. Django / Ruby on Rails

Pick either one; both are great. ## 2. Learn how to use it well enough to build a web site or web app with it Focus on building stuff, learning how the different parts work together. ## 3. Learn how to build a RESTful API with it Learn about RESTful and building HTTP api’s. ## 4. Learn React or Vue Pick either or; some like React while others prefer Vue. Learn how it works, when it is appropriate. ## 5. Use the API with React Learn how to bind your Django or Rails stuff together with your web app through the API’s you wrote. ## 6. Dig into the following technologies - HTML - CSS - JS - React / Vue - Django / Rains - Databases - HTTP Protocol

#

25.06.2018 02:00

Using keyboard maestro to auto tune images because Lightroom CC don’t have real batch editing yet

On why I prefer Iroshizuku

25.06.2018 02:00

I have used various other inks brands over the last six months or so. I don’t remember exactly how long. But I have decided to go back to just using Iroshizuku. The reason is that other inks brands I have tested, that have as good colours are often worse in some other ways. Like for example dry time and ink flow.

There are many other interesting colours and inks brands out there. But I’m perfectly happy with the Iroshizuku colours. And I don’t want to mess around when I could get a worse experience

The Power Broker

22.06.2018 02:00

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.

21.06.2018 02:00

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.

#

20.06.2018 02:00

Ordered a 144 pack of Golden Bears.

Picking the right language for your project.

20.06.2018 02:00

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.

#

19.06.2018 02:00

Who Uses EMacs to read mail? - emacs

Making Code Faster

19.06.2018 02:00

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

18.06.2018 02:00

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.