hjertnes.blog

Pairing it down even further.

05.03.2018 01:00

I’m lucking enough to own a lot of great pens. But that means that I can’t use all of them. Or I can at least not use all of them all the time.

I own a few Retro51’s, three Pilot Metropolitan, one Lamy Safari, two TWSBI Eco, one TWSBI 580AL, a Lamy 2000, A Pilot Vanishing Point, a Pilot Metal Falcon and one Noodlers Ahab.

The way it works for me is that the pens I use is the ones I have in my Nock Hightower. It has room for three pens. And I have a system for rotating the pens in it. Too few pens means that you run out of ink, and too many means that they dry up or that you spend more time making sure that they don’t dry up than you spend writing with them.

My problem before I started to move pens out of rotation, first with the Metropolitans and then the Eco’s was that there was three pens I enjoyed way more than the others. I love the Metropolitan, but I enjoyed the other five pens way more. And I also loved the Eco’s but I loved the other three pens more.

The result was that I almost never used them, except for when it felt like “I had to”. Therefore I decided to clean and rotate out everything that I didn’t enjoyed the most. And I’ll probably ink them up when I test out inks.

My current pen carry is as follows:

  • Pilot Metal Falcon: Broad Flex Nib

  • Lamy 2000: Medium Nib

  • Pilot Vanishing Point: Broad Nib.

Testing your web app

05.03.2018 01:00

To implement tests in a Web App requires your to test three different things: the backend, the front end and cross browser testing.

Assuming your backend is a series of REST API’s, the tests should make sure that your API’s are always doing what you expect even when you get input you don’t expect. And it is always a good idea to implement tests that re-produce bugs that are reported to make sure they don’t are re-introduced.

Then you also need to test your front end code. This means that you test all of your components or views and make sure that they always do what you expect, even with input you don’t expect. This is especially important when you are dealing with forms.

And last you should also use something like Browser Stack to do cross browser testing. Just to make sure there aren’t any problems with either your backend or frontend code in any of the browsers you support.

The reason you want all of this is to make sure that a) everything works right now b) test if some changes you made broke something c) see if performance improvements actually improved things.

Using a higher order function to deal with exceptions

05.03.2018 01:00

I have a longer and complicated relationship with exceptions, and I do in general think that they are the right solution, but I’m not a fan of the syntax. And I also think that they are not always the best solution. For example I personally think that to throw an exception when you are trying to fetch something(as in one exact row) from a database and don’t get anything back, I would prefer null instead of an exception because it ends up being a lot of code to deal with something very trivial. But when there are actual problems (like you try to get one of something and there are many, then you should get one). Long story short.

You have many different approaches when it comes to dealing with Exceptions. There are problems you can recover from and then you have those you either can’t recover from or those you don’t know about. I say use a specific solution to fix the former. But I often use generic ones when it comes to dealing with “the rest”.

I have written many versions of the higher order function below over the years. It is a simple HOF to wrap a function that will or might trigger an exception in a try catch and deal with it. For me it almost always means sending some feedback to the user and reporting the error.

Web Development in 2018

05.03.2018 01:00

Web Development is in a weird place for me at the moment. The choices for front end development are pretty solid. Frameworks or libraries like React, Vue, Ember and Angular are pretty solid; I personally prefer React, but all of them are good. Backend development on the other hand is in a weird place for me. I have used both Django and .NET a lot in the past. But neither of them are what I want in 2018 or 2017 for that matter.

The good thing about Django is that everything is easy to do and you get all the tools you need to build a database driven, fully tested RESTful JSON API out of the box. And you get the same with .NET Core. What I don’t like about both of them is that there are a little bit too much “magic” in other words stuff that the frameworks just does. The thing I don’t like about Django or Python is the lack of a solid type system, which makes the tests more verbose than needed and too much validation code. And C# and .NET have gone a long way, but there are still too many places where you need to define full classes to do simple things.

I spent a lot of time last year to see if Node + Express was what I wanted. And the answer is not quite. The reason is that I could come up with a setup that is almost there, but the type system is still too far away from what I want.

The next thing I started to check out was F#, Chicken Scheme and Guile. But none of them had all the stuff I wanted.

What I want is either a framework or a set of libraries I can configure to Database Migrations, define database tables in code (ORM), write RESTful API’s, manage authentication etc. And I want the language to have a good type system, support functional programming well and most important be fun to use.

