Guido Stevens: plonesocial demo

This is not yet on PyPI.

• plonesocial.activitystream: portlets and a view to show activities (like object creation) in the site, plus microblog if it is installed
• plonesocial.microblog: post twitter-like updates
• plonesocial.suite: combine this in a bundle that you can add in your buildout.

Matt Hamilton: our approach to social

http://belron.net wanted some social stuff. We installed Intracore, some stuff we usually add to intranets; not yet open source, waiting for some legal stuff and some refactoring. Technically it is separately installed in MySQL for performance reasons.

Not every website needs top performance. So some adapters that allow you to choose a back end that fits your needs would be good.

Blindly adding some social sauce does not work. People need to want to use their intranet of their own free will, otherwise they will just avoid it after a while. It should help them with their tasks. It needs to fulfill business goals.

If Plone is lacking in the social area (or any area) it can be because no one has really needed it so far. But some people may be avoiding Plone because it does not support all this stuff out of the box yet (or with an add-on). It is the same for example for supporting CMIS. But see https://github.com/infrae/collective.cmisbrowser.

Guido Stevens: a social approach to Plone

No real social networking support in Plone currently. Web 2.0 is less state driven, more event driven. I tried approaching this with ZeroMQ. Downside is that you need to setup extra services outside of Plone. You need to store this somewhere. You need to integrate it within Plone. You can pull it in using a view, but can you search it?

For a client I have built a activity/discussion stream on the front page, which was basically just plone.app.discussion under the hood. You can do similar stuff with favorites/likes. Let's just see how far we come with this low hanging fruit, just using standard content types. For thousands of users this may not scale and you may need to use other solutions outside of Plone, but that is not the initial use case we are after. A plone.social suite.

Matt: we have something similar at NetSight. Danger may be performance: it only starts begin interesting with enough users, but then performance may become a problem.

Fred: make storage flexible, so for small cases you can just annotate the Plone Site root, and for larger cases you use a separate Data.fs

Matt: plone.com

Our main website is http://plone.org. It tries to appeal to developers, decision makers, users, everyone. Last year the Plone Foundation acquired http://plone.com. We want to use this to show people why they should use Plone. It could be just twenty pages of content, translated into various languages. Leading this effort are: me, Mark Corum, Carol Ganz.

Two things to do here:

• A feature list of Plone. The old hands take a lot of things for granted, like the permission system, or being able to drag a folder somewhere else. Also, go through these features and see whether they are interesting for developers or end users.
• Show case sites. Show some good examples that give a good idea of what you can do with Plone.

Maurizio: Case management

A bit of a business buzzword currently. Gathering information about a case (health, jurisdictional, etc), determing what it is. Plone probably has 90 percent of what is needed already out of the box.

Matt: blogs

Make Plone blogging a bit more like Wordpress blogging. Just have a nice overview with a big button 'Add blog post'. Sometimes it is just terminology. Maybe make a product with a skin that turns Plone almost into WordPress. You don't have to patch Plone every week for a new security fix. Usually for our customers of course we already have Plone, so using a blog in Plone means we do not have to add an extra technology stack.

Guido: Plone Innovation Awards

An idea that may be used in the Plone Conference in Arnhem. Have an awards website where you can nominate new technologies or solutions that have surfaces in Plone. Maybe use twitter for voting. Have a ceremony at the conference.

Giampiero: Google Docs

Google Docs is not always an acceptable solution, but sending around Word files edited in Windows and Mac and Linux via email is also not always working; I have seen lots of problems, like not being able to view it anymore. Something like that would be good in Plone. There is some xmpp stuff from Jarn.

Remko Wendt, Maykin Media: Logging with Logbook

(I missed the first part as I was buying books at the nearby American Book Center, related to the ABC Treehouse where this PUN meeting is hosted; they sponsor this location.)

Logbook is a handy alternative to the standard logging module.

It is easier to disable debug logging and make it hardly take any time, contrary to the standard debug logging.

You can define a MailHandler that mails you at most 3 times per 5 minutes for the same error.

FingersCrossedHandler: only output debug level info when there is a problem .

You can use Logbook in combination with Sentry. This gathers log messages from several applications in one place, with statistics. See http://www.getsentry.com

See the Logbook documentation.

Sylvain Viollon, Infrae: Good and bad code

[Hurray: Sylvain is wearing an Emacs shirt. :-)]

I do open source because I want to reuse existing code: code that works, that helps me build my project. For me good code is reliable code. Professionally I want a high quality application that works for my customer.

Bad code is code that I can't reuse, because it is broken or it doesn't do what it claims to do.

Writing good code is writing code that works and fits my needs. Publish your code on PyPI so I can use it. Test your code, verify that it works in real life, under real conditions. Do not write tests only to get 100 percent test coverage. Handle errors and test them. Write code that is easy to test.

Respect the standards that are applicable to your application, for example the WSGI standards. Be polite to other parts of the system that you interact with. Actually look at the standards, instead of just guessing what will be the correct way.

Don't write fantasy code, code for hypothetical use cases that are never actually used. Keep it simple. Refactor your code later if needed.

