Agrégateur de flux

Gergely Nagy: GSoC2014: syslog-ng accepted projects

Planet Debian - mer, 23/04/2014 - 14:01

The Google Summer of Code 2014 programme reached another milestone recently: the accepted proposals were published, and over a thousand students were selected by nearly two hundred mentoring organisations, among them the syslog-ng project. We will be working with four students this year (twice we worked with last year), with more mentors, on a wider selection of projects. It was a tough decision to select the proposals, we received some very strong work this year.

We would like to express our gratitude to both Debian, for giving us an extra slot (so we could accept four students instead of three), and Google and Carol Smith in particular, for allowing it, and putting up with our fumbling during the process.

The accepted projects and students are:

Good luck to all students, we're looking forward to working with you throughout the summer! Happy hacking!

Catégories: Elsewhere

Andrew Pollock: [life] Day 85: Mostly a day off for me

Planet Debian - mer, 23/04/2014 - 08:37

Zoe slept solidly all night. She woke up a little before 6am, wanting a cuddle, but it was still dark, so she went back to sleep for another half an hour or so. It was actually nice to get that extra 30 minutes to have a leisurely wake up myself.

Sarah wanted to pick up Zoe at 7:45am to get away and get a camp site, so when Zoe finally woke up for the day, we didn't muck around too much. She announced she wanted banana and oat pancakes, but we were out of bananas. I offered her the opportunity to scooter down to the Hawthorne Garage to get some if she went and got dressed. She decided that'd be good.

I had a 10am appointment in the city with an intellectual property lawyer to talk about patents, so I had this grand plan of trying to squeeze in a run after Zoe was picked up and before I'd have to head into the city, so I got into my running gear, and we headed down to acquire some bananas.

We whipped up the pancakes, and then after a couple of mouthfuls of hers, Zoe declared she didn't like it and wanted Cheerios instead. Oh well. It was nice to get out of the house early in the morning, and it helped get Zoe moving.

Sarah ended up getting here closer to 8:30am, which made it a little too tight to go for a run, have a shower and get into the city, so I scrapped the run and pottered around at home instead for a bit, before driving into the city.

My goodness casual parking in the city is exorbitant. It cost me $35 for under an hour. I got some good advice from the lawyer, so I know where to proceed from here.

Next I headed down to the Valley to get my orientation at River City Labs, but had I read my email before leaving the city, I'd have discovered that the lady giving me the orientation had to leave early because her daughter was ill. It cost me $6 drive into the car park in the Valley, take the elevator down, read my email on my phone and pay my ticket and leave again. Lesson learned.

I decided to do the grocery shopping that I hadn't done yesterday while I waited for Anshu to come over.

Catégories: Elsewhere

Károly Négyesi: How to crash your site

Planet Drupal - mer, 23/04/2014 - 08:14

I got a desperate call about a site being down, this is ordinary for me (advertisment: you can contact me if it happens to you). But the error I saw was new to me. This is surprising -- I have thought I have seen it all and then some. The modules/views/includes/plugins.inc was fataling about the function views_include not existing. At first I thought opcache went south cos how on earth could an include be loaded when the module isn't?? But it wasn't opcache. Next step was adding a debug_print_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS) before the offending views_include call and behold... what?? variable_initialize?? o_O OH! Obviously the poor thing is trying to unserialize a views object but it's superb early in the bootstrap and so modules aren't loaded. So while unserializing the classloader loads plugins.inc which leads to this fatal. Neat. Moral of the story: don't ever try to store a views object in variables. Or an array containing a views object.

Catégories: Elsewhere

Modules Unraveled: 105 Using Membership Entity to Set Up a Drupal Based Membership Site with Caleb Thorne, Bryan Jones and David Csonka - Modules Unraveled Podcast

