Java : « Will Open-Sourcing Java Remove Competetive Corporate-Think? » de Bruce Eckel

• http://www.artima.com/weblogs/viewpost.jsp?thread=244996 (« Will Open-Sourcing Java Remove Competetive Corporate-Think? The problem with public corporations is that, no matter what they say, « maximize quarterly profits » is the real mantra…Java was created in a company run by a hyper-competitive CEO and the whole culture around it has been competitive. Many decisions were made without the consumer (programmers) in mind, but with Sun’s apparent best interests in mind…Early on, the « write once, run everywhere » chant started and that justified everything. If you want to talk to something OS-specific, you can use JNI, right? What a nightmare. And the joke became « write once, test everywhere »…Sun, as is its habit, never learns from its mistakes. Sometime in the last couple of years, rumor has it that Adobe apparently extended the possibility of working with Sun so that Flex would integrate seamlessly with Java. This would seem like a best-of-all-worlds situation, to pal up with the folks who have been specializing in UI programming. Instead, that seems to be around the time that JavaFX was started (which even poached Flex’s « Fx »). The classic « not invented here » response is the standard reply of corporate competitive-think…Open-sourcing Java is not going to make it an open-source project. The culture that has built up around Java for over ten years is not going to change just by moving to a new license…A truly open-source programming language does not have shareholders to serve. It can only serve its actual customers, the programmers who are consuming the language. For example, Python has always been about « what do you want to do today? » If you want to create a cross-platform app, no problem. And if you want to talk directly to the OS, that’s been made as easy as possible. This makes sense because Python is an « enabling » language — it’s about helping you do what you need to do, rather than telling you what you can and can’t do (these comments also apply to Ruby and other enabling languages, but I only occasionally tinker with Ruby so I can’t speak authoritatively about it).Python, after thrashing around with many different approaches, also solved the « interfacing to native code » problem. In Python 2.5, ctypes were added. Now you only have to say « there’s the DLL, connect to it as efficiently as possible » and it does it. And amazingly, the DLLs are the only things that are different on different platforms; your Python code can be the same. That’s the right solution to the problem. (When Jython 2.5 comes out, I’ve heard it will have ctypes working so that may be the reasonable alternative to JNI)…Java won’t die. But the adoption of new Java versions and features is going to continue to slow. People have been bitten too many times. Java lost its status of being a leader awhile ago, and it’s now a legacy language — it’s just taking awhile for everyone to realize it…Full disclosure: My consulting contract (mostly speaking, some free-form writing) with Adobe expired around last May (and yes, Adobe is a full-on corporation with all of the problems that implies — but according to rumor it was Adobe that suggested the liaison with Sun); I decided on my own that Flex is a good solution for UIs, both before and after that contract. Also, James Ward and I just published our coauthored book (written under our own steam, not part of the Adobe contract) First Steps in Flex. I’m working on an open-source book on Python 3. And before you say I’ve gone totally anti-Java, I also organize The Java Posse Roundup with The Java Posse (so think « tough love »).« )

Voir:

• http://openjdk.java.net/(‘What is this? The place to collaborate on an open-source implementation of the Java Platform, Standard Edition, and related projects. (Learn more.)‘)
  • http://openjdk.java.net/install/ (‘On Ubuntu 8.04 (Hardy Heron), do one of the following…The openjdk-6-jre package contains just the Java Runtime Environment. If you want to develop Java programs then install the openjdk-6-jdk package…On Fedora 9 the OpenJDK 6 runtime and development packages are installed by default during any large-media install)
• http://blogs.sun.com/darcy/category/OpenJDK

• http://fr.wikipedia.org/wiki/Openjdk (‘OpenJDK est la version libre du langage de programmation Java tel que défini par le Java Community Process.‘)
  • http://en.wikipedia.org/wiki/OpenJDK#Inclusion_in_Linux_distributions (‘As of May 2008, the Fedora^[15][16] and Ubuntu 8.04^[17] distributions were released with OpenJDK, based completely on free and open source code^[18]. OpenJDK did not pass all of the compatibility tests in the Java SE 6 JCK at the time, because of the remaining encumbrances. They had however been reduced to less than 1% of the source code^[19] and were only necessary to build OpenJDK^[20], not running it. Moreover, OpenJDK can run complex applications such as NetBeans, Eclipse, GlassFish, or JBoss. In June 2008, it was announced that IcedTea6 (as the packaged version of OpenJDK on Fedora 9) has passed the Technology Compatibility Kit tests and can claim to be a fully compatible Java 6 implementation^[21]. On July 12, 2008, Debian accepted OpenJDK-6 in unstable^[22][23], and it is now in testing^[24].Since August 2008, OpenJDK 7 is runnable on Mac OS X and other BSD distributions^[25] 9.’)

• http://planetjdk.org/

• http://wiki.debian.org/Java
• http://en.wikipedia.org/wiki/IcedTea (‘IcedTea is a software development and integration project launched by Red Hat in June 2007.^[1] The goal is to make the OpenJDK software which Sun Microsystems released as free software in 2007 usable without requiring any other software that is not free software. For Red Hat, this would make it possible to add OpenJDK to the Fedora Linux distribution, as well as other distributions. This goal has been met, and a version of IcedTea based on OpenJDK was packaged with Fedora 8 in November 2007. April 2008 saw the first release^[2] of a new variant, IcedTea6 which is based on Sun’s build drops of OpenJDK6, a fork of the OpenJDK with the goal of being compatible with the existing JDK6. This was released in Ubuntu and Fedora in May 2008. The IcedTea package in these distributions has been renamed to OpenJDK using the OpenJDK trademark notice‘)
• http://packages.debian.org/sid/java-package (‘This program currently works with the following Java(TM) 2 Runtime Environments and Development Kits:

   * Sun Microsystems(TM) 1.4, 5 and 6 Standard Edition
   * IBM(TM) 1.3, 1.4, 5 and 6 Standard Edition
   * Blackdown Java-Linux 1.3 and 1.4 Standard Edition')

Python: news du 17 décembre 2008

• –http://ironpython-urls.blogspot.com/2008/12/ironpython-2-final-released.html (‘IronPython 2 final (or Release To Web in Microspeak) is finally out. IronPython 2 targets Python 2.5, is built on top of the Dynamic Language Runtime and runs on .NET 2 SP1, Mono 2.2 and Silverlight.’)

• http://tarekziade.wordpress.com/2008/12/16/pycon-2009-talks/ (‘The talks that made it:
  • How AlterWay releases web applications using zc.buildout
  • On the importance of PyPI in delivering and building Python softwares – mirroring, fail-over and third-party package indexes »)
• http://jessenoller.com/2008/12/16/pycon-2009-talks-accepted/ (‘Last night I got two emails – both of my talks I proposed for PyCon 2009 were accepted, here’s the title and abstract from both:
  • Introduction to Multiprocessing in Python
    • This talk will cover the new multiprocessing package included with Python 2.6 (and 3.0) focusing on design, benefits, practical usage, application construction, gotchas and how to use it to build multi-core and distributed applications.
  • Concurrency and Distributed Computing with Python Today
    • This talk will cover the recent changes to Python 2.6, including a brief introduction to the threading module and multiprocessing inclusion and changes but will primarily focus on the concurrent and distributed ecosystem for Python today.‘)

Python package management: « using pip requirements » from Ian Bicking

