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.

It had to happen eventually, but PieCrust 1.x is now officially deprecated. It was deprecated more or less unofficially before, as you can see from the lack of activity on the repository, but, well, here it is.

The PieCrust 2 help pages are now showing up by default at the official URL, and that’s where I’ll be focusing from now on.

If you want to upgrade your existing 1.x website to 2.0, you can follow the installation and upgrade instructions. And of course, please contact me if you have issues or feedback!

After the nice one-shot “The Murderer of Thomas Fell”, my new gaming group decided to continue with the 1930s horror genre and we played through roughly a third of the Realm of Shadows campaign for Call of Cthulhu.

It ended with a near-total-party-kill.

You can read the actual-play for “Kith and Kin” (the first chapter) and “Provender of the God” (the second chapter) over in the RPG section.

One thing that I realize now that I’m writing those things up is how often I feel the need to explain why, as a GM, I’m doing this or that – making the bad guys attack here, adding some clues there, etc. Most of the “actual plays” out there only focus on what happened around the players’ side of the table. But I’m finding it more interesting to also include what’s happening behind the GM’s screen.

This is especially interesting because investigative adventures rely a lot on the GM improvising events and moving around clues to keep the story going, as opposed to, say, a dungeon crawl, where most of the design decisions can be done upfront during the preparation phase, and the improvisation is mostly about adjusting enemies to keep combat balanced.

Adding the GM side of the game makes it easier for me to see what I did right and what I did wrong, and may even get me some constructive feedback on some of those decisions. I’ll try to keep adding things like that in the future reports.

This week-end in Vancouver was FanExpo, with the shopping frenzy, celebrity line-ups, cosplay contests, and friendly comic-book sketching that you’ve come to expect from such conventions, albeit at a smaller scale for our relatively young Vancouver edition.

Here’s my artist-commission-focused loot this year:

Nadia (from Kukuburi) by Ramon Perez, Conan by Cary Nord, and Iron Fist by Kaare Andrews. And a nice Thundercats t-shirt because I always need a new t-shirt.

After the jump you can see some cosplay pictures I took, although you can probably see better ones elsewhere on the internet.

You can see the other pictures in my FanExpo 2015 album.

Sarah Baird talks about what us left-handed people have put up with all our lives, and all the way back through history:

Day in and day out, though, the biggest hurdle faced by lefties isn’t discrimination — it’s mundane, basic functioning. Almost all facets of society, from ink pens to urban design, are crafted and structured to support, abet and cater to the right-handed majority. For lefties, functioning means a constant, conscious consideration of how they can reverse or modify their natural behavior in order to most effectively move around in the world.

The funny thing is that most of the time, I’m not even thinking about it. I’ll be, say, getting hot air blowing all over me from holding the vacuum-cleaner “the wrong way”, and not really realize that this wouldn’t happen if I was right-handed. It’s just like living in a world that’s slightly less well-designed.

Generally speaking, I’ve probably encountered less hurdles growing up in France than most North-American lefties: spiral notebooks were not used a lot (we had properly bound notebooks) and student chair/tablet combinations were pretty much inexistent.

The last time I really felt the pain of being part of a market minority was when I was shopping for a new computer mouse. Being a palm gripper, I ideally need a so-called “ergonomic” mouse. But those mice are only ever manufactured for right-handed people. The only left-handed ergonomic mouse that I’ve been able to find is the Razer Death-Adder Left-Handed Edition. Many people dislike Razer for their annoying configuration software but I figured I still needed to vote with my money. And, you know, I needed a mouse.

As expected, the configuration software is annoying, but the mouse is really nice.

I’ve been quite silent for the past few weeks because I’ve been mostly working on the PieCrust 2 documentation website – a lot of time spent writing stuff, trying out different layouts, figuring out how to organize the information, and coding the infrastructure tools that will generate separate documentations for each release.

Now at least I’ve got half of something to show, in case some of you want to provide feeback or – gasp – help! Head over to the PieCrust 2 documentation preview to see it in all its work-in-progress glory!

At this point, it’s only about a third done, so there’s probably another few weeks of work. But it’s interesting how writing documentation forces you to polish a product. This is not new – it’s really a variation of README-driven development – but that’s why it’s taking a long time: a good chunk of the documentation writing time is looking at what I just wrote, thinking that it’s completely stupid, writing what it should be like, and then fixing the code so it does exactly that.

Anyway, back to writing…