tartley

That's like saying "I don't use wheels, because I don't live in the prehistoric era when they were invented."

Some tools are fundamental. A tool to solve the problem of executing dependant tasks is one of them.

Solutions to these fundamental problems tend to be implemented early on. Some of those early solutions were poor, and have fallen out of use. Some of them were good, and have been refined in the intervening years, and hence are still with us.

A good tool to solve a fundamental problem is still useful, no matter how old it is.

Since they are interoperable, you can write in pyopengl for Punic code, then convert your half dozen opengl calls in your innermost loops into pyglet for performance.

Lots of civilisations have collapsed throughout all of history. Millions of people have starved to death as a result. What makes you think we're somehow immune?

+1 for #3

It's not just in the diffs. Trailing commas make editing the list easier.

I think he invited pull requests containing implementations.

Using script files to store config is convenient, but is it true that in some circumstances it could give malicious parties a chance to inject arbitrary executed code into your environment, in ways that parsing a pure data file could not.

Hey. Out of interest, Jason, would you personally write a functional test that spun up a local SFTP server like I describe? As a developer who's better than average, it presumably wouldn't take you a couple of days to get that working, but even so, would you consider cheating a little and mocking out the sftp client calls? If so, would you still call it a 'functional test'?

Hey. It's a nice idea, but there are problems with this. The actual output varies depending on your hardware & driver combo, and is substantially affected by the state of the graphics drivers (e.g. What types of anti-aliasing or interpolation are enabled? What color profiles are loaded?) The RGB pixel values on one machine will not match those on another machine.

You could imagine writing an 'is image almost equal' comparison, but I'm informed by those who have tried (pyglet developers) that this is substantially harder than it sounds - the differences between images are not what you would expect.

The alternative, if you want anyone else to be able to run your tests, is to tie yourself to a particular OS/hardware/driver combo. Not appealing for many projects.

Even if this could be done, this sort of 'compare snapshot' test is brittle, because, of course, we're talking about high level functional tests here, so you'd be snapshotting your whole game/application, not just limited aspects of it in a limited environment. Hence the screenshots would change all the time. Every time you added or modified any functionality you'd get a failing test and have to manually compare the images and assert that the differences were OK and then commit the new screenshot. This is ripe for overlooking small regressions, and makes subsequent bisection very difficult.

Of course, we haven't even got into the aspect that, as an end-to-end test, your test code would actually have to interpret the images and send mouse/key inputs to successfully play your game. Through to completion, of course - how else would you know your game-completion conditions were all wired up correctly?

An interesting aspect of the "different dimension" is that functional tests actually demonstrate that your application works. If your website is down after deploying a well-functionally-tested application, then it's often because of something beyond your control, like an Amazon outage. Functional tests give you the confidence to deploy often, or automatically, even after bold refactoring, because you can prove that the app works, which unit tests or integration tests cannot do.

I'm a big fan of unit & functional testing. One reason for not writing functional tests though is that they are way harder to write than unit tests (assuming that your unit tests are relatively straightforward because your code is well factored)

I always find starting functional tests, especially in a new area of your program, to be a tremendous exercise. Maybe I'm doing it wrong. For example, last week we moved on to writing code that hits an sftp server - so our functional test spins up an sftp server locally & overrides the product code settings so that it connects to that. Getting this set up and working took me a couple of days, and this is such a tiny aspect of the code under test that I'm afraid I'm exhausting my teammates patience for "test first functional tests".

In other areas e.g. hobbyist opengl code, I think this initial barrier to getting started is so high (you'd have to write a sort of machine vision thing to analyse the actual output, rather than just what opengl calls were made) that truly end-to-end tests are a complete nonstarter. You have to give in and settle for integration tests instead.

I suspect many people are in that same place with regard to functional testing of web apps. Yes there are tools like selenium, but there are issues of test data & making sure product code connects to test databases. There are solveable, but people don't see that the value is greater than the costs of wrestling with that.

http://ontwik.com/python/django-deployment-workshop-by-jacob...

Our intro page does need some love, good call.

>> HTML5 charting or Google Visualisation

This would be great. Maybe we could have a canvas element off on some discreet pane somewhere, direct these rendering libraries at it, and reveal the pane when the canvas gets written to.

>> public datasets readily available to hack on.

Genius. Great idea.

Hey. Thanks for the comment. Yep. Right now the beta only works on regular OS & browsers, and on the Nokia N900, but we still have some work to do on Android, and have yet to test on iOS, but theoretically we have no known incompatible tech.

We hadn't thought about chart drawing, but it seems to make good sense. Thanks!

We're constantly brainstorming about the best ways to import and export source and data. We're currently thinking about Dropbox or Github integration, or maybe a very lightweight client-end component which simply allows you to sync the current directory to your PythonAnywhere server-side storage.

Hey. OP here. This comment is the closest to my actual motivation for producing the post, although me and my co-author that afternoon were not so much angry about it as just 'delirious with laughter'.

Yeah, most are, but the good ones are amazing. As a for instance, I spent years going to large corporate oriented industry conferences, and hating them. Last few years, I've discovered the smaller, community run Python conferences, which have had a transformational effect on myself and my understanding and my career.

That's why something like Lanyrd is great, for helping you find those small events which are full of smart passionate people doing cool things.

Hey ivank. I work at Resolver, and just wanted to say, that's a fair comment. Getting the startup time of Resolver One down has been difficult for us. Our new web-app will fix that for some of our users, and we hope to provide a clear migration from Resolver One to projectdirigible.com for those of our users for whom it makes sense.

Best regards,

Jonathan

It sounds like use in moderation might make it easier to rapidly leap around the conceptual problem space, perhaps reaching apparently unrelated insights. This tallies with the stereotype of being good for creativity.

At higher doses, this would be overshadowed by the negative effects (leaping too far around the problem space, into nonsensical ideas, deleterous effects on memory and motivation.)

I presume an experienced user could differentiate, judge their own reactions and moderate accordingly. I don't believe I could.

I suspect that being a foreigner meant you didn't pick up on a lot of the class-based ambition in London. The city is moribund with it. Every social event reeks of it.

I'm English, but lived in the US for five years, and have returned to England for five years now, in London for the first time.

Another beautiful essay though, thanks for that.