honekamp.net

Is 3 Read for Prime … Wait a Minute

Stop, I’ve already spent this headline, albeit on a different subject.

This time, however, I’d like to briefly discuss my first impressions of Octopress 3, the next evolution step of the static blogging engine I use for publishing this blog.

Octopress 3 has been around for a couple of weeks. As I write this, Octopress 3 can already look back to a rapid succession of bug fix releases ending up in the currently available 3.0.11.

Of course, as a user of Octopress 2, I’d be intrigued1 to see how the platform is making its way into the next major release.

When using Octopress 2, it does not become immediately visible that the heavy lifting of blog generation is actually done by Jekyll, and that Octopress 2 is basically a convenience wrapper around Jekyll that takes away some of the rough edges of directly using Jekyll for blog generation.

Octopress 3 takes a different approach in that it clearly separates its job to “logistics tasks” on top of Jekyll, and then let the user actually call Jekyll as part of the publishing workflow.

I don’t have a problem with this approach, as long as it’s working as advertised. Which it does, as far as I can tell.

At least, I was able to install Octopress 3 and further gems2 as well as to port my blog to the new engine quickly. Menaing: it took a short amount of time after having installed Octopress 3 until I got my site up and running served locally by Jekyll.

That’s not the end of the porting effort, though. The slugs generated by the combination of Octopress 3 and Jekyll are different than the ones generated by Octopress 2.

This is a bummer, and leaves the option to either tweak the new workflow to the point that it creates identical slugs as my existing engine, or else create redirect permanent rules into a .htaccess file to accodate for the change.

Of course, the .htaccess file is sort of the last resort. And it would be nicer if the job could be done directly as part of the generation process.

And it turns out: the easiest way to generate the slugs as required is to drop all the categories from the blog. Which is OK, I have used the categories more or less halfheartedly and getting rid of them is not such a big deal.

The landing page that I end up with consists of a list of article headlines as opposed to a list of full articles, as I end up with in Octopress 2.

Customization will be necessary. This has been foreseen by Brandon Mathis, the main contributor to the Octopress project. It seems that it will be possible to define Themes as a measure of customizing a blog extensively.

There is a default theme available, called Octopress Genesis. According to its description, it is a “work in progress”. It is certainly possible to use the theme as is, but I unfortunately failed to find out how to apply any customization to it that was respected in the generation.

In principle, it should be possible to overwrite the default theme by putting the respective files into the _plugins directory. I tried several variations of putting the files into the directory, but to no avail.

Maybe this is part of being “work in progress”. I looked up how plugins are processed by Jekyll. I didn’ get the impression that themes are processed as plugins, but maybe that’s just me.

Anyway, the theme also does not generate a landing page that is a list of full article text either. On the bright side, it takes care of footnotes in the way I prefer footnotes to be taken care of: Bigfoot style. And, just to name another nice feature, it is possible to add pages to the site in a very simple way.

Granted, it would be possible to tweak the theme in its default installation location. But, frankly, that’s an evil hack. In conclusion, without being able to customize3 the theme Octopress 3 is not really usable.

So no, not ready for prime time so far. Not for me, at least. I’ll need to invest more time to better understand how the customization of Octopress 3 is supposed to work. But never mind, I can wait, no problem.

  1. I’m not a web developer, but I’ve always enjoyed tinkering with Octopress, and thereby get in touch with technologies unexplored.

  2. From the technical point of view, Octopress 3 is delivered as a gem rather than a bunch of rake tasks.

  3. I mean, a serif font, come on …

And Now?

Software has issues, and software on iOS is unfortunately no exception to this rule. From time to time, as I stumble upon something unexpected I usually I go ahead and report the issue back to the developer, go through one or two iterations of making my point better explained1, and hope for the best.

Thus was my first impulse in the case that I’m going to unfold in this article. But then it occurred to me that I don’t understand the problem to the extent that I could even decide where to aim the bug report to.

Take Unread. Take Instapaper. Take the combination of the two in form of the Instapaper extension launched from within Unread.

