Mikkel Høgh

In this kind of workflow, the meaning of git diff becomes “work I haven’t reviewed yet” or “work I don’t want to commit yet” and git diff --cached becomes “work I have vetted for inclusion in the next commit”. The index is what makes this possible.

I don’t know how I ever worked another way.

While I use GitX to do the heavy lifting, my workflow is more or less the same, and when I use SVN or similar tools, I find that I spend a lot of time mucking around in my files to only commit what I want to at a given time. Those fixes on line 79-84 needs to go out now, but the untested feature I was working on on line 343-359 is not ready for prime time. I do things like that almost every day, and git saves me so much time.

Visit: http://plasmasturm.org/log/gitidxpraise/

Bryan Woods on why we should not think that programming is easy:

Every single time (and this will happen constantly) you come across a concept that seems foreign or difficult or even just unintuitive, instead of thinking "It's OK. Programming is hard." you're going to be thinking "This is supposed to be easy. What's wrong with me? I must be stupid." These feelings will keep you from seeking help or pushing through to discover why things work the way they do, and that is what's stupid.

Highly recommended reading.

Visit: http://writing.bryanwoods4e.com/

An enlightening perspective on the relative weakness of the password schemes used by many systems like Drupal and Django. Drupal 7 has stretched hashes, but I’ll have to look into how I can make my Django apps more secure. Currently, they use a simple salted SHA1, but we can do better.

Visit: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

Josh Berkus has some excellent suggestions on how Django could be improved to take advantage of PostgreSQLs capabilities.

I find myself agreeing, and in particular with this:

Allow the Use of Schema in Place of App Names: currently Django prefixes all table names with the "app name" resulting in table names like legacyauth_userpreference. This makes sense on databases with no schema support, but it would be great if, on Postgres, Oracle and other DBs with good schema support, Django would support replacing that "_" with a "." so that we could use real schema.

Django’s current table naming scheme hurts my eyes, so this would be a definite improvement…

Visit: http://it.toolbox.com/blogs/database-soup/stuff-id-love-to-see-from-django-36278

Alexander Limi has an excellent proposal as to how we could improve page loading speed:

What if there was a backwards compatible way to transfer all of the resources that are used on every single page in your site — CSS, JS, images, anything else — in a single HTTP request at the start of the first visit to the page? This is what Resource Package support in browsers will let you do.

Getting this implemented in all major browsers will be an uphill battle (I'm looking at you, Internet Explorer), but it would be a tangible improvement for anyone who has a browser that supports it.

Visit: http://limi.net/articles/resource-packages/

By fellow Dane, Troels Arvin:

The following tables compare how different DBMS products handle various SQL (and related) features. If possible, the tables also state how the implementations should do things, according to the SQL standard.

This is very thorough and interesting. It does a really good job of explaining why creating applications that run on multiple database platforms is a hard thing.

It's encouraging to see that my favourite RDBMS, PostgreSQL seems to lead the pack (although it has a few transgressions of its own.

There's little good to say about MySQL in this comparison. Several flagrant violations of the standard and slow to adopt new SQL features.

Visit: http://troels.arvin.dk/db/rdbms/

An enlightening perspective on a complex issue.

If I had the choice, I’d pick Django simply because I prefer Python to PHP and find Django to be more productive. Prototyping and debugging PHP is very crude by comparison to Python. Much of Drupal’s convoluted architecture and reliance on naming convention “magic” to provide quasi-inheritance is due to the limitations of PHP. I often say, half-seriously, that Drupal is good despite PHP, not because of it.

and:

In the end, a good developer can do good work with just about any system, while a bad developer can make mincemeat of even the best system. It’s not all about the platform.

Picking the right tool for the job has never been easy. The best advice I can give: Be pragmatic.

Visit: http://birdhouse.org/blog/2009/11/11/drupal-or-django/

It seems that Mac OS X is where a lot of open source developers are heading nowadays.

You know… you get a computer to do stuff, and you want it to work. You don’t care what it has to do so that it works. You just want it to stinking work. Wouldn’t it be nice if Desktop Linux was like that?

My sentiments exactly. I took the jump to OS X 18 months ago, and while the idea of open source for everything is good, but the amount of time and frustration I've saved by switching is staggering.

I still enjoy fiddling with FreeBSD on my servers, but for my desktop, I'd like it all to "just work".

Visit: http://movingparts.net/2009/11/10/i-think-im-tired-of-desktop-linux/

So apparently, Apple makes more money selling mobile phones than Nokia.

The firm estimates that Apple’s iPhone operating profit came in at $1.6 billion in Q3, while Nokia recorded only $1.1 billion in operating profit.

In just two years. That's gotta hurt.

Visit: http://blog.telephonyonline.com/unfiltered/2009/11/10/apple-beats-nokia-for-world%E2%80%99s-most-profitable-handset-maker/