Drupal High

finding old versions of firefox

krs — Wed, 21 Jan 2009 19:29:21 -0800

It took me a while to find a good source of old versions of Firefox. The need arose while trying to reproduce a bug that the client reported only happened using Mac Firefox 3.0.1 (several versions back).

Most of the places that link to Firefox downloads update to point to the most recent release. A few that did have old version were windows only, and I needed the Mac release! Even Mozilla's website, usually the reliable source only had links to 2.0.0.5

So, back to the old FTP Site.

ftp://ftp.mozilla.org/pub/firefox/releases/

It has everything! All operating systems, all versions back to 0.10 it seems, and all languages! Should make future QA much simpler.

Git for Mac OS X

krs — Mon, 20 Oct 2008 17:50:58 -0700

Installing git, the newest version control tool, on a mac is kind of a pain. There's lots of sites pointing you to compile it from source, or use macports to do the same for you. Finally found a mac native version (command line), at google code, with versions for intel and ppc macs.

Git for Mac OS X : http://code.google.com/p/git-osx-installer/

This took some hunting around, so I thought I'd post it here in case anyone else has to go through it. Thanks Google!

BADCamp 2008 report

krs — Thu, 16 Oct 2008 00:20:09 -0700

Well, BADCamp had another incredibly successful year. I lived in Berkeley for 10 years, so I always make sure to go to this camp as a chance to see old friends in between sessions and nights out getting drupal-drunk. Great venue, lots of free wireless access, gallons of coffee, and a plethora of doughnuts, bagels, and snacks. (Yes, I do know what it means to have a plethora.) Yummy organic cheap eats nearby. A free t-shirt even! And a sponsored (ie free beer) party at Jupiter, and they were nice enough to let in all us shabby programmers :) Thanks to all the organizers, especially Tao and Jen and all the sponsors!

Friday night brought my favorite of all activities, dinner at Chez Panisse in north Berkeley. If you haven't been, you're missing out on some of the best food on the west coast, even if you do have to eat late cause you made your reservation at the last minute :) And honestly, its really not that epensive, especially if you eat upstairs at the "cafe". Two and a half hours and 3 desserts later, and I was well fortified for battling nodes, themes, and even simepletests all weekend long.

The presentations over the next two days were mostly very polished and informative, thanks to everyone who gave a talk, I thought the quality was very nice. Mine seemed to be fairly well received, and I hope I was able to create a few new drupal devs. The installfest seemed to go really well, and thanks to Chris Bryant some weird configurations managed to get their copies of core up and running smoothly. I use xampp on a mac for ease-of-use, but there was still plenty to figure out when I first set it up those months ago. Good to remember its often not that easy, especially if
you're not used to working with a command line or server tools.

Saturday night there was a small, but active, testing party to get some simpletest patches reviewed and into core. As chx, flobruit, and dmitrig01 explained, we're still pretty far from 100% core code coverage, so there's still plenty of opportunity to get involved. Getting into test writing is not hard, and reviewing tests is even easier.

Chapter3 has been hiring and brought a crew of friendly folks. WorkHabit had a lot of staff and volunteered (again!) to do all the A/V recording for the event. Achieve managed to bring up 5from San Diego, and the LA Drupal group was well represented as well.

Flew back Sunday night full of new Drupals and impressed as always by the great community and spirit behind Drupal. Overall a great trip that didn't cost a lot of nodes, I can't wait to be back next year :)

Now we roll into the holidays and the camp schedule winds down significantly. I heard a rumor that the next DrupalCon is going to be Washington, DC - my hometown! Going to start planning as soon as its official. That won't be until early next year, so its back to the grindstone for me until then.

Stop sharing a default settings.php

krs — Mon, 22 Sep 2008 23:52:47 -0700

Many times when working on a site, you are writing code and testing it locally first, before you even commit it to the development repository. Too often I've seen teams all share one sites/default/settings.php file, which leads to accidental commits which can halt everyone's development until the problem is resolved.

You can easily resolve this with 3 easy steps!

1. Create a local settings.php.

Whatever you named your site on your local server, create a sites/example_site/settings.php file. This is where all the settings go that will just apply to local dev environment. You're free to set your or database name, db user and password, or you can change php's error reporting level and available memory, and those are just some commonly useful adjustments. You can use the $config array to define some witewide variables, then you don't have to worry about changing things back whn you go to a new server (that server would have its own independent settings.php file).

2. Keep your local settings.php out of the code repository.

No one else wants it, its just for your desktop box. How do you do this? If you're using an IDE, most of them will let you add files or directories to svn:ignore. Poof! it will sit happily on your machine and be ignored - never to be committed accidentally. If you're just using the command line svn tool (may be different on a windows OS), use the more cryptic (cd to drupal root) svn propedit svn:ignore sites*, which will open a text editor for you. Add the line example_site (whatever you named your directory above), save and close. You should see the status message "Set new value for property 'svn:ignore' on 'sites'", and your new directory and the settings.php file within should be safely ignored.

3. Get rid of sites/default/settings.php!

Its tempting to keep this file around, and for smaller sites its probably ok. But when you move to large team development, and having more test environments (typically: local -> shared dev -> qa/stage -> prod), you don't want this dangerous fellow around. Your site should have basic configuration details for each of those servers, and you want to be sure what settings you are running. Its too easy to change a default settings.php "just to test something out", not realizing it may also be in use on other servers. You may not even find out until much later, when the code is actually deployed to a new server.

* If you havent set up a default shell editor, you may get an error message like "svn: None of the environment variables SVN_EDITOR, VISUAL or EDITOR is set, and no 'editor-cmd' run-time configuration option was found". This just means SVN didn't know where to find an editor to use. Instead try svn propedit --editor-cmd pico svn:ignore sites, and replace pico with your editor of choice. If you don't have an editor of choice, stick with pico and read the commands available at the bottom.