Un article très dense et très instructif de Ian Bicking reproduit dans son intégralité:

Source: http://blog.ianbicking.org/2008/12/16/using-pip-requirements/

================================

Following onto a set of recent posts (from James, me, then James again), Martijn Faassen wrote a description of Grok’s version management. Our ideas are pretty close, but he’s using buildout, and I’ll describe out to do the same things with pip.

Here’s a kind of development workflow that I think works well:

• A framework release is prepared. Ideally there’s a buildbot that has been running (as Pylons has, for example), so the integration has been running for a while.
• People make sure there are released versions of all the important components. If there are known conflicts between pieces, libraries and the framework update their install_requires in their setup.py files to make sure people don’t use conflicting pieces together.
• Once everything has been released, there is a known set of packages that work together. Using a buildbot maybe future versions will also work together, but they won’t necessarily work together with applications built on the framework. And breakage can also occur regardless of a buildbot.
• Also, people may have versions of libraries already installed, but just because they’ve installed something doesn’t mean they really mean to stay with an old version. While known conflicts have been noted, there’s going to be lots of unknown conflicts and future conflicts.
• When starting development with a framework, the developer would like to start with some known-good set, which is a set that can be developed by the framework developers, or potentially by any person. For instance, if you extend a public framework with an internal framework (or even a public sub-framework like Pinax) then the known-good set will be developed by a different set of people.
• As an application is developed, the developer will add on other libraries, or use some of their own libraries. Development will probably occur at the trunk/tip of several libraries as they are developed together.
• A developer might upgrade the entire framework, or just upgrade one piece (for instance, to get a bug fix they are interested in, or follow a branch that has functionality they care about). The developer doesn’t necessarily have the same notion of « stable » and « released » as the core framework developers have.
• At the time of deployment the developer wants to make sure all the pieces are deployed together as they’ve tested them, and how they know them to work. At any time, another developer may want to clone the same set of libraries.
• After initial deployment, the developer may want to upgrade a single component, if only to test that an upgrade works, or if it resolves a bug. They may test out combinations only to throw them away, and they don’t want to bump versions of libraries in order to deploy new combinations.

This is the kind of development pattern that requirement files are meant to assist with. They can provide a known-good set of packages. Or they can provide a starting point for an active line of development. Or they can provide a historical record of how something was put together.

The easy way to start a requirement file for pip is just to put the packages you know you want to work with. For instance, we’ll call this project-start.txt:

Pylons
-e svn+http://mycompany/svn/MyApp/trunk#egg=MyApp
-e svn+http://mycompany/svn/MyLibrary/trunk#egg=MyLibrary

You can plug away for a while, and maybe you decide you want to freeze the file. So you do:

$ pip freeze -r project-start.txt project-frozen.txt

By using -r project-start.txt you give pip freeze a template for it to start with. From that, you’ll get project-frozen.txt that will look like:

Pylons==0.9.7
-e svn+http://mycompany/svn/MyApp/trunk@1045#egg=MyApp
-e svn+http://mycompany/svn/MyLibrary/trunk@1058#egg=MyLibrary

## The following requirements were added by pip –freeze:

Beaker==0.2.1
WebHelpers==0.9.1
nose==1.4
# Installing as editable to satisfy requirement INITools==0.2.1dev-r3488:
-e svn+http://svn.colorstudy.com/INITools/trunk@3488#egg=INITools-0.2.1dev_r3488

At that point you might decide that you don’t care about the nose version, or you might have installed something from trunk when you could have used the last release. So you go and adjust some things.

Martijn also asks: how do you have framework developers maintain one file, and then also have developers maintain their own lists for their projects?

You could start with a file like this for the framework itself. Pylons for instance could ship with something like this. To install Pylons you could then do:

$ pip -E MyProject install  -r http://pylonshq.com/0.9.7-requirements.txt

You can also download that file yourself, add some comments, rename the file and add your project to it, and use that. When you freeze the order of the packages and any comments will be preserved, so you can keep track of what changed. Also it should be ameniable to source control, and diffs would be sensible.

You could also use indirection, creating a file like this for your project:

-r http://pylonshq.com/0.9.7-requirements.txt
-e svn+http://mycompany/svn/MyApp/trunk#egg=MyApp

-e svn+http://mycompany/svn/MyLibrary/trunk#egg=MyLibrary

That is, requirements files can refer to each other. So if you want to maintain your own requirements file alongside the development of an upstream requirements file, you could do that.

Python package management: critiques de setuptools et louanges de pip et virtualenv

La compréhension de la gestion des packages Python est devenue essentielle avec l’arrivée de 2 nouvelles versions de Python: python 2.6 et Python 3000 (ou Python 3k)

Voici quelques articles récents:

– http://blog.ianbicking.org/2008/12/14/a-few-corrections-to-on-packaging/ (‘James Bennett recently wrote an article on Python packaging and installation, and Setuptools. There’s a lot of issues, and writing up my thoughts could take a long time, but I thought at least I should correct some errors, specifically category errors. Figuring out where all the pieces in Setuptools (and pip and virtualenv) fit is difficult…

…

pip:

This is an alternative to easy_install. It works somewhat differently than easy_install, but not much. Mostly it is better than easy_install, in that it has some extra features and is easier to use. Unlike easy_install, it downloads all distributions up-front, and generates the metadata to read distribution and version requirements. It uses Setuptools to generate this metadata from a setup.py file, and uses pkg_resources to parse this metadata. It then installs packages with the setuptools monkeypatches applied. It just happens to use an option python setup.py –single-version-externally-managed, which gets Setuptools to install packages in a more flat manner, with Distro.egg-info/ directories alongside the package. Pip installs eggs! I’ve heard the many complaints about easy_install (and I’ve had many myself), but ultimately I think pip does well by just fixing a few small issues. Pip is not a repudiation of Setuptools or the basic mechanisms that easy_install uses.

virtualenv:

This is a little hack that creates isolated Python environments. It’s based on virtual-python.py, which is something I wrote based on some documentation notes PJE wrote for Setuptools. Basically virtualenv just creates a bin/python interpreter that has its own value of sys.prefix, but uses the system Python and standard library. It also installs Setuptools to make it easier to bootstrap the environment (because bootstrapping Setuptools is itself a bit tedious). I’ll add pip to it too sometime. Using virtualenv you don’t have to worry about different library versions, because for any one environment you will probably only need one version of a library. On any one machine you probably need different versions, which is why installing packages system-wide is problematic for most libraries. (I’ve been meaning to write a post on why I think using system packaging for libraries is counter-productive, but that’ll wait for another time.

…I don’t think zipping libraries up is all that useful, and while it should work, it doesn’t always, and it makes code harder to inspect and understand. So since it’s not that useful, I’ve disabled it when pip installs packages. I also have had it disabled on my own system for years now, by creating a distutils.cfg file with [easy_install] zip_ok = False in it. Sadly App Engine is forcing me to use zip files again, because of its absurdly small file limits… but that’s a different topic. (There is an experimental pip zip command mostly intended for App Engine.

…Another pain point is version management with setup.py and Setuptools. Indeed it is easy to get things messed up, and it is easy to piss people off by overspecifying, and sometimes things can get in a weird state for no good reason (often because of easy_install’s rather naive leap-before-you-look installation order). Pip fixes that last point, but it also tries to suggest more constructive and less painful ways to manage other pieces.

Pip requirement files are an assertion of versions that work together. setup.py requirements (the Setuptools requirements) should contain two things: 1: all the libraries used by the distribution (without which there’s no way it’ll work) and 2: exclusions of the versions of those libraries that are known not to work. setup.py requirements should not be viewed as an assertion that by satisfying those requirements everything will work, just that it might work. Only the end developer, testing the system together, can figure out if it really works. Then pip gives you a way to record that working set (using pip freeze), separate from any single distribution or library….

…

Tarek Ziadé | 14-Dec-08 at 5:29 pm | Permalink

• http://www.b-list.org/weblog/2008/dec/15/pip/ (‘Why I like pip. So yesterday I explained some of the reasons why I don’t like setuptools. In essence, my objections boil down to one idea: application packagingdevelopment should be orthogonal concerns. The way setuptools works, however, seems to tend, inevitably, toward coupling them to each other…But toward the end of yesterday’s article I suggested pip as an alternative to pkg_resources/easy_install toolchain, and today I’d like to explain a bit more about why I prefer pip and some of the concrete benefits it offers and application as an alternative to the setuptools… in his response to my article yesterday Ian clarified that pip just uses the setuptools APIs to do this. Which is saying something: glossing over setuptools’ warts to the point where you don’t even realize it’s being used is a pretty big deal… pip looks before it leaps, can bail out early if it’s not going to be able to install your package and will leave behind a useful log file explaining what went wrong…The point where pip really shines, though, is in the ease of specifying and creating reproducible builds. If you’ve ever dealt with having to deploy the same code base across multiple machines, you know what a headache this can be, since a huge number of factors (operating system and version, pre-installed packages and versions, system package managers and configuration, etc., etc.) can change the results of your deployment process, sometimes in subtle and difficult-to-debug ways. With pip, this is not (so much of) a problem…I mentioned pip requirements files yesterday as an alternative to the way setuptools specifies dependencies directly in setup.py, and that’s certainly one useful application of the feature, but you can take it much further: once you know which packages (and, just as important, which versions of which packages) you need, you can write them down in a simple, plain-text file, point pip at it, and it’ll install them…The last piece of the puzzle, for me, is virtualenv; virtualenv is a tool for creating and working with isolated Python environments, and is basically the only way I work with Python these days…pip integrates quite nicely with virtualenv; normally, when working in an active virtualenv, Python packaging/installation tools (pip included) will install into that virtualenv, but pip also lets you:

• Specify a virtualenv to install into (using the -E flag), and

• Create a new virtualenv and install into it.

The second one is really the killer feature, because it means you can set up a requirements file specifying a list of packages, and get pip to create a virtualenv for you and install the packages into it…… well, there’s a heck of a lot more I could write here about pip (and about virtualenv, and about some other interesting tools), but I think this is a good start and hopefully I’ve at least got you interested enough to explore a bit on your own. And I hope I’ve managed to communicate some of the practical reasons why I’ve ditched easy_install for package installation; compared to what pip can do right now (not even considering what it might be able to do in the future), easy_install just doesn’t measure up enough to justify the headaches it can create… »)

• http://tarekziade.wordpress.com/2008/12/15/python-isolated-environment-pie/ (‘Right now, when Python is loaded, it uses the site module to browse the site-packages directory to populate the path with packages it find there.  .pth files are also parsed to provide extra paths. Python 2.6 has introduced per-user site-packages directory, where you can define an extra directory, which is added in the path like the central one. But both will append new paths to the environment without any rule of exclusion or version checking…A few workarounds exist to be able to express what packages (and version) an application needs to run, or to set up an isolated environment for it:
• setuptools provides the install_requires mechanism where you can define dependencies directly inside the package, as a new metadata. It also provides a way to install two different versions of one package and let you pick by code or when the program starts, which one you want to activate.
• virtualenv will let you create an isolated Python environment, where you can define your own site-packages. This allows you to make sure you are not conflicting with a incompatible version of a given package.
• zc.buildout relies on setuptools and provides an isolated environment a bit similar in some aspects to virtualenv.
• pip provides a way to describe requirements in a file, which can be used to define bundles, which are very similar to what zc.buildout provides.

But they all aim at the same goal : define a specific execution context for a specific application, and declare dependencies with no respect to other applications or to the OS environment…This proposal describes a solution that can be added to Python to provide that feature. A new file called a  Python Isolated Environment file (PIE file) can be provided by any  application to define the list of dependencies and their versions…’)

Logiciel libre: La Campagne d’ahésion à l’APRIL continue…

http://www.april.org/fr/roman-photo-campagne-adhesion

Le roman photo

Pour illustrer sa campagne d’adhésion de manière humoristique, l’April a réalisé un roman photo en forme que questionnaire à choix multiple. Nous espérons ainsi expliquer de manière ludique les raisons de notre campagne … saurez vous les trouver ?

• Pourquoi l’April a-t-elle besoin de financement ?
• Pourquoi l’April a-t-elle besoin de plus de membres ?
• Pourquoi adhérer à l’April ?

Ce roman photo a été tourné au local de l’April le 4 décembre 2008 sous la direction de Luc Fievet.

Les photos sont de Jérémie Zimmermann et sont placées sous licence art libre.

Les acteurs

Luc FIEVET
Le réalisateur du roman photo !
Sous l’influence des libristes acharnés et précoces de l’université de Paris 8, j’ai été sensibilisé au libre assez tôt mais n’étant pas informaticien la chose manquait d’aspect pratique pour moi. Puis l’élargissement des problématiques (avec les licences libres et de libre diffusion appliquées en dehors de l’informatique) ainsi que des logiciels libres accessibles aux utilisateurs de base dont je suis m’ont permis de rentrer dans le mouvement dont la grande qualité à mon sens est de permettre d’allier pratique et idéologie.

	Benoît SIBAUD Président. Membre du conseil d’administration depuis le 18/12/2002. Ingénieur en informatique dans un centre de R&D Télécoms. Il a découvert GNU/Linux dans un magazine en 1996. Après des implications dans un GULL et à LinuxFr.org, il adhère à l’APRIL en 2001 pour sa dimension nationale, et pour être plus actif dans la défense du logiciel libre. À l’APRIL, il a entre autres créé le groupe de travail pour obtenir un classement du logiciel libre au patrimoine immatériel de l’humanité et est président depuis décembre 2004. En dehors de l’APRIL, il est encore co-webmestre du site LinuxFr et fait partie de l’organisation des Rencontres Mondiales du Logiciel Libre. Un mini-cv est aussi disponible.
