On Wednesay night the Sac DUG met for the second time at Hoppy Brewing Company and beat it's 2 year old attendance record in the process. It was a great meeting, which was attended by Drupal users of every stripe - there was even folks who showed up to evaluate Drupal for use in their companyl (a highly recommended way to check out Drupal, btw!).
Thanks to Phil Glatz for the live demonstration using the step-through debugger on his IDE - I've gotta say he inspired me to dust off my debugger and investigate it a little more (something I'm not regretting already - it's been great).
Some other great resources which came out of the meeting:
The Shared Links module (I and my legacy sites thank you for the as_yet_unreleased Drupal 5 version, Shawn)
So you have a virtualhost set up for Apache and your local site is running at http://yoursite.local and everything is working great on your computer. Now you want to test that awesome responsive design you've been working on with some other device(s), so you try to go to yoursite.local which won't work unless you want to modify the host file on the device(s), which is something you can't even do to an iPhone/iPad without jailbreaking it. Gah.
So, then you try to access the site with your device by just using your computer's IP address + the path to your docroot (for instance 10.0.1.10/mysite/trunk/htdocs/) - great idea and now the site at least sort of loads, but all the links to the CSS/JS and image files are broken...
In my own search to avoid jailbreaking I finally figured out how to enable normal-looking-pages access to devices following a bit of trial and error. The whole setup to enable this is done on the computer your site exists on - no need to fiddle with any of your other device(s) settings:
Last night (1/14/2009), Sacramento user group had a great meeting, held for the first time at its new and permanent-for-the-foreseeable-future location, Hoppy Brewing Company, which provides us with our own room, free wifi, as well as some great beer and food.
Ten of us showed up - an amazing number considering that we've had three different meeting places in the last 5 months. If we can pull ten despite previous scheduling and location difficulties, it will be very interesting to see how things evolve for the group now that it will have continuity of location and frequency!
In addition to introductions, each person gave some information about what they were hoping to do with Drupal for the coming year, as well as something they would like to see happen for the Sac DUG itself in 2009. Lots of great ideas were put forth, which included internal group stuff (code sprints, ideas/formats for monthly presentations), as well as some external stuff where we, as a group, might get involved directly with contributing-to/evangelizing Drupal and/or helping a charitable organization get going with a Drupal site.
Thanks to everyone who came, and I look forward to seeing you all Wednesday, February 18th, 2009 at Hoppy Brewing Company!
Just got back from Do It With Drupal which was hosted by the Lullabot crew in the French Quarter of New Orleans. Despite staying up until 4am one night working, 2am the following night, and working through a couple sessions I still managed to have a great time, meet/catchup with a lot of people, and get totally re-inspired!
There was a good mix of sessions, and between the good job presenters did and the back-channel opportunities to chat with other attendees or questions to presenters, via IRC or Twitter, both newcomers to Drupal and those with more experience had a variety ofl ways to send and receive information and thus get something out of the sessions. (the IRC rooms and/or Twitter interactivity of the sessions was totally awesome - hopefully Drupalicon and/or DrupalCamp organizers will take note!)
For Drupal developers out there wondering about the value of going to something like this, or other Drupal conferences, I highly recommend it for more than just the value of what you'll learn directly in the sessions - for me, it was the being around other people who are intensely passionate about what they're doing with Drupal, as well as the personal conversations that really made the trip.
Thanks to everyone at Lullabot and all the sponsors who put on such a great show, and looking forward to seeing everyone at DrupalconDC.
For the past 6 months I've been lucky to be part of the development team for the newly launched Yoursphere.com, a Drupal-powered social networking site which "provides one of the safest online destinations for youth ages 9 through 18 to interact*". To say that Yoursphere is the most customized Drupal site I've worked on would be quite an understatement. One example of that, and subject of this article, the user registration system went from the standard single page - to one which uses 4 unique user creation forms which are integrated within several possible 'registration flows'. The most complex of these involves two of the user creation forms, 8 total screens and third-party identity verification.
Besides being an opportunity to get to know hook_user real well, at the end of creating this system we were left with a larger-than-normal nightmare of, "Wow, I wonder if my new small change just exploded the entire registration system for the site. Hmmmmmm."
Deciding on acceptance testing / Selenium
Faced with how to automate testing of these screens and use case, combined with limited time to implement the testing framework, a method of acceptance testing (using Selenium) was opted for instead of unit testing (e.g., using Simpletest) for several reasons (though perhaps in the future we'll have both unit and acceptance testing implemented):
Facilitate testing of the registration system by non-developers
There are registration screens which involve third-party interaction/functionality which cannot be unit-tested by us
Selenium opens the possibility of testing the registration system across multiple browsers
Seeing a browser step through all the registration steps just like a real person would do (except more quickly) is just so cool and offers a unique piece of mind about the integrity of the registration system
Selenium in action
When I last wrote about Selenium, I was trying to find an easy way to get Selenium RC to work *easily*, meaning without having to install a PEAR extension and/or PEAR itself. After (much) more research I can report conclusively that there is no *easy* way to get Selenium RC working, which in all honestly puts it outside my scope of interest, as I'm sure it would for most of the Drupal community.