Robert Steinback’s op-ed in the Miami Herald, Fear destroys what bin Laden could not is a very nicely written piece that makes an important point about one of the things that makes America great (individual liberty) and why we should be trying to defend that.
Archive for December, 2005Ian Landsman is right on in 4 Rules for the Practical Entrepreneur. This is a must-read for anyone considering making the jump to being a software product freelancer. Falling into Ian’s “visionary” category is fine as long as you know what you’re getting into. With Zesty News, I broke one of Ian’s rules: it’s a consumer product. Kinda. It appeals to both business and consumer users, so the question then becomes one of marketing and how you draw the business users in. I’ll be writing more about Zesty News soon (believe it or not). With TurboGears, it’s hard to even draw parallels with the kind of thing you just “go off and start”. I’m forging off into some new territory (for me) and it’ll be interesting to see where I end up.
Dec
20
2005
 
What is TurboGears not?Posted by: Kevin Dangoor in Product Management, Python, TurboGearsIn product management, the things you choose not to do are at least as important as the things you choose to do. Though it might seem like adding features is always a good thing, there are actually tradeoffs being made with each feature added. Consider my cell phone (a Nokia Series 60): this thing can do many different things. It keeps my contacts, has games, takes pictures and can wake me up via its alarm clock. Because it has so many features, I have to do *a lot* of clicking around to set an alarm on the alarm clock. If the phone had fewer features, the user experience could be optimized better for setting alarms. In an open source project, having an idea of what your product truly is becomes critical. Many people will have patches or apparently complementary projects that are ready and free for the taking. But, should you take them? Numerous times along the way, people have asked about using “template package X” or “database thingy Y” with TurboGears. There have been thoughts of making TurboGears abstract away some of the underlying pieces so that they can be swapped out. (My responses have been that TurboGears shouldn’t stand in the way of using those other packages, but TurboGears itself will not directly support them.) If what you want is to pick and choose every piece of the application stack, then the web framework you want is CherryPy or, I guess, one of the other controller frameworks. If one tried to support everything in order to become the web framework “to rule them all”, you’d eventually end up with just Python (or some hideous layer on top of Python) and the current collection of fine components available for Python. TurboGears is not going to go that route. Here are the overarching thoughts that go in to TurboGears’ evolution:
I want to start with and maintain use of the “best-of-breed” components for each part of the stack. If you use great quality ingredients, you’ll get a great tasting cake. Of course, “best” is in the eye of the beholder. Often, two components may be equally capable, but have a different feel. That’s when you get into a more subjective area which makes the second rule that much more important: rather than punting when faced with two nearly equal choices, pick one and run with it. I can’t overstate the importance of TurboGears providing “one obvious way to do it” (at least when it comes to the big picture items). Let’s say that TurboGears specifically supported several templating packages (and there are certainly several to choose from in Python). The documentation would balloon, because it would have to cover both. The users would somehow have to have a basis for choice and the mailing list will get frequent questions of “which one should I use?”. Email traffic related to template issues would likely double. Features like internationalization would need to account for both. And, the path to adding more features that integrate multiple components would be a lot less clear. The new TurboGears widgets package uses Kid to power the appearance of the widgets. The Toolbox makes full use of all of TurboGears’ components. Am I saying it’s always wrong to provide a choice? No. But, if there is going to be a choice, there has to be a good reason for it. If it’s a specific use case that one tool handles tremendously better than another, document that use case and encourage people to use the right tool for the job. If it’s a case where one component is far better overall, but is just missing a feature that another has, maybe it’s better to try to build that feature into the component of choice. Wouldn’t some people be turned away if you don’t support the exact component they want to use? Sure. But, expending the effort to support that rather than truly enhancing the user experience will cost far more users than simply not supporting one group’s preference. An example of this is alternative database technologies. Python has quite a few interesting non-relational databases available. There are certainly applications for which those databases make life easier. And, you can even use those technologies with TurboGears, just without special tool support. But, for the vast majority of people writing web applications today, relational databases are the primary storage option and which means that providing optimum support for relational databases is key. Providing support in TurboGears for non-relational databases would muddy the waters considerably. (Would CatWalk have to support those other tools? How about the tg-admin command line tool?) You could end up with half-baked support for a whole bunch of things rather than robust support for the “best-of-breed” toolset. Note that I’m not saying that TurboGears won’t have plugin support to allow people to mix in other components. The balance being struck here is that TurboGears provides a distinct way to get things done. If you agree in general with the TurboGears approach, but have some specific unusual needs you want to meet, TurboGears should at least try provide a reasonable way to meet those needs while you use the rest of the framework. The “reasonable way” to meet those other needs cannot conflict with the primary tools being used, however. One more point about when to say “no”: Good ideas come along all the time. At some point, you’ve just gotta ship it. Particularly with software, “good enough” today is worth a lot more than “perfect” at some distant point in the future. 1.0 is not the end, but just the beginning. TurboGears as envisioned and implemented can meet a wide variety of web app needs in a way that many people find fun to use. It’s impossible to make a framework that makes everyone happy, and to try would mean creating a framework that ultimately makes no one truly happy. Ruby’s rise seems to have some people in the world of Python nervous. Without question, Ruby’s increase in popularity can be largely attributed to Ruby on Rails. Though I could be wrong, it seems like many Python people look at the fine bits of code that exist for Python and think “Python can do that! The only reason Ruby is getting users is because there’s only one web framework to use”. This thought then gets extrapolated to the notion that we in Pythonland need to somehow create one web framework “to rule them all”. Ruby gets some converts who like the way the language works: “Perl, only better” or features like Ruby’s blocks. Or, maybe those people don’t like Python’s significant whitespace. Whatever the reason, creating a Python web framework to rule them all is not going to change the minds of these people because they’re picking up Ruby for Ruby, not for Rails. So, eliminating those folks from discussion, I guess the thinking is that people are moving from language J with framework S to Ruby On Rails because Ruby has only one framework to choose from. Of course, that’s not even true: there are several web frameworks for Ruby. Ruby on Rails is just the largest and best known. People aren’t choosing Ruby over Python because Ruby has one obvious choice for a web framework. People are choosing Ruby On Rails because it will help them get their projects done, and they know it will help them get their projects done. Java, as a language/platform, has been quite successful despite having a variety of ways to write webapps: servlets, JSP, Struts, Tapestry, WebWork, JSF, etc. People aren’t migrating to Ruby because they’re tired of having to choose a web framework. People are choosing Rails because it’ll get the job done faster than the technologies they were using in Java. It all boils down to user experience. In the case of a web application framework, the user is a developer of webapps. Anything you can do to make the developer’s life easier will win users: better and easier APIs, convenient tools and better docs are three examples. There’s no “official” backing for TurboGears, and it didn’t come out of a committee of Pythonistas trying to achieve world domination by “creating” the “One Framework”. And yet, TurboGears is gaining users, many of whom are refugees from PHP and Java projects. This is purely market forces at work: people are coming to TurboGears and Python because they meet a need and at a reasonable cost (and if you don’t think open source web frameworks have a cost, I think that’s a good topic for another article). As with Rails, people come to the website, learn about the project and gain confidence that the TurboGears will meet their needs now and in the future. In a nutshell: if it makes sense for Python to have one dominant web framework, it will happen naturally through the choices people make every day when deciding how to get a project done. Rather than spending my time thinking about how to create the Python web framework to rule them all, I’m spending my time doing whatever I can to make writing webapps easier. It’s official! After a month of discussions with two different publishers (both of We’re working with Mark Taub, who has experience publishing books for We’re grateful for the positive reviews and useful input our proposal
Dec
13
2005
Tasty - a REST tagging engine built on TurboGearsPosted by: Kevin Dangoor in Software Development, TurboGearsWho would’ve thought: open source projects have real people with real lives behind them. TurboGears contributor Jeff Watkins (responsible for the identity package) is now a father! Congrats to Jeff and his wife and best wishes! TurboGears Latest (December 7, 2005)
========================= TurboGears http://www.turbogears.org Wiki/issue tracking: TurboGears Feeds: http://planet.turbogears.org Mailing lists: Primary (818 members, high traffic): Announcements (314 members, low traffic): Repository commits: Sprint coordination:
Dec
07
2005
admi18n: Painless localization for TurboGearsPosted by: Kevin Dangoor in Python, TurboGearsRonald Jaramillo doesn’t tell me anything. He certainly didn’t tell me that he was going to build a GUI for TurboGears i18n: admi18n: Painless localization in 10 steps. Dan Jacob has been hard at work getting core i18n support for TurboGears (and that’s looking pretty nicely baked at this point). Ronald’s admi18n is a TurboGears 0.9 Toolbox GUI for simplifying the process of extracting strings and creating message files and translations for your app. Great job, guys! I’m planning to go to tomorrow’s Atlanta Python December Meetup. I’m surprised that only 3 people are RSVPed as yes. The Michigan Python Users Group has gotten 8 people or more for its meetings. If you’re in Atlanta, stop in and say ‘hi’! I’d like to meet some more folks while I’m down here. |
|
Entries (RSS)