Category: Content Management

I’ve been updating my python/plone weblogs on my bloglines account. Here’s some great things I’ve been finding:

Ian Bicking on why web programming is important for python. Lots of comments. Ludo responds to the charge that php is better than python:

The key PHP advantage is, in my opinion, just one: the tight integration with Apache, and the flexibility it gives you in deciding where your code goes and how it gets executed. The ability to scatter a bunch of PHP files around, to use a hierarchy of directories, to put “static” content alongside your code, those are the features that make PHP web programming a joy. Oh, and PHP’s speed, which seems to be far greater than Python’s at web apps.

In all other respects, Python beats PHP hands down: code quality and functionalities available in the included libraries, design cleanliness, unified DB API, namespaces, proper types, the list could go on for half a page.

A review of 6 Python IDEs. Conclusion?

I still think Komodo Personal is a good deal, but today I would go with Wingware Personal ($35) instead, primarily on the strength of its better code completion support, “Go to definition” feature, and Source Assistant. Superior Emacs emulation (superior to just about any other non-Emacs editor I’ve ever used, actually; I suspect Wingware has at least one Emacs refugee) seals the deal. A few days ago, I ordered Wing IDE Professional (paid for by my boss). If you need an integrated GUI builder, or you have an older machine, Komodo remains a good choice, although not many people these days would pick Tk as their first choice for a GUI toolkit. Of the free choices, PyDev is the clear choice if you have Eclipse experience. If not, well, the situation isn’t pretty. Perhaps you’ll have better luck with one of the IDEs we didn’t review here.

On a similar note, here’s a post by Wolfram of Pythoneer wishing that HTML editors could “dive into” css files and js files when they are referenced in html files. This is a good idea, and actually the reason why I do more editing within my CSS editor than my html editor nowadays. Actually my workflow for creating static HTML pages is very peculiar. I type them normally in my NoteTabLight editor, open up HTML kit HTML editor, use a plugin to add tags everywhere, cut and paste them into Oxygen XML editor, validate the file and then I spend the rest of my time doing layout in my excellent CSS Editor. Pretty strange, eh? Thank goodness I’m not editing static pages too often.

Web 2.0 Stereotypes.

– Name that consists of a number and a word. (37signals did it for their company, and 43places did it for their site. That’s enough.)

– Blatant rip off of font and style from everything from 37signals.

– Ruby on Rails. (PHP is good enough for Flickr, remember).

– Yellow background appearing then fading out whenever something changes.

– Submit buttons that grey out and say “please wait” when you click them.

Hacknot warns people about wikophilia:

Wikiphilia: A mental illness characterized by the irrational conviction that any problem faced by a group can be rendered solvable through installation and use of a Wiki. This delusional ailment has been occurring in increasing numbers ever since it was first identified in 1995. Wikiphilia usually manifests in two distinct phases – the rapturous anticipation of the Wiki’s potential in the short post-installation phase; slowly giving way to denial of the Wiki’s failure to fulfill that potential in the second phase.

Hacknot has written some remarkable essays about software design. Here’s an essay about confirmation bias in software testing. Here’s his take on dialog boxes. And on the art of the flame war, he says:

Responses you give while angry are likely to be poorly considered, so it is invaluable to have techniques at your disposal to moderate that anger so that you can argue at your best and even begin to enjoy the dispute. Here are a few techniques that might be useful:

* When you’re not arguing in real-time (e.g. via email or discussion forums), print out the email or message that you’ve found inflammatory. Read it somewhere away from the computer and plan how you will respond. Delay making your actual response as long as possible.
* When arguing in person, make a deliberate effort to slow down the pace of the discussion and lower its volume. If you’re uncomfortable with the silence created, adopt a thoughtful expression and pretend to be considering your reply carefully. Use the time created to take a few deep breaths and calm down.
* Adopt a different mental posture towards the email or message. Pretend that the message is for someone else. This helps to de-personalize the argument and put it at a distance.

Realizing that your opponent is a susceptible to emotion as you are, you may choose to use this to your advantage. Here we venture out of the realm of the logical and into the rhetorical. If you can identify your opponent’s “hot buttons”, then you may be able to goad them into making an unconsidered response. Once made, the response cannot be retracted and you may be able to play that advantage for the remainder of the argument. When being inflammatory or provocative, be careful not to overdo it. Lest you appear vitriolic or juvenile, make your barbs short and well targeted. Ensure that they are offered as parenthetical asides rather than as a basis for argument.

