Blog

Drupal development, project updates, occasional knee / head slappers

Jul 7, 2010

Skip to the video demo

Open the Drupal.org project page for Query-Based Views

One of my first Drupal modules ever was Ajax Table, which gave some rich tools to users who would would normally circumvent Views to create a report or feed by constructing it programmatically. The problem being solved was "what does one do when they need to build a report starting with a query?" The Views answer is to expose everything you need to Views through modular hooks. This is an awesome long-term solution because, once your tables and custom output functions are exposed to Views, they can be used by any other view, and you can combine stuff in really novel, nifty ways.

However, a lot of people don't have the time or expertise to do that. They need to start with a query, and they would normally create a custom function, run the query directly and then generate the output programmatically. I think that there will always be use cases for this, and even if the same report could be created in Views, some people will do it this way simply because it's faster for what they need. Ajax Table was a utility module for these use cases. By running a query through a helper function and passing a couple parameters, users could generate ajax-reloading, searchable, sortable reports with very minimal work. It was handy, and I used it all the time. I still use it for my internal time-keeping / invoicing / proposal generating system.

The functionality was useful enough that I built out a second iteration called Query-Based Views, this one using Drupal configuration instead of straight-up code. I demo-ed the module to my local Drupal User Group, and got some positive responses regarding of the ajax functionality, rapid development and in-line editing. However, the general consensus was that the functionality would make a much greater impact if contributed as a Views plug-in, or as patches to Views itself.

So I shelved the project, thinking that until I knew enough about Views to integrate this, it would be better not to fork efforts.

Then a few days ago it struck me that maybe I should ask Earl Miles (merlinofchaos), the developer of Views, if the idea of starting with a query was actually Views-compatible. I was thinking that maybe the Views query builder was just an element of the UI that could be replaced out with something supplying a raw query. He said that it really wasn't. Too much of the power of Views is derived from abstracting out the query building process into the UI that's there.

That means there's actually room for this type of module. It's true that a lot of functionality is duplicated, but Query-Based Views runs on a different paradigm that's incompatable with Views, so it's reasonable for it to do so. Some specific bits like in-line editing could be abstracted more to be able to work with Views and Q-Views, but as a first effort, I think this module should fit the bill.

So I spent a couple of days porting the Drupal 5 version of Q-Views to Drupal 6, fixed a bunch of bugs and am releasing it as an alpha. The bulk of the code is written by the Chris Shattuck of yesteryear, who was not as well versed in Drupal ways, so if the module is useful enough a code rewrite is in order for a non-alpha / beta release. But as it stands, it's functional and ready to roll.

Video Demo

Q-Views has a lot of functionality, so this is a longer video (20 min). Feel free to skip around, though.

Jul 7, 2010
200908041150.jpg

WebEnabled is really neat, so neat you have to give it a few minutes to sink in.

If you're a Drupal freelancer or web shop, you spin up new Drupal sites all the time. If you've been doing it long enough, you've probably figured out ways to make the process quicker and cleaner. If you've got a team, you've most likely established a system that allows multiple people to work on the same project. You've got a system for demo-ing Drupal to potential clients and for capturing your work so that you don't do the same stuff over and over. However, if you're considering adjusting your current workflow, have some gaps that need to be filled, or are starting from square one, then it's worth your while to meditate on what WebEnabled can do for a moment.

After signing up for WebEnabled, the first thing you'll want to do fire up an 'application'. WebEnabled has a one-click installer, which installs the latest versions of Drupal 6, Drupal 5, Drupal 7 dev or Acquia Drupal. While cool, a one-click installer is not novel in itself. What is novel is the feature set that accompanies the application. You can set up an app on a fresh .webenabled.com sub-domain, or link it up with your own domain. You can share applications with other users, which makes team-driven development a snap. SVN is also supported out of the box, if you roll with version control. Once you have your app set up, you can clone it. Imagine this workflow: You have a few different flavors of sites you work with, say blogs, e-commerce sites and social networking sites. If you start from scratch, you end up running the same configuration every time, installing the same modules, making some basic theme adjustments. If you've been doing this long enough, you've probably got a folder and database set up locally which you copy every time you start a new project. WebEnabled take this one more step: Fully automated cloning, complete with database config changes, a new database and new SSH account. Again, all this with just one click. It's hard to get simpler than that. After its cloned, you can continue to make improvements to the base site.