Jérémie ZIMMERMANN Vice-président. Membre du CA depuis le 16/11/2004. Ingénieur-conseil indépendant, artisan-intégrateur passionné de logiciels libres depuis sa découverte de GNU/Linux en 1996. Il s’interesse tout particulièrement à la rencontre entre le droit et les technologies numériques, notamment depuis la promulgation du DMCA, et les batailles des brevets logiciels et du DADVSI. Multitâche frénétique, il papillonne entre de nombreux projets professionnels, associatifs et personnels (photos, musiques, fromages, etc.)	Benjamin DRIEU Trésorier. Informaticien, fondateur et membre du CA depuis le 29/11/1996. Il a découvert le libre à la fac et s’est lancé dans l’APRIL pour essayer de le démocratiser auprès du public. Il occupe les fonctions de trésorier, effectue des tâches d’administration système et assure le développement du SI. En dehors de l’APRIL, il est aussi impliqué dans le projet Grisbi.
Tony BASSETTE Trésorier adjoint. Il a découvert les logiciels libre sur les bancs de l’université Paris 8 en 1992. Fondateur, trésorier et maintenant administrateur de l’association. Il a fondé l’APRIL afin d’aider à la démocratisation des logiciels libre auprès du grand public. La démocratisation des logiciels libres dans le monde de l’entreprise s’est faite au travers de son activité professionnelle.	Tangui MORLIER Membre du CA. Diplômé de l’INSA de Lyon et de l’IUT de Vannes, Tangui Morlier est ingénieur en informatique indépendant. À partir de 1998, date à laquelle il découvre GNU/Linux, il s’intéresse aux logiciels libres et à la culture libre en général. Il s’investit dans Copyleft Attitude à partir de 2000. Afin de soutenir le travail de diffusion et de défense du logiciel libre, il devient membre de l’APRIL en 2006. Tangui est également membre du collectif StopDRM.
Frédéric COUCHET Délégué général. Fondateur et président pendant presque 10 ans. Informaticien de formation, marié et père de deux enfants, il a découvert le libre dès 1990 à l’université Paris 8. A travers l’APRIL, et la FSF France, il cherche à créer et défendre un écosystème politique et juridique favorable au logiciel libre. Plus d’info sur Frédéric avec son mini-cv ou sur son site perso.	Alix CAZENAVE Permanente. Alix Cazenave a rejoint en octobre 2007 l’équipe des permanents de l’APRIL. Elle est en charge des dossiers institutionnels, législatifs et réglementaires. Après l’École internationale de commerce et développement 3A (EICD 3A), Alix a complété sa formation par un master Ingénierie de l’information, de la décision et de la connaissance. Dans son parcours professionnel elle a notamment été chargée de veille technologique à SOITEC, leader mondial du silicium sur isolant (SOI), avant de devenir assistante parlementaire de 2005 à 2007. À ce poste, elle a notamment travaillé sur les dossiers brevets logiciels, RGI et DADVSI.
Eva MATHIEU Permanente. Eva Mathieu a rejoint l’équipe de l’APRIL le 9 octobre 2006 au poste d’assistante de direction. Outre les tâches de gestion et d’organisation de l’association, Eva Mathieu intervient comme support au développement de l’association. Diplômée d’une maîtrise de philosophie, trilingue, Eva a assumé depuis vingt ans diverses fonctions telles que chargée de projet, assistante de direction et documentaliste, dans des contextes humains et professionnels variés.

http://www.april.org/fr/campagne-dadhesion-april-plus-de-1-000-nouveaux-adherents

La campagne en chiffres

Pour encore mieux promouvoir et défendre le logiciel libre, l’April a lancé le 12 novembre 2008 une campagne d’adhésion qui a pour objectif de renforcer l’April dans sa représentativité et dans ses moyens d’actions.

Un mois après le lancement de la campagne d’adhésion nous venons de dépasser les 1 000 nouveaux adhérents.

Près de 900 personnes, 58 entreprises, 25 associations, 1 collectivité locale et 2 départements universitaires ont rejoint l’April suite à son appel à soutien.

Le nombre actuel d’adhérents est désormais de 3 613 répartis ainsi: 3 338 personnes, 162 entreprises ou réseaux d’entreprises, 107 associations, 3 collectivités et 2 départements universitaires.

Une nouvelle collectivités et deux départements universitaires

Nous avons donc le plaisir d’accueillir une nouvelle collectivité : la ville de Yerres dont le conseil municipal a approuvé à l’unanimité le 11 décembre 2008 l’adhésion à l’April.

Nous accueillons également un nouveau type d’adhérent personne morale à savoir deux départements universitaires :

• la licence professionnelle « Communication, Logiciels Libres et Sources Ouvertes » qui est une formation universitaire professionnalisante qui s’adresse aux communicant(e)s ou aux personnes qui recherche à compléter une compétence initiale avec des connaissances et des savoir faire des metiers de la communication
• Le laboratoire LE2I (Laboratoire d’Electronique, Informatique et Image), qui est associé au département STIC du CNRS depuis Janvier 2001 (FRE CNRS 2309 puis UMR CNRS depuis janvier 2003). Il est composé d’enseignants-chercheurs provenant des sections 27, 61 et 63 du CNU, de collaborateurs techniques et administratifs et de doctorants répartis sur quatre sites géographiques.

Soutiens

Parmi les soutiens de notre campagne d’adhésion nous avons notamment : Tristan Nitot, Alexis Kauffmann, LinuxFr, Framasoft, Ubuntu-fr (communauté francophone des utilisateurs d’Ubuntu), le projet VideoLAN, Fedora-Fr (communauté francophone des utilisateurs de Fedora), l’Association des Utilisateurs Francophones de Mandriva Linux, Sésamath (association ayant pour but, la création collaborative et le partage gratuit sur Internet de ressources pédagogiques en mathématiques).

Causerie April sur la campagne

Les « Causeries April » sont des interviews ou des discussions d’une durée d’une ou deux heures, sur un sujet donné. La causerie du mardi 9 décembre 2008 a eu lieu de 21h à minuit sur le thème «Causerie sur l’April, sa campagne d’adhésion, ses actions passées et à venir», avec l’équipe de l’April dont Benoît Sibaud, président de l’April, Frédéric Couchet délégué général, Alix Cazenave chargée des affaires publiques. Le compte-rendu a été publié, bonne lecture.

Le roman photo et la causerie sont deux éléments différents et utiles pour permettre d’expliquer les raisons de la campagne d’adhésion.

N’hésitez pas donc à diffuser largement ces éléments sur vos blogs, sites…

Logiciel libre: nouvelle campagne d’adhésion de l’APRIL: objectif 5000 adhérents pour la fin de l’année 2008

