Hjertnes.blog

#

May 29, 2018

One of the problems with digital photography is that it is so easy to end up with 30 000 pictures shot over 4 four years; and that is after you have deleted a lot of them. I have spent a lot of time the last 8 months or so trying to get rid of as much of the “noise” in that collection as possible. It will probably take a while before I get there. You get rid of 75%, then you give it some time, and repeat it until you can’t remove anything more without loosing something you really care about.

Some people think that machine learning or what ever will solve this problem. It might, for some or to some degree. But I still think we have to do the manual work of deciding what to keep or not. It requires a lot of work, like everything else worth doing.

Moving to Doom Emacs have made it simpler

May 29, 2018

One of the awesome bonuses of moving my Emacs config system of choice from Spacemacs to Doom is that how I sync my configuration between systems are much simpler. Because of the difference in where your additions or modifications live in relation to the rest of the code.

In Spacemacs you have a config file: .spacemacs and then you have all the Spacemacs code in .emacs.d and a folder called “private” in the layer folder in .emacs.d where you add your stuff. Doom on the other hand (on the develop branch) has all its code in .emacs.d and all your stuff in .doom.d. What makes the doom.d folder interesting is that in its init file is where you control what modules to load, but it is also a module of itself. Which menas that you can treat it as your private modules that adds all the extra packages you want and all your configuration.

The great thing about this is that when you want to update or re-install your emacs setup on a machine, all you have to do is to is to clone Doom Emacs and clone / copy your doom.d folder. Instead of how you had to do it with spacemacs

Doom Emacs

May 28, 2018

So I found something called Doom Emacs a few days ago. It is kind of like Spacemacs, a Emacs configuration system / setup with VIM keybindings.

The big selling point of doom over Spacemacs is that it loads much faster. For example on my MacBook Pro it loads in 25% of the time with similar setups.

There are multiple reasons for Doom being faster:

  • It is in general much less code, than in Spacemacs.
  • All the code in Doom uses modern methods to load Elisp code.
  • Doom uses a Makefile to install / uninstall and update packages instead of during startup
  • And you can pre-compile most modules with “make compile”.

Now. Spacemacs is much more “complete” all the built in keyboard shortcuts and command have been set up to be very intuitive and it almost always work exactly how you expect. This means that I think Spacemacs is a better place to start, than Doom. But Doom is awesome if you are afraid of configuring yourself.

Doom features a similar module system to the Spacemacs layer system. But I found it much more intuitive to use myself. Doom itself is also much more like standard emacs than Spacemacs when it comes to configuration. You can use much more code exactly how it would be using plain Emacs.

My favourite thing on the develop branch is that you have the doom code in .emacs.d and then you have your “private” module (exactly the same as other modules) located in .doom.d. This is awesome and makes it much easier to keep your settings in sync on multiple branches than with the Spacemacs structure where you have your stuff inside the Spacemacs repo.

#

May 26, 2018

I might be very cynical, but I love how Billions portraits everyone as the bad guys.

Test

May 26, 2018

Hello World

The ArchLinux Wiki

May 25, 2018

There are a few Linux resources out there that is beyond awesome, and shows that there are good parts of the world. Where a community come together and make something amazing. The Arch Linux Wiki is one of them. When I want to find out to do something on Linux, the Arch Wiki always come to the rescue. I use it even when I’m trying to do it on other distros or operating systems.

How to fix C# Auto complete in VS Code and Emacs.

May 24, 2018

There are times when the auto complete for C# and .NET Core stops working in editors that use the OmniServer auto complete engine. For me it is Emacs and Visual Studio Code.

Visual Studio Code will give you a hint when it starts, while Emacs will just fail. The problem is that they can’t locate the “dotnet” command. The place you need to start is that you start a Terminal with your shell of choice and make sure that it works there. If it does type “which dotnet” and copy the output.

Then you type sh and enter. Test it there, this is the place where it should fail. There are two ways you can fix it, either by adding the folder where the dotnet binary is located in to the path, or if you are lazy like me by doing something like “ln -s /usr/local/share/dotnet/dotnet /usr/local/bin/dotnet”.

And that should do the trick. As long as you can run the command “dotnet” in sh it should be available anywhere.

#

May 23, 2018

New camera bag

OmniFocus vs Things

May 23, 2018

The big GTD question on a Mac is Things or OmniFocus?

They are both very good, and I think which one is the right for you depends a lot of your personal preferences. It was a time in the middle where it was a very easy pick because Things used a shit load of time to get their sync act together.

Things is a little bit easier to get started with, while OmniFocus is a power tool. I have used both, multiple times over the years.

Things look a lot better. But it is a little bit too far in the eye candy over usability in some areas. It does for example drive me nuts that it takes noticeable longer to add a task to Things versus OF.

OmniFocus on the other side is a little bit more nerdy, and it takes a while to get into it. But when you do, it is a power users dream. It is awesome.

Python rant.

May 22, 2018

Python is solid language, with a lot of good libraries, framework and a lot of great documentation. This makes it an obvious choice for a number of things, everything from command line programs to Web Development because of stuff like Flask, Django and Jinja.

But there are a number of problems with the language that makes it a poor fit for larger things, even with the addition of type hints. Because Python is a language where developer productivity is very important. But you have almost no validation of the code before loading it into the runtime. Like types and pre flight checks. This means that you need to write way more unit and integration tests than you would with a typed language.

I’m probably going to continue with Python for some stuff, because it is so easy. But I’m not going to write any work stuff in it. Because of types, and because Python almost makes it a priority to make sure it is impossible to follow functional programming concepts.

The reason I often go with Django for a little bit larger stuff at home is that it is so easy to put together some models, add unit testing to them and get something that works. And flask is perfect for some small api’s. But I think Clojure is the future for my Projects.