Okay, so we've got the ability to create a new site and clone it in just a couple of clicks. Perfect for solo folks, but what about managing default installations with a team? Here's one place where the number of options in WE is a little overwhelming, and detracts from the central awesomeness which is that if you want team-driven development, you can have it. For one, you can use integrated Subversion to manage team development with version control. Version control is a common solution to the problem of team development, but you can also connect different WE accounts to the same project to give several team members access to work with files directly.

The above feature set was enough to get me excited, but WE does one more really unique thing that I personally think is brilliant.

In the Drupal community, there's a lot of work sharing that goes on. Users contribute modules, themes, documentation, and support so that other users don't have to go through the same rigamarole that they did. Fixing people's problems is a two-way exchange. You help people, and earn a name for yourself, and perhaps meet some of your other goals (financial or otherwise). One thing I haven't seen is a good method of sharing base installations. Install profiles and the Patterns module can do something similar, but they take time that most folks don't have. People can package up distributions and share those, but maintaining a distribution is a daunting task that's difficult to do well.

WebEnabled allows you to publicly share your default installation, again with one click. What this does, in essence, is elegantly fill this missing gap for a community-based mechanism of sharing base installations. One doesn't need to go so far as to create and maintain a distribution, and updates made to the default install are automatically available, so there's no overhead in making the default install public. A WE account is required to initially import the default install, but because the free WE account allows up to 3 application installs, there's no cost to download. A public URL is given to a shared install, so you can promote the install however you'd like.

A plan is in the works to provide a marketplace so that developers have the option of selling their default installs. This would work in the same fashion as the free / premium theme model. Supporting this model means that people can actually derive some financial motivation to construct good default installs, and that could benefit the Drupal community and help users at all levels.

One more use case - Drupal training

One thing I think is worth mentioning is that WE is being used by at least one Drupal training firm to get their students set up and learning Drupal. It's easy, ubiquitous, and the only thing that you have to help people set up is an SSH browser of some sort. I can see WE being used for all kinds of Drupal training, both by instructors demonstrating, and students following along.

Criticisms and Concerns

From a User Experience standpoint, the interface assumes that you're a seasoned developer, and I think that might be a mistake, especially considering that students and new developers provide some really solid use cases. So, there are some gaps in documentation and some of the messaging was a little cryptic. There were several points during the initial setup where I asked myself 'okay, what's next?' Once I sorted those out, moving forward was reasonably clear.

I get the feeling that WE is still wrapping their head around their target markets. If I hadn't talked to one of the WE developers, the site wouldn't have called out to me to re-think the way I was doing things. It took a longer conversation to get enthusiastic about it, and to think about ways to incorporate WE into my workflow.

At it's core, WE is a hosted solution. While they've got a bit of a head start, with the open availability of Aegir, and with the Garden / Fields Acquia hosting projects, they're going to have some formidable competition in the marketplace really soon. WE is already stepping up their marketing, and that's good to see. WE has the opportunity to fill a real niche amidst some different rising options, but they will need to carve it out and perhaps even define it as they go.

My experience experimenting with WebEnabled left me pretty excited about its future. I can see that it's headed in a good direction, and it already has what appears to be a solid platform for creating default installs, supporting team-based development, and distributing the install packages. WE can be an awesome addition to a Drupal developer or firm's toolbox, and solves some rather difficult problems quite elegantly.

Jul 7, 2010

