Planet Plone

This is where developers and integrators write about Plone, and is your best source for news and developments from the community.

June 15, 2016

Chris McDonough: I'm Gonna Regret This

by chrism at 2016-06-15T06:11:10Z

A plea for liberals to fight for individual rights.

June 10, 2016

Wildcard Corp: Wildcard to Present on Cybersecurity at PSU Web Conference


What's Happening?

Nathan Van Gheem, Wildcard Corp.'s Director of Solutions Engineering, will be presenting at Elements: the Web Conference at Penn State. The session entitled "Do You Lose Sleep at Night?" will cover the vitally important security practices put in place by Wildcard for its biggest government clients. 

These security measures protect web applications from common attacks that afflict thousands of web sites daily, often leading to embarrassment at best and multimillion dollar data breaches at worst.

Other practices covered will include sometimes surprisingly simple ways to improve the performance, stability, and user satisfaction of web systems.

Nathan's additional roles include being the Security Team leader for Plone (, the enterprise-ready open source content management system.

If you're at the Web Conference, come to Nathan's session and bring your toughest security questions!

If you can't make it but are still interested, we will be posting slides afterwards. Keep on the lookout for those.



When: Monday, June 13, 2016, 11:45 am - 12:30 pm

Where: Penn Stater Conference Center and Hotel, 215 Innovation Boulevard, State College, PA 16803


Wildcard Corp. is the premier enterprise web systems provider for major US federal government departments. It is with pride that we developed and manage one of the most traffic-heavy websites in the world with 100% uptime and no security breaches ever.



June 07, 2016

Martijn Faassen: Impressions of React Europe 2016

by Martijn Faassen at 2016-06-07T09:34:10Z

