Weblog
Plog Wednesday morning
What are some of the topics in the Plone Open Garden in Sorrento?
More info about PLOG 2012: http://www.abstract.it/abstract-en/initiative/plone-open-garden-2012/
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.
Marion Altena: Ontworteling
Boekbespreking van deze literaire thriller.
Op de voorkant van Ontworteling staat als genre aangegeven: literaire thriller. Het literaire wil zeggen dat van de lezer enige intelligentie wordt gevraagd en dat hem in ruil daarvoor een leerzame wandeling door de architectuur, het spel van de viola da gamba en de strenge winter van 1709 wordt aangeboden. Dat het een thriller is, geeft aan dat de duistere schaduwen en onheilspellende karakters nooit ver weg zijn.
Lente is een jonge Rotterdamse fotografe. Zij komt op Internet in contact met een intrigerende figuur, Raphaël. Ze hebben goede gesprekken en ze voelt zich steeds meer tot hem aangetrokken. Ze vindt hem alleen niet helemaal eerlijk: hij beweert een vampier van ruim 300 jaar oud te zijn. Kennelijk is dat de online persoonlijkheid die hij zich aanmeet. Als ze elkaar in Londen ontmoeten, blijkt hij de waarheid gesproken te hebben...
Wacht, een vampier in een literair boek? Ja, dat heet magisch realisme. Het hele boek is realistisch, op één onderdeel na: vampiers bestaan echt. De wereld verandert er niet van, dus de vampiers moeten zich aanpassen. Ze kunnen slecht tegen de zon, dus als het even kan hebben ze het liefst een baan als nachtwaker. Ze worden niet ouder; dat gaat na een tijd opvallen, dus na tien jaar verhuizen ze naar een ander land. De schrijfster heeft er over nagedacht.
Het thriller-element zit hem in de gevaren die Lente en Raphaël bedreigen. Ten eerste is dat Raphaël zelf. In hem huist het dierlijke, vampierlijke dat uit is op bloed. Kan hij dat in de hand houden? De wereldwijde organisatie van vampiers vreest dat Lente hen zou kunnen verraden. Wat gebeurt met haar als ze dit risico te groot vinden? En dan is er nog het ongeleide projectiel Lucas die haar en Raphaël om dezelfde reden uit elkaar wil houden. Of heeft hij andere motieven en gevaarlijke ambities?
Ik ben geen kenner van het vampiergenre, maar dit boek lijkt mij een aanwinst daarvoor. Er is veel aandacht voor de karakters. Lente en Raphaël hebben elkaar wat te vertellen, leren van elkaar en veranderen door elkaar. Ik denk dat er niet veel boeken zijn die over vampiers gaan en waar je tegelijkertijd iets leert over architectuur, parkour (free running) en de viola da gamba.
Op Facebook vind je de schrijfster en het boek. Je kan een stukje van haar voorleesconcert bekijken, waarin ze uit haar boek voorleest, daarbij ondersteund door Christoph Urbanetz op de viola da gamba. Je kan het boek bestellen op bol.com en boekentip.nl.
Mijn oordeel: een intelligent, ambitieus boek met een magisch-realistische twist.
Eerste hoofdstuk
Is het eerste hoofdstuk van mijn roman verrassend?
Ik ben een boek aan het schrijven, een fantasyroman. Het eerste hoofdstuk begint voorlopig als volgt:
Kou. Het eerste wat hij voelde was kou. Het tweede was een lichte trilling, en wat geluid erbij. Het werd warmer. Hij slaakte een klein, tevreden zuchtje en sliep weer.
Er drongen geluiden tot hem door. Af en toe was er een diep gerommel, waarna hij het weer warmer kreeg. Dan hoorde hij twee stemmen: een diepe basstem en een wat hogere. Hij begon eraan te wennen en sliep rustig verder.
Hij voelde beweging. Hij ging naar beneden, hoorde een klap en bewoog naar boven. Dat ritme herhaalde zich steeds. Herhaling is goed. Hij sliep weer.
Wat was er aan de hand? Hij voelde weer beweging, maar deze keer was het helemaal niet leuk. Op en neer, heen en weer, snel en langzaam. Hij had het nog koud ook. Hij liet een klaaglijk geluid horen. Het gerommel was er weer en de warmte ook. Dat was een stukje beter. Maar wat een herrie aan zijn oren! De hoge stem en de diepe bas, maar daarbij nog een paar onbekende stemmen. Wat er daar buiten ook was, het ging flink tekeer.
Zo gaat het nog een tijdje door. De beschrijving is wat vaag en hopelijk gaat de lezer zich afvragen wat hier gebeurt en wordt nieuwsgierig en leest verder.
Dat is de opzet.
In de praktijk heeft de lezer dan allang op de flaptekst gelezen dat in het boek draken de hoofdrol vervullen. Op de omslag is vast ook wel een tekening van een draak te zien. Dus wanneer heeft de lezer door dat dit stukje geschreven is vanuit het perspectief van een draak die nog in het ei zit? Waarschijnlijk al in de eerste paragraaf.
Tot zover het opbouwen van spanning, verrassing en nieuwsgierigheid. Gaap. De hierop volgende twee à drie pagina's zijn best leuk en schattig ("Ahhhhhh, een babydraakje, is het geen snoepje?"), maar verrassend en wereldschokkend zijn ze niet meer te noemen. Oké, het draakje hoort geluiden van een gevecht op de achtergrond, dus het is duidelijk dat hij niet op het allervriendelijkste moment ter wereld komt en dat er in de rest van het boek genoeg geknokt gaat worden, maar het verrassingseffect ebt snel weg.
Oftewel: deze passage kan ik beter schrappen. Het is ook niet voor niets dat ik in een voorproefje niet dit eerste hoofdstuk heb gezet, maar een deel van een hoofdstuk dat wat representatiever is voor het hele boek. Ik had sowieso al het idee om het boek met een ander hoofdstuk te beginnen. Het oorspronkelijke begin is misschien nog leuk als kort verhaal in een fantasytijdschrijft of korte-verhalenwedstrijd, maar laat ik het maar niet in mijn roman opnemen.
Schrijfcursus
Ik ben begonnen aan een schrijfcursus.
Ik ben vanavond begonnen met de cursus Een roman en dan? van het SKVR. Deze wordt gegeven door Silvana Sodde. Ik ben ondertussen een leuk eindje gevorderd met mijn fantasyroman over draken. Daar valt nog een hoop aan te verbeteren, dus ik hoop daar in deze cursus praktische tips voor te krijgen. Als cursisten gaan we ook (twee-aan-twee) een deel van elkaars verhalen lezen en daar kritiek op leveren. Silvana zal als docent iedereen feedback geven. Naast het inhoudelijk bespreken van elkaars werk zal de nadruk vooral liggen op hoe 'het' werkt in het uitgeverswereldje.
Ik ben benieuwd wat ik hiervan ga leren. Ik hoop meer inzicht te krijgen in mijn sterke en zwakke punten. Wat zijn mijn blinde vlekken in het schrijven? Ik wil boeiende fantasyverhalen schrijven die iets laten doorschemeren van God. Dan moet ik wat in mijn hoofd zit wel duidelijk kunnen overbrengen op het papier.
Om inspiratie op te doen, heb ik zojuist een abonnement genomen op het Pure Fantasy tijdschrift.
Ik heb ondertussen ook contact gehad met een Rotterdamse schrijfster, Marion Altena. Ik ben haar boek Ontworteling aan het lezen en dat bevalt me uitstekend. Ik zal daar vast nog wel een recensie over schrijven.
Dus: het duurt nog zeker een tijd voordat mijn fantasyboek af is, maar ik ben er serieus mee bezig. Zie een voorproefje van mijn boek hier.
Python Users Netherlands
PUN meeting 15 February 2012.
The Python Users Netherlands (PUN) meeting on Wednesday 15 February 2012 was organized by Maykin Media in Amsterdam.
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.