Planet Drupal - mer, 23/04/2014 - 07:00
Published: Wed, 04/23/14Download this episodeProject
  • What is the Membership Entity module?
    Project background
    First membership site developed was Mercedes-Benz Club of America (http://www.mbca.org).
    Involved a bunch of custom code.
    Development
    Entity API
    Key features
    Multiple users per membership (primary and secondary)
    Join/Renew online
    Role management
    Membership terms and modifiers
    E-Commerce solutions (coming soon)
    Commerce integration (Caleb)
    Ubercart integration (Bryan)
    product class
    Using product attributes to store membership data.
    Investigating better ways to store data before official release.

  • Do you handle pro-rated renewals?

  • Trials?
  • How are you guys dealing with role based permissions, and time limited access?
  • Are there different levels of membership?
  • Do you deal with CC details?
  • What other solutions did you guys look at before creating this one?
    • Why not just use profile2/rules/civiCRM or other existing modules?

The big problem with Profile2 is that it only allows one user per profile. Some fields should be shared for all users that belong to a single membership.
Membership Entity includes rules integration.
Membership Entity is 100% Drupal. No third party integration required.

Use Cases
  • Do you guys have any sites currently running the Membership Entity module?
    (David) - Joined the team after much of the development of the module was already done, so had the perspective of a developer on the outside, learning what the module provides and how to extend it. Being built around the Entity API made creating Views-based reports very simple, as most of the membership data that I needed to display was already exposed. For any that wasn’t, the extensible nature of the module (via things like all of the provided custom hooks) made the process of developing additional custom entities derived from membership meta-data rather straightforward.
    (Bryan) - Drop in solution for simple membership sites (CEMA).
    No custom code required.
    Membership process working in less than an hour.
    Integrated with Ubercart (Module coming soon).
Episode Links: draenen (Caleb Thorne)BryanDavid CsonkaMonarch DigitalMembership EntityCommerce integration (sandbox)Ubercart integration (sandbox)Module release blog postWe will be having a BoF at DrupalCon Austin. Watch for it atTags: 
Catégories: Elsewhere

Clint Adams: Before the tweet in Grand Cayman

Planet Debian - mer, 23/04/2014 - 04:02

Jebediah boarded the airplane. It was a Bombardier CRJ900 with two turbofan jet engines. Run by SPARK, a subset of Ada. He sat down in his assigned seat and listened to the purser inform him that he was free to use his phone door-to-door on all Delta Connection flights. As long as the Airplane Mode was switched on. Jebediah knew that this was why Delta owned 49% of Virgin Atlantic.

On the plane ride, a woman in too much makeup asked Jebediah to get the man next to him so she could borrow his copy of the Economist. The man said she could keep it and that it was old. He had stubby little fingers. She was foreign.

At Terminal 2, they passed by Kids on the Fly, an exhibit of the Chicago Children's Museum at Chicago O'Hare International Airport. A play area. Jebediah thought of Dennis.

The Blue Line of the Chicago Transit Authority was disrupted by weekend construction, so they had to take a small detour through Wicker Park. Wicker Park is a neighborhood. In Chicago. Jebediah looked at Glazed & Infused Doughnuts. He wondered if they made doughnuts there. Because of the meeting, he knocked someone off a Divvy bike and pedaled it to the Loop.

Once he got to the Berghoff, he got a table for seven on the west wall. He eyed the electrical outlet and groaned. He had brought 3 cigarette lighter adapters with him, but nothing to plug into an AC outlet. How would he charge his device? An older gentleman came in. And greeted him.

“Hello, I'm Detective Chief Inspector Detweiler. Did you bring the evidence?” Said the man.

Jebediah coughed and said that he had to go downstairs. He went downstairs and looked at the doors. He breathed a sigh of relief. Seeing the word “washroom” in print reminded him of his home state of Canada. Back at the table he opened a bag, glared angrily at a cigarette lighter adapter, and pulled out a Palm m125. Running Palm OS 4.0.

“This has eight megabytes of RAM,” he informed the newcomer.

DCI Detweiler said, “I had a Handspring Visor Deluxe,” and pulled out a Samsung Galaxy Tab 3 8.0 eight-inch Android-based tablet computer running the Android 4.2.2 Jelly Bean operating system by Google. “This also has eight megabytes of RAM,” he continued. “As you requested, I brought the video of your nemesis at the Robie House.

Jebediah stared at the tablet. He could see a compressed video file, compressed with NetBSD compression and GNU encryption. It was on the tablet. “Some bridges you just don't cross,” he hissed.

Part 2

AUD:USD 1.0645

donuts:dozen 12

Gold $1318.60

Detective Seabiscuit sucked on a throat lozenge. “Who are you again?” he asked the toll-booth operator.

“I said my name is Rogery Sterling,” replied the toll-booth operator.

“Rajry what?”

“I said my name is Rogery Sterling,” replied the toll-booth operator. Again.

“Where am I?”

“Look, I'm telling you that that murder you're investigating was caused by software bugs in the software.”

“Are we on a boat?”

“Look at the diagram. This agency paid money to introduce, quite deliberately, weaknesses in the security of this library, through this company here, and this company here.”

“Library, oh no. I have overdue fees.”

“And they're running a PR campaign to increase use of this library. Saying that the competing options are inferior. But don't worry, they're trying to undermine those too.”

Detective Seabiscuit wasn't listening. He had just remembered that he needed to stop by the Robie House.

Catégories: Elsewhere

Darren Mothersele: Drupal Site Builder Patterns - The State Machine

Planet Drupal - mer, 23/04/2014 - 01:00

In this new series for my blog, I'll be documenting some common design patterns for Drupal site builds. This first post is about the State Machine pattern, which is something I've used on several sites recently.

First, let me explain what I mean by "pattern". If you are already familiar with design patterns in Object-oriented software then you can probably skip this bit, but I think it's useful for context.

Design patterns?

Here's a quote from the original Gang of Four book on design patterns. That book is about design of object-oriented software, but I think it applies to Drupal development too. The quote is from p.1 of the book, apologies if I offend anyone by bastardising it. I've taken the liberty of substituting the words "Designing object-oriented software" with "building Drupal sites", and a few other substitutions to make my point...

[Building large maintainable Drupal sites] is hard... Your design should be specific to the problem at hand but also general enough to address future problems and requirements [and be maintainable]... Experienced [Drupal site builders] will tell you that a reusable and flexible design is difficult if not impossible to get "right" the first time.

Yet experienced [Drupal site builders] do make good designs. Meanwhile new [site builders] are overwhelmed by the options available and tend to fall back on non-[Drupal] techniques they've used before. It takes a long time for novices to learn what good [Drupal site building] is all about. Experienced [site builders] evidently know something inexperienced ones don't. What is it?

One thing expert [site builders] know NOT to do is solve every problem from first principles. Rather, they reuse solutions that have worked for them in the past. When they find a good solution, they use it again and again. Such experience is part of what makes them experts.

So I've been looking at what these "good solutions" are that I might have been using, and as I identify them I've been documenting them along the same lines of the original design patterns from the Gang of Four book:

  • Pattern name - the handle we use to describe the problem
  • Problem - explain the problem and its context, and when you might want to use this pattern
  • Solution - describe the elements that make up the solution, in my case how the pattern can be best implemented in Drupal
  • Consequences - results and trade-offs of using the pattern, in this case I also consider further issues that many need to be considered as a result of using the pattern.

So, first let's look at what a state machine is, and what problems it solves, before going on to look at how to configure it in Drupal.

State Machine

A state machine is a theoretical computer science concept that provides a mathematical basis for modelling computation. But don't worry, the kind of state machines we'll be using don't require a degree in computer science to understand.

All you really need to know is that the state machine (or more correctly a Finite State Machine) has a finite number of "states" it can be in and the machine is only ever in one of these states at a time, it's current state. The state machine can change from one state to another triggered by an event or condition. This change of state is called a transition. A state machine is typically visualised using a state machine diagram, for example:

As you can see the states are represented by an ellipse with the name of the state inside, the arrows denote the possible transitions. You can also see how the entry point and exit point would be notated.

Here's a (very simplified) example of a ticket in an agile issue queue. In reality this would probably have several other states but for the sake of this example, here's a simple state machine for the ticket:

A state machine is defined by the list of possible states and the event/condition that triggers each transition.

If you're reading this and thinking "Events", "Conditions", sounds a bit like Drupal Rules, then you've already worked out how we're going to implement this in Drupal!

In this simple ticket example the states are "In progress", "Approval", and "Finished". The transitions are "Completed", "Rejected", "Accepted".

When to use it?

It might be useful to think that in business speak, when they say "business processes" they are actually talking about state machines. Here are some cases when you might want to think about state machines:

  • If you've ever had to model a "state" or "status" field, then you've got a good candidate for a state machine.
  • If you've ever wanted to anything more complex than just published and unpublished nodes then you have a good candidate for using a state machine.
  • If you have boolean fields in your content model called things like "paid/unpaid".
  • If you have records that need to expire after a specific period of time

Drawing out a state machine diagram to model this kinds of problems can be really useful to help identify any "edge-case" scenarios you may not have thought of, and capture them early in the design process. It also shows you exactly what you need to test further along in the site build.

Let's build it

As with anything in Drupal there are several ways to achieve this functionality, in fact there's even a State Machine module, but that relies on creating custom plugins. If you're a developer you might want to take a look at this module.

Workbench Moderation and various other workflow modules include a state machine implementation for a specific purpose.

The approach documented here is suitable for site builders, is flexible, and provides a neat solution that can be configured using the following contributed modules:

I said before that the state machine is defined by it's set of possible states and set of transitions. In Drupal we'll be using a simple list field to store the list of possible states for the node.

In a recent post on Drupalize.me they mention the addition of the ability to hide form fields in Drupal 8 core. In Drupal 7 we need a module to help us do this. In this case we are adding a field that will never be directly edited by the user so we just deny access to edit that field using the Field Permissions module.

For the simple ticket example, we have 3 states. So use an integer list field with the following allowed values:

  • 0|In progress
  • 1|Awaiting approval
  • 2|Finished

I said that the state machine was defined by the set of possible states (implemented by our list field), and a set of transitions. These transitions can be implemented using the Rules Link module.

Using the Rules Link module you can add a button to the ticket node which manipulates the "state" value preventing the user from actually editing the value in the state field directly, and thus enforcing the workflow defined in our state machine.

Each "Rules link" is configured in two parts. First you define the conditions for when the link should be visible using standard Rules conditions. Secondly, you use the rules reaction to set the value of the state field to the new value (and perform any other actions that you want as a side effect of the transition).

Considerations

It's good to follow a principle of audit-ability, so you probably need to keep the transition history. A simple solution might be to add a timestamp field such as "confirmed at" to mark when it went to confirmed state. If using node, you could log revisions to track state changes in the revision log for the node. Or you could look at Messages module to log messages when state changes happen.

More patterns

If you're interested in learning more from my 7 years of Drupal experience (and if you're based in London) why not join me for Everything I Know About Drupal an intensive 2-day Drupal training I've been working on. It's taken a lot of preparation, and there's still a small number of tickets available. You can find more information on my blog post about it or grab a ticket on the Eventbrite page.