At DrupalCamp Colorado, Stephanie Pakrul and Jay Wolf spoke about the new module Skinr and how it relates to Panels for theming, and I left the session with a few pleasant goosebumps. For the uninitiated - as I was - Skinr is a module sponsored by Gravitek Labs which allows themes to expose style presets to blocks. The upshot is that once you create a nice style, you can allow users to apply the styles to virtually any area of a page with a couple clicks. This effectively incorporates several principles that have up until this point been applicable mostly to modules, like reuse of code, config-based changes and ... well ... general modularity. I could immediately see that this was an idea with really big potential. Even in its infancy, the Skinr module can do some pretty neat stuff.

Along these lines, Top Notch Themes did a pre-release of their new Fusion theme which incorporates Skinr functionality. The folks at TNT have really been quite genius with their positioning of the Fusion theme, and I think they have really wrapped their minds around where theming is headed over the next couple of years. Their base message is that Fusion is the only theme you'll ever need - a tall order for any one theme, and an interesting proposition. The theme is grid-based and comes in fluid or fixed 960 variety, and a plethora of styles are made available through Skinr for layout and look and feel.

The main purpose of the Fusion base theme, however, is not to provide a look and feel, but rather to supply a solid foundation for sub-themes and - get this - pluggable, extensible style packs (my term). So, instead of having to cut and paste stylesheets and images from one theme to another, instead you paste these style packs in. I really like this idea. Fusion will ship - I believe - with an example sub-theme that looks pretty decent out of the box. Fusion also exposes some nice configuration options you don't see in a lot of themes, like font settings and setting the default text in several areas of the site.

Fusion will be released into Drupal contrib, and then TNT will be selling sub-themes on their site. The fact that they will be moving their themes to Fusion says something really important about Skinr and Fusion. If a leading Drupal company that needs the support of the community to survive is throwing their weight behind these technologies, it's a good indication that it's something to watch very carefully.

I think the move to create a one-size-fits-all, highly modular theme is inevitable, and comes at an excellent time considering how important it is to the Drupal community to attract more designers and themers. I also think it's a daunting task that can be accelerated if there is a model to drive the development commercially, alongside community development, so I appreciate TNT's and Gravitek's roles in this venture. The ability to create 'style packs' (again, my term), is another way that themers can contribute, and Fusion / Skinr will allow designers to do an awful lot of design without worrying about theming. That's pretty powerful stuff.

I'm really looking forward to seeing how this moves forward. TNT and Gravitek have their work cut out for them, but I hope that quickly it will become a minor movement to change the way we look at theming from here on out.

Jul 7, 2010

I spent a little time today exploring some options for improving the internal linking on my blog. I'm not particularly worried about getting my site high up in the Google, but because I regularly add content it's a good sandbox for testing modules and techniques in achieving search engine friendliness.

A huge focus in SEO is getting higher ranking sites to link to yours, called 'incoming links', and the emphasis on this strategy leaves a lot of room for getting an edge using other techniques. In particular, 'internal links' - or links from one of your pages to another - is a technique way less exploited, but also much more under your control. Here's a couple of principles I've picked up over the years:

  • Links from one of your pages to another one is just as valid as a link from an external site. What matters is the PageRank of the page. Think "pages" not "sites"
  • The longevity of links comes into play, so rotating links aren't as effective in the long run as permanent ones
  • You can link to several pages from one page without diluting the PageRank that page passes onto the others, possibly up to a hundred

So, what this calls for is a strategy for easily creating permanent links from one page to another. Also, by linking to new pages from several others you increase the speed of getting indexed (in theory).

Here's what I done:

1. Installed the Related Content module

The Related Content module allows a user to create one-way associations between one node and several others. These associations can then shown in a variety of formats on the node page, or you can use an API to get a list and do your own formatting. To use it, you first have to set up a view and that's used to display a list of nodes to choose from. I thought the implementation was pretty witty, and I've got some ideas for improvements I'd like to see. For example, automated relationships based on keywords, 2-way associations, hiding the current node (so you don't associate the node with itself), supplying a default view, adding a few more formats, and ajax-loaded views so that exposed filters can display. Doesn't look like the module hasn't gotten much love in the last year or so, but it's functional and think it's a great start.

