hjertnes.blog

On using the DOM API

27.04.2018 02:00

There are two different parts, when we are talking about coding a web browser. You have the language: JavaScript and you have the API: DOM. Most people are often using either their own or a third party library or set of library to work with the DOM. I do for example use Axios to deal with requests against RESTful API’s because it is kind of cumbersome to do so directly. The other reason for doing this is to leave it to a third party library to deal with differences between browsers (this problem have for the most part gone away).

The DOM is designed by a committee, and it is designed to be as flexible as possible to make sure that all kinds of Web Applications can be developed. That means that the DOM is often not the easiest to use. This does not mean that the DOM sucks or anything like that. It just means that it is there to solve many different problems and use cases. And I believe that it is really good at what it attempts to do. This does not mean that front end developers should use the DOM api’s all day or ignore them.

You should probably use libraries to deal with the DOM most of the time. While at the same time do some projects where you use it directly. So that you know how it works.

#

26.04.2018 02:00

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

#

26.04.2018 02:00

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

26.04.2018 02:00

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.

Webpack

25.04.2018 02:00

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

24.04.2018 02:00

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.

#

23.04.2018 02:00

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

#

23.04.2018 02:00

The Field Notes pencil is actually good.

Project configuration.

23.04.2018 02:00

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.

To keep or not to keep?

23.04.2018 02:00

I guess this comes as a response to recent discussions on The Pen Addict podcast about keeping journals or not. My collection of notebooks is growing. And it grows some every year. The big question is: what should I do about them?

One option is to just keep them and let future generations deal with it. Not unlike how my parents and grand parents generations dealt with climate change.

Another option is to throw it all out.

And the third is to throw out some of it.

A lot of it is just notebook after notebook after notebook of tasks. While other parts are notes I have taken while reading or studying. And some of it is journaling.

Here is the thing: I’m probably the worst judge to what’s interesting. And I’m not one of those who care what happens after I’m dead and buried.