//@ifdef IE6_BUILD
 ...custom IE6 code here
//@else
 ...code for other browsers here
//@end

Of course, this goes against the idea that your JavaScript would remain usable for development without needing to be processed, but it’s just an example. Longer term, I hope to have a different approach available that will allow conditional code substitution so that browser specific optimizations won’t get in the way of an easy development/test/debug process.

[Note that before writing this I did seek out existing implementations, and found js-preprocess to be the most interesting; However, I needed something that would work as part of an existing build chain, so authoring the tool in Python instead of JavaScript made more sense.]

Currently, jsmacro is poorly named, as I didn’t write the macro system that was in my head. Instead, it’s currently a basic preprocessor supporting only DEFINE and IF statements, which happened to be all I needed at the time. Usage works like this:

Input JavaScript

  //@define DEBUG 0

  var foo = function() {
    //@if DEBUG
    alert('This.');
    alert('That.');
    //@end

    print "Hi";
  };

Pass the above JavaScript through jsmacro from the command line like this: ./jsmacro.py -f infile.js > outfile.js (assuming the files are all in the same directory), and you get the following:

Output JavaScript

  var foo = function() {

    print "Hi";
  };

The tool has registered the variable ‘DEBUG’as 0 (i.e., false), so the conditional include statements omit the alert() calls. If DEBUG had been set to 1 (i.e., true), the alert() statements would remain (though all jsmacro instructions would be removed either way.)

One of the tricky things about doing macros or preprocessing in JavaScript is that I wanted the code to be valid JavaScript before the tool is run (which is why C-preprocessors won’t work.) The idea is that you develop as you normally would, but wrap your debug and testing code in conditional jsmacro statements so that they are automatically removed as part of your build process.

There’s nothing fancy about the current implementation (it’s a crude state machine that scans line-by-line, top-to-bottom looking for regex patterns and deciding whether to output the line of not.) Crude as it may be though, it completely solved a problem for me, and hopefully it will help you out as well.

Since I don’t always need real-time links, devising a mechanism to time-shift, and read at my leisure, seemed appropriate. Furthermore, since I don’t mind following friend’s del.icio.us feeds with a feed reader, converting tweets-with-links into RSS feeds seemed like a natural fit. After some brainstorming with @karllong and a bit of hacking, tinyLinkFeed was born!

tinyLinkFeed is designed to aggregate microblogging streams (like Twitter), and expose RSS feeds for posts containing URLs. To make the feeds a bit more useful, tinyLinkFeed also resolves shortened URLs, so you know what you’re linking to. (The URL un-shortening is done by another webservice I wrote at the same time, called tinyexpander; but I’ll save those details for another post.)

Using tinyLinkFeed is pretty straight-forward. For example, my normal Twitter page can be found at http://twitter.com/smartt, so my tinyLinkFeed page lives at http://www.tinylinkfeed.com/twitter/smartt. To follow the links I post to Twitter, you’d point your RSS reader to http://www.tinylinkfeed.com/feed/twitter/smartt.xml. For something perhaps more useful, you might try Tim O’Reilly’s link feed: http://www.tinylinkfeed.com/feed/twitter/timoreilly.xml (which is actually one of the main reasons I wrote tinyLinkFeed.)

The application came together fairly quick (it’s written in Python and runs on Google App Engine), though I haven’t had time to expand it since launch. I have a few ideas on what to add next, but I’m setting up getSatisfaction so you can leave ideas as well.

Adding profiles to tinyLinkFeed’s aggregator isn’t openly available yet, so if you’d like a profile added, drop a message to @smartt or @tinylinkfeed. I hope you find it useful!

Basic authentication is often added to sites (or directories) using a .htaccess file and something like this:

AuthUserFile /home/foo/.htpasswd
AuthName "Private Area"
AuthType Basic

<Limit GET>
require valid-user
</Limit>

…but you can also do basic authentication on-the-fly by reading/writing HTTP Headers. To ask the browser for a user/password, you can raise a 401 error, and write a “www-Authenticate” header containing something like ‘Basic realm=”Secure Area”‘. To read the user/password, look for an Authorization header, grab it’s value, Base 64 decode it, and you should have a string in the form of “user:password”.

