Gruber, about Apple probably removing the jack and maybe shipping wireless earbuds by default with the next iPhone:

[…]not that one port is better than another, but that wireless is better than wired.

It’s not that wireless is better than wired – it’s that Bluetooth (as it’s widely speculated that Apple would still stick to that technology) is a far better alternative than something proprietary like the Lightning port. The complete absence of the “proprietary vs. compatible/open” considerations from the Apple bloggers is not only baffling but incredibly worrying to me. If Apple was to use, say, AirPlay, that would still be a terrible choice.

A transition towards Bluetooth as the replacement to the venerable jack port would be tolerable in the short term, and would maybe (hopefully) drive improvement on how OSes and devices work with it – for instance, the experience of switching your wireless headphones between devices is far from ideal, and that’s a very common scenario for me, almost on a daily basis. But frankly, I’m not looking forward to having to manage yet another battery level, and having headphones become obsolete with wireless protocol updates.

Update: the times reported by the Bench utility are CPU times, i.e. they represent the time spent working by your various CPUs. The “real/wall” time, i.e. the time you effectively have to wait as a user, is usually a third less than that. So the “real” time for my blog went roughly from 7 seconds to 5 seconds.

In a previous blog post about PieCrust performance, I mentioned how static site generators are dependent on the performance of their formatting and templating libraries. One of the most common formatters are Markdown formatters and, by default, PieCrust uses Python Markdown. It’s the easiest one to install and use, but it’s far from the fastest one.

As far as I know, the fastest one that’s still maintained is Hoedown, for which some Python bindings exist. And if you have a recent enough version of PieCrust, there will be support for a Hoedown formatter, as long as you install Hoedown. You can do that by running pip install hoedown.

Once installed, you can make replace Markdown with Hoedown by writing this in your config.yml, or in a config variant:

site:
    default_format: hoedown
    auto_formats:
        md: hoedown

Any extensions you have declared for the Markdown formatter generally also translate directly to Hoedown:

hoedown:
    extensions: [fenced_code, footnotes, smartypants]

The performance increase can be pretty noticeable. For instance, on my ancient MacBook Pro (2.4GHz Core 2 Duo), this blog takes almost 9 seconds to bake¹:

With Hoedown, the time goes down to 7.2 seconds:

Pretty worth it if you ask me! Now most of the time spent baking happens during templating with Jinja2… time to look for a faster alternative?

The “Apple removing the headphone jack plug” story is warming up again.

The 2 best arguments against removing the jack plug in favor of a digital port, in my opinion, have been put forward by Patel and Streza in the previously linked articles:

• Opportunities for audio DRM.
• Necessity to move the DAC and amp into the headphones – which will most probably sound worse than before on average, or raise the price of headphones in general.

I can add one more that I haven’t seen yet:

• A shared connector like Lightning or USB (as opposed to a port dedicated for headphones) means a connector that will change in a few years. Some of us buy expensive headphones that we expect to last for 10 or 20 years – well below the life expectancy of those digital ports.

The interesting thing though is that pro-removal people often make a weird logical leap. For instance, Gruber:

Should the analog headphone jack remain on our devices forever? If you think so, you can stop reading. If not, when?

He does his best to compare the jack plug to floppy disk drives, and how eventually it will all work out and Apple will once again be proven right in their forward thinking awesomeness… but the floppy disk drives weren’t replaced with a proprietary Apple device. They were replaced with USB sticks and downloads, all of which are superior in every way to floppy disks. It’s definitely not the case for the Lightning port – to quote OSNews’ Thom Holwerda: “as far as I can tell, there are only downsides”.

The whole point isn’t whether the jack plug is up for grabs or not – it’s debatable whether it should be right now, but nothing is sacred in technology. The whole point is that the replacement needs to fulfill the basic requirements that we expect from something to use headphones with. The Lightning port fails so many of those requirements (“standard” being probably the most important one) that it’s a really bad and, yes, user-hostile choice.