OK, here’s my story. What happens is that the first time I swipe right in the article view of Unread, select “share”, and then the Instapaper extension, everything works just fine. The shared article appears in the Instapaper queue just fine. No complaints.

The second and all following times (until Unread gets restarted) I try to use the Instapaper extension again I’ll be presented with the list of extensions configured on my device, only the Instapaper extension does not appear.

It is also missing in the list of extensions, as if I did not have Instapaper installed on the device. Which is quite regrettable, because it happens that I want to add more than one article to my Instapaper queue and I get hit by this issue every single time.

The only remedy is to use the Safari extension to open the article in Safari and then launch the Instapaper extension from within Safari. And sure enough, the Instapaper extension launches from Safari, every single time.

Going back to Unread, the extension is missing again. As if it wasn’t there.

OK, but what happens if I, say, use the Evernote extension from within Unread? Will it also be missing the second time I try to use it.

Nope, it’s there, right next to the Instaper extension that magically appears again, after I used the Evernote extension to save an article.

I have heard of many complaints about extensions being reordered frequently. But I haven’t heard of extensions just going missing, and then reappear again out of thin air.

So, who should I complain to in the hope to get this annoyance fixed?

All of the above?

  1. to be fair, the developers are usually quite open to my support queries. In many cases I just fail to describe the issue as precise as I should have.

Day One Sync

I’ve had my troubles with the storage options provided by Day One, and in the last few years I’ve put everything onto Dropbox because this option used to be way more stable and reliable than using iCloud.

Yesterday, the folks at Bloom Built released a new storage option to the world: Day One sync. I couldn’t resist trying it out. Let me tell you: this thing is fast! Switching over several years worth of journal entries took less than a minute on my iPad.

Of course, only time will tell whether the new option is also reliable but the first impression makes me trust the developers of this feature. Plus, there are hints that the new storage option will be taken as the basis for a much improved feature set:

Beyond syncing, this service is vital to the future of the Day One platform. It lays the foundation for numerous features in the future, including:
• Multiple journals
• Web-based version of Day One
• Shared journals
• Multiple photos
• Journaling via email
• API and IFTTT integration

Nice!

A Hardware Keyboard for iPad

I’ve been toying with the idea of an external keyboard on my iPad for some time now. There are several options available, from the more or less loosely integrated approach of the Incase Origami Station to a more tightly integrated package (where the keyboard is part of the iPad cover) that can be purchased e.g. from Logitech.

My idea of a keyboard for my iPad primarily follows the tightly integrated approach because this seems to be better suited for being carried around and requires less effort to get the entire rig into operation.

Enter the Logitech Type+, a protective case and keyboard for iPad. Snap the iPad into the cover and you’ll be presented with a laptop-like setup that is really fun to work with. Nothing beats having a full screen of text without the on-screen keyboard taking the better part of the screen real estate.

The entire package, iPad plus Type+, weights something in the range of 900g. This may seem unbearably heavy for an iPad, and yet this number is in the same ballpark as the new MacBook which can be rightfully considered as a super-lightweight workstation.

On top of that, you can separate the iPad from the case and enjoy less weight at any time. If this was the only concern, I think I could easily live with it.

The product can be used in two different positions, one for “creation” (with the iPad in a near upright setting and keyboard activated) and one for “consumption”1, with the iPad positioned flat on the inactive keyboard.

Pairing between iPad and the Type+ couldn’t be easier. It just works. However, it only works if the correct version of the product is used. Due to oversight from both myself and the sales person in the Apple Store I went out first with the version for iPad Air and that one refuses to pair with an Air 2. So keep your eyes on the numeric qualifiers when purchasing.

The build quality of the keyboard is within the expected range, i.e. definitely worse than a Mac keyboard and similar to many PC laptops that I already have had the pleasure to work with.

I’ve got the German layout and I’m happy to report that the key combinations for e.g. square brackets are exactly the same as on my Mac2.

