29.06.2019 17:53


22.06.2019 14:08

MacBook repair

19.06.2019 18:50

My MacBook Escape will hopefully be back home tomorrow. I handed it in to the largest Apple Norwegian Premium Reseller, and I think they are the official repair place for most Apple products in Norway.

What happened was that my MacBook have had some issues booting the last few months, but jumping into recovery and a repair drive usually fixed it. Then in the beginning of June it refused to boot at all, but it worked fine to boot with my SuperDuper clone. So I handed it in. My hunch was that the drive was dead.

I have received some updates from the technician as they have been looking into it, and they made it clear that it will all be covered by Apple, not because of warranty but because of customer protection laws in the EU (plus EFTA etc). First they ordered a new logic board (plus keyboard, trackpad and battery, and the casing around the keyboard etc; all of that is one “part” apparently). Then they found out that they also had to replace the drive.

My guess was that it was just the drive that was broken, but I’m not going to complain about them giving me all the guts of a new machine for free, and I get to keep my stickers.

But I think Apple have lost a lot of money on this machine, because first I got a new machine when the keyboard broke, and now they replace most of the hardware again.

Now, I also have some worries about this whole “your computer is basically three parts” strategy. It probably makes sense for Apple, when they have to pay for it. But lets say someone got a MacBook Pro in 2016 and it works fine, but they want a new battery in 2021, and they’re told: you have to replace more or less everything inside this computer to do that. How do you think they react?

I guess they have reasons, but there got to be a way for us, the consumers to replace stuff without having to pay for half a computer, either through them being able to recycle the parts or something.

A week without the Apple Watch

15.06.2019 17:23

I have gone over a week without the Apple Watch now, and I don’t miss charging it, or having constant access to push notifications on my wrist.

But there are some features of the Watch that I miss, most of it have been replaced by various Shortcuts and other stuff. What I miss is:

  • Playback control: to be able to play, pause, skip etc on the Watch was one of my favorite features.
  • Timers: I miss how fast and easy it was to manage them
  • Due and Drafts: two of very few apps that is awesome

At the moment I don’t plan to get back into it, but I might if I continue to miss the features.


14.06.2019 19:13

React-Redux 7.1 brings hooks.

12.06.2019 17:57

The way grownups handle state in larger React apps is with Redux, and the only way to use it from React is by using the React-Redux package. Instead of the state being a part of your components it becomes a separate thing, this has many advantages like separation of concerns, easier to make re-usable code etc. The way it works is that you set up your redux stuff with reducers, actions, action creators etc, create a store and add that as near the root of your react app as possible. Then you used to use the connect function to inject state and actions into your components.

Connect is great, you can do a lot with very little code, but it is a little bit hard to explain to new people, and it can be a real pain in the ass to debug. The way most people use it is that you give it two callbacks one for selecting data from state and a second one for wrapping your your action creators in dispatch, and then you pass your component as the argument to the second function. It usually looks something like this: connect(({value1, value2}) => ({value1, value2}), dispatch => ({someAction: (input) => dispatch(someAction(input))})(Component).

It isn’t great, but the best we have had, and you can make it a lot better with some functions that make the job of mapping dispatch more automatic and having selector functions that select state etc.

The new hooks introduced in react-redux make this a lot better though. With this you can make proper container functions that are declarative. You can use useSelector to select values from the store, and useDispatch + useCallback to create wrapped actionCreators. I have not used it yet, but I do think it looks very promising. And I’m always a sucker for more declarative code.

More pens in rotation

09.06.2019 12:26

For some reason I just went a little bit nuts and inked up all the pens I love using last weekend. I’m not carrying all of them all the time, usually just two. But my plan is to rotate between them. All of them have different things I like about them

  • YStudio portable fountain pen
  • Lamy 2000
  • TWSBI Eco Broad nib
  • TWSBI Eco Stub nib
  • Pilot Vanishing Point
  • Pilot Metal Falcon

I’m not sure how long it will last. But I’m writing more with pens that I have in a long time at the moment. When I got into Pencils last year my fountain pen use went way down. But I think things are back to something more balanced now.

My take on test driven development

09.06.2019 12:18

If you do formal Test Driven Development (TDD) there are some rules for how you should do it, like you start with the test, then you write a failing test, but not more than to make it all fail. Then you fix it, add another test etc.

I’m not into this for a number of reasons, but I do agree with the basic idea: you don’t write anything without also writing tests to make sure it works. It takes some time, but it will save you a lot of time as you move forward.

This is how I do it for backend code:

  • I write the controller, and then the services behind it, plus model changes etc that are required for the controller to do what it needs to do. Sometimes that also means so extra filter/middleware stuff etc.
  • When the code makes sense I write tests for it.
  • I exclude what I don’t need to test (classes with just setters getters) or can’t test
  • Write unit tests for the rest
  • Finally I write a test in Javascript that use the controller over HTTP

The big difference between them is that I only care about making sure there are good tests in place by the time I’m done; how you do it isn’t that important.


07.06.2019 17:16

It never stops to impress me how many blog posts I read or skim each week.

Dealing with weird bugs

03.06.2019 04:59

I spent most of the day today at work dealing with a weird problem. The summary is that when add prettier as a dependency in a create react app based front end project jest breaks down and none of our tests work. The reason as far as I can tell is that something weird happens to the dependency graph and some babel runtime stuff aren’t where it should be.

When stuff like this happens, and I have no idea what’s going on, I try to locate what I think is the reason for it. Like in this situation I thought it was some dependency doing something weird.

The process from there was to remove everything except react-scripts from dev and regular dependencies. And start the process: run tests, add the dependency it complained about, and repeat until I either got it running or I met the issue.

To my surprise I managed to get it running before getting there. Then I added linting to the mix. Run tests, run lint, add missing dependency.

Then when I discover the problem child I start a new blank project and tries to reproduce it there.

The reason I do the last thing is to make sure it isn’t anything dumb I have done.

My experience is that it is usually because of something I have done, and not a real bug.

The idea behind finding problems is to figuring out where it is, that means where it is not. The most efficient way is to just start in one end and just start looking.

It can be really time consuming. Or is really time consuming. And there are no short cuts to finding the kind of problems that don’t give you any hints.

You just need to think straight, pick a strategy and start in one end.