• Presque un mois après le lancement c’est plus de 880 personnes qui ont répondu présente à notre appel ainsi que plus de 50 entreprises  et près de 25 associations.  Nous approchons donc la barrre des 1 000 nouveaux adhérents. Symboliquement ce serait bien de la dépasser d’ici le 12 décembre.  Ce jour-là nous organisons en effet (ou participons à) quatre soirées (voir http://www.april.org/fr/lapril-fete-ses-12-ans) et nous organisons  une conférence de presse de bilan 2008. À cette occasion sera d’ailleurs  annoncée l’adhésion à l’April d’un nouveau type de personne morale. Il est important de continuer à bien relayer la campagne pour que le rythme  se maintienne.

Parmi les récents soutiens notons Ubuntu-fr :

• http://www.april.org/fr/ubuntu-fr-appelle-les-utilisateurs-dubuntu-a-adherer-a-lapril (‘« Ubuntu-fr travaille depuis plusieurs années avec l’April, et en est membre. C’est une association en laquelle nous avons confiance et dont nous soutenons les projets. […] Nous pensons que les objectifs de l’April rejoignent, directement ou indirectement, ceux d’Ubuntu-fr, et que le travail de l’April a contribué au déploiement des logiciels libres comme Ubuntu dans la francophonie. Ubuntu-fr appelle les utilisateurs d’Ubuntu à adhérer à l’April. Soutenir l’April, c’est aussi soutenir Ubuntu ! »‘)
  
• http://www.april.org/fr/adhesion-a-lapril-de-lassociation-des-utilisateurs-francophones-de-mandriva-linux

Adhérer à l'APRIL pour lutter contre les brevets abusifs:

• http://www.numerama.com/magazine/10718-L-Office-europeen-des-brevets-en-greve-pour-denoncer-les-abus.htm (‘« Chaque année, le nombre de brevets déposés en Europe augmente. Alors que les gouvernements y voient le signe d’une recherche en bonne santé, des examinateurs de l’Office européen des brevets manifestent et dénoncent un emballement néfaste à la qualité de l’innovation, encouragé pour des raisons purement financières et politiques…Les attaques contre les abus de propriété intellectuelle se multiplient ces dernières années sous l’influence des lobbys du logiciel libre, des groupes de défense des intérêts publics, des internautes qui réclament la possibilité de partager librement les oeuvres, des organisations qui militent contre la brevetabilité du vivant ou en faveur d’un assouplissement des règles de protection des molécules des médicaments à destination des pays les plus défavorisés. Après plus d’un siècle de laisser-faire où la propriété intellectuelle s’est toujours renforcée à coups d’accords internationaux (ce qu’ils essayent encore de faire), le balancier ne demande qu’à partir dans l’autre sens...Vendredi dernier, des examinateurs de brevets et d’autres employés de l’Office Européen des Brevets (OEB) ont ainsi manifesté dans les rues de Bruxelles devant la Commission Européenne, non pas pour demander une réévaluation de leur statut ou de leur salaire… mais simplement pour demander une réforme du système des brevets qui arrêterait enfin de freiner l’innovation au lieu de l’encourager…Le nombre de demandes de brevets augmente chaque année. Alors qu’il était de 60.000 demandes en 1990, 209.000 brevets ont été déposées en 2006. Or plus le nombre de brevets augmente, plus le risque juridique des entreprises qui innovent grossit. Statistiquement, les chances de violer un brevet sont multipliées par le nombre de titres octroyés en circulation. Par crainte de représailles, et par manque de solidité financière pour acquérir les licences, les petites et moyennes entreprises gèlent leurs travaux de recherche et développement lorsqu’elles s’aperçoivent qu’elles exploitent de près ou de loin un procédé breveté, ou qu’elles le craignent. Quand bien même la validité du brevet serait à coup sûr annulée en justice en cas de procès, les entreprises préfèrent abandonner leurs recherches que de risquer une procédure judiciaire très longue, très coûteuse, qui les mènerait à la faillite avant son terme.‘)
  

A voir

• http://www.april.org/relayez-la-campagne-dadhesion ('Soyez les premiers ambassadeurs de l'April en faisant connaître l'association autour de vous.')

• http://www.april.org/wws/info/campagne-adhesion (‘Cette liste regroupe l’ensemble des personnes travaillant a l’animation de la campagne d’adhesion de l’April.’)
• http://www.april.org/fr/tristan-nitot-appelle-a-adherer-a-lapril-pour-soutenir-ses-actions-de-promotion-et-defense-du-logiciel-libre (‘Pour encore mieux promouvoir et défendre le logiciel libre l’April lance, avec le soutien de Tristan Nitot (président de Mozilla Europe), aujourd’hui 12 novembre 2008 une campagne d’adhésion qui a pour objectif de renforcer l’April dans sa représentativité et dans ses moyens d’actions. L’April souhaite atteindre dans un premier temps les 5 000 adhérents avant la fin de l’année. L’April a besoin de votre soutien dès maintenant.)
  

• « VideoLAN encourage ses utilisateurs français à adhérer à l’association amie April. L’April, par le passé, a soutenu VideoLAN dès le début de son aventure dans le logiciel libre. L’action de l’April, lors de son engagement contre des projets de lois bloquant le logiciel libre ou pour la défense de la GPL, est soutenue par l’équipe de VideoLAN. »

Faites comme Tristan Nitot et les autres membres de l’association :

• adhérez dès maintenant à l’April
• encouragez d’autres à nous rejoindre en relayant la campagne d’adhésion

A lire et relire 🙂

• http://www.april.org/ (‘Pionnière du logiciel libre en France, l’April, constituée de 3520 adhérents (3252 individus, 268 entreprises, associations et collectivités), est depuis 1996 un acteur majeur de la démocratisation et de la diffusion du logiciel libre et des standards ouverts auprès du grand public, des professionnels et des institutions dans l’espace francophone’)
• http://fr.wikipedia.org/wiki/April_(association) (‘L’April (Association pour la Promotion et la Recherche en Informatique Libre) est une association qui a pour but la promotion et la défense du logiciel libre dans l’espace francophone. À ce titre, elle entretient depuis le début des rapports étroits avec la Free Software Foundation, et traduit depuis longtemps la section philosophie^[1] du projet GNU.’)
• http://www.april.org/fr/brevets-sur-les-logiciels (‘Les brevets sur les logiciels constituent une menace pesante sur l’ensemble de l’industrie du logiciel, qu’il soit libre ou non. ‘)
• http://www.ffii.org/ The Foundation for a Free Information Infrastructure (FFII) is a non-profit organisation dedicated to establishing a free market in information technology, by the removal of barriers to competition. The FFII was largely responsible for the rejection of the EU software patent directive in July 2005, working closely with the European Parliament and many partners from industry and civil society. CNET awarded the FFII the Outstanding contribution to software development award for this work, which was the result of years of research, policy, and action. Today we continue to defend your right to a free and competitive software market by working towards sane patent systems and open standards.

« Python 3.0 and 2.6 and Executable Zipfiles »: a great way of distributing applications as a single file

Source: http://www.voidspace.org.uk/python/weblog/arch_d7_2008_12_06.shtml#e1038

A new feature that was quietly sneaked into Python 2.6 (NDLR, and Python 3.0), without the fanfare it deserves, is the ability to distribute Python applications as executable zipfiles.

What is new is the ability to make zip archives executable. If you call the Python 2.6+ (or 3.0+) interpreter passing in a zip file instead of a Python file – the interpreter looks inside the zip file for a Python file named __main__.py (at the top-level) and executes it. The zip file can also contain all the (pure-Python only) modules and packages your app depends on.

This is a great way of distributing applications as a single file. The nice thing is that the Python interpreter doesn’t depend on the extension to recognise zipfiles, instead recognising them automagically.

Floris Bruynooghe notes in the comments that you can add a hash-bang line to a zipfile and make it executable:

$ cat > __main__.py
print('hi there')
^D
$ zip test.zip __main__.py
adding: __main__.py (stored 0%)
$ cat > hashbang.txt
#!/usr/bin/env python3.0
^D
$ cat hashbang.txt test.zip > my_exec
$ chmod +x my_exec
$ ./my_exec
hi there
$

Un grand événement pour Python: la sortie de la version 3.0: Python 3000, Py3k

voir https://pvergain.wordpress.com/py3k/ pour les mises à jour.

Ca y est:Python 3000 est arrivé !

Bien sûr la version 2.5 qui est installée sur un très grand nombre de systèmes ne va pas être remplacée de sitôt car un grand nombre de frameworks python ne sont pas encore sous Python 3000. La démarche qui est recommandée est de passer par une version 2.6 et ensuite passer sur Py3k.

Voir à ce sujet:

• http://wiki.python.org/moin/PortingToPy3k (‘Since Python 3 introduces some incompatibilities, a porting strategy is needed to be able to run code on Python 3, and to have a single codebase that can be made to work under Python 2 and Python 3 using automatic conversion‘)
  • http://wiki.python.org/moin/PortingPythonToPy3k
  • http://wiki.python.org/moin/PortingExtensionModulesToPy3k
• la FAQ 3000.
• http://docs.python.org/3.0/library/2to3.html (‘2to3 is a Python program that reads Python 2.x source code and applies a series of fixers to transform it into valid Python 3.x code. The standard library contains a rich set of fixers that will handle almost all code. 2to3 supporting library lib2to3 is, however, a flexible and generic library, so it is possible to write your own fixers for 2to3. lib2to3 could also be adapted to custom applications in which Python code needs to be edited automatically’)

D’abord un grand bravo à tous les core-développeurs Python qui ont participé à son développement !.

Ci-dessous quelques réactions à la sortie de Python 3000:

– http://www.python.org/download/releases/3.0/ (‘

We are pleased to announce the release of Python 3.0 (final), a new production-ready release, on December 3rd, 2008.

Python 3.0 (a.k.a. “Python 3000” or “Py3k”) is a new version of the language that is incompatible with the 2.x line of releases. The language is mostly the same, but many details, especially how built-in objects like dictionaries and strings work, have changed considerably, and a lot of deprecated features have finally been removed. Also, the standard library has been reorganized in a few prominent places.’)

