The Stochastic Game

Ramblings of General Geekery

The Journey to Digital Comics

You may have noticed that, a couple months ago, I bought myself an iPad 2 as an early Christmas present. This was the result of some market research based on a few requirements I had for my next big household change: transition from paper comics to digital comics.

The incentive to start reading digital comics was pretty obvious: after moving my music, movies, TV shows and books to the digital world, it was only a matter of time before I would do the same with my comics. Sure, just like I still like to own some books in physical form, I will still buy some of my comics at my friendly local store, but, realistically speaking, more than two thirds of my collection is just enjoyable stuff I don’t care so much about – I want to read it, but the book itself is not especially beautiful, and it’s not something that would impress my guess when they spot it on the shelves.

IMG_5680.jpg

For me, going digital is all about reclaiming space and uncluttering the house where it makes sense.

As a result, here’s my “Journey to Digital Comics”, in the tradition of Mike Vardy’s Journey to…” series:

  1. The Journey to Digital Comics: Reading Device
  2. The Journey to Digital Comics: US Comics Apps
  3. The Journey to Digital Comics: Manga Apps
  4. The Journey to Digital Comics: Pros and Cons
  5. The Journey to Digital Comics: On Ownership and Stuff
  6. The Journey to Digital Comics: Conclusion

Edit: it turns out there’s a lot more to say than I expected, so I expanded the series a bit.


PieCrust 0.2.0

It’s been a busy few weeks, both on PieCrust and on a couple other projects. I pushed versions 0.2.0 through 0.2.3 and didn’t even have time to write about it until now! Here are some details about what’s new and what’s changed.

Hot Pie

