Elsewhere

Quick tip: Use bash aliases to easily run multiple versions of drush at onceSunday, 12th May 2013

There are times where it can be desirable to run two or more different versions of drush on one computer, or even multiple versions for one user.

For example, if you're using a server running the 1.x (stable) branch of Aegir and you attempt to upgrade from drush 4 to 5 globally all of your provision tasks will start failing, rendering Aegir completely useless.

The "real" solution is to upgrade Aegir to the 2.x branch but if you're looking for a quick fix it's easier to just install drush 5 in parallel with drush 4 for your user.

Steps to install drush 5 in parallel with drush 4:

This assumes you already have drush 4 installed, so that running $ drush status will report version 4.x

1. Download the latest version of drush 5 from the project page.
2. Extract the contents of the drush tarball into your home directory in a folder called drush5, so that the drush files can be found at ~/drush5.
3. Edit or create either ~/.bashrc or ~/.bash_profile and add the following line: alias drush5='~/drush5/drush'.
4. Reload your terminal/console or run $ source ~/.bashrc or $ source ~/.bash_profile as appropriate (whichever file you edited).

That's it! if you run $ drush5 status you should see a drush report a version number 5.x

You can now swap between drush 4 and 5 easily whenever you need to.

These steps can be adapted to do the same thing in reverse and have drush 5 run with the drush command and drush 4 with drush4, or you could even have each version explicitly mapped to drush4 and drush5 - it's up to you :)

Syndicate: planet drupal

Knowledge Language English My Mentor/D8MI Drupalcon Portland ScheduleCathy Theys05/12/2013 - 08:28

This is a wishful schedule. Some things I'm committed to be at. Some I'm wishing I will to have time to go to.

Note, the google core mentoring calendar will make it easy to add some of these to your calendar. Core mentoring calendar: 7ss54o2foktlc8b75d1gest4do@group.calendar.google.com

It's a mix of what I'm into: my sessions, mentoring and multilingual.

Tuesday

• 9:00am Programming Diversity by Ashe Dryden
• 10:15am Making core development sustainable by Greg Dunlap
• 11:30am The Current State of Drupal 8 Keynote by Dries (is what I would go to if I were not staffing the Community booth at that time.)
• 2:30pm I'm going to be trying to be calm right before my session. But if not, I'd pick: Dependency Injection in Drupal 8 by Katherine Bailey
• 3:15pm I'll be at my session! Running coaches wanted! Contribution sprints and trainings by Jess, Andrea, Addi and me
• 4:30pm I'll be in a BoF with mentors doing task selection for the Friday sprint, but if I were not, I'd be in UX Case: Love and Hate in The Issue Queue Garden by Michael Keara, Thomas Svenson
• 5:30pm Exhibit Hall for Drupalcon Kick Off Reception
• 6:00pm or so Women in Drupal Meet and Greet

Then on Weds...

In January, I announced a new IRC channel #debian-lego, for those of us in the Debian and Linux community interested in LEGO, the marvellous construction system from Denmark. We also created a wiki page to have a place to take notes and write down our plans and hopes. And several people showed up to help. I was very happy to see the effect of my call. Since the small start, we have a debtags tag hardware::hobby:lego tag for LEGO related packages, and now count 10 packages related to LEGO and Mindstorms:

brickosalternative OS for LEGO Mindstorms RCX. Supports development in C/C++ leocadvirtual brick CAD software libnxtutility library for talking to the LEGO Mindstorms NX lnpddaemon for LNP communication with BrickOS nbccompiler for LEGO Mindstorms NXT bricks nqcNot Quite C compiler for LEGO Mindstorms RCX python-nxtpython driver/interface/wrapper for the Lego Mindstorms NXT robot python-nxt-filersimple GUI to manage files on a LEGO Mindstorms NXT scratcheasy to use programming environment for ages 8 and up t2nsimple command-line tool for Lego NXT

Some of these are available in Wheezy, and all but one are currently available in Jessie/testing. leocad is so far only available in experimental.

If you care about LEGO in Debian, please join us on IRC and help adding the rest of the great free software tools available on Linux for LEGO designers.

We're not talking about Darwin, but about the fact that a website project - even after delivery - will often stay in a state of evolution before becoming ‘stable’. The evolution itself isn’t the problem. Responding to that evolution is often what causes operational headaches. This article will not deal with the technical complexities of the Drupal development lifecycle, the CMI in Drupal 8 should solve that. Here we delve into the operational issues of website evolution.

