sacha chua :: living an awesome life

I coached developers on this project. =) It was pretty darn cool, what they did with Drupal, Websphere, DB2, and web services. Check it out!

Integrating Drupal with Enterprise Back-Office Systems to Deliver a Best of Breed e-Commerce Sites

Join Drupal experts from IBM Global Services as they detail the process of defining business requirements, selecting the appropriate technologies, overcoming the technical enterprise integration challenges, and ultimately launching best of breed e-commerce sites with Drupal.

Key takeaways will include:
A review of the key business and technology decision criteria for selecting Drupal and Acquia
An example of a 3 tiered architecture designed to deliver end-end automation and a flexible platform for future innovation
Tips on how to integrate front-end and back-end systems including Drupal, Websphere, DB2, and ERP system for launching a best of breed e- commerce solution.
A discussion of which Drupal modules and Acquia services are recommended.
Best practices and technologies for building a development and test environment to optimize parallel development and ensure security

This Webinar is designed for those who want to learn more about best practices for designing an enterprise architecture with Drupal at the core and integrating Drupal with other enterprise systems.

http://acquia.com/resources/webinars/integrating-drupal-enterprise-back-office-systems-deliver-best-breed-e-commerce-s

Enjoy!

(Update: Thanks for catching that!)

One of the recent hires dropped by with a few questions about Drupal development in small projects. She wanted to know if it was worth having another person do the HTML and CSS theming if that person didn’t know PHP or Drupal, and what the workflow might look like.

As a Drupal developer who really hates working with cross-browser fiddliness, I think it’s almost always a good idea to have someone else do the HTML and CSS theming. In an ideal world, that person would also create the Drupal theme and whatever Javascript behaviors are desired, but it seems hard to find people who are comfortable with both front-end and back-end development. A reasonable compromise is to have someone else translate the visual design into cross-browser HTML and CSS for the splash page, an inside page (anything representative of the main layout), and other layouts. What takes me four hours of teeth-gnashing may take an experienced designer just one, and he or she might even be happier doing it. So go ahead and optimize for developer productivity and happiness.

Another benefit of splitting up the work is that you can work in parallel. While you work on the technical bones of the application, the designer can get the theme just right. The earlier in the project that you know about complex parts that could be problematic, the better, and this is true for both theme and function. You’ll still need to integrate the theme at the end, so budget at least a few days for that.

So here’s what the workflow might look like:

1. Developer installs modules and configures them to work together.
   Designer prepares basic HTML and CSS.
2. Developer fleshes out site and adds custom functionality.
   Designer fleshes out individual forms/pages requiring special treatment.
3. Developer ports HTML and CSS theme to Drupal.
4. Developer and designer collaborate on fixing any cross-browser problems that show up.

Build the functional parts of the application before worrying about the theme. Problems in the theme layer can mask problems in the functional layer. If you build the theme first, then build the features, tracking down bugs might take more time.

It’s usually a good idea to build the hard parts first, so you can get a better sense of how much more effort is needed and whether you need to scale things down. If you’re new to Drupal, you may want to build a few easy parts first so that you can familiarize yourself with the system.

Hope that helps!

I love this! I’m practically running an IBM Drupal drop-in clinic at 120 Bloor E, helping five developers on two projects become that much more productive. They’re all working with Drupal 6, but my experience with developing and debugging on Drupal 5 is still helpful, and I can navigate through Internet posts pretty quickly too. I get to help with the tough and interesting bits without needing to set up my environment or work on the boring bits.

This is definitely worth the subway ride. I create more than CAD $4.50 of value and save people more than 60 minutes of time total. Besides, I usually get to sit down and write a blog post during the commute.

Some things from today:

• Want to protect files from being downloaded? Set your Drupal file system handling to Private, manage your view uploaded files permission, and don’t forget to add an .htaccess in your files directory with the following:
  SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006

  Options None

  Options +FollowSymLinks

• Use hook_form_alter to print out the form_id if you want to change where a form redirects. After you figure out the form_id, set the appropriate form’s #redirect property.
• var_dump may look different if you don’t have xdebug installed. Check the HTML source for your expected output.

Lots of other HTML- and Drupal-related things, too.

Good leverage on time and experience. =D I wonder how to get even better at this…

I learned a lot from another three months doing Drupal. Here’s a summary:

• I learned how to write low-level design documentation. I used to hate doing this because I was much happier prototyping things in order to figure things out, and writing in a word processor instead of a code editor seemed slow. Also, laying out images was a pain in both OpenOffice.org and Microsoft Word. The key breakthrough was that after a lot of iterations, I finally got to a document that had the level of detail my project manager wanted. Once I knew what he wanted, it was easy to write documents like that. In fact, I did one better–I filled in lots of details in the validation section of the design document, and I used that for test-driven development.
• I smoothed out more of the kinks in our deployment process. Always testing our update scripts with update.php’s access check set to false helped flush out assumptions about user ID. Our regression tests came in handy, too.
• I practiced more test-driven development. And I loved it! =) Yay yay yay yay.
• I learned JQuery and the ins and outs of Views+Calendar. We customized our calendar implementation extensively, and it doesn’t look half-bad. Working with timezones had given me a lot of pain, though, but I managed to address all of those issues (and I have the regression tests to prove it! ).
• I learned that I should’ve gotten a second computer a long time ago. Having a dedicated development computer and another computer I can leave on Microsoft Windows means less hassle and less stress when it comes to working with other Windows-centric people and tools.
• I learned that I have a lot of things I can teach people about Drupal. =) Mentoring is fun!

I’m moving to strategy-focused projects next quarter, but if I were to continue on this project, I’d probably:

• Learn more about optimization (started doing a little bit of this, speeding up a page by an order of magnitude)
• Write more validation tests in my design documents
• Figure out how to check that coding standards are consistently applied
• Find some way to convince folks to go for Drupal 6, or find another project that uses Drupal 6.

Today was the first time I used a DELETE statement that joined multiple tables. I didn’t even know you could do that. =)

I needed to look into this because my update function was just taking so much time and memory. We have a little over 3,000 nodes, most of which are usernodes automatically created by the usernode module. I needed to rebuild the node access entries for a few hundred content nodes to take into account the new partner access module I wrote, but node_access_rebuild took quite a while.

The first approach I thought of taking was to delete usernode because we didn’t seem to need it any more. In order to do that, though, I would still have to delete all the user nodes, though, and invoking all the hooks for each of the 2000+ user nodes took a while as well.

The second approach was to delete just the node access records related to the nodes I needed to update. I found a way to do it even faster – instead of querying the node IDs and then deleting individual rows, I could do something like this instead:

db_query("DELETE FROM na USING {node} n
          INNER JOIN {node_access} na ON (n.nid=na.nid) WHERE n.type='%s'", $type);
$rs = db_query("SELECT nid FROM {node} WHERE type='%s'", $type);
while ($row = db_fetch_array($rs)) {
  $node = node_load($row['nid'], NULL, TRUE);
  if (!empty($node)) {
    node_access_acquire_grants($node);
  }
}

(UPDATE: Fixed MySQL statement)

That was interesting. =)

I was also running into memory problems trying to run all the unit tests in one go. I broke it into individual tests with:

drush test list | grep KEYWORD | xargs -n 1 drush test run | tee out

where KEYWORD is the keyword I use to filter the list for just the tests I wanted to run, and out is the file that stores a copy of the results. It’s not neatly summarized, but oh well. =) It works.