Catégories: Elsewhere

Evolving Web: DrupalCamp NYC at the United Nations - Recap and Photos

Planet Drupal - mar, 22/04/2014 - 23:52

This year's DrupalCamp NYC was held at the United Nations. The camp was crammed with summits and useful sessions and included a lot of content about Drupal 8.

read more
Catégories: Elsewhere

Steve Kemp: I've not commented on security for a while

Planet Debian - mar, 22/04/2014 - 23:14

Unless you've been living under a rock, or in a tent (which would make me slightly jealous) you'll have heard about the recent heartbleed attack many times by now.

The upshot of that attack is that lots of noise was made about hardening things, and there is now a new fork of openssl being developed. Many people have commented about "hardening Debian" in particular, as well as random musing on hardening software. One or two brave souls have even made noises about auditing code.

Once upon a time I tried to setup a project to audit Debian software. You can still see the Debian Security Audit Project webpages if you look hard enough for them.

What did I learn? There are tons of easy security bugs, but finding the hard ones is hard.

(If you get bored some time just pick your favourite Editor, which will be emacs, and look how /tmp is abused during the build-process or in random libraries such as tramp [ tramp-uudecode].)

These days I still poke at source code, and I still report bugs, but my enthusiasm has waned considerably. I tend to only commit to auditing a package if it is a new one I install in production, which limits my efforts considerably, but makes me feel like I'm not taking steps into the dark. It looks like I reported only three security isseus this year, and before that you have to go down to 2011 to find something I bothered to document.

