See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.

I work at MindDistrict. Today I will talk about a web service I built with Tornado. It needs to talk to lots of things, without doing much computation itself. It uses Python 3, because it was about time to use it.

Tornado is a Python web framework and asynchronous networking library, originally developed at FriendFeed.

Tornado is IO loop based. Does not work with a WSGI server. It is easy to implement (micro) web services.

What is an IO loop? Old programming technique, from when threads did not exist or were expensive. It does not use threads, only one flow to execute the code. The loop calls you, you do things, when you are done you relinquish control to the loop. Not efficient for computation intensive tasks.

You can use callbacks, but they are ugly. With generators for the IO loop you can replace them. With @tornado.gen.coroutine you decorate a function and let it yield results.

It works with 'future' objects: a result that still needs to be computed. Comparable with promises in Javascript. You can create them yourself:

def some_function():
    future = tornado.concurrent.Future()
    # do stuff
    future.set_result(42)
    return future

Tornado provides an improved version of subprocess.pOpen. Create a future, call the subprocess, when it is done set the return value or an exception.

You cannot use normal threads or file locks. But you can implement a lock mechanism with futures.

Future objects are reusable for caching. 'memoize' type decorators work.

concurrent.futures is part of the standard library in Python 3. With it you can run your heavy computations in a separate process. It works with tornado: create a coroutine and use the Python 3 futures in there. There is a backport for Python 2.7.

Then Python 3. The syntax for generators is much better. Enough support in main packages. It works nice for us in production.

See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.

I am going to talk about modelling. Process modelling and data modelling. My colleague Henk Doornbos will give a more detailed technical talk after this.

Many ICT systems do not work, a lot of projects fail. Dutch government loses about 5 billion euros a year on failed projects. Expected functions are not provided, and offered functionality is not wanted. For example medical patient information systems.

Main cause of failure: the initial design does not match the end-user requirements.

Possible solution: model driven approach (MDA). You can see models as very high level programming constructs. You might think of UML. But let's revisit this.

Wittgenstein: Don't ask for meaning (of data) but of its use.

Our process: start from business process models (our context) and derive data models, mostly automatic.

Validate your models. The only real correctness is end-user correctness. Capture the main requirements from experts. Anyone can write a model, but how do you know it is correct. UML class diagrams are hard to read and write. Instead, we use a structured natural language that is easy to validate by domain experts.

Are the requirements consistent and complete? Go through it in cycles. Do they converge to a stable model? Models are assumptions about how the domain expert would like to do her job. Try to invalidate the model, hunt for false assumptions.

We use business process modeling and notation. Many modeling primitives, of which we have chosen a subset of eight. Process is a collection of pools. Pool has swim lanes for each stakeholder.

Clients learn the notation pretty quickly. We stick as close as possible to the domain expert's language, which may just be Dutch.

High level overview of a process flow:

• You start
• code the input
• process/transform the input
• decode the output
• stop.

Fact-based modeling approach. Get data. We talk about objects and facts. Facts are sentences that are true or false. The European Space Agency uses this approach for their satellites.

Our flavor of that approach is OLE: Object and Logic-based English. Structured natural language. Better suited than graphical models for validation by domain experts. It is very precise and expressive. OLE can be compiled a prototype to pyDatalog for example. From the site: pyDatalog adds the logic programming (think: the prolog language) paradigm to Python's extensive toolbox, in a pythonic way. More about that in the next talk in this room.

An activity may be coded as for example six statements. Activity A is on Date D. Start Event E leads to Statement S. Entity Type T is identified by Number N. Things like that.

We are using this for a contract system. Contracts are built from small initial building blocks. They are combined recursively into a kind of algebra for contracts. That is turned into a pyDatalog program.

The data modeling part is difficult when you are not used to it, but clients can come up with activities themselves and will spot errors in the logic. They may find out that their own process is more difficult than they previously thought. Or they discover that they do it differently than their colleagues.

How good is this when the process later needs to be adapted? We identify which part of the process needs a change. Change the model, compile that part again.

See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.

At RedHat we try to be newbie friendly, because everyone is a newbie in lots of contexts. You specialize in very few fields.

Declarative knowledge: Amsterdam is the capitol of the Netherlands, A is the first letter, etcetera.

Procedural knowledge: how do I get to Groningen, how do I train for a marathon, how do I learn a new language.

So: what versus how.