The thing I mean when I say “good type system” is to define what kind of parameters to I expect to get of what type over URL parameters, GET Parameters and BODY data. Ideally those who are required and not required.

What I have decided to use for now is Clojure. It is a LISP, which I love. And I think everything is just a question of setting everything up to work like I want to. My “starter” project is on GitHub but it is far from done.

What I Carry

05.03.2018 01:00

What I carry these days are more or less the same as always, with some minor changes.

I always carry three pens, and I rotate them from a collection of five that I have in active use: Lamy 2000(M), Pilot Vanishing Point(B), Pilot Metal Falcon (Broad Flex), TWSBI Clear Eco(B), TWSBI Black Eco(Sub).

All of them are inked up with the same ink, as always. I currently use the Diamine Sargasso Blue, which I reviewed a while back.

As always, I use my Nock.co Hightower to carry my pens and pocket sized stuff.

Some of this stuff might change when Nock.co releases their A5 and Travelers Notebook Covers.

#

04.03.2018 01:00

I’ve been looking for a good replacement for Django for a while. What I like about Django is that you get everything you need to build a database backed backend out of the box. What I don’t like is how bad of a fit Python is for functional programming, and because the type system isn’t that great.

Clojure seems like the best option I’ve tested out this far.

#

02.03.2018 01:00

I have been trying to get into meditation for a very long time. I think some of my first attempts where back in 2009. It have been difficult to identify what is important and not. And I gave up after reading countless books. The “breathing” app on my Apple Watch got me back into it, and I used the Oak app for a while. Before I started to use Headspace a few days ago. It is awesome. And I would encourage anyone that want to get into it to check it out.

#

02.03.2018 01:00

Decided to pretend like I’m a designer and write some styling for my micro blog last night.

A single Apple OS

02.03.2018 01:00

There was a lot of talk about the merging of iOS and Mac OS at the end of last year. And I never wrote anything about it, because I never made up my mind what to say about it.

When people start to talk about a single Apple OS, I assume they are talking about making them more similar under the hood. Because I know I don’t want OS X on my iPhone, and I certainly don’t want iOS on my MacBook.

I’m certain that there is a “Core” that is maintained separately from OS X, iOS, TV OS, Watch OS etc. And that is the “Apple OS” everything Apple makes with Apps shares. And I think that Apple will, and I also think that it is in their interest to limit the differences between the platform as much as possible. One of them is to make sure that the API’s on their platforms are the same, except for where there are really good reasons for doing so.

If expanding from iOS to OS X would be more like adding an extra Storyboard to the Xcode project, I assume that it would be more of an option to add OS X to the supported platforms. This would solve many problems that both Apple and third party developers have. It is hard to maintain many different projects at once. And by limiting the number of them, and making them as similar as possible, without turning Y into X or X into Y, you could end up with more Mac Apps. And more Mac Apps adding support for iOS. For example the app I’m writing this blog post into (MarsEdit).

I think the biggest issue with maintaining both iOS and Mac OS at this point is that even the most trivial stuff like a fucking colour is not the same across the different platforms. Making Apple’s development platforms more modern is a story for another day.

Optimising your Web app

02.03.2018 01:00

Let’s say you are building a new web app. When should you start to optimise it?

I personally think that starting to make sure something is as fast as possible is the last thing you should do. Because there are a number of things you should think about and test out before you start on that.

First, you need to make sure that what you made are doing what you want it do to.

Second, make sure that what you made are needed and add value to your product.

Third, make sure all the user experience is how you want it to be, so that your target users will actually use it.

Then I would start to make sure everything is as fast as possible. This means everything from how fast your code is to how large the code the browser have to load is. My approach to optimising have always been to find the way to do something that requires the least work. For example by limiting how often you commit queries to the database(saving data), using the fastest possible queries to fetch data and, if you are looping over data: always continue to the next row as fast as possible when there is no point in running a lot of extra code.

If you’re still not happy with the performance I would start to debug and identify the parts of your code that is slow and try to find better ways to do that.

In the backend it’s often about optimising how you deal with the database and to cache slow stuff in memory (redid) and on the front end is it often about using many smaller methods instead of large ones and to limit how often stuff are re-rendered.