What would I do if I had copious free time? I wouldn't audit code. Instead I'd write test-cases for code.

Many many large projects have rudimentary test-cases at best, and zero coverage at worse. I appreciate writing test-cases is hard, because lots of times it is hard to test things "for real". For example I once wrote a filesystem, using FUSE, there are some built-in unit-tests (I was pretty pleased with that, you could lauch the filesystem with a --test argument and it would invoke the unit-tests on itself. No separate steps, or source code required. If it was installed you could use it and you could test it in-situ). Beyond that I also put together a simple filesystem-stress script, which read/wrote/found random files, computes MD5 hashes of contents, etc. I've since seen similar random-filesystem-stresstest projects, and if they existed then I'd have used them. Testing filesystems is hard.

I've written kernel modules that have only a single implicit test case: It compiles. (OK that's harsh, I'd usually ensure the kernel didn't die when they were inserted, and that a new node in /dev appeared ;)

I've written a mail client, and beyond some trivial test-cases to prove my MIME-handling wasn't horrifically bad there are zero tests. How do you simulate all the mail that people will get, and the funky things they'll do with it?

But that said I'd suggest if you're keen, if you're eager, if you want internet-points, writing test-cases/test-harnesses would be more useful than randomly auditing source code.

Still what would I know, I don't even have a beard..

Catégories: Elsewhere

Daniel Pocock: Automatically creating repackaged upstream tarballs for Debian

Planet Debian - mar, 22/04/2014 - 22:34

One of the less exciting points in the day of a Debian Developer is the moment they realize they have to create a repackaged upstream source tarball.

This is often a process that they have to repeat on each new upstream release too.

Wouldn't it be useful to:

  • Scan all the existing repackaged upstream source tarballs and diff them against the real tarballs to catalog the things that have to be removed and spot patterns?
  • Operate a system that automatically produces repackaged upstream source tarballs for all tags in the upstream source repository or all new tarballs in the upstream download directory? Then the DD can take any of them and package them when he wants to with less manual effort.
  • Apply any insights from this process to detect non-free content in the rest of the Debian archive and when somebody is early in the process of evaluating a new upstream project?
Google Summer of Code is back

One of the Google Summer of Code projects this year involves recursively building Java projects from their source. Some parts of the project, such as repackaged upstream tarballs, can be generalized for things other than Java. Web projects including minified JavaScript are a common example.

Andrew Schurman, based near Vancouver, is the student selected for this project. Over the next couple of weeks, I'll be starting to discuss the ideas in more depth with him. I keep on stumbling on situations where repackaged upstream tarballs are necessary and so I'm hoping that this is one area the community will be keen to collaborate on.

Catégories: Elsewhere

Drupalize.Me: Webinar: Easily Create Maps with Leaflet

Planet Drupal - mar, 22/04/2014 - 21:50