Write documentation. Write simple documentation to get started. For me, doctest is not good enough for simple documentation. Maintain a changelog that is easy to find.

Listen to your users, so they can use your code. Update your code to make it usable by them or delegate that role to someone who wants to do it. Or better: make your code extensible so your users can be independent of you and continue development without you needing to watch it or spend time on it. Use dictionaries instead of if-statements [not sure how that would look, Maurits]. Create setuptools entry points. Use the Zope Component Architecture (which in essence is a nested dictionary). Do not EVER hardcode anything.

Audience:

• Remco: be iterative; start small and release it. Your package does not have to be perfect the first time around and contain everything. Do not let doubts about how good your code is hold you back.
• Good code is code that does just one thing, instead of a package that does eight things out of which just one thing is relevant for me.
• Use PEP8, please.
• Make easy tasks easy and make hard tasks possible.
• If I can choose between code hosted on Launchpad and code hosted on github, I choose github.
• 100 percent test coverage is still better than 80 percent test coverage. Sylvain: sure, but your 100 percent may have tested that your code can correctly divide 2 by 2, but you may still miss the more important corner case of dividing by zero.
• If you write documentation but do not keep it up to date, you should be shot.

Reinout van Rees, Nelen en Schuurmans: Laptop setup: explicit automation

Do not just fool around. Collect everything. It it is not version controlled, it does not exist. I have my stuff on github: https://github.com/reinout/tools

There is a directory with some tiny shell scripts that probably each save four of five seconds of work per time (e.g. editignores.sh: svn propedit svn:ignore .). Also python scripts.

Symlink your dotfiles (.bashrc, .pypirc, etc): pip install dotfiles. Separate: ~/.emacs.d: Google for the starter kit.

I have a lot of packages on github, bitbucket, pypi, etc. But my dotfiles? Maybe not. I use a private repository on an own Linux box, like ssh://vanrees.org/~/git/Dotfiles, ssh://vanrees.org/hg/preken. (Yes, I do need to have my ssh key somewhere.)

I counted: I have 31 git, 22 subversion and 9 mercurial checkouts. I use checkoutmanager so I do not have to do git pull, svn up, etc in each directory. Also, checkoutmanager out checks if I have changes that are committed but not yet pushed to the central server. It's on PyPI and bitbucket: http://pypi.python.org/pypi/checkoutmanager

Backups. You should automate this, too. I have mail that is coming in on an own server and is automatically copied to gmail. Use git/hg/svn. Use the Time Machine when you are on the Apple Mac. Synchronize with Ubuntu One. Backup your own server when you have it, for example with backupninja.

Write a blog entry on your setup, so you can Google it the next time you need it.

You can also put a gpg encrypted file with secrets (passwords) somewhere in a version control system.

Erik Romijn, Solidlinks: Making awesome apps with Open Data

Apps for Amsterdam, Apps for Noord-Holland. Last week I won the third prize in Apps for the Netherlands with an app.

What is open data? Our goverments have tons of data. Sometimes they just publish that data for free, without restrictions (as long as it is not private info of course). Data can be eighty videos about cars travelling over ice, or places where you can hook the line of your boat, or numbers about gas or electricity meters, water levels, data sets about where you can charge your electric car, Nijmegen has a register on valuable trees.

Data is available at http://data.overheid.nl/ Launched September last year.

Why should you work with open data? It is like crude oil, money just sitting on the ground waiting for someone to pick it up. You can enrich your existing apps with knowledge about the surrondings. What if your TomTom could say: "You are speeding. The intersection you are nearing saw ten deadly accidents last year." Or as Mr. T. would say: "You are a fool!"

How do you make an awesome open data app? Create awesome visualizations. Do innovative things with it. Make it exciting. Be socially relevant: e.g. show significance of solar panels. http://10000scholen.nl shows you information about schools, helping you find a good school for your children.

There is a contest. Build an awesome app, submit it for free, you may win a prize and win a seat at the main contest. On average one in three apps win.

Challenges with using open data. I do not want to scare you away, but have you be a bit more prepared. Some data needs a high level of domain knowledge. Data may be in different formats: csv, json, xml, shapefile. You may need to access it with SOAP, HTTP, FTP. Most of it is live, so it has an API. Locations: 'rijksdriehoekscoördinaten' in the Netherlands is based on a spot in a farmfield in France, or on a church tower in Amersfoort, so that may not be what you expect. The data is all in Dutch and there are no plans to change this.

After the contest, you should make your app durable. Talk to data owners about how you use it; they like that and are usually impressed. Yes, it is the government, so gettings things done may happen slowly.

How do you earn money with your apps? There was 40,000 euro in prizes awarded in apps for Amsterdam, Northern-Holland and The Netherlands. Open data usually makes no restrictions on money that you make on it. Usually the government is just happy that someone is using the data and they don't have to create an app themselves. You are free to use any business model that you like. You keep all rights. Also, it is free publicity.

If we making more awesome apps, we make it more attractive for the government to add more data.

The United Kingdom is further here. Usually the data format is different. So building the same app for similar data from two countries is hard.