The role this module fills in terms of search engine friendliness is that it allows nodes to permanently link to multiple other nodes. For real users, it also gives them a next step on your pages. For pages with a high bounce rate, it lays out something that might be a bit enticing.

2. Installed the Vocabulary Index module

You can set up Views to create a list of taxonomy terms with links to the term pages, or you can install Vocabulary Index, which does that out of the box, and also includes a count of nodes for each term. This exposes links to vocabulary terms, which then provide internal links back to articles. I see this as another factor in a good internal linking strategy.

3. Installed the Clean Pagination module

Clean Pagination is a module I put together that will change links from /view-list?page=2 to /view-list/2. Google does a good job at indexing query string-ed pages, but it's generally thought that using clean URLs even in pagination is a stronger method. A setting in the module will also change your pagination links to include keyword-rich, more descriptive URLs in pagination links, which get replaced out with plain numbers when the page is loaded. I'm not sure if this is a good idea or not, but makes sense from an accessibility and search engine friendly perspective. Anyway, the option is there.

4. Used the monthly archive view

A monthly archive is an excellent way to generate permanent internal links. By using a monthly archive view (export found here) and adding it as a block, you expose the index pages for spidering. It took me a while to dig this view up, so I've included the code below for Views 2 in Drupal 6. Here's the view:

$view = new view;
$view->name = 'blog_archive';
$view->description = 'Display a list of months that link to content for that month.';
$view->tag = 'default';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = FALSE;
$view->api_version = 2;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->override_option('sorts', array(
  'created' => array(
    'id' => 'created',
    'table' => 'node',
    'field' => 'created',
    'order' => 'DESC',
    'granularity' => 'second',
    'relationship' => 'none',
  ),
));
$handler->override_option('arguments', array(
  'created_year_month' => array(
    'id' => 'created_year_month',
    'table' => 'node',
    'field' => 'created_year_month',
    'default_action' => 'summary asc',
    'style_plugin' => 'default_summary',
    'style_options' => array(
      'count' => 1,
      'override' => 1,
      'items_per_page' => '30',
    ),
    'wildcard' => 'all',
    'wildcard_substitution' => 'All',
    'title' => '%1',
    'relationship' => 'none',
    'validate_type' => 'none',
    'validate_fail' => 'not found',
    'default_argument_type' => 'fixed',
  ),
));
$handler->override_option('filters', array(
  'status' => array(
    'id' => 'status',
    'table' => 'node',
    'field' => 'status',
    'operator' => '=',
    'value' => 1,
    'group' => 0,
    'exposed' => FALSE,
    'expose' => array(
      'operator' => FALSE,
      'label' => '',
    ),
    'relationship' => 'none',
  ),
  'type' => array(
    'operator' => 'in',
    'value' => array(
      'blog' => 'blog',
    ),
    'group' => '0',
    'exposed' => FALSE,
    'expose' => array(
      'operator' => FALSE,
      'label' => '',
    ),
    'id' => 'type',
    'table' => 'node',
    'field' => 'type',
    'relationship' => 'none',
  ),
));
$handler->override_option('access', array(
  'type' => 'none',
  'role' => array(),
  'perm' => '',
));
$handler->override_option('title', 'blog archive');
$handler->override_option('items_per_page', 30);
$handler->override_option('use_pager', '1');
$handler->override_option('row_plugin', 'node');
$handler->override_option('row_options', array(
  'teaser' => TRUE,
  'links' => TRUE,
));
$handler = $view->new_display('page', 'Page', 'page');
$handler->override_option('path', 'drupal-blog-archive');
$handler->override_option('menu', array(
  'type' => 'none',
  'title' => '',
  'description' => '',
  'weight' => 0,
  'name' => 'navigation',
));
$handler->override_option('tab_options', array(
  'type' => 'none',
  'title' => '',
  'description' => '',
  'weight' => 0,
));
$handler = $view->new_display('block', 'Block', 'block');
$handler->override_option('arguments', array(
  'created_year_month' => array(
    'id' => 'created_year_month',
    'table' => 'node',
    'field' => 'created_year_month',
    'default_action' => 'summary asc',
    'style_plugin' => 'default_summary',
    'style_options' => array(
      'count' => 1,
      'override' => 0,
      'items_per_page' => '30',
    ),
    'wildcard' => 'all',
    'wildcard_substitution' => 'All',
    'title' => '%1',
    'relationship' => 'none',
    'validate_type' => 'none',
    'validate_fail' => 'not found',
    'default_argument_type' => 'fixed',
  ),
));
$handler->override_option('block_description', 'Archive list');
$handler->override_option('block_caching', -1);