Here’s how you might handle it with Google App Engine. (Well, really you might use a decorator.. but this example is easier to explain.)

class AuthTest(webapp.RequestHandler):
  def get(self):

    # Wrapping in a huge try/except isn't the best approach. This is just
    # an example for how you might do this.
    try:
      # Parse the header to extract a user/password combo.
      # We're expecting something like "Basic XZxgZRTpbjpvcGVuIHYlc4FkZQ=="
      auth_header = self.request.headers['Authorization']

      # Isolate the encoded user/passwd and decode it
      auth_parts = auth_header.split(' ')
      user_pass_parts = base64.b64decode(auth_parts[1]).split(':')
      user_arg = user_pass_parts[0]
      pass_arg = user_pass_parts[1]

      checkAuth(user_arg, pass_arg) # have this call raise an exception if it fails

      self.response.out.write(template.render('templates/foo.html', {}))

    except Exception, e:
      logging.debug("AuthTest Exception: %s" % (e))

      # Here's how you set the headers requesting the browser to prompt
      # for a user/password:
      self.response.set_status(401, message="Authorization Required")
      self.response.headers['WWW-Authenticate'] = 'Basic realm="Secure Area"'

      # Rendering a 401 Error page is a good way to go...
      self.response.out.write(template.render('templates/error/401.html', {}))

That’s all there is to it.

If you want to programatically write an Authorization header (as in, sending authentication credentials to another site, like the Twitter API’s, for example) you’ll do something like this:

request = urllib2.Request(url)
request.add_header('Authorization', "Basic %s" % (base64.b64encode("%s:%s" % (user, password))))

Enjoy!

Here it is: conway-life.py

There’s not much to it, but it does show a software pattern I’ve been using frequently with NodeBox. Many of the NodeBox examples make heavy use of non-namespaced, global variables. I suppose it makes simple code easy to read for those new to programming, but it’s a habit you’ll want to break before your code starts getting more complex.

What I’ve found helpful is to create a World/Universe/Controller/Stage object that drives the rendering. Instead of using multiple globals in draw(), the controller object keeps the main parameters as local properties, and instantiates any needed objects in it’s __init__(). This approach prevents global variables names from clashing, and allows for creative reuse of rendering components.

Enjoy!

For those unfamiliar with NodeBox,

“NodeBox is a Mac OS X application that lets you create 2D visuals (static, animated or interactive) using Python programming code and export them as a PDF or a QuickTime movie.”

It uses PyObjC to embed a Python runtime into an OS X native application, and fits into the same toolbox as Processing and openFrameworks. It’s a bit slower to run complex animations in, but you’re coding in Python, you get the gorgeous fonts and anti-aliasing you’d expect on OS X, and it provides easy access to some OS X native libraries, like Core Image. For a quick look at what it can do, check out the NodeBox gallery.

NodeBox includes it’s own Python build, which is nice for portability and reliability, but it uses a custom sys.path that doesn’t look for Python packages you might already have installed on your system. There are a few ways to deal with this:

1. You can install your packages into NodeBox’s path, ie., ~/Library/Application\ Support/NodeBox/ — meaning that you can use them from NodeBox, but not from other scripts…
2. You can import sys in your NodeBox code and manually modify the sys.path value to add your existing packages…
3. You can install packages into your system site-packages directory, and sym-link them from NodeBox’s directory…
4. You can make NodeBox use your system packages instead of it’s own by sym-linking ~/Library/Application\ Support/NodeBox to your site-packages directory of choice (ex., /Library/Python/2.5/site-packages)

For this exercise, I’ll be adding pymunk (Python bindings for the Chipmonk physics library) to NodeBox using option #3: Installing pymunk globally, and sym-linking from NodeBox’s package directory. This allows me to run the pymunk examples from the command-line (which use PyGame and Pyglet), but still use pymunk from NodeBox. This may not always be the best solution, so you’ll have to pick what’s right for your needs.

Let’s get started.