It’s a great choice for Apple however. It grows their accessories revenue, strengthen their hold on their users, and generally speaking puts them even more in control. It’s such a great idea for Apple that I can actually totally see them doing it. A lot of people will complain, but pretty much everybody will put up with it, as the cost of switching is much higher than the cost of tagging along. And what does it matter if it splits the audio market in two because of the proprietary port? It’s not like Gruber and other Apple bloggers are very sensitive about life outside of the walled garden anyway.

PieCrust 2.0rc1 is now out! The last piece of the puzzle (or should I say the pie?), page generators, is now in place.

You can run pip install piecrust --pre -U to update from PyPi, or grab it from BitBucket or GitHub.

More details after the break.

Page generators

The big new feature in this release are page generators. They’re basically a generalization of the previous taxonomy feature, which used to let you define taxonomies (tags, categories, etc) to classify your pages, and then PieCrust would generate one page for each term that you use (e.g. each tag would get its own page).

But the concept of generating pages based on what’s in the “normal” pages is also useful for other things… for instance, blog archives – assuming you don’t want all your archives to be in one page, like you had to do before. Instead, you could have one page per year, for instance.

That’s exactly what PieCrust 2.0rc1 ships with – a yearly blog archive generator, in addition to the taxonomy system. By default, if you create a pages/_year.md page, it will start creating yearly archive pages based on it.

Page generators benefit from the same kind of parallelism and caching that all other page sources have during a bake, so it should be as fast as before.

For more information on page generators, see the new documentation page.

Miscellaneous

Other improvements in this release include bake performance improvements, fixes with the administration panel (FoodTruck), and various fixes.

For a full list of changes, you can actually see the new fancy online changelog.

These past couple days most of the video games development community was set on fire by some pretty bad article written by some pretty famous guy on some pretty high traffic website. I’m not going to comment on it – other people like Rami Ismail did that very well already. Interestingly enough, it revived the old debate about “passion” and “crunch”, and we’ve seen a fair number of interesting articles about it as a result. This is not one of those articles either.

What this is is just a simple look at what’s going in my team, Frostbite Cinematics, which I think is interesting because Frostbite is in a fairly unique position in the industry, and that translates to a fairly different approach to overtime.

Spoiler alert: there’s pretty much none.

Pretty things

For those who need a refresher, Frostbite is EA’s proprietary game engine. Originally Battlefield’s engine, it now powers a growing number of EA games, including the Bioware franchises, Need for Speed, Mirror’s Edge, or PvZ: Garden Warfare. Where Unity or Unreal have thousands of customers that are external to them, we only have a dozen, but with which we have very close partnerships.

On the cinematics team (around 6 people), we build the tools that let people make, well, cinematics. If you know Unreal, a very simplistic but easy way to look at it is that we’re responsible for something that looks like¹ the Matinee editor.

(we also get to work on gay sex scenes)

Going undercover

One thing that sets us apart (but that other groups inside Frostbite are increasingly adopting) is that we like to be embedded with our customers. We spend months at a time (co-)developing new features, or polishing existing ones, directly in a team’s codebase.

During that time we’re often treated as temporary members of the team: we attend team meetings and stand-ups via Skype, we’re active on their JIRA boards, we break their build, and we get some cool swag².

The one thing we can’t afford however is to do overtime: if we started doing overtime for one team, we’d have to do overtime for all teams. So we just make it clear, and we try to manage our task load accordingly and realistically. While helping ship Dragon Age: Inquisition, I think we must have stayed late only a handful of times.

Of course, that’s quite unique to us. Other groups in Frostbite, especially in Stockholm, had a vastly different (and grueling) experience while shipping Battlefield 4, for instance.

The drive

Most people on the overall “Frostbite Animation & Cinematics” team (around 20 people) are what you’d call “passionate” to some degree. And this quest to hire other “passionate people” is all fine and dandy – of course we want to hire people who will care about what they do here. But the biggest fallacy about it is thinking that the entirety of this passion has to be spent sitting on that one office chair, on that one project.

Furthermore, this “passion” takes a different form when you start looking at core tech teams. Generally, people who care about games want to work on games, period. People who work on core tech care about something slightly different.