Matt Harrison on how to create a passport photo with gimp (Note the links on the panela blog are iffy; I’m providing dates just in case). His Sept 13 give his thoughts on Cinelerra and its forking, and what it reveals about open source software. Here’s a discussion of why the overwhelming majority of open source bring Mac laptops to developer conferences. (I’ve noticed that too; I find it incredible).

Ehud Lamm on how to read a paper. Perhaps it is absurd to consider the topic, but I think what he means is reading an academic technical paper.

Mark-Jason Dominus on why he hates advocacy of computer languages.

n that talk I discussed the Pascal type system at some length. There was only one reason that I brought up Pascal. I needed to convince people that type systems have moved forward a little since the invention of Pascal in 1968. I had found from many years of experience that when I mentioned strong typing, people would frequently say “You must be kidding. Pascal sucks.” I knew that if I did not address Pascal, people would be unpersuaded by my talk—they might go home thinking I was advocating Pascal as soon as I mentioned strong typing. So I spent a lot of time discussing the particular failures of the Pascal type system so that I could show how these problems are surmountable—Pascal is not the be-all and end-all of strong typing, as many people think. I discussed C at the same time, because the C and Pascal type systems are so similar, and I did not want people to think I was singling out Pascal.

Nevertheless, several people have written to me to complain that my talk was ‘unfair to Pascal’. They saw the talk as an attack on their favorite language. I don’t understand this. Even if the talk had been about Pascal, which it wasn’t, it couldn’t have been an attack, because I only told the truth about Pascal. The Pascal type system does have big problems, many of which were corrected in various incompatible ways by various vendors, and many of which were corrected by Wirth, the inventor of Pascal, in his later languages.

You can be ‘unfair’ to a person, and you can hurt their feelings, even if you tell only the truth. But Pascal is a programming language, not a person. It has no feelings to hurt. Criticizing Pascal’s type system is like complaining that your hammer has a scratched face. There is no use getting upset about it. You just have to get a new hammer or make do. Saying that the criticism is unfair to the hammer, for whatever reason, is just silly.

He concludes:

I think the root of the problem is that we tend to organize ourselves into tribes. Then people in the tribe are our friends, and people outside are our enemies. I think it happens like this: Someone uses Perl, and likes it, and then they use it some more. But then something strange happens. They start to identify themselves with Perl, as if Perl were part of their body, or vice versa. They’re part of the Big Perl Tribe. They want other people to join the Tribe. If they meet someone who doesn’t like Perl, it’s an insult to the Tribe and a personal affront to them.

I think that explains the reaction of the folks who wrote to me to complain about my unfairness to Pascal. I think maybe they took it personally, and felt that I was being unfair to them.

Getting yourself confused with a programming language isn’t a sane thing to do, but a lot of people do it, including people from our community.

(BTW, Lisp rocks! Long live Lisp!)

Guido von Rossum compares the continuity obligations of Harry Potter to the backward compatibility requirements of a programming language.

Werner Schultz makes a lucid remark in the comments:

Part of the problem stems from the “Worse is better” school of programming language development. People start off with a language but don’t spend enough effort to boil things down to as few concepts as possible. Seems to me that Smalltalk and Ruby are still the best, but not perfect, examples of language design.

I think it also a mistake to regard a programming language as a language for a specific purpose. It may have started from the need to solve a particular problem, but a language will always spread far beyond its original domain. Your design must stand up to that. It is impossible to cover all potentialities but by laying a good foundation it will be much easier.

A basic rule: Be as restrictive as possible in the beginning, only permit as little as possible. It is much easier to relax the rules later than to restrict them. This avoids a lot of backward compatibility problems.

Example: Java interfaces imply that all methods are public abstract and many coding standards advise against supplying the superfluous keywords. This is actually inconsistent since no access specifier implies package visibility in Java. This also means it is difficult to extend the interface concept later to include more fine-grained access rights a la Eiffel.

