hjertnes.blog

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.

#

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.