Some definitionsAbout a decade ago, websites were constructed by ordinary people promoted from among their peers to the role of webmaster. Because websites weren’t used as the powerful marketing tools they are today, many websites remained under construction for a long time. Sometimes forever. Nowadays, websites can be under construction for a long time as well, but the construction phase is more accurately name; used by website engineers as they actually construct the website. Once the website is completed and delivered, it enters the maintenance phase. The actual go-live might happen overnight, but there’s often a fairly long time before development stops. The time between construction and maintenance is what’s called the evolution phase.  for ITIL lovers Within Application Maintenance Services our focus in this article is on Application (Drupal) Support.   Within Application Maintenance we can identify 4 types of Support. Corrective Support (eg. download link does not work), Adaptive Support (eg. make whole website work for new version of Internet Explorer),  Preventive Support (eg. perform security updates) and Perfective Support (eg. Add a carrousel to the new campaign page).     We rather use the term “Evolution” to denote the combination of Perfective and Preventive Support since it better fits the notion that we are talking about, more than ‘support’. ConstructionThe construction phase for websites is that period between having a neat idea, and bringing the resulting idea into production. The most important part of that phase is the concepting phase, while the largest part of that phase is the actual development project. The business model for development projects is fairly straightforward: sell as many development projects as there is capacity while keeping planning and efficiency (i.e. working billable hours at least 80% of the time). To fill the gaps between projects, you can take on smaller projects. The less downtime you have in your work schedule, the better. The resulting website will consist of everything that the client wants to start from. MaintenanceConstruction processes can be standardized to some extent, but it’s impossible to predict fallouts and failures, once software is running stably. The main problem of these fallouts is not the failure itself, it’s making sure you have resources available to fix the problem. So suppliers of modern-day equipment and services need to make sure they have enough permanent resources to address issues as they arise, in order to comply with their Service Level Agreements (SLA). Typically there are peaks moments and there are moments when everything is running smoothly. Only proactive maintenance tasks (e.g. upgrades, increasing memory) become plannable. But for this to be worthwhile, you need enough clients and enough resources to come up with usable heuristics. Once you have proper statistics, the maintenance business model becomes scalable, because it’s not people but statistics that are sold. In fact, resources can be sold multiple times when you’re dealing with small, unpredictable chunks of work. The resulting website will become  stronger and more stable by performing these maintenance tasks. EvolutionThe business model of maintenance is clear (enough resources + enough clients = scalable workflow), but starts to degrade as soon as these chunks of work become too big. This is what happens when the website is in evolution. During that evolution phase, the client will make feature requests that the development team needs to handle. But due to the nature of the request, the client will be unsatisfied if that request is handled as a project (ie. planned to happen in 5 weeks).  The resulting website will consist of improvements to adapt to changing business requirements, staying up to date with the newest technologies (e.g responsive design) or being ready for new marketing campaigns. What is the problem?If the evolution were handled as construction, clients would have to wait too long for small changes.If, on the other hand, it were handled as maintenance, the support team would lack experience  to complete all the engineering going on. Even if they did have the skills to handle those medium-sized chunks of work, accepting these requests would break the statistics of the business model. This could jeopardize the correct reaction time on more critical requests. What we are hearing from prospects and clients working with Drupal websites at the moment does indeed comply with our findings. We hear remarks like, “Yes, we have a support contract, our supplier reacts quickly and communicates well, but the quality of the fix is low or feature A gets implemented, while another existing feature B breaks down.” Or we hear, “Yes, we have a support contract, and the supplier delivers correct solution. They even bundled multiple requests into one release, but it takes weeks, sometimes months to get a small thing changed.”  Possible solutionsThere’s a list of possible ways to be able to deal with these situations, and the Wunderkraut support model currently handles all of them.  Fixed SupportReserve a few people from the development team for a number of days a week/month for a certain period of time, e.g. every Friday for six months, two developers will be available to react to client requests in the issue queue. The following problems arise with this solution:

• It’s very hard to predict how many resources will be needed and for how long, which will result in either too many or too few blocked resources.
• If these developers are unable to get a feature totally released on that Friday, they need to continue working on it, the next week - i.e. it is still slow.
• If the client does NOT have any requests, they will still be paying (maybe partially) for that unused time, and some clients don’t like that.

 Lower the billabiltyAnother option would be to decrease the billabilty of one or more dev-teams, e.g. only the dev-team is directly billable on projects for 60% of the time, so has extra room to handle these small chunks of works. But the problem here is pretty clear: the risk  is completely moved to the supplier. If in one month, none of the clients requests smaller work, the supplier has no income. This is in general not a good business model. On the other hand, this solution does not scale. If the supplier freed up some resources for each of his clients, the dev-team would just be ‘waiting’ for new features to come in, instead of working on new projects. Wunderkraut Evolution model (beta)We’ve finally managed to devise a model that combines the agility of the two weekly sprints of Scrum, with some warranties on reaction time for certain requests. We won't go into the details of the model, but the general idea is that we use a mix of fixed support and lower billability to spread the risk evenly between client and supplier, and at the same time allow small chunks of (evolutiove) development work to be added to the sprint backlog of a selected development team.  We are currently test-driving this solution for some clients, and will report back at a later time to talk about the results. Let’s discuss and learnIt may not come as a surprise that both clients and service agencies are dealing with complex issues as a result of this dilemma. In fact both parties are actually losing time and money in their search for the best solution. Therefore we would like to invite CTOs, CMOs and other company decision-makers and influencers to our round table discussion group in Belgium to exchange views on how to best solve this.  In an informal setting, a panel composed of a  Marketing Director (Kinepolis), a Technical Director (Cultuurnet) and a Supplier (Wunderkraut) will touch upon the different  aspects  of  the website evolutionary support.  The discussion will be moderated by Bart Gysens (project medewerker V-ICT-OR). If you are interested in joining this event please send an email to be.info@wunderkraut.com to register. 

Lumail <http://lumail.org> received two patches today, one to build on Debian Unstable, and one to build on OpenBSD.

The documentation of the lua primitives is almost 100% complete, and the repository has now got a public list of issues which I'm slowly working on.

Even though I can't reply to messages I'm cheerfully running it on my mail box as a mail-viewer. Faster than mutt. Oddly enough. Or maybe I'm just biased.

I’ve recently been spending a bit of my spare time playing Ingress (see the Wikipedia page if you haven’t heard of it). A quick summary is that Ingress is an Android phone game that involves geo-location of “portals” that you aim to control and most operations on a portal can only be performed when you are within 40 meters – so you do a lot of travelling to get to portals at various locations. One reasonably common operation that can be performed remotely is recharging a portal by using it’s key, after playing for a while you end up with a collection of keys which can be difficult to manage.

Until recently the set of portal keys was ordered alphabetically. This isn’t particularly useful given the fact that portal names are made up by random people who photograph things that they consider to be landmarks. If people tried to use a consistent geographic naming system (which was short enough to fit in large print on a phone display) then it would be really difficult to make it usable. But as joke names are accepted there’s just no benefit in having a sort by name.

A recent update to the Ingress client (the program which runs on the Android phone and is used for all game operations) changed the sort order to be by distance. This makes it really easy to see the portals which are near you (which is really useful) but also means that the order changes whenever you move – which isn’t such a good idea for use on a mobile phone. It’s quite common for Ingress players to recharge portals while on public transport. But with the new Ingress client the list order will change as you move so anyone who does recharging on a train will find the order of the list changing during the process and it’s really difficult to find items in a list which is in a different order each time you look at it.

This problem of ordering by location has a much greater scope than Ingress. One example is collections of GPS tagged photographs, it wouldn’t make any sense to mix the pictures of two different sets of holiday pictures because they were both taken in countries that are the same distance from my current location (as the current Ingress algorithm would do).

It seems to me that the best way of sorting geo-tagged items (Ingress portals, photos, etc) is to base it on the distance from a fixed point which the user can select. It could default to the user’s current location but in that case the order of the list should remain unchanged at least until the user returns to the main menu and I think it would be ideal for the order to remain unchanged until the user requests it.

I think that most Ingress players would agree with me that fixing annoying mis-features of the Ingress client such as this one would be better for the game than adding new features. While most computer games have some degree of make-work (in almost every case a computer could do things better than a person) I don’t think that finding things in a changing list should be part of the make-work.

Also it would be nice if Google released some code for doing this properly to reduce the incidence of other developers implementing the same mistakes as the Ingress developers in this regard.

Related posts:

1. Ingress Today Google sent me an invite for Ingress – their...
2. Security Lessons from a Ferry On Saturday I traveled from Victoria to Tasmania via the...
3. Cyborgs solving Protein Folding problems Arstechnica has an interesting article about protein folding problems being...

Read more

Automated installation of apachesolr multicore localy will save you valueable time.

How to automatically install apache solr multicore localy for drupalapachesolrsearchautomationSaturday, May 11, 2013 - 14:49

There was an interesting question by ‘Fool’ recently on the StackExchange site for Boardgames: How do you play a game like Rock-Paper-Scissors with friends online? Or any other game where players have to simultaneously submit their moves (e.g. Diplomacy, or Rock-Paper-Scissors-Lizzard-Spock), which, as I just learned, are simultaneous action selection games. While there are websites dedicated to playing specific games, such as webdiplomacy.net, we could not find a generic one that you can use if you, for example, invent your own variants of a game.

So I created one: At you-say-first.nomeata.de you can enter rooms and share the URL with your friends. On the one hand, you have a regular chat room there. But there is also the possibility to enter moves (whatever a move may be to you) and only when all players have done that and marked the move as final, it is shown to everyone. If you want to try it out: There is an integrated, not very fancy Rock-Paper-Scissors-playing bot. Just enter a room, join and say „I want to play!“

Note that this site can be used for more than just for games. Have you ever observed that persons would often want other to express their preference (e.g. where to dine) first to not reveal their own preference, so that they can (or pretend to) change their mind if they would contradict? In such situations simultaneous action selection can be a fairer method.

A technical note: I created this web app using meteor (a JavaScript framework building on node.js and MongoDB that allows for reactive programming), and it is also hosted on meteor.com. I chose Meteor after someone mentioned Firebase to me, which looked very slick, but was not Free Software, so I looked for alternatives. I did not do any cross-browser-testing, and the UI design could be improved, so if you want to help out (or just complain), please use the GitHub code repository and issue tracker.

Last week we released Wheezy, roughly two years after our last release Squeeze.

I’d like to thank all the contributors in- and outside of Debian for your fine work! Every single contribution — no matter how big or small — summed up to the wonderful release we finished last week. Without you this release would not have been possible. Keep up the good work guys and make Jessie rock even harder!

PS: It is very nice to see once again fresh packages rolling into unstable and spending some time fixing broken dependencies

I don't work at Google, so I can play to Google IO prediction game.  Here are my Android predictions:

1. New android version -- 99%
2. New Nexus 7 -- 90%
3. Upgraded storage on the Nexus 4 -- 70%
4. T-mobile LTE for Nexus 4 -- 40%
5. AT&T LTE for Nexus 4 -- 30%
6. Verizon Nexus 4 -- 15%

 So I think that means there is a (0.99 * 0.9 * 0.7 * 0.4 * 0.3 * 0.15) a 1% chance of all of these things happening.

• drupal 7.x
• views
• menu
• planet drupal

This article describes how to place a custom local task menu tab alongside the 'View' and 'Edit' tabs on a content type.

The Drupal.org infrastructure is a great resource for developers: A hub for development, with a combination of version control access, issue tracking, and automated testing.

Of course, it can be improved, and I don’t want to open a can of worms by saying it is perfect (it isn’t).

But I think the community does benefit from an environment that is designed especially for it.

Within this environment, we also have useful tools that help maintain quality in Drupal code.

1. The issue queues and workflow are set up to foster peer review, which (in line with the open source way) gives unlimited human eyes on a problem, rather than being siloed within a commercial organization.
    
2. Contributed projects such as dreditor allow fast, tangible reviews from reading through code, giving a clear comment for others to work from.
    
3. Automated tests mean that once you’ve set up code, you will automatically get the green or red light as to whether a change has unintentionally broken anything.
    
4. The coder module allows automatic reporting of code style, which helps bring the community towards common coding standards and accelerates the speed at which a contributor can become familiar with a new section of code. 

But these checks do add to the hassle of contributing a patch. Not good.

Formalising the process of review

On one of my projects, the Project Management Module, I was weighing up whether I should formalise the review process.

Previously, whilst a lot of the factors mentioned were taken into account (although not coder), it was a little haphazard, and I felt it wasn’t clear enough.

I wanted a contributor to know what the hurdles they were in advance, so that they could write a patch at the outset that solved the issues.

There are typically several patches undergoing review at the same time in the issues queue, so I also wanted to be able to speed up the review process to minimise the need for patch rerolls.

My biggest concern here was that I would alienate contributors to the project. This would not be an acceptable sacrifice, even if it meant that we were upholding the coding standards more precisely, etc.

Contributors come first

You’ll have got the message by now that one of the biggest risks to an Open Source project is (in my opinion) alienating your contributors.

So, whilst I’ve gone ahead and put a bit more structure in how I review patches, my focus has been on keeping the process easy and worthwhile – with a focus on the new element, coder reviews. 

Those regulars in the Project Management Module issue queue will keep me honest in the comments, I’m sure!

Is there a point to code style?

There are massive advantages to uniform code style among a community, but it is an investment made in a patch, with a longer term reward.

I’ve done two things to make coder patch reviews less painful:

1. Show the results: I’ve set up a developers website for the Project Management Module.
   
   You can see it at http://api.project-management-module.org.
   
   The aim here is for developers now to reap the benefits of the documentation that we’re adding to the code.
    
2. Lower the hurdle: I understand that not everyone has a test site running the coder module, and it adds a lot of time if you need to set that up each time.
   
   So I’ve opened up coder on the Project Management Module demo site.
   
   You can see it at http://drupal-7.project-management-module.org/admin/config/development/c....
   
   A check of a patch now takes a few seconds, and can be done before submitting on Drupal.org (in fact, you could use it for your patches too - it isn't module specific).

So far, I’m pleased with the results.

Nobody has complained about additional hurdle of coder reviews, and there have been some very positive comments about having an API site for all to see.

Conclusion

Alienating contributors is a real risk when formalising a process in an Open Source project, but it doesn’t mean that you shouldn’t try it.

Before implementing any change, think about how you will make the change worthwhile from the point of view of other contributors – whether by showing the point of it, reducing the pain, or both.

When have you tried to formalise a process in Open Source?

Has it worked?

What steps did you take to ensure contributors were not alienated? 

As always, I’d welcome your thoughts in the comments.

Category: WebsitesTags: DrupalDrupal PlanetMaintaining an Open Source ModuleOpen SourceCoderPatches

Still not sure what to do with this whole thing, but preserving the sharp increase in RC bug count for posterity can't hurt either way. Not sure if it's sad that so many issues may have been overlooked, if this means that Debian is very much alive, either.

The UDD bugs interface currently knows about the following release critical bugs:

• In Total: 1134
  • Affecting Jessie: 131 That's the number we need to get down to zero before the release. They can be split in two big categories:
    • Affecting Jessie and unstable: 116 Those need someone to find a fix, or to finish the work to upload a fix to unstable:
      • 16 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them.
      • 8 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate!
      • 92 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution!
    • Affecting Jessie only: 15 Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests.
      • 0 bugs are in packages that are unblocked by the release team.
      • 15 bugs are in packages that are not unblocked.

How do we compare to the Squeeze release cycle?

Week Squeeze Wheezy Diff 43 284 (213+71) 468 (332+136) +184 (+119/+65) 44 261 (201+60) 408 (265+143) +147 (+64/+83) 45 261 (205+56) 425 (291+134) +164 (+86/+78) 46 271 (200+71) 401 (258+143) +130 (+58/+72) 47 283 (209+74) 366 (221+145) +83 (+12/+71) 48 256 (177+79) 378 (230+148) +122 (+53/+69) 49 256 (180+76) 360 (216+155) +104 (+36/+79) 50 204 (148+56) 339 (195+144) +135 (+47/+90) 51 178 (124+54) 323 (190+133) +145 (+66/+79) 52 115 (78+37) 289 (190+99) +174 (+112/+62) 1 93 (60+33) 287 (171+116) +194 (+111/+83) 2 82 (46+36) 271 (162+109) +189 (+116/+73) 3 25 (15+10) 249 (165+84) +224 (+150/+74) 4 14 (8+6) 244 (176+68) +230 (+168/+62) 5 2 (0+2) 224 (132+92) +222 (+132/+90) 6 release! 212 (129+83) +212 (+129/+83) 7 release+1 194 (128+66) +194 (+128/+66) 8 release+2 206 (144+62) +206 (+144/+62) 9 release+3 174 (105+69) +174 (+105/+69) 10 release+4 120 (72+48) +120 (+72/+48) 11 release+5 115 (74+41) +115 (+74/+41) 12 release+6 93 (47+46) +93 (+47/+46) 13 release+7 50 (24+26) +50 (+24/+26) 14 release+8 51 (32+19) +51 (+32/+19) 15 release+9 39 (32+7) +39 (+32/+7) 16 release+10 20 (12+8) +20 (+12/+8) 17 release+11 24 (19+5) +24 (+19/+5) 18 release+12 2 (2+0) +2 (+2/+0)

Graphical overview of bug stats thanks to azhag:

What is a million dollar house worth if it has bad wiring? Bad wiring means ripping out the drywall, getting it inspected by the city, and starting from scratch. If you have a builder that would allow something like that, as an owner you have to go from the bottom up and review what else they left lurking in your dream home.

Web application development is no different from a house. Sites require real estate, maintenance, and are living, functioning pieces. They require the occasional remodel to add more features as users needs change.

So why do so many web consultants often act like the McMansion builder of the web? Build it fast, cheap, charge as much as we can and walk out the door? Who do they think they're fooling? Maybe the clients, but will they be repeat clients?

Read more

After adding the new triggers to auto-build wheezy-backports and jessie yesterday, today I cleaned up the remaining bits in wanna-build from lenny: wanna-build=> delete from packages where distribution ~ 'lenny' ; DELETE 8250 wanna-build=> delete from distribution_architectures where distribution ~ 'lenny'; DELETE 63 wanna-build=> delete from locks where distribution ~ 'lenny'; DELETE 63 wanna-build=> delete from pkg_history where distribution ~ 'lenny'; DELETE 16504 wanna-build=> delete from distributions where distribution ~ 'lenny'; DELETE 6 wanna-build=> delete from architectures where architecture in ('alpha', 'arm', 'hppa'); DELETE 3

You are all invited on Monday, May 20th, the first day of DrupalCon Portland, to honor Aaron Winborn's ongoing contributions to the Drupal community and to celebrate Drupal's power to make the world a better place.

I have to admit that I don't exactly know how to write about this event. I don't know Aaron personally. But like most of us, I've been working with his contributed code and following his writings on Drupal for several years. If you follow Aaron's blog, you know that he and his family are struggling with his ALS. You may have seen Aaron's G.D.O. post two weeks back looking for volunteers to help him continue to code in spite of the progression of his illness.

Two things are sure: Aaron loves Drupal, and Aaron loves our community.

One might argue, however, that Aaron's situation points to a challenge in open source software development: Aaron continues to simply give away his code, and in so doing he and his family won't benefit long-term from royalties or productization. In this situation, we have a responsibility, or at least a great opportunity, to show that we in open source take care of our own.

But I'm being melancholy. And based on my correspondence with Aaron about this event, he wouldn't want that. Aaron wishes that he could be at DrupalCon this year. He is excited for us to gather, of course to raise money for his family, but also just to get together and laugh and geek out together.

So on Monday night, the first night of DrupalCon, rather than go pay for beer at some bar, please consider making your way to the EcoTrust building (it's right on the streetcar) for this celebration, and donate that night's beer money to Aaron and his family.

We joke that "open source is free as in beer" - that we have an obligation to give back. Now it's time to prove it:

• Please register for the event at: http://pdxdrupaldogooders.eventbrite.com.
• If you cannot attend, please consider making a donation directly to Aaron's special needs trust.
• And Drupal firms, consider sponsoring the event.

So far, the generous sponsors of this event have raised over $4,000 for Aaron and his family. Let's keep the momentum going and hit the goal of raising $10,000 on this special night.

Tags: Drupal PlanetDrupal Givenonprofit techevents

Here at Advomatic we've experimented with several approaches to responsive design over the past few years. I think the "mobile first" philosophy became popular right in the nick of time. There was a point when we'd detect if the user was on a mobile device and then deliver a separate mobile theme. This meant two instances of a site to develop for and maintain. I can't imagine doing that now, given the amount of device width/height possibilities and device-specific bugs that exist out there. So, now we work on layout with the goal of accommodating the content rather than the device. To accommodate a responsive and flexible layout, it's best to get your site on a grid. There are tons of options out there, but we've found one in particular helps you quickly get rolling and set up with a column layout that can adjust to whatever device you need your site to display on (and is fun to work with, too). Lately, it's been part of our holy trinity for responsive theming: Sass, Compass and Susy.

First things first: ditch pixels

One big first step to responsiveness in your site is to stop using pixel units for measurements. We use em units because they are proportional to any parent measurement, and therefore flexible and responsive. If we have a base font-size set on the body element of 16px, and our #footer is set to 1.6em, that #footer font-size will automatically scale up or down accordingly if the body's (or any parent element to #footer, for that matter) font-size changes.

To manually figure out exactly what em value you should be using for an element, you can use a commonly used formula: target ÷ context = result... or you could do it the easy way with a Sass function:

// Create em() for setting font-sizes in pixels.
@function em($target, $context: $base-font-size) {
   @if $target == 0 { @return 0 }
   @return $target / $context + 0em;
}

// Example usage: font-size: em(21px);
// This will set the font-size to 21px in relation to the browser's base font size if it has not been established in any parent element, or in relation to $base-font-size which is a variable you can set in your Sass.

// Example usage 2: font-size: em(12px, 10px);
// This will set the font-size to 12px in relation to a parent element's font-size of 10px.

Get on the grid

If you're doing front end development these days, you're probably familiar with the concept of grid-based design and translating a comp into a fully fluid or adaptive layout via HTML/CSS. We frequently use Zen 5 as a base theme and have been big fans over the years because it comes loaded with many of the best tools for front end/theme development, while also pretty lean as far as bloat goes. While it's important to be able to build themes for browsers that can handle fancy bells and whistles, we also need to support older browsers that don't. Zen 5 already has Sass and Compass integrated. As far as a grid framework goes, we use Susy instead of Zen Grids... this has just come down to personal preference. Zen Grids is also a great system.

Susy is a responsive grid framework/plugin for Compass, and it allows you to build on top of either a "magic", static or completely fluid grid.

• "Magic" grids are the default - they have an elastic container that responds to font sizes when set with em units, and is fluid on the inside. It's container size gets calculated according to the widths of your columns and gutters.
• Static grids are just that - all containers and column widths are not flexible and this is the traditional grid style. As such, it does not collapse when the viewport is smaller than the grid is wide. Even though you may specify pixel values for the column sizes, Susy converts to a percentage of the container size. The container size, like the magic grid, gets calculated according to the widths of your columns and gutters.
• Fluid grids are truly flexible layouts that respond to the width of the viewport. By default the container width is 100%. However, as with any grid type you choose, you can specify this with the $container-width variable (such as "$container-width: 70%").

Set it all up

To add Susy to your theme, there are a few things you'll need to do.

1. If you haven't already, install Sass and Compass. sudo apt-get install rubygems
   sudo gem update
   sudo gem install sass sudo gem install compass
2. Set up a Compass project in your theme directory.

   This is already done for you with Zen 5. If you're not using Zen 5 or a contrib theme that has this done already (look for a config.rb file in the theme directory), then set up your Compass project by going to your theme directory in your favorite command line interface and run:

   compass create nameofyourtheme

   This will add a "config.rb" file to your theme, and is where the Compass project settings are located.

3. Then, install Susy. sudo gem install susy
4. Require Susy in your Compass project.

   Open up the config.rb file and add the following (wherever "requires" are located):

   require "susy"
5. @include susy and add grid settings to your _base.scss (or equivalent "global" Sass file).

   We usually stick any of our grid settings in the _base.scss file that comes with Zen so that the grid variables set there are available to any other Sass stylesheet in the theme (because Zen's base gets @imported in them all). You'll also want to place them in whatever Sass file you're using that gets imported into any file where you'll be doing responsive styling/layout. For example:

   @import "susy";
   $total-columns: 12;             // a 12-column grid
   $column-width: 4em;            // each column is 4em wide
   $gutter-width: 1em;            // 1em gutters between columns
   $grid-padding: $gutter-width;  // grid-padding equal to gutters

After installing Susy, and getting your Compass project set up properly for the theme, you'll want to tweak those default grid settings that you just added (total columns, column width, grid padding, etc...) for the purpose of your own design. Using those settings, Susy will automatically figure out the math and put percentage widths on internal grid elements, as well as a max-width on the container (should you use a non-fluid grid). By default, all Susy grids are "magic." If you want to use one of the other types of grids, you would do that by setting the $container-style variable. For example, to build a 5 column-wide mobile first "magic" layout, we can do something like this:

$total-columns: 5;
$column-width: 3em;
$gutter-width: .75em;
$grid-padding: $gutter-width; Making things happen at different viewport sizes

Another handy part of Susy is its at-breakpoint() mixin. This can be used in replacement of a long and drawn out media query that targets specific pixel-based min-width or max-width values of the viewport. Something we do frequently for adaptive/responsive layouts (where there are established, comp-determined breakpoints for mobile, tablet, desktop), is set variables for different numbers of grid columns.

$mobile   : 5;
$tablet   : 11;
$desktop  : 16;

So if you're building in a mobile first manner like this, and you want something to happen at a certain breakpoint in your Sass, you can use at-breakpoint() with your column count variables as an argument.

#content {
  @include span-columns(5);
  @include at-breakpoint($desktop) {
    @include span-columns(13, $desktop);
    @include prefix(3, $desktop);
  }
}

In this situation, #content normally spans 5 columns wide, which is the default/mobile width of the grid in this example. When the viewport is at the desktop breakpoint (16 columns can fit in the viewport), the width of #content will change. span-columns(13, $desktop) means "make this 13 columns wide, out of 16 total columns". prefix(3, $desktop) means "add 3 columns of empty space beforehand." So #content becomes 16 columns wide in total, however only 13 columns of space are usable and contain content, since we added 3 columns of padding to the start.

A different, non-layout related way of using at-breakpoint() is to maybe change some kind of style at a given breakpoint.

padding-bottom: em(15px);
@include at-breakpoint($desktop) {
  padding-bottom: em(85px);
  background: url("bg-content.png") 162px 100% no-repeat;
}

Having at-breakpoint() at the ready is a great way of releasing yourself of the mindset and clutter of maintaining several pixel-based breakpoints in your site, and helps future-proof things since device sizes are fluctuating so wildly as time goes on. Since Sass supports code nesting, it has become standard operating procedure for us to use at-breakpoint() at the end of things in a selector's nested styles, so that they override any established defaults (which are usually the mobile version styles if we are building mobile-first).

Alternatively, Aurora

While we normally use Zen and add Susy in manually (replacing Zen Grids), some themes have Susy, Sass and Compass (and other front end goodies) baked in already. Aurora is also a Sass & Compass-powered minimalist theme with a focus on best practices for HTML5 and front end development within Drupal. It has a number of cool features like Google Chrome Frame and Typekit integration. Aurora encourages the use of Panels' HTML5 Sections layout instead of using the standard Drupal left/right sidebar block regions for sidebars. Aurora also suggests you use the Blockify module to turn all the little things on the page that normally get rendered in a page template variable into blocks that you can assign to regions via Drupal's block admin page. There are a number of features in Aurora which have been pulled out and put into a separate module, so that any theme can make use of them. That module is called Magic and some of it's best features are the ability to exclude certain CSS/JS from being included, exporting of theme settings, enhancement of CSS aggregation and adding a viewport width indicator - which is very helpful when developing a responsive site to check all your breakpoints and everything in between.

Conclusion

Susy provides a great way of quickly getting your site layout blocked out and can produce any kind of grid you need. What has your experience been like using Susy in Drupal?

Jeff Eaton and Jason Scott discuss digital preservation, the historical importance of the web, and the utility of large hard drives.

• Sockington The Cat
• Textfiles.com
• MAKE.MONEY.FAST
• The Geocities Archive
• The Archive Team
• "Falling Hare" Looney Tunes Episode
• The Posterous Archive Project
• The Meme Hustler

The web is a part of our culture now, and perserving its history has value

One of my recent innocent tweet about Gerrit vs Github triggered much more reponses and debate that I expected it to. I realize that it might be worth explaining a bit what I meant, in a text longer than 140 characters.

I'm having a hard time now contributing to projects not using Gerrit. Github isn't that good.

— Julien Danjou (@juldanjou) May 8, 2013 <script async="async" charset="utf-8" src="http://platform.twitter.com/widgets.js"></script> The problems with Github pull-requests

I always looked at Github from a distant eye, mainly because I always disliked their pull-request handling, and saw no value in the social hype it brings. Why?

One click away isn't one click effort

The pull-request system looks like an incredible easy way to contribute to any project hosted on Github. You're a click away to send your contribution to any software. But the problem is that any worthy contribution isn't an effort of a single click.

Doing any proper and useful contribution to a software is never done right the first time. There's a dance you will have to play. A slowly rhythmed back and forth between you and the software maintainer or team. You'll have to dance it until your contribution is correct and can be merged.

But as a software maintainer, not everybody is going to follow you on this choregraphy, and you'll end up with pull-request you'll never get finished unless you wrap things up yourself. So the gain in pull-requests here, isn't really bigger than a good bug report in most cases.

This is where the social argument of Github isn't anymore. As soon as you're talking about projects bigger than a color theme for your favorite text editor, this feature is overrated.

Contribution rework

If you're lucky enough, your contributor will play along and follow you on this pull-request review process. You'll make suggestions, he will listen and will modify his pull-request to follow your advice.

At this point, there's two technics he can use to please you.

Technic #1: the Topping

Github's pull-requests invite you to send an entire branch, eclipsing the fact that it is composed of several commits. The problem is that a lot of one-click-away contributors do not masterize Git and/or do not make efforts to build a logical patchset, and nothing warns them that their branch history is wrong. So they tend to change stuff around, commit, make a mistake, commit, fix this mistake, commit, etc. This kind of branch is composed of the whole brain's construction process of your contributor, and is a real pain to review. To the point I quite often give up.

<figure> <figcaption> A typical case: 3 commits to build a 4 lines long file. </figcaption> </figure>

Without Github, the old method that all software used, and that many software still use (e.g. Linux), is to send a patch set over e-mail (or any other medium like Gerrit). This method has one positive effect, that it forces the contributor to acknowledge the list of commits he is going to publish. So, if the contributor he has fixup commits in his history, they are going to be seen as first class citizen. And nobody is going to want to see that, neither your contributor, nor the software maintainers. Therefore, such a system tend to push contributors to write atomic, logical and self-contained patchset that can be more easily reviewed.

Technic #2: the History Rewriter

This is actually the good way to build a working and logical patchset using Git. Rewriting history and amending problematic patches using the famous git rebase --interactive trick.

The problem is that if your contributor does this and then repush the branch composing your pull-request to Github, you will both lose the previous review done, each time. There's no history on the different versions of the branch that has been pushed.

In the old alternative system like e-mail, no information is lost when reworked patches are resent, obviously. This is far better because it eases the following of the iterative discussions that the patch triggered.

Of course, it would be possible for Github to enhance this and fix it, but currently it doesn't handle this use case correctly..

<figure> <figcaption> Exercise for the doubtful readers: good luck finding all revisions of my patch in the pull-request #157 of Hy.</figcaption> </figure> A quick look at OpenStack workflow

It's not a secret for anyone that I've been contributing to OpenStack as a daily routine for the last 18 months. The more I contribute, the more I like the contribution workflow and process. It's already well and longly described on the wiki, so I'll summarize here my view and what I like about it.

Gerrit

To send a contribution to any OpenStack project, you need to pass via Gerrit. This is way simpler than doing a pull-request on Github actually, all you have to do is do your commit(s), and type git review. That's it. Your patch will be pushed to Gerrit and available for review.

Gerrit allows other developers to review your patch, add comments anywhere on it, and score your patch up or down. You can build any rule you want for the score needed for a patch to be merged; OpenStack requires one positive scoring from two core developers before the patch is merged.

Until a patch is validated, it can be reworked and amended locally using Git, and then resent using git review again. That simple. The historic and the different version of the patches are available, with the whole comments. Gerrit doesn't lose any historic information on your workflow.

Finally, you'll notice that this is actually the same kind of workflow projects use when they work by patch sent over e-mail. Gerrit just build a single place to regroup and keep track of patchsets, which is really handy. It's also much easier for people to actually send patch using a command line tool than their MUA or git send-email.

Gate testing

Testing is mandatory for any patch sent to OpenStack. Unit tests and functionnals test are run for each version of each patch of the patchset sent. And until your patch passes all tests, it will be impossible to merge it. Yes, this implies that all patches in a patchset must be working commits and can be merged on their own, without the entire patchset going in! With such a restricution, it's impossible to have "fixup commits" merged in your project and pollute the history and the testability of the project.

Once your patch is validated by core developers, the system checks that there is not any merge conflicts. If there's not, tests are re-run, since the branch you are pushing to might have changed, and if everything's fine, the patch is merged.

This is an uncredible force for the quality of the project. This implies that no broken patchset can ever sneak in, and that the project pass always all tests.

Conclusion: accessibility vs code review

In the end, I think that one of the key of any development process, which is code review, is not well covered by Github pull-request system. It is, along with history integrity, damaged by the goal of making contributions easier.

Choosing between these features is probably a trade-off that each project should do carefully, considering what are its core goals and the quality of code it want to reach.

I tend to find that OpenStack found one of the best trade-off available using Gerrit and plugging testing automation via Jenkins on it, and I would probably recommend it for any project taking seriously code reviews and testing.

While ago i was looking for an slider module (implementation of JQuery UI slider module), surprisingly i couldn't find any solution except jSlider Form API which wasn't exactly what i was looking for. So i did what every good Drupal developer does, I wrote a generic slider module and shared it on Drupal.org (jQuery UI Slider Field). I even implemented "jSlider Form API" features.

Several months later and after i published several new minor versions, one of the users mentioned that there is in fact another slider module similar to mine!! SliderField and it was quite old too. He suggested joining forces to prevent duplicate modules. and that's what i did and even more.

read more