– http://jeremyhylton.blogspot.com/2008/12/python-3000.html (‘Python 3000 is ready! The official release may not come until tomorrow, but Barry has tagged the source and is preparing the release. We’ve been waiting for this release for almost nine years. The earliest reference I can find is a message from Guido to python-dev in Jan. 2000.’)

– http://sayspy.blogspot.com/2008/12/holy-crap-30-is-done.html (‘As Jeremy Hylton has pointed out, Python 3000 was first discussed nine years ago. When I first started following python-dev back in June 2002, Python 3000 was this somewhat mythical version that pretty much any idea that seemed somewhat reasonable somehow to someone was attached to. To an extent I viewed it as a joke for a while since the Py3K title was tossed about so loosely.’)

– http://regebro.wordpress.com/2008/12/04/python-30-released/ (‘1 minute before midnight according to the website, Python 3.0 was released. Yes, all the incompatibility tests still runs.’)

– http://blog.dscpl.com.au/2008/12/python-30-and-modwsgi.html (‘Now that Python 3.0 has been released, it is probably worth while pointing out that mod_wsgi has been ported to Python 3.0 for quite a while now. It didn’t always work, but that was actually because various versions of the Python 3.0 betas and release candidates managed to break support for sub interpreters. All these issues in Python 3.0 have been fixed now and mod_wsgi appears to be working fine for a basic WSGI test case. Of course, with Python 3.0 being so new and with the internal changes required to mod_wsgi to handle Unicode strings, there are no doubt some gremlins lurking in the mod_wsgi changes still. One can just hope that the WSGI folks out there don’t ignore Python 3.0 for too long and start on porting some stuff to Python 3.0. This will then give me some decent code on which to test out mod_wsgi support for Python 3.0.’)

– http://jessenoller.com/2008/12/04/python-30-some-multiprocessing-info-administrative-notes/ (‘So, first off – unless you’ve lived under a rock for the last 24 hours, you should know Python 3000 final is hot off the bit presses. This marks a huge milestone for the language, and major props are deserved to all of the python-core people who have spent so much time working on it.

Python 3000 marks an interesting point in the evolution of the language – we all know it is meant to clean up some of the warts of the python 2.x series. It’s designed and implemented knowing full well it breaks backwards compatibility – but I would argue it doesn’t fall in the black and white camp of revolution vs. evolution. In my mind, Python 3 actually falls right in the middle. Yes, it is revolutionary in the aspect that it breaks compatibility with 2, but it is not so significant a series of breakages that it falls outside of the evolutionary camp.’)

– http://plnews.org/posts/python_30_final_released_20081203_210004.html (‘Python 3.0 final has been released. Python is a portable, dynamic, object-oriented language. The new features are described in the “What’s New in Python 3.0” document. This release includes: the replacement of the print statement with the print() function, simplified rules for ordering comparisons, a new form for octal literals, binary literals, a single Unicode string type, function argument and return value annotations, the ‘nonlocal’ statement, a new ‘raise’ statement syntax, new reserved words, a new metaclass syntax, library updates, a new system for string formatting, new and removed builtins, changes to the C API, and other changes.’)

– http://holdenweb.blogspot.com/2008/12/python-30-is-out.html (‘I posted a short article a while ago about 3.0 (in)compatibility, but the differences between 2.6 and 3.0 aren’t so great. It’s perfectly possible to write 3.0 code that will run on 2.6 too, as most of the language hasn’t changed at all.

The preferred strategy for writing code that runs on both versions is to write in 2.6 and then apply the 2to3 converter and verify that it produces a correct 3.0 program. There’s no guarantee that it will, so you may need to paraphrase the 2.6 code a few times before you get a transatable program.

Once all the third-party modules you and extensions you rely on are 3.0-ready, and you no longer have clients requiring 2.6 version of your software, you can simply drop the 2.6 compatibility requirement and start to make use of the few 3.0-only constructs that have been introduced.’)

– http://rhodesmill.org/brandon/2008/comprehension-consistency-at-last-in-python-30/ (‘A new era is begun: Python 3.0 has been released, bringing the bright and burning lights of reason, consistency, and symmetry to bear on my favorite language. Guido van Rossum, the creator of Python, has carefully guided this final attempt to remove the warts that have accumulated over the language’s 17-year lifetime, and the result is magical.

Python 3.0 (r30:67503, Dec  4 2008, 10:23:44)
[GCC 4.3.2] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
>>>
>>> [ n*n for n in range(5) ]
[0, 1, 4, 9, 16]
>>>
>>> { n*n for n in range(5) }
{0, 1, 4, 16, 9}
>>>

>>> { n: n*n for n in range(5) }
{0: 0, 1: 1, 2: 4, 3: 9, 4: 16}

... After the aching and painful years of the Python 2 series, the language
once again shines bright and clear as a model of clever symmetries and
low mental impedance. Python’s famously tight “feature set” can, now
more easily than ever, fit comfortably into the programmer’s brain.')

Nov 18, 2008 4:49am

Autres liens

• http://www.python.org/ftp/python/3.0/Python-3.0.tar.bz2
• http://www.python.org/download/releases/2.6.1/
• http://wiki.python.org/moin/Early2to3Migrations

• http://mail.python.org/mailman/listinfo/python-porting  ('This list is to contain discussion of porting Python code between versions,mainly from Python 2.x to 3.x.')

• http://www.comp.leeds.ac.uk/nde/papers/teachpy3.html (‘In this paper, we explore some of the ways in which Python 3.0 improves on earlier versions of the language for the purpose of teaching programming. We highlight simplification of the type system and object model as improvements of particular significance, along with changes to some of Python’s operators and its built-in capabilities for console I/O. We also examine what adopters will need to do to make existing code examples run with Python 3.0, and discuss other obstacles to early adoption such as the lack of suitable of textbooks and delays in introducing support for Python 3.0 into third-party tools and frameworks.’)
• http://mail.python.org/pipermail/python-dev/2008-December/083920.html
  • Programming Language :: Python :: 2
  • Programming Language :: Python :: 2.3
  • Programming Language :: Python :: 2.4
  • Programming Language :: Python :: 2.5
  • Programming Language :: Python :: 2.6
  • Programming Language :: Python :: 2.7
  • Programming Language :: Python :: 3
  • Programming Language :: Python :: 3.0
  • Programming Language :: Python :: 3.1

