Officially Lucky link blog feed. By Clint Ecker

I’m now an iPhone owner :) (Torres Talking)

2008-07-14T00:42:05Z

I swore off the iPhone for at least a year when it was first announced. I had good reasons (to me at least). To recap:

I couldn’t synchronize with Exchange over the air (ADDRESSED)
Couldn’t swap the battery out for a better one
The EDGE network was/is so slow to be unusable (ADDRESSED)
It was a closed platform (ADDRESSED)
It was ridiculously, insanely expensive (ADDRESSED)
It was a v1 from a company that’s never built a phone before (ADDRESSED)
Typing on something without feedback won’t work
I didn’t want a phone that could get scratched easily
Functionally, it didn’t do more than my current phone (ADDRESSED)

I compromised on a few of these things – but Apple addressed the important ones. So I ended up waiting in line for 2.5 hours (I think it was actually more like 3!) yesterday morning to get one. I don’t even know where to start with this thing, I dig it so much; it’s easily the most excited I’ve been for a toy since I got my first PalmPilot in 1997 (the thing that started this addiction).

I likely won’t be writing too much about my iPhone though, for a few reasons: 1) I don’t want to gush, and I will end up gushing 2) I’m not blogging that much anyway - even though the iPhone is inspiring me to, 3) It’s been covered to death, 4) Anything I write can’t do justice to this little marvel.

So, just in case anyone cares, I now have an iPhone (syncing it with Windows Vista and Exchange Server of course). Using it is like having a magic wand ;)

Shared from Google Reader

Macenstein | Developers furious over App Store “Line Cutting” (macenstein.com)

2008-07-13T21:40:16Z

Clint: These Jirbo guys are jerks

There’s a bit of bad blood brewing between developers of iPhone Apps these days. It seems several different companies have renamed their iPhone games to begin with either a space, a quotation mark, or some other symbol so that they appear first in the list of 197 games on the iPhone portal to the App Store.

Shared from Google Reader

django-pagination - Google Code (code.google.com)

2008-07-13T21:17:48Z

Shared from Google Reader

DjangoCon Officially Announced (Empty Thoughts - Home)

2008-07-13T21:15:17Z

There’s been lots of discussion and hints over the past several days about a forthcoming Django based conference called DjangoCon. The official announcement was just released. I’ve always been fond of small intimate group settings and this one will certainly be that with only 200 attendees allowed to participate. I only hope that I get one of the coveted spots.

Shared from Google Reader

MobileMe doesn’t push from Mac to Me.com and handheld devices (JeffCroft.com: Latest bookmarks)

2008-07-13T20:37:55Z

Turns out, MobileMe doesn’t “push” changes to calendars and contacts made on your Mac to the Me.com web apps and your handheld devices. From an Apple Knowledgebase article:

Changes made on your computer will be synced to the MobileMe “cloud” once every 15 minutes (or every hour in Mac OS X 10.4.11).

Changes to calendars and contacts made on Me.com or on your iPhone will be pushed to your Mac immediately, but the reverse is not true. Strange. From Apple’s MobileMe features page:

MobileMe stores all your email, contacts, and calendars in the cloud and pushes them down to your iPhone, iPod touch, Mac, and PC. When you make a change on one device, the cloud updates the others. Push happens automatically, instantly, and continuously. You don’t have to wait for it or remember to do anything — such as docking your iPhone and syncing manually — to stay up to date

Emphasis mine. For many people, including me, a 15 minute sync time is probably just fine in real-world usage. But, it definitely seems contrary to how the service was promoted and demoed at the WWDC keynote, and I can definitely understand why so many people are complaining about it on the MacRumors forums and across the Internet. This sort of reeks of deception.

A couple things worth pointing out about this, for those wondering why it’s a big deal:

