planet drupal

Stories for drupal.org/planet

Empirical development and Scrum

Recently, I've been reading a book about Scrum methodology for software development. The book is titled Agile Software Development with Scrum, by Ken Schwaber and Mike Beedle. It's interesting to me because it really defines and encapsulates a lot of my theories in a way I have not been able to articulate on my own. It helps to define a process to create unique, unrepeatable results. I think it demonstrates a great way to build custom-tailored solutions for your clients.

Click through to read more...

AJAX with jQuery is wicked easy... for real!

Images: 

I haven't had much time to play around with jQuery, but I've always been intrigued by how nicely it is used in Drupal. So, I decided to download it for a quick test. For those of you who might not be familiar with jQuery, it is a Javascript library that lets you create animations, DOM interactions, AJAX connections and more. I've used the YUI tools before which, while functional, are relatively cumbersome to implement. In stark contrast, in less than five minutes, I had downloaded the latest version of jquery and created an HTML page with a working asynchronous request.

1. Download the latest version of jQuery [jquery.com]

2. Read the quick how-to document on creating an AJAX request using the load() function.

3. Create an html file for the test with a function to call load(), which only requires one argument, though you can add key/value request variable pairs if you want to call a PHP script. You can also specify a callback function to perform after the request. We'll keep this simple for the time being:

<html>
<head>
  <script type="text/javascript" src="jquery.js"></script>
  <script type="text/javascript">
  function loadtest() {
    $("#loadtest").load("load.html");
    return null;
  }
  </script>
</head>
<body>
<a onClick = "loadtest();">Click here to test</a>
<div id = "loadtest">TEXT</div>
</body>
</html>

This sends a request to load.html and then populates the block id=loadtest with the response.

4. Create load.html

<strong>UPDATED TEXT</strong>

5. Seriously, that was it. Here's the working test

Now, this is obviously quite a rudimentary test lacking error checking and without proper callbacks, but I was shocked at how easy it was to implement. If you can get it up and running in five minutes, imagine what you could do in a day! The possibilities are vast!

Using sar to analyze server performance

Recently I've become addicted to the linux command sar (system activity reporter), which is reporting application for sadc (system activity data collector) that comes bundled with sysstat. This is a great way to see daily trends in resource usage like processor, memory, load averages, I/O and more. It comes bundled with RedHat distros, but you can also install it yourself via one of the RPM repositories.

Basically, there are two cron jobs that call sa1 and sa2. sa1 logs the current load, and sa2 compiles them into one daily log. The output can be displayed using sar.

The default settings create a log entry every ten minutes, but you can edit this by modifying the cron job that calls sa1 (RedHat puts it in /etc/cron.d/sysstat).

So, to look at today's load averages, you could use the -q flag:
$ sar -q
The output is similar to the load averages in the uptime command: current, five and fifteen minute load average figures.

Or, to look at today's memory usage, use the -r flag:
$ sar -r
the output of memory is very similar to that of top showing free, cached, swap, etc.

The logs are kept by default in /var/log/sa/sa[day], so to look at the memory usage for the first of the month, use:
$ sar -r -f /var/log/sa/sa01

But beware that these logs get rotated, so if there is a particular day that you need to save, be sure to create an archive somewhere.

I've been using sar daily. It's a great way to get a feeling of how your site is performing during varying traffic and can be a great tool to help diagnose bottlenecks. There are a slew of options that you can use with sar to report on different aspects like processes, TTY, switching, swapping and a lot more that you may or may not need.

Happy tracking!!

Drush is sweet!

Images: 

I've been playing around with an awesome Drupal module recently called Drush, which is a CLI interface for common Drupal functions. It's just a PHP script that bootstraps Drupal and calls modules within the Drush module. You can do cool stuff like from managing contributed modules and executing SQL queries, right from the terminal. I've got my head buried in the terminal for ten hours a day anyway, might as well be able to do some Drupal stuff there!

Install is fairly easy:

  1. Download the latest Drush modules for your version
  2. Install them as you would install a normal module
  3. Execute:
    php sites/all/modules/drush/drush.php

    from your Drupal site's root directory, or add the "-r /path/to/drupal" flag. You might also have to include the "-l http://siteurl.com" flag if you have a multi-site installation

  4. Create a path alias in your .bash_profile, .profile, etc. shell config to, sort of, put it in your path:
    alias drush='php /path/to/sites/all/modules/drush/drush.php -r /path/to/drupal/root'
    1. And, voila! You can now check the watchdog, run cron, run simpletests and a lot more without leaving the comfort of your favorite shell. I'm kind of stoked to write some custom modules to do some other common stuff.

Putting together a Drupal testing server

So, I've been playing around Drupal 7 and wanted to put together a local server for testing. The only crux is that the only "server" I had to work with was a cruddy old eMachines desktop with 640MB of ram running Fedora Core 5. Well, long story short, I had neither the time, patience nor the bandwidth to download Fedora 9. Unfortunately the Fedora 5 distro only comes with php 5.1 yet Drupal 7 requires PHP 5.2. Yum showed no available updates, so I had to scour pbone.net for a bunch of FC5 RPMs to get it up and running. Here's a quick Breakdown:

First, locate and remove the old PHP installation and extras:

> rpm -qa | grep php

the -qa option shows which RPMs have been installed and | grep php filters out anything not containing "php"

> rpm -e php-cli php-common php php-gd php-pdo php-pear

the above, run as root, will remove any of the listed RPM packages installed

Second, download the new RPM files from a repository like pbone.net - I grabbed the following RPMs for Fedora 5:

  • php-cli
  • pcre
  • php-common
  • php-5.2
  • php-mbstring (required for D7)
  • php-gd
  • t1lib (libt1.so.5 is required by gd)
  • php-pdo
  • php-pear
  • php-mysql
  • sqllite (required for php-mysql)

Third, install the above RPM files

> rpm -Uvh pcre-6.6-1.fc5....
> rpm -ivh php-common-5.2....

and repeat for the additional packages. Note, use the -Uvh to upgrade packages that are installed, and -ivh to install the ones you do not currently have installed.

Fourth, set up CVS on the server and check out the latest from HEAD:

> yum install cvs
> cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal checkout -d var/www/html drupal

Fifth, and final step, was to tune apache a bit, set up the database and install Drupal 7! Now I've got a server that I can quickly keep up to date with Drupal HEAD and compare patches against the CVS.

Goosh.org - the unofficial google shell

Images: 

I just stumbled upon goosh.org, which is an oddly interesting site. It's a virtual shell to interact with google. It works like a terminal shell, complete with commands like man and clear. Type in web [search terms] and you get a nicely formatted text list of results, or change web to blog, news or site to filter.

I haven't yet figured out the whole purpose of it, but I'm addicted! I guess one benefit is that you don't have to look at ads :)

Syndicate content