December 9th, 2009 by Mark Ramm
At geek.net we’ve been using MongoDB on various projects for the last six months or so. We finally re-factored out our MongoDB related code and created a new library. It’s battle tested on the project pages of sourceforge.net, and it’s getting a workout in my new project (no details on that yet).
One thing we learned is that you have to enforce some stuff on the Python side of the world in order to make working with totally schema free data stores easier.
So, just like in Flash Gordan, we’ve got Ming to rule Mongo.
Rick’s blogged about it at length here:
http://blog.pythonisito.com/
And all I can say, is that I’m very happy with Ming as it is now, and it’s meeting our needs quite well. We are of course open to suggestions, and we’re hoping that we can open up more stuff as we go.
If you want to see the details, they can be found on the (of course) sourceforge.net site:
If you’re looking for a larger exampel of Ming in actin Chris Perkins (coding machine that he is) and some other TurboGears devs are already looking at building a content management system with Ming and tg2:
http://bitbucket.org/percious/c5t/
If you use Ming, and like it, feel free to let us know.
December 9th, 2009 by Mark Ramm
I’ve been thinking a lot about template engines in Python recently. Partly because sourceforge.net’s new python code needed to choose a template language, and there were some questions about why we would choose one over the others.
But beyond that In the past few weeks used Genshi, Mako, Jinja, Django Templates, and Cheetah, and have been looking at, but not yet using out chameleon.genshi.
I figure all this promiscuous template library usage means that I should put my thoughts down somewhere. There are advantages and disadvantages of all these libraries, but I think that the choices are pretty clear once you know your constraints.
I’m not going to commit to covering them all in depth, but I’m going to try to put my thoughts about them down over the next few days.
For today let’s talk about the pros and cons of Django Templates. This is another post that has been developed over the last year or so, where typed stuff up while working on fossfor.us.
Django made making fossfor.us easy in lots of ways. Want threaded comments? Add the existing app in a couple hours — Done! Want OpenID? Again add an app — Done!
But it also had frustrations, and one of the biggest for me was the template language.
Continue reading ‘Python Template languages (Part 1 — Django)’
December 2nd, 2009 by Mark Ramm
I recently read Seth G’s book “the dip” which I’ve heard described variously as a book about choosing your battles, a book about quitting, or a book about mastery.
And it is about all those things. Because all those things revolve around a central idea:
sometimes things get harder before they get easier.
That “harder” is what Seth calls the dip.
And it is is difficult, but it’s also important because it makes being on the other side more valuable — after all not just anybody is willing to work their way through that dip.
For Seth, there’s obviously a lot about marketing, and reaching a wide audience. Obviously, it takes work to develop a new skill, grow a network of helpful people, or sell a new product. But given that our economy is “dipping” and that many of us have personal dips to work through, I’m finding Seth’s message very timely and relevant at the moment.
Getting through the dip is about the choices you make
If you’re like me and the people I know in southeast michigan, you are actually facing multiple “dips” at once. We are struggling our way through problems at work, financial problems, interpersonal problems, and we’re trying to figure out what to do about all those things.
One of the core ideas in “The Dip” is that you have to choose which battles you will fight, or you’ll loose them all. Some battles beg to be lost. You have to give up fighting on some fronts in order to win on others.
So, to go back to yesterday’s post, you have to say No to some things, in order to make it through any of the dips. You can’t have everything, you have to choose. And once you choose, you have to make it happen.
December 1st, 2009 by Mark Ramm
It’s easy enough to say that you don’t have enough time, but the reality is that time is the medium in which we live. Complaining you don’t have enough time very much like a fish complaining that he doesn’t have enough water. So, rather than complaining about the amount of time I have, I’ve been learning to think about my time management issues differently.
Where David Allen lead me wrong
The first insight I had is that Getting Things Done (GTD) has steared me wrong. This is hard to say because I think it’s a great book with a lot of great insights. In particular the strong admonition to get everything you need to do down on paper has changed the way I live and think. That list includes all the major and minor commitments I’ve made, and having it out of my head and in a system that I trust reduced my stress levels imensely.
But I found that I still have a lot of stress. And I found that I was still thrashing back and forth between projects without making the kind of decisive progress on any of them that I wanted to.
Why wasn’t the GTD process enough?
Because, as I eventually learned the GTD “inbox processing” strategy as described in the book is broken. You are supposed to choose between three options for each input: do it, deligate it, or defer it. But really there’s a key fourth option that is the really important one if you’re life is anything like mine.
What is that all important forth option?
- Don’t do it. Say no. Avoid adding another commitment to your list.
Wait, there’s science behind this!
This is really critical because like any queue that’s processed by a limited resource (in this case my time and attention) filling it too full actually causes the system to break down. This process of breakdown even has a technical name that feels exactly right, it’s called “thrashing.”
Every programmer and computer user knows what this is like. Open too many apps at once, and your machine grinds to a halt, data keeps getting swapped out to disk and the rate at which the machine can process information goes down exponentially.
Ok, so know I knew the name for my problem. Naming it is good, but it’s not the solution.
So, how do I stop thrashing about and get stuff done?
At some point, i’m not exactly sure where, I had a realization that in life, just like a manufacturing line, or a software resource issue, there are two keys to preventing thrashing.
- Avoid too much multitasking. A system spends time switching between tasks and is less efficent when time-windows for work are too small, and task-switching happens too often.
- When multiple commitments are being made that require real-time or near real-time responses, you have to keep the task-switching window short enough that high-priority tasks can be scheduled immediately. This, of course, creates a tension with the first principle which suggests larger time windows between task-switching.
This is where Getting Things Done’s todo list system provided me with a lot of help. It helped me reduce my task-switching costs, and that’s allowed me to get a better balance on these two pressures.
Letting the work FLOW
I think there’s a very clear analogy with what happened at Toyota in the early days. Manufacturers had die presses which took a long time to change, so they would run them for a long time. This was great in that it helped keep the machine working and limited the downtime. But it also meant that there were long delays in the system since the switching time and the time for the long runs added up. Toyota decided that since they couldn’t afford more machines, they needed to figure out ways to reduce the cost of switching, which reduced total cycle time, made them more responsive to bugs (quality problems) and helped them to get more done in less time.
Reducing the cost of switching made it possible for the system to run differently, rather than batching up lots of work and pushing it through, it Toyota discovered that you could pull what you needed through the system just in time. This same thing works for time management, when you aren’t overloaded you can be more responsive to today’s needs, and you avoid the inevitable mismatches that come with long delays between request and response.
What happens when there’s still too much to do?
But, to come back to my main point, even when you’ve done everything you can do to reduce the task-switching costs, you still can have significant thrashing problems when the resource (that’s you or me) gets overscheduled.
Most projects I’ve worked on ended up in this situation at some point, where working harder stopped producing results because of schedule pressure and resource contention.
This is why saying no is a critical skill.
If you limit the commitments you make, you can provide rapid turn around on the commitements you do make, and everything runs much more smoothly because you’re thrashing less, and wasting less time on task switching.
Beyond the basics, I’ve discovered that one really critical notion is to have enough slack in your system to handle emergencies. If you schedule the system full, any high-priority, high-urgency task that enters the system can break the whole process.
Without slack in the system emergencies snowball…
I know this from experience, as I’ve had my share of emergencies in the last couple of years, and when there was slack in the system things settled down quickly, and when there wasn’t I ended up with new emergencies caused by the first emergency delaying things just a little bit too much.
So, when you are tempted to take on another commitment, think about what would happen to your life if you had to take a week off to deal with a death in the family, or to help a sick relative. If you don’t see any path to recovery, perhaps you’re over-scheduling your most important resource — you.
When No, really means Yes
In the end I discovered the biggest irony of time management: it’s only when you say No to some things, that you have the ability to say Yes, and make real commitments.
When you say no to helping a friend move, or to visiting family, or whatever feels valuable to you you will feel terrible. But, if you don’t say no sometimes to at least some of these things, you’ll end up not being able to do any of those things anyway, because you’re always behind and never quite able to fulfill the commitments you make.
I learned the hard way, hopefully you don’t have to ;)
November 30th, 2009 by Mark Ramm
Bruce Eckel recently posted “We No Longer Need Power,” and Ian Bicking recently gave a talk “Toward a new self-definition for open source“. Both raise similar points, “power” seems to be handled differently — actually they both say better — in open source communities and open spaces conferences than traditional companies.
I agree, but I think that any discussion power politics is pretty risky, particularly since we use authority, power and force pretty interchangeably in many situations. And it’s hard to nail down exactly what people mean because there’s some confusion even at the level of what the words mean.
So, from my perspective (heavily influenced by Hannah Arendt here’s a reasonable definition of terms:
- Power: group action in service of some goal
- Authority: some kind of status “given” to an individual, which gives her influence over the actions of others.
- Force: the ability to make somebody do something they would not do on their own
- Violence: the act of causing of physical, social, or economic damage to an individual or group.
( * Arednt fans should note that I am using force differently than she does.)
Power and Authority in Open Source
Open Source projects have powerful people, in that they have people who somehow manage to get a group of people to work in common on some larger goal. And there’s often some sort of formal authority which resides in the BDFL or project leaders. Authority often centers around who has commit access and who can flip the commit bit. But there’s very little force or violence involved, and the authority that we give is always tentative and revokable in the case of an “unfriendly” fork of the community.
The fact that there’s often not much money going on reduces the chance of economic violence and removes the main way that developers encounter force. So, nobody can force you to work on stuff you don’t want to, and nobody can force you to stop working on the things you really want to see done.
Open source is Force/Violence free
At least that’s how it often seems. But I there can be significant social pressures to work on one thing rather than another, and many people often feel like they have a right to tell you what you ought to be working on.
None of this counts as force, but it does seem to indicate some imbalances in the system, where there are producers and consumers of open source and the producers seem to often feel like they can never do enough to please all of their consumers.
And because there’s a lack of resources going to the producers, it’s consumers are often frustrated by the slop pace of development. But all of that is another post for another day.
P.S. A Science Fiction book recommendation
Ursula K. LeGuin wrote a great book that I’ve been thinking a lot about when talking to people about the subject of the difference between “commercial” software culture, and the somewhat anarchistic Open Source culture. The book The Dispossessed, is one of my favorite Science Fiction novels, and and though it came long before “Open Source” or even “Free Software” even existed as such, I think it has a lot to say about the strengths and limitations of the “Free Software” culture.
One thing we learned is that you have to enforce some stuff on the Python side of the world in order to make working with totally schema free data stores easier.