by Peter Seibel
-- A fantastic collection of interviews with 15 famous programmers. Contains some great history and insights on the field of "computer science."
-- Geeks, drugs, and deception. An entertaining look into the (fictional) lives of techno con artists, and how a recently-fired comic book artist get pulled into their inner circle.
"
-- Particularly useful reference when trying to eek out a few extra milliseconds of load times in older browsers.
-- Interesting tech, and somewhat engaging, but disappointing ending (or lack thereof.)
, by Neil Strauss
-- An engaging, first-person account on transforming from an urban writer into "Jason Bourne."
, by Cory Doctrow
-- A high school hacker fights the 'Department of Homeland Security' to reclaim American civil liberties after anti-terror tactics are taken to a new level.
-- Techniques-for, and the value-of sketching interactivity before developing products. Good ideas. OK book.
" -- About finding untapped opportunities in your market and repositioning yourself to capitalize on them. Easy to grasp; Longer then it needed to be.
" -- A thin book with some good best-practices, but a little disappointing. Perhaps it's JavaScript's fault, not the author's ;-)
" -- Good overview of usability issues in designing HTML forms, backed by examples and eye-tracking research. I bought the 
" by Marshall Goldsmith
-- Discusses interpersonal skills (and how to identify and fix them) that most commonly hold executives back in their career advancement.
"
-- Lesson: Cut the corporate B.S. and stop wasting your time. Focus only on what matters most.
"
-- Lessons on handling tough conversations: firing people, relationship problems, hostage negotiations (well, maybe not that last one.) Wasn't an exciting read, but I've been paying more attention to "turning points" in conversations since reading it.
"
-- Lessons in building reusable ("pluggable") Django applications. Assumes you know the basics of Django and Python.
"
-- I really enjoyed this one. Lots of suggestions and strategies for negotiating.
I’m back from PyCon 2007. It was a busy weekend, with 593 Pythonistas attending the conference. I took a fair amount of notes, but I’ve pulled out some highlights below:
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”:
- Use good tools. “Open source is better because it’s better.”
- Avoid dogma. Don’t get stuck on what language something is implemented in.
- 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.
- “Methodologies” suck. Ex., MVC is cool, but Django abuses it because it doesn’t fit so well with the web.
- DRY — Don’t Repeat Yourself. The one methodology to use.
- 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.
- 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.
- 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.
- 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!
- 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.
- 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.
