My newer blog may be found here.

We are organizing a Code Sprint [1] for ChiPy by ChiPy ChipyChipySprint.

The idea is we want to make a site like MeetUp open source this and use this for our Chicago Python user group. Here my original note to the ChiPy list:

I propose our next Sprint Saturday March 18th. The Sprint will be in response
to Alanta's User Group site where we will make our own with Django. At the same
time we will invite those who wish to learn Python to come and get hands on
experience. I suggest we hold this all day (pending availability) at the
Lincoln Park Chicago Public Library. They have a nice big room they have let us
use in the past.

At the same time we are also organizing a free class for those who wish to learn Python. We are still working out the details but it sounds like all you will need to do is to:

1. Sign up at ChipyChipySprint
2. Load Python on a laptop and bring with you
3. The hands-on class will be lead by Michael Tobis [2]

So, if your a Python Expert, come code with us. If not, become an expert.

I am suggesting we use Django instead of TurboGears. We will see if other ChiPy people go for this idea or not. Either way, I am happy to continue hosting the server. The reason I like Django is because it's agile in getting up and running. If you were at our last ChiPy Sprint you would already know getting up and running was one of our hangups. Likewise, I plan on having everyone get things set up before meeting up at the Sprint.

Last night I ran into a New Orleans native who enjoyed my story of how I wondered into Rocky & Carlos on St. Bernard Highway in Chalmette. I was traveling around at the time with a friend of mine Roy Early and we just sort of walked in. As it turns out, the place stuck in my mind and I keep crossing paths of others who have frequented the place while living in New Orleans or visiting.

Rocky & Carlos before the storm:

Rocky & Carlos after the storm (picture courtesy Margriet H.):

Another one:

Last I heard, Roy is living in a tent in someone's back yard in Colorado so I doubt he will ever read this. He and I were quite pleased with our Po' Boys and Mac an Cheese. What a long strange trip it's been ...

RIP Rocky & Carlos.

In a rather silly Chicago Python User Group Mailing List Thread, it was brought to my attention Python 2.5 will have a not-so-silly new in-line Conditional Expression feature.

Ok, so I have spent a lot of time making fun of (and sometimes secretly coding, but don't tell anybody) languages where programmers spend hours trying to write everything on one line. Likewise, I found myself hacking away on the recent seven-segment PyContest where we attempted to solve this puzzle by writing Python on one line and with a ridiculously few number of keystrokes (like 117). Would I support yet another one-liner time saver syntax much like decorators, list compression, or the lambda construct?

Yes, actually, in-line conditional expressions are a worth while language addition. The reason i am found of this feature goes back to the PEP. This ternary expression (at least the one accepted by BDFL), is extraordinarily easy to read in the form:

X if C else Y

So, now things can be done like (factored from dev-list and ChiPy mailing list):

return TRUE if a else FALSE
l = map(lambda x:'%s: "%s"' % (x[0], '""'.join(x[1]) if x[1][0] else ''), l)
b = if a[i] else a
1 if z in [1,'a',7,9] else 2

Of course, I have no clue what I just typed would actually work. That's not my point. The point is that I get some sort of understanding of each lines function by simply glancing at it. In other words, if I am reading through 1200 lines of code, this line would not throw me off so much as with one-liners from other languages, say C or PERL.

I usually wait until new language features are actually implemented and, usually, for them to appear in other sources before I even consider. For example, I am just now starting to use decorators. I trust the PSF and (in this case) BDFL who made the call on this one. I am excited about writing one-liners with this one, but only in Python.

So, I signed my first client.

Part of job is to add dynamic content to portions of a large commercial (mostly static) site. After a closer look, I realized the base content can be templated with Django's template system. Then I wrote a catch-all view and locate the page's old url from the model. So besides the headers and footers, the old content is now pulled in from the database itself. This was preferable because I was able to also give some versioning tools to the content itself (although static blocks).

So my setup looks something like this:

  Framework    Configure        Render
+------------+-----------+---------------------+  
|    v       | v         |                     |
|Apache2     |httpd.conf | Branding Logo       |
|mod_python  | v         |                     |
|    v       |settings.py| Navigation / Search |
|Python2.4   | v         |                     |
|    v       |url.py     | Navigation Crumbs   |
|Django      | v         |                  <------ (later: Login bar here)
|SQLObject   |view.py    | Content (cached)    |
|psycopg     | v         |                     |
|PostgreSQL  |model.py   | Footer              |
+------------+-----------+---------------------+  

This is the view:

def base(request,template="sample/base"):
   if request.path == "/" or request.path == "index.html":
      sp = get_object_or_404(staticpages, relative_page_url__exact="./index/")
   else:
      sp = get_object_or_404(staticpages, relative_page_url__exact=".%s" % request.path.replace("index.html",""))

   # low level cache
   key = "sample_static_%s_%s" % ( sp.id, sp.revision)
   content = cache.get(key)
   if content == None:
      content = sp.content
      cache.set(key, content, 30000)

   return render_to_response(template, {
      'title':sp.page_title,
      'meta':sp.meta,
      'js':javascript(request),
      'searchbar':searchbar(request),
      'crumbsbar':crumbsbar(request),
      'content':content,
   })

Also, having the content in the database allowed me easily to re-write the search engine. Good URL's do not change so I have things like "specifics/list.html" in the database.

For migration, I wrote a quick script to recursively grab the content from the static site and put it in PostgreSQL table created with Django.

The low-level cache (See the cache.get() method above) I added to speed up for these static pieces. I am so amazed how much faster these pages are being served. Even though they are now being pulled in from a database they are now faster than when they were being served as static content from a large web hosting agency. This is true with and without the cache. In concept the cache should be faster. Although I am having a hard time detecting the difference. I tried "file" and "memcache" methods. I am afraid this site is not the sort to be slashdoted, so I guess I need not concern myself too much.

btw, I used a Python framework called funkload to conduct load tests on Django. Seems fairly cool but a little bit overkill for what I need to test. Maybe simple webunit (I did not try) would have been easier.

Django is fast. Fast is setting up. Fast for fitting in with legacy item. And these pages load really fast. Not only faster than most JAVA and RoR sites, but faster than many static sites.

FileMerger.app (callable from the command line) has I nice built in file tree comparer. To run:

$ opendiff project1/ project2/

This opens FileMerger with a special databrowser for comparing file trees.

Merging can be done using keyboard commands. Useful.

My re-introduction into the web programming world is well under way. After careful evaluation on various web-programming frameworks, I have decided to start with Django for some serious contract work I am currently bidding on. Hence, I am now a Django developer--see the new Django section in this blog.

In the past, I have tried to stay away from web-work. The reason I venture to bid on such work is that the potential client is highly integrated with many types of media. My goal is to fulfill some very complicated tasks where many systems are are married with a web interface only being the tip of the iceberg. The only reason I stay away from some web-work is that it has been saturated with quite a few programmers who concentrate very little on good programming techniques, development philosophies, and quality assurance. I have said this before, but I still believe good programming and simply building a one-off website have very little in common.

Moving forward with my emphasis on sound techniques, I make specific reference to the MVC (Model View Controller) architecture used by Django. Taking it a step further, I broke these up into Roles:

• Role 1 Model) Highly Relational Database
• Role 2 View) Graphic Design of Reports, Forms, and Web Templates
• Role 3 Controller) Event Driven Dynamic Content Programming