Jul 7, 2010
drupal-javascript-and-jquery.jpg

After reading Drupal 6 Javascript and jQuery (Matt Butcher, Pact Publishing), I gained a new appreciation for writers attempting to expound on a one specific aspect of Drupal development. jQuery, for example, can be used by nearly every layer of Drupal, from module building to theming, from the file system to forms. How does one boil down the many and varied applications of this multi-purpose tool into a reasonably sized book? I think Matt Butcher did a fantastic job of doing just that.

The book was not quite what I expected, and that's a good thing. For one, the author assumed a minimal amount of experience from the reader, and started at square one with some basic terminology and a first 'hello, world' tutorial. Like most tech tutorial books, the chapters are comprised of 1-3 mini projects where some new ideas or techniques are introduced. For the most part, each chapter builds on previous chapters, illustrating more complex functionality. Another thing that struck me from the start and continued to impress me throughout was the quality and creativeness of the example projects. While few of the examples were production-ready, they solved common issues in a compelling way. Here's a quick list of some of the mini-projects:

  • Load an RSS feed via AJAX
  • Create a live in-page alert when new comments are added
  • Create a text editor
  • Create a random, rotating node teasers in jQuery
  • Write a jQuery plugin

A lot of these projects have crossed my mind as things I'd like to dig into at some point anyway. In addition to being interesting ideas, these projects are also executed in a way that brings together many aspects of Drupal. Having used jQuery and Drupal for a couple of years now, I felt like I knew the basics, but I was pleasantly surprised to learn something new in virtually every project. Some things I learned, but didn't expect to:

  • How to use JSON - I've been wanting to wrap my mind around that for a while
  • How to use translations in jQuery
  • What are Drupal behaviors - If you don't know about them now, you absolutely need to! They solve one of the more complex problems I've dealt with in complex jQuery apps
  • How to theme in jQuery - Awesome, I didn't know you could do that
  • Creating jQuery functionality in themes - I had thought this was a purely modular job, but no!

By the time you make it through the book, you've been introduced to all of the major parts of Drupal. If I had known nothing about Drupal from the start, I would come out the other end with the ability to create themes, modules, and jQuery plugins. Not bad for 318 pages, probably half of which is code. And the fact that I was still satisfied even having worked with Drupal and jQuery for the last couple of years says something to the depth of the material covered.

I was excited enough about the new stuff I learned that I picked up a module that had been languishing for a while and re-wrote a bunch of the code using the principles addressed in this book. The code is now a whole lot easier to understand and debug. The 2 major concepts I applied were object oriented javascript and Drupal behaviors. Drupal behaviors is binding jQuery actions to html elements on the fly, so if you load up some new content via ajax, you can then attach all the jQuery stuff to it without affecting the rest of the page (like accidently attaching an action a second time, which can have undesirable consequences). I've found all kinds of ways of dealing with this is the past, and they've all been really ugly in comparison. Behaviors are a breath of fresh air, and there were lots of examples in Drupal 6 Javascript and jQuery to really anchor the coolness of them.

