I finally got around to produce a first Crunchy screencast. Since Crunchy is an interactive program, I thought I should do screencasts that reproduced the interactive feel: that is to say, I would record a live, more or less improvised session. This means that the screen cast is not as polished as it could be - an even has a few minor mistakes in it. Still, I think it gives a good (superficial) overview of what Crunchy is capable of.
What do you think?
Friday, November 30, 2007
Wednesday, November 28, 2007
First result from GHOP: Crunchy Estonian
By now everyone has probably heard of Google Highly Open Participation contest, and the participation of the PSF. And, initially through serendipity but later with more active involvement, a few Crunchy-related tasks were created including some involving translations. And, just a day after the contest started, a first translation (in Estonian!) has been made for Crunchy by a student named Tanel.
The tasks assigned are usually not very big but they provide nice stepping stones for getting people involved in open source software. Thank you Google for this wonderful idea.
The tasks assigned are usually not very big but they provide nice stepping stones for getting people involved in open source software. Thank you Google for this wonderful idea.
Tuesday, November 27, 2007
A failed experiment
On a whim, I decided to try a fun experiment: have Crunchy run correctly when invoked either from Python 2.4 or Python 2.5 ... or from Python 3.0! I thought that if I could make it to work, it would be a great tool to go through the 3.0 docs and tutorial, and finding out if there were any mistakes. (I was planning to do this, hoping to help the developing team in my own limited way.)
In the end, I had to give up, as Crunchy uses third-party modules (ElementTree, HTMLTreeBuilder, ElementSoup, BeautifulSoup, etc.) that I could not make compatible with both Python 2.x and 3.0 without essentially rewriting them in two separate modules each. Actually, this was already done for ElementTree (included in the stdlib under a different name) but not for the others.
The main stumbling block was string handling/encoding... This should not be a surprise to anyone who has followed the Py3k development.
Still, I've learned a fair bit from that experiment. One thing that I sort of knew already related to using print statements for debugging purpose. I often sprinkle my code with "if DEBUG: print ...", having multiple print statements appearing. Often I find that I want to have a few debug flags in the same file and think to myself
Shouldn't I replace these print statements by a debug() function with a variable setting the debug level ...
If I would have done something like this, I could have had just a few print statements located in a debug.py module. As it was, with the change in Py3k for print becoming a function, I had to do a lot of changes by hand. Yes, it might have been possible to use the automated 2to3 tool ... but I wanted to maintain compatibility with Python 2.x and, more importantly, get a feel for what was involved in making the code Py3k compatible.
If or when BeautifulSoup, ElementSoup and HTMLBuilder become Py3k compatible, I'll have to give it a try again...
In the end, I had to give up, as Crunchy uses third-party modules (ElementTree, HTMLTreeBuilder, ElementSoup, BeautifulSoup, etc.) that I could not make compatible with both Python 2.x and 3.0 without essentially rewriting them in two separate modules each. Actually, this was already done for ElementTree (included in the stdlib under a different name) but not for the others.
The main stumbling block was string handling/encoding... This should not be a surprise to anyone who has followed the Py3k development.
Still, I've learned a fair bit from that experiment. One thing that I sort of knew already related to using print statements for debugging purpose. I often sprinkle my code with "if DEBUG: print ...", having multiple print statements appearing. Often I find that I want to have a few debug flags in the same file and think to myself
Shouldn't I replace these print statements by a debug() function with a variable setting the debug level ...
If I would have done something like this, I could have had just a few print statements located in a debug.py module. As it was, with the change in Py3k for print becoming a function, I had to do a lot of changes by hand. Yes, it might have been possible to use the automated 2to3 tool ... but I wanted to maintain compatibility with Python 2.x and, more importantly, get a feel for what was involved in making the code Py3k compatible.
If or when BeautifulSoup, ElementSoup and HTMLBuilder become Py3k compatible, I'll have to give it a try again...
Tuesday, October 16, 2007
Choosing a CMS ... Will Python make it
This post is not related to programming per se; feel free to skip it ...
"We" are in the process of revamping our web site, and use a CMS. We have just signed off on the first part of the project (new look and wireframe) and are looking at the second (and "final") stage. As we are too small to afford a commercial solution, we are looking at open source CMS. So far, the preferred choice of our director of technology is Alfresco. The choice recommended by our usual technology provider is Joomla! My favourite would likely be Plone - given it is written in Python ;-)
Normally, we would proceed with a public tender - but given that there are few local providers, we may just proceed with the same firm that provided services in phase one. However ... If some of you reading this have work experience in this area, and would be interested in such a project, have a look at our current web site, and give me an informal time/cost estimate of migrating this website to use a [Python based? ;-)] CMS. If we do proceed to tender, you would most likely be included in our list of firms contacted to submit an offer.
"We" are in the process of revamping our web site, and use a CMS. We have just signed off on the first part of the project (new look and wireframe) and are looking at the second (and "final") stage. As we are too small to afford a commercial solution, we are looking at open source CMS. So far, the preferred choice of our director of technology is Alfresco. The choice recommended by our usual technology provider is Joomla! My favourite would likely be Plone - given it is written in Python ;-)
Normally, we would proceed with a public tender - but given that there are few local providers, we may just proceed with the same firm that provided services in phase one. However ... If some of you reading this have work experience in this area, and would be interested in such a project, have a look at our current web site, and give me an informal time/cost estimate of migrating this website to use a [Python based? ;-)] CMS. If we do proceed to tender, you would most likely be included in our list of firms contacted to submit an offer.
Friday, August 31, 2007
pyglet and pygame: which one?
Pygame is great. Pete Shinners has done some fantastic work in creating it. I have played a bit with it in the past and was planning to learn to use it better, and probably write some Crunchy-based tutorials for it. Unfortunately, this will not happen. Since I moved from a PC to a Mac, and installed Python 2.5, I can not use Pygame, as there is no ready-made version for my setup. Yes, I imagine I could find out how to compile it from the source ... but there is an easier alternative: pyglet. pyglet is a pure python library, with no external dependency. I downloaded it, tried it ... and it just worked. Not only that, but when Python 2.6 will come out, I know it will still work.
I do realise that pyglet is just in alpha stage ... but it's a very impressive alpha. It is not as fully featured as Pygame is ... but it works for me, thanks to Alex Holkner.
If you're currently using pygame, there's probably not any reason to switch. But if, like me, you find that you can not use pygame with your current setup, check out pyglet. You might be pleasantly surprised.
I do realise that pyglet is just in alpha stage ... but it's a very impressive alpha. It is not as fully featured as Pygame is ... but it works for me, thanks to Alex Holkner.
If you're currently using pygame, there's probably not any reason to switch. But if, like me, you find that you can not use pygame with your current setup, check out pyglet. You might be pleasantly surprised.
Python 3.0a1 has been released!
Congratulations to all Python developers on the release of Python 3.0a1!
My favourite language is on its way to get even better!
My favourite language is on its way to get even better!
Tuesday, August 07, 2007
Crunchy-like sites for javascript and ruby
While I have been aware of the Try Ruby site for quite a while, recently I came across this interactive javascript tutorial. While none of these are nearly as flexible as Crunchy, they are nice resources that are currently available for anyone to try without needing to install anything. It would be nice if I could have a dedicated server running Crunchy in a sandbox so that people could try it out without having to download it.
Subscribe to:
Posts (Atom)