Pymunk (at the time of writing) includes it’s own copy of the Chipmunk source code, making this whole process rather easy. Once you’ve downloaded and uncompressed the pymunk source, cd into it’s directory and build chipmunk using:

> python setup.py build_chipmunk

Now you can build and install pymunk:

> python setup.py install

This will install an egg (which I normally hate dealing with, but that’s another story.) If you don’t want the egg, just copy the pymunk directory into your site-packages.

Now we’ll add pymunk to NodeBox’s path. My pymunk is in /Library/Python/2.5/site-packages/, so I’ll:

> cd ~/Library/Application\ Support/NodeBox

> ln -s /Library/Python/2.5/site-packages/pymunk-0.8.1-py2.5.egg/pymunk .

Finally, NodeBox needs access to libchipmunk. I used this approach:

> cd /Applications/NodeBox/NodeBox.app/Contents/MacOS/

> ln -s ~/Library/Application\ Support/NodeBox/pymunk/libchipmunk.dylib .

We should be done! Fire up NodeBox and try an include pymunk to see if it loads. If you don’t see any error messages, you’re good to go.

If you’re new to pymunk (as I was until this week), head over to the Slide and Pin Joint tutorial to see how it works. The example is written for PyGame, so you’ll be doing a little rewriting to bring it into NodeBox.

The following screenshot shows the Slide and Pin Joint demo within NodeBox using my take on porting it. I’m having a little trouble with the slide joint, but you can check out my code if you’re curious: slide_and_pinjoint_example.py

For directions and more info, see the APUG wiki: http://wiki.python.org/moin/AustinPythonUserGroup

Hope to see you there!

• Targeted at developers wanting to learn Django by building example applications rather then (or in addition to) reading the docs and man pages
• The reader builds three working applications by following along
• The examples are based on up-to-date Django features (ie., a 2008 build)
• Lesson’s focused on using Django (not on Django’s inner workings)
• Doesn’t waste time explaining Python and HTML (nor does it dive deep explaining the how/why of what you’re doing in the examples)
• Introduces the reader to powerful Django features — covering a wide range of capability
• Examples focus on designing for code reuse (and leading by example, by integrating with existing reusable apps and Python libraries)
• Offers an alternative approach to learning, focused on relevant, practical examples

Background:

Practical Django Projects (Apress book description) was written by James Bennett, release manager and contributor to the Django Web Framework. It was published by Apress in 2008. This was Bennett’s first book.

Full disclosure: I was provided with a free, review-copy of the book by Apress.

The Book:

