XSIBlog

When you start building new tools or a new pipeline you have to answer quite a few artist-centric questions such as what you want these tools to do and how they will fit into the workflow. You also have to answer a few technical questions unless you might wind up in a quagmire consisting of disparate tools, unmaintainable code and longer than necessary development times.

Some of the choices that need to be addressed are the technological choices of tools, systems, libraries and techniques.

Which tools and technologies should you use and why? I won’t pretend to be suggesting the holy grail of tool chests. I just felt like sharing the choices I’ve made and why I made them. Please don’t hesitate and comment if you think I’m off base, you have questions or would like to suggest other alternatives that you use. I’d love to hear, and learn, from you!

Core Tools and Systems

My preferred programming language as you may (or may not) have noticed, is Python. It has clean and concise syntax, an object oriented approach second to none in dynamic languages, and a standard library that provides most of the functionality you’ll ever need. It has almost become the defacto language in our industry with support in XSI, Maya, Houdini and RealFlow just to name a few. With Python you can code system tools, CG application plugins and scripts, standalone applications, web applications as well as custom libraries to back all of these up. The language is evolving and has strong community and industry support. Need I say more?

On the server I run Linux. Wouldn’t have it any other way. Actually, right now I’ve been forced into running a pipeline off a Windows box and I hate it to death! I can already hear you asking: “Which linux distribution?” On the server, honestly, I don’t really care. I’ve often built all my applications from scratch according to a technique a friend has taught me. This guy was, at one point or another in his career, senior systems administrator for the likes of Hydro-Quebec and Teleglobe – I tend to trust him in IT matters.

On top of the OS I like to run Apache with mod_python for all my web serving needs and MySQL for database needs. Apache is by far the most versatile web server I’ve worked with and with a few cnames in your DNS and virtual hosts in Apache you can be very organized in your web applications. As far as MySQL goes, it is free, well hooked into a multitude of languages, and very stable. Until recently it didn’t have any stored procedures but that’s the kind of stuff I like to keep in my application logic anyway. To make easy MySQL management even easier I’ll also build a vhost in my apache dedicated to serving phpMyAdmin, by far the best web front end for MySQL.

Note: With the purchase of MySQL by Sun and after a few discussions with a friend, I think I’ll be looking heavily into PostgreSQL.

The last thing I usually install onto the system is Subversion. Even if you’re a lone developer I think source code control is invaluable in helping you track not only code changes but also release cycles and versions. Also look at installing Subversion and/or TortoiseSVN on your development station to make interfacing with the server easier.

Libraries

To help build the web applications you’re probably going to be needing, look into Django. It’s biggest assets for me are it’s Model and Object Relational Mapper (ORM) as well as it’s template language. Django is also built in such a modular fashion that you can use the template language in standalone applications that need to build static HTML pages or you can use it’s ORM in XSI tools that need to access a Database. This means you can build a whole lot of application logic in such a way that it is highly decoupled from either the database or the ui. Django can really break out from the web, this shouldn’t be forgotten. SQLAlchemy also exists as far as ORM layers go but it doesn’t jive as well with me and obviously doesn’t offer an end to end solution if you’re building a web app.

On the networking side, I’ve started tinkering with Twisted. Wow. This is definitely going to be a part of my standard set of tools. When building more complex systems that need to interact over the network Twisted’s protocol building facilities are simply wicked! Some of it’s constructs needed a bit of getting used to for me, see the deferred, but once I got a handle on them I saw how they can get quite powerful.

Finally, on the UI side for standalone applications, I’ve fallen in love with QT. I had used Tk and WxWidgets in the past but they definitely don’t compare to QT. And QT is much more than UI, it is also networking, OpenGL, threading, etc… To get QT and Python working together you’ll need PyQT whose latest version includes everything you need to get started, including QT itself. I know that from the UI perspective XSI allready offers much of what we need in its PPGs but if you are in a mixed pipeline, think Maya and XSI, there is some merit in using a UI toolkit that you can run in both applications to cut down on the amount of code you’ll be doing.

Techniques

One of my self imposed rules is the maximum length of a function or method. If I can’t fit it into a single screen it is probably too long and I should rethink it and split it up.

I am also trying to better my documentation. I like self documentation through variable names so you’ll often find rather verbose symbol names in my code. With a proper IDE that does name completion the burden on typing isn’t so big. I also try to do a first draft of my functions or methods in pure comment form. This gets my ideas out quickly while they are fresh without bogging me down in details. The comments also wind up being present in the final code thus helping out comprehension of the program. Finally I try, and often fail miserably ;), to use Python’s docstrings to document public interfaces.

One of the latest things I want to impose upon myself is unit testing. Especially for my libraries. Some detractors of dynamic languages will gripe about type safety and they would be right. That’s why you test. And testing not only helps with types but also algorithms, refactoring, logic, etc… If your application breaks in one way or another, proper testing can help find the break sooner than later. On the subject of unit testing libraries check out this nice roundup. I’m currently leaning towards py.test.

Bored yet?

I hope you’re not bored out of your mind yet! Were you really expecting me not to totally geek out in an article entitled “Technological Choices”?

Cheers!

Popularity: 29% [?]

This entry was posted on Sunday, April 20th, 2008 at 11:32 pm and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.