Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
May 19 2013
May 19

Exaltation of Larks will be at DrupalCon Portland next week and we’d like to share some of our DrupalCon plans.

To summarize, we’re excited to announce that we’re co-training on Drupal Commerce with Commerce Guys; we’re continuing the conversation we started last month about Long Term Support for Drupal 6; and we have a quick list of Drupal Fit activities that are happening before and during the conference.

Interested? Read on.

Drupal Commerce Training

One of our core philosophies is that high-quality trainings are one of the very best ways to help Drupal and the Drupal developer community grow, and we’ve been working closely with Commerce Guys for the DrupalCon training, Launching an Online Store with Commerce Kickstart, on Monday, May 20th.

Our joint curriculum is based on the 7.x-2.7 version of Commerce Kickstart, which was just released yesterday. The attendees of this training are really in for a treat and this is a Commerce training that’s not to be missed.

Drupal Commerce Meetups Every Month

This is a good time as any to let everyone know that we’re proud sponsors of the Drupal Commerce Meetup, which meets in Los Angeles on the 4th Tuesday of each month.

Not in Los Angeles? Not to worry, these meetups are also being broadcast online for everyone to tune in for and enjoy. The next meetup is after DrupalCon on Tuesday, May 28th, so be sure to sign up over at Drupal Groups to hear what the next meetup is about.

These meetups are recorded and the video from last month’s meetup is available online. The video features a presentation by Ryan Szrama on Relify and personalized product recommendations. Relify neatly narrows the gap between Drupal Commerce and recommendation systems, like Amazon’s “you may also like” suggestions.

Long Term Support (LTS) for Drupal

We’re hosting a BoF (birds of a feather) discussion on long-term Drupal support (particularly for Drupal 6 sites when Drupal 8 comes out and bug fixes and security releases for Drupal 6 are discontinued).

Long Term Support is a topic that is near and dear to us and a number of our clients and this BoF is a followup to our earlier post, Drupal 6 End of Life When Drupal 8 is Released… Or Not.

We’re preparing an “LTS” version of Drupal 6 and have a lot more planned, so stay tuned to the DrupalCon BoF schedule and @LarksLA on Twitter for news of when this BoF gets scheduled.

Drupal Fit

Finally, if you haven’t heard of Drupal Fit, it’s a group of nearly 200 Drupaleros who are dedicated to fitness is one form or another (mental, physical, etc.) and to sharing their experiences with other Drupal community members.

Here’s a summary of some of the Drupal Fit activities at DrupalCon Portland.

Are there any other Drupal Fit activities not mentioned here? Send @DrupalFit a shout out on Twitter.

read more

Sep 07 2011
Sep 07

Drupal camps are different from DrupalCons in several very important ways. I helped organize DrupalCon San Francisco in 2010, and I have been an organizer for BADcamp since 2007. BADcamp has been growing in size each year, but I still wanted to voice what I think the key differences are between camps and cons.

What makes Drupal camps different from DrupalCons, and why are they a necessary part of the Drupal community?

Drupal camps are usually cheaper than DrupalCons. This means that camps will draw a slightly different audience. The cheaper events attract more non-profits, educational institutions, hobbyists, new-comers, and people who are curious about Drupal but may not be ready to invest in an expensive conference ticket. In the case of BADcamp, our event is completely free.

Drupal camps are usually smaller than DrupalCons. DrupalCon has grown to be a very large event with a very, very, large budget. Camps are usually much smaller, and can be executed on a tight budget. In addition to having a more reasonable budget (which is an advantage for organizers) a smaller event can also benefit attendees. Having fewer people present makes the event feel more personal, and allows for accidental meetings with the Drupal-famous. Realizing that your favorite core contributor is a also friendly person is truly priceless.

Drupal camps happen at lots of different times and at lots of different places. This means they are more easily accessible to almost anyone. DrupalCons happen only twice a year, can conflict with schedules, and can be very far away. Having a camp in your own back yard means that it's easy for you to get involved with the community, on your own terms. You don't need to fly half way around the globe to talk find out what's cool in Drupal, or to share your thoughts and opinions.

Last but not least, camps tend to be organic. Each camp is born from it's own local community, as an answer to the needs of that community. This allows each one to be a little different, and include the activities that are important to each community. There is no decree from the Drupal Association telling camps what needs to be included to make a camp successful, and this allows freedom, creativity, and innovation. These are qualities we see in the Drupal project itself, and I'm happy to see them reflected in how the community gathers also.

Mar 23 2011
Mar 23

DrupalCon is a Mecca for thousands of companies and individuals that call the Drupal community home and, naturally, several of the Larks attended DrupalCon Chicago earlier this month.

We’re very involved in our local and global professional communities and we participated at DrupalCon Chicago on several levels, from volunteering to organizing to presenting.

Sessions and BoFs (birds of a feather sessions)

Rain Breaw, who heads up our Drupal training program, presented to a filled auditorium on Views Demystified, a Drupal 7 update to her immensely popular session from DrupalCamp LA and DrupalCon San Francisco. Rain was also a DrupalCon volunteer and you may have seen her at conference registration.

