ianb is currently certified at Journeyer level.

Name: Ian Bicking
Member since: 2001-03-06 20:19:46
Last Login: N/A

FOAF RDF Share This

Homepage: http://www.colorstudy.com/ianb

Notes:

I program mostly in Python. Okay, almost completely in Python. Once upon a time I wanted to be rounded, now I'm happy being niche.

Besides Python, I spend some of my computer-thought doing tech for Chicago Indymedia, since Free Software not the highest justice we can seek, and proprietary software not the greatest injustice.

Projects

Recent blog entries by ianb

Syndication: RSS 2.0

Funny how people get weird about style issues. Me too, I guess. There's a certain territorial aspect to it. Combined with the intuitive Rightness of one style over another... the Rightness creates conflict, the intuition means people can't argue very usefully about it.

Seeing this, of course people decide that style isn't a useful thing to discuss. They get short about it, seeing it as troll talk.

I don't think that's quite right, though. I like systems because they feel right. I design systems intuitively -- and I think that's the way good design has to be done. You need to envision the entire thing, which has a certain gestalt aspect to it. You can't work towards a great design, except by experimentation and iteration. Even then at some point you simply have to arrive at it. It's all about feel. So I think the feel of something is very important. An elegant system feels good. That's pretty important.

Did some C programming today, which I haven't done in quite a while. First run at a small CGI program to interface with the Webware application server -- hopefully being in C it will start up considerably faster than the Python-based version. C is awkward, but I actually quite enjoyed it -- dealing with pointers and such is refreshing, and I haven't programmed in anything but Python (and a little PHP) for many months. Heck, I hardly even program shell scripts anymore... that'll get a person stuck in a conceptual rut.

But I'll be back to Python tomorrow, I imagine.

Spent yesterday writing testing documents for work. Oh, that hurts. It's like all the exactness and tedium of programming, but with absolutely none of the satisfaction. I felt like I was writing copy -- something I really should do for my website as well. Wish I could automate more of the testing... not sure how to do that for a website, though.

dyork: (tree program) os.path might use statcache, I don't know, but you may be able to optimize your code by using os.stat instead of islink, and isdir. It also would be more correct, as your current program seems to treat all symbolic links as directories. I think it's certain to save at least a little speed, maybe a fair amount (since stat's disk access is probably the biggest performance issue). Also, it's nearly as easy to pass the full path (relative to cwd or not) as it is to change directories, and this will probably also be a little faster. I think this is a case where the smallest version of the program you can write will be the fastest (as long as that means that each file gets stat()ed only once).

Spent yesterday reading through the code for Webware. I understand it a lot better -- the factoring reminds me of Smalltalk. Wrote a document trying to describe how it all fits together.

I realized that most documentation fits two models: tutorials/users guides, and reference documents for the developers. I think that leaves a big gap, for someone who wants to become a developer on the project, and is already a programmer. Being confronted with a pile of code can be very intimidating, not to mention frustrating. You change a piece of code only to find out it doesn't get called when you think it will, or you search in vain to find the code that corresponds to a certain behavior -- you may never find it, the section of code you imagine may actually be scattered across the entire program because you have the wrong model as to the inner workings. Reference documents don't help you there. At best they infer a model, in a vague sort of way.

Webware was pretty bad that way. A lot of generality, classes are often not referred to concretely (since part of customization can be creating subclasses of core components), and a mess of methods passed back and forth. Not so bad when you understand it, but I had to struggle some to figure it out. (that said, I think it is well programmed and very compact... I wouldn't want to even start were it programmed in Perl... it's just complicated and has a lot of hooks for future growth).

I always enjoy code maps, more people should write them. They address concretely what's probably the most important part of the program -- the architecture.

7 older entries...

 

ianb certified others as follows:

  • ianb certified futility as Apprentice
  • ianb certified ianb as Apprentice
  • ianb certified superuser as Apprentice
  • ianb certified Johnath as Apprentice
  • ianb certified srl as Apprentice

Others have certified ianb as follows:

  • superuser certified ianb as Apprentice
  • ianb certified ianb as Apprentice
  • carmstro certified ianb as Journeyer
  • ian certified ianb as Apprentice
  • srl certified ianb as Apprentice
  • mvo certified ianb as Apprentice
  • quarl certified ianb as Journeyer
  • insom certified ianb as Journeyer
  • oubiwann certified ianb as Master
  • araumntl06 certified ianb as Apprentice
  • asaddi certified ianb as Master
  • eopadoan certified ianb as Master
  • percious certified ianb as Master
  • mnot certified ianb as Master

[ Certification disabled because you're not logged in. ]

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page