New Stuff

  • Pagination: that was the main focus for this version. On the pagination object you’ll find a whole bunch of new properties and functions, like the number of posts actually on the page, the total number of posts and pages for the current filter, or the indices for the previous and next pages. This will let you build layouts like Yahoo’s pagination patterns.

    There are also a few methods you can call to change the pagination filters for the current page, like skip(), limit(), with_tag() or in_category(). This is pretty handy for special pages that need to list a specific set of articles.

    Last, but not least, the complete set of categories and tags are exposed as (wait for it) categories and tags. You can iterate on them to get their name and their post count. This lets you build things like tag clouds and archive listings. This one may change a bit in the future, however, since I’m not too happy yet about how it works. Feedback is welcome!

    Use the template data debugging window to inspect the pagination object and see what you can use.

  • Twig Filters: There’s a new Twig filter called nocache, which appends a timestamp to an URL. This is useful for preventing cache issues on resources like CSS files. You can of course combine it with pcurl: {{ pcurl('styles/default.css')|nocache }}

  • WordPress Import: The WordPress import was broken for a while, but it’s been rewritten completely so it’s as good as new. Also, it now not only supports importing from an XML file exported from WordPress’ dashboard, but also importing directly from WordPress’ MySQL database, which is faster in some cases, and necessary in others (like when your blog was hosted on wordpress.com.

Changed Stuff

  • The skip_patterns configuration setting for excluding files from a bake is now evaluated against the root-relative paths instead of the filenames. This means that if your pattern was a regular expression like ^_, it will no longer exclude any file or folder starting with an underscore – instead, it will only exclude any file or folder starting with an underscore at the root of the website. It unfortunately makes some scenarios a bit harder to do, but the point is to make brand new scenarios possible.

  • The chef init command, which creates a new empty website, doesn’t add files for Apache or IIS hosting anymore. You can create them by passing the --apache or --iis parameters.

  • Old bugs have been fixed, new bugs have been written!

Next Up

The next tasks involve actually updating the documentation on the PieCrust website, and working on version 0.3.x, which will feature support for user plugins (effectively making it easier to add formatters, template engines and bake processors).

As usual, grab the latest version of PieCrust from the BitBucket or GitHub repositories.


New PieCrust debug window

There’s a new experimental feature (meaning: only in the new default branch) that makes the debug window more useful. The debug window is a little known PieCrust feature that used to only show you some caching and performance information on the bottom right corner of your website. But now you’ll notice a second line about “template engine data”:

If you click on it, you will see all the template variables exposed for the page you’re currently viewing.

Not only is it useful for troubleshooting things, but it’s also a great learning tool. Tell me what you think!


PieCrust code changes

There’s been some big changes in the PieCrust codebase recently: some refactoring to make unit-testing easier, the creation of a second branch, and the creation of a satellite repository for the application’s code alone.

You won’t care much about the first one (the refactoring) although you may have to expect a whole bunch of new bugs, which will hopefully be easy to test and fix since the whole point of this refactoring is to make testing easier. The other changes are important, however:

  • There’s a new stable branch which will, well, be kept as stable as possible. This means that new features introduced in the default branch will stay there for a little while until they’re merged into stable. This branching policy is simple yet quite common, as explained by Steve Losh.

  • The "PieCrust Sample" repository now contains the partial history of the main repository. Yeah, I’ve decided to read the Mercurial documentation and found that the hg convert command is pretty useful in this case.

  • The new "PieCrust App" repository contains only the PieCrust app’s code in the root directory. This is useful if you want to include it as a sub-repository of your website’s repository – e.g. in a _piecrust directory. This way, you don’t need mix the PieCrust files with your own, and you can easily update by pulling the sub-repo. This one is also mirrored on GitHub in case you don’t want a Mercurial sub-repo for some reason.


Abandoning Remember The Milk

The milkify.com domain recently expired, and I didn’t really feel like renewing it. If you look at the (absence of) recent commits in either IronCow or Milkify, it’s easy to understand why: I’m not really working on those projects anymore. And that’s because I’m not using Remember The Milk anymore either.

To be fair, IronCow is pretty stable already – most of the latest changes were configuration management stuff and upgrades to Visual Studio 2010 – so it’s still usable. I’ll be available for bug fixes, of course, but if the guys at Remember The Milk add new features, I would probably not know about it and it wouldn’t be ported to IronCow unless somebody forks the project and submits a patch.

Milkify, however, won’t see any improvements unless somebody picks it up. It’s just not worth it to work on a tool I’m not using myself.

This means I get more time to focus on my new home projects like PieCrust and a couple of other bigger ones in progress.


Simple workaround for the iPad’s smart cover’s design flaws

I recently got an iPad (more on this later), and with it I got the much hyped smart cover.

IMG_4353.jpg

I loved the simplicity of it, and how quickly you can take it off and put it back on again… However, I quickly realized that I probably had more dust on the screen while using that thing than if I didn’t have any cover at all. Among the problems I had the infamous “dust lines” – those three lines you get on the screen at exactly the same spot as the cover’s folds.

The problem was pretty obvious: the natural way to fold the cover, and the way Apple advertises it, is as follows:

IMG_4357.jpg

But this results in the following situation:

IMG_4354.jpg

The iPad rests on the folded cover as expected, but the outer faces of that triangular stand are the faces that go against the screen when the cover is closed! They would therefore pick up dust and other particle directly from the table and all around, and put them back onto your screen as soon as you walk away… I don’t know where Steve Jobs used to go with his iPad, but my house is not always spotless clean, and neither are any restaurant tables or office desks that I want to put my iPad on.

An easy workaround for this problem is to fold the cover the other way:

IMG_4355.jpg

This way, the faces that go against the screen are actually inside the triangular stand, where they’re very unlikely to pick up any dust. This way of folding is a lot less intuitive, but once you get the hang of it, you can actually close and open it as fast as before. I haven’t had much dust on my screen ever since I started using this technique.

There’s just one big caveat to this workaround: it doesn’t work with the “stand up” mode.

IMG_4358.jpg

If you look closely at the picture above, you’ll notice what’s wrong: gravity alone can unfold the cover and make your iPad fall down on the table. In my case, the magnetic strength of the cover is barely enough to counteract the iPad’s weight and make it stand on its own, but the slightest touch can make it crumble down like a house of a couple of very expensive cards. However, I don’t care because I’ve never felt the need to use that position so far.


Article drafts in PieCrust

A common feature of a blog engine is to let the user work on an article for a while before actually publishing it. Thanks to pagination filtering, it’s pretty easy to do in PieCrust.

All you have to do is add the following to your blog’s home page’s configuration header:

posts_filters:
    not:
        has_tags: draft

This will skip any post that has the draft tag.

You will probably need to add some similar filtering to other pages such as the _tag or _category pages.

Edit: as Keilaron mentioned in the comment, you can’t modify the filters on a tag or category listing page, because their filters are preset to, well, filtering posts with a specific tag or category. This means that, unfortunately, you should not actually tag/categorize your drafts.

Edit 2: as of PieCrust 1.0, it’s possible to use a posts_filters on the _tag or _category pages, so it’s all good!


Fresh PieCrust available

I just pushed version 0.1.2 of PieCrust, the lovely static website generator that powers this blog, and most of my other websites.

Pie, anyone?

Yep, the version was bumped from 0.0.4 to 0.1.2. The main reason is that I very heavily refactored the code to make it a lot more readable and maintanable. This also means a whole new batch of bugs are lurking in the dark!

The main change for users is that there’s no _chef directory anymore. It’s all a lot cleaner, with everything living in _piecrust. Just be sure to delete your old directories before getting the new ones, so you don’t have old junk lying around. This also means that you need to (slightly) change your bootstraping code for running PieCrust. If you didn’t customize anything, you can just grab the new index.php from the sample website and overwrite your own. If not, you may want to check out the updated documentation on PieCrust bootstraping.

Among the new features, you’ll find:

If you want to see what’s planned in the future, there’s also a brand new public
Trello project board
.

Finally, check out the slightly redesigned and reorganized PieCrust website!


PHP is fucked up

You may be shocked by what I’m about to say but here it is: PHP is fucked up.

Well, duh

Oh, no. Wait. No you’re not shocked. You already knew it.

Today’s topic: namespaces.

PHP’s namespace implementation is fucked up. There’s really no way to say it nicely, and you will realize it 5 minutes after starting to use them, when most of your code breaks and you need to litter the beginning of your files with use statements and you really wonder what you gained in the process. It really comes down to the impossibility to import a whole namespace, and PHP’s inability to look into parent namespaces when a class is not found in the current one. Sure, I understand the first feature is actually very tricky in a dynamic language, and the second one may have been rejected because of performance reasons, but with that many downsides you have to wonder why namespaces were implemented at all. Pornel gives a good list of all those downsides in his article on PHP namespaces.

Sure, namespaces let us get rid of the PEAR naming conventions, and they work nicely with spl_autoload_register, but they also gave me my biggest WTF moment in recent history.

Consider the following code:

namespace Foo;

class BarException extends Exception
{
}

class Bar
{
	public function trySomethingSafe()
	{
		try
		{
			throw new BarException("Catch this!");
		}
		catch (Exception $e)
		{
			echo "Caught exception: ".$e->getMessage();
		}
	}
}

It defines a new exception type (FooException), and a class (Bar) that does something safe by wrapping the code of the function inside a try/catch statement.

Now run this from another file:

require_once 'foobar.php';

$b = new FooBar();
try
{
    $b->trySomethingSafe();
}
catch (Exception $e)
{
    echo "This should never show up, right?";
}

Well, guess what you get in your output window? Yep:

This should never show up, right?

It’s like the first try/catch block is not catching the exception! Surely it can’t be a bug in the PHP runtime, right?

Well, of course not. It’s the user’s fault. And that’s because PHP’s namespaces suck ass.

Look at the catch statement in trySomethingSafe: it’s meant to catch all types of exceptions by specifying the top parent Exception type, but this is actually not it. See, that code is inside namespace Foo, and I didn’t specify either a use Exception at the top of the file, nor did I use Exception’s full name, Exception. Yes, that leading backslash is really super important in this case, because it makes all the difference between what you meant (the standard Exception type) and what PHP understands (a completely imaginary FooException type).

To fix the problem, replace the catch clause in trySomethingSafe with this:

catch (Exception $e)

You will then get the expected result:

Caught exception: Catch this!

The tricky thing here is that PHP doesn’t seem to care that FooException doesn’t exist. It happily runs the script, gets the exception, which is of type FooBarException, figures out that the class name does not equal to FooException, and bubbles the exception up the call stack. It doesn’t stop to check that the exception type we want to catch actually exists.

So, yeah. You need to be careful with PHP namespaces, especially when you add them to a previously un-namespaced project.


From Archos to Amazon

As you probably already know, Amazon’s tablet, the Kindle Fire, was announced a few days ago. Priced at a pretty amazing $199, its purpose is more focused than your general usage tablet like the iPad or the Xoom: it’s specifically designed for consuming content like books, music and video (preferably through Amazon’s own services, of course). Although it will probably be possible to install some other apps (through Amazon’s AppStore) to do some email and chatting and gaming and what have you, it will probably be more limited than on those bigger tablets, and will likely be only advertised as the last bullet point on the list of specs, if at all.

Now you know what else was priced around $200 and was useful mostly for consuming content like books, music and video? Yep. The Archos 70 I got last year for $249 (I got it on a discount, it was normally at $279).

Oh sure, Archos may not have been advertising their product like that. They may have advertised it along the lines of:

The most awesome Android tablet ever! Do everything you want! Web browsing! Videos and music! Email!! Games!!! Video chat!!!! This is so awesome we’re running out of exclamation marks!!!!!

Being a long time Archos user, I’m used to their bullshit and I know how to read through it. It usually translates to:

It’s rubbish at everything, especially anything web-related, but it can read any fucking video format in the universe, doesn’t come with any bullshit iTunes-like sync program, and is so much cheaper than the competition.

And as I stated last time, that was just perfect: I only wanted a good portable media player, and maybe a nicer way to read my Instapaper clips. But, of course, everytime somebody saw my small cheap looking tablet, there was a good chance the discussion would go like this:

  • “What’s that?”
  • “My Archos 70. Android tablet. I use it mainly as a portable media player, though.”
  • “Why didn’t you get an iPad?”
  • “Too big. Not enough codec support. Too expensive.”
  • “Yeah but you can do so much more with it!”
  • “Don’t care.”
  • “Come on! Apple is so awesome! The iPad is so shiny!”
  • “Yeah, whatever.”

Well it looks like Amazon found a lot of people like me out there because the Kindle Fire’s product story is exactly what I was looking for a year ago. Well… apart for that one small detail about data freedom, because I’m not sure exactly how easy it will be to get your own content onto the device, without necessarily going through Amazon (especially since most of their content is not even available outside of the U.S. anyway).

At least I’m very happy to see someone try to move the market into a slightly new direction instead of spitting out confusing all-purpose Android tablets like everyone else.