Canvas CompositeOperation different behaviour on WebKit and Firefox

Recently while coding a game/scene library for Canvas I had the idea of implementing pixel perfect collision by using an offscreen canvas where to draw the two objects alone and check if they collide.

This can be easilly done with the source-in/destination-in composite operation. If any pixel of the offscreen canvas if not white then the two objects collide. It seems a great idea, but I had a bad surprise when testing it on Chrome and Safari.

Indeed it seems that source-in and destination-in have been differently intended on webkit. I find the Mozilla implementation more useful, but as the Canvas 2D specifications are written it is difficult to understand what they mean by Display the source image wherever both the source image and destination image are opaque. Display transparency elsewhere

Here you can find a screenshot of the two different behaviours

FIREFOX Composition

WEBKIT COMPOSITION

Handling iOS out of memory warning for images in web applications

It seems that one of the main problems with websites on iPad when handling with a lot of images is the limited memory reserved for images. If you have a lot of big images you will start seeing white boxes instead of your pictures when viewing the site on the iPad.

It seems somehow that Safari for iOS ignores the memory limit for background images, so you can consider substituting your img with divs with background-image to avoid hitting against the limit.

This is also valid for iOS Applications that use UIWebView.

Fixing broken inline genshi tags on TG2.1

Turbogears 2.1 got a little issue with genshi templates being rendered as xml instead of xhtml. This causes the most various strange problems with tags nesting being closed in random points as the browser likes.

This is caused by an improvement to the mechanism used to decide with rendering format to use that it is now based on the response content type. If your applications returns Content-Type text/xml or text/plain your templates will be rendered as xml or as plain text.

But what happens with your application returns text/html which is the default case?

Indeed in this case the application asks to your configuration file what to do, and as in your configuration file by default there isn’t any templating.genshi.method entry you get the default genshi behaviour, which is xml. Your browser doesn’t really like receiving some xml when he is expecting html and so handles the tags as not being closed.

In the recent future it will probably be fixed, in the mean time you can work around this problem by declaring in your development.ini

[DEFAULT]
templating.genshi.method = xhtml

This will reassemble the default behaviour that was available in TG2.0 rendering your templates as xhtml and correctly showing them inside the browser. If you have specified in your template the html doctype instead of the default xhtml one, then you might also want to change that value to html.

Workaround for empty helpers in Turbogears 2.1

Last release of TG2.1 has a subtle bug due to the changes helpers management to support in pylons 1.0, this makes the “h” object appear as an empty dict instead of your application helpers module.

The bug is already tracked on http://trac.turbogears.org/ticket/2488 and as the fix is quite easy it will be probably fixed soon. In the mean time you can work around it by monkey patching the pylons.templating.pylons_globals (I do it in lib/app_globals.py but any place is fine).

import tg.render, pylons
def patched_pylons_globals():
    x = tg.render.my_pylons_globals()
    if x['h'] == {}:
        conf = pylons.config._current_obj()
        x['h'] = conf['package'].lib.helpers
    return x
pylons.templating.pylons_globals = patched_pylons_globals

This will make your helpers work again in TG2.1.
Please pay attention that this code is specific for TG2.1, TG2.0 didn’t perform pylons_globals monkey patching and so the code won’t work.

libACR 0.6 and ACRcms 2.0 are out

As we are going deep with ACR our cms, it’s becoming a full featured product, we are using it more and more in production and we decided to release a new version on pypi.

New features include:

  • Plugins Support. You can now add your own sections to the administration panel, views to the add slice menu and implement new functions or views.
  • Multisite support, serve multiple sites from one single WSGIDaemonProcess
  • Themes Support, create your own themes for the ACRCMS
  • A simple Scripting language to automate some actions on theme setup
  • User Defined Views, create new type of contents without having to write a single line of code
  • SliceGroup Admin to permit to editors to change content of image galleries and news without have to need access to the admin panel
  • Support for Disqus comments
  • Export html slicegroups as RSS feeds
  • Various Plugins for Slideshows, Image Galleries, Accordions, etc.
  • New Script type and Script menu to make easier to add and manage javascript inside your pages
  • RDisk should now be faster and has content caching
  • Change My Password for current logged in user
  • Permit to store binary data inside contents as base64 and serve them through the /data call.
  • Integration with the Stroller eCommerce (stroller will be released opensource in the near future)

Here is the complete changelog since our latest release:

