Hjertnes.blog

#

May 02, 2018

It’s too much fun to make Emacs start faster…

#

May 02, 2018

MY PENCILS WILL ARRIVE TODAY!

#

May 02, 2018

@jack You have / had the Fuji 23mm f2 lens?

#

May 02, 2018

New pencil sharpener, two packs of new pencils and AirPods all arrived today.

#

May 02, 2018

On my CMS

May 02, 2018

I ditched Wordpress a while back because it was way too much work to keep it up to date, and I always get the feeling after using Wordpress for a while that it is too much for my needs. And I’m not that fund of hosting PHP+MySQL apps either.

Then I used Hugo for a while. It is an awesome static site generator. Much faster than all the others. But I ended up with like 75% of a CMS, because I wanted to continue using MarsEdit and the Micro.blog apps. So did what I should have done from day one and wrote a very simple CMS for my needs. It’s called JAC or Just another CMS. It has no admin panel or anything like that. No formal system for themes or plugins. It is written in Python, Flask and Jinja2; backed by a PostgreSQL database. It supports part of the Micropub standard, and emulates the Wordpress XML-RPC API. The goal is to get up full support for the Micropub standard as soon as I get around to it.

It is very simple, and have been built around what I need, and how I prefer to use a CMS. You probably want or need other stuff than I. But it should be very simple to extend or change.

Arq

May 01, 2018

Arq is a app for OS X and Windows that let’s you use a little bit more power user friendly version of something like Backblaze. I have been using it since this summer, and I love it. You have all the options and features you would like. And you have full control over where your data is stored.

With something like Backblaze you get what ever storage system they are using. But with Arq you get to chose a cloud provider, for example I use S3 using the Glacier storage tier(because it’s cheaper; and slower). It is a little bit more expensive per month than Backblaze, but I think it is much more convenient to back up external drives with it. And you get a lot more feedback on what’s going on.

Awesome product. You pay up front for the app, and then you pay for the storage at the provider you went with.

On keeping your front end and back end code separate.

April 30, 2018

I have thought that you should chose how you implement your back end and front end separate from each other, all the way since I started to form the idea that all complex web development should be driven by static resources plus JavaScript, instead of being server rendered.

How you implement a modern JavaScript application changes, and sometimes, but not too often, it makes sense to start from scratch to follow a more modern approach. This is why many teams have been moving over to for example React the last few years. And the same goes for the backend, you will find yourself in a situation where it makes sense to move over to something else because your needs have changed. For example because what you went with in 2010 doesn’t scale that well anymore, either because of performance or because of how large it have become.

The best way to make sure that these transitions go well is to keep each part separate. And that the one don’t know much about the other. If you do that, it will not be that difficult to re-implement either part. If you make sure that how the front end talk to the back end is the same, or for the back end, as long as you make sure that the URL’s and so on are the same.

Keep them in separate repo’s and treat them as separate projects, even if the same people are working on both,

#

April 27, 2018

Automattic should buy Tumblr

On using the DOM API

April 27, 2018

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.