Agrégateur de flux

A week or so ago, Dries posted this

http://buytaert.net/creating-a-structure-for-drupal-governance

Which links to a number of draft charters for working groups focussed on different facets of the community, the software project, our tools and infrastructure.

Dries wrote

This is a work in progress. Please help shape the future of Drupal.org governance by reviewing and commenting on the following proposals:

• Drupal.org Infrastructure Working Group
• Drupal.org Software Working Group
• Drupal.org Content Working Group
• Technical Working Group
• Community Working Group (Already formalized)

Please take a moment to review Dries post, and each of the draft charters. Please comment, and please help spread the word about this proposal. It's important. :-)

If anyone wants to check out some new Hy stuff, check out the REPL 3.0 at hy.pault.ag

Also, check out the GitHub Repo, and star it, or consider contributing to it.

Hang tight, this is technical — Hopefully you’re a rockn’ Pythonista already. If not, hang on!

Right, so, here’s the Hython we’re working with:

;;;; testing.hy (import-from sunlight openstates) (defn get-legislators [state] "Get some Legislators from a state" (kwapply (.legislators openstates) {"state" state})) (defn print-legislator-count [state] "Print the Legislative count for a state" (print (len (get-legislators state))))

And a Python script to run it:

#!/usr/bin/env python import hy import testing # import pdb; pdb.set_trace() testing.print_legislator_count("ma")

Which outputs (correctly): 198.

Now, let’s try and debug this sucker:

I added import pdb; pdb.set_trace() to the top of the Pythonic script (after the imports), to drop into a pdb shell:

> /home/tag/tmp/invoke.py(8)() -> testing.print_legislator_count("ma") (Pdb)

Here’s where we are:

(Pdb) l 3 import hy 4 import testing 5 6 import pdb; pdb.set_trace() 7 8 -> testing.print_legislator_count("ma") [EOF]

OK. Let’s step into it.

(Pdb) s --Call-- > /home/tag/tmp/testing.hy(12)print_legislator_count() -> (defn print-legislator-count [state]

Whoh! Right! We’ve just invoked Lisp. Let’s step through the Lisp code:

> /home/tag/tmp/testing.hy(14)print_legislator_count() -> (print (len (get-legislators state)))) (Pdb) --Call-- > /home/tag/tmp/testing.hy(7)get_legislators() -> (defn get-legislators [state] (Pdb) > /home/tag/tmp/testing.hy(9)get_legislators()->[ (SNIP) ] -> (kwapply (.legislators openstates) {"state" state})) (Pdb) l 4 (import-from sunlight openstates) 5 6 7 (defn get-legislators [state] 8 "Get some Legislators from a state" 9 -> (kwapply (.legislators openstates) {"state" state})) 10 11 12 (defn print-legislator-count [state] 13 "Print the Legislative count for a state" 14 (print (len (get-legislators state)))) (Pdb)

Rockn’. This worked hilariously well.

-> (kwapply (.legislators openstates) {"state" state})) (Pdb) state 'ma'

Whoh, right there. Look at that! Python’s pdb has access to Hy’s bits! Neat :)

(Pdb) openstates (Pdb) s

And. just to prove it’s actually Python :)

(Pdb) s 198 --Return-- > /home/tag/tmp/testing.hy(14)print_legislator_count()->None -> (print (len (get-legislators state)))) (Pdb) s --Return-- > /home/tag/tmp/invoke.py(8)()->None -> testing.print_legislator_count("ma")

Whoo! From Python to Lisp and back!

Now, for fun, here’s some pudb action:

And, now, some bpython voodoo:

Hopefully this is the start of something wicked neat! :)

Components in a system

But what we are discovering is that if we see ourselves as components in a system,

that it is very difficult to change the world.

It is a very good way of organising things, even rebellions,

but it offers no ideas about what comes next.

(from All Watched Over By Machines of Loving Grace)

In this episode we add runtime error recovery to our calculator (and fix a teeny bug we introduced last time – did you spot it?).

I recently wrote about setting up Jenkins. My next step was making it do something useful to help our team become more efficient. In most any team it's likely that you'll get some folks for whom "just use drush sql-sync" is not a reasonble solution.

My goal: get a database backup into dropbox on a regular basis and make sure no sensitive customer data is in that backup.

Make a Database backup of the live site

We're running jenkins on a non-production server (for a variety of reasons). So, we get a backup of the live database into a temporary scratch database using the drush aliases feature. That process sanitizes it a bit using the sql-sanitize feature of drush. Then we dump out that database.

1. Start with an up to date checkout of your live site's Drupal code
2. Use the multisite feature and create a sites/example.prod/settings.php where the $databases array has a set of read-only credentials to the production database
3. A second "site" at sites/example.scratch/settings.php
4. Setup a Drush alias that points to those two sites inside the Drupal - be sure to use the 'uri' element so that drush knows which set of credentials to use inside the sites/ folder:
   
   $aliases['example.prod'] = array(
   'root' => '/var/lib/jenkins/example_scripts/example_com_checkout_for_drush/',
   'uri' => 'example.backup',
   );
   $aliases['example.scratch'] = array(
   'root' => '/var/lib/jenkins/example_scripts/example_com_checkout_for_drush/',
   'uri' => 'example.scratch',
   );
   
5. The example.scratch credentials should point to a "scratch" database that is used just for these purposes.
6. Finally a line in the Jenkins job to copy the database from the live site to the backup.
   drush sql-sync @sitename.prod @sitename.backup
7. Run the "drush sql-sanitize" command on it to get drush's default sanitization. If you have the paranoia module installed it will do a few extra sanitization steps. For more on some ways to sanitize a Drupal database checkout this Drupal Scout article.
8. Bonus points: Write your own sitename_drush_sql_sync_sanitize hook just like the paranoia module does - you can clear out data that is important to your site
9. Once that's done, you export the sanitized database:
   drush sql-dump > sitename.prod_sanitized_backup.sql

Send the result to Dropbox

There's Dropbox page for Linux that even has command line instructions. If you're not sure if you need 64 or 32 bit do a "uname -a" on your server. x86_64 is 64 bit.

I also downloaded their dropbox.py script to manage dropbox. I wanted the script to work regardless of whether the dropbox daemon has properly restarted (it feels like a likely point of failure). So, we have a Dropbox account that is connected just to the server and frequently our jobs will have a last step of moving their contents to ~/Dropbox/something and then they kick off the command ~/bin/dropbox.py start

To be honest, the Dropbox CLI mode has been a real pain. Some random TIF files don't synch to the server.

Bits and bobs

For us, this script runs every morning. After a few minutes Dropbox has synched it to all their machines and they can easily import it to a local environment using drush, mysql command line, PHPMyAdmin, or whatever their favorite tool is.

It does a few extra things:

• It bzips the output before putting it in Dropbox.
• It does an "rm -f *.sql; rm -f *.bz2" at the beginning and end to remove any leftover cruft.
• A downstream project uses the output of this step to rebuild a test site where we get the latest code from the testing branch, the latest prod database and people can test it out without having to have a local Drupal installation.

Related: Jenkins is CARD.com open source project spotlight article.

Thanks to c4rl for his help editing.

Over the past few years, we were called in to assist clients with poor performance of their site. Many of these were using Pressflow, because it is "faster" and "more scalable" than Drupal 6.x. However, some of these clients hurt their site's performance by using Pressflow, rather than plain Drupal, often because they misconfigured or misused it in some way or another. Setting cache to "external" without having a caching reverse proxy

read more

You might remember that a while ago I mentioned I got involved in skepticism to the point I even co-host a podcast, Skeptics in Romania (in Romanian).

Among the subjects we tackle there are claims about various miracle fruits, shady dietary advice, various nonscientific health products, and even scams. We try to inform or listeners about ways to identify themselves such dangerous/fake products and how they can inform themselves about the claims they might encounter, what questions they should ask before considering buying (into) such things.

One sensitive subject is the so called multilevel marketing, especially for people involved in such businesses.

This is a sensitive subject because many of these schemes are actually pyramidal schemes, also known as Ponzi schemes. These are illegal in many countries, since they are, in fact scams designed to lure people with supposed high profits and little work.

One such pyramidal system... well you can judge yourselves (note that the presentation contains many slides, but it's really captivating):
http%3A%2F%2Fwww.businessinsider.com%2Fbill-ackmans-herbalife-presentation-2012-12%3Fop%3D1&h=QAQGttTwK&s=1

Happily, I spent Saturday at Brant Wynn's sprint in Chicago, Illinois, USA. And I got to see ZenDoodles there. Thanks Brant and Michelle!

Morning in Oak Park

On Sunday, March 10, 2013, a few of the same people that were at Promet came a little ways out of the city to Oak Park. In Oak Park, there is no tech business to sprint at (that I know of), and the Libraries are not open at the bright early hour of 9:00 am. So we rented the yoga studio attached to a Natural Health clinic. They provided a couple tables, folding chairs and wireless. I was worried about there being enough tables, so I brought 4 little folding tables. I also brought some cookies, and a few outlet strip extension cords. What else does one need?

We had some experienced drupalers, an initiative lead, and a few new people. 12 people in total, and ranging in age from 10 years old to 60. Some people from right in Oak Park, some from the Chicago, one from the Fox Valley Drupal group, and one from Milwaukee. It was a very mixed and friendly group. I handed out issues, but so did others. I helped people set up their environments, but so did others. Thanks Larry and David! Even one of the young ones helped someone else when they ran into a similar problem they had seen already that day. We worked on general issues, Twig, WSCCI, D8MI and ... Will was cranking away most of the day working on something. About half way through the day we had more people join us.

Lunch

Lunch was sponsored by comm-press. Thanks! The fuel was much appreciated.

We had someone post their first screenshots of before and after a patch on a Drupal.org issue. We had another new person post their first patch.

After the Sprint

Weiterlesen

 

I've been a little reluctant to go to camps if I'm being honest. They always gave off a "coders only!" kind of vibe, and not being a codemonkey myself, I was afraid of feeling useless or left out. This year I was lucky enough not only to attend this event, but to speak at it (I'd like to give very big thank you to the sponsors of Drupalcamp Stockholm and to Commerce Guys for making my trip to Stockholm possible!).

This camp was in a word: Awesome. They sold out, and for good reason! Here are my top 5 reasons for why this camp really rocked it: 

1) The sessions weren't just about coding 

It's hard to strike the right balance at a camp. Many of the attendees are looking for technical content, but that's not all they need to become well-rounded and successful site producers. This camp's organizers clearly value more than just development, and there were many sessions to accommodate the "rest" of us. Sessions about theming, migration, buying/selling Drupal and project management responded to the many facets of this vast community's needs!

2) They focused on community building 

These camps are great community builders in general and from the very start with the keynote, this camp really set the tone: community is key! The session "It's not their drupal, it's our drupal" really hit the nail on the head: "we", the community, own this product! It's up to us to make it great. And it wasn't all talk either, Wunderkraut provided a great space for sprinting the next day, and this supported the whole camp's desire to give back with a way to do it :) Way to walk the walk!

3) They recognized our competition 

Drupal is not the only CMS out there, and as a group we need to learn to get outside of our bubble! This camp provided a way to foster that conversation and keep the community looking to its competitors to compare and contrast our own solutions. I was glad to hear this discussion happening because we can learn things from taking a closer look at wordpress, typo3, and proprietary solutions. Too often we are happy to talk about the joys of Drupal, why our platform is the greatest and why we'll remain so. I for one, am really pleased to see us expanding our vision to what could be, and not just what is.

4) They talked about the future

The camp provided a platform to discuss Drupal 8 and what it means during the panel session. The audience provided a lot of questions to feed this conversation like, "is it going to be hard to learn?" and "what makes this version different?" -- important questions to answer and discuss from the perspectives of site builders, front-enders, coders, etc. We need to prepare for the next version, and find ways to learn more/better/faster if we are to keep growing this community and improving our toolset.

5) Great organizers & organization

From the venue, to content, to food, to, eh-hem *KITTEN KILLERS CONCERT*… this day was fantastically organized! The location was practical, the food was delicious and easily accessible (no 2hr lines here!). The content was varied and valuable, and speakers were full of passion. They opted for better food instead of paying for beer, which I think was a smart move because a) not everyone drinks!, b) everyone eats and c) beers are cheap, we can buy our own. The Kitten Killers really brought down the house and gave our after party a very fun vibe in a modern/comfortable venue. Also +1 to having english content so that the audience could be opened up to neighboring countries! Bravo!

Not only was this a great event for learning, but also for networking. Many of the top shops and minds were in attendance, and I really enjoyed talking with, and learning from you all. I heard from many first-timers that it was well worth the trip and that they would be back next year, and I have to say that I'd love to join them!

 

 

 

Tags: Drupalcampstockholm2013communityPlanet Drupal

Daniel bought a Trunk Tees "Happiness is a depilated yak" hoodie. See the picture! (Won't embed it, since it's on Google Plush, sorry.)

15 Professional Trainings led by world class Drupal Trainers

DrupalCon Portland will offer professional full-day training on Monday, May 20 to anyone interested in gaining hands-on knowledge on a variety of hot Drupal topics. Trainings are $440 unless otherwise stated. We recommend registering as soon as possible since trainings tend to sell out.

This is a call to gather information about Sprint Weekend which was March 9 and 10, 2013. Note with a global event, that makes it hard to figure out when exactly it might have begun and finished. This is also some preliminary wild guesses about some stats regarding issues worked on, commits, projects ported to Drupal 8. A follow-up post will come in a couple weeks that will be more organized.

Warning, I still find timezones confusing, so let me know where I got this wrong!

Local sprint data Attendance

I had 12 people at my local sprint in Oak Park, Illinois, USA, on Saturday. Other sprint organizers, please add data about how many people were at your sprint to this google spreadsheet. I'll compile information when it comes in and report back.

Write ups

Write up your experience attending or organizing a local sprint for Sprint Weekend. So others find your thoughts, do any of these:

• tweet out a link and add #SprintWeekend,
• ping me,
• (organizers) add a link to your row in the google spreadsheet,
• (organizers) add a link to your item in the g.d.o Sprint Weekend post.

Me (and others) want to know: how was it? what worked? what support did you get? what was challenging? what would you do differently next time?

Other interesting questions about the effect of Sprint Weekend

I'm going to try and write some queries for Drupal.org and then give them to someone who has access to run them on the real d.o. Here are some ideas, in words about what might be interesting data.

Number of Issues touched for Sprint Weekend

Wild guess: 550 Issues touched. I used just an advanced search for core issues, sorted by last updated. I did it early on Monday, took into account that Sydney started before my timezone, and some sprints went longer than my time. There are 50 issues per page, and I figured there were about 11 pages of issues for that time period.

Better data: A query on d.o will be more accurate. Let's see, Sydney Saturday March 9 10:00 which is Friday March 8 23:00 UTC, and the latest one on Sunday was probably California Sunday March 10 19:00 PST which is Monday March 11 02:00 UTC.

Number of Issues touched for the two weekends before

That number might be impressive, but maybe it's the same as a usual weekend. Comparing to other weekends, over the same (UTC) time span, will be good.

Issues tagged with #SprintWeekend

@DamienMcKenna counted 35 Needs Work, 33 Needs Review, 14 RTBC, 19 Fixed. 124 total issues tagged with #SprintWeekend.

I might hazard a guess that this indicates that we might find that Sprint Weekend increased the number of issues above a normal weekend by about 100.

New d.o accounts

We can compare the number of new Drupal.org accounts over time around Sprint Weekend. A graph of this would be a cool thing to see, maybe annotated with big events like cons, releases, etc. to see what effects that. It might be an indication of the number of new people getting interested/involved with Drupal.

Projects (Themes and Modules) ported to Drupal 8

http://drupal.org/project/modules/?f[0]=drupal_core%3A7234&f[1]=bs_project_sandbox%3A0&solrsort=ds_project_latest_release%20desc is not quite getting me a list of the 8.x dev releases that had some commits to them. I'll have to play with that some more.

@patrickd_drupal worked on FAQ Field. The commits page for that shows a commit on March 10th.

How can I find out what contrib projects had commits during Sprint Weekend? Hmm.

Core Commits

Weiterlesen

If you’ve stumbled upon this blog, you probably already know the basics about Drupal. The sales pitch I usually hear starts with: it’s a powerful CMS, free, open source, and has a great community of developers powering it. Those statements are all true, but I like to believe that Drupal is much more than that. So I started researching, interviewing the team here at Mediacurrent, and came up with this list of 15 cool things you (probably) don’t know about Drupal - especially if you're new to the community. 

We've posted an overview of where the SCOTCH initiative is at, and our plans for the remainder of the Drupal 8 cycle. Initially it was posted here, but that's not policy, so we've moved it out of this group.

*Sorry, but this will require using the command line.

I think at this point it is pretty obvious that I prefer a GUI over the terminal any chance I can get. That is why CodeKit and I were made for each other. I have just recently jumped on the Sass bandwagon/trend and am trying to learn all the tools that go with it. So of course when I found Sass, I also found Compass. The last thing I wanted to do was install these via the terminal. I use a Mac, and while I saw that it was very minimal to do this with the command line and Ruby gems, simple it may be, it was still against my principals none the less. This is where CodeKit came into play. Woot! I now easily had Sass, Compass, and a watched project, all using my best friend — the mouse.

read more

Some Debian/Ubuntu folks had participated to Open Source Conference 2013 Tokushima, in 徳島 (Tokushima), which is in Shihikoku (smallest of the four main islands of Japan).
(Oh, there's Matz. Can you find it? :)





I have not been there but I hope they had a good time...

I hereby pledge, that for every mail I send into a thread on the private Debian list with more than 10 mails, I will fix a release critical bug in a foreign package.

Recently, I've learned about git remote helpers feature in Git, which allows to transparently use Git with other version control systems. As Weblate currently supports only Git, it was quite obvious to give this approach a try.

After some testing, it actually worked just fine - everything works as expected and you can use Weblate with Mercurial or Bazaar with these helpers. Of course there might be some rough edges, but all standard things I've tried worked just fine.

This is now also covered in Weblate's FAQ, which includes basic instructions on how to setup this.

Filed under: English Weblatee | 0 comments | Flattr this!

I had the privilege of attending DrupalCamp London on the weekend of March 2nd and 3rd. I wasn't really sure what to expect but was hoping it would be like a mini DrupalCon. I was not disappointed one little bit. It was very well organised, the talks and BoFs were fantasic and there was a great atmosphere. The best bit for me was that it was more intimate than a DrupalCon and I found it easier to get chatting to a variety of people.

Saturday sessions I attended: Keynote: David Axmark, MySQL co-founder

An entertaining walk through of the history of MySQL. Even though MySQL has always been open source, they set out to make money from it from day one. This was a fascinating insight into combing open source with commercial reality.

Drush Make Driven Development - Steven Jones

I've been using Drush Make for a while, but it was good to get an overview and pick up some new tips. If you don't use drush make, it allows you to define the modules and patches you want in a make file and running a command to build a site. You do not need to store contributed Drupal code in your source control, which saves duplication.

My Vagrant Love Story - Joe Baker

A light hearted and hilarious talk on why Joe fell in love with Vagrant. Joe gave a great overview of Vagrant and walked through the setup of a simple Vagrant box. If you are not using Vagrant, it is a tool for development environments that are configurable and portable. One of the main benefits is that every person in your team uses the same Vagrant box and therefore has the same dev environment. No more "it works on my machine".

Wake up and smell the CoffeeScript - Rob Knight

I decided to attend this talk because CoffeeScript is something that I have no experience with but am very interested in so would learn a thing or two from this talk. Rob presented a great overview of CoffeeScript and I can certainly see why it is becoming as popular as it is. The syntax looks delicious in comparison to Javascript. I'm definitely going to give it a try soon.

Manage your assets with the Scald Module - Sylvain Moreau and Olivier Friesse

The Scald module is an asset management system for Drupal. It is similar to the Media module but has some differences. One difference is that it can store tweets and Facebook status updates as assets. The interface for the Drupal 7 version looks great and looks like the sort of thing my clients would love.

Make your cheap VM fly - Greg Harvey

Greg took us through the VM optimisation techniques Code Enigma use. Greg is a fabulous presenter and made it all look very interesting. The main take aways are:

• Use Percona as it is faster than MySQL and more stable than Maria DB
• Use Ngnix as it is faster than Apache and has no .htaccess file (Apache has to read .htaccess for each page load)
• Only use Varnish if you have over 4GB of RAM, otherwise you will do more harm than good
• Use APC - its a no brainer
• Use New Relic or Tracelytics

Fun with Form API - Joe Schindelar

Joe took us through the basics of the Form API and why it is so incredible. I didn't learn anything new here, but wasn't expecting to. However, I did thoroughly enjoy Joe's talk. I have seen him present on Drupalize.me and he is always top class.

Drupal 8 UI changes - Lewis Nyman

Another one of the days entertaining talks. Lewis kept the crowd happy and laughing with his witty talk. He presented the modules that are in and out of core for Drupal 8 and many of the UI changes.

Sunday sessions I attended: Keynote: Step 4: Distributions could help, if we do them right - Robert Douglass

Robert's keynote was all about distributions, why companies build them. He read through one of Dries' blog posts from the days of Drupal 5. Yup, we have had distributions since Drupal 5. They are a powerful feature, but only now is the Drupal world starting to really unleash their force. There are some high profile distributions available, such as Commerce Kickstart, OpenPublish, Open Atrium, Drupal Rooms etc. I have just finished a project with Dennis Publishing, who use a private distribution to run their many Drupal websites.

He moved on to the somewhat controversial topic of an App Store. He started off comparing the elegance of Google+ and Facebook when it comes to handling images to Drupal. Robert explained that we used to have a generic image module that did most things out of box but now we have abstracted everything. It now takes nine steps to build a image gallery and there are many different ways of doing it. That is great for clients who employ site builders to build some specific. Not so great for someone who just wants a working image gallery. You COULD make it as awesome, but it would require a lot of work. The point here is that Drupal provides toolkits, not finished products. This is where distros and apps can help.

The idea with the App Store being that if a customer is using a distribution, they could visit the AppStore and buy an app which is a finished product of some sort. For example, a fully working, one click install, no configuration required image gallery.

Robert contrasted that to Wordpress where you can buy a fully working, great looking, one click install image gallery plugin for $20 which includes commercial support. Robert showed a slide with how much money a single image slider plugin had generated. Robert then made the point, we are all in this to make money. Passion goes a long way, monetary incentive can go further.

This lead on to a BoF, which I attended (notes at the end).

zip-BDD-do-dah zip-BDD-ay! - Andrew Larcombe and Graham Taylor

Andrew started off with an overview of what BDD is and why you would want to use it. Graham then took us through a demonstration of Behat and it explained it very clearly. I have already used Behat, but still found the overview very useful. Capgemini have Behat integrated with both Jira and Sourcelabs. With the Jira integration, the business can add the test to a Jira ticket, and it will run the test without the test code being committed. With Sourcelabs, a secure tunnel is created between your local machine and Sourcelabs and the test is run. Sourcelabs records the test and you can watch a video of it going through the browser. It will take snap shots along the way, so you can see exactly where the test fails. Great stuff!

Architecting Drupal Modules - An agile guide to choosing the right architecture for your module - Ronald Ashri

Ronald took us through how you should architect modules from an agile point of view. It is about using principles, guidelines and patterns to define your architecture, not recipes. The main point is, don't think about the Drupal way of solving a problem initially. Instead, use solid OOP principles and then apply them to Drupal.

Ronald has written a blog post covering much of this on, you should check it out.

App Store BoF

There was a BoF on Sunday afternoon to follow up to Robert's keynote. The start of the discussion was centred around how we can build a common App Store with a consistent user experience. When installing a Drupal distribution (or even a standard Drupal install), a customer would shop for "apps" to install. These apps would work out of the box with no need to time consuming configuration. App developers could commit to a central repository.

There was discussion around the fact that Drupal provides toolkits to build web sites and applications. It does not provide a finished product by itself. Modules are built by developers for developers and site builders with an awesome level of collaboration. An app will not change that, but will instead offer finished solutions to non-technical (or low technical) customers.

Robert talked about Wordpress a lot, which has some commercial plugins. These plugins offer finished product to non-technical end users. Robert made the point that there are software vendors who sell their software to markets such as Wordpress and Joomla, but will not touch Drupal as it stands because of the lack of a marketplace to sell them.

One of the main benefits of distributions and apps make it easier for all of us to sell fully working products to end customers. It was mentioned that this is where the mind shift is because it is about much more than making Drupal by developers for developers. Ronald Ashri talked about making a distribution for tours to sell to travel agents as the next step from Drupal Rooms. Robert pointed out that this is the key difference - Ronald is talking about an entirely different audience to site builders. His audience would be travel agents. And this is where there is a massive opportunity to expand Drupal's market share.

We did talk about technical issues and there are many. If you look at Features as a method for exporting configuration and creating "Apps", we currently get conflicts between Features. These need to be resolved on a case by case basis by an experienced Drupal site builder or developer. For this to be a true app model, they need to work out of the box without conflicts. In the end, the group decided not to focus not this yet as it is viewed as a technical issue that can be resolved. More important is ensure that the community does not get split over the concept of paid for apps.

On the topic of compatibility of Features, since the BoF Alan MacKenzie pointed out Kit. According to the project page, Kit is a specification, it is a set of guidelines that facilitates building compatible and interoperable Features. This could go along way to helping the community create fully working one click install apps.

If you would like more information, see Drupal App Store BoF on the Open App Standard group. I'm sure there will be a lot more debate within the Drupal community about this.

Socialising

What Drupal event would be complete without a healthy dose of socialising? After all, Come for the software, stay for the community. From the official party in the The Slaughtered Lamb to chatting in the corridors, I had great fun with old and new faces.

Thanks to the volunteers

Massive thanks to all the volunteers who spent a lot of their own time making this event happen for all of us. Everything ran smoothly and without a hitch. It was a great weekend of camping with Drupal without the need for tents!

Tags: Drupal EventsPlanet Drupal

The standard multiple select list can be difficult to use, if your users are not very technical. Most of the time they won't know that you have to hold down command or ctrl key if you want to select multiple options. Also, once you have more than 10 options, the select list becomes very difficult to use. One wrong move and you can loose all the selected options.

The Multiselect module defines a widget that allows users to move selected items from one box to another. Visually this helps users to see which items have been selected. The widget can be used on a bunch of field types and it can be implemented as a form element using FAPI.