This reminds me of a quote by Mark Twain (or some other wit) who apologized for the prolixity of his letter because he did not have the time to make it short. Here’s one thing that programmers, mathmaticians and novelists can appreciate: brevity.

Pybloglines, a tool for accessing bloglines. BTW, this monster post comes from browsing through bookmarks of other people’s bloglines.

Everything I Need to Know about Web Design I learned from Wizard of Oz (by Brian Alvey):

At last year�s GEL conference, Stuart Butterfield gave a fantastic presentation on constraints and their effects on creativity. He launched the 5k competition in 2000, challenging web developers to create the most innovative and stunning web sites � using files that totaled less than 5,120 bytes.

Butterfield explained that constraints can be found everywhere in music, architecture, poetry and design. Adding constraints to a project motivates artists to come up with more creative solutions to the design problem at hand. Extreme constraints like �48-hour filmmaking,� �three-day novel writing,� �Bush in 30 Seconds� and the 5k contest can lead artists to extreme creations.

Every new web design is the solution to a design problem that can be summed up in a series of constraint questions: Who is my audience? What am I trying to get them to do? How do I want them to feel about this site? What browsers and platforms are we targeting? Can I use Flash?

Jeffrey Zeldman agrees (in describing the results of the 5k contest). Unfortunately, the 5k winners’ site is offline, but here are some of the entries

Om Malik on Switching Costs

During Internet 1.0, AOL was the master of creating high switching costs. Using the email address as the cornerstone, they were able to lock-in their subscribers into a garden with very high walls. In fact, they locked up the gates so well that there are still 20+ million people who subscribe to AOL�s dial-up service (which, consequently, enables AOL to generate more annual revenues than either Yahoo! or Google, to this day). Even at a time when broadband access is oftentimes less expensive, their subscribers are hesitant to switch away from their AOL email addresses.

But in a world where people themselves are increasingly becoming the sources of content and the owners of distribution, any product development strategy that aims to proactively increase switching costs becomes antithetical to the gravitational pull of the market (as AOL is now painfully experiencing). In fact, in many markets, we are likely to see an inversion of control, where vendors will increasingly rely on their customers to provide them with their strategic and competitive advantages. Put another way, the tail will start wagging the dog.

So in such an open and unpredictable environment of consumer control, what happens to the notion of switching costs? The answer, on its surface, is actually quite simple. The importances of switching costs do not disappear. They will always remain a critical success factor for building market share and defending against competition. What does change, however, is who creates and controls it.

It won�t be the corporation that locks its customers into a walled garden any more; instead, it will be the people themselves who create their own high switching costs. For instance, if you are an eBay seller, your switching cost is not so much the relationship you�ve created with eBay itself and the store you set up, it�s the reputation and trust you spent years building with fellow members of the community. Similarly, if you are a member of MySpace, it�s not the web-page and blog you spent time constructing, it�s your social network of cyber-friends you�ve cultivated and accumulated over time.

At the end, the lesson is one of a paradox. As the power shifts increasingly towards community, the corporation loses its grip on the traditional means of control. Yet, by letting go of control, the corporation creates an environment where the community willingly creates its own switching costs. Such changing market behavior, which is structural and permanent for any industry being usurped by the Internet, must be met with a corresponding shift in corporate mindset. Otherwise, a �generation gap� will exist between the members of management themselves (old vs. new media), as well as the company and its market. In my view, if there is one company that seems to grok such dynamics better than anyone, and is in the process of executing superbly against these new set of challenges, it�s Yahoo!

Python Paradox and the Jobs Market by Jeremy Jones. This is a bit of a troll post, but the fact remains that corporations impose a set of tools and they seek warm bodies to use them. One can only hope that the habits and skills these warm bodies pick up is sufficient to help them develop outside interests. The only way to have complete freedom is to go out on your own and make your own solutions. At a plone conference a few years ago, I heard a developer comment that customers didn’t really understand or care about what the web backend of their CMS was; they just wanted to see if it worked. On the other hand, there are real mindset differences between corporations and open source. The last two companies I have worked for use IIS/ASP/SQL Server, and the specific syntax and coding doesn’t really help you with outside projects. Who on earth can afford an IIS server license or a SQL Server license? On the other hand, learning postgresql or some language that is not singularly controlled by a corporation does have payoffs.