Hjertnes.blog

Battery usage on iOS 8.

September 23, 2014

iOS 8 came with a feature I remember from, back in the dark days, when I was using Android. And that is a neat feature that let’s you see which apps consume the most battery.

It’s a brilliant way to see what apps you use the most, and to get some pointers on where your battery power goes.

First of all, don’t complain to developers about them being on the top of the list if you are using the app all the time. Overcast, Audible, Spotify together with Unread and Tweetbot, will probably high on my list, most of the time. The reason is simple: I listen to audiobook, podcasts and music more or less all the time when I don’t study, work or sleep. While Tweetbot and Unread is the apps I launch when I have a few minutes to kill.

I think the battery usage list is a useful feature for two reasons. You can kind of see which apps you use the most. But, you can also see if there are some app that use way too much battery related to how much you use it.

For example. I expect that the Facebook app would rise in the list, if I re-enabled the access to background updates and location data. I won’t.

Use the list, if you have some concerns about your battery life. The first thing I always do, to opitimize my battery life is to limit access to background refresh and location data. I only let a few apps have it.

Background refresh or update, or whatever it’s called, is something I limit to the apps where I need it; like unread. While access to location data, is something I limit by doing a simple test: is the app less useful without it. Tweetbot isn’t less useful without it, but Google Maps is.

The great thing about this list, is the same as with a similar feature in OS X Mavericks last year; developers have a real incentive to make sure their apps don’t use more power than they should.

