Summaries of the Python meetup in Amsterdam¶

Ethics in IT - Nick Groenen¶

Computer systems are taking over the world. They’re influencing everything. A lot of good has come out of this. But there’s also a downside.

We’re talking (at meetups like this, for instance) mostly about tech, not about the people that build it or the people affected by it. Nick Groenen calls that an ethics problem.

As an example, Uber’s “greyball” that was originally written for a good purpose but that was later used to mislead governments. Same with Volkswagen’s diesel emissions scandal: detecting when there’s an official test and adjusting the motor parameters to seem more environmentally friendly.

How ethical is it to work on something like that?

The above examples are of big companies. But what about working for smaller companies? You have the same ethical challenges there. What are you doing with your logfiles? How much information do you mine about your customers? Do you give customers’ data to your boss when he asks about it even though it isn’t allowed by your privacy policy?

And how do you treat new programmers? Is there budget for training? How do you treat interns? That’s also an ethical question.

A good first step would be to actually acknowledge the problem in our IT industry.

Ethics… we didn’t learn for that. There are some pointers to get you started:

• https://www.ieee.org/about/corporate/governance/p7-8.html

• https://ethics.acm.org

• Talk to other departments in your organisation, like the legal department. Or your local UX designer.

• Try to apply ethics during design and code review.

• Design for evil. Try to abuse what you’re building. It is actually quite a funny exercise!

• Understand the communication and decision-making structure of your company. Who do you have to talk to? Who makes the actual decisions?

We need a better testing framework - Noam Tenne¶

Noam Tenne works at Van Moof, a bicycle company. He made his own testing framework, Nimoy, named after the actor who played Spock.

TDD ought to be a given now. It isn’t always, but it ought to be. Test Driven Development.

What about BDD: Behaviour Driven Development? A test for a feature is written like this:

• SCENARIO some description

• GIVEN some starting point

• WHEN some action

• THEN some expected result

You can do it with the python behave library. It works with one file per scenario with decorators inside them. Which is a bit cumbersome. And not business-people-friendly.

Nimoy goes back to the old way. One test method per feature. The steps (“given”, “when”) are indicated by using the with statement:

from nimoy.specification import Specification

class ExampleSpec(Specification):

    def example_feature(self):
        with setup:
            a = 5
        with when:
            a += 1
        with expect:
            a == 6  # Look! No

It functions like a DSL (domain specific language) this way. It isn’t real regular python code, but it uses python syntax in a specific way. (Note by Reinout: I suspected he was using metaclasses behind the scenes to adjust the way python treats keywords and variables within the Specification classes, but he later mentioned he used the AST (python’s Abstract Syntax Tree module). ast.NoteTransformer and so.).

And DDT? Data Driven Testing? There’s support in nimoy for parametrizing existing data (for instance from a file or database) and to use that in the tests.

Nimoy has some nice syntactic sugar for using mock classes. Easy to specify expected output, for instance.

He’s got a series of blog posts on how/why he created Nimoy.

He showed some internal code examples afterwards. Including Nimoy tests for nimoy itself. Looked nice.