Skip to content

Pyroma 1.3.1 released

Update: After another bug report I realized I didn’t have a check that there are distributions uploaded to the Cheeseshop. This despite being a pet peeve of mine that people don’t upload distributions to the Cheeseshop. So I released 1.4, with an additional check for this.

Pyroma rhymes with aroma, and is a product aimed at giving a rating of how well a Python project complies with the best practices of the Python packaging ecosystem, primarily PyPI, pip, Distribute etc, as well as a list of issues that could be improved.

The aim of this is both to help people make a project that is nice and usable, but also to improve the quality of Python third-party software, making it easier and more enjoyable to use the vast array of available modules for Python.

Pyroma 1.3.1 fixes a small bug and improves the integration with zest.releaser for a smoother release experience.

tzlocal 1.0 released

tzlocal is a module that tries to deduce what your local time zone is from your operating systems configuration, and returns a pytz timezone object.

It supports Python 2.5, 2.6, 2.7, 3.1, 3.2 and 3.3, as well as Jython and PyPy.

Version 1.0 adds a couple of bug fixes, mainly related to giving better error messages when deducing the time zone fails.

My defunct modules

I’ve gone through my modules on the CheeseShop and made sure the information about them is up to date. Most importantly, I’ve marked the following modules as “Development Status :: 7 – Inactive“:

  • calcore: This is a module that Martijn Faassen and me write that has the Python core of a calendaring system. It was pretty nice, but only ever used by Nuxeo.
  • collective.portlet.quote: Shows random quotes in a portlets, chosen from quotes in a folder. I developed this for project at Jarn.
  • megrok.genshi: Genshi template support for Grok. Mostly it was used as use case for making Grok support other templates. I don’t think nobody ever used it, though.
  • p4a.calendar: This module, originally by Rocky Burt (I think) once contained views for p4a.plonecalendar, but the project since a long time uses dateable.chronos instead.

I don’t think anyone is actually using these packages any more, but if you do, please tell me and you can take over maintenance.

svg.path 1.0 released

svg.path is a collection of objects that implement the different path commands in SVG, and a parser for SVG path definitions. It supports Python 2.6 to 3.3.

It’s main use is to parse an SVG path specification and then you can extract points on that path. You can also easily manipulate the path, but 1.0 doesn’t contain support to render paths back to SVG specs. I hope to get time for this in the future, contributions are welcome.

svg.path 1.0 fixes a bug when handling path specifications that use no spaces and have negative numbers.

svg.path is put into an svg.namespace to allow for other modules using the same principles that can handle other parts of the SVG spec. I currently have no need for anything than the path bit of the specifications, but other modules are welcome there as well. Please contact me to make sure the API follows the same principles so that the modules are easily inoperable.

blog.star 1.2 released

collective.blog.*, or just blog.star for short, is a suite of blogging modules for Plone. It is primarily designed for integrators. Most people who use Plone for blogging also uses Plone as a customized content management system, and they have specific requirements and their own skin, custom content types and other integrations. It turned out that other Plone blogging products make a lot of assumption about how you are to use it, what you want from a blog, and how your site is set up. The blog.star modules are modular, make few assumptions and reuse already existing technology as far as possible.

blog.star 1.2’s main feature is that it now supports Plone 4.3. This has in some cases required quite big changes. For example, collective.blog.feeds will under Plone 4.3 rely on Plone 4.3’s built-in Syndication functionality. collective.blog.view also has quite substantial changes.

Language support is also vastly improved, but many of the latest features has created new strings which remain untranslated, help with updating translations and adding new translations are appreciated.

 

It’s been far too long since I released a new version of blog.star, which is entirely because of lack of time. If somebody is interested in taking over maintenance, email me.

p4a.plonecalendar 2.1 released

p4a.plonecalendar is a calendar for Plone. Mainly it is a set of calendaring views whose main feature is that can be used without Javascript.

Version 2.1’s main feature is that it adds Plone 4.3 support.

Development workflow and architecture