Example: when you start learning a new programming language, you may want to stick to your trusty editor and version control system instead of switching those at the same time.

I used to dance, had a degree. You do not earn a lot of money that way. I learned languages. Later html, css. I applied, but I usually not even got an interview, because I had a degree in dancing. So I got a degree in computers. I got hired by RedHat.

At RedHat we say "drink from the firehose:" inhale something that is overwhelming. Go with the flow. You have 90 days to pass the exam. It is like a boot camp. It is not about what you do exactly, but how you manage it: do you drown and give up, or do you battle on. So you learn lots of new technologies and after you pass the exam, you apply that knowledge. Not the knowledge about those new technologies, but about how you learned them. You just keep on learning new stuff, and are not afraid of it. No pressure...

For a workshop I setup this Django Girls blog: http://leanderthalblog.herokuapp.com

Challenge: deploy to OpenShift. http://django-leanderthal.rhcloud.com So, it is deployed, but I ran into problems, so you don't really see anything on it. Battling on, challenge still accepted.

Figure out who you are, what you are good at. What programming languages did you learn? How did you do that? Apply that knowledge to new programming languages. Did you learn via tutorials? Readme? Asking others? Reading books, blogs? Just do it and practice, practice, practice? Did it work or not? Apply that knowledge.

On 19 September 2015, there is a Django Girls workshop right here in Groningen. See http://djangogirls.org/groningen/ Free programming workshop for women. We need coaches. Men are welcome too.

On Twitter: rainsdance

On the Trello board there is now a column for teams. Feel free to edit it. And add yourself to a team if you feel lonely and want to join the fun. :-)

Report-outs from yesterday:

• Javascript / RESTful api. First needed is the RESTful api. Afterwards Javascript front-end. Talked about technical challenges for REST, like supporting http verbs in the ZPublisher without defaulting to webdav, Ramon actually has a working prototype for this, too good to be true. Roadmap can be found on https://github.com/plone/plone.restapi/milestones. It will only work for dexterity. How can we make it happen. We can discuss that here and online. Second session was on Javascript front-end. Brainstorming about what each Javascript framework actually does. If you compare things, they should be similar, which they really are not. We do not have to make a future decision now. We currently have patternslib, and mockup on top of that. Patternslib may help you to not have to write Javascript, but you should really learn Javascript anyway if you want to be a web developer. In half a year there will be even more Javascript frameworks, we can decide later. Sorry, there was no pillow fight. We have smart people who can implement a solution. We still have a solid, integrated stack. Outsiders who may want to build on top of Plone will not look deeply into out stack, at how difficult it may be: when is the last time you really dived into the SOLR code? You simply use it, without worrying too much, so we should not worry to much.
• Plone Intranet. Reviewing where we are and how to move forward to ship with a sane architecture. We decided to organize four one-week sprints in the next ten weeks. One online, others in Bristol, Berlin, Arnhem.
• Hackable Plone, Through The Web Plone (TTW). The need for hackability (tinkering with it as power user) was widely supported. Finishing up Mosaic is an important, maybe vital task. Through the web editable .po files, to change jargon. [Look at prototype in collective.storedtranslations, Maurits.] Editable labels per content type, even in the same dexterity behavior; would be really cool, but we have no idea if that is easy or difficult. Repeatable export and import of content and configuration, in the Plone UI please; per add-on exportable config would be great, but might be difficult. Making view, viewlets, theme snippets through the web; make that be seen as a normal supported practice, instead of being frowned upon. Through the web installable add-ons? collective.jbot allows through the web jbot. Some few but loud people are against jbot, but most seem to think it is a fine method for overriding. portal_view_customizations can be tricky, in some cases breaking things simply by customizing it without changes. Being able to do a similar and less breakable thing through the Plone UI would be good. Undo or better versioning of such changes is helpful.
• Branding, positioning. Micro managing has not worked. Various regional and cultural differences that do not work. See Fred's talk of yesterday. We could work towards a common brand view. Get help from community and also from outside. We know someone who uses Plone and does Jungian Archetypes for a living, he was actually here at PLOG last year, so maybe we can ask him to help. plone.com discussions, a bit too much American, enterprise has different connotations. Whatever brand identity we have, does not necessarily influence how individual companies market themselves. Press releases on time can be hard with volunteers, we may explore other ways. Agreement among US companies to hire marketing people. Not a finished discussion. Board and current marketing team will pick this up, and be sure to ask others for their input.