* work around to make it go with buggy sprox 0.6.10 (patched version still not released)
* Fix problem with Tg2.0 not casting headers to str
* Add delete udv and preview template for udvs
* Finalize user defined views with support for single selection fields, html and files
* Permit to serve fields encoded as per HTML5 base64 data source definition
* Add etag caching to rdisk based on file modified time
* Skeleton for user defined views
* Merge changes from master branch which improve multisite support
* Move every reference to stroller inside the stroller plugin itself
* Working delete action for slicegroup admin
* ACR might be mounted averywhere, never suppose its url, always use url() from libacr to generate acr urls
* Fix for TG2.0.3 (before tg2.1 remainder is a tuple and is not editable)
* SliceGroupAdmin plugin seems to work fine for adding things
* Make it work with Pylons1.0
* First import of sgadmin
* Stroller plugin preparatives
* Google Analytics change section
* Added new LinkedImage view same as the Image, just with a link utility. Must be evolve it, in the future to make him reuse the original view, without code duplication.
* Try to solve problems with repoze.who and repoze.what when running multiple acr sites inside the same daemon process and group
* Remove code render template from views as it collides with plugins
* Add setup script support to themes and fix default page url
* MCE options
* Fix icons and section for new plugins
* Fix for setup-app failing due to plugins
* gmap working (hopefully)
* gmap.js from static to plugin
* Merged single process mode, seems to be stable enough
* Moved GoogleMaps viewer to GoogleMaps plugin
* Disqus plugin
* Google Analytics from plugin static to site instance
* GoogleMaps key moved to database & added modify plugin
* Added tag classes for slices
* Add slice cloning
* Make rdisk_root dynamic to be able to run multiple instances in same process
* Permit to force lang from request
* Use genshi dict dotted access instead of a module
* permit to access and manipulate content from genshi slice
* add tabs plugin
* Added a class to the page as the uri of the page to make possible Custom css classes for page, hence different style for different pages
* Style fixes to administration menu
* fix crash when unable to contact pypi
* multiengine
* tests with multiengine
* engine from config
* first attemp at making a single process acr in the simplest way
* bind engine at each request
* cache session per db
* More experiments to make acr work on single process
* try to make acr work inside one single process
* Automated merge with ssh
* make section use id instead of class and declare in a less colliding way
* detect script slices also derived from default page
* Removed unused imports
* Fix done to correct the position of the excerpts under IE7
* Closes #43 it adds exception handling in case of failure of pypi version check, and just logs a warning to notify
* Minor edits
* Replaceing file templating, with python's Template string module
* Removed javascript putting css rules in place to allow 100% with of the edit menu; So added a relative container to the absolute positioned edit menu
* Minor edits
* Added new plugin to insert google analytics tracking to the site
* removed useless import
* Moved update check under helpers as it is more appropriate and, changed naming convention to follow standards
* Added new plugin to add uservoice feedback tab to pages
* add slice type class to slices, refactor properties management and add find_by_property helper
* Added help on accordion plugin, to help user interaction on creation
* Added same size of the edit button menus as the slice/slicegroup element
* Created new container for the heading admin section as pseudo-tabbed links + minor style edits on the css
* Added release update notification
* make script view wrap content with script tag and migrate existing plugins to use it
* add script slice type and menu
* Make rdisk upload view type dependant, fix videos and make deletion work on actual slice content instead of slice name
* Removed oops, console.log + Removed timestamp from end of slicegroup names to allow, reusability of the acrodion within a page, if you edit and recreate the sliceroup
* add description placement management for image slice
* Added Accordion Plugin, it will put a template for creation of Accordion galleries filters by tag on uploaded images
* fix problem with image thumbnails not showing if not logged in and add Slideshow plugin
* plugin injected resources
* add image, video and file slices to add slice menu if there is rdisk available
* themes plugin for acr
* initial work to make acr_cms working on multiple sites with only on installation, necessary to implement themes support
* improvements to edit bar

Python 3 Object Oriented Programming

Python 3 Object Oriented Programming had been reviewed already by a number of people in the python community and I’m lucky to have been given the occasion to read it as well.

As most of the other reviewers I say that the book is pleasant, it’s easy to follow and crystal clear. It gives a good overview of everything you have to expect from python.

The book is composed of 12 chapters

  • The first 5 introduce the reader to basic concepts related to object oriented programming like Objects and Classes, Exceptions and Inheritance:
    Object-oriented Design, Objects in Python, When Objects are Alike, Expecting the Unexpected, When to Use Object-oriented Programming
  • The next 2 delve into more python specific features and uses: Python Data Structures, Python Object-oriented Shortcuts
  • Two chapters on common design patterns and patterns commonly used in python follow: Python Design Patterns I, Python Design Patterns II
  • The remaining three provide some basic I/O introduction (Files and Strings) and a good intruduction to useful libraries and tools: Testing Object-oriented Programs and Common Python 3 Libraries

