I have shows for my kids that I’d rather they wouldn’t binge watch. For example, a weekly/6 months a year show like Dragon Ball is supposed to evolve with its audience. But if my kid watches 7 or 8 episodes a week because that’s all he ever wants to see when he gets TV privileges, it would take him only a few months before he ends up in front of the teenage power fantasies of the Saiyan Saga.
Say your kids watch stuff on Plex or Kodi or whatever. You can remove all the episodes of the show they’re watching by putting them in some separate folder, out of your HTPC’s reach. Then you use SaturdayMorning to bring the video files, one by one, every week day or every saturday or whatever you want.
With only one new episode ahead of them, you may find that your kids ask for TV slightly less often, diversify their shows, and/or get more excited about a “new” episode being available to watch.
I believe that in recent years, while looking for revenue models that work for electronic games, game designers and publishers have stumbled upon some formulae that work only because they abuse segments of their player population. Games can have addictive properties – and these abusive games are created – intentionally or not – to exploit players who are subject to certain addictive behavior.
It’s a good read, as Garfield tries to formalize what’s OK and not OK in games, with clear guidelines about gameplay aspects that make a game become “skinnerware”, while still allowing some gray areas. Of course, many people were quick to point out that his own game, Magic, falls, at least, in these gray areas. After all, a certain percentage of Magic players are known to spend huge amounts of money to acquire rare cards, and, generally speaking, buying more packs give you better cards which gives you some advantage.
What saves Magic from the skinnerware category, in my opinion, is largely that it’s a physical game, not a video game1, so whatever you buy still has value and can be sold back. The other thing is that its “power-ups for money” mechanism is not quite open-ended. True skinnerware games typically let you buy an endless amount of coins or jewels or energy charges or whatever. Magic, on the other hand, has a limited (although quite big) catalog of cards. Trying to get them all by buying booster packs quickly gets you diminishing returns because of the rarity of many cards, so you would quickly turn to individual purchases at market price. It’s still a shitload of money, but it’s a finite shitload.
I’ve never had even the slightest opportunity to get my own office1 so I frankly have no idea whether a private office would be an improvement – I just don’t know any better.
We do a fair bit of asynchronous communication, however. This is pretty much unavoidable, since, over here on the Frostbite Engine team, we have to deal with customers and co-workers that are spread across a dozen various places on Earth with up to 9 hours of time difference.
In some ways, however, it’s funny that Larson recommends replacing meetings with emails since a lot of my coworkers mainly complain about having to deal with too much email already. Also, the way he describes how a “quick” email conversation can replace a lengthy meeting is misleading since – having turned off all notifications and checking email only a couple times a day to improve productivity – this “quick” 4-message back and forth would actually take 2 days to complete.
In the zone
The part that caught my eye the most is the part about reaching a “flow state” – something that most people call being “in the zone”.
I have almost no problem reaching that state – even in an open floor plan.
Arguably, I’m not important enough to receive enough emails or meeting invites to experience the problems a lot of other people (most of them more senior than me, I assume) complain about, so that must help… but I basically get “in the zone” often enough that, on a regular basis, I finish a task, take off my headphones, and realize that it’s 2pm and that everybody had lunch already.
While most people use the Pomodoro technique to help protect themselves from distractions, I was, for some time, using that technique to help me take a break every now and then… because being “in the zone” for too long would frequently give me painful migraines (at least once a week). Even when I used Pomodoro timers on my phone, I would frequently not notice them going off!
Then again, I’m one of those people that most of you probably hate: the ones who can fall asleep in less than 5 minutes. So I suppose my brain and I really get along well when it’s time to shut off distractions. Yay brain.
Video game companies are almost all using open floor plans, and nothing will change that any time soon. ↩︎
It’s September 2016, and Apple showed once again some pretty cool hardware: dual cameras, clever asymmetrical core design, water resistance, blah blah. I’m not interested since I already have the very recent 6S (I’m not that rich or desperate) but it’s a very nice piece of technology.
The change that will create the most ripples on the rest of the market however is the removal of the headphone jack, I think. Actually, scratch that. The removal in itself is not that important – it’s what they replaced it with that’s important. Yet, 90% of the press gets hung up on the removal.
I think they’re all missing the point.
The matter of the jack port removal is temporary. It’s going to be very annoying for those of us whose audio needs are not limited to “one phone and one pair of headphones”, but it will be temporary. Hopefully.
I don’t imagine Lightning port headpones will take off – as a manufacturer you’d have to be crazy to invest in a proprietary connector for which you need to pay licensing fees, which is something you didn’t have to do before, and which would also prevent you from selling your products to half of your market. Plus, even low-cost manufacturers are already able, to some degree, to produce relatively cheap Bluetooth headphones. So that’s where the market will go, and where Apple wants to go anyway.
The real problem is that in my opinion Apple opened a can of worms with their wireless headphones: they run with a proprietary “secret sauce” layer on top of Bluetooth. Some people are worried about the potential for DRM but I’m mostly wondering if we’ll see some kind of “wireless protocol war” starting in the next couple years.
Right now, Apple’s “secret sauce” is supposed to be backwards compatible with normal Bluetooth devices, but you know how these things go. The proprietary layer will get bigger with each new release – I’m even expecting that you’ll have to download firmware updates for your headphones on a regular basis soon – but all those cool features will create envy. You can bet that someone like Samsung will come up with their half-assed version of another proprietary layer on top of Bluetooth, as a “me too” feature. Maybe there’s going to be a couple of those out there. Some of those implementations may have some kind of DRM, added under pressure from the movie or music industry, in exchange for some short term IP, marketing, or financial boost.
Eventually the Bluetooth SIG will try and draft some new version of Bluetooth that tries to fix all the basic problems that really should have been fixed before anybody decided to remove the jack port… and meanwhile, Apple has a 5+ year lead on wireless technology, keeps growing their accessory licensing revenue, and is laughing at how everybody else is still having trouble pairing headphones correctly. It’s like the dark ages of the W3C all over again, for audio.
So yeah, Apple is really clever here. I’ve got no doubt iPhone users will be buying increasingly more “W1” enabled headphones from approved manufacturers… it’s a smart move. But not a courageous one. Courage would be to open-source their Bluetooth layer. Courage would be to work with the Bluetooth SIG (which they’ve been a member of since last year) to improve wireless audio for everyone.
PieCrust 2.0rc2 was published a couple days ago, and it’s mostly a bug fix and clean-up release, as you might expect. Run your pip install piecrust --pre -U to update, or whatever you do usually. More info after the jump.
Since there are mostly bug fixes in this release, there’s only a few small user-facing change to discuss here.
Are you using the recent new publishing features? You should! Now there’s an SFTP publisher. See the publishers reference for details.
Simplified URL functions
I did some simplification of the way URL routing is handled. The biggest change is that URL functions now don’t need to specify their parameters. Here’s how it works:
In the routes defined for those 2 sources, you can specify a func property which is the name of a function available through the template engine to generate URLs for these routes. In the aforementioned documentation configuration, these functions are docurl and apiurl (so one documentation page can link to another by writing {{docurl('something/else')}} for example).
The parameters to pass to the URL function are the same as the placeholders in the URL itself… so if the route is /blog/%year%/%slug%, you need to pass the year and the slug into the function ({{posturl(2016, 'my-new-post')}}).
By default, PieCrust “slugifies” your taxonomy terms (like tags) using URL encoding, so that something like “étrange” (“strange” in French… not the accented first letter) is transformed into “%C3%A9trange” (which your browser will properly show as “étrange”).
However, you can also tell PieCrust to do different slugification1, with the site/slugify_mode configuration setting. So say you set it to lowercase,transliterate… it will transform your tag names to lowercase and replace accented and non-latin characters with their closest equivalent. In this case, “étrange” gets slugified to “etrange” (without the accent), and “Technology” gets replaced with “technology” (lowercase).
Of course, it means that 2 slightly different tags can resolve to the same slugified tag – for example, “étrange” and “Etrange”. In this case, PieCrust will now warn you that you spelled things differently in some pages, but will combine both – i.e. the page listing for the term “étrange” will also list the posts where you spelled it “Etrange”.
As always, the full list of changes is available on the CHANGELOG.
[…]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:
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 bake1:
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?
I used the Bench tool to generate those reports. ↩︎
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.