Minor Nitpicks

My criticisms of the book are really minor in comparison with my praise. There were quite a few typos and consistency errors. In another genre of book I wouldn't be as concerned, but when dealing with code where one misplaced character can break an entire script, running into typos in the text reduces confidence that the code will work if copied verbatim, especially for the unexperienced programmer. I actually worked through every example up until the last two chapters, and was pleased to find out that they all (with one exception) worked as advertised. The one exception was in Chapter 7 where a module is required that does not produce valid JSON. It took me a while to discover the problem, look and find a patch to the module. One more really minor thing is that I felt that the tone vacillated a bit, assuming at times that the reader was new to programming, and at others more experienced. Sometimes a good bit of work went into describing more complex programming conventions, and at other times they were more casually alluded to.

Summary

Overall, I was really happy to spend the time reading this book. I'm not the fastest reader, and working through the code examples takes me some time, but it was worth it. It anchored some important Drupal 6 conventions, illustrated some best practices for jQuery which can extend from simple to complex projects, and introduced me to some of the ways that jQuery integrates with the different aspects of Drupal. I'm looking forward to reading more from Matt, and would recommend this book to anyone aspiring to jQuery ninja-dom.

Notes in the margin

I made several notes in the margin of the book that didn't make it into the above review, so here they are for those interested:

  • Until later on in the book, the example code snippets were short, which I appreciated
  • I liked the idea of introducing jQuery in the theme layer in early chapters. Really simple, good call.
  • Good callout in the translation chapter, which says 'hey, translations are really important, don't skip this chapter'. By the title, it was the least interesting chapter to me, but I really enjoyed it.
  • Excellent job covering lots of gotchas: Syntax coloring, can't call ajax on a different domain
  • Creating a javascript templating engine - weird and cool!
  • Would have liked a chapter on jQuery.getScript() - dynamically load javascript
  • How to handle cookies in jQuery - yea!
  • I like the .info file trick - stick your own stuff in there, use it later
  • I really liked the using caching for search auto-complete example. Will definitely use that one in the future.
Jul 7, 2010

Skip to the video

To celebrate by recent release from employment, I spent several days busting my butt to put the sexy back in administration. Namely, I updated the Drupal Navigate module to include some new features, and to fix some long-standing bugs that had been making administrators feel less than sexy for the last several months.

navigate.jpg

For the uninitiated, Navigate is an administration module that works a little like Administration Menu. It loads a sidebar with widgets which allow users to search the menu, nodes or users, construct favorite lists, and load up expandable / collapsable menus. It works really well for clients who aren't used to Drupal. The newest release allows admins to set default widget sets, and adjust user sets. You can also theme it (a funky lemon theme is included as an example).

There's a video demo below, but here's a quick list of improvements made in this release:

  • Made snappier through quicker transitions and fewer ajax calls
  • Added ability to manage default widget sets for users and user roles (all ajax, btw)
  • Made theming Navigate really easy
  • Fixed compatibility issues with Administration Menu
  • Added keyboard shortcuts
  • Added XHTML compliance
  • Added import / export ability for Favorites and for entire widget sets, so you can quickly deploy a set from one site to another
  • Added 'customize' permission, to keep *certain* users from messing up their own sets
  • Added ability to search users
  • Squashed some bugs
  • Re-factored lots of code to be more Drupal-esque
  • Made some minor layout adjustments

I'm hoping to put in some work to help with the current administration tools in D7, but before that, I needed to grease my wheels a bit with some contrib work to to anchor some jQuery techniques I'd learned, and re-familiarize myself with D6. It feels good getting so much done so fast. You can do that with contrib work, but it's hard to be that productive in core Drupal. Things just move at a different pace there. Now that I've gotten a bit out of my system, I think I can crack down a bit and start seeing what I can do for core.