Practical Django Projects introduces the reader to the Django Web Framework by example. It takes the reader step-by-step through three example projects: a basic CMS, a blog application (called Coltrane, which powers the author’s personal blog), and a code-sharing/snippets site (called Cab, which powers http://www.djangosnippets.org/.) The examples cover real-world problems (and integration tasks) that developers are likely to be interested in, and leaves the reader with three working Django applications.

The lessons are spread across eleven chapters:

1. Welcome to Django — a wonderfully short introduction that wastes no space explaining prerequisites (it assumes the reader knows Python)
2. Your First Django Site: A Simple CMS — an introduction to the Django Admin and Flatpages
3. Customizing the Simple CMS — customizing the Admin interface (adding TinyMCE) and developing a simple, reusable search feature
4. A Django-Powered Weblog — defining the basic models, and using django-tagging and Generic Views
5. Expanding the Weblog — adding del.icio.us-synced links, and custom categories
6. Templates for the Weblog — more extensive use of Generic Views, template inheritance, and custom template tags
7. Finishing the Weblog — using django.contrib.comments and model signals to develop a moderation system with email notification and Akismet integration; Using django.contrib.syndication to add RSS/Atom feeds
8. A Social Code-Sharing Site — building the initial models, integrating with the pygments syntax highlighter, and writing custom model managers
9. Form Processing in the Code-Sharing Application — great examples of using newforms (much better then the The Definitive Guide to Django‘s chapter on form processing)
10. Finishing the Code-Sharing Application — more custom template tags, this time used with bookmarking and rating features
11. Writing Reusable Django Applications — a summary of Bennett’s philosophy on decoupling application features into reusable components (with references to the UNIX saying, “do one thing, and do it well”)

The examples focus on building applications the “Django way” — meaning that they heavily leverage Django features such as Generic Views, custom template tags, and the django.contrib package. Each section starts by outlining the features to be developed, then walking the reader through model definitions, URLs, template design, and the request-handler (view) code.

While working through the three example applications, Bennett teaches the reader how to decouple applications from projects, how to think about (and look for) opportunities for code reuse, and how to integrate with other reusable Django applications. The lessons aren’t so much “how does Django work”, but rather “how do you, as a developer, structure your projects to get the most out of the framework.” Depending on your level of comfort using Django and Python, the lessons will either be a breeze, or ridiculously confusing. (ie., there’s a lot of magic going on in the examples, and the book assumes that either you get it, you’re comfortable not knowing, or that you’ll figure out the finer bits when you need them.)

The Core Message

Ultimately, the book isn’t so much about learning Django, as it is about learning how to use Django properly (where properly is defined as the way in which the Django developers use Django.) From this perspective, it’s quite successful. The reader is shown a number of patterns and concepts that can be applied to any Django project.

Bennett wraps up the book with a chapter on design philosophy, but I think the overall lesson of the book is best summarized on page 124, with the following quote:

…this is the hallmark of a well-built Django application. Installing it shouldn’t involve any more work than the following:

1. Add it to INSTALLED_APPS and run syncdb.
2. Add a new URL pattern to route to its default URLConf.
3. Set up any needed templates.

This is the zen of pluggable Django applications. It’s the path Bennett wants to help you start down. The value of going down this path will depend on how often you’ll use Django in the future.

Conclusion:

Overall, I think the book will be more valuable for someone just getting started with Django, then someone who’s been hacking lower-level with the framework for awhile. It’s a developer-focused, quick-start, “get you on the right foot” kind of book that I certainly would have appreciated more a few years ago. The big question then, is whether this book is for you. The answer depends on a couple things, with the most important being how you like to learn. Do you prefer learning by example, or learning by reading the docs and building things on your own? If you prefer to have an expert guide you step-by-step, then this book is for you. You’ll still need to poke around in the Django documentation to really grok how it all works, but this book will get you up to speed quickly.

If you’ve read the docs, done the online tutorials, and are still interested in picking up some best-practices on decoupling your code from your specific application (ie., learning how Django supports code reuse), then this may still be a book for you. If you know you’ll be building a large application, the lessons in the book might help prevent you from writing a single, monolithic application, or at least give you some insight into how to organize and package your code. Down the road you’ll thank yourself.

For me personally, I was actually looking forward to this book before it came out. I think the Django docs online (as great as they are) can sometimes lack in providing best practices. However, I’ve also been using the framework professionally for a number of years (to deploy personal, start-up, and enterprise-class web applications), and I’ve previously built and deployed a pluggable, multi-site, Django-based blog engine (with del.icio.us and Akismet integration, flexible moderation rules, etc.), so the idea of using a blog engine as the core example in the book was a bit disappointing. That said, I did enjoy seeing another developer’s approach on solving the same problem, and I picked up a few nice tips around some of the more recent Django features.

If you’re looking to build a reusable code library (and you should be, if you’re going to build more then one Django project) and ensure that you’re using Django efficiently, this book will help point you down the right path and have you thinking about decoupling your architecture from the start.

For more details, see: http://wiki.python.org/moin/AustinPythonUserGroup and http://python.meetup.com/188/.

Hope to see you there!

Background

The book was written by Adrian Holovaty and Jacob Kaplan-Moss, the creators and “Benevolent Dictators” of the Django Web Framework. It was Holovaty and Kaplan-Moss’first book, and, I believe, meant to be the first Django book to market. The book was drafted online; open to peer-review and community feedback; and ultimately published under the GNU Free Documentation License.

From the get-go, the print edition had a few inherent market challenges to face: First, the entire book is available online, for free, at: <http://www.djangobook.com/>. Second, in many ways the book is a re-hash of the docs available at <http://www.djangoproject.com/documentation/>, which are also free. Third, the book covers Django 0.96, not SVN. (0.96 is technically the latest-snapshot release, but a lot has changed since 0.96.) And finally, the $45 MSRP could be seen as a little steep for what is effectively a printed copy of a free, online book.

The print experience

Diving in, the book takes the reader through the basic installation process, provides a brief background on how the framework came to be (and why you want one), then steps through the major features (ie., the template system, ORM, URLconfs, generic views, etc.) It’s what you’d expect from a technical reference — no fluff, and straight to the details. There are plenty of code snippets to learn from, and the sidebar notes tend to be insightful.

Since it wasn’t new material for me, the book was a fairly quick read; but the experience of reading Django documentation in book-form was actually quite fascinating. There’s something about settling into a comfortable chair with a book, pen, and highlighter that you just can’t get with online documentation. Perhaps it was just a little more noticeable given the material. When I read the Django docs online, I tend to skim over them while trying to solve a problem. I use them as a reference more then a learning tool, and it’s usually while actively coding, thus my brain is partially distracted with whatever it is I’m building.

With a physical book, you can unplug, step away from the computer, and give the material your undivided attention. This isolation from distraction results in a much deeper understanding of the text. This is the real the value of the printed book — it’s an opportunity to digest online documentation in an environment more conducive to learning and retention.

My general take-aways and observations

• The book definitely has a beginner/intermediate feel to it, but only in the sense of a beginner Django user — not a beginner Web developer or Python programmer. I’m curious how well the book is received by folks who are beginners at Django and dynamic Web development since the text brings up a lot of complex topics in Web development that aren’t really explained. (Ex., database administration, server clustering, manipulating HTTP headers, etc.)
• The breadth of the book is impressive, but in some ways, the book really feeds you through a firehose, so to speak. It throws a lot of new concepts at the reader and doesn’t always explain why you’d need to know them, or how you might use them in the real world. For someone deploying a site with Django, it will be good to know that all these features are available, but it might take awhile before they need to use them (if ever.)
• The book does touch on some of the more advanced Django features (like extending the template system and writing custom middleware), which was nice, but some topics are reserved for the appendix and get limited coverage (ex., model managers and ‘Q’queries.) Others, like the Sites Framework, are given good exposure, but not so much that the reader is left with a clear picture on when to use them and what their limitations are.
• The forms processing chapter was a bit lighter then what I was hoping for — especially given that the current newforms documentation still trends toward “read the source code.” It provides enough to start using newforms if your form needs are pretty basic, but doesn’t address creating your own widgets, or any of the fun stuff you can do once you start dynamically generating and manipulating newforms objects.
• It might have been nicer if the examples in the book were a little more tied together, perhaps all focused on building a single example project and showing how the various features are used in real-world applications. (The example of the book-publisher’s app was a reoccurring theme, but not so strongly that each chapter applied it’s new learnings to it.)
• The Deploying Django: “Going Big” sub-section provides a nice infrastructure graphics for how high-traffic systems might be setup, but once you get to the point of being “big”, you need to architect for it, and that’s really outside of the scope of this book. For this section, it might have been nice to reference other resources on scaling infrastructure, and perhaps pointing out some of the ways that Django can be optimized for performance and horizontal scaling. (For example, one of the Django projects we put into production at work will happily support 1,200 requests/second, but the database layer and session middleware have been reworked a bit, and the content caching approach is a little different then the standard Django offering.)
• On the more positive side, even as someone who’s been using Django for some time, I still learned a few new tricks, and I was reminded of a few features that I could be taking better advantage of. (And when you do this stuff professionally, every shortcut and productivity gain has monetary value — avoiding even a half-hour of debugging pays for the cost of this book.)
• This book would make a fantastic read for a back-end developer joining a project that is already using Django. I normally tell new developers to go through the Python Tutorial at <http://python.org/doc/tut/> if they’re new to Python, then to complete the Django Tutorials at <http://www.djangoproject.com/documentation/> before trying to grok any in-progress Django project. Now I have a third reference (though I might still suggest that they walk through the tutorials first, so that they have some context when reading the book. Otherwise, there are just too many new concepts to do a straight read-through and still grasp it all.)

Summary

The market needed a good Django book, and this one delivered a solid reference for the framework. Arguably, it’s not really a “Beginner’s Guide to Django”, but hopefully it covers enough of the basics that future books can focus on best practices and more advanced techniques. (On a related note, there’s apparently an upcoming “Practical Django Projects” book, also from Apress, that will focus more on building “reusable Django applications from start to finish”. This might actually make for a better beginner’s book, depending on how it turns out. [Via The B-List: Speaking and writing].)

The million-dollar question then, is “Should you buy this book?” My answer ended up being a bit more positive then I expected, but there are two parts: First, if you’re a front-end developer only, you don’t need this book. You can just read Chapter 4: The Django Template System online, and then use the “Django Templates: Guide for HTML authors” section of the online docs as a reference. For back-end developers, the story is different. If you’re going to just “read it while you hack”, then you might as well just read it online; but if you’re serious about building applications with Django (especially if you’re new to it), then you should consider the book and investing the time to step away from the computer and really let yourself get into it. Unless you are an active contributor to Django (which I’m not, just to be clear), the odds are pretty good that you’ll learn something new, even if you’re already using Django today.

The Django Web Framework project just added a new contrib.webdesign module with an amazingly simple, but incredibly handy first feature: a lorem ipsum generator. The idea is that a project’s base templates can include generated lorem ipsum for testing layout and page flow, but inheriting templates can override the generated text once real content is available.

The lorem tag is used like this (via the contrib.webdesign docs):

• {% lorem %} will output the common “lorem ipsum” paragraph.
• {% lorem 3 p %} will output the common “lorem ipsum” paragraph and two random paragraphs each wrapped in HTML <p> tags.
• {% lorem 2 w random %} will output two random Latin words.

In practice, you might do this:

templates/template.html:

<html>
  <head>
    <title>{% block article_title %}{% lorem 5 w %}{% endblock %}</title>
  </head>
  <body>
    <div class="article">
      <div class="article_title">{% block article_title %}{% lorem 5 w %}{% endblock %}</div>
      <div class="article_body">{% block article_body %}{% lorem 4 p %}{% endblock %}</div>
    </div>
  </body>
</html>

And then inherit when you’re ready:

templates/article.html:

{% extends "template.html" %}

{% if article %}
  {% block article_title %}{{ article.title }}{% endblock %}
  {% block article_body %}{{ article.body }}{% endblock %}
{% endif %}

Previously, I used to just paste lorem ipsum text directly into the main template (wrapped in block tags for overridding), but this new tag will let you skip the copy/paste routine. Very nice!

From Ivan Krstic’s keynote on the One Laptop Per Child project:

• Python is the language of the One Laptop Per Child (OLPC). Everything that can, will be done in Python… and there’s a “view source” button on the keyboard (view layout) so you can view (and edit) the source of your current running application.
• The filesystem (which supports versioning) is called Yellow, and will be released withing a week or so. The GUI is called Sugar, and is available on http://dev.laptop.org/ to play with. You can download the full image (or build the environment on Linux.)
• The OLPC supports 802.11s mesh networking.
• The hand crank was removed for case durability. The OLPC’s are designed to last five years, but the torque from the hand-crank would have stressed the plastic case too much for it to last that long.
• The first OLPC’s will start shipping in August of this year!
• The OLPC hardware was getting ~1100 pystones before optimization. They are now up to ~2300 pystones (on a 366 Mhz AMD Geode processor.) (Note: This means they have better Python performance then Python for S60 is seeing on current S60 phones.)

From the Web Frameworks panel:

• James Tauber, “Reinventing the wheel is great if your goal is to learn more about the wheel.”
• Jonathan Ellis, “When you control the whole stack you can innovate faster.”

From Adele Goldberg’s keynote:

Public school education is so bad that real eLearning solutions can’t go to the schools — they need to be outside of schools so that you don’t have the traditional censorship that comes with public schools — and you don’t have the associates with the bad experiences kids have while at “school”.

From Jacob Kaplan-Moss’talk, “Becoming an open-source developer: Lessons from the Django project”:

1. Use good tools. “Open source is better because it’s better.”
2. Avoid dogma. Don’t get stuck on what language something is implemented in.
3. Work with (and hire) smart people. The model in open source is that if you’re smart, people listen to you. That’s rough if you’re not smart… But also means that it’s worthwhile to mention when you’re an expert on a topic.
4. “Methodologies” suck. Ex., MVC is cool, but Django abuses it because it doesn’t fit so well with the web.
5. DRY — Don’t Repeat Yourself. The one methodology to use.
6. The business case for open source. You have to make one (to your company.)
   • Money. You’ll get recognized and sell services because of it. (Ex., Ellignton wouldn’t be as successful without Django.)
   • Free labor. (Sad to think of this way, but true when you have an interesting project.)
   • Self-improvement. Knowing that peers will review your code makes you much more careful about the code you submit. This makes the code a lot better.
   • Geek cred — gaining credibility within the geek community makes it easier to hire great people.
   • Moral Argument — If you built a business on open source — it’s time to give something back.
   • Figure out where to draw the line — Django gave away the tools, but not all the apps.
7. Selling open source to other companies. Microsoft’s FUD had been quite successful in some areas. Counter the “communist” argument with a “freedom” argument. Focus on the freedom of data — your data belongs to you; there is no vendor lock-in. Open vs. Lock-in is a better argument then Open vs. Closed.
8. Create a community. This doesn’t just happen because you setup a mailing list. (Gave example of thanking people who post anti-Django blog posts and asking what they didn’t like.) Don’t say anything that would get you kicked out of a bar.
   • Avoid monsters (trolls, vampires, etc.) Detect them early, and ignore them.
   • Spam can’t be an afterthought. Collaborative tools require spam filtering from Day 1. You’ll get spam. Lots of it. Google Groups is pretty good about cutting out spam.
9. listen to the community. But smartly. Sometimes the vocal majority doesn’t represent the wishes of the whole community. Django’s magic-removal was a big risk, driven by the community. You also have to be willing to ask for help. Sometimes you don’t feel comfortable delegating tasks that you think suck — but not everyone has the same definition of “what sucks” — sometimes there’s someone who actually WANTS to do this task!
10. Handling community contributions. You need a defined method for how you take contributions. It helped the Django project when they adopted a system for differentiating between patches that are controversial, and those that aren’t. (ie., simple bug fixes vs. design decisions.) A ticket reviewer makes this decision.
11. Learn to be comfortable saying ‘no’— there are plenty of Python web frameworks, and maybe someone’s needs are better handled by another framework. “If everyone can check in features, you have PHP.”

From “The absolute minimum an open source developer must know about intellectual property”:

• It’s a lawyer’s job to figure out what will go wrong with your plan. They are professional pessimists.
• Only the “claims” in a patent are covered, not the stuff in the “specification.”
• A header file is a “purely functional” expression, thus NOT-copyrightable.
• If you don’t protect your Trademark, you lose it. This is why companies have to send cease and desist. The “get a first life” situation was important because Lindon explicitly granted them a license to use the Second Life trademark in the parody, thus they were able to demonstrate that they were protecting their mark.
• If you tell someone how to do the work (ie., “work for hire”), then you own it.
• An independent contractor owns their work unless the contract specifically assigns the rights to the company.
• The person who made a patch owns the patch. By giving it to you, you get an applied license to use it, but because it’s implied, it’s fuzzy as to what you can do with it.

From Robert M. Lefkowitz’s keynote:

• Only 2% of the population can read source code. (And free software doesn’t matter if no one can read it!)
• Proprietary software values function. Free software people value the building of the “community of learning” around the software, even if it has fewer features.
• The traditional view is that computer literacy is about one’s ability to use applications, rather then to program. If this is right, then what’s the point? Computers might as well be printing presses.
• In literature, you read the greats (ex., Shakespeare), then try to write like them. So in computer literacy, who are the greats? If we were going to make every high school students memorize a program, what would it be?
• Great programmers break the rules elegantly. Bad programmers break the rules without realizing it.