April 26, 2018

When I start the day with Flogging Molly, I usually move over to Dropkick Murphy’s before lunch.


April 26, 2018

Every time I read some article or book about some new and amazing software development methodology or office / no office work system I pick up on some useful information. But the thing about all of them are that what works for your team or company depends on what you and the people you work with.

For some teams it wouldn’t matter if they were located in the same area or not, because they only talk over Slack. While others have too much “meat space” collaboration for it to work. Some people think working for home is the best. While others can’t deal with it. The perfect for me would be to do it like half of the time.

The same goes for agile. I know developers that can design and build features themselves and developers that can’t do anything unless someone give them drawing and descriptions of everything.

Pick up on the details you and your co workers like and build the mix that work for you. And hey you might get a book deal and write the next book I get annoyed at.

Going analog only

April 26, 2018

Every now and then I consider ditching digital photography and move over to just shooting analog.

And I think I would, if two things would happen: cheaper film and someone would start to produce mechanical SLR cameras with lenses again. Something like my Nikon FM.

Why? Because analog cameras are so much simpler. They almost never run out of batteries, and when they do I can buy new ones at a grocery store.

I know Leica still makes analog cameras, but that is a little bit too expensive for me. And I think there is room for someone to make cameras like Canon and Nikon did at the end of the 70s.


April 25, 2018

Some developers think that you should write code that can run in any browser. While others take full advantage of tools like Webpack to make it easier to build complex applications.

The reason this is even a discussion is that you can write code without any tools that performs well in the browser. But it is much harder to do so without any extra tools. Because we as developers like to split stuff up into multiple files to make it easier to manage the code. But when you do that it takes longer to download them. This is why we started to use various different tools to kind of take all our css and combine them into one file, all of or images and combine them into one file and all of our javascript and combine them into one file.

But then you meet another problem. Because a lot of tiny files takes much longer to load than a few big ones. But three huge files also takes longer time to load than some smaller. What you want it the perfect balance between total file size and how many files you can download at once and take full advantage of the bandwidth. And if you configure stuff correctly you’ll only download the updated parts when you update your app.

For example one JavaScript file of 10MB takes longer than 40 files at 250kB; but one file of 10MB takes shorter time to download than 2000 tiny files.

But there is one thing you should keep your eye one when you use a tool like Webpack and that is huge node modules. Because some modules from NPM may be responsible for a very large portion of the total size of the output. Just google for Webpack Bundle Analyzer to find a recent one. And start digging. The way I tackle this is to identify large modules and then I figure out if I can solve it by only importing select methods or I try to find smaller replacements. And remember to split CSS out as their own files.

Pass: Im going back to 1Password

April 24, 2018

I thought Pass looked interesting. So I decided to give it a shot. And it is a interesting idea. But I have decided to go back to 1Password because it is better. The user experience is much better, and pass felt too much like work. And the browser extensions was not reliable enough for me.


April 23, 2018

My girlfriend isn’t happy when I compare the local dialect to the swedish chef


April 23, 2018

The Field Notes pencil is actually good.

Project configuration.

April 23, 2018

If you are working on a software project that have a backend or server component, it probably have some kind of configuration. Like database servers, maybe some API keys to upload to S3 etc. To get configurations right, the first time is always a pain in the ass. Because some of it is about configuring exciting tools and libraries to work with your setup, and other times it is about configuring your stuff depending on where you want to run it.

There are a few different ways you typically would deal with this. And there are a few ways I would encourage you to not do.

The biggest don’t is to not put it in a database, because you might want to take data from production and use it during development to make sure that what you make scales well. Make sure that you don’t keep settings that only works in production in the database. Because it will make stuff like testing production data much harder than it has to. And don’t just hard code settings.

The day I usually do it, is to hardcode the development settings in my projects. And then I re-configure them to run in production. Why? The less time I have to configure the machines of the people I work with, the better it is. When it comes down to the actual configuration I think there are two good ways to do it in 2018. Either with a configuration file or with environment variables. There are places where using a configuration file makes sense, and there are places where using environment variables are better. A configuration file is awesome for all kinds of settings that applies to your software project, as long as they always are the same. The moment where it might change is when you run into trouble. Because it is a pain in the ass to keep multiple almost identical files up to date. A typical software project runs in three different environment: development, staging and production. Development is a developers personal machine, staging is where you test stuff to make sure everything works in a production like environment and production is where your users or customers will use it. The way I do it these days is that everything that is not the same all places are controlled with a environment variable. Usually through a docker-compose configuration file.

What are a environment variable? Well, they are like a variable in your programming language, except that they belong to the environment the program runs in. This means that if you have two programs on written in Java and one in Python that uses the same database, they can read the same connection string.

Let’s say you have a project with two variables that change depending on where you run it: URL and DATABASE_CONNECTION_STRING. The URL is used to display the full URL to a resource for when you need it(for example when sending an e-mail) and the DATABASE_CONNECTION_STRING is used to connect to your database. I use environment variables for this because I can just change them in the script or server configuration. Instead of having to keep multiple copies of large config files on the project side of it. That someone (me) have to keep in sync. On a UNIX/Linux system you could just do something like URL=”https://yourdomain.ltd” DATABASE_CONNECTION_STRING=“‘postgres://pompeii:pompeii@db:5432/pompeii” command-to-start-your-server to override them.

If you for some reason need to implement some project configuration on your own. Use JSON or YAML. Most if not all developers know the formats, and you’ll find parsers for all languages under the sun. And some in the shadows as well.


April 21, 2018

It’s cool that SmugMug have bought Flickr. Flicker was awesome, but I stopped using it because the Yahoo authentication crap drove me nuts. Let’s hope they don’t fuck it up.

ES6 Proxies

April 20, 2018

ES6 Proxies are awesome. I have not used them much “in the wild” yet. But I think they add some very interesting concepts to JavaScript. You are kind of familiar with them if you have worked with Properties in C#, Java, Swift or Objective-C. The short version is that you define a method that is called when you try to retrieve a value or setting a value. But instead of calling .methodToGetMyValue is it called when you try to access some value.

The biggest difference between the JavaScript Proxies and setter / getters is that you define them for a “variable”(in lack of a better word for it). That means that you could define it for an entire list or object or just a value.