Also at the conference was our Director of Business Development, Cary Gordon. Cary is a Board Member of the Drupal Association, the organization dedicated to Drupal’s funding, promotion and infrastructure, and he has been working to help build the Association’s professional events team. You may have seen Cary at the Library BoFs (I and II), the Domain Access BoF and several of the Core Conversations sessions.

As for myself, I co-presented on Building Successful Local Communities: Insights and Best Practices. I also participated in the DrupalCamp Organizing Round Table, where I shared how the Los Angeles Drupal community, already one of the largest Drupal user groups in the world, is dealing with the growing pains of nearly doubling in size in less than a year.

Drupal Fit: Drupal’s fitness movement and support group

For fun, I participated with dozens of others in the Drupal Fit BoF that ran throughout the entire conference. Drupal and fitness might sound like an unusual combination, but as Dries Buytaert, Drupal’s creator and project lead, once told me, “We want the Drupal community to be fit so that we make better open source software.”

During the conference, I recorded several new Drupal Fit interviews that will shine the spotlight on members of the community who are focused on getting and staying fit.

Looking to the future

DrupalCon is one of our favorite events and DrupalCon Chicago was no different. This time, DrupalCon felt like another turning point for the Drupal community. As Rudyard Kipling once said, “I have struck a city — a real city — and they call it Chicago,” and DrupalCon Chicago has without a doubt left a similar impression on everyone who attended and exhibited.

See you at the next DrupalCon at DrupalCon London!

Mar 13 2011
Mar 13

At DrupalCon Chicago this past week, there was a "Core Conversations" session track, made up of sessions pitched by contributors to the core Drupal project. A wide range of topics were covered from the Butler project (a new system for context and blocks), to the built-in Help system, to Deployment strategies, to redesigning the issue queue. These sessions were shorter presentations followed by a discussion period for the attendees to give input on the topics.