Curious about Leaflet? Join Drupalize.Me Trainer Amber Matz for a live tutorial on how to add Leaflet maps to your Drupal site during this Acquia hosted webinar on May 1, 2014 at 1:00 PM EDT.

Catégories: Elsewhere

Ritesh Raj Sarraf: Basis B1

Planet Debian - mar, 22/04/2014 - 21:32

 

Starting yesterday, I am a happy user of the Basis B1 (Carbon Edition) Smart Watch

The company recently announced being acquired by Intel. Overall I like the watch. The price is steep, but if you care of a watch like that, you may as well try Basis. In case you want to go through the details, there's a pretty comprehensive review here.

Since I've been wearing it for just over 24hrs, there's not much data to showcase a trend. But the device was impressively precise in monitoring my sleep.

 

Pain points - For now, sync is the core of the pains. You need either a Mac or a Windows PC. I have a Windows 7 VM with USB Passthru, but that doesn't work. There's also an option to sync over mobile (iOS and Android). That again does not work for my Chinese Mobile Handset running MIUI.

AddThis:  Categories: Keywords: 
Catégories: Elsewhere

Dcycle: Simpletest Turbo: how I almost quadrupled the speed of my tests

Planet Drupal - mar, 22/04/2014 - 21:15

My development team is using a site deployment module which, when enabled, deploys our entire website (with translations, views, content types, the default theme, etc.).

We defined about 30 tests (and counting) which are linked to Agile user stories and confirm that the site is doing what it's supposed to do. These tests are defined in Drupal's own Simpletest framework, and works as follows: for every test, our site deployment module is enabled on a new database (the database is never cloned), which can take about two minutes; the test is run, and then the temporary database is destroyed.

This created the following problem: because we were deploying our site 30 times during our test run, a single test run was taking over 90 minutes. Furthermore, we are halfway into the project, and we anticipate doubling, perhaps tripling our test coverage, which would mean our tests would take over four hours to run.

Now, we have a Jenkins server which performs all the tests every time a change is detected in Git, but even so, when several people are pushing to the git repo, test results which are 90 minutes old tend to be harder to debug, and developers tend to ignore, subvert and resent the whole testing process.

We could combine tests so the site would be deployed less often during the testing process, but this causes another problem: tests which are hundreds of lines long, and which validate unrelated functionality, are harder to debug than short tests, so it is not a satisfactory solution.

When we look at what is taking so long, we notice that a majority of the processing power goes to install (deploy) our testing environment for each test, which is then destroyed after a very short test.

Enter Simpletest Turbo, which provides very simple code to cache your database once the setUp() function is run, so the next test can simply reuse the same database starting point rather than recreate everything from scratch.

Although Simpletest Turbo is in early stages of development, I have used it to almost quadruple the speed of my tests, as you can see from this Jenkins trend chart:

I know: my tests are failing more than I would like them to, but now I'm getting feedback every 25 minutes instead of every 95 minutes, so failures are easier to pinpoint and fix.

Furthermore, fairly little time is spent deploying the site: this is done once, and the following tests use a cached deployment, so we are not merely speeding up our tests (as we would if we were adding hardware): we are streamlining duplicate effort. It thus becomes relatively cheap to add new independent tests, because they are using a cached site setup.

Tags: planetblog
Catégories: Elsewhere

C.J. Adams-Collier: AD Physical to Virtual conversion… Continued!

Planet Debian - mar, 22/04/2014 - 20:54

So I wasn’t able to complete the earlier attempt to boot the VM. Something to do with the SATA backplane not having enough juice to keep both my 6-disk array and the w2k8 disk online at the same time. I had to dd the contents off of the w2k8 disk and send it to the SAN via nc. And it wouldn’t write at more than 5.5MB/s, so it took all day.

Anyway, I’ve got a /dev/vg0/ad0 logical volume all set up now that I’m exporting to the guest as USB.

Here’s the libvirt xml file: win2k8.xml

No indication as to how long this will take. But I’ll be patient. It will be nice to have the AD server back online.

Catégories: Elsewhere

Axel Beckert: GNU Screen 4.2.0 in Debian Experimental

Planet Debian - mar, 22/04/2014 - 20:22
About a month ago, on 20th of March, GNU Screen had it’s 27th anniversary.

A few days ago, Amadeusz Sławiński, GNU Screen’s new primary upstream maintainer, released the status quo of Screen development as version 4.2.0 (probably to distinguish it from all those 4.1.0 labeled development snapshots floating around in most Linux distributions nowadays).

I did something similar and uploaded the status quo of Debian’s screen package in git as 4.1.0~20120320gitdb59704-10 to Debian Sid shortly afterwards. That upload should hit Jessie soon, too, resolving the following two issues also in Testing:

  • #740301: proper systemd support – Thanks Josh Tripplett for his help!
  • #735554: fix for multiuser usage – Thanks Martin von Wittich for spotting this issue!