Last week I went to the React Europe conference 2016 in Paris. It was a lot of fun and inspirational as well. I actually hadn't used React for about 6 months because I've been focusing on server-side stuff, in particular Morepath, but this really makes me want to go and work with it again (I'm available). I especially enjoy the creativity in the community.

In this post I want to give my impression of the conference, and highlight some talks that stood out to me. There are actually too many to highlight here: I thought the talk quality of this conference was very high. I also appreciated the wide range of topics -- not everything was about React directly. More of that, please!


I was quite worried about travel this year. I'm in the Netherlands, so it all should be so easy: hop in a train to go to Rotterdam, a 45 minute ride. Then take the Thalys that speeds from Rotterdam to Paris in about 3 hours. In total it takes about 4 hours. Awesome.

But it's strike season in France. Railway strikes were threatened. And then there was a railway strike in Belgium, through which the train passes, on the day I was to travel. Uh oh. I already got some warnings in the days in advance about possible train cancellations due to the strikes. But my train was still going.

But travel in the Netherlands at least wasn't disrupted, so I wasn't worried about that. I made it in time to the normal intercity train that brings me from my home town, Tilburg, to Rotterdam. Found a comfortable seat. All ready to go. Then an announcement: please leave the train as it can go no further. A cargo train had broken down ahead of us. Argh!

In the end I managed to get to Rotterdam and catch a later Thalys, and made it to Paris, just 2 hours later than I'd planned.

I was also worried about announced strikes in the Paris metro system on the day of the conference. Getting around in Paris is very convenient with the metro, but not if it isn't going. In the end the metro wasn't affected.

What I did not anticipate was the whole flood situation, to the point where they had to move parts of the inventory of the Louvre. But Paris is a big city and the floods did not affect me.

So in the end what I worried about never happened and stuff happened that I didn't worry about at all.

Hackathon and MobX

Like last year there was a hackathon one day ahead of the conference at the Mozilla offices in Paris.

Last year's hackathon was special: I met up with Lee Bannard and we worked on reselect, which became quite a popular little library for use with Redux. You might enjoy my story on that.

I was very happy to see Lee again at this year's hackathon. We didn't create any new code this time; we spent most of our time learning about MobX, which I first heard about that day. We met Devin Pastoor at the hackathon. He already had a little app that used MobX that he wanted to work on together. Lee and myself helped a little with it but then got distracted trying to figure out how MobX's magic works.

MobX is a state management library, typically used with React, that takes a different approach than the now dominant library for this, Redux. Mobx lets you use normal OOP style objects with state and references in your client-side model. Unlike Redux is does not require you to normalize your state. MobX observes changes to your objects automatically and is very clever about only updating the parts of the UI that are affected.

This gives MobX different tradeoffs than Redux. I haven't used MobX in practice at all, but I would say MobX is less verbose than Redux, and you get more performance out of the box automatically. I also think it would be easier for newcomers to adopt. On the other hand Redux's focus on the immutable state constraint simplifies testing and debugging, and opened up a rich ecosystem of extensions. Redux's implementation is also a lot simpler. People want a simple answer to "what is better", but these really are tradeoffs: which way is the right way for you and applications depends on who you are and what you are working on.

Sorry folks, Lee and I created no thing new this time. But we had fun.

Dan Abramov: The Redux Journey

Dan Abramov, one of my open source heroes, gave a very interesting talk where he talked about the quick and wild ride Redux has been on since last year. Redux was indeed everywhere at this conference, and people were building very cool stuff on top of it.

Dan explained how the constraints of the Redux architecture, such as reducers on immutable state, also lead to its stand-out features, such as simple debugging and persisting and sharing state. He also spoke about how Redux's well-defined minimal contracts help its extension and middleware ecosystem.

Dan's talk is interesting to anyone who is interested in framework design, even if you don't care about React or Redux at all.

Watch "The Redux Journey"

Eric Vicenti: Native Navigation for Every Platform

This talk was about using a Redux-style approach to manage navigation state in mobile apps, so that the app can react appropriately to going "back", and helps with links within the app as well as it responding to links from other apps. Web folks have deep experience with links and is an example of how bringing web technology to mobile app development can also help make mobile app development easier.

Watch "Native Navigation for Every Platform"

Lin Clark: A cartoon guide to performance in React

Lin Clark gave a great talk where she explained why React can be fast, and how you can exploit its features to help it along. Explaining complex topics well to make them seem simple is hard, and so I appreciated how well she accomplished it.

If you are new to React this is a really good talk to watch!

Watch "A cartoon guide to performance in React"

Christopher Chedeau: Being Successful at Open Source

Christopher described what strategies Facebook uses when they open source stuff. I especially liked the question they made sure to ask: "What did you struggle with?". Not "what do you want?" as that can easily devolve into a wishlist discussion, but specifically asking about problems that newcomers had. One fun anecdote: the way to make a FAQ go away was not writing more documentation but changing an error message.

I also liked the clever "fake it until you make it" approach to making a community appear more active than it is in the early stages, so that it actually becomes active. One trick they used is to ask people to blog about React, then publish all those links on a regular basis.

As an individual developer who occasionally open sources stuff I must point out rule 0 for open source success is "be a huge company with lots of resources like Facebook". Without those resources it is a much bigger struggle to build an open source community. (It also doesn't help that with Morepath I picked a saturated space: Python web frameworks. It's hard to convince people it's innovative. But that was the same problem React faced when it was first released.) (UPDATE: of course Facebook-level resources are not required for open source success, there are a lot of counter examples, but it sure helps. The talk mentions a team of multiple people engaging the community through multiple routes. A single individual can't replicate that at the start.)

Nevertheless, open source success for React was by no means guaranteed, and React helped make Facebook's reputation among developers. They made the React open source community really work. Kudos.

Watch "Being Successful at Open Source"

Dan Schafer: GraphQL at Facebook

I liked Dan Schafer's talk: a nice quick recap of why GraphQL is the way it is, some clear advice on how to deal with authorization in GraphQL, then a nice discussion on how to implement efficient queries with GraphQL, and why GraphQL cache keys are the way they are. Clear, focused and pragmatic, while still going into to the why of things, and without overwhelming detail.

Watch "GraphQL at Facebook"

Jeff Morrison: A Deepdive into Flow

This talk was about the implementation of Flow, which is a type checker for JavaScript code. This is a very complex topic involving compiler technology and type inferencing, and was still amazingly clear. The talk gave me the nice illusion I actually understand how Flows works. It also makes me want to try Flow again and integrate it into my development tool chain.

Flow is a general JavaScript tool. It comes out of Facebook but is not directly connected to React at all, even more so than something like GraphQL. I really appreciated that the organizers included talks like this and mixed things up.

Watch "A Deepdive into Flow"

Cheng Lou: On the Spectrum of Abstraction

This talk, which isn't about React, really stood out for me, and from what I heard also resonated with others at the conference. It tied neatly into the themes Dan Abramov already set up in his opening talk about Redux. Dan told me later this was not actually coordinated. The ideas are just in the air, and this speaks for the thoughtfulness of the React community.

Cheng Lou's talk was a very high level talk about the benefits and the costs of abstraction. This is something I care about a lot as a developer: how do I avoid over-engineering and under-engineering (I've written about it before), and solve problems at the right level? Software has many forces on many levels pulling at it, from end-users to low-level details, and how do you balance out these forces? Engineering is so much about dealing with tradeoffs. How do you even communicate about this?

The next day I had an interesting chat with Cheng Lou about his talk, where he discussed various things he had to cut out of his talk so it wouldn't be too long. He also mentioned Up and Down the Ladder of Abstraction by Bret Victor, so that is now on my reading list.

I highly recommend this talk for anyone interested in these topics.

Watch "On the Spectrum of Abstraction"

Preethi Kasireddy: Going from 0 to full-time software engineer in 6 months

This was a 5 minute lightning talk with a personal story: how overwhelming software development is to a newcomer and how it can nonetheless be learned. During the talk I was sitting next to someone who was relatively new to software development himself and I could see how much this talk resonated with him.

Preethi Kasireddy also encouraged more experienced developers to mentor newcomers. I've found myself that mentoring doesn't have to take a lot of time and can still be hugely appreciated. It's fun to do as well.

A new developer is often insecure as there are just so many things to grasp, and experienced developers seem to know so much. Ironically I sometimes feel insecure as an older, more experienced developer as well, when I see people like Preethi learn software development as quickly as they do. I certainly took more time to get where they are.

But I'm old enough to have gotten used to intimidatingly smart younger people too. I can keep up. The Internet overall helps with learning: the resources on the Internet for a new developer may be overwhelming, but they are also of tremendous value. Preethi called for more intermediate-level resources. I am not sure this series I wrote counts; I suspect Preethi is beyond it, but perhaps others will enjoy it.