It’s an especially big deal for laptop users, who are prone to opening their laptop, adding a calendar event or contact, and then closing it again. If MobileMe really “pushed” from Mac to the cloud, then this behavior would be fine — the update has already made it to the cloud by the time the laptop is closed. If a user has to sit there, laptop open, for at least 15 minutes, to ensure the sync takes place, that sucks.
MobileMe isn’t all about the iPhone. It’s supposed to keep all your devices instantly in sync, including multiple Macs. Someone who doesn’t have an iPhone but has two Macs might want to keep their laptop in sync with their desktop. The old .Mac did this at a 15 minute interval, and MobileMe was promoted as an improvement that made the sync near-instantaneous. In reality, for this user, MobileMac is not an improvement at all — and that also sucks.

Visit site (http://www.macrumors.com/2008/07/13/mobilemes-push-services-detailed-no-mac-to-mobile-me-push/)

Shared from Google Reader

DjangoCon 2008 (The Django weblog)

2008-07-13T19:48:00Z

For the past year or so, people have been asking for us to hold a conference all about Django. Putting together a conference is an imense amount of work, so it took us a while to get the ball rolling. However, over the past couple of months we've found a few good volunteers who've taken on the task of planning a "DjangoCon," and now the dream is a reality!

For the details, I'll turn this space over to Robert Lofthouse, the conference chair:

I am pleased to announce that DjangoCon will be held on the 6th and 7th of September, 2008 at the Google headquarters in Mountain View. This will tie in with the 1.0 release of Django, and so we'll be also having a 1.0 release party on Saturday September 6th.

All the details including a schedule of speakers will be made available when we launch the conference website on Friday. Space will be limited to about 200 attendees, so we'll be releasing tickets in batches to give everyone a chance to come to the conference. Admission will be free, but we'll be asking for an optional donation to the Django Software Foundation to help cover our costs.

Thanks to everyone who has been helping out, and also thanks to Google for working so hard to get everything done!

I look forward to seeing those that can make it! It's going to rock!

— Robert Lofthouse, Conference Chair

Shared from Google Reader

Monkeypatching For Humans (Coding Horror)

2008-07-13T15:00:53Z

Clint: Can you not subclass the String class in other languages?

Although I love strings, sometimes the String class can break your heart. For example, in C#, there is no String.Left() function. Fair enough; we can roll up our sleeves and write our own function lickety-split:

public static string Left(string s, int len)
{
    if (len == 0 || s.Length == 0)
        return "";
    else if (s.Length <= len)
        return s;
    else
        return s.Substring(0, len);
}

And call it like so:

var s = "Supercalifragilisticexpialidocious";
s = Left(s, 5);

Fairly painless, right?

But with the advent of C# 3.0, there's an even better way -- extension methods. With an extension method, we "extend" the String to add the missing function. The code is fairly similar; I'll highlight the changed parts in red.

public static string Left(this string s, int len)
{
    if (len == 0 || s.Length == 0)
        return "";
    else if (s.Length <= len)
        return s;
    else
        return s.Substring(0, len);
}

And now we can call it as if this very method existed on the String class as shipped:

var s = "Supercalifragilisticexpialidocious";
s = s.Left(5);

Pretty slick. It's difficult not to fall in love with extension methods, as they allow you to mold classes into exactly what you think they should be. This is fairly innocuous in C#, as extension methods only allow you to add new functionality to classes, not override, remove, or replace anything.

But imagine if you could.

Well, that's exactly how it is in other, more dynamic languages such as Javascript, Python, Perl, and Ruby. Something as prosaic as C# extensions is old hat to these folks. In those languages, you could redefine everything in the String class if you wanted to. This is commonly known in dynamic language circles as monkeypatching.

If the idea of monkeypatching scares you a little, it probably should. Can you imagine debugging code where the String class had subtly different behaviors from the String you've learned to use? Monkeypatching can be incredibly dangerous in the wrong hands, as Avdi Grimm notes:

Monkey patching is the new black [in the Ruby community]. It's what all the hip kids are doing. To the point that smart, experienced hackers reach for a monkey patch as their tool of first resort, even when a simpler, more traditional solution is possible.
I don't believe this situation to be sustainable. Where I work, we are already seeing subtle, difficult-to-debug problems crop up as the result of monkey patching in plugins. Patches interact in unpredictable, combinatoric ways. And by their nature, bugs caused by monkey patches are more difficult to track down than those introduced by more traditional classes and methods. As just one example: on one project, it was a known caveat that we could not rely on class inheritable attributes as provided by ActiveSupport. No one knew why. Every Model we wrote had to use awkward workarounds. Eventually we tracked it down in a plugin that generated admin consoles. It was overwriting Class.inherited(). It took us months to find this out.
This is just going to get worse if we don't do something about it. And the "something" is going to have to be a cultural shift, not a technical fix. I believe it is time for experienced Ruby programmers to wean ourselves off of monkey patching, and start demonstrating more robust techniques.

Try to imagine a world where every programmer you know is a wannabe language designer, bent on molding the language to their whims. When I close my eyes and imagine it, I have a vision of the apocalypse, a perfect, pitch-black storm of utterly incomprhensible, pathologically difficult to debug code.

I was just looking at random PHP plugin code the other day, and it was, frankly, crap. But that's because most code is crap. Including my own. It is, sadly, the statistical norm. That's why sites like The Daily WTF are guaranteed to have more material than they can possibly ever publish for the next millennia. (Note to self: invest in this website). I can only imagine what that PHP plugin code would have looked like, had its developer been granted the ability to redefine fundamental PHP keywords and classes at will. These are the sort of thoughts that drive me to drink Bawls. And that stuff is disgusting.

You might say that PHP, sans the fundamental dynamic language ability to monkeypatch, is just another crappy Blub language. But there's also a ton of incredibly useful PHP code out there. So it seems to me that the ability to monkeypatch doesn't stop people from producing a huge volume of useful code, even in a kind of.. horrible language. Some of it is even good!

While I acknowledge the power and utility of dynamic language monkeypatching, I know enough about programmers -- myself absolutely included -- to know the vast majority of us have absolutely no business whatsoever re-designing a programming language. There's a reason some of the most deeply respected computer scientists in the world end up as language designers.

Perhaps then, given the risks, monkeypatching should mean reaching for the meta-hammer as infrequently as humanly possible. This is a position that Avdi himself espouses in a followup comment:

I'm afraid a lot of people have missed the actual meat of my argument -- that dynamic extension of classes is currently overused in Ruby, in ways that are:

Needless - another technique (such as a mixin, or locally extending individual objects) would have worked as well or better.
Overcomplicated - the use of a monkey patch actually created more work for the author.
Fragile - the solution is tightly bound to third-party internals, reducing the usefulness of the plugin or gem because it is prone to breakage.
Excessively wide in scope - by hardcoding extensions to core classes, the author takes the choice to scope the change out of the plugin/gem user's hands, further limiting utility.

My point is that there are alternatives - often alternatives which are actually easier to implement and will make your plugin or gem more useful to the user.

While I enjoy the additive nature of C# extensions, even those are enough to make me a little nervous, as mild as they are. Full-blown dynamic language monkeypatching goes even further; it might even be the ultimate expression of programming power. Is there anything more pure and godlike than programming your own programming language?

But if wielding that power doesn't scare and humble you a little, too, then maybe you should leave the monkeypatching to the really smart monkeys.

[advertisement] Read the largest case study ever published about lightweight peer code review in Best Kept Secrets of Peer Code Review. Free book, free shipping.

Shared from Google Reader

Premium Rock Band 2 Drum Kit Surfaces: "Badass" Is The Word You're Looking (Gizmodo)

2008-07-13T05:51:15Z

Shared by Herschell / Special*Dark Liana sez: With a drumkit like THAT... who the hell would even want to touch that old guitar. lol.

I play Rock Band like a champ, and when I'm with my crew I'm usually on drums. I'm a drummer, and I love playing them, and the included drum controller always seemed just fine to me. Kotaku found this photo of the premium Rock Band 2 kit and I've decided I must have it. UPDATE: OK, so this kit doesn't ship with Rock Band 2, it's an $300 optional purchase. [Kotaku]

Instead of just four heads, the badass looking kit gives you four heads, hi hat, crash, and ride cymbals. This kit, which will come with Rock Band 2 certainly beats the Guitar Hero: World Tour offering, but it also signals something unusual: the start of a music games arms war. I hope they bring it hard.

Shared from Google Reader

Protocol buffers: the early reviews are in (dive into mark)

2008-07-13T04:19:40Z

Google (my current employer) has finally open sourced protocol buffers, the data interchange format we use for internal server-to-server communication. The blogosphere’s response? “No wireless. Less space than a Nomad. Lame.”

Aaaaanyway…

Protocol buffers are “just” cross-platform data structures. All you have to write is the schema (a .proto file), then generate bindings in C++, Java, or Python. (Or Haskell. Or Perl.) The .proto file is just a schema; it doesn’t contain any data except default values. All getting and setting is done in code. The serialized over-the-wire format is designed to minimize network traffic, and deserialization (especially in C++) is designed to maximize performance. I can’t begin to describe how much effort Google spends maximizing performance at every level. We would tear down our data centers and rewire them with $500 ethernet cables if you could prove that it would reduce latency by 1%.

Besides being blindingly fast, protocol buffers have lots of neat features. A zero-size PB returns default values. You can nest PBs inside each other. And most importantly, PBs are both backward and forward compatible, which means you can upgrade servers gradually and they can still talk to each other in the interim. (When you have as many machines as Google has, it’s always the interim somewhere.)

Comparisons to other data formats was, I suppose, inevitable. Old-timers may remember ASN.1 or IIOP. Kids these days seem to compare everything to XML or JSON. They’re actually closer to Facebook’s Thrift (written by ex-Googlers) or SQL Server’s TDS. Protocol buffers won’t kill XML (no matter how much you wish they would), nor will they replace JSON, ASN.1, or carrier pigeon. But they’re simple and they’re fast and they scale like crazy, and that’s the way Google likes it.

Shared from Google Reader

Zooey Deschanel Web Gallery: Click image to close this window (FFFFOUND! / EVERYONE)

2008-07-13T01:02:34Z

via http://zooey-deschanel.us/gallery/displayimage.php?pid=7528&fullsize=1

Shared from Google Reader

ignore the code » iPhone, third-party applications and Settings.app (ignorethecode.net)

2008-07-13T00:15:58Z

Apple should either update Settings.app to support the features developers need, or change its HIG, telling devs not to put settings into Settings.app, but to keep them in their applications.

If Apple decides to update Settings.app, applications should turn preferences which users want to change regularly - such as whether the user sees completed items or just available actions - into “regular” application features accessible outside the application’s preferences.

Either way, the current situation is confusing, as it is never clear where a particular application’s settings can be found.

Shared from Google Reader

Thrift vs. Protocol Buffers - Digital Digressions by Stuart Sierra (stuartsierra.com)

2008-07-13T00:00:19Z

Overall, I think Thrift wins on features and Protocol Buffers win on
documentation. Implementation-wise, they’re quite similar. Both use
integer tags to identify fields, so you can add and remove fields
without breaking existing code. Protocol Buffers support
variable-width encoding of integers, which saves a few bytes. (Thrift
has an experimental output format with variable-width ints.)

The major difference is that Thrift provides a full client/server RPC
implementation, whereas Protocol Buffers only generate stubs to use in
your own RPC system.

Update July 12, 2008: I haven’t tested for speed, but from a cursory examination it seems that, at the binary level, Thrift and Protocol Buffers are very similar. I think Thrift will develop a more coherent community now that it’s under Apache incubation. It just moved to a new web site and mailing list, and the issue tracker is active.

Shared from Google Reader

Friendfeed view source (Bill de hOra)

2008-07-12T22:30:05Z

Friendfeed - nice service. I pulled this Atom Entry out of my Friendfeed feed:

<entry>
    <title type="text">Free as in electricity (via Blog)</title>
    <updated>2008-07-12T15:33:12Z</updated>
    <published>2008-07-12T15:33:12Z</published>
    <id>tag:friendfeed.com,2007:1d0c3524-1c88-d01e-5864-21953bef1ca1</id>
    <link href="http://www.dehora.net/journal/2008/07/12/free-as-in-electricity/"
       rel="alternate" type="text/html"/>
    <content type="xhtml" xml:base="http://friendfeed.com/">
       <div xmlns="http://www.w3.org/1999/xhtml"
       style="font-size:10pt;font-family:Arial,sans-serif;color:#222222">
          ...
       </div>
    </content>
</entry>

Here's the original Entry from my feed:

<entry>
<id>http://id.dehora.net/entry/2008/07/12/ea18ed947f5ba3e06ff02528f7e6b150</id>
<title>Free as in electricity</title>
<updated>2008-07-12T15:59:34Z</updated>
<author>
    <name>Bill de hÓra</name>
   </author>
   <link href="http://www.dehora.net/journal/2008/07/12/free-as-in-electricity/" rel="alternate"></link>
   <content type="html"><p> ... </p> </content>
</entry>

Some observations:

The Friendfeed updated value happened a few minutes before mine did. It doesn't seem to be a multiple of anything, so let's assume it's a clock skew. What's interesting there is that Friendfeed's Entry could show up after mine in an aggregated feed.
The Friendfeed Entry doesn't have an author element. The enclosing feed did have one, and the author is "Friendfeed", which means the author of that Entry is "Friendfeed", not me. I guess that makes sense. Or maybe it doesn't.
Friendfeed added their own id. It's a Tag URI that has a uuid embedded. This makes me think their backend is decentralised or at least has the potential to be. The date part of the tag appears to be hardcoded to 2007.
Friendfeed munged the original title with a suffix. They added a type of text/html as well. I wonder if that was derived or assumed. And I wonder what would happen if the source type was set to say, xhtml. In any case what's nice about my use of Atom here is that Atom Text constructs have well-defined escaping rules - unlike RSS2.0, there's no need to second guess the upstream provider (unless it's borken).
Friendfeed have copied the link@rel=alternate across. They've added a type of text/html. Again I wonder if that was derived or assumed. It would be interesting to have a JSON alternate.
Friendfeed have written out their own content. That's fine; what's notable is not providing a summary of the original. Or maybe that's because I don't server summaries, just full content.
Friendfeed use xml:base. It would be interesting to see if what would happen if relative URLs were in the source title, which seems to have been copied into their content.
Friendfeed are not proxying or rewriting upstream links. A naive system would do something like that for tracking reasons, and eventually melt down under load. The only interesting redirect walling they perform is to route the "link to this entry option" on the site back to their permalink and not mine. The slug for the permalink is the same as the uuid in the tag URI.

But for a syndication wonk, by far the most interesting thing is that Friendfeed aren't using the Atom source element. The feed could have looked like this:

<entry>
    <title type="text">Free as in electricity (via Blog)</title>
    <updated>2008-07-12T15:33:12Z</updated>
    <published>2008-07-12T15:33:12Z</published>
    <id>tag:friendfeed.com,2007:1d0c3524-1c88-d01e-5864-21953bef1ca1</id>
    <link href="http://www.dehora.net/journal/2008/07/12/free-as-in-electricity/"
       rel="alternate" type="text/html"/>
    <content type="xhtml" xml:base="http://friendfeed.com/">
       <div xmlns="http://www.w3.org/1999/xhtml"
       style="font-size:10pt;font-family:Arial,sans-serif;color:#222222">
          ...
       </div>
    </content>
    <source>
   <id>http://id.dehora.net/entry/2008/07/12/ea18ed947f5ba3e06ff02528f7e6b150</id>
       <updated>2008-07-12T15:59:34Z</updated>
   <link href="http://www.dehora.net/journal/2008/07/12/free-as-in-electricity/" rel="alternate" />
    </source>
</entry>

Not many people seem to use Atom source. It can contain the whole original entry, but the most useful parts to pass along are the id and the updated elements. Why? Well, aggregators and clients can immediately pick those out, tell you if you've smelt what the Friendfeed is cooking and mark it as read. In this particular case the fact that Friendfeed's outer updated date is ahead of the source might confuse some code, depending on the implementation logic. Possibly they should consider treating updated as an offset to the original Entry timestamp. It might not be precise relative to a particular server/system but globally it will be more accurate and the partial ordering would be preserved. You could also put the source author in there as well ;)

Shared from Google Reader

django-app-plugins - Google Code (code.google.com)

2008-07-12T17:16:08Z

Allow 3rd party apps to dynamically insert template inclusions into your apps at pre-defined plugin points. Similar to how Eclipse manages plugins via contributors.

You could think of this as the reverse of the {% block %} or {% include %} tags.

templates/myapp/foo.html: {% load app_plugins %} {% plugin_point "foo" %}

templates/otherapp/plugins/foo.html: Anything you want...

templates/thirdapp/plugins/foo.html: yet another plugin...

foo.html is rendered as: Anything you want... yet another plugin...

Shared from Google Reader

django-timezones - Google Code (code.google.com)

2008-07-12T17:15:56Z

A Django reusable app to deal with timezone localization for users.

Shared from Google Reader

django-email-confirmation - Google Code (code.google.com)

2008-07-12T17:15:45Z

django-email-confirmation

This simple app is for cases where you don't want to require an email address to signup on your website but you do still want to ask for an email address and be able to confirm it for use in optional parts of your website.

Shared from Google Reader

django-mailer - Google Code (code.google.com)

2008-07-12T17:15:34Z

django-mailer

A reusable Django app for queuing and throttling of email sending, scheduled sending, consolidation of multiple notifications into single emails and logging of mail failures.

Shared from Google Reader

django-robots - Google Code (code.google.com)

2008-07-12T17:14:43Z

The robots exclusion application consists of two database models which are tied together with a m2m relationship:

Rules
URLs

Shared from Google Reader

Cloud27 - A Social Network (Empty Thoughts - Home)

2008-07-12T16:26:47Z

This morning I got my first glimpse of what will become Cloud27, featuring a sporty design by Greg Newman, and I already like what I see. Cloud27 is a new social network based on Pinax, a Django reference application for reusable applications.

So if there’s Pinax, why Cloud27? Well Pinax is where all development and new ideas happen. Pinax is project intended to provide a starting point for websites. Cloud27 will actually be focussed on building out on the base of Pinax and expanding it into a kick-ass social network application.

To find out a whole lot more about reusable applications and Pinax, I highly recommend a listen to This Week in Django 24, featuring Pinax / Cloud27 founder James Tauber.

I’ll be keeping an eye on Cloud27.

Shared from Google Reader

Two New Great Books (Empty Thoughts - Home)

2008-07-12T16:06:33Z

There seems to be a plethora of Python related books coming out these days. I just stumbled across two interesting ones. First up is Essential SQLAlchemy. I desperately want this book but I’m tired of paper books. It’s available on Safari Online, but I don’t have that. I’d really like to see a Kindle version. I’ll probably end up buying the paper, because it looks to be very exciting.

Secondly is The Definitive Guide to Pylons. This book is offered as a free beta book, but will also be available for purchase through Apress. I’ve skimmed the contents but plan to spend some time with it in the coming week. I’m really interested in the Deployment chapter, so I’ll probably start there first.

Shared from Google Reader

Say it ain’t so, Mike! (BuzzMachine)

2008-07-12T15:42:30Z

Clint: Ha ha ha ha ha

Kara Swisher says that Techcrunch and AOL are in acquisition talks. Oh, no. AOL is where things go to die.

Shared from Google Reader

Dave Johnson: My personal iPhone3G debacle (Ryan Irelan)

2008-07-12T15:41:40Z

Clint: They just swiped our CC, threw the iPhones in a bag and told us to activate them ourselves at home

Dave Johnson: My personal iPhone3G debacle - “2:55PM Cheers erupt as the customer who was 1st in line at 8AM finally gets activated.” Wow.

Shared from Google Reader

Caught up in the iPhone 3G fever (sbdc)

2008-07-12T14:35:33Z

Shared from Google Reader

iPhone Settings (Michael Tsai's Weblog)

2008-07-12T14:05:12Z

Ken Case (via Lukas Mathis):

Settings which appear in the built-in Settings application can’t have any code associated with them, they can only use standard controls which store data in a few limited data types. We wanted to provide the ability to copy synchronization settings from a Mac on your local Wi-Fi network, which involves code—making it impossible to put our settings in the global Settings application.

The above point makes this moot, obviously, but in general another important factor to consider is whether the user might change a setting more than once or whether it’s really just a one-time configuration. If you’re talking about something like Mail settings, it’s pretty much fire and forget—but in OmniFocus’ case, the user might want to quickly switch between looking at all their completed items and then switch back to looking at just their available actions, and they wouldn’t want to have to relaunch OmniFocus each time they did this.

It’s not clear to me why Apple wants applications to use Settings, except that it reduces the need for a button in the application. It’s a pain to have to quit an application to change a setting, and it’s not always clear what’s a setting and what’s application data. I’ve only changed the locations in the Weather application maybe half a dozen times in the past year, yet I’m happy with them being in the application rather than in Settings.

Shared from Google Reader

Worst Fears Ease, for Now, on Mortgage Giants’ Fate -... (kung fu grippe)

2008-07-12T14:00:00Z

Worst Fears Ease, for Now, on Mortgage Giants’ Fate - NYTimes.com

If you aren’t worried about how dangerously fucked the economy and infrastructure of this country are, you’re either not paying attention or you already have a plan for offing yourself.

Shared from Google Reader

Officially Lucky link blog feed. By Clint Ecker

I’m now an iPhone owner :) (Torres Talking)

Macenstein | Developers furious over App Store “Line Cutting” (macenstein.com)

django-pagination - Google Code (code.google.com)

DjangoCon Officially Announced (Empty Thoughts - Home)

MobileMe doesn’t push from Mac to Me.com and handheld devices (JeffCroft.com: Latest bookmarks)

DjangoCon 2008 (The Django weblog)

Monkeypatching For Humans (Coding Horror)

Premium *Rock Band 2* Drum Kit Surfaces: "Badass" Is The Word You're Looking (Gizmodo)

Protocol buffers: the early reviews are in (dive into mark)

Zooey Deschanel Web Gallery: Click image to close this window (FFFFOUND! / EVERYONE)

ignore the code » iPhone, third-party applications and Settings.app (ignorethecode.net)

Thrift vs. Protocol Buffers - Digital Digressions by Stuart Sierra (stuartsierra.com)

Friendfeed view source (Bill de hOra)

django-app-plugins - Google Code (code.google.com)

django-timezones - Google Code (code.google.com)

django-email-confirmation - Google Code (code.google.com)

django-email-confirmation

django-mailer - Google Code (code.google.com)

django-mailer

django-robots - Google Code (code.google.com)

Cloud27 - A Social Network (Empty Thoughts - Home)

Two New Great Books (Empty Thoughts - Home)

Say it ain’t so, Mike! (BuzzMachine)

Dave Johnson: My personal iPhone3G debacle (Ryan Irelan)

Caught up in the iPhone 3G fever (sbdc)

iPhone Settings (Michael Tsai's Weblog)

Worst Fears Ease, for Now, on Mortgage Giants’ Fate -... (kung fu grippe)

Premium Rock Band 2 Drum Kit Surfaces: "Badass" Is The Word You're Looking (Gizmodo)