The final conversation on Thursday by Dries Buytaert (Drupal's project lead) focused on discussing the development process for Drupal 8. (It was also exciting to witness the Drupal 8 branch being created live during the session!) During the presentation portion, Dries described in more detail the process changes he had suggested during his keynote. He then opened the floor up for everyone to bring up issues they felt needed some attention/discussion.

Discussion points

Here is the list of discussion points (that Dries noted during the talk) we core enthusiasts came up with:

  • More structured sprints - project management
  • Sandboxes (aka. Samboxes, since Sam Boyer was a huge contributor to Drupal's CVS to git migration) and locations
  • Timeline of release cycle
  • Hybrid development cycle
  • Ubuntu model?
  • Gate details; performance testing, etc.
  • Roles of initiative owners
  • Backporting
  • Non-initiatives / small changes / bugfixes -- different process?
  • Tools for usability/accessibility
  • Process around new initiatives / proposal
  • Documentation gate - workflows

Many, but not all points were discussed, and as we progressed through the conversation, I began to see parallels between some of the process changes we've implemented here at Affinity Bridge and what's going on in the Drupal development process. When I first began my position as Project Manager here, the first task I was assigned was to figure out how to make our development process work better, especially for larger, ongoing projects. This was sparked by the pain of working on very large projects, with huge issue backlogs and many feature requests, and no set launch date. 

After a lot of reading and research, our team started experimenting with a more agile process. Picking smaller chunks of work, completely finishing them, picking a new chunk of work, completely finishing it, etc. helps to make progress faster and at a better quality. Many times now, the benefits of this process have proven themselves, and I am beginning to see how some of the main points we discussed at the core conversation could be addressed with some incremental changes towards a more agile development process. 

A sidenote, as I was discussing this over the weekend, Bruno De Bondt from DeWereldMorgen.be pointed me at a blog post from one of his old coworkers from Krimson (a development shop in Belgium), Kristof De Jaeger (aka. swentel). The post is from about a month and a half ago, and outlines a proposal for an agile Drupal 8 development process. He goes into much more detail about the process and different roles involved than I will here, but it is well aligned with my thoughts (and potential long term vision), so I recommend you read it!

Specific ideas about sprints and agile for core

Before I delve into details here, I would like to preface this by saying I am not a religiously devoted agile follower. So far, what I've seen work is using elements of the agile methodology that fit for the team and project. Some devoted capital-A "Agile" followers might find that to be a flaw, but I don't think it's necessary to shoehorn people into a process. It's important that anyone adopting this feel comfortable with it, and not forced into it. Also, speaking briefly with Dries after the core conversation, he noted that it's important with such a large community not to try and undertake too much change at once (referring to the git migration and also the new idea of core "initiatives"). I very much believe those are wise words, and so am more keen to suggest some practices that the community can experiment with. If these are successful, then perhaps they can be applied more overarchingly.

Now, to go through a few of the main discussion points and others that came up, and relate them to how a more sprint-based/agile process might help address them.

New opportunites from sandboxes and git

The move to git is obviously going to open up many doors as far as more collaborative work and changes to workflows. Any Drupal.org user can now have their own development sandbox, and as Dries mentioned anyone can now fork core (ie. make a duplicate version and add improvements to it), though it's not always recommended! 

As many others noted in the session, this is going to allow multiple people to easily work on different parts of core and then merge their work back together. It could also allow multiple people working on different approaches to the same parts of core, to then compare and combine the best pieces. In any case, it will allow for a lot more safe experimentation and collaboration.

Keeping the criticals count below 15

This was something Dries brought up in both his keynote and the session. The Drupal 7 release cycle was very drawn-out because of the large quantity of criticals accrued through the three years of work. Longer release cycles tend to lead to burn-out and work that doesn't get fully completed.

Having the sandboxes and git will allow for a totally new approach here, one which is common to a more "agile" process, which prioritizes keeping the master branch clean and ready to launch at any time. To work like this, the master branch for core would be kept in a launchable state, and any changes or new work would be done in branches/sandboxes which would have to be completely done to be merged back into core. The "gates" would protect the master branch from bugs or incomplete work, so that we could be relatively certain that core is always ready to ship.

As a result, we wouldn't be aiming for under 15 criticals, but rather a constant of zero criticals in the master branch.

Small changes and bug fixes

Small changes and bug fixes would also be done in branches, but merged back in more frequently. There would be no necessity to save up batches of small fixes, though they could be done in batches related to different pieces of functionality. 

We would want to aim to avoid incurring technical debt, ie. fix problems as we go, as much as possible. Never delay working on bugs that will need to be fixed before launch. If that's the case, the work is not "done" and should not go into the master branch. This may mean more refactoring, but it helps keep the master branch ready to ship at all times.


The "gates" Dries talked about are still being defined, but the general idea is that there would be some steps that need to be completed before any branch would be merged into the master. Examples of what gates there might be include:

  • Documentation: making sure all of the code/API documentation is complete/updated, and ideally make sure the online documentation is also complete/updated. Possibly could go through review by Documentation Team members or other developers.
  • Accessibility: making sure that basic accessibility standards are met. Possibly could go through review by Accessibility Team.
  • Testing: making sure automated tests are written and pass. Possibly could go through manual testing as well.
  • Performance: making sure performance meets certain standards.
  • Design/UI: having design or usability reviews.

Making this concept of "gates" work will require defining a set of requirements and standards, and possibly finding people willing to do frequent reviews. But it will also mean that this additional work is really done before merging into the master branch, and that "done" refers not only to code being complete, but a more holistic interpretation of when work is ready to ship.

Timeline of release cycle

Dries suggested a shorter release cycle for Drupal 8, with likely a more focused and smaller set of initiatives (which he's outlined as areas of focus that will have initiative leaders). Keeping the master branch ready to ship at all times will mean that the release cycle can be as short or long as we want, and that we are not limited by half-finished functionality in the master branch (since only finished functionality would ever be merged in).

More structured sprints and phases

A lot of these goals and ideas lend extremely well to working within more structured sprints, and using phased development for larger initiatives. My initial suggestion (Kristof's post suggests two month sprints) would be for one month sprints. Despite the issue of working with a spread out team of mostly volunteers, I find that shorter sprints lead to better momentum. I also feel that it will be easier to pick out clear sets of issues to work on per sprint if they are relatively short.

Another benefit to shorter sprints would be the potential to attract more help from people who aren't interested/able to work on core more consistently. It's a lot easier for someone to commit to working on some functionality for a month rather than for three years. I would bet that once someone helped with one sprint, they would be far more likely to end up helping on another one down the road.

For larger pieces of work, we'd want to work in phases that are several sprints long. Each phase would have a set of functionality that can be merged with the master branch when complete. And the end of each phase would be a great place to work through the "gates". It would be nice to think we could go through the gates at the end of each sprint, but I don't think we currently have the resources to do this. It might take many phases to get an initiative fully complete, but the length of the initiative wouldn't necessarily delay a potential release.

A note on infrastructure...

Structured sprints would be much easier to do if we were able to add "sprint" and/or "phase" fields to the issues, but even without this we can always organize what is in each using tags, as was done with the git migration.

It would also be ideal to be able to relate issues in a richer way like in some issue tracking systems such as Unfuddle (see image below). Despite Unfuddle not being created specifically for agile development, it's easy to use it this way. I tend to create "parent" tickets for meta-issue/discussions and then create specific work item tickets as "children". You can also mark "related" issues, which aren't part of the batch of tickets, but are somehow related. And you can have parent tickets that have child tickets that are parents to others, so it's possible to create a hierarchy of what needs to be done to move onto another piece of work. Then, I create a "Milestone" for each sprint, with start and end dates, and add and prioritize tickets in the milestone appropriately after discussing priorities with the product owner and the development team.

If this interests you, there are issues filed for redesigning the issue queue and creating functionality to support meta-issues that you can add your opinions to.

Project management

This all seems to beg the question: does the Drupal project need a dedicated project manager (or scrum master)? 

At this point, I would say no. Between Dries (who tends to fill the product owner role), the core maintainer he appoints (who tends to act somewhat as a project manager, and does a lot of QA), and now the new Initiative leads, I don't feel that this would be necessary during a period of more experimental adoption.

If teams and individuals try this method, and find it works well enough that it could be adopted fully for all core development, it would be a very good idea. A much more structured process takes a lot of work to keep organized and stick with, and I believe it's best to keep developers' time free to be dedicated to development as much as possible. So at this point we would want to create some overall structure in the issue queues to be able to manage sprints efficiently, and have someone who can oversee the project's organization as a whole.

Realistically, I don't think this would be necessary very soon. For now, I would suggest anyone interested start with:

  • Running set sprints (recommending one month). Meeting at least once per sprint (on IRC or by voice) to review and align priorities amongst whoever is working on a given issue/set of issues/initiative. Communicating frequently on IRC (like we always do!).
  • Defining work to be done at the start of the sprint, and doing your best not to introduce new work into the in-progress sprint. In the beginning, underestimate how much can be done, until you get a feel for the momentum possible in a single sprint. If some things don't get finished, they go back into the "backlog" (or main queue of issues) and are reevaluated in regards to whether they will be in the subsequent sprint.
  • Making sure at the end of the sprint (or phase for larger initiatives), that you pass through the "gates" and deliver functionality that is completely "done" and ready to merge into the master branch.
  • Making sure that no bugs get into the master branch so it can always be ready to ship. As a result being able to make the release cycle any length, and launch on short notice if desired.
  • Avoiding technical debt (things that you put off that will need to be done later); making time for refactoring or bug-fixing as you go. Possibly even having a technical debt recovery sprint early on.
  • Defining the "gates" clearly and deciding who is responsible for signoff before merging into the master branch of core.
  • During this experimental phase, making sure there are some resources that teams and individuals can refer to and learn more about these methods. Possibly looking for project managers in the Drupal community who are familiar with agile development, and open to informal advising on IRC.
  • Remembering that this is a pilot project of sorts. Not putting too much pressure to follow capital-A Agile strictly. Letting this be an organic process to see what fits the community best, while leading to a more efficient, clean, and smooth process.

I was extremely happy to hear how open and interested the other attendees of Dries' core conversation were, and hope this helps clarify some ideas. This should be an open discussion rather than anything too prescriptive, so I would love to continue the conversation and hear your feedback, questions, and concerns below.

(ps. The Drupal 8 wordmark used with this post on the homepage is from Dries' slides, just for the record!)

Mar 09 2011
Mar 09

I gave my "Views for hackers" talk at DrupalCon Chicago yesterday. This was definitely the biggest attendance I've ever had in my short experience as a speaker! Thanks everyone for attending and for the great questions. Please rate it at the DrupalCon site, this will help me improve it. Thanks!

Here are the slides as uploaded to SlideShare:

AttachmentSize 191.42 KB 272.33 KB
Dec 17 2010
Dec 17

2010 has been a big year for the Drupal Association. Early in the year new members were brought on and the Board of Directors saw some changes. But most noteworthy is what the Drupal Association did for the Drupal community;

Screenshot of the newly redesigned Drupal.org.

Drupal.org Redesign Completion

Drupal.org has a new look and feel. If you have not seen it (have you been under a rock!?) go check out Drupal.org right now!

It took a few years and many iterations and volunteers, and even that was not enough. This year the Drupal Association came to the party with funding to finish the job. Contracts went to tender and were won by Neil Drumm, Achieve Internet and 3281d Consulting.

Thank you to everyone who contributed to the Drupal.org redesign for all your hard work and effort to pull this off. And especially thank you to the Drupal Association for funding the last several miles that could not be covered by volunteers alone.

Drupal.org will never be the same again! Find out what is next for Drupal.org.

DrupalCon San Francisco

Photo of chx with a large DrupalCon San Francisco logo on the projector screen behind him.
Photo by Kathleen Murtagh

How could we ever forget? DrupalCon San Francisco, was epic. By all measures, it was the largest and most spectacular Drupal event yet.

The Drupal Association bootstrapped the funding and locked in critical contracts in order to secure the venue and other services. Many of the DrupalCon San Francisco committee members also serve the Drupal Association. The Drupal Association managed all the finances for the event and coordinated the local team and service providers with the rest of the Drupal community.

And that is just the beginning of what the Drupal Association did to make DrupalCon San Francisco a reality!

Git Migration

Photo of Sam Boyer posing with a Druplipet on his head.
Sam Boyer. Photo by Fox

The Drupal Association recognized the urgency to update Drupal.org's version control system (currently CVS).

Drupal has an active, amazingly awesome and amiable community. One of the reasons for this, is that Drupal.org is our home. It has everything Drupal developers need, all in one place. However the last couple of years has seen a trend for contributions to be distributed elsewhere.

The Drupal Association realised that if Drupal.org did not offer modern version control and code-distribution tools, then Drupal.org would cease to be a central repository for contributed Drupal code. And that would ultimately be damaging to the community and the project.

Git logo

So earlier this year, the Drupal Association hired Sam Boyer to work on detailed planning and foundation work in preparation for the migration of Drupal's gigantic CVS repository, including about 9000 contributed themes modules and other projects, to Git.

This work is underway and is making good progress, but has some way to go yet. Sam is leading the effort but the success of the project is highly dependent on volunteer effort too. You can get involved on g.d.o.

Paid Staff

Early in the year, Treasurer Jacob Redding was hired as full-time General Manager for the Drupal Association. More recently, the Drupal Association hired Neil Kent as a Events Manager and Megan Sanicki as Sponsor Wrangler (Fundraising Manager).

Jacob does a wide range of tasks including managing financial assets and tasks, lawyers, accountants, contracts, bills, Drupal Association meetings and boot load of other tasks that arise.

Neil is working hard on a range of administrative, logistic and financial tasks related to DrupalCon Copenhagen 2010 and DrupalCon Chicago 2011, as well as trying to document it all and make DrupalCon production more sustainable, so that it is not so much work to reproduce DrupalCon in a new location every 6 months.

Megan is working on raising funds and managing relationships with past, future and potential sponsors, for both DrupalCon and other projects of the Drupal Association. She is also exploring new avenues of revenue.

These funds allow the Association to;

  • pay salaries of staff
  • fund hardware that keeps Drupal.org online
  • fund projects like the Drupal.org redesign and the Git migration
  • pay contractors to keep Drupal's websites up to date, secure and useful to the community

Megan's, Neil's and Jacob's responsibilities are critical to the health of the Drupal Association. Which is in turn, critical to the Drupal community and the resources they depend upon, such as Drupal.org and many other infrastructure services.

Legal and Financial Achievements

Through the careful management of Jacob Redding, the Drupal Association has managed to achieve all of this with less than 25% overhead. That is incredibly low for any non-profit or trade organisation.

DrupalCon Inc. received its 501c3 (not for profit) status, which allowed tens of thousands of dollars to be put right back into the Drupal community. This was a major process to work through the processes of the Internal Revenue Service agency of the US government.

Additionally, the Drupal Association;

  • got payment time for invoices down to less than 30 days (from more than 60)
  • turned over more than a million US dollars
  • registered for tax purposes in four countries
  • was a fiscal agent for 3 major DrupalCamps in the US; NYC, Colorado and Chicago

Mission Statement

Another important achievement of 2010 was updating our mission statement. We began this process in April in San Francisco at our full-day-long meeting, then iterated on it over the following months to reach the final wording.

You can read more about the process and work that went into the missions statement in this blog post by Robert Douglass. Or you can just skip to the result;

Mission Statement

The Drupal Association fosters and supports the Drupal software project, the community and its growth.

The Drupal Association does this by:

  1. Maintaining the hardware and software infrastructure of Drupal.org and other community sites.
  2. Empowering the Drupal community to participate in and contribute to the project.
  3. Protecting the GPL source code of the Drupal project and its community contributions.
  4. Protecting the Drupal project and community through legal work and advocacy.
  5. Organizing and promoting worldwide events.
  6. Communicating the benefits of the Drupal software.

The mission statement helps guide the Drupal Association in it's decision-making, and makes it clear to the community what the Drupal Association does and does not do.


Another of the main outcomes of the full-day-long meeting in San Francisco was a list of the five highest priority goals;

  1. Completing the implementation of the Drupal.org redesign
  2. Continuing to build a sustainable model for DrupalCons
  3. Improving internal processes and decision-making
  4. Hiring permanent staff to help the DA better execute on its initiatives
  5. Improving the technical infrastructure of drupal.org

We completed items 1 and 4. Double yay!

We made excellent progress on item 2, including hiring an Events Manager and outsourcing website development to Growing Venture Solutions. However scaling the production of 3000-person bi-annual events is a large project that will take time and never be completely finished.

Similarly, item 5 is never really "done". Maintaining Drupal.org hardware, software and infrastructure is a never-ending job that volunteers work at tirelessly and with very little thanks from the hundreds of thousands of members and visitors to Drupal.org. The Drupal Association applauds their hard work and thanks them sincerely. The Drupal Association funds some of this work from time to time when volunteered time is not sufficient, and also pays for hardware and expenses required for the task.

As for item 3, the mission statement is one significant achievement towards this goal, but there is a lot more to it than that. Additionally, the Drupal Association has hired a consultant experienced with non-profit organisations to help us determine changes to structure that will help us achieve this goal. We are looking forward to report the changes that we decide to implement and how this will improve the efficiency of the Drupal Association to better serve the Drupal community.

Thank You!

Thank you for empowering the Drupal Association with your financial contributions and volunteer effort. You can continue to donate to the Drupal Association by;

Sep 14 2010
Sep 14

A few weeks ago, I embarked on my first overseas trip to go to Copenhagen for this year's European DrupalCon. It was my 4th DrupalCon to date, but I've been wanting to attend one of the European ones for a while, as they have a reputation for having a different vibe than the North American ones (and of course so I could finally see some of Europe!)

The Core Dev Summit (+ Code Sprint Day)

Like the last conference in San Francisco, it was prefaced with the Core Developer Summit, which is a full day of presentations, discussions, and code sprinting on the core Drupal platform. The Core Dev Summit is the single day (twice a year at this point), where a good number of the people who work on Drupal core come together to take a step back and discuss in-depth any ideas or concerns. This often leads into some dedicated sprinting on core related issues (as well as some of the most crucial contributed modules).

I attended mainly for two purposes: to keep on top of what all the core developers are up to and get some face time with them (since I usually only talk to them online), and to make sure there was some representation from the Drupal Docs team there.

I've been working on the online Drupal documentation a lot lately, helping to prepare the it for the Drupal 7 launch, and ended up leading an impromptu docs sprint when several people volunteered to work on the handbook for the second half of the day. It was great to get some help from both people who were new to docs as well as a couple fairly hardcore long time developers. Big thanks go to Djun Kim (aka. puregin) for working on the handbook page for the new-to-Drupal-7 File module, and to Ken Rickard (aka. agentrickard) for working on the new-to-Drupal-core Field and Field UI handbook pages. It was fantastic having help from some great developers writing these, and Ken actually found a pretty big permissions bug while writing the page.

...when you write documentation, you are forced to take a bit of code and really understand it. You [read] through it, make sure it does what you're saying it does, and test it. Guess what happens when you dig into code that deeply? You find bugs!

And because it's so encouraging (and true), I have to add this other bit he posted:

If you are interested in getting involved in core, working the docs queue is the single best way to do it. You find bugs other people miss, the patches are generally easy to get committed, you get used to the issue queue and creating patches, and best of all the patches are enormously valuable. Get to it!

(Off-but-on-topic, Angie Byron, aka. webchick, just put up a great post on contributing documentation on the Lullabot blog today, go read!)

Neil Drumm (aka. drumm) who works on the API docs and is currently helping manage the Drupal.org redesign was there as well, so I got to review some of the docs.drupal.org in-progress redesign with him. The redesign team has been doing a fantastic job, and I'm really looking forward to the relaunch and some of the freedom that will be afforded by having a separate subdomain for documentation.

I was also really pleased to get the opportunity to participate in a discussion about the CVS application process, which was has been a hot topic recently. Sam Boyer (sdboyer), who is working on the Drupal git migration, led a discussion to get feedback from many long time core contributors. Mainly, we talked about what is still broken in the process, what needs to change, and what small but effective changes could be made during the git migration to help improve matters. Main suggestions focused around ideas about how to manage namespace and numbers of modules, how to mentor new applicants, and the need to recruit more reviewers.

The post-conference Code and Docs Sprint Day was also extremely productive even though I was feeling a bit off and had to lead the docs sprint from back at the apartment! We did a kickoff over Skype then worked over IRC the rest of the day, and powered through a TON more of the core module handbook docs and some work on the install and upgrade guides. I really missed not being able to work in-person with everyone, but still want to thank all who turned up and cranked out some awesome docs work, namely: Steve Kessler (DenverDataMan), Alex Pott (alexpott), Barry Madore (bmadore), Marika Lundqvist (marikalu), Miro Scarfiotti (smiro2000), Paul Krischer (SqyD), Carolyn Kaminski (Carolyn), Khalid Jebbari (DjebbZ), and last but not least Boris Doesborg (batigolix) who I am really sad not to have met in person, as he worked a bunch with me on the D7 Help initiative over the winter. Next time! You all rock, hope to see you around the docs queue and IRC till the next con. 

The rest of DrupalCon...

I had to agree with what I'd heard about the European cons, as I did feel a lot more of a community vibe (probably due to the smaller size, being the same size as my first DrupalCon in Boston in 2008), and did not see a lot of the corporate aspects that have become part of the North American cons of late. Those are, of course, part of Drupal's growth, but they do change the atmosphere.

The sessions I went to were all really fantastic. I think my three favourites had to be:

  1. The Managing a Drupal Consulting Firm panel (video) - Todd Nienkerk and Aaron Stanush (Four Kitchens), Thomas Barregren (NodeOne), Vesa Palmu (Mearra), Matt Cheney (Chapter Three), Liza Kindred (Lullabot), Eric Gundersen (Development Seed), and Tiffany Farriss (Palantir) sharing stories and tips for how to be a successful and happy Drupal consulting firm. Great ideas, and bonus high comedic value!
  2. Jeff Miccolis' (jmiccolisFor Every Site a .make File - great review of .make files and associated development practices (couldn't find the video, if anyone knows where it is, comment please!)

And though I didn't attend it, Amitai Burstein's session on Group, which is the Drupal 7 iteration of Organic Groups (video) was the crowd favourite, and highly recommended as one to watch online.

What else can I say? It was a fantastic week with a bunch of fantastic people. As @timbertrand put it:

"Dear Proprietary Social SW Vendor -
this is only a taste of our development team"

See you next time!

Apr 12 2010
Apr 12

jQuery for Designers and Themers is a fun interactive session at DrupalCon San francisco on getting started with jQuery. It is targeted at designers and themers but is suitable for anyone with a decent understanding of HTML and CSS — no programming experience is necessary. It doesn't include any PHP, and only basic programming concepts are introduced.

The session is early on Tuesday 20 April in room 307 (Commerce guys) at DrupalCon SF at 8:30am.

The sample code is available at Drupal.org/Project/jQ4DaT and slides are available at TinyURL.com/jQuery-Designers (Google Docs).

Some other related or similar sessions include;

Feb 26 2010
Feb 26

jQueryjQuery for Designers and Themers is a fun interactive session on getting started with jQuery. It is targeted at designers and themers but is suitable for anyone with a decent understanding of HTML and CSS — no programming experience is necessary. It doesn't include any PHP, and only basic programming concepts are introduced.

If you want to see this session at DrupalCon San Francisco you'll need to vote on it here it is at 8:30am on Tuesday 20 April in room 307 (Commerce guys) at DrupalCon SF.

I've presented sessions like this one twice before. The first time at DrupalCon Paris September 2009, and the second time at DrupalSouth Wellington January 2010, where it was successful and well received and both times.

Sample code is available at Drupal.org/Project/jQ4DaT and slides are available at TinyURL.com/jQuery-Designers (Google Docs). (They will be updated.)

Some other related or similar sessions include;

Nov 09 2009
Nov 09

We are excited to announce the DrupalCon Asia-Pacific Organisers group. DCAPO intends to lay foundations that will facilitate international Drupal Conferences (DrupalCons) in the Asia-Pacific region.

DCAPO welcomes and needs input and assistance from Drupal users and communities throughout the Asia-Pacific region. DrupalCons are a lot of work, and are only possible through the community's effort. Please join the DCAPO group to share your opinions and experience, volunteer your time, or nominate yourself or others for roles on the selection team.

DCAPO will later announce a call to the community to suggest and research locations for the first Asia-Pacific DrupalCon. Note that a lot of work goes into researching locations. The DCAPO selection team will only be able to seriously consider locations with suitable venues, dates and event management companies, financial estimates, potential audience and motivated local teams.

But first, as much of the Asia-Pacific Drupal community as possible needs to get involved. You can help by translating and reposting this announcement on other websites where Asia-Pacific Drupal users and communities are likely to find it. Don't forget to note any translations and reposts in the DCAPO group so that we can track progress and share translations with each other.

DCAPO is a result of the Drupal Association's new Events Plan (announced on Drupal.org) to have an Asia-Pacific DrupalCon every two years.

Thank you!
From the DrupalCon Asia-Pacific Organisers group

Mar 01 2008
Mar 01

I arrived in Boston yesterday afternoon, absolutely exhausted after Usability testing at UMN -- which was amazing. See the report at 9am on Monday to hear why. It was snowing heavily here this morning. Today I need to prepare for my presentation on Scalable Theming and my parts of the Usability presentation, and try open another US bank account.

Here's my photoblog to date:

A few NEW cultural oddities I've noticed in the US since my last visit 5 years ago:

  • Airport pager: "The security threat level... is orange" -- talk about
    fear-mongering. No need for foreign terrorism in the US -- the local authorities are terrorizing plenty enough here!
  • Control-culture doesn't seem to be so severe this trip but is still grating. I think that's more to do with the people and places I'm mingling with though.
  • You can't seem to fill up a bottle with water anywhere. They seem to be getting the idea of 'being green' with recycle bins and signs to conserve hand-drying paper in the toilets and not leave the tap dripping, yet it's difficult NOT to go through several styrofoam, paper or plastic cups, bottles, plates and fast-food trays per day. I wonder how effective the recycling actually is here? Given the amount of extremely cheap "recyclable" materials consumed, and the fact that these materials usually aren't economically worth recycling, I suspect very little of it is actually recycled. Even where recycle bins are present. Meaning all the recycle bins do is make you feel less guilty about being a polluting consumer.
    • Most annoyingly of all for me, I can't fill up a bottle with tap water anywhere except a public bathroom, which 'feels' unhygenic, although probably isn't.
Jan 29 2008
Jan 29

I assume any future DrupalCon Down Under (wherever it ends up) would attract less North Americans or Europeans purely from a travel distance point of view anyway, so might not need quite the same size facilities as the Boston or Barcelona events would. But it would probably still be quite a stretch to justify and/or organise an NZ event.

More realistically an Australasian miniconf as part of a future Webstock (eg Wellington 2010) would be pretty cool. Or if LCA comes back to NZ - Due to circumstances I missed both LCA Dunedin and the previous Webstock unfortunately.

Or maybe with the help of Silverstripe (and any O'Reilly or Google friends they have) get an open source CMS conference happening down under?

Jan 25 2008
Jan 25

[Update: This had the wrong tag to get on Planet Drupal]
As others have noted, the DrupalCon Boston logo contest is closing soon, so you'd better get your votes in.

Here are my personal favourites;

  1. About 3rd as far as user-votes go, with 36 points; DB8
  2. LauraS only just submitted this one, so it's only got a few votes so far: BoSox style by Don Hajicek at pingVision
  3. This one is simple and elegant, although probably not everyone's cup of tea. By Dakku:

And here are the leading entries so far, by user-votes:

  1. 50 points, By Acromedia:
  2. 41 points, Boston Seal, by Konstantin Kaefer:
  3. 29 points, By Camworld:
  4. 28 points, the luck of drupal, by corinn:
  5. 19 points: DrupalSox by pcorbett:
Mar 27 2007
Mar 27

I started the morning with a round of Drupal lightning talks -- eleven topics in sixty minutes. dww even convinced me that if I ever actually have free time, I should pitch in a bit on project module.

Dries' "State of Drupal" talk was excellent, though the audience as a whole didn't seem to react well to the bit about eliminating the webmaster, developer, designer, etc. The whispers and whines in the crowd implied that some people found those statements threatening. I'm mentioning this because I didn't feel that way, and I'd like my fellow geeks to know why: web technology is an ever-evolving industry. I've been doing system administration since the early 1990's, working with open source software since 1995, and playing with web technologies on and off since the 1990's as well. NOTHING is like it used to be, and *I'm still here*. So are a lot of other people. There was a time when the end-all and be-all of being a webmaster was smashing text and some basic HTML into static pages, then updating them by hand any time anyone wanted to make a change. Then came scripting and databases -- suddenly you could code your way out of the repetition, and even make some editing and interaction (such as web forums) available to users. The hard-core coders moved on to writing scripts, the less nuts-and-bolts folks formed new niches as site moderators and documenters, and users could now contribute directly to content. Those less interested in adapting moved on.

This is what Dries was talking about when me mentioned "eliminating the webmaster". On many sites, users began to take a leading role in entering content. Now we've moved from every site being scripted in isolation, to CMSes where a community of developers and themers can provide the tools for even non-coders to create web sites with all sorts of features. The internet is still evolving, and will be for the foreseeable future. I'm not afraid of the market for my talents drying up tomorrow, nor should anyone else be, as long as they are willing to learn and step into the next niche. In the mean time, keep innovating! If you doubt how much work there still is to be done, take a look at the Drupal issue queue and forums sometime.

Next came a talk on the Date API and Calendar modules. Karen's presentation was absolutely wonderful, and I learned more than one useful tidbit about managing time, scheduling, and iCal feeds in Drupal. Steven Witten's talk on jQuery convinced me both that JavaScript is every bit as hideously disgusting as I thought it was, and that jQuery makes it tolerable to add some JS tricks to things I'm working on (for those users who even enable JS) without feeling dirtied by the evils of JS code. Last, but certainly not least, I sat in the audience of the Live from OSCMS Summit Drupal podcast/netcast. There's no need for a long description here, you can listen for yourself.

After the close of the summit, some of the Lullabot crew, a few other Drupal geeks, and I went out for Thai food. Still fewer of us ended up in add1sun's hotel room, where much Drupal hacking goodness and a fair bit of socializing took place. We were joined by Leslie from Google and a couple of Joomla folks. I finally headed back to my hotel around 3am, my head buzzing with thoughts of projects to come, some curiosity about the aggregator module and what might be involved in cleaning it up, along with a healthy dose of laptop-related determination. I was still buzzing on the plane ride home. Those of you who have had the good fortune to fly off to a brain-bendingly interesting conference and there meet at least a dozen people you've worked with for ages but never met face to face, only to become even more excited about the project that brought you together know exactly how I feel. The rest of you couldn't possibly imagine, so I hope you get to try it some time.

Mar 27 2007
Mar 27

I started OSCMS by making hasty child care arrangements from my cell phone in the airport Wednesday night, due to my mom's flight being canceled in the eleventh hour. Everything worked out, though I also spent a large part of Thursday on the phone, ducking in and out of sessions to coordinate the situation at home. My poor mother finally made it to my place late Thursday night. I'm still glad I went, though I feel pretty bad that my mom went through all of those delays and cancellations.

Rasmus Lerdorf's talk alone made the trip worth it. He's an even better public speaker than I'd heard, and I learned some new things about PHP, including the existence of some tools I can't believe I didn't know about. The OpenID talk was well done, but really didn't tell me anything new. I changed my mind about "Theming Drupal" and instead went to chx's talk on the new menu system. I am glad that I did. Not only did I learn quite a bit, but I ran in to webchick, the first of my fellow Drupalers besides chx to whom I could match nick, real name, and face. She is even more awesome in person than online. Her astute questions and comments added a lot to every presentation or discussion I saw her in. I certainly picked up a lot more than I would have had she not been there. Yahoo's hospitality was top notch. They provided parking, meeting space, food, swag -- all the essental materials. I even managed to get some extra swag for mom as a thank-you for all she went through to babysit for me. Earl (merlinofchaos) gave an outstanding talk about node_access. It was my favorite among today's talks. After node_access, I attended the Drupal Search talk, but gave up on the internationalization talk part way through because I have a horrible time following people with strong accents when I don't have enough visual cues to make up the bits I missed. I plan to catch up on the internationalization info online once the conference is over. I nabbed a great pick-up discussion in the common area after leaving, so the time block definitely wasn't a loss.

The summit wrapped up for the day around 5:15, but I stuck around for a quick Drupal Dojo meetup. Following that, I joined sepeck, webchick, add1son, jjeff, eaton, Dries, dopry, chx, KarenS, merlinofchaos, and many others for dinner, drinks, and witty banter. Much fun was had by all, and if my head wasn't already completely awash with new ideas after my day at the summit, it was when dinner ended. My only regret is not having a functional laptop to take notes, scratch out ideas, etc. on. (Not to mention the coding withdrawal I've had lately for the same reason.) I can't wait for tomorrow.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web