They may care about games, but dislike the often “throw-away” nature of AAA game dev, seeking a position where the code you write is longer lived and multi-purpose. They may care about, say, “animation in games” (in our case), and want to make a difference at a deeper level. Or they may not care about games at all, and instead just love a good technical challenge with an end product that’s fun to press F5 for. This means that the end result of a “crunch”, which may be at least appealing to a game team member (because that’s the game they want to make) may not be so appealing to a core tech dev (because it’s often hacky code or crappy UX that will have to be fixed).

Just say no to drugs

So when faced with the possibility of having to do overtime, it’s easier as a Frostbite Cinematics dev to just say no if it feels unnecessary. Sometimes it can still require some guts, like when you have a multi-Oscar winning CTO from Lucasfilm who calls you at 3pm on a Friday to suggest that you stay over the week-end to fix a problem… but it’s possible.

It doesn’t even have to be about “staying late” overtime. For instance, I personally consider eating at one’s desk to be a capital offense. Maybe it’s my French upbringing, coming from a country where 1-hour lunch breaks are the norm. It’s also just incredibly sad. But so many people do it – and probably only a small fraction of them have a good reason to do so (like a lengthy commute to their kid’s school).

I once bumped into one of our junior devs who was heading for his desk with a plate from the cafeteria. He gave me a lame excuse about having bugs to fix or something, when I knew there was absolutely no time-sensitive factor. I gave him a very tongue in cheek speech about perpetuating a culture of overtime and constant pressure because of impostor syndrome-induced fantasies of how an ideal game dev performs. He sighed, smiled, and joined us for lunch.

Once you foster a culture where things can generally wait 30 minutes so you can get a healthy lunch, it gets easier to foster a culture where things can generally wait until tomorrow so you can get a healthy evening.

One more thing

We’re hiring! Hit me via email or twitter if you’re interested.

PieCrust 2.0 beta 5 is now live on PyPi, so you can go ahead and pip install --pre piecrust -U to get it.

The 2 big new features in that release are the last reasons I switched to Python for PieCrust 2 after packaging and multi-core support: better ways to launch and manage sub-processes. This lets me do:

• Publishing support, because baking your site is only the beginning, and you actually need to upload that stuff somewhere.
• “FoodTruck”, an optional administration panel to work on your site(s) the same way you would with a traditional system like WordPress.

More after the break.

Publishing

A lot of static website generators out there already have this concept of “publishing” your website, i.e. not only bake it, but also upload it to some FTP server, rsync it, push it to GitHub pages or an S3 bucket or whatever. Support varies from system to system.

Well now PieCrust at least has the basic infrastructure to support the same kind of feature – something I have been delaying for too long! There’s only support for arbitrary shell commands and rsync, but I’m hoping more publish targets will come soon.

For more information, see the documentation on publishing your website.

FoodTruck

I’ve wanted to do this for a while now, but had to figure out the right way to do it, which is to provide a web administration dashboard that you can use to work on your website.

Now I know what you’re thinking. Isn’t the whole point of static website generators that you keep everything simple as text files, and you use your favorite (and most productive) text editor? Well, of course!

But the reality is that you need an optional adminstration panel for 2 reasons:

• First, you want to attract newbies and non-technical people to the dark side of flat-file CMSes. Making it attractive and usable to them will hopefully be one of the gateways for them to become more technical, and in turn maybe participate in this wonderful melting pot that is the open-source
  web.
• Second, have you seen the average blogging frequency of a static website user? Have you seen mine¹? I believe that it’s a consequence of the price we pay in terms of practicality: to post something new, we have to get to a computer that has our site repo, and some way to bake and upload that to our web server. But it doesn’t have to be that way. You could also have an administration panel running on your server, so that you can also quickly post on the move, from your phone, and it would take care of baking and publishing for you in the background.

As I was writing FoodTruck, a couple static website generators appeared with an administration panel – most famously Lektor, by Python superstar “mitsuhiko”². As far as I can tell, these are mostly geared towards the first reason, i.e. provide a nicer, user-friendly way to edit your website.

Hopefully, they start moving towards the second reason too. That second reason is actually the heart of FoodTruck, although there’s still a lot of work to get there. Consider:

• The administration panel needs to run some heavy process (baking and publishing) from a web page.
• The administration panel needs to be able to submit to your Git/Hg/etc. repository so you can then pull the edits you made on the go once you get back home.
• The administration panel needs to be secure, obviously. And I don’t know shit about web security.

It can do most of that already, but not well enough yet for me to be comfortable with letting you all run this code on a public web server… so stay tuned for the next few releases, and check out the documentation on the administration panel for more info.

This looks like a small update for Wikked but it’s kind of the reason this blog has been so quiet lately…

If you don’t want to hear about it, just know this:

• Wikked 0.6.5 is available on Pypi so just go and pip install wikked -U.
• You can of course grab it directly from Bitbucket or Github, depending on your preferred source control software.
• You can check out the new documentation website.

If you want the full story, keep reading.

Back to the 90’s

I originally wrote Wikked as a single page app because, well, I wanted to have a little fun and learn something new. And it worked (I did have fun learning Javascript past the “copy JQuery snippets from the internet” phase), but it didn’t really work (it made testing and deploying unnecessarily harder). It could have also been argued that making this an SPA was overkill… at least, it did bother me a bit, since I tend to prefer simpler/old-school technologies.

Anyway, I embarked on a giant refactor of the code base to reimplement the front-end using a more classic architecture, and the last couple versions of Wikked are the result of this transition. You shouldn’t see anything new, besides a few less old bugs, a few new bugs, and an overall more stable
experience.

New documentation

In the process, I also got rid of the old documentation page I had on BOLT80, and made a proper versioned documentation website, just like with PieCrust. That website is part of the Wikked codebase so you can easily send patches for it… and of course, it’s made with PieCrust.

You can check it out at the same place as before on BOLT80. It’s still a work in progress design-wise – it’s meant to look similar to a Wikked-powered wiki, but it still lacks a bit of graphics and other stuff to make it look less sterile.

Next steps

As always after I spend a few months doing some giant task with the limited free time that I have, I need to get back to my other projects and reply to the various bug reports and pull requests I haven’t replied to in weeks. Then it’s back to business as usual, I hope… at least unless I get into another big refactor.

Since I reached an acceptable milestone with PieCrust performance recently, I had some free time again to catch up with some of my other projects. The first one to get some love is Gutentags, my tag-management Vim plugin, which was sitting there with a bunch of pull requests and bug reports.

The newest version of Gutentags includes better support for project-specific settings via the .gutctags file, some progress on supporting Cscope (not quite finished yet), and various bug fixes, all from a few generous (and patient) contributors.

Grab it from Bitbucket or Github, depending on your preferred source-control poison.

PieCrust news – and this blog – have been pretty quiet for the past couple months, and that’s because I’ve been busy working on PieCrust 2 performance.

TL;DR: PieCrust 2 now runs in multiple cores, which speeds up the baking process quite a bit. Update your repositories, or grab the latest version from Pypi!

More details after the break.

While I was working on the documentation for PieCrust 2, I decided I might as well do something proper, like support for translations and versioning. The documentation is now in the same repository as the code, and it’s easy to bake the documentation pages for each release.

To do this, I needed a simple tool that could do the basic work of cloning a repository, syncing back to given points in times, and do something. In theory, this would be a simple bash script or something, but I also wanted it to do nothing if it already did something for that same specific point in time.

Thus September was born (if you don’t get the reference, even with the picture above, I can’t help you).

It’s a simple Python script that still packs some goodness to it. It basically lets you roll your own readthedocs kinda website (in a very basic way of course), with appropriate hooks to your repositories.

You run it from inside your repository (Mercurial or Git at the moment) and it will sync back to each tagged changeset and run a command of your choice. You can specify a bunch of stuff in a configuration file, like the command itself (which supports interpolation with a few useful values), the oldest tag to start from (in case you don’t want to go all the way back to the first release), and a couple of other things. It will work out of a temporary directory in which it clones your repository, and stores a cache file that describes what it’s doing. If you keep that temporary directory around, it won’t re-do the work it previously did (so it will only rebake my documentation pages if I moved a tag or added some new ones, and it will re-use and update the repository clone).

It’s still all new and a bit squeaky, so make sure to file some bug reports if you see anything wrong. Oh, and it’s on Github too for you Git kids.