Mastodon

hjertnes.blog

#

02.05.2018 02:00

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

#

02.05.2018 02:00

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

#

02.05.2018 02:00

On my CMS

02.05.2018 02:00

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

01.05.2018 02:00

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.

Clairefontane Flying Spirit Notebook Review.

30.04.2018 02:00

I received the Clairefontane Flying Sprit Notebook free of charge from Tudos.no for the purpose of this review..

This notebook is amazing. There are no other way to put it. When I look at a Rhodia Webnotebook I see the best designed version of the A4 softcover notebook that Moleskine popularised. This on the other hand is the perfect design for the soft cover version; you know the kind you can buy in a three pack.

The design is very understated, and you don’t think much about it straight away. Before you start to realise how perfect everything is. Even the stitches on the back are beautiful.

Let’s move over to the paper. The paper is very similar to Rhodia(same parent company), but my impression is that it is a little bit smother. There are smaller differences between this and Rhodia, like there are minor differences between Leuchtturm1917 and Rhodia, but they are very minor. And I would put them in the same ball park.

This book came with a lined layout, and I like it a lot. The lines are broader than I’m used to from Travelers Notebook refills and Leuchtturm1917; they remind me a lot about the layout I used in school. The kind you usually find in most wire bound notebooks.

The Flying Spirit is a fantastic notebook, that I would recommend to anyone that like notebooks like the Moleskine Volant. It is in many ways a much better version of that. With better paper and higher quality production standards. I’m not going to get another one of these, because I prefer a hardcover notebook, because it is a little bit easier to write on them for example when I take the train to work, and don’t always have access to a good table. %

On keeping your front end and back end code separate.

30.04.2018 02:00

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,

#

27.04.2018 02:00

Automattic should buy Tumblr

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.