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.


01.03.2018 01:00



01.03.2018 01:00

Hot tramp, I love you so! 🎵👩‍🎤


01.03.2018 01:00

Testing out Firefox, for the first time since the Chrome Mac Beta. It’s fast, but damn it is ugly.


01.03.2018 01:00

Dear designers: can you please stop hiding the fucking sign-in button.



01.03.2018 01:00

Gnu Artanis. A Web Framework for Guile (the GNU Scheme implementation).


01.03.2018 01:00

Three things I want from a future X-Pro 3:

  • In body stabilisation.

  • Larger battery

  • Quieter shutter.

When to do client side and when to do server side

01.03.2018 01:00

When you are doing a web project in 2018 you have the choice between doing most of the heavy lifting server side or client side. The former means that you render most or all of the HTML before it reaches the browser, while the latter means that you only send a minimal HTML file from the server and the browser will use API’s and Javascript on the browser to produce most of what the user end up seeing.

There are pro’s and con’s to both approaches, and there are times when one is better than the other.

If you are developing something where the content is in focus, in other words where the user of your web site are primarily consuming the content like for example a blog then doing more of the work server side is the better approach. Because it will load faster and less resources have to be transferred to the client.

But, if you are developing something where there either is a combo or where user interaction is the primary thing. What we call a web app. For example Gmail, Facebook or Twitter, then doing more on the browser is better. This is because it enables us to do more advanced functionality that in the past was reserved for native apps.

Like always, it depends on what you are building. I see a lot of people bringing in huge frameworks using for example Angular or React when it is unnecessary and the only difference between that and doing it with some backend language like Python or PHP + some plain JavaScript is a lot more JavaScript assets than needed.

Just because a modern framework is there, doesn’t mean it is the right thing for everything. Or for all parts of what you are building

Why I shoot film

01.03.2018 01:00

I shoot both film and digital. And I use them for very different reasons.

When I want to make sure that I end up with some good images I always bring my X-Pro 2. I can shoot duplicates and make sure that I at least have some good images at the end of the day. No matter how the lighting conditions are. But I often bring my 35mm camera instead if I just want to shoot for fun.

If you go for a film camera you can more or less anything. I personally prefer very manual cameras, but you can also get something that are more like a modern DSLR or a point and shoot. The reason I prefer manual cameras is that they just work, even without a battery. And you just expose and shoot. This process is a very useful to really understand how light and the different settings on your camera works together.

The reason people shoot film vary. Some do it because they like the process, others like the simplicity and some because of the look of the films they use.

I shoot film because I enjoy having some stuff in my life that don’t require me to re-charge the batteries all the fucking time. And I really enjoy how the images look. Good black and white film looks much better than anything I have ever gotten out of a digital camera. And I really love how goofy Fuji Superia colour film look. Some do it with filters, I personally prefer to go back to where the Instagram filters or Lightroom Presets go their looks from in the first place.