Back in the stone-age, when I started programming, the main development paradigms was “bottom-up” or “top-down”. Essentially, if you created the overall structure of the program first, and then started filling out details, or did you implement low-level functions first and then composited them together.

I never did any of those, I tended to do “start-finish”, I start with the first thing that needed to happen in the program and go from there. It was hard to get it into a “workflow” of things to do that resulted in anything else. So I shunted the whole idea of “bottom-up” or “top-down” to the side, and apparently so did everyone else because people stopped talking about it. I also think that many frameworks enforce their own workflow on things, so it’s therefore become less relevant because if this.

The last few years I have however found myself doing a lot of bottom-up development, and that’s because my tool kit now includes test-driven-development (TDD)

My workflow currently looks more or less like this: I fiddle around, test things, look at what others have done and use it if I like it. If I don’t like it I do a bit of rough “start-finish” development until I start getting the “feel” for what I’m doing and a rough idea of what I need.

Then I start a new module, and use TDD (more or less). And since I use TDD, and need something that is easy to test, and that results in a bottom-up modular approach where classes tend to be very independent of each other and their environment, simply because that makes them easy to test. It wouldn’t be possible, at least for me, to do this unless I had a clear idea of what I want, which means trying it out first. But in the end, once I start the module and the tests, even though I usually end up copying in what I already had, this quickly tend to get thrown out.

But the end result is that TDD makes me a better programmer, and makes me write code that is clearer and more modular and can be refactored more easily. And this is because TDD more or less forced me to write bottom-up. So maybe that paradigm was less irrelevant than I thought.

About finding a contractor to build your website

Once again I have been contacted by a consulting firm who asks if I can help them with some specific problem. Some quick poking reveals that the problem is that they are trying to develop a site in Python with Plone, and that they don’t know either Python or Plone. However, since they know ASP or PHP, they simply have assumed that they can do this, because it has to be the same, right? It’s just the same principals but another language?

Well, no it isn’t. And the end result is that they have problems, because they are doing things they should not be doing. And the way to fix those problems, is to stop doing it.

I’ve told them that they have two options:

  1. Hire somebody to teach them Python and Plone and Plone development, which will probably encompass at least two weeks of education for all of their developers, and even after that they will be very inefficient and it will take a long time to make the site.
  2. Cut their losses, tell their customer that they can’t do it, and take the hit of not getting paid for the effort they have put in so far.

I’m sure this hurts, but it’s true. Python is not like PHP or ASP, and Plone is not a web framework, it is a content management application. You can’t start using either without some investment in learning the technology. And there is another lesson here too: When a company tells you they can implement a complex website for a pittance, be prepared that what they come up with is no good. Assuming they come up with anything at all, that is.

Hire a contractor who knows the technology that is selected and is recommended by other people who also knows the technology that is selected. Yes, that will cost more. You won’t be able to hire the $25 per hour guys. But trust me: It is cheaper in the long run. Quality pays, and this is true also for contractors.

Discussion: Massively parallell CMS?

I’ve been thinking a lot about this lately, and I realize this is probably a question that can only be answered by actually trying, but still, I think it’s an interesting discussion to be had.

To what extent would it be useful to make a web application, such as a CMS, massively parallell? (or for that matter, concurrent, see comments)

And with that I mean, would it make sense to break the typical one thread per request model? Could we break it up so that fetching from the database is made in different threads or processes than rendering the template? Could the rendering be split up into smaller bits, so that parts of the template could be rendered while the data is still being fetched from the database? Are there other things that could be split up and made parallel?

Porting to Python 3 now available as PDF!

Front coverYou can now buy Porting to Python 3 as PDF, and enjoy it even when you are offline!

You’ll get a ZIP file with three PDF’s, one made for a typical computer/laptop screen and printer, with nice big margins. It will print well on both A4 and Letter paper. Another PDF is formatted to fit well when reading on a tablet, and the last one is made as small as possible, so you can read it on your smartphone.

All three PDF’s for the low price of $12.

Follow

Get every new post delivered to your Inbox.

Join 1,315 other followers