How to create a good-looking Flipboard RSS feed

I'm a fan of Flipboard and I use the IPad app on a daily basis to browse through Facebook updates, tweets, news and fresh images. I'm also a fan of Danish basketball and I need a way to follow the different Danish online basketball media on my IPad. So - why not aggregate online media feeds and pull them from Flipboard? The app works by adding different RSS feeds to Google Reader; however, pages in Flipboard look boring. No images. Missing descriptions here and there. That is not what I want. The magazine experience, please! So in order to get this, I've now remixed a few RSS feeds utilizing Yahoo Pipes and a bit of YQL. What I do is basically two things:

1. If an RSS image is too small, pick up a bigger one if available
2. Insert an image tag at the start of the RSS description field.

And now my feed looks just right. Two examples of Yahoo Pipes RSS rewrites:

• Stiften
• DK4 Basket

Image size matters

A few observations along the way: Flipboard wants images to match the Flipboard design and filters out those images that do not meet the size requirements. After some trial and error, I think the image size rules are:

1. Minimum 120 px width and 100 px height
2. The ratio of width to height must be less than 200%, e.g., an image 200 px high can have a max width of 399 px
3. If the image height is at least 300 px, rule #2 does not apply. I've seen 300 px high images with a 1500 px width.

You can try my test RSS feed here: http://feeds.stonor.dk/flipboard/flipboard-img.xml It also looks like images wrapped in div tags are filtered out. A clean img tag works best. However, I've not spent time exploring this in depth.

Good luck Flipboard-fixing your own feeds.

Please donʼt leave the open source world, SnapLogic

I like SnapLogic. It is a great piece of middleware that makes lightweight integration convenient, using REST, JSON and Python. In another blog Iʼll talk more about why SnapLogic works, and how fun it is to write plug-ins for it.

However, over the last year it has seemed as though SnapLogic is starting to give up on the open source community, promoting its new marketplace instead (SnapStore):

• A year ago, SnapLogic had an open source installer. Now, there is a trial version and a source release (where the latest source release requires a licence and version 2.3 has not been released at all).
• A year ago, SnapLogic provided a community portal at www.snaplogic.org where everyone could browse the open source part of the code and the issue tracker. Today, permissions for public consumption of both has been revoked. I can no longer see the status of the issues Iʼve contributed to.
• A year ago, SnapLogic had a public forum at the community portal. Today, it is no longer functional.
  

There could be many reasons why SnapLogic is taking this direction. Maybe the reception of its online community was considered too limited and disappointing? Perhaps itʼs a step to reduce free riders?

Hopefully, SnapLogic will give the open source community another chance. I think it has the potential to gain momentum here, given time.

Faster faster - getting Chameleon up'n running on Plone 3.3

You might have heard of Chameleon, Malthe Borch's fast templating engine for Python. Very fast. I wanted to give it a shot on Plone 3.3 as the benchmarks posted by Plone nestor Hanno Schlichting were looking convincing.

Chameleon works out of the box on on Plone 4. Just include cmf.pt in your buildout. However getting it up and running on Plone 3.3.1 did not turn out well at first attempt. Luckily Malthe was helpful yesterday and found a simple way to work around an issue with the global template variables in Plone. In the main_template, replace this:

<metal:block macro="here/global_defines/macros/defines">
</metal:block>

with this:

<tal:globaldefines define="global plone_view context/@@plone;
global view nocall:view | nocall:plone_view;
foo plone_view/globalize">
</tal:globaldefines>

Malthe has posted a patch for the Plone 3.3 series that might be accepted.

After a few hours together with Chameleon I have a few observations to share so far:

• Chameleon works! It is a clever peace of software that really speeds of page rendering.
• Chameleon's parser is more strict than the default Zope ZPT parser. If a template is not valid XML, Chameleon throws an error. Expect to spend some time to "repair" old templates. The environment variable CHAMELEON_EAGER is helpful here. Setting it makes Chameleon spit out broken templates when Zope starts.
  