(Video not up yet! I'll update this post when it is.)

Jonas Gebhardt: Evolving the Visual Programming Environment with React

This was another one of those non-React talks I really appreciated. It is related to React as it is both inspired by functional programming patterns and component-based design, but it's really about something else: a UI to construct programs by connecting boxes with arrows.

There are many of these around. Because these don't seem to ever enter the daily life of a programmer, I tend to be skeptical about them.

But Jonas Gebhardt acknowledged the prior art, and the approach he described is pragmatic. An open world approach in the web browser, unlike many of the "we are the world" sandbox implementations from the past. Annotated React components can serve as the building blocks. He even sketched out an idea on how to connect UI input and output to custom user interfaces in the end.

So I came away less skeptical. This approach has potential and I'd like to see more.

Watch "Evolving the Visual Programming Environment with React"

Bonnie Eisenman: React Native Retrospective

I really like retrospectives. This was an excellent talk about the history of React Native over the course of the last year and a half. React Native is the technology that lets you use JavaScript and React to develop native iPhone and Android apps. Bonnie Eisenman also wrote a book about it.

React Native is a potential game changer to me as it lets people like me use our deep web development experience to build phone apps. The talk made me excited to go and play with React Native, and I'm sure I wasn't the only one. In a chat afterwards, Bonnie confirmed that was a goal of her talk, so mission accomplished!

Watch "React Native Retrospective"

Phil Holden: subdivide and redux-swarmlog

Phil Holden gave a 5 minute lightning talk, but please give him more space next time. He discussed Subdivide, an advanced split pane layout system for React, and then also discussed another mind-blowing topic: using WebRTC to create a peer to peer network between multiple Redux frontends, so that they share actions. This lets users share data without a server being around. This he packaged as a library in a package called redux-swarmlog.

I've been thinking about peer to peer serverless web applications for some years as I believe they have the potential to change the web, and Phil's talk really reignited that interest. Peer to peer is hard, but the technology is improving. Later that day, I had the pleasure of having a brief chat with Phil about such wild topics. Thanks Phil for the inspiration!

(Video not up yet! I'll update this post when it is.)

Andrew Clark: Recomposing your React application

Andrew Clark is Internet-famous to me, as he created Flummox, the Flux state management framework I used before switching to Redux (Andrew in fact co-created Redux). In this talk he discusses recompose, a library he wrote that helps you do sophisticated things with pure, stateless function components in React. I need to play with it and see whether it fits in my React toolbox. Andrew also described the interesting techniques recompose uses to help reduce the overhead of small composed functions -- this highlights the properties you gain when you stick to the pure function constraint.

Watch "Recomposing your React application"

Jafar Husain: Falcor: One Model Everywhere

When multiple development teams have a similar idea at about the same time, that may be a sign the idea is a good one. This happened to me when I came up with a client-side web framework few years ago, thought I was onto something new, and then Backbone emerged, followed by many others.

Jafar Husain in this well-done talk described how Falcor and GraphQL were a similar solution to similar problems. Both Falcor and GraphQL let the client be in control of what data it demands from the server. He then highlighted the differences between Falcor and GraphQL, where he contrasted Falcor's more lightweight approach to GraphQL's more powerful but involved focus on schemas. It's tradeoffs again: which fits best depends on your use cases and team.

Watch "Falcor: One Model Everywhere"

Laney Kuenzel & Lee Byron: GraphQL Future

This was a wide-ranging talk that went into various issues that GraphQL team at Facebook is trying to solve, mostly centered about the need to receive some form of immediate update when state on the server changes. Laney and Lee presented various solutions in a various states of readiness, from mostly untested ideas to stuff that is already deployed in production at Facebook. Very interesting in you're interested in GraphQL at all, and also if you're interested in how smart people tackle problems.

Watch "GraphQL Future

Constructive feedback

In my blog post last year I was clear I enjoyed the conference a lot, but also engaged in a little bit of constructive criticism. I don't presume that the React Europe organizers directly responded to my feedback, but let's see how they did anyway and give a bit more feedback here. My intent with this feedback is to do my bit to make a great conference even better.


Last year the conference was in early July in Paris and it was 40 degrees Celsius. The React Europe team responded by shifting conference a month earlier. It was not too hot: problem solved.


Last year the hackathon assumed people were going to compete in a contest by default instead of cooperate on cool projects. This year they were very clear that cooperation on cool projects was encouraged. Awesome!

Still, I found myself walking around Paris with a friend on Friday night trying to find a quiet place so we could look at some code together. We enjoyed the conversation but we didn't find such a place in the end.

This is why I prefer the approach Python conferences take: a 1-3 day optional sprint for people to participate in after the conference has ended. Why I like afterwards better:

  • You can get involved in cool projects you learned about during the conference.
  • You can get to know people you met during the conference better.
  • Since there is no pressure it's a good way to wind down. Speakers can participate without stressing out about a talk they will be giving soon.

Facebook speakers

Many of the speakers at this conference work for Facebook. They gave excellent talks: thank you. I understand that having a lot of speakers from Facebook is natural for a conference on React, as that's where it originated. (and Facebook hires people from the community). But this is an open source community. While I realize you'd take on more unknown quantities and it would be more difficult to keep up the quality of the talks, I would personally enjoy hearing a few more voices not from Facebook next year.

Gender diversity

Last year I spoke about a bit gender diversity at the conference. This year there were more female speakers than last year (keep it up!), but male voices were still the vast majority. Women speakers are important in helping women participants feel more welcome in our conferences and our community. We can still do a lot better: let's learn from PyCon US.

Back home

The train ride back home on Saturday morning was as it should: uneventful. Left the hotel around 9 am the morning, was back home around 2:30 pm. I came home tired but inspired, as it should be after a good conference. Thanks so much to the organizers and speakers for the experience! I hope you have enjoyed my little contribution.

June 06, 2016

Vikas Parashar: Plone theme development- part 2

by Vikas Parashar at 2016-06-06T13:41:30Z

Google Summer of Code 2016— Two weeks into coding period.

eGenix: eGenix PyRun - One file Python Runtime 2.2.1 GA



eGenix PyRun is our open source, one file, no installation version of Python, making the distribution of a Python interpreter to run based scripts and applications to Unix based systems as simple as copying a single file.

eGenix PyRun's executable only needs 11MB for Python 2 and 13MB for Python 3, but still supports most Python application and scripts - and it can be compressed to just 3-4MB using upx, if needed.

Compared to a regular Python installation of typically 100MB on disk, eGenix PyRun is ideal for applications and scripts that need to be distributed to several target machines, client installations or customers.

It makes "installing" Python on a Unix based system as simple as copying a single file.

eGenix has been using eGenix PyRun internally in the mxODBC Connect Server product since 2008 with great success and decided to make it available as a stand-alone open-source product.

We provide both the source archive to build your own eGenix PyRun, as well as pre-compiled binaries for Linux, FreeBSD and Mac OS X, as 32- and 64-bit versions. The binaries can be downloaded manually, or you can let our automatic install script install-pyrun take care of the installation: ./install-pyrun dir and you're done.

Please see the product page for more details:

    >>> eGenix PyRun - One file Python Runtime


This minor level release of eGenix PyRun comes with the following enhancements:

Enhancements / Changes

  • Fixed support for -u command line option with Python 3. Since this is used by pip since version 8.0, it also removes issues with pip.
  • Removed ensurepip package from PyRun since this only works with access to the bundled whl files. This is incompatible with the frozen nature of packages in PyRun.
  • Added support for setting the OpenSSL path to the Makefile and have it look in /usr/local/ssl before reverting to system dirs to make it easier to link against more recent builds of OpenSSL.
  • Linking against OpenSSL 1.0.2 now on Mac OS X for the precompiled pyrun binaries. You may have to set your shared linker path to point to the right OpenSSL version.

install-pyrun Enhancements

For a complete list of changes, please see the eGenix PyRun Changelog.


Please visit the eGenix PyRun product page for downloads, instructions on installation and documentation of the product.


Commercial support for this product is available directly from

Please see the support section of our website for details.

More Information

For more information on eGenix PyRun, licensing and download instructions, please write to

Enjoy !

Marc-Andre Lemburg,

June 01, 2016

Gil Forcada: python 3 support one (of the many) step closer

by gforcada at 2016-06-01T21:35:51Z

During the Barcelona sprint (report from Paul and Ramon) there was quite some work to bring dexterity related packages to work both in python 2.7 and python 3.5.

That work is mostly still pending to be merged, because we had a blocker: our current CI infrastructure (namely jenkins master and its nodes) run on a version of Ubuntu1 that does not provide python 3.5 by default.

So it would be a bit irresponsible to merge those changes without a way to ensure that the effort that was put during that sprint is not long forgotten and had to be done again from scratch some months later.

As reports about the newer Ubuntu version regarding python and plone are not that encouraging, and also due to other reasons, I decided to take the longest but long-term best approach: enters gforcada.compile-python!

An ansible role

So I decided to create an ansible role, given that our jenkins CI setup is already using some, and Plone community is also favoring it, to install all the system dependencies to compile Python 2.6, 2.7 and 3.5.

As extras I added:

  • install virtualenv on python 2.6 and 2.7 (on python 3.5 is already available)
  • install system dependencies for Pillow and lxml

See its README for all the details and more.

With that and vagrant I was able to test that a buildout.coredev (branch 5.1) runs all its tests without a problem :-)

I was tempted to add pypy as well, but I was too lazy/busy for that, if anyone feels like it, pull requests are always welcome!

I hope you find it useful and happy hacking!

  1. 14.04 for the curious

Makina Corpus: The world's simplest Python template engine


A template engine is a component able to render some data using a given string template.

We use it extensively in web development (that's not surprising because web development is mainly about reading some data and render them as strings, that's what I say when someone ask me about my job).

So there are already a lot of Python based template engines (Jinja2, Mako, Chameleon, ...).

The purpose of this article is to build a very basic template engine based only on the Python standard string class formatting capacities.

You probably know...

You probably know .format() replaces the old "%" based formatting solution:

>>> "My name is %s and I am %d" % ("Eric", 41)
'My name is Eric and I am 41'
>>> "My name is {name} and I am {age}".format(name="Eric", age=41)
'My name is Eric and I am 41'

It allows to perform all the typical formatting features, for instance:

>>> '{:^20}'.format('centered')
' centered '
>>> '{:^20}'.format('align right')
' align right '
>>> '{:>20}'.format('align right')
' align right'
>>> '{:<20}'.format('align left')
'align left '

and many other things (have a look to

Did you know?

format() is also able to access attributes or items of the parameters.

For instance with a dictionary, we can do this:

>>> 'Name: {person[name]}, age: {person[age]}'.format(person={'name': 'Eric', 'age': 41})
'Name: Eric, age: 41'

And the same goes with attributes:

>>> class Song(object):
... title = 'Where is my mind'
>>> 'My favorite song is: {song.title}'.format(song=Song())
'My favorite song is: Where is my mind'

That's really cool. It starts looking like a template engine, right?

Ok, but few things are missing

What we usually expect from a template engine is to be able to:

  • call methods,
  • make loops over iterables,
  • manage condition.

Let's see how we can handle that.

Calling methods

A method is an attribute of an object, we can call attribute, why couldn't wecall a method? Let's try:

>>> 'My name is {name.upper}'.format(name='eric')
'My name is <built-in method upper of str object at 0x7f67dc8d1630>'

Yeah, not exactly what we expected...

An interesting feature of format() is the format specification: instead of just inserting a field with {field}, we can specify a format like this: {field:spec}.

That's exactly what we do with float for instance:

>>> "{:.3}".format(3.14159)

Well, it is actually very easy to implement our own spec by derivating the Formatter class. So let's implement a ':call' spec in charge of calling the current field:

class SuperFormatter(string.Formatter):
    def format_field(self, value, spec):
        if spec == 'call':
            return value()
            return super(SuperFormatter, self).format_field(value, spec)

We can use it that way:

>>> sf.format('My name is {name.upper:call}', name="eric")
'My name is ERIC'



Similarly, we can implement a :repeat spec,

class SuperFormatter(string.Formatter):
    def format_field(self, value, spec):
        if spec.startswith('repeat'):
            template = spec.partition(':')[-1]
            if type(value) is dict:
                value = value.items()
            return ''.join([template.format(item=item) for item in value])
            return super(SuperFormatter, self).format_field(value, spec)

Here, we pass a parameter to the spec to provide the template to use when we iterate on the loop items. So the resulting format is: <field>:repeat:<template>.

This subtemplate is a regular format() template where we escape the curly brackets by doubling them, and where the only field is the loop variable (named item).

So we can use it like this:

>>> sf.format('''Table of contents:
... {chapters:repeat:Chapter {{item}}
... }''', chapters=["I", "II", "III", "IV"])
'''Table of contents:
Chapter I
Chapter II
Chapter III
Chapter IV


Let's also implement a :if spec to test the field value, and then display or not the subtemplate:

class SuperFormatter(string.Formatter):
    def format_field(self, value, spec):
        if spec.startswith('if'):
            return (value and spec.partition(':')[-1]) or ''
            return super(SuperFormatter, self).format_field(value, spec)

At first, it seems stupid, because it looks like it will only be able to conditionnally display static portions, like this:

>>> sf.format('Action: Back / Logout {manager:if:/ Delete}', manager=False)
'Action: Back / Logout '
>>> sf.format('Action: Back / Logout {manager:if:/ Delete}', manager=True)
'Action: Back / Logout / Delete'

What if we want to render conditionnally a portion of template containing fields, like this:

>>> sf.format('Action: Back / Logout {manager:if:/ Delete {id}}', manager=False, id=34)
'Action: Back / Logout '
>>> sf.format('Action: Back / Logout {manager:if:/ Delete {id}}', manager=True, id=34)
'Action: Back / Logout / Delete 34'

Hey that works! That was unexpected. To be honest, I first wrote the test exactly like this, and I expected it to fail, but it was not! Why is that?

Because here the curly brackets are not escaped, so they are processed by the main format() call. So cool!

Here we go

That's it, we have a pretty nice and complete template engine.

The full code of our world's simplest Python template engine is here, the implementation itself is 10 lines long, Python is a really powerful language!

If you have any funny idea to improve it (remember, I want to keep it short), pull requests are welcome.

The objective is mostly to have fun with Python and demonstrate what the standard Formatter class is able to do, but, having a second though, I might intregate it in Rapido :).

May 31, 2016

Wildcard Corp: Beer at Work: the Wildcard Tradition


Part of what we pride ourselves on as Wildcard Corp. is being able to work highly collaboratively as a team of experts at all rungs of the corporate ladder, even though many of us work remotely from across the country every day. Being able to do this successfully certainly isn’t easy, and in fact it’s often a struggle. One of the ways we try to overcome this struggle is to bring everyone together once a month for a special event where we can all work in the same room. Everyone at Wildcard knows this day as Krausening.


Where Does the Name Come From?

Krausening (or Kräusening if we’re being particular) is a process of secondary fermentation in brewing that creates carbonation and rounds off the beer’s flavoring. The term comes from “Krause” and “kräuseln,” the German words for “ruffle” and “to ruffle.” Supposedly, the word krausening was originally used as creative language, because the foamy head of the beer resembled the frilly lace ruffles on the clothing of the time. We never looked into the details too much, but that certainly is a good story.

As you may know, Wildcard Corp. is a major contributor to the Plone content management system community. The Plone community is international, including many beer-centric European countries. It’s well-established that part of the Plone community's culture is the enjoyment of beer, and we have adopted the tradition as part of our own company culture as well. In truth, it’s pretty easy to get away with that being a Wisconsin-based company and all. We have even brewed and bottled our own Wildcard beer.

The word Krausening means something a little different to us though. For us it simply means a gathering. For programming, brainstorming, having fun, and drinking beer (responsibly). It’s a time for our company culture to really shine through and for us to really grow as a team.


Wildcard Growler Label:


Initial Sketch of Wildcard Beer Label:


Final Beer Label Design:

* Wildcard beer labels and T-shirt designed in-house by Graphic Designer Beth Jolin. Beer brewed by Business Development Manager Craig Haydock. Both are individuals of many talents.


What Happens at a Krausening?

Ordinarily, we save huge projects for Krausenings that could really benefit from having all of us in one room banging our heads together. Once, for example, we made really drastic changes to our website, updating the content on almost every page. We sat around our conference table, squished like sardines, talking about what we could do to improve the content. Even those of us who work across the country and weren’t able to fly to headquarters were set up in a teleconference with us all day. We ended the day with three new heading tabs on our website, and several pages of new content.

Another Krausening was devoted to developing our marketing plans. Shortly before this particular gathering, we added a number of new employees to the staff, so if we had felt like sardines before, this was entirely something else. We had to improvise an additional conference table out of a sheet of raw plywood and sawhorses. There were so many people in our conference room that day, I almost expected it to burst, sending a bunch of website nerds floating down the street in a shallow river of beer froth. But it didn’t, and we got a lot of good work done.

Toward the end of our Krausening events, we go out for drinks as a company, largely to unwind and also to provide a last burst of creativity before we are all burned out for the night. I like to say, “Creativity brews good beer, and good beer brews creativity.”


What’s Next for Krausening?

Just this last week, we did a company golf outing as a Krausening. It was different from past events in that we weren't all sitting in front of computer screens all day. Instead we mainly tried to relax and have fun, but it was also used to brainstorm ideas for an upcoming software release to be announced later this year. So stay tuned for more information on that.

Since the company is growing so quickly, we expect most of our future Krausenings to be like this one. It's just getting too hard to fit everyone in one room. We have been talking about doing Krausenings by department, or instead of working on a single project as a group, we might do something like TED talks targeted at our new hires to show everyone how to use the software that we sell. You’ll hear more details when we actually decide what we want to do.

Until then, drink responsibly. Keep following us on our blog, on Twitter, and on Facebook. And as always, for all of your technology needs, look no further than Wildcard Corp.



May 29, 2016

Vikas Parashar: Plone theme development- part 1

by Vikas Parashar at 2016-05-29T17:41:15Z

Google Summer of Code 2016 — One week into coding period.

T. Kim Nguyen: ansible-playbook error "sudo: no tty present"


"sudo: no tty present and no askpass program specified"

May 27, 2016

Ramon Navarro Bosch: What are we doing in PloneNG - Barcelona Sprint 2016

by Ramon Navarro Bosch at 2016-05-27T16:04:58Z

One week later I could get some time to write down what we did and which ideas are behind the Barcelona Sprint 2016...

It all started two months ago when we where thinking about how we could organize Barcelona Sprint to be productive. We've already decided to create three teams, REST API, experimental new backend and frontend so we needed to see how a week sprint can be organized to reach some goals. At that moment I contacted Asko, Timo and Nathan to ask if they can lead each team and prepare a pre-sprint discussion (so we did not need a pillow fight for react vs angular,...) and the goals for the sprint. They did a great job and the result was a document:

With that document in mind, discussed with all sprinters that were coming and define our goals:

  • API : reach a stable state so we can start building front and back with it.
  • BACKEND : play, experiment and see if its possible to create our own backend for plone that is API centric and async.
  • FRONTEND : have a prototype that solves most of the problems of creating a JS application powerful, customizable and on top of a content management API

So we started a really nice week with a lot of grey matter, nice weather and energy! I really want to thanks Barcelona Activa and Startup Bootcamp for holding our sprint in their facilities! It's been great to have so much space and resources to work and concentrate!

I also want to thank all sprinters, because it did it! We could accomplish and overcome all the goals! The faces of all sprinters by the end of the week was joy and proud, so it's been great!

Finally and not least I want a special thanks to all Iskra/Intranetum team to help making it possible, the ones who attended the sprint (Aleix, Alex, Berta and Marc) and the ones who stayed at the office (specially Eudald)

I've been talking with all three groups and mostly involved on the backend team, so I'll try to explain some backend decisions and results.


Right now plone.server package on is a WIP backend that has:

  • ZTK security system to provide Permissions and Roles
  • Annotation local roles on content objects
  • Multisite system with DX Site object
  • Plone.registry on top of site objects to hold all configuration
  • Dexterity Content types (without CMF) and fti
  • Credentials extraction and user factory customizable engine
  • Aiohttp HTTP server
  • Python 3.5+ support
  • All the app works on a asyncio loop
  • A new traversal with content and language negotiation based on API definition
  • Extensible API definition on a json file
  • Basic permission checkers
  • Frame inspection based global request operation
  • Websockets basic implementation
  • Basic transaction support for asyncio
  • Async parallel utilities to run parallel process
  • Serialization of zope Schema to json
  • plone.example package with dummy content type

There are two missing parts that are covered by external tools by now:

  • Catalog: we decided to not catalog objects on the ZODB (at least right now) so we provide a transaction aware elasticsearch indexing functionality
  • User DB and JWT generation: Iskra open sourced a custom OAuth server in python/redis/ldap (plone.oauth) aware about groups/roles that can provide global roles and JWT generation, so we integrated it on the plone.server (at least right now)

There is lots of things to work on, workflows, improve request, improve transactions on ZODB,... but it's a long term project!

Opinion on some concerns

About MVCC, we can maintain it on the new core with three different approaches (thanks Asko!) 
  • For websockets create a single connection for each one and delegate to the client the commits.
  • For API requests (PUT/POST/DELETE/PATCH) do a to create a connection object for each request.
  • For async utility that are not request aware create a connection for each one, with a non request aware DB object.
It's clear that lots of websockets, utilities and requests will mean memory depending on the connection cache size.

This approach is still not implemented, we are discussing about different approaches.

About elasticsearch cataloging strategy its triggered on commit success, so search functionality will not be able before commit. That is a change from the actual stack and my opinion is that we are abusing about catalog searches on navigation and rendering. As there is no templates my opinion is that its possible to deal with BTree navigation.


plone.server, plone_client and plone.oauth are tested on travis-ci with the needed backend services to avoid mocking them using docker-compose.

plone.server, plone_client and plone.oauth are build on docker container by docker hub for each commit

After each plone.server build at docker hub a deployment is done to a sandbox cluster.

The main idea is to provide a continuous integration and continuous deployment story.

Try sandbox:

git clone
cd docker
# Choose any RAW token
# Call with you HTTP tool to
ACCEPT: application/json

Soon an integration with plone_client, a roadmap for plone.server and tests will be included!


After deploying the application I've run a small read performance test to compare plone.server agains actual stack (plone 5 with plone.restapi):

Operation : GET /dexterity_object with authentication
Result : The same on both operations

plone.server is 241% faster right now from 10 - 100 concurrent users
plone.server is 342% faster right now on 700 concurrent users 

Wildcard Corp: Wildcard Featured in Stevens Point Journal


As a growing company that doesn't see itself slowing down any time soon, Wildcard is starting to grab the attention of people in the local Stevens Point area.

An interviewer from the Stevens Point Journal had the opportunity to interview Director of Operations Gregg Gokey about the status of the company and what we are trying to build toward. Among our key goals outlined is our focus on pointing young technologists toward open source programs, especially local students.

It's truly a tremendous sight to see the publicity we are getting as a Plone provider. Hopefully this recognition will help open the door to new opportunities to spread Plone in the local community. Follow the link below to check out the article:

[Stevens Point tech company Wildcard serves FBI]

May 23, 2016

Asko Soukka: Plone Barcelona Sprint 2016 Report

by Asko Soukka at 2016-05-23T04:13:01Z

For the last week, I was lucky enough to be allowed to participate Plonecommunity sprint at Barcelona. The print was about polishing the new RESTful API for Plone, and experimenting with new front end and backend ideas, to prepare Plone for the next decade (as visioned in its roadmap). And once again, the community proved the power of its deeply rooted sprinting culture (adopted from the Zope community in the early 2000).

Just think about this: You need to get some new features for your sophisticated software framework, but you don't have resources to do it on your own. So, you set up a community sprint: reserve the dates and the venue, choose the topics for the sprint, advertise it or invite the people you want, and get a dozen of experienced developers to enthusiastically work on your topics for more for a full week, mostly at their own cost. It's a crazy bargain. More than too good to be true. Yet, that's just what seems to happen in the Plone community, over and over again.

To summarize, the sprint had three tracks: At first there was the completion of plone.restapi – a high quality and fully documented RESTful hypermedia API for all of the currently supported Plone versions. And after this productive sprint, the first official release for that should be out at any time now.

Then there was the research and prototyping of a completely new REST API based user interface for Plone 5 and 6: An extensible Angular 2 based app, which does all its interaction with Plone backend through the new RESTful API, and would universally support both server side and browser side rendering for fast response time, SEO and accessibility. Also these goals were reached, all the major blockers were resolved, and the chosen technologies were proven to be working together. To pick of my favorite sideproduct from that track: Albert Casado, the designer of Plone 5 default theme in LESS, appeared to migrate the theme to SASS.

Finally, there was our small backend moonshot team: Ramon and Aleix from Iskra / Intranetum (Catalonia), Eric from AMP Sport (U.S.), Nathan from Wildcard (U.S.) and yours truly from University of Jyväskylä (Finland). Our goal was to start with an alternative lightweight REST backend for the new experimental frontend, re-using the best parts of the current Plone stack when possible. Eventually, to meet our goals within the given time constraints, we agreed on the following stack: aiohttp based HTTP server, the Plone Dexterity content-type framework (without any HTML views or forms) built around Zope Toolkit, and ZODB as our database, all on Python 3.5 or greater. Yet, Pyramid remains as a possible alternative for ZTK later.

I was responsible for preparing the backend track in advance, and got us started with a a simple aiohttp based HTTP backend with experimental ZODB connection supporting multiple concurrent transaction (when handled with care). Most of my actual sprint time went into upgrading Plone Dexterity content-type framework (and its tests) to support Python 3.5. That also resulted in backwards compatible fixes and pull requests for Python 3.5 support for all its dependencies in plone.* namespace.

Ramon took the lead in integrating ZTK into the new backend, implemented a content-negotiation and content-language aware traversal, and kept us motivated by rising the sprint goal once features started clicking together. Aleix implemented an example docker-compose -setup for everything being developd at the sprint, and open-sourced their in-house OAuth-server as plone.oauth. Nathan worked originally in the frontend-team, but joined us for the last third of the sprint for pytest-based test setup and asyncio-integrated Elasticsearch integration. Eric replaced Zope2-remains in our Dexterity fork with ZTK equivalents, and researched all the available options in integrating content serialization of plone.restapi into our independent backend, eventually leading into a new package called plone.jsonserializer.

The status of our backend experiment after the sprint? Surprisingly good. We got far enough, that it's almost easier to point the missing and incomplete pieces that still remain on our to do:

  • We ported all Plone Dexterity content-type framework dependencies to Python 3.5. We only had to fork the main plone.dexterity-package, which still has some details in its ZTK integration to do and tests to be fixed. Also special fields (namely files, richtext and maybe relations) are still to be done.
  • Deserialization from JSON to Dexterity was left incomplete, because we were not able to fully re-use the existing plone.restapi-code (it depends on z3c.form-deserializers, which we cannot depend on).
  • We got a basic aiohttp-based Python 3.5 asyncio server running with ZODB and asynchronous traverse, permissions, REST-service mapping and JSON-serialization of Dexterity content. Integration with the new plone.oauth and was also almost done, and Ramon promised to continue to work on that to get the server ready for their in-house projects.
  • Workflows and their integration are to be done. We planned to try repoze.worklfow at first, and if that's not a fit, then look again into porting DCWorkflow or other 3rd party libraries.
  • Optimization for asyncio still needs more work, once the basic CRUD-features are in place.

So, that was a lot of checkbox ticked in a single sprint, really something to be proud of. And if not enough, an overlapping Plone sprint at Berlin got Python 3.5 upgrades of our stack even further, my favorite result being a helper tool for migrating Python 2 version ZODB databases to Python 3. These two sprints really transformed the nearing end-of-life of Python 2 from a threat into a possibility for our communitt, and confirmed that Plone has a viable roadmap well beyond 2020.

Personally, I just cannot wait for a suitable project with Dexterity based content-types on a modern asyncio based http server, or the next change meet our wonderful Catalan friends! :)

May 22, 2016

Mikko Ohtamaa: Python standard logging pattern

by Mikko Ohtamaa at 2016-05-22T19:30:26Z

(this article originally appeared in Websauna documentation)

1. Introduction

Python standard library provides logging module as a de facto solution for libraries and applications to log their behavior. logging is extensively used by Websauna, Pyramid, SQLAlchemy and other Python packages.

  • Python logging subsystem can be configured using external configuration file and the logging configuration format is specified in Python standard library.
  • Python logger can be individually turned on, off and their verbosity adjusted on per module basis. For example by default, Websauna development server sets SQLALchemy logging level to INFO instead of DEBUG to avoid flooding the console with verbose SQL logs. However if you are debugging issues related to a database you might want to set the SQLAlchemy logging back to INFO.
  • Logging is preferred diagnose method over print statements cluttered around source code.. Well designed logging calls can be left in the source code and later turned back on if the problems must be diagnosed further.
  • Python logging output can be directed to console, file, rotating file, syslog, remote server, email, etc.

2. Log colorization

  • Websauna uses rainbow_logging_handler which colorizes the logs, making it easier to read them in the console of the development web server.


3. Standard logging pattern

A common logging pattern in Python is:

import logging
logger = logging.getLogger(__name__)
def my_view(request):
    logger.debug("my_view got request: %s", request)"my_view got request: %s", request)
    logger.error("my_view got request: %s and BAD STUFF HAPPENS", request)
        raise RuntimeError("OH NOES")
    except Exception as e:
        # Let's log full traceback even when we ignore this exception
        # and it's not risen again
  • This names a logger based on a module so you can switch logger on/off on module basis.
  • Pass logged objects to logging.Logger.debug() and co. as full and let the logger handle the string formatting. This allows intelligent display of logged objects when using non-console logging solutions like Sentry.
  • Use logging.Logger.exception() to report exceptions. This will record the full traceback of the exception and not just the error message.

Please note that although this logging pattern is common, it’s not a universal solution. For example if you are creating third party APIs, you might want to pass the logger to a class instance of an API, so that the API consumer can take over the logger setup and there is no inversion of control.

4. Changing logging level using INI settings

Websauna defines development web server log levels in its core development.ini. Your Websauna application inherits settings from this file and can override them for each logger in the conf/development.ini file of your application.

For example to set SQLAlchemy and transaction logging level to more verbose you can do:

level = DEBUG
level = DEBUG

Now console is flooded with very verbose logging:

[2016-05-22 20:39:55,429] [sqlalchemy.engine.base.Engine _begin_impl] BEGIN (implicit)
[2016-05-22 20:39:55,429] [txn.123145312813056 __init__] new transaction
[2016-05-22 20:39:55,429] [sqlalchemy.engine.base.Engine _execute_context] SELECT users.password AS users_password, AS users_id, users.uuid AS users_uuid, users.username AS users_username, AS users_email, users.created_at AS users_created_at, users.updated_at AS users_updated_at, users.activated_at AS users_activated_at, users.enabled AS users_enabled, users.last_login_at AS users_last_login_at, users.last_login_ip AS users_last_login_ip, users.user_data AS users_user_data, users.last_auth_sensitive_operation_at AS users_last_auth_sensitive_operation_at, users.activation_id AS users_activation_id

5. Initialization loggers from INI file

If you need to initialize loggers in your own applications see websauna.system.devop.cmdline.setup_logging() for how Websauna picks up loggers from INI configuration file.

6. More information

How Websauna logs username and email for every internal server error. It’s impressive service if your devops teams calls a customer on a second an error happens and guide the customer around the error. As a bonus if using Sentry you will see the Gravatar profile image of the user when viewing the exception.

Logbook is an alternative for Python standard library logging if performance is critical or the application has more complex logging requirements .

Discussion about log message formatting and why we are still using old style string formatting.

structlog package – add context to your logged messages like user id or HTTP request URL.

 Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+