And here's the demo video to celebrate Issue Queue Zero (at least for the D6 version):


Jul 7, 2010

Last weekend I attended DrupalCamp Colorado, and thought I should jot down a few of my personal highlights.

The Hostel

I reserved a dorm bed at a local hostel. Maybe the creepiest place I've ever been. When you register, on the counter is a ventriloquist doll, folded in half with it's legs behind his head. Next to the doll is a communal bowl of chips. Like, potato chips. BBQ flavored. Now, I appreciate the sharing attitude, but would have been far more comfortable plunging my hand into a bowl of individually wrapped candies. After a series of strange events which I hesitate to recount (just in case involved parties are tracking my posts) but which kind of pushed me over the edge of creepiness, a fellow attendee offered to let me stay at his place, and I gratefully accepted. After I presented at one session, someone who actually stayed at the hostel let me know that out of a couple of months of traveling through Europe and Asia, the Denver hostel was the dirtiest he'd seen, and I'd done good by not staying there. The result is a good story with lots of embellishments if you're (un?)fortunate enough to hear the whole tale in person.

The Sessions

I ended up attending a lot of sessions, which I haven't done at previous camps / Drupalcons. I got some good stuff out of the security session with Greg Knaddison, Ezra Gildesgame and Ben Jeavons. Also, got some D6 theming goodness, presented by Stephanie Pakrul and Jay Wolf from Top Notch Themes. The stuff going on with the Skinr module really got me excited, and hearing how TNT improved their conversion rates so drastically using just a few intuitive techniques and very little time was excellent. Ended up sitting in on a few sessions that were a little under my point on the learning curve, but I enjoyed those as well because I was watching for presentation styles, since I gave my first session ever on Sunday.

Good wifi access, fun backchannel discussion, excellent lunch with TNT people and my friend Josh Brauer. There was enough time between sessions to get some socializing done (my favorite part of Drupal events) and meet some Denver folks.

The People