Code source, gestionnaire de versions/code: mercurial, bazaar, git

Quelques informations concernant la gestion des programmes source sous GNU/Debian Ubuntu.

Comment obtenir les sources d’un programme sous Debian/Ubuntu ?
=========================================

Quand on installe une distribution Debian/Ubuntu nous avons un ensemble de logiciels sous forme de fichiers (ou paquets) binaires, la liste de ces « paquets » étant donné dans le fichier /etc/apt/sources.list. Si l’on veut consulter le code source correspondant à ces  programmes, il faudra:

• modifier le fichier /etc/apt/sources.list (sudo gtkedit /etc/apt/sources.list) en rajoutant pour chaque ligne commençant par « deb http://xxxx… » une ligne « deb-src http://xxx… ».
• lancer commande « sudo apt-get update » pour mettre à jour la liste des paquets.

Si l’on veut voir à quoi ressemble les sources de l’interpréteur python on se crée un répertoire ~/src/python par exemple et un simple « apt-get source python2.5 » suffira pour télécharger les sources. A cette occasion, on aura le message suivant:

Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
NOTE : l'empaquetage de 'python2.5' est maintenu dans le système de contrôle de version 'Bzr' à:
http://bazaar.launchpad.net/~doko/python/pkg2.5
Veuillez utiliser:
bzr get http://bazaar.launchpad.net/~doko/python/pkg2.5
pour télécharger les dernières mises à jours (probablement non publiées) de ce module.

On apprend donc que ce paquet Ubuntu est géré avec un logiciel de gestion de version distribué appelé ‘bazaar’ (petit nom :’ bzr’) ce logiciel étant écrit en python (faire un apt-get source bzr pour voir le code python).

Pourquoi vouloir obtenir le code source  d’un programme ?
==================================

