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.
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.
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.
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 like1 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 swag2.
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.
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.
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.
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 mine1? 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”2. 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.
Ironically enough, my blogging frequency went down around the time I started writing my own blog system… although that’s slightly misleading, because that’s also around the time I started having kids, and coincidentally figured I should focus more on fewer home projects in order to actually ship them, instead of always leaving them in a half-finished state. ↩︎
There go my chances of having the most popular Python static website generator! ↩︎
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!
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.
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.