And I needed to add some roles to the Administrative Side:

• Role 4 Hosting) System Administration, Security Management, and Backups
• Role 5 Administration) Data Entry, User Accounts

Roles 1-3, have separate hourly rates. Role 4, is a monthly rate. And Role 5 is handled by the client thanks to Django's Admin. interface which comes for free.

My MVC representation does not necessarily reflect MVC in the programming world 1-to-1. I simply present this abstraction as a way to break up the work into some business worthy logic. Furthermore, I can easily hand over pieces of these roles to different parties if it simply becomes too-much. So, Role 1 is the database programmer (or in Django, the person who builds the models), Role 2 is the Graphic Designer the person who builds the templates (not really the Views used in Django), and Role 3 is the person who writes the actual business logic in the views. It's best that Role 1 knows PostgreSQL and Python fairly well. The Role 2 person must know CSS, HTML, some Javascript/AJAX and general good design skills for template building. Role 3 should know Python and be proficient in all other areas because they will be the primary programmer who glues it all together.

For now, I am roles 1-4. Nevertheless, despite my butchering of MVC for business reasons, the real importance with my choice of Django over others is it's ability to be agile. "Agile" is term generally understood by business people and programmers, alike, regardless in how this is achieved.

I am a public transit advocate. I take my fat butt on the "L" to work every day. The other day, I took the bus just to get some real Mexican food. At first, I thought to myself I should be walking. But the fact that a very cool bus driver sung Christmas carols all the way confirmed to me I made a good choice on ridding the CTA.

CTA Chicago Transit Authority has it's problems. But well, at least we are still running. Unlike New Yorkers, who are currently walking themselves due to the labor strike situation--how terrible.

Let's look on the bright side.. no wait, let's look at the underside--the derriere. Many New Yorkers will get some badly needed exercise. On the flip side, Chicago Tribune writer Virginia Groark writes in Does this bus seat make me look fat? that the CTA has recently ordered seats enlarged from 17 1/2 inches to 18 inches.

As for you hard working Transit workers, I know your job is no piece of cake. I really do appreciate the many years you have taken my fat butt everywhere I've needed to go.

"There should be one-- and preferably only one --obvious way to do it." -- Tim Peters

Most people who know me know I am fond of Python. The biggest gripe I hear from programmers about Python is it feels restrictive, at first. Although, what I say in return is to think about with other languages how much time is waisted trying to adhere to all the best practices, DRY and Agile and so on, and work with a flimsy language. Some choices should be trivial and treated this way. Also, if your making something for someone else to use, the "how to" should be as self explanatory as possible.

Take whitespace in Python. One good thing about ChiPy is that I get to hear a lot of programmers talk about programming Python. Once a presenter said when he was first placing is Python code under version control he had done some thing really stupid, he said. He said that instead of converting his tabs to space, he checked them into source control as tabs. Now is this so bad? What is wrong with tabs under source control. For one thing, the tab size, three spaces or four... needs not specified.

I still think back to Guido van Rossum's April's fool joke in his blog. But seriously, why are people afraid of white space? And what is the proper way to handle it? Also, why does it seem some editors are so unfit for managing white space? Why are some programmers afraid to work off a restrictive foundation?

It seems to me, I am better off with Python being restrictive much the same way a carpenter feels comfortable with a rigid piece of wood. Through carefully tooling, the wood can be made pliable into whatever you want and without ever hindering productivity or creativity. Although, if you start with a flimsy piece of wood you can not do as much: not as quickly and not as concisely.

7 weeks is not too young for Maura's first computer lesson: