Although I'm still short on sleep, I'm definitely full of inspiration coming out from last weekend's Carnegie Apps hackathon. Being a mentor at Qatar's first true hackathon was an honour. But getting to know all those passionate students was even better. And it was just that, their passion and their dedication, that made the hackathon so great.
I won't talk so much about all the individual ideas that sprung up during that night, I want to talk about something greater than individual ideas (although they were pretty darn great). I want to talk about building a culture, and a movement.
I haven't been part of Qatar and the Middle East for very long, but I've been part of it long enough to understand that programming is looked at purely as a linear, mechanical process that takes a specification sheet in one end, and produces a product in the other. It just happens, often in a slow uninspiring process inside a square office somewhere de-attached from where the ideas are created, if it's not bought from distant resources. Often this process is associated with huge costs, both in terms of labour and licensing. It's painful to talk about, it's painful to implement, it's painful to be a part of it.
But this is changing (and has already) in many parts of the world. Software is not a mechanical process any more. It's a creative process, a non-linear process. Something that can bring more value to a problem space than just solving the actual problem at hand. And it doesn't have to be painful. It can be fun and it can be fast. The students showed that last weekend.
The organizers' idea behind hosting last weekend's hackathon was to help drive this change into Qatar. And I'm joining in this effort and will help trying to change the mentality that's holding back so much creativity and development here in Qatar and many other parts of this region as well. Because truth is - there's a huge number of young and inspired people here to change this. I know many of them. We just need to be organized, and hackathons are a great way to start building something.
Here are some instructions for participants in the Carnegie Apps workshop on Wednesday, January 30 at 6PM.
This blog post will be continuously updated with more info. So please check back to stay updated!
There are 4 required preparation steps. You don't need to do more. But if you want a better chance at winning prizes at CMUQ's first hackathon you're encouraged to go through an additional 4 steps and read through some links for more background knowledge.
Preparations before the workshop
Bring your own computer, ready for hacking! Any flavours of Debian, RedHat, Macintosh or Windows are ok.
The hackathon is a 24-hour event where students can either work individually or in teams to build a cool application - be it a game, a mobile application or a web application. Students who participate in the event - referred to as 'Hackers' - can use any technology to build their application.
In the workshop I'll introduce the participants to some tools and methodologies that will help them through the 24 hours of rapid coding, with focus on web and mobile apps. During the first hour of the workshop we'll install a virtual development environment with Virtualbox and Vagrant. The environment will contain some of the most popular frameworks that's being used for app development.
During the workshop's last hour we will be build a very simple web app with a public API, using one of those frameworks - Drupal.
Obviously we won't be able to cover everything in detail, that's not the point. The point is to introduce them to some new tools and show what's possible to do in a very short time. All to help the participants to let loose of their creativity during these 24 hours! More about everything later.
DrupalCon is over (since two weeks already). It was an awesome time. Some say it was the best so far. Thankfully it doesn't mean that the community will sleep until Munich. No, now it's time for action! The code freeze is coming closer and things need to happen quickly.
One of the things that I've decided to help with for Drupal 8, is improved support for content staging in core. At DrupalCon there were quite a bit of discussions around this matter. And I'm going to try to summarize this in this blog post.
Content staging is a lot of different things to different people. It involves workflows, APIs to manage content, universally unique and identifiable content, APIs for pushing and merging content between environments, and so on. Many people also use content staging-like functionalities to share content across networks of sites. So, when people talk about content staging they often talk about it in different contexts or focusing on different technical problems. Here are some of the semi-related discussions that took place.
@stevector and robeano held a core conversation about the editorial workflow experience in Drupal and highlighted some problems with revision management in core. This is something we need to improve to efficiently be able to stage revisions of content. But more about that in the next blog post. Listen to the core conversation here: http://denver2012.drupal.org/content/i-just-want-edit-node
Discussions about Entity API
On Tuesday (if I recall correctly) we held an Entity API BoFs. One of the things we talked about was introducing a Property API, similar to what the Entity API contrib module for Drupal 7 provides. This would unify how we interact with fields and properties on the code level and help solve one of the toughest problems for efficient content staging, namely consistently tracking what properties and fields that adds dependencies (like author or taxonomy terms). This would then be defined in the property API, similar how "data types" are used in the Entity API contrib module and Rules.
Another important discussion that happened around the Entity API in core was @DamZ's and @lsmith's core conversation about implementing standards for document storage in content management systems in general, but Drupal in particular. One of the very interesting topics was the plan for introducing PHPCR to Drupal. PHPCR defined a standardized API for how content should be stored and managed. That in turn, would make it a lot easier to implement a standardized outward-facing API and a canonical format for our content (like CMIS). This would define a more robust transportation protocol for moving content between environments. Go ahead and listen to the whole core conversation here: http://denver2012.drupal.org/content/open-standards-and-document-oriented-storage.
Notes from the content staging BoFs
For the Drupal 7 BoF that was held, we mostly talked about how people are tackling content staging (and similar functionality) right now. We simply concluded that people and organizations do it very differently. Some people are using Deploy, some people don't, some people build more advanced content staging/preview functionalities on a single site together with modules like Workbench Moderation or State Machine. One thing that came out of the Drupal 7 BoF was that we should look deeper into how we can integrate Deploy and State Machine better with each other. More on this in another post.
For the Drupal 8 BoF we identified some of the things I already mentioned in this blog post:
better revisioning support for single-site content staging
ability to define variants of your configuration (more on this below)
ability to synchronize deployments of configuration and content together
we need a canonical entity format
Being able to work on different variants of configuration for your site was something we talked a lot about. One exemplifying scenario would be an editor on an e-commerce site that, through the UI, prepares new sets of content together with a new variant of configuration (menus, views, landing pages etc) for the launch of a new spring clothes collection. Currently in CMI there's no API support for this, not even support for different variations between staging and production. It's for now recommended that you solve this on a VCS level with different branches of your code. I talked to Greg Dunlap, the initiative lead, about this and he said it has been discussed. But providing API support for this and eventually a UI where you blindly can switch between variants of your configuration is complicated with the risk of mangling your database (switching between different Field API configurations for instance). So we would need to think some more about this and eventually re-visit this discussion.
All in all, there were a lot of good discussions and ideas flying around. The next step will be to formalize a more concrete plan and start work on things we need to improve for better content staging in Drupal 8. Work is already being done in a lot of areas that help improve the situation, but there's more work to do. More about this in the next blog post ;)
The lack of a robust content staging solution in Drupal has been long standing. In this post I won't go into details of why this is such a difficult problem to solve. Instead, I'll suggest a plan, to make a plan, to solve it! So, those of you that are interested in tackling a strategically important functionality for Drupal 8, please continue to read.
What's being done right now?
Throughout the last 8-9 months I've been working on a rewritten version of UUID and Deploy for Drupal 7. It's been moving slow for different reasons, one being because we're very few people coding on it. But (dare I say it?) we are close to a release of Deploy!
Acquia started an initiative called Large Scale Drupal (LSD), focusing on identifying, planning and consolidating work on problems for large scale Drupal implementations. Content staging is one focus area, with wireframes and workflow discussions.
For those of you that are interested to work on this topic, here are some events you should participate in during DrupalCon Denver, and some points we need to discuss in order to get out of Denver with a solid plan on how to make content staging work better in Drupal 8!