The keyboard features an extra (top) row of function keys specifically tailored to be useful on iOS. These are (from left to right):

  • Go to springboard.
  • Activate task switcher.
  • Search. Note that the focus is not set to the search text field automatically. In order to actually start searching it is necessary to manually tap the search field to set the focus to it. This is inconvenient for obvious reasons because the keyboard-centric workflow is interrupted.
  • Language. On pressing this button, an on-screen menu appears that displays the new keyboard3. The keyboard layout changes to the selected language. As far as I can see, there is no way to keep the layout that is printed on the keys and just switch the spell checking (like on OS X).
  • Activate on-screen keyboard.
  • Take screen shot.
  • Media control: rewind, play/pause, fast forward.
  • Volume control: speaker on/off, volume down, volume up.
  • Put iPad to sleep.

As expected, the actual switch of the keyboard Layout is one of the most glaring downsides of using a hardware keyboard in iOS. You better be good in memorizing key positions in different keyboard layouts.

Admittedly, it is beyond the keyboard manufacturer to “fix” this. This is a consequence of someone at Apple thinking that it would be brilliant idea to bind the spell checker to the keyboard layout and not let people select keyboard layout and spell checking language separately. Let me tell you, it’s not.

Interestingly, there’s a hole in the cover through which the back camera could take pictures.

Theoretically.

In reading mode, this does not work because the camera points at the underlying keyboard. The only way to actually use the camera would be to put the iPad upright in the cover or else hold the iPad in your hand with the keyboard part dangling. Just don’t.

I’ve come across reports from customers at Amazon such that physical contact between the keyboard and the iPad’s display may cause scratches on the latter. Well, all I can say is that if you hold the folded cover against the light such that the small gap between the keyboard and the iPad becomes visible I can see the point of such claims.

There is one area, right above the keyboard itself, where the iPad and the Type+ touch each other even if there is no stress put on the cover. I can imagine that given some stress and movement between the iPad and the cover damage could very likely occur.

This is a shame because The cover seems really sturdy and able to protect the iPad against influence from the outside. In this case, however, the weak point may very likely be on the inside and that is just sad.

I guess it would not do any harm to always have a piece of microfiber cloth handy.

All things considered, I’m personally in two minds about a hardware keyboard and the Type+ in particular. On the one hand, I can type much faster on a hardware keyboard and There is a lot to like about the function keys.

On the other hand, having to memorize key positions and, in consequence, blindly use a significant part of the keyboard isn’t fun at all and decreases my average typing speed a lot. The gain provided by the existence of the keyboard is effectively consumed by the necessity to find the correct key.

Plus, the sheer possibility to physically damage the display when putting the cover into a bag for transportation is outright scary.

I’m not a big fan of using the on-screen keyboard but the downsides of the Type+ will probably weigh heavier than the benefits I can take from it. So far, I haven’t tried writing in portrait mode using the on-screen keyboard.

In portrait, the ratio between the part of the screen that contains text and the part occupied by the keyboard is much higher than in landscape and this would at least mitigate one of my complaints about using the on-screen keyboard.

But don’t get me wrong, I still believe that the Type+ is a great addition to an iPad if the user does the majority of writing in the language supported by the particular variant of the Type+.

  1. Sorry, Federico, could not resist.

  2. This information is a special service for the geniuses at the local Apple Store.

  3. This works in pretty much the same way as keyboard switching using the on-screen keyboard.

Yosemite Is Trolling Me

My current wallpaper is a dark one, a picture of the center of our galaxy. Obviously, it stands in stark contrast to the light menu bar.

In an attempt to mitigate this nuisance, I have switched on the dark mode introduced with OS X 10.10, a.k.a. Yosemite.

I understand that there is some debate about both the concept and the implementation of the dark mode, but in my particular case, it really solves a problem.

And yet, every now and then, when I wake up my old and trusty 2011 MacBook Pro from sleep the dark mode mysteriously has been switched off again. I haven’t been able to find related information on the Internet, so it does not seem as if this is a common problem for a larger group of people.

This has happened and continues to happen with every version of Yosemite from 10.10.0 to 10.10.2.

Weird.