(#blog)

R.I.P Macworld.

September 11, 2014

I rarely write about anything news related here. My usual reasoning for this is that I don’t have the time, a lot of other people do it way better than me. But the most important reason is that I’m not interested in it.

This is one of the few exceptions. My goal is to write about it, when I get the feeling “I have to write about this”.

The fact that Jason Snell is leaving Macworld, and the fact that the Macworld magazine are shutting down is mind boggling.

You have publications like The Wall Street Journal, The New Yorker or The New York Times; they have always been there; and I hope they will continue to be there, well beyond my death. I have always looked at PC World, and Macworld as the two publications that always was there. And it is sad to se that both of them are gone in a few months.

The print version of PC World was shut down a while ago, and now Macworld.

It is sad. But most of all weird.

A lot of great writers lost their job, and we lost our number one Mac-site.

(#blog)

Write good

September 09, 2014

Some people like long articles, while others prefer the short and concise versions. I have gone back and forth on this question many times. But I think I have managed to make up my mind.

Some people like to read the kind to writing that contains long sentences, complicated words. While others like short and direct sentences, that use the simplest and most direct word available.

I read a lot of writing from both camps. Two of my favourite authors are Bukowski and Hemingway. Both of them had a style that give me a lot, if few words.

I don’t care either way. Write your text as long as it need to be, but also edit it down to be as short as it need to be. There are good and bad ways to form a sentence. Some people are competent enough to write long sentences, without making them hard to read. There are times for complicated language, but rarely.

My style here on this site have always been to keep it as short as possible, with the simplest and most direct wording possible. While at the same time telling the reader what I want to say.

Don’t write 35000 words, just for the sake of writing 35000 words. And don’t use fancy words, because you think it makes you look any smarter. The brightest people, and the best writers I know, write short, with the simplest terms in their possession.

(#blog)

You aren’t a content creator.

September 08, 2014

I don’t like imprecise descriptions, or definitions. And I hate passive writing even more. The thing that fascinate me more than anything is that people think they are content creator. What is a creator? A creator and the creator is two very different things. What is content? Well, content is more or less anything.

This bullshit need to stop, right now.

You are a writer, you are a podcaster, you are a photographer you are a “whatever the people creating video’s for youtube are called”.

Be precise. Tell people what you do. Don’t use generic terms. A content creator could be everything from sending dick picks over snapchat to writing a very popular site.

(#blog)

Some thoughts regarding markdown flavours, and standardisation.

September 07, 2014

Markdown is more or less the de-facto markup language these days. And some people are trying to standardise the whole thing. I, and a lot of other people have some problems with it.

My problem with the whole thing is the following 1. They didn’t give Gruber the time to answer them 2. It doesn’t come clear in the name what they are trying to do; example GitHub flavoured markdown is a good name. While Standard Markdown is obnoxious and misleading. 3. Do we need a standard?

There are many versions of Markdown; in many ways. You many different parsers for the original format that Gruber made, there are minor differences in most of them, but I don’t think this is a major issue.

And there are a few different other versions that extend on the original. Like MultiMarkdown or GitHub flavoured markdown. All of them add something to the mix, that the original doesn’t have. Which one you use, depend on your needs.

I use MultiMarkdown a lot, because I like Footnotes.

We don’t need “one markdown to rule them all”. It would be nice to have a test suite to make sure that all parsers do the basic markdown parsing more or less in the same way. But it’s not something we need to have.

The thing I would love to see is a project that takes all the different flavours of markdown out there, and highlight the differences. In other words: makes it easier for people to pick the flavour that’s right for them.

(#blog)

The minimalist home screen.

September 04, 2014

I can’t promise anything, but I think this will be the last one about home screens I’m a while.

One of the requirements I set for apps on my home screen is that I launch them every day. Or at least five days a week. In other words, every day I’m doing something more productive than listening to podcasts or audio books.

My home screen is usually not full. And I do this for a very important reason. Few apps there, makes it easier to find the app I need.

Give it a try. It makes my day to day life much easier. And I think it could make yours simpler too.

(#blog)

Managing your home screen

September 03, 2014

Shawn Blanc wrote something very interesting when he linked to my iPhone setup.

I like to think that my iPhone’s first Home screen is organized much like Eivind’s --- that the apps on my Home screen are the ones I actually use regularly. But part of me wonders if I’m just so used to my Home screen apps that these are actually only the apps I think I use every day.

My iPhone dock and home screen see radical change every 2-3 months. This is something I do on purpose, to avoid having a dock filled with apps I think I use a lot, and a home screen filled with apps I also think I use a lot.

This is how I look at it. My dock is for the apps I launch a lot — or need to have access to very quickly when I need them. Like for example drafts. While my home screen is for the apps I use a lot. Not that apps I would like to think I use a lot.

My method for making for making sure this is the reality is both simple and easy to do.

Move everything off your dock and home screen and leave it empty.

Everything is empty, and you have some room to fill. The first thing you need to do is to make a mental note of the apps you launch all the time. Start moving them to your dock or home screen.

My personal opinion about how to organise the apps is the following. The dock is for everything you need to access fast, or launch a lot. While the home screen is for apps you use every single day.

Good luck organising your iPhone.

Remember, you don’t need to have the calculator and camera app on your home screen. It’s pretty easy to access them via the control center.

(#blog)

My iPhone homescreen.

September 02, 2014

My iPhone homescreen is at The Sweet Setup. It’s amazing and scary to have my home screen posted on one of my favourite web sites.

Thanks Shawn Blanc, Steven Hackett and the rest of the Sweet Setup Team. Shawn also linked to the interview.

(#blog)

Relay.fm

August 31, 2014

Relay.fm is Myke Hurley and Stephen Hackett’s new podcast network. All of Myke Hurleys shows was moved over from 5by5. All, except for The Pen Addict have a new name. And he also started a new podcast with Casey Liss.

I wanted to write about it, the day they launched; 18th of August. It didn’t happen. The short story is that I spent a whole week being sick, and last week was just insanly busy.

Relay.fm is a fantastic podcast network, with great shows. You should check them out.

(#blog)

Code, and comments.

August 24, 2014

I was just listening to Pragmatic, and John had Guy English on. They were talking about something I care a lot about, code.

I’m a huge fan of writing small units, classes, method and so on; that do one thing — the right way.

Before we move on, I don’t do all of this, all the time; but that’s just like testing. I wish I could, but I don’t have the time often enough.

There are a few things we programmers could do to our code, to make it easier to understand. Variable names, method names, class names, comments and explaining it in a readme file.

I try to always give everything a name that explains more or less what it is. And I also try to write a simple readme file that explains all the important information regarding the project.

One of the reason I don’t write as many comments as I should do, is because of all the bullshit comments I have seen in source code during the 10+ years I have done software development.

The most obvious, as most important rule is to not comment things that a experienced developer in the field you are working would understand. You don’t need to write a comment on the following python line “counter += 1”. Every Python programmer, and probably most other experienced developers would understand it.

I’m a strong fan of having small files, that are containing exactly what you need; and just that. And those stupid author and copyright comments drive me nuts. Put it in at text file, or git. It’s not that hard to export it, if you need to.

If you use good method, class and variable names, then you don’t need to comments most of your code. And the same goes for writing easy to understand code. Avoid “smart” tricks. It’s better to have longer code, if it makes it more maintainable.

But, if you need to use some fancy hack to make the performance better. Comment what it’s doing, and why. And write comments if you have something where the name don’t explain what it’s doing.

In other words, document how the project works in a readme file. And use standard conventions. Python have standards, and so does Objective-C — use them! And comment everywhere it doesn’t explain itself, or where you can’t follow the standard for some reason.

(#blog)