I got a really good vibe from everyone at the Camp. In contrast to Drupalcon (I'm still pretty green when it comes to Drupal events), I enjoyed the atmosphere of a smaller event. Ended up talking to the same people several times, and felt less lost in the crowd. I met a lot of people I'd love to chat with again, and got to put a lot of faces to names I'd only seen in IRC. I came home seriously considering the idea of taking an extended vacation (6 months or a couple years) in the area, just to be around such an active, fun bunch of Drupal folks. The experience anchored my resolution to attend a decent-sized event at least once every couple of months, to keep connected with the really neat people that make up the Drupal community.

Giving a Presentation

I was thankful to have the opportunity to present a session, and that the audience was probably too sedated by the unlimited pizza lunch to judge me too harshly. It went well, at least from my perspective. I kept on time, didn't freak out, and managed to make a few people laugh. The goal of the session was to jumpstart folks who haven't really taken part in community discourse yet, and go over the basics of getting involved. So hopefully, a couple more folks are a little closer to making that leap, or better yet actually took it. I learned that 45 minutes is pitifully short to cover a subject in-depth, and that it would have been nice to have more time for answering questions and getting feedback about what was missing from the presentation so I can make it better next time.

Conclusionary Stuff

I'm looking forward to presenting again, got a little more excited about doing a DrupalCamp in Idaho, am considering taking my wife back to Denver to evaluate an extended vacation there, learned that if you teach something you end up believing it simply through extended exposure, was surprised at my stamina after waking up at 3am, hope to pay some hospitality forward in turn, and am looking forward to hooking up with a lot of the great folks at the camp again. Oh, and if I get back to Denver I'm totally hitting up Chedds. A grilled cheese bistro? Beautiful.

Jul 7, 2010

Below are my slides from my presentation at DrupalCamp Colorado (had an awesome time, blog post of praise to come later). I think the presentation went well, but would appreciate any feedback from the folks that came. Was the info pertinent? Confusing? Was the presentation too basic or contrived?

Next time, I will remember to post the slides before the session so I can get feedback right away. Also, thanks to the fellow in the back for recommending Slideshare!

Jul 7, 2010

I've spent a good bit of time the last couple of weeks getting my thoughts straight for a session I may present at DrupalCamp Colorado called "Plugging into the Drupal community - Essential tools". The process of formulating my thoughts regarding my experiences with the Drupal community and what the project is all about has been a really good one. As a friend pointed out the other day, I'm more of verbal guy, so I've been thinking / practicing out loud and jotting down good thoughts when they come out. I remember David Byrne once saying that he writes music in a similar way.

The idea of the session is to help atendees wrap their mind around the social channels used by the Drupal community so they can get plugged in quick. Not just the technological aspects, but also the cultural implications of how the community uses them. I've been involved with the community on some level for a couple years now, and in hindsight I think my climb up the Drupal learning curve would have been greatly accelerated if I had gotten plugged in to the community earlier. Drupal is really a social solution to a technical problem, not the other way around, and realizing that can have a positive impact on the speed of learning and the ability to make a meaningful contribution.

Based on the voting so far, the session is lagging behind a bunch of other great-looking sessions - probably the material I'm covering seems too basic for the typical DrupalCamp crew. But I think I like the idea of putting a session out there, regardless of if it gets presented, just for the nudge to get some ideas in order. If I end up not presenting, that's just one more session I can either attend or skip out on to rub real elbows with some virtual friends.

Jul 7, 2010

I spent some time today digressing from my regular work to see if anyone was working on and iPhone / iPod Touch looping app that works like Ableton Live. I wanted something with variable-length loops and that would play loops as you recorded them. It took me a surprisingly long time to dig Loopy up, so here's my blog post and vote. Here's how Loopy works works:

  • Tap a speaker icon to start recording (no limit to length, afaik - woot!)
  • Tap the icon to stop. It will start to play immediately (if you're familiar with Ableton live, it works the same way)
  • Tap another speaker to start recording the next loop. You can record any length of measures, another woot!
  • There's six tracks (the six speakers you see below), but you can drag one speaker onto another to merge them.
  • If you start recording before the measure starts, it records the lead-in and subtracts the space from the end, if you stop recording before the end of the measure. That's pretty cool, Ableton doesn't even do that.

I love having this in my pocket. Because I have an iPod touch, I also need my headset with mic in my pocket, too, but that's a small price to pay for such uber coolness. On @loopyapp on Twitter, the developer posted a short clip of Imogen Heap using Loopy. That led me to Imogen's web site, which lead me to her YouTube channel, where I got caught up in further digressing from work. What a cool, down-to-earth person she seems to be. Hopefully I run into her at some Tweet-up. Maybe she'll record our conversation and put it in a song...

There are some things about this app that can no doubt be improved, and it seems like the developer, Michael Tyson, is pretty on top of it. It's the kind of app that makes me want to quit my day job and go into iPhone development.

Here's my wish list / gripes:

  • A foot pedal attachment to start and stop recording. I tried my bare big toe to record a guitar track, but it wasn't very reliable. If there could be a full-screen button, then the foot might work. One suggestion in the forum was more practical, to allow the user to set the count-in and length.
  • Every once in a while the sound stops and I have to quit the app and come back.
  • Probably due to the mac headset mic I use, the sound quality is dismal. This app will result in me purchasing yet more fun hardware for my Touch.
  • Setting the tempo seems a little hit and miss. Maybe it's my huge finger.
  • There's some latency, and that is a little annoying. Laying down a couple of ill-concieved beats (I am no beat boxer but have always longed for the prestige that goes along with being one) made it clear that any precise recording would be a challenge.

Overall, wicked cool! Thank you, and I'm looking forward to version 2!

Cam-2.jpg

Syndicate content Syndicate content Syndicate content Syndicate content Syndicate content