Each chapter share the same Introduction-Details-Case_Study-Exercise-Summary internal structure.

The book seems really good for teaching in university, it explains very clearly lots of basic concepts that usually are given as already known and introduces to concept like UML, design patterns and test driven development in a quite soft and easy way.
It is perfect for an initial object oriented programming course, if it comes along or one term before software engineering course.

  • The usage of UML is to the point and isn’t heavy at all, making it good for people that just learnt what UML is or that were going to learn it along in other courses.
  • The chapters about design patterns touch most of the commonly used patterns in python and explain why some patterns aren’t used at all. In an academic context those are quite good to show how the abstract concepts get used in the real code.
  • Since we are using a lot nose probably I’d prefer having it used while explaining unittest, still I the chapter is quite good to have somebody without previous knowledge start playing with tests.
  • The end of chapter summary and an exercise sections are quite useful for reviewing and do a bit of self check. Probably having also an appendix with the exercises solved would made the book even more student-suited.

All in all I consider this book quite well suited for Universities (both professors and students will enjoy it) and python newcomers. More skilled readers will still find it a good book to read about python3.

Android Motorola phones policy

As a previous HTC Dream owner I have been quite sad with my Motorola Backflip in the past few months. I couldn’t upgrade it to unofficial roms, I couldn’t run root software, my bootloader was constrained to run only specific signed roms probably by using IBM eFuse and last but not least Motorola announced that it didn’t have any intention to provide an upgrade to Android 2.X for the Backflip in Europe. It’s 2010 and I am confined to a device running an Android version older than the version that my 2 years old HTC Dream did run.

As I really liked the policy from Samsung to release their complete OS sources for their android phones and I really liked the design of the Galaxy S, my next phone will probably be a Samsung. In the mean time I’m finally happy to discover that someone got a working root on the Motorola Backflip and having tested it myself I can say that it actually works.

I can only hope that someone will also be able to find a way to produce backed roms for the Backflip providing and unofficial upgrade to 2.x as Motorola left me alone with my plain old Android 1.5

ACR goes for “Packt Open Source CMS Awards”!

Like every year Packt Publishing organizes the Open Source CMS Awards, right now they started the nomination phase.

The following categories make up the contest.

  • Open Source CMS

  • Hall of Fame CMS

  • Most Promising Open Source Project

  • Open Source E-Commerce Applications

  • Open Source JavaScript Libraries

  • Open Source Graphics Software

We decided to propose ACR for the Most Promising Open Source Project and Open Source CMS.

Even if young our CMS is already interesting since it’s quite easy to deploy,  it integrates in other turbogears applications (like we did for iJamix) in a breeze and has already most of the features you would expect from a full fledged CMS.

In our humble opinion is the best and most promising Turbogears2 based CMF/CMS out there.

Python Sequence VS Iterable protocols

Recently my colleague Luca got an extracted chapter of Python 3 Object Oriented Programming book to review. As I am a long time Python developer and lover I couldn’t stop myself from taking a look at the chapter so satisfy my curiosity.

A little excerpt from the chapter talks about len, reversed and zip functions illuminated me about the fact that usually due to duck typing Python developers tend to consider sequences and iterables quite the same.

The author of the books says that “The zip function takes two or more sequences and creates a new sequence of tuples” and also the help(zip) documentation says “Return a list of tuples, where each tuple contains the i-th element from each of the argument sequences”.

Indeed the zip function works on every iterable, not just sequences. Python tends to define non-formals protocols and looking around in the doc one can discover that the sequence protocol is defined as implementing __len__() and __getitem__() while the iterable protocol requires to implement __iter__() and return an iterator.

This made me think that having duck typing not only allows easier development of code, but also easier communication of concepts. In any other language commonly using formal protocols (ie interfaces, protocols, or any other formal definition of them) the author of the book would have been required to specify also the definition of the two protocols and the differences between them before the reader would have been actually able to use the zip function. In the Python case the author just had to write the sentence in natural language and the reader is aware that he/she can actually call zip on any collection, container or even generator. Anything that he unconsciously recognizes as a sequence without even having to know the existance of the protocol itself..

Indeed I recognize that duck typing and non-formal protocols tend to be more error prone, but its interesting to notice that they also help to simply communication of concepts as human tend to find easier to feel intuitions over formal definitions.