Check out our Drupal contributions for the month of May.
Check out our Drupal contributions for the month of April.
Sheldon tested a patch for the Address Field module. The Address Field module allows developers to build content types that can save postal addresses. If the field is optional upon node creation then no information should be required.
Today marks the official opening of the call for papers for DrupalCon Portland. Yay! Head over to the DrupalCon Portland site to start your session submission now!
One of the greatest aspects of Drupal is the outstanding community of Drupal users and supporters that constantly work to not only make the software function better, but to make your overall experience using it better. With Drupal, that experience has many opportunities to extend beyond the electronic world and into the real world by way of DrupalCon and regional Drupal meetups. Prior to moving to Portland, Oregon, I had the privilege of coordinating the Denver Drupal meetups and have been able to visit other meetups. While all regional meetups have their own local flavor, they are all share a welcoming atmosphere... and the Portland meetup is no exception.
April's Portland Drupal meetup kicked off with Voodoo Doughnuts (courtesy of the Drupal Association), followed by reports from DrupalCon Denver. Some of the highlights that Portlanders mentioned include:
Following the highlights, Jacob, Neil and Stephanie talked about what DrupalCon Portland means to the local community, how Portlanders can get involved and a bit about the process of hosting DrupalCon. It's a lot of work (even with the incredible support provided by the Drupal Association), but the Portland community is excited to jump in and make DrupalCon Portland the best one yet. If you'd like to get involved, fill out the volunteer form.
With the air still buzzing with DrupalCon talk, we headed over to The Lucky Lab Beer Hall for food, drinks and continued discussions. For information about future Portland area meetups, visit the Portland Drupal Groups page.
This past week at DrupalCon Denver, I attended a wonderful BoF on project management. The session started as a conversation about the complexities of Drupal project management. As we collected a bulleted list, one item in particular from our list stuck with me:
In Drupal development, fixed budget projects exist in an instantaneous sense, but in reality evolve constantly.
One can never account for every unknown on any given project, even when given an infinite amount of time. This idea captures the typical project process exceptionally well as Drupal (and its community) rapidly changes and improves, but we often stumble on the "two steps forward, one step back" phenomenon as a part of this. How can we account for these external risks and explain this phenomenon to our collaborators in the project process? Without firm understanding of this concept, the frustration is likely to mount for all parties.The illusion of moving forward by several paces only to jump back detracts (sometimes entirely) from the fact that progress has been made. This often leaves development teams discouraged and clients, stakeholders and collaborators neglected. As project managers, we're posed with bridging the gap. But how?
Because sometimes modules become abandoned, patches never get merged, and other dominant features crop up, it's best not to guarantee the use of any one particular module, installation profile, distribution or any other kind of feature, but rather an encompassing functionality. For example, instead of specifying the use of the ShareThis module, specify the functionality for users to share pages with members of their social networks. Not only does this get at the meat of the problem we're trying to solve, it explains it in language that our stakeholders will understand, and it won't lock the development team into a dead-end in terms of solutions architecture.
At this point, I can hear site builders and business developers alike saying to themselves, "You expect us to account for building this feature from scratch when there's already something out there that does what I want? That will multiply the size our estimate!" The answer is: not necessarily. Obviously, the Views module is not going to be abandoned any time soon (and if it somehow is, there better well be an jaw-droppingly awesome successor). It really depends on the strength and the state of the feature the developers wish to incorporate, and how cutting edge the stakeholder wants to be. The most cutting edge stakeholder will likely be understanding of the two-steps-one-step phenomenon, so it's a moot point. Those who aren't looking for the shiniest tool in the toolshed should be happy to settle with something that is tried and true. As for those who fall in between, consulting on a feature-by-feature basis will likely get you what you need to accomplish the project: "We could go wtih module X which is currently the standard, or we can try module Y which seems to be up and coming for such and such reasons, but may have risks involved as it's still in its early stages."
Another great resource to determine where a particular feature is, and where it is going is by consulting the good old technology product cycle diagram (More about the product life cycle on Wikipedia). The development team should be able to place where the feature falls in the product cycle. If they can't, then it's probably not a safe bet. Anywhere at the tail end of a growth phase or in the maturity phase is ideal. This diagram will speak to many clients, stakeholders and collaborators in a way that they will understand. If they see that the module they're interested in is in a decline or an early growth phase, they should be able to understand the consequences with little explanation.
A cry I hear coming from the coding side of my psyche is: "Modules and other functionality can't be swapped out so simply-- they aren't interchangeable. What if the module we intended to use is one I'm familiar with, but the one we end up going with is completely foreign to me?" This begins to get into internal risk mitigation and recognizing the skill set of your team. Skipping over the complexities of that (enormous) topic, before selecting a module and getting gung-ho about it, give your developers time during the design phase to familiarize themselves with the options, and gain confidence in their ability to manipulate them to suit the needs of the project. If they're not confident in this before the design is solidified, they may as well be building the feature themselves. How this affects budget, especially with regard to an increase, will need to be discussed with the client, and the budget balanced accordingly.
In the end, by avoiding specifics and focusing on goals (while still emphasizing the feasibility of the target) in the sales process gives the design and development team the freedom to accomplish the goals in the best way possible in the moment. If uncertainties arise out of product life cycle changes, the path forward should be determined by the stakeholders, so long as they understand the consequences and the available options fit within budget (which could encompass an entire blog post on its own).
All in all, my mind is still churning the ideas exchanged during the brief 15 minutes in this one hour BoF in the three day conference and I can't wait to contribute again to the DrupalCon experience (next time, at home base!) in Portland in 2013. Looking forward to seeing you all next May!
Image: A graph of Everett Rogers Technology Adoption Lifecycle model. Drawn in OmniGraffle and then trimmed in Apple Preview. http://en.wikipedia.org/wiki/File:DiffusionOfInnovation.png
I had a great time in Chicago, at my first-ever DrupalCon! Several sessions I attended confirmed to me that we’re using many cutting-edge development practices for Drupal development at OpenSourcery already; it’s nice to hear some of the brightest minds in the business tell you things you already know. Fortunately, I wasn’t able to get too full of myself, because every time I thought, “Yeah, that’s cool, but I already knew that,” there would be a few extra details mentioned that I hadn’t thought of on my own—the icing on the Drupal Best Practices cake. Three examples I’d like to share came from the Advanced Features session, a Design Secrets BOF, and the Advanced Drush session.
Drupalcon Chicago introduced the core developer track (Core Conversations) as a parallel track to the normal, broader tracks. Because of this, and a series of compelling BOFs, I spent comparatively little time in the main session halls during the conference. Below I cover some of the topics and discussions that got me excited about Drupal 8 and the direction of our community.
There was a core conversation about Butler, but unfortunately, there is no video (oddly, no video from Copenhagen either), or slides from what I can find. The initiative was also mentioned by Dries during his keynote presentation as one of the goals for Drupal 8. The overarching idea is for core to provide a unified context system, coupled with a better plugin system. This will allow, among other things, better rendering of non-HTML pages, faster rendering for HTML (eg, small portions of a page can be rendered), and allow for better web-services support. The project can be followed on Drupal Groups, and there is code available for Drupal 7 in contrib.
The idea behind Snowman is to build something with Drupal core that does something. Whether the goal is a gateway drug, an on-ramp to contrib, or a canary for determining what can be axed from Drupal core, depends on who (and when) you talk to. Nonetheless, I think the idea is a good one. During the core conversation, it was mentioned that this could be dangerous, because something can always be built better using contrib. So if Drupal is packaged as the definitive Foodie Club site, for example, it could potentially do damage to Drupal's image since it wouldn't be as polished as a site that took advantage of contrib. The proposed solution to this concern would be to direct the new user, via content in the installation profile, towards groups or categories of modules that could quickly be used to further enhance the site.
My favorite session was a discussion between Moshe, Eaton and Irakli, moderated by Eric Gundersen. While the video isn't too exciting (no slides, but the audio is good), the discussion is fantastic. Moshe explained that his vision for Drupal core would be to follow something similar to the Ubuntu project, where core itself might be hidden away for developers ('drop' perhaps), and the Drupal.org homepage would direct users to any number of flavors (distributions with a purpose). These distributions would be free to move at an independent pace from core, always targeting the latest stable release. Related to this, Eaton explains his then-named Tsunami initiative (since renamed Snowman, and explained above) as a sort of canary that could be used to define what constitutes the core of Drupal.
With over 30 Portlanders in Chicago for the conference, this represented more than 1% of the total conference attendees. Additionally, during the git phase next presentation, 5 out of the 11 people thanked on-stage hail from Portland and the surrounding area. The Portland Drupal community is indeed flourishing!
Eaton comparing Drupal to platypodes and broader ecosystems was one of the best sessions I made it to, and is well worth watching if you missed it.
I've recently returned from an amazing time at Drupalcon Copenhagen, and wanted to highlight some of my favorite sessions, events, and departing thoughts (this also serves as preparation for the impossible task of summarizing such an epic and comprehensive conference in 15 minutes for this week's Portland Drupal group). While I can't cover them all, the complete list of videos from Drupalcon Copenhagen can be found here.
Jeremy Keith, not only touched on the core functionality and concepts of HTML 5, but also spent a great deal of time focusing on the history and reasoning behind the design.
This session sets a new bar for presentations, not just at Drupalcons, but for conference presentations in general. Amitai Burstein managed to map the complexities of international relations to the new flexibility of groups in Drupal 7, in a witty and hilarious manner.
UPDATE: Amitaibu has an alternate version of the presentation video that shows his introduction a bit better.
If you haven't been following the development of this Drupal mapping solution, this session is a good place to catch up. The presentation did an excellent job of detailing the creation of complex maps, that are based on views and are fully exportable.
Find out how using Drush make to build sites encourages developers to contribute back patches, rather than running monolithic and duplicative code repositories. Unfortunately, as of this writing, the video is not available on archive.org. Once it is, it is well worth a watch. In the meantime, Jeff Miccolis has this related blog post.
Angie Byron's session provides a nice, friendly overview of some of the major, user-facing changes that Drupal 7 will bring. For a more behind-the-scenes view, Damien Tournoud highlights some of the lesser-known features (video) such as job queues and the fine-grained caching options available. Larry Garfield covers some goals for Drupal 8 (but first, of course, let's get Drupal 7 done).
Speaking of which, the 2 code sprints (the first after the Core Developer Summit, the second after the conference), saw the critical issue queue drop to 13 at one point, but then, with the additional attention of developers, it bounced back up to around 25, and is currently hovering at 29. There's even a site to see what these numbers might mean for a release date for Drupal 7.
I have just returned from DrupalCon San Francisco 2010, the largest DrupalCon ever. With over 3000 attending, and $72,000 worth of coffee consumed, it was a very lively event. Thanks to the awesome work of those organizing, nearly all of the sessions now have high quality video available on the DrupalCon site, and on Archive.org. Below are the sessions that really left an impression on me regarding the future direction of Drupal.
While we've been using context on most projects for quite some time, the work presented here around the spaces presets has me itching to try integrating them into some upcoming projects.
The page rendering system in Drupal 7 waits much later in the process to transform structured data into the relevant output format (which is typically HTML). Practically speaking, what this allows for is
hook_page_alter, which has access to the contents of the entire page, in a structured array. Two highlights:
This talk wasn't specific to Drupal (yet anyway), but rather, provides a sort of roadmap to the future of Drupal and the social web. By combining 4 rather new protocols (PubSubHubbub, WebFinger, ActivityStreams and Salmon), Brett Slatkin of Google walks through the potential for realtime feeds being used to contect people like never before.
It would be very powerful if any Drupal site out there were capable of sharing, in real time, at the level Brett outlines in this talk. The Feeds module is already capable of consuming PubSubHubbub, and support for ActivityStreams have a little momentum. Salmon and WebFinger, as well as publishing to hubs for PubSubHubbub are the pieces that need to be filled in.
At Dries' keynote, he showed a best case scenario (June 2010), a worst case scenario (October 2010), and an ideal scenario (lock the 3000 attendees in until it was released at the conference) for the Drupal 7 release.
While we already missed the ideal scenario, the progress made on critical bugs at the conference has the community working at a velocity that should come in closer to the best case scenario. Over the course of the week, thanks to the awesome gatherings at the chx coder lounge, the number of critical bugs dropped from 114 to 94 as of this writing.
I attended several sessions at Drupalcon on performance and scalability. One common thread was the need to offload static files to dedicated servers or a content delivery network (CDN). The use of a CDN is also part of the well-known YSlow test for measuring front-end performance. With CDN providers getting cheaper by the day, content delivery is not just for big media companies anymore! A bit more explanation is required to understand why this is complicated in Drupal, and what's being done about it. As a bonus — I'll share a trick for getting a useful chunk of your files on a CDN in less than 3 minutes.
First, if you aren't at Druaplcon this year, recordings of most (all?) off the sessions are available online! I've even bookmarked several that I couldn't attend, but want to watch later.
Here are some highlights:
The session I was most excited to see at this conference happened to be on the very first day, "Training: Boosting our raw capacity to provide Drupal training". It turns out, as OpenSourcery Training and Quality Assurance, I was drawn to pow wow with the presenters after we ran over time.
Barry Madore, Sean Effel, Lee Hunter, and Alex Urevick-Ackelsberg each gave a short talk, followed by panel Q&A, around the different styles of training they employ and their varied methods for improving the trainings through feedback. The training perspectives varied from speakers dealing with training drupal users every single day, to training a drupal development and sales team in how to work well with the drupal community. I will focus more here on the end-user.
One of the more potentially obvious take-aways from the talk was something I've seen folks miss the mark on: know your audience. When we start building tools to be used to understand the product the end-user has, we can lose sight of the user's goals. What is most important to the user of the software is nearly never the shiny piece of code, or a loving explanation of why it is fantastic. The exact function of the code or application may also be missing the mark of what a user really wants to know. They want to know how to use the system everyday. Your users really don't want to know how they can hack the code, but how they can interface with it without fear.
That which we are thinking about as software devs has already been invented and re-invented by teachers. The art is assessing knowledge, and then creating education and curriculum from that assessment. What we need is practice as educators, and the same education principles apply to drupal as apply to any other classroom. How much do they know? What else do they need to know? What might need to be un-learned? Are there different learners in the same group? Those questions get you close to having an assessment on which to found your curriculum.
Again, looking to the educators on curriculum, we should start by covering the concepts in the best logical order. That might not be in numerical sequence, but probably by associated concepts. One of the best parts of creating a plan like this is the exposition of concepts. This can increase confidence in knowing the right answer before a user would need to push a button. The last piece is, of course, cementing the lesson. Repetition is excellent to get you used to a new pattern of thought. Having 2 shorter trainings with time between is more effective than having a single day long training.
My hope is to bring fearlessness to software users through education. With the right tools, the hardest problems look easy. What is the worst we could do, break it? That'd be sweet!
This week, the Drupal team is out in Washington, DC for DrupalCon - an unconference for Drupal lovers getting together to share knowledge, exciting developments in the field, better practices, and actually meet face to face.
We're just back from the pre-parties and discussing the session topics, expect posts from me, Jonathan, Dylan and Stacy about what we're excited about, people we've met and good discussion.
I made it back from Hungary last Friday, and am only now starting to convince my body that it really isn't 9 hours later than it is. After Drupalcon, I managed to make it out to Eger, for castles and a valley of wine cellars (thanks for the recommendation Chrys). Following Eger I returned to Budapest to explore more castles, a Cold-war-era statue park, and some labyrinths all made possible by some of the best public transit I've experienced.
Being back, and having had a bit of time to process all that I took in at Drupalcon, I wanted to do a bit of a review of some of the highlights. For most of the talks I mention below, there are either slides, video or both available here.
The venue itself was very nice. Spacious and airy, it was the perfect place for Drupal geeks from all over the world to congregate and talk about, well, Drupal. Also, many thanks to all the volunteers and the Hungary Drupal community that made Szeged a reality.
I can't talk about the venue and the organization of the event without at least mentioning the Hitchhiker's Guide to the Galaxy theme. I won't go into too much detail, as the pictures do that, but suffice to say I thought it was awesome and thorough (42+ languages, a babelfish, don't panic and the certainty of knowing where one's towel is).
Dries, while opening the conference with his State of Drupal talk, hit on many aspects of the future of Drupal. One highlight was the idea of embracing RDF, which not only makes for richer content, but addresses the problem of importing and exporting for Drupal in an application-independent manner. Another very interesting point was that most Drupal developers feel they are best at HTML, and by the same token, want to learn about HTML the least. That's good I suppose...
Many of the sessions I attended provided a very exciting preview of Drupal 7, and I came away with high hopes for the new version.
Larry Garfield proposed the idea of getting handlers into core. My favorite example of why this might be useful was about the idea of swapping out default file handling, for say, a file handler that sends all images to Flickr, and all videos to YouTube, but behaves normally for everything else. To do this without handlers, one would need to either hack core (oh noes), hack image and video modules, or write a custom module. With handlers, the modules can simply be concerned with the Drupal API, thus making this sort of behavior module-independent. Essentially, handlers are one of the last steps towards making Drupal completely customizable without hacking core (thus saving kittens).
The very next day, Larry gave an overview of the new database layer that landed, which takes advantage of PHP's PDO abstraction layer, shortly before Drupalcon. The short of it is that the new abstraction layer looks awesome. The dynamic query builder will take the place of complicated string concatenation and pattern matching that plagues certain hooks and modules today. The new layer also provides—out of the box, so-to-speak—the ability to support master/slave replication and transactions, to name a few. Also, since this is all object-oriented, simple (but fragile) INSERT statements are no longer directly coded into modules. Instead, inserts and updates are built up using placeholders, and can be reused. Finally, the new db_merge() function will make checking for an existing record (in order to determine if an INSERT or an UPDATE is needed) a thing of the past.
Barry Jaspan gave a talk on the Field API that will hopefully be landing in Drupal core for 7 (ie, CCK in core). However, the field API isn't just about moving the CCK module's functionality into Drupal. Along the way, the code will be transformed into a real API (so that the creation and modification of fields is no longer dependant on a form submission). Another key change is the idea that fields will be attachable to anything, not just nodes. During the talk, field definitions looked to be custom classes, which seemed very clean and extendible. It was later rumored around the halls that this idea had been scrapped, but I'm unable to find any hard evidence indicating one way or another.
Peter Wolanin discussed the idea of page rendering being capable of outputting many different formats in Drupal 7. The central idea of the talk was to move page rendering to a later stage in the process, so that data can be rendered as, for example, JSON, XML or XHTML, depending on any number of factors. The only way to currently change format, is to either pre-empt the rendering level (by exiting the script early) or to re-render data, which is inefficient at best. Needless to say, this would be a welcome change.
And finally, the new file handling patch continues to get closer to RTBC.
That's all I have time for now, although there were many other very exciting and informative sessions/BoFs (I saw a demo of the progress being made with the Geo module, as well as the work Development Seed is doing with Mapnik, and am very excited about the future of mapping and Drupal).
Tomorrow I fly to Budapest by way of Frankfurt as I start making my way towards Drupalcon in Szeged. Brian will be joining me in Szeged closer to the start of the conference. I'll have several days to take in the sites of Budapest (the funicular railway to Buda Castle looks awesome), then catch a train south to Szeged. I'm looking forward to meeting so many Drupal people all in one place, and the sessions are looking fantastic.
I'm particularly excited about the Awesome Testing Party, not only due to the free pancakes, but also, writing tests is a whole lot of fun, and they're critical for a solid Drupal core, and a more feature-rich development cycle. It also looks like there should be several excellent sessions on the state of GIS, mapping and Drupal (A Roadmap for Mapping: GIS on Drupal in 2008 and Beyond, Simple Mapping Mashups with Drupal, and Mapping with Drupal and Mapnik just to name a few). And of course, no Drupal gathering would be complete without a session about Awesomeness and Drupal.
I'll be posting updates frequently from Drupalcon. Also, if you'll be in Budapest prior to Drupalcon and are interested in any pre-Drupalcon activities, drop me a comment here, or contact me directly.
While the rest of us stand enviously put, CEO Brian Jamison and lead Drupal developer Jonathan Hedstrom pack their respective bags and transform into international men of open source mystery and mastery. Both will parlay their "business" trips into personal adventures, but we expect them to enjoy the stay, hobnob with the likes of Dries Buytaert and Kieran Lal, and return with plenty of new ideas.
They leave Portland with happy news on the home front. OpenSourcery's newest Drupal developer, Dylan Wilder-Tack, is making the most of his new position. His transition has been seamless and his work spotless. We only wish he could crawl into Jonathan's suitcase (we're talking Dr. Who level of comfort, TARDIS-like in its ability to expand for our intrepid Dylan) and travel to Szeged.
And look for some very exciting Drupal partnerships in the near future, bringing OpenSourcery together with some of our favorite nonprofit and developer groups both in Portland and nationally.
Bon voyage, gentlemen. And pirítós!