• TTW editing of Zope 2 ZPT templates doesn't work. TTW editing of Zope 3 ZPT templates with plone.app.customerize does (after fixing the customerize template).
• Old style i18n does not work (PlacelessTranslationService). That includes the main Plone translation files, so for now Chameleon is not really useful for non-english Plone sites. Any ideas of how to fix that, Hanno?
  

I'm looking forward to play more with Chameleon. It is good company.

Scratching an deployment itch

Recently we deployed 8 Plone instances at the same time running on almost the same code base. Buildout and deployment helper tools actually did a great job automating the deployment task -- with a few mandatory glitches.

However, one piece was missing in the puzzle: A consistent way to deal with running profiles and re-installing Products.

One thing is deploying a controlled code base. Another thing is changing the database state afterwards. When code adjustments and fresh packages needs to be deployed, we often see the need of changing configuration that resides in the ZODB, such as:

• Configuration of actions, content types, workflows, kupu and actions
• Persistent Archetypes schemas that needs to be synced with the code base
• Boilerplate content that just needs to be there

Generic Setup profiles and upgrade steps are a great way to deal with that. However, we still need to run them by hand. And with 8 sites and counting it is a bit boring to login and click-activate those profiles each time we deploy.

Besides being boring, it is also error prone. Often you need to run profiles in the right order not to mess up a site.

To scratch that itch we wrote a small buildout recipe: collective.recipe.updateplone
It lets you run Product installs, profiles and update profiles when you run the buildout. And it makes sure only to run them once. Give it a spin and give some feedback.

Don't load all translations at Zope startup - new filter

Plone translation maestro Hanno Schlichting has added a useful option to Placeless Translation Service. It can speed up the Zope startup time and reduce memory footprint a bit.
The philosophy is this: If your site is mono linguistic, why bother to load dozens of translations that you're not using at all?

It is quite easy to use. Just give the environment variable PTS_LANGUAGES a list of translation domains you are interested in. An example. I prefer a site to speak Danish, so I include this in the zope.conf of an instance:

<environment>
PTS_LANGUAGES da
</environment>

It works with Plone 3.1.1 - I don't know about earlier releases.

Easy testing of new deployments against a live production database

Your client AcmeCorp has a Plone website happily running in production. Being existed by all the cool features and positive response from the site visitors, the client is thirsty for more.

So you agree to build three new features and kill a handful of bugs. After a week of hard work and testing in your development environment you feel like ready to rock'n roll.

So what do you do?

1. Being eager to harvest the fruits of your hard work and to move on, you deploy directly to the production server. Hey, if it works in my development environment, it probably will do the same on the live server. If stuff goes wrong or the AcmeCorp is unhappy, I can just fix it and redeploy. Or...
   
2. AcmeCorp is an important client and you don't want to end up with eggs on you face. So you play it safe, copy the production database to a staging environment and test your changes properly. After you and AcmeCrop have tested the new package on the staging server, you deploy.
   

Now, you've got a third option. You can both play it safe and be kind-of-lazy at the same time.

Zope Godfather Jim Fulton has released two new packages that let you test on a staging server against a live, running production Zope Database (ZODB) without affecting it at all. All changes you make ends up in a separate, possible temporary database. It works with ZEO, meaning you can have your staging environment on a different physical server than the production environment.

No need to copy larges Data.fs files over the wire anymore.

The packages are:

• zc.beforestorage: Makes it possible to open a read-only connection to a ZODB database at a particular point in time. Gives you access to the production database without changing it.
• zc.demostorage2: Makes it possible to use a read-only database as "base" and store changes in a separate database.
  

I have only played a bit with the packages. A few observations:

• zc.beforestorage doesn't seem to work with the demostorage that comes with ZODB by default. You'll need zc.demostorage2.
• You need at least ZODB 3.8 to work with zc.demostorage2. Have a look at plone.app.blob buildouts for a way to upgrade ZODB.