That way I could decouple these packaging fixes/features from the new upstream release which I uploaded to Debian Experimental for now. Testers for the 4.2.0-1 package are very welcome!

Oh, and by the way, that upstream comment (or ArchLinux’s according announcement) about broken backwards compatibility with attaching to running sessions started with older Screen releases doesn’t affected Debian since that has been fixed in Debian already with the package which is in Wheezy. (Thanks again Julien Cristau for the patch back then!)

While there are bigger long-term plans at upstream, Amadeusz is already working on the next 4.x release (probably named 4.2.1) which will likely incorporate some of the patches floating around in the Linux distributions’ packages. At least SuSE and Debian offered their patches explicitly for upstream inclusion.

So far already two patches found in the Debian packages have been obsoleted by upstream git commits after the 4.2.0 release. Yay!

Catégories: Elsewhere

AGLOBALWAY: Drupal & Bootstrap

Planet Drupal - mar, 22/04/2014 - 19:34
Here at AGLOBALWAY, we are constantly learning to take advantage of the myriad of tools available to us whether for communication, productivity, or development. As a company dedicated to all things open source, one of the tools we employ is Twitter’s Bootstrap framework. Thanks to the industriousness and generosity of companies like Twitter, (or Zurb for its own Foundation framework, among others), the web community has a tremendous amount of resources from which to draw upon.   Drupal has been a key content management framework for us ever since the inception of our company for its flexibility, power, and configurability. Bootstrap has made an excellent companion for Drupal in several of our projects so far, so I will highlight just a few of the many ways that a Bootstrap-based theme can compliment your Drupal website.   Bootstrapped Style   While some decry the design style and “look” that is quintessentially Bootstrap, there really is no need to. Yes, it has been a major influence on modern web design trends. Bootstrap has prepackaged layouts and default styles for nearly all UI elements, taking away the need to create styles for everything. But, building a unique site that doesn’t follow that typical Bootstrap style own doesn’t have to be difficult. The real undertaking is in learning the ins and outs of the preprocessor system employed by Bootstrap (Less, in this case), and how they have laid everything out.   Once familiar with the system, one will quickly realize that it’s relatively straightforward to take advantage of all of the mixins and variables already given in order to generate the styles you have designed. In one .less file, we can quickly define colours, sizes, and other default settings that will appear throughout your site. Again, like the JavaScript libraries above, this is not unique to Drupal. However, being able to take advantage of these tools helps immensely to speed up the development cycle of building Drupal sites.   JavaScript Libraries   Having access to a number of common functions used throughout the web is a huge time saver. Already bundled with jQuery, a Drupal Bootstrap-based theme allows for easy integration of accordions, image carousels and more, without having to write your own JavaScript. While these libraries are certainly not exclusive to Drupal, there can be unique ways of making use of them with Drupal. For example, rendering a block inside of a modal for a login form is a snap, and css is all you really need to customize it once you initialize it with the proper JavaScript.   Another example would be to pair Bootstrap with the popular CKEditor module to generate templates, using Bootstrap’s markup. Users may want to place an accordion inside their own managed content, so we can create a template with CKEditor’s default.js file (even better, create a separate file and use that one instead), following the pattern of the templates already given. Add the Bootstrap markup with the appropriate classes, and voila! Your users now have an accordion they can insert using only the WYSIWYG editor.   Bootstrap Views   This is a Drupal module I have yet to really play around with personally, but a cursory look tells me just how easy it can be to display content using Bootstrap elements without even getting into template files or writing code. While I generally prefer to separate markup from data output, I can see the potential here for a lot of time saving, while avoiding some head-scratching at the same time. This is the whole point of views in the first place - making it easy to display the content you want without having to dive too deep.   As we can see, integrating Drupal with Twitter Bootstrap has considerable advantages. While its heaviness is a fair criticism, I believe those advantages justify the use of Bootstrap, particularly in an Agile development environment. Besides, we can always eliminate the JavaScript or CSS we don’t use once we’re done developing our site. Whether it’s Bootstrap, Foundation, or your framework of choice, having such front-end tools to integrate with Drupal can only be a good thing. Many thanks to all who are dedicated to creating and maintaining these resources for the benefit of us all. Tags: drupal planetBootstrap
Catégories: Elsewhere

Propeople Blog: Propeople at Stanford Drupal Camp 2014

Planet Drupal - mar, 22/04/2014 - 19:26

This past weekend, some of our team had the pleasure of attending Stanford Drupal Camp, which Propeople supported as a Gold Sponsor. Stanford University is one of the biggest advocates of Drupal in higher-education, and is home to an active and passionate Drupal community. Hosted on the world famous (and too-gorgeous-to-put-into-words) Stanford campus, the Stanford Drupal Camp is an annual event focused on Drupal and the state of Drupal at the university (where thousands of websites are powered by the CMS). Propeople has participated in the event the past few years, and we've had the pleasure to work on a wide variety of Stanford projects in the same amount of time. These include the Stanford Graduate School of Business, SLAC National Accelerator Laboratory, Stanford Student Affairs, Riverwalk Jazz, and many others. 

Stanford Drupal Camp featured a great line-up of sessions and talks all day Friday and Saturday, ranging from the simple to the complex. The talks focused on a variety of topics, from site building to Agile and Scrum methodology to specific Drupal use cases in higher education. As you can expect at any Drupal camp, more casual BoFs and lightning talks were interspersed throughout the conference.

We were happy to have the packed schedule include two sessions presented by one of Propeople’s own Drupal experts, Yuriy Gerasimov, on Saturday. Yuriy’s first session was titled “CI and Other Tools for Feature Branch Development”, aimed at helping developers and organizations implement feature-branch workflow. The second was “Local Development with Vagrant”, which, as you might have guessed from the title, was all about the benefits of using Vagrant to spin up local virtual machines with the same settings on different platforms.

 

 

Overall, the many sessions, BoFs, and lightning talks provided Stanford staff, faculty, students, and developers (from the university and beyond) with plenty of great information.

In addition to the full session schedule, Stanford Drupal Camp featured plenty of opportunities for those at the event to enjoy each other’s company, catch up, and engage in some great conversation about every attendee’s favorite topic...Drupal! As a technology partner to more than a dozen Stanford departments and institutions, Propeople has learned first hand how great the Stanford community is, and it was a treat to have some of our team on campus to join in on the fun at Stanford Drupal Camp. We’ll be looking forward to next year!

Tags: DrupalDrupal campStanfordCheck this option to include this post in Planet Drupal aggregator: planetTopics: Community & Events
Catégories: Elsewhere

Phase2: Exploring Maps In Sass 3.3(Part 3): Calling Variables with Variables

Planet Drupal - mar, 22/04/2014 - 19:25

For this blog entry, the third in a series about Sass Maps, I am going to move away from niche application, and introduce some more practical uses of maps.

Living Style Guides

In my current project, a large Drupal media site,  I wanted to have a style guide, a single static page where we could see all of the site colors, along with the variable name. I collected all of my color variables, and created some static markup with empty divs. Below is the loop I started to write.

<!-- The HTML for our Style Guide --> <div class="styleguide"> <div class="primary-color"></div> <div class="secondary-color"></div> <div class="tertiary-color"></div> </div>

// Our site color variables $primary-color: #111111; $secondary-color: #222222; $tertiary-color: #333333; // Make a list of the colors to display $styleguide-colors: primary-color, secondary-color, tertiary-color; // Loop through each color name, create class name and styles @each $color in $styleguide-colors { .styleguide .#{$color} { background-color: $#{$color}; // Spoiler Alert: Does not work!! &:after { content: “variable name is #{$color}” } } }

This loop goes through each color in my $styleguide-colors list and creates a class name based on the color name. It then attempts to set the background-color by calling a variable that matches the name from the list. We also set the content of a pseudo element to the variable name, so that our styleguide automatically prints out the name of the color.

This is what we want the first loop to return:

.styleguide .primary-color {  background-color: $primary-color; // Nope, we won’t get this variable  &:after {      content: “variable name is primary-color”    } }

The problem is that we can’t interpolate one variable to call another variable! $#{$color}  doesn’t actually work in Sass. It won’t interpolate into $ + primary-color , and then yield #111111  in the final CSS. This 3 year old github issue points out this exact issue, and hints at how maps is going to be introduced in Sass 3.3 to solve this problem. https://github.com/nex3/sass/issues/132

Make it better with maps

So now that we have maps, how can we create this color styleguide? Lets take this a step at a time.

First we need to wrap all of our colors in a map. Remember, any of these colors can be accessed like this: map-get($site-colors, primary-color)

$site-colors: (  primary-color: #111111,  secondary-color: #222222,  tertiary-color: #333333, );

Now we can create a list of the colors we want to iterate through and loop through them just like we did before.

$styleguide-colors: primary-color, secondary-color, tertiary-color; @each $color in $styleguide-colors {  .styleguide .#{$color} {    background-color: map-get($site-colors, $color); // This DOES work!    &:after {      content: “variable name is #{$color}”    }  } }

This time when we loop through our colors we get the same class name and pseudo element content, but lets look at what happens with the background color. Here is the first pass through the loop, using primary-color as $color :

.styleguide .primary-color {   background-color: map-get($site-colors, primary-color);   &:after {      content: “variable name is primary-color”    } }

As you can see in this intermediate step, we are able to use map-get($site-colors, primary-color)  to programmatically pass our color name into a function, and get a returned value. Without maps we’d be stuck waiting for $#{$color} to be supported (which will probably never happen). Or in the case of my project, write all 20 site color classes out by hand!

Make it awesomer with maps

Astute readers might realize that I am still doing things the hard way. I created a map of colors, and then duplicated their names in a list called $styleguide-colors . We can skip that middle step and greatly simplify our code, if we are wanting to print out every single value in the map.

$site-colors: ( primary-color: #111111, secondary-color: #222222, tertiary-color: #333333, ); @each $color, $value in $site-colors { .styleguide .#{$color} { background-color: $value; &:after { content: “variable name is #{$color}” } } }

Now, instead of passing a list into the @each loop, we pass the entire map. We can do this with the following pattern: @each $key, $value in $map . Each iteration of the loop has access to both the key primary-color  AND the value #111111 , so we don’t even need the map-get function.

The ability to ‘call variables with variables’ is incredibly useful for creating these programmatic classes, and is a foundational process upon which we start to build more complex systems. Be sure to check out part 1 and 2 of my Sass Maps blog series!

Catégories: Elsewhere

Martin Pitt: Booting Ubuntu with systemd: Test packages available

Planet Debian - mar, 22/04/2014 - 18:54

On the last UDS we talked about migrating from upstart to systemd to boot Ubuntu, after Mark announced that Ubuntu will follow Debian in that regard. There’s a lot of work to do, but it parallelizes well once developers can run systemd on their workstations or in VMs easily and the system boots up enough to still be able to work with it.

So today I merged our systemd package with Debian again, dropped the systemd-services split (which wasn’t accepted by Debian and will be unnecessary now), and put it into my systemd PPA. Quite surprisingly, this booted a fresh 14.04 VM pretty much right away (of course there’s no Plymouth prettiness). The main two things which were missing were NetworkManager and lightdm, as these don’t have an init.d script at all (NM) or it isn’t enabled (lightdm). Thus the PPA also contains updated packages for these two which provide a proper systemd unit. With that, the desktop is pretty much fully working, except for some details like cron not running. I didn’t go through /etc/init/*.conf with a small comb yet to check which upstart jobs need to be ported, that’s now part of the TODO list.

So, if you want to help with that, or just test and tell us what’s wrong, take the plunge. In a 14.04 VM (or real machine if you feel adventurous), do

sudo add-apt-repository ppa:pitti/systemd sudo apt-get update sudo apt-get dist-upgrade

This will replace systemd-services with systemd, update network-manager and lightdm, and a few libraries. Up to now, when you reboot you’ll still get good old upstart. To actually boot with systemd, press Shift during boot to get the grub menu, edit the Ubuntu stanza, and append this to the linux line: init=/lib/systemd/systemd.

For the record, if pressing shift doesn’t work for you (too fast, VM, or similar), enable the grub menu with

sudo sed -i '/GRUB_HIDDEN_TIMEOUT/ s/^/#/' /etc/default/grub sudo update-grub

Once you are satisfied that your system boots well enough, you can make this permanent by adding the init= option to /etc/default/grub (and possibly remove the comment sign from the GRUB_HIDDEN_TIMEOUT lines) and run sudo update-grub again. To go back to upstart, just edit the file again, remove the init=sudo update-grub again.

I’ll be on the Debian systemd/GNOME sprint next weekend, so I feel reasonably well prepared now.

Catégories: Elsewhere

Gábor Hojtsy: Drupal Developer Days 2014 Organizers Report

Planet Drupal - mar, 22/04/2014 - 18:21


The organizer team is still energized after our experience putting together Drupal Dev Days Europe 2014 in Szeged, Hungary between 24 and 30 March.

Several people asked about details and we wanted to document the event for future event organizers to share what worked best for us. We prepared a report for you so if you experienced Drupal Dev Days Szeged, you can look behind the curtain a bit, or if you heard about it, you can see what we did to pull off an event like this. If you were not there and did not hear about it, we included several feedback references as well to give you an idea.

Do you want to see tweets and articles like those about your event? Read the report for our tips!

We definitely did not do everything right but we hope we can help people learn from the things we did right.

Excuse us if the report is a bit too long, we attempted to pack useful information to every single sentence to make reading it worth your time. Send questions and comments to the team.

Catégories: Elsewhere

Acquia: I’m Kris Vanderwater, Drupal Developer and Acquia’s Developer Evangelist.

Planet Drupal - mar, 22/04/2014 - 17:01

I’ve been working at Acquia for a little over two weeks now. The experience has been one I would characterize as “whirlwind” in nature. If you ask new Acquians about their on-boarding experience, the most common comparison is the age old “Drinking from a firehose” analogy. I honestly expected, as someone who already knew Drupal, that this might in some way lessen the stream of information to manageable levels. I was wrong. If anything the fire hose is a bit like sticking your toes into the shallow end of the pool, and knowing Drupal already was like “Oh you know how to swim?

Catégories: Elsewhere

Pages

Subscribe to jfhovinne agrégateur