• les logiciels libres/open source étant des logiciels de très bonne qualité, il est très intéressant de voir comment tel programme a été implémenté
• cela permet de contrôler le contenu d’un programme (absence de spywares par exemple) et/ou de faire une revue de code (http://en.wikipedia.org/wiki/Code_review)
• si on est très motivé, cela permet de participer au développement d’un logiciel ou si l’on n’est pas développeur de participer à sa documentation.

Les gestionnaires de versions
================

La participation à un projet open source implique l’utilisation d’un gestionnaire de versions. Depuis 2003 environ, CVS  est progressivement remplacé par subversion. Et depuis quelques moi, subversion est remplacé par des systèmes de gestion distribué tels que Mercurial (ou hg, écrit lui aussi en python), git (écrit par Linus Torwals), et bazaar.

Ainsi le langage python actuellement géré avec subversion pourrait passer sous bazaar ou mercurial:  http://www.python.org/dev/bazaar/ (« Python’s source code is maintained under the Subversion revision control system. We are experimenting with distributed revision control systems (dvcs) because of their greatly improved workflow, accessibility and merging facilities over Subversion. While there are several serious dvcs contenders in the open source world, this page describes the experimental Bazaar mirrors of the Python Subversion tree that we are making available to developers« )

A voir:

• http://en.wikipedia.org/wiki/Revision_control (« …Revision controlversion control (system) (VCS), source control(source) code management (SCM)) is the management of multiple revisions of the same unit of information. It is most commonly used in engineering and software development to manage ongoing development of digital documents like application source code, art resources such as blueprints or electronic models, and other projects that may be worked on by a team of people… « )

• http://fr.wikipedia.org/wiki/CVS (« …CVS, abréviation de Concurrent Versions System, est un système de gestion de versions libre, successeur de SCCS, originellement écrit par Dick Grune en 1986, puis complété par Brian Berliner (avec le programme cvs lui-même) en 1989, et par la suite amélioré par de très nombreux contributeurs…« )

• http://en.wikipedia.org/wiki/Git_(software) (« Git is a distributed revision control / software code management project created by Linus Torvalds, initially for the Linux kernel development…Git was designed as a set of programs written in C, and a number of shell scripts that provide wrappers around those programs.^[15] Although most of those scripts have been rewritten in C as part of an ongoing effort to port it to Microsoft Windows, the design remains, and it is easy to chain the components together to do other clever things« )
• http://git.or.cz/gitwiki/GitProjects
• http://linux.yyz.us/git-howto.html

• http://en.wikipedia.org/wiki/Mercurial_(software) (« …it is written in Python, with a binary diff implementation written in C. Mercurial is primarily a command line program. All its commands begin with hg, a reference to the chemical symbol for mercury…Mercurial was written to run on Linux. It has been ported to Windows, Mac OS X, and most other Unix-like systems. »)
• http://www.selenic.com/mercurial/wiki/index.cgi/ProjectsUsingMercurial

• http://en.wikipedia.org/wiki/Bazaar_(software) (« Bazaar (formerly Bazaar-NG) is a distributed revision control system sponsored by Canonical Ltd., designed to make it easier for anyone to contribute to free and open source software projects…Bazaar is written in the Python programming language, with packages for major LinuxMac OS X and Windows. Bazaar is free software and part of the distributions, GNU project…Bazaar has support for working with some other revision control systems.^[3] This allows users to branch from another system (such as Subversion), make local changes and commit them into a Bazaar branch, and then later merge them back into the other system. Bazaar has basic support for Subversion with the bzr-svn plugin.^[4] There is also beginnings of support for both Mercurial^[5] and Git.^[6] Currently these are not feature complete, but are complete enough to show a graphical history. »)
• http://bazaar-vcs.org/WhoUsesBzr
• http://wiki.list.org/display/DEV/MailmanOnLaunchpad (« The Mailman source code was originally maintained using CVS, and only a few people had write access to the code. Later, development was moved to SourceForge and then the CVS repository was converted to Subversion. This proved to be a successful transition, as Subversion provided many benefits over CVS.Now however, it’s become clear that even Subversion has its limitations, and better options exist. Specifically, we are now using the distributed (or decentralized) revision control system (dvcs) called Bazaar. Bazaar has many beneficial features, both for the core developers and for casual, third party developers. »)

Django news, svn, git, mercurial

> Models in Django are conceptually based on tables in a database. I’d like to enhance that with the introduction of resource-based models.The basic idea comes from Ruby on Rails’ ActiveResource, which allows
> for interaction between two sites through a RESTful API. I would like
> to take this a step further and provide an implementation of this type
> of interface not bound specifically to REST. The interface will be
> generic enough to allow for different types of sources.I couldn’t be more interested in a GSoC because that’s exactly what I
miss in Django. Thanks for proposing that project, I really hope it
will be accepted and count me on for extending the base with at least
RDFModel once you setup the base. I’m already dreaming of some kind of: class User(models.RDFModel):
user = whatever(DjangoUser.name)
# mmh, I need more time to think about the way to declare triples

class Meta:
source = sources.FOAFSource()

Good luck!

Cheers,
David

////////////////////////////////////

Of course, this’ll require better tooling — we’re going to need to make sure
these links all work and maintain them correctly. More documents means we need
better indexing, searching, etc. Luckily someone else already wrote the
perfect tool for the job; it’s called Sphinx (http://sphinx.pocoo.org/). It’ll
do everything I want, and more. I’m not interested in using different tools,
so let’s not discuss that. Suffice to say I’ve sketched out the code needed
and it’s perfect; all the hard work is going to be in actually
rewriting/moving around docs.

Right.How will I do this, you say? Here’s my plan:

* Using the outline from the existing documentation
(http://toys.jacobian.org/django/docoutline-r7392/), make a new outline and figure out where each bit fits into the new regime. This doesn’t need to be in any way perfect or 100% complete; just good enough to get started from.

– http://agiletesting.blogspot.com/2008/03/links-to-resources-from-pycon-talks.htmlI took some notes at the PyCon talks I’ve been to, and I’m gathering links to resources referenced in these talks. Hopefully they’ll be useful to somebody (I know they will be to me at least.) »MPI Cluster Programming with Python and Amazon EC2 » by Pete Skomoroch

* slides in PDF format
* Message Passing Interface (MPI) modules for Python: mpi4py, pympi
* ElasticWulf project (Beowulf-like setup on Amazon EC2)
* IPython1: parallel computing in Python
* EC2 gotchas

« Like Switching on the Light: Managing an Elastic Compute Cluster with Python » by George Belotsky

* S3FS: mount S3 as a local file system using Fuse (unstable)
* EC2UI: Firefox extension for managing EC2 clusters
* S3 Organizer: Firefox extension for managing S3 storage
* bundling an EC2 AMI and storing it to S3
* the boto library, which allows programmatic manipulation of Amazon Web services such as EC2, S3, SimpleDB etc. (a python-boto package is available for most Linux distributions too; for example ‘yum install python-boto)

* UML image repository

« PyTriton: building a petabyte storage system » by Jonathan Ellis

* All this was done at Mozy (online remote backup, now owned by EMC, just like Avamar, the company I used to work for)
* They maxed out Foundry load balancers, so they ended up using LVS + ipvsadm
* They used erasure coding for data integrity — rolled their own algorithm but Jonathan recommended that people use zfec developed by AllMyData
* An alternative to erasure coding would be to use RAID6, which is used by Carbonite

« Use Google Spreadsheets API to create a database in the cloud » by Jeffrey Scudder

* slides online
* APIs and documentation on google code

« Supervisor as a platform » by Chris McDonough and Mike Naberezny

* slides online
* supervisord home page

« Managing complexity (and testing) » by Matt Harrison

* slides online
* PyMetrics module for measuring the McCabe complexity of your code
* coverage module and figleaf module for measuring your code coverage

Resources from lightning talks

* bug.gd — online repository of solutions to bugs, backtraces, exceptions etc (you can easy_install bug.gd, then call error_help() after you get a traceback to try to get a solution)
* geopy — geocode package
* pvote.org — Ka-Ping Yee‘s electronic voting software in 460 lines of Python (see also Ping’s PhD dissertation on the topic of Building Reliable Voting Machine Software)
* bitsyblog — a minimalist approach to blog software

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

– http://weblog.rubyonrails.com/2008/4/2/rails-is-moving-from-svn-to-git (We’ve been preparing for Rails to move the official source repository from Subversion to Git for some time now and it seems that it’ll happen over the next week or so. The premiere will happen alongside the official launch of Github.

The move will also mean that we’re going to be switching ticket tracking to Lighthouse. So now both our repository and ticket tracking will be powered by Rails applications, which is a nice bonus treat.When the move happens, we’ll freeze the existing Subversion repository and the Trac installation. Both will live on for a long time to come, but will be entirely deprecated. This means that your existing svn:externals will not break, but if you want the latest edge, you’ll have to get it from the new git repository.

So now is a great time to learn more about Git in anticipation of this move. I recommend starting with the Git for SVN’ers crash course.

———————————————————————–

Mercurial and even bazaar is quite popular among rubysts than Git…

————————————————

Why Git and not Mercurial ? What’s all the Git hoopla about ?————————————————Although I do fully agree with punting SVN and moving to a distributed SCM, I don’t think that Git is the best solution for Rails. Git is fantastic no doubt, but its windows support is no where near Mercurial. Considering that Ruby on Rails is a platform independent framework, it would make sense to use something that plays nice for everybody.I’m not a windows user, but I’m sure there are still a few of them out there 🙂Also, the Mercurial command set is much more closer to SVN than Git, so the learning curve should be smaller.

Downsides to Mercurial: No peepcode show. And hghub.com isn’t ready. But guess what, turns out you don’t need either to get this working.

I’d highly recommend reconsidering your decision to move to Git and consider Mercurial as an alternative.

—————————————————-

Although I prefer mercurial slightly more, git and mercurial are so alike that trying to figure out which is superior is just a waste of time. It’s better to just quickly choose one (even randomly) and stick with it.

—————————————————-

Git is awesome, I’m not saying it isn’t. I still think Hg would fit better in this case, but since windows is in the minority here it really doesn’t matter.Getting a DSCM in there is the most important point, and I’m glad Rails is going in that direction.——————————————————————-

– http://www.technobabble.dk/2008/mar/06/exposing-calendar-events-using-icalendar-django/ (« I recently wrote simple abstraction for exposing calendar events in Django as iCalendar feeds. It relies on vobject for managing the formatting of the calendar file, so you will need this if you want to try it out. It is available in Debian in the python-vobject package. »)

– http://morethanseven.net/posts/why-the-webstandards-world-appears-to-be-choosing-django/ (« I’ve been noticing an interesting trend recently, not one I have any empirical evidence for mind, but one I though interesting non-the-less. Parts of the webstandards world appear to all be playing with Django. Part of this has been the odd mention down the pub, at barcamps or at SXSW this year. But the main source of information on the topic has been twitter. To name but a few I’ve seen tweets from Steve, Ross and Aral recently and Stuart and Cyril literally wont shut up about it.What’s interesting is that this didn’t happen with Rails, not in the corner of the pub that generally talks more about markup, javascript and CSS anyway. I’ve worked on a couple of Rails projects both personally and commercially, and I’ve just launched a little pet project build with django called doesyourapi. What follows is, to my mind, a few reasons why I think this trend exists and also why I think it will continue, at least for the time being…People: You can’t ignore the personal touch, and in Simon Willison and Stuart Langridge we already have two people who bridge the community and the web standards crowd, at least in the UK. Personal technology choices at least are often driven by personal correspondence. « )

– http://fi.am/entry/using-the-geonames-database-with-django/ (« I’ve been using the Geonames database with Django for a while, as part of the ffloat.it project (which will be launched soon, stay tuned ;)). I’ve done some preprocessing to the data, normalizing some bits and denormalizing others, but always aiming for the best speed…Just unzip django-geonames-0.1.zip and drop the geo application inside your project. Add it to your INSTALLED_APPS, syncdb and then go to the geo directory and run the geoimport.py script (you’ll need to specify database credentials and db name, run geoimport.py -h for help). I haven’t included any documentation for the models, but i think, more or less, they should be self explanatory. Don’t hesitate to ask any question, posting a comment to this entry »)

– http://code.google.com/p/django-wordpress-admin/ (« For those looking to migrate their self-hosted WordPress site to Django. This app will hook into the existing databases allowing management through Django’s admin interface and easy migration to a Django site. Built using manage.py inspectdb with some custom managers thrown in to separate out the different content that is all thrown into one big table (wp_posts). « )