In praise of git’s index
In this kind of workflow, the meaning of
git diffbecomes “work I haven’t reviewed yet” or “work I don’t want to commit yet” andgit diff --cachedbecomes “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.
Introducing Herd Fire
If you, like me, are an avid Firefox user, you will likely have felt the burden of using the same Firefox profile for a variety of tasks. Having NoScript or ImgLikeOpera installed is handy when surfing, but just annoying when working on developing websites. Having FireBug installed will slow down JavaScript execution on all pages, unless you disable some of its features, regardless of whether you're using it or not. Every extension you install slows down Firefox ever so slightly.
And that just extensions. Same goes for many aspects of Firefox configuration, language, about:config, etc. Would it not be better to have several Firefox profiles, one for each task? If you ask me, it would.
One problem though – even if you find the hidden Firefox profile manager, Firefox will not let you launch multiple instances of it without a bit of coercion. Previously, I resorted to all kinds of commandline trickery to manage my profiles until I found a script somewhere on the web (I've been unable to find it again. If you know it, please post a comment – I'd like to give proper attribution) that helped me set up copies of Firefox.app for each profile, but it had its limits. It did not work for Firefox.app itself, only for its named copies. It also renamed the Firefox binary, causing trouble for other scripts. So I've rewritten it in Python, improving a few key things:
- It modifies
Info.plistto use a launching script instead of renamingfirefox-bin. - It sets the normal Firefox.app to use the profile named “default”.
Instructions for use
- Download Herd Fire.
- Copy your Firefox.app to create a named copy (I'm using the name “_example_” here):

- Run Herd Fire ( run it from the folder its located in, or stick it in a folder on your path):

- Launch your new Firefox copy.

- If there is not a Firefox profile with the extra name you gave your
Firefox.app copy (in this case “example”), the profile manager will appear.
In that case, use it to create a new profile with the correct name.


- Firefox-example.app will now always start with the “example” profile
activated. Firefox auto updater might break this. In that case, all
you need to do is to run
herdfileagain.

The code is in a GitHub repository, so please don't hesitate to fork, file bugs, etc.
Programming is not easy
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.
What you need to know about secure password schemes
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.
PostgreSQL expert suggestions for Django
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
Making browsers faster: Resource Packages
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.
Comparison of different SQL implementations
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.
Drupal or Django?
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/
Jason Kasper is tired of Desktop Linux
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/