Archive for October, 2008

Consulting Experiment

Compound Thinking is a Python Web development shop, and I’ve been spending some time recently thinking about how I can help our development team grow. One thing several people have expressed is a desire to work on some projects using newer stuff, like Pinax, or tg.ext.geo, we’ve also been doing quite a bit of dojo and some flex work, and would like to do more. And I know all of us are very interested in doing more Open Source work.

Compound Thinking has been able to provide affordable development prices by using a variety of high-talent developers in the US and around the world. And, I’d like to see if we can push forward some open source projects, while making our services even more affordable for customers who help us help the world.

So, here’s my proposed experiment:коли под наем

  • We will provide significant discounts for people with projects using the stuff the team wants to work on.
  • We will split the costs of any development work which is released under an OSI approved license, including parts of any project we do that can be refactored out into a reusable component.

In particular we want to:

  • we’ve got a lot of GIS/geo experience, and have done a lot of framework work in TurboGears to improve that story, but we need a larger TG+geo project that can showcase all this cool stuff.
  • After DjangoCon, I’m very interested in Pinax, and what all those reusable components bring to the table for Django, and so several of us are surprisingly eager to work on social networking style projects to explore that in more depth.
  • I’m interested in pushing TurboGears integration with javascript frameworks and dojo in particular, so heavily javascript oriented applications
  • I’m also interested in improving the e-commerce story for TurboGears and would love to open source some related tools. We’ve done this stuff a few times, and I’d love to do it one more time under an open source license so we can help future generations not to have to reinvent this particular wheel.

Beyond that, feel free to pitch us a project that has some open source components that we can release, and we’ll see if we can work up a deal to split the costs on those components.

If you’re interested in any of these ideas e-mail me ( let me know. And more importantly if you’ve tried any of these things and had good or bad experiences drop a comment here, because I’m very interested in figuring out how other consultancies expand their technical repertoire and push forward the free software agenda.

REST is a design for the long run

Found this quote in a recent discussion or REST.

REST is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency.

The one technology every developer should learn!

I recently wrote a little article for an O’reilly project, in which I argue that the single most important technology that Software Architects need to master is not at all new. And I don’t just mean that Fred Brooks already told us about it in the 70′s. It’s older than that, much older.

Software Architects and all Developers ultimately will succeed or fail based on their knowledge of one of the same technologies the architects of the pyramids used to get their jobs done — the conversation.

When something goes wrong, or when somebody just isn’t getting it, mastery of this simple technology makes a huge difference. A well placed, well handled conversation can change the course of a failing project, or transform something good enough into something great.

Sure conversation can’t solve every problem, but it’s a key enabler for every other solution, since it is the very thing that allows for exploring possible solutions as a group.

We all learned the basics of conversational technology as kids. But often that’s not enough, and we still have conversations that go horribly wrong. Fortunately conversation is not a stagnant technology, and we can learn more as adults.

I’ve read more books about “how to talk to people” than the average software guy, and I’m endlessly fascinated by the subject. I’ve recently been getting into the neuroscience side of the subject, and am endlessly fascinated by the complexities of brains.

But, if I had to recomend just one book for developers and architects to read to improve their “people skills,” it would be Crucial Conversations. It cuts through the complexity to offer a lot of really simple suggestions that actually work. There’s good science behind what’s suggested (even though it’s not always spelled out in scientific terms.

I know that I really need to write more about why this book is so good. But for now, let me say that it does a better job of outlining in a simple and easy to understand way exactly the tools that are needed to keep both parties in a conversation thinking. It’s easy to ignore the impact of fear and anger on our conversations, but to do so is to ignore the way our brains actually work.

Crucial Conversaitons outlines the steps necessary to create a safe place to think, and to actually turn that thinking into mutual decisions, and ultimately into actions that solve some of the most intractable problems in our projects. It certainly helped me.

If you’re just struggling to be understood this may not be the best book for you — because it does little to help people structure their thoughts in ways that others can understand. But if you’re struggling to break through on tough conversations, and have important issues where you or the other person are frustrated, defensive, and have been avoiding talking about emotionally charged subjects — this is the book for you.

I know it helped me to have productive conversations about difficult issues at work, and at home.

WSGI Middleare is cool

Sure, there are lots of potential nitpicks that you can have with WSGI and WSGI middleware — mostly because the CGI spec on which WSGI is based is getting a bit long in the tooth — but I think those who get worked up about that kind of thing are missing the point.

WSGI provides a known, standard, working way to create reusable components of functionality which are coupled only to a published specification, not to your code. It’s the same reason that HTTP was so successful in the first place, you can build stuff without knowing exactly how it will be used later.

A perfect example of this is the new repoze.squeeze middleware that was released a couple of days ago.

It uses statistical analysis to decide how to best join and compress stylesheets and javascript resources based on actual usage.

Sure you could do this same thing with Django middleware, but if you use WSGI then Zope, Django, TurboGears, Plone, and any other WSGI compliant app can just use it without having to worry about this stuff inside the app itself.

BTW, they also released repoze.bitbit

which automatically re-sizes images before sending them out. When coupled with a good caching proxy server this makes it very easy to let people link to any-sized version of any of the images in your library. While i don’t think it’s as widely useful as repoze.squeeze, it too provides an example of something that can just sit there transparently helping you, and it exemplifies a kind of very loose coupling that is a mark of “true middleware.”

There’s another kind of middleware which does stuff that’s “required” for your app to work properly, and I agree that it’s probably best to call this something else, since it’s not transparent, but I think it too has a wide variety of uses, but that’s a blog post for another day.