Last Call Media: Design 4 Drupal, A First Timer's Perspective

Planet Drupal - jeu, 07/08/2014 - 22:39
Design 4 Drupal, A First Timer's Perspective

I just joined Last Call Media a couple of weeks ago, and was invited to join my new peers for a trip to Boston for Design 4 Drupal.  I was super excited for a couple of reasons.  A) I love a road trip, and B) this was my first opportunity to meet my new and extended Drupal family.

So, given that I am not a morning person, I set two alarms.  I did not want to be late to the meet-up spot and have my new coworkers leave without me, or think that I am a total slacker.  I showed up at 5:57am and was the only car there.  I started to feel foolish, like I had been the subject of a hilarious practical joke designed to break in the new team members.  I imagined my coworkers plotting against me “Just string a couple letters and numbers together, make an early meeting time on one of her first weekends.  You can imagine my relief, as the earliest of my coworkers started to trickle in, oh, and it turns out they are not the bullies I had imagined.  I now know that 6am means 6ish  (I think this is called Last Call standard time or LCST, for any event that begins before 8am).  From here we started our convoy, with 11 Last Callers en route.  Monster Energy Drink and Old School Rap tunes first thing in the morning had me amped for my first day long All-Geek event!

We arrived at MIT (what an amazing campus, btw) with plenty of time to set up a booth and attend the Keynote:  Steve from Republic of Quality gave a heartfelt talk about being emotionally connected to your work and how to demonstrate this with your content.

We had one of the first sessions of the morning, Case Study: lastcallmedia.com,  where we were able show how heartfelt and connected we all are to our work.

It became clear to me that I have joined a very engaging team, as I sat in on my new coworkers presenting their work; I learned that we have the first commercial site in the US running on Drupal 8. It was a great opportunity to treat ourselves to a very special site redesign and tackle Drupal 8, which was still alpha, and get our hands dirty with constant upgrades.   The team was so pumped to share their experience with the Drupal community!

There was a great deal of excitement from the attendees who were impressed that we invested the time and resources to work with Drupal 8. It made me very proud of where I work!  After the session, attendees flocked to our booth to find out more about our site and to ask more specific questions.  There is certainly is a lot of buzz about Drupal 8 and lastcallmedia.com.

I met a lot of great people in the Drupal community, and went to a few sessions myself.

Erin Holloway gave a lot of nice pointers for streamlining communication in the Anti-Handoff session and visuals to increase efficiency in the design/development process, from emails to Photoshop shortcuts.   This session was well attended by Last Call; I looked around the room and saw, Sean, Colin and Julia.

Jeff reported that he really enjoyed The Accessible Experience: Designing for Everyone session, where he was introduced to different accessibility tools and was able to see them demonstrated.

Jayme reported that the presentation RWD on a Budget WTF offered a good reminder about the countless small non-profits who both require and deserve a quality responsive website, but who do not have much of a budget. Large scale, and hence, expensive projects have more and more become the central focus of the industry. In our enthusiasm to see how far we can push the envelope of what we can do with Drupal for clients who have the budget to allow us to take it to this level, smaller companies--and in particular smaller non-profits--often get left behind. Johanna Bates and her collaborative made the important point that Drupal is still an excellent tool for making responsive websites that, while are perhaps not as ambitious to produce, offer a way to contribute to making the world a better place.”

Our very own Rob hosted a well-attended session at the end of the day, although technically way over my head, it must have had some good meat that developer types could chew into because I received several requests for the slides and code samples.  You can find his presentation here.

Most of us finished out the night at the General Assembly in Boston for a super time at the WeWork coworking space.  What a cool spot.  We challenged other developers to table tennis, learned a little mixology as we played “bartender” by hand squeezing our own lemons and crafting our Tom Collins drinks.

Catégories: Elsewhere

Niels Thykier: Recent improvements to Britney2

Planet Debian - jeu, 07/08/2014 - 22:27

As mentioned by Raphaël Hertzog, I have been spending some time on improving Britney2.  Just the other day I submitted a second branch for review that I expect to merge early next week.  I also got another set patches coming up soon.  Currently, none of them are really user visible, so unless you are hosting your own version of Britney, these patches are probably not all that interesting to you.


The highlights:

  1. Reduce the need for backtracking by finding semantically equivalent packages.
  2. Avoid needing to set up a backtrack point in some cases.
    • This has the side-effect of eliminating some O(e^n) runtime cases.
  3. Optimise “installability” testing of packages affected by a hinted migration.
    • This has the side-effect of avoiding some O(e^n) runtime cases when the “post-hint” state does not trigger said behaviour.
    • There is a follow-up patch for this one coming in the third series to fix a possible bug for a corner-case (causing a valid hint to be incorrectly rejected when it removed an “uninstallable” package).
  4. Reduce the number of affected packages to test when migrating items by using knowledge about semantically equivalent packages.
    • In some cases, Britney can now do “free” migrations when all binaries being updated replace semantically equivalent packages.
  5. (Merge pending) Avoid many redundant calls to “sort_actions()”, which exhibits at least O(n^2) runtime in some cases.
    • For the dataset Raphaël submitted, this patch shaves off over 30 minutes runtime.  In the particular case, each call to sort_actions takes 3+ minutes and it was called at least 10 times, where it was not needed.
    • That said, sort_actions have a vastly lower runtime in the runs for Debian (and presumably also Ubuntu, since no one complained from their side so far).


The results so far:

After the first patch series was merged, the Kali dataset (from Raphaël) could be processed in “only” ~2 hours. With the second patch series merged, the dataset will drop by another 30-50 minutes (most of which are thanks to the change mentioned in highlight #5).

The third patch series currently do not have any mention-worthy performance related changes.  It will probably be limited to bug fixes and some refactoring.



The 3 first highlights only affects the “new” installability tester meaning that the Britney2 instances at Ubuntu and Tanglu should be mostly unaffected by the O(n^2) runtime.  Although those cases will probably just fail with several “AIEEE“s. :) The 5th highlight should equally interesting to all Britney2 instances though.


For me, the most interesting part is that we have never observed the O(n^2) behaviour in a daily “sid -> testing” run.  The dataset from Raphaël was basically a “stable -> testing/sid” run, which is a case I do not think we have ever done before.  Despite our current updates, there is still room for improvements on that particular use case.

In particular, I was a bit disheartened at how poorly our auto hinter(s) performed on this dataset.  Combined they only assisted with the migration of something like 28 “items”.  For comparison, the “main run” migrated ~7100 “items” and 9220 items were unable to migrate. Furthermore, the “Original” auto hinter spend the better part of 15 minutes computing hints  – at least it results in 10 “items” migrating.


Links to the patches:


Catégories: Elsewhere

Sylvestre Ledru: Debian Twitter accounts are back

Planet Debian - jeu, 07/08/2014 - 21:46

After some downtime due to the identi.ca changes, the Debian Twitter accounts are now back.

New Twitter feed ideas are welcome.

Original post blogged on b2evolution.

Catégories: Elsewhere

Lars Wirzenius: On ticketing systems

Planet Debian - jeu, 07/08/2014 - 20:14

I don't really like any of the ticketing systems I've ever needed to use, whether they've been used as bug tracking systems, user support issue management systems, or something else. Some are not too bad. I currently rely most on debbugs and ikiwiki.

debbugs is the Debian bug tracking system. See https://www.debian.org/Bugs/ for an entry point. It's mostly mail based, with a read-only web interface. You report a bug by sending an email to submission address, and (preferably) include a few magic "pseudo-headers" at the top of your message body ot identify the package and version. There's tools to make this easier, but mostly it's just about sending an e-mail. All replies are via e-mails as well. Effectively, each bug becomes is own little dedicated mailing list.

This is important. A ticket, whether it is a bug report or a support request, is all about the discussion. "Hey I have this problem..." followed by "Have you tried..." and so forth. Anything that makes that discussion easier and faster to have is better.

It is my very strong opinion, and long experience, that the best way to have such a discussion is over e-mail. A lot of modern ticketing systems are web based. They might have an e-mail mode, perhaps read-only, but that's mostly an afterthought. It's a thing bolted onto the side of the system because people like me whinge otherwise.

I like e-mail for this for several reasons.

  • E-mail is push, not pull. I don't need to go look at a web page to be notified that something's happened.

  • E-mail requires no extra usernames and passwords to manage. I don't need to create a new account every time I encounter a new ticketing system instance.

  • E-mail makes it very easy to respond. I can just reply to a message. I don't need to go to a web site, log in, and find a reply button.

  • I already have archives of my e-mail, so referring to old messages (or finding them) is easy and quick. (Mutt, offlineimap, and notmuch is my particular set of choices. But I'm not locked to them, and you can use whatever you like, too.)

  • E-mail is a very rich format. Discussions are inherently threaded, and various character sets, languages, attachments, and other such things just work.

For these reasons, I strongly prefer ticketing systems in which e-mails are the primary form of discussions, and e-mail is a first class citizen. I don't mind if there's other ways to participate in the discussion, but if I have to use something else than e-mail, I tend not to be happy.

I use ikiwiki to provide a distributed, shared notebook on bugs. It's a bit cumbersome, and doesn't work well for discussions.

I think we can improve on the way debbugs works, however. I've been thinking about ticketing systems for Obnam (my backup program), since it gaining enough users that it's getting hard to keep track of discussions with just an e-mail client.

Here's what I want:

  • Obnam users do not need to care about there being a ticketing system. They report a problem by e-mailing the support mailing list, and they keep the list in cc when conducting the discussion. This is very similar to debbugs, with the distinction that there's no ticket numbers that must be kept in the replies.

  • The support staff (that's me, but hopefully others as well) have access to the ticketing system, which automatically sorts incoming messages into tickets. Tickets have sufficient metadata that it's possible to track which ones have been dealt with, or still need work, and perhaps other things. Each ticket contain a Maildir with all the e-mails belonging to that ticket.

  • The ticketing system is distributed. I need to be able to work on tickets offline, and to synchronise instances between different computers. Just like git. It's not enough to have an offline mode (e.g., queuing e-mails on my laptop for sending to debbugs when I'm back online).

  • There is a reasonably powerful search engine that can quickly find the relevant tickets, and messages, based on various criteria.

I will eventually have this. I'm not saying I'm working on this, since I don't have enough free time to do that, but there's a git repository, and some code, and it imports e-mails automatically now.

Some day there may even be a web interface.

(This has been a teaser.)

Catégories: Elsewhere

Drupal core announcements: Priority TCDrupalaton sprint tasks!

Planet Drupal - jeu, 07/08/2014 - 20:07

Today is the start of a double dose of sprint awesome at TCDrupal and Drupalaton. Here are some important sprint tasks to help get Drupal 8 done.

  1. Beta blockers

    Our top goal for the sprints is to make significant progress on the three remaining beta blocker issues. These issues aren't the best place to jump in if you're not already following them, but plach, alexpott, effulgentsia, fago, and others are going to do what they can to get these issues done.

  2. Beta deadline issues

    The next priority for the sprints are the beta deadline issues, which are non-critical issues that will have to be postponed to either Drupal 8.1.x or Drupal 9 if they are not done by the time the beta is ready. Many of these issues are related to the Entity Field API, so if you're interested in those systems, reach out to entity and field maintainers fago and swentel at Drupalaton to see if there's a beta deadline issue for you.

  3. Twig autoescape followups and double-escaping bugs

    One of the beta-blocking issues that's already been resolved is enabling Twig's autoescape functionality, so that strings that have not already been sanitized by Drupal can be escaped automatically in the theme layer. There are a lot of important followups to this change, which can be grouped into two categories:

    • Double-escaping issues (#2297711)

      Since Drupal already does its own sanitization at many different points, there are a number of places where we are unintentionally escaping markup twice, resulting in double-escaping bugs like:
      <em>My double-escaped string</em>

      When code uses the appropriate sanitization functions or the theme and render systems so that the output can can be themed, escaped, and altered properly, double-escaping is not an issue. So, we need to fix these regressions, ideally by removing the markup from the code entirely and converting to a Twig template, or failing that, by using the inline templating render element. In some cases these issues might be simple to fix; in others they will require some refactoring.

    • Improper uses of SafeMarkup::set() (#2297703)

      In order to inform the theme layer about what markup Drupal has already sanitized, strings that have been processed by t(), String::checkPlain() or Xss::filter() are automatically marked safe, as are markup strings created from render arrays via drupal_render(). This list of sanitized strings is stored by the SafeMarkup class, which is intended for internal use only. However, the initial conversion patch added SafeMarkup::set() calls in many places as an interim fix. We now need to remove as many of these improper uses of SafeMarkup as possible, by converting or refactoring the code in the same way that we would to fix double-escaping bugs.

    We will be sprinting on these issues at TCDrupal. Talk to YesCT or mdrummond for help getting started.

  4. Critical issue triage

    Once Drupal 8 is in beta, the next step will be to resolve the other critical issues that block a Drupal 8 release candidate. As a first step, we need to assess all of the critical issues to determine which are most important, which are no longer relevant, etc., as well as what the path to get each done is. In each critical, we should clearly identify:

    1. Why is it critical?
    2. What would be the implications of not fixing the issue?
    3. What would be the implications of fixing the issue between betas? (Code changed for modules, upgrade path, etc.)
    4. What would be the implications of fixing the issue after the first release candidate?
    5. What is the next step to make progress? What are the remaining tasks?

    Talk to xjm to help with this essential task.

If you're sprinting at TCDrupal, remember to put the TCDrupal 2014 issue tag on issues you work on at the sprint. Similarly, use the Drupalaton 2014 tag at Drupalaton. And whether you're sprinting in Minnesota, in Hungary, or remotely, join the #drupal-contribute IRC channel to coordinate with other sprinters.

Catégories: Elsewhere

Get Pantheon Blog: Headless Websites - Headless Drupal Options

Planet Drupal - jeu, 07/08/2014 - 19:44

This past week at Drupal Costa Rica, I had a nice conversation with Todd Ross Neinkerk of Four Kitchens, who was there presenting on the notion of de-coupling content management and content display (here's video of a similar talk he did in Austin). I also spoke with Jesus Olivias who recently did a great Spanish-language podcast with Omar Aguierre on the topic, and he was kind enough to give me his two cents.

Headless Drupal is officially now "a thing". It's all happening. If you're curious why this is exciting people, see my previous blog post on the topic: what's the big deal with headless websites? In this blog post I will dig into the technologies at your disposal for exploring Headless Drupal today.

Headless Drupal Now!

For those looking to develop Headless Drupal websites right now, you can totally do it with version 7. Even though there's excitement about the upcoming Drupal 8 release — and I'll detail the action below — you don't need to wait to get started with these techniques. Drupal 7 still has a long life ahead of it, and with the right contrib modules it is usable for anyone looking to build headless websites today.

The most well-known interface for Drupal 7 and an alternate front-end is the Services module, which has a very Drupal-ish manner (e.g. hook_services_alter()) of exposing various interfaces. It comes with built-in REST and XML-RPC interfaces, and allows you to expose, nodes, users, taxonomies and other core data fairly easily behind custom endpoints (API paths). You can also use it as a basis for specifying your own custom services.

There's also the restWS module, which exposes any Drupal entity on its existing URL based on headers. This module is the basis for Drupal 8's REST module, which we'll discuss more later.

Finally there's a really interesting package from the developers at Gizra, the Restful module, which is also entity-centric, but takes a different philosophical approach. Rather than exposing Drupal's internals, it allows developers to define what data they specifically want sent in response to a request. It also allows the exposure of some entity types and not others (e.g. the "Article" nodes, but not "Pages"). This module is definitely more developer-centric, but they have some nice blog posts about how they use it with AngularJS that will help you get up to speed.

The Future of Headless Drupal in Version 8

The future of Headless Drupal opens up significantly with version 8. Core includes both a REST interface module and a brand new routing system built on the Symphony2 HTTP kernel. This provides a lot of opportunity for headless implementations both for beginning and more advanced developers.

The REST module is a souped-up version of what you got from RestWS in Drupal 7. Your core entities are all eligible for exposure, using the JSON+HAL format by default. This gives consumers of entity data the ability to follow "links" to other data sources — for instance you can pull the definition of a content type from any node.

Making Drupal's native entity data model accessible to other apps via REST takes only a few clicks. Views — also in core for Drupal 8 — natively supports "REST export" as a type of display. You can configure your way to a robust REST API into your content without installing a single extra module.

For those looking for more specific or nuanced functionality, the core HTTP routing framework is one of the most exciting pieces. It's a general upgrade for how all Drupal modules handle requests, replacing the legendary hook_menu() with a fully-featured HTTP server. You can set up custom routes, define controllers for callbacks, and manage responses based on headers, status codes, and all the other things one cares about once you make the mental leap from "serving pages" to "talking HTTP" in your application.

For developers with experience building server-side applications in Python, Ruby on Rails, or Node, this is a welcome change. It opens the door to much more sophisticated implementations with Drupal — powering the backend for complex mobile applications, serving as a lightweight integration point for different kinds of data, even acting as a pure API to external application developers.

Much More To Come

There's still more to come. A big part of the equation is what's on the other side: now that we know how to build a headless backend in Drupal, what's the client? There are many exciting answers, which I'll address in another post, ideally with code samples for AngularJS, Backbone, and others.

There's also exciting movement in the headless direction in WordPress, where the WP-API project aims to have a native REST/JSON server bundled into the 4.1 or 4.2 releases later this/next year. I'll be doing a dive into the potential for those implementations soon as well.

Are you building headless applications? Do you have tips tricks or techniques to share? Let me know and let's spread the word!

Blog Categories: EngineeringRelated posts: Headless Websites: What's the big deal?WP REST API - A Superficial Review
Catégories: Elsewhere

tanay.co.in: FBIp - A lightweight module to automate form-submission based IP banning in Drupal

Planet Drupal - jeu, 07/08/2014 - 18:34

Drupal has a nice Internal tool to block IP addresses. It is available in core with no additional modules required. It can be accessed via Configuration -> People -> IP Address Blocking.

But it is practically useless without any automation to control spammers as it requires each IP to be manually submitted by the admin.

And there are the suite of modules available for Drupal. Ranging from captcha to mollom. And all of these target preventing form submission. While they do a good job in preventing the spammer from submitting forms on your site, the spam bots are still able to access your site/form.

And most of the times, there are some really dumb spam boths that do not bother whether they have been successful in the spam attempt. They do not realise that the same and they keep attempting to submit the same form repeatedly. While cpatcha, mollom, honeypot etc on your site are discarding these form submissions from bots, your site’s resources are being utilised to generate this form and show it again to the bots thousands of times.

And the worst part is that many of these form pages are not really cached allowing capcha etc to function properly. This makes the condition ever worse.

Have you ever wished there was a small module that just blocks a spammer completely after he either submits / attempts to submit a form a dozen times  times on your site?

So FBIP is here now!


  • It keeps a track of form submissions and if some user crosses a threshold that you specify, the user’s IP will be automatically blocked!

  • It is Leightweight. It does not add any additional tables to your site. It makes use of the Flood Control API available in the core of Drupal to keep a track of submissions per user.

  • You can choose between tracking either all forms on your site. Or specific form ids.

  • You can whitelist some IPs that you do not want to be tracked (Like your site administrators)

  • You can also choose to reset the IP bans at each cron run, if you wish to not to block any user permanently!

Beware Spammer, FBI(p) is watching you!

Catégories: Elsewhere

Advomatic: Design for Drupal 2014

Planet Drupal - jeu, 07/08/2014 - 18:15
My new (awesome!) coworker Sarah recapped her experiences at DrupalCampWI the other day, so I will follow suit with my thoughts from my new favorite tech camp, Design4Drupal, held in Boston last weekend. This camp is an intimate gathering for front-end developer and designers all experiencing the same pain points working with Drupal and on websites in general. On the surface, that meant things were a little less geeky and a lot more stylish, and digging deeper, there were many substantial, tangible lessons to take home.  

Home base was this magical Ghery building, the Stata Center, on the MIT campus.

The organizers of D4D made a conscious effort to gear the first day more toward business, and I relished the opportunity to think more about client communication.    I attended a great session on getting better client feedback, and you can read my favorite client communication tips here.   Another gem of the day was a detailed explanation of copyright and creative commons, and robust list of places to get open source fonts and stock imagery.    

Capped off Friday by dinner & drinks with the lovely women of DevCollab and Pixels&Pulp. Above is Cuchi Cuchi. This is without a doubt how I would decorate my house if I lived alone.

I started Day Two started a little bleary-eyed, but we jumped right into all the discussions I'd been itching to have, particularly about workflow.   The workflow for front-end development has skyrocketed in complexity over the last few years, and we front-end devs are welcoming anything we can do to improve the hand off from design to development and to streamline our work. You can read more about taking some of the headaches out of front-end work here.    The Responsive Javascript session was a good reminder to pause every time you think about jumping into writing some responsive Javascript. First, stop, and ask if it can be done better with CSS. Most likely, CSS will trump Javascript every time in terms of performance, accessibility and potential QA rabbit-holes.   And check out window.matchMedia() -- it's a simple way to check if you have hit different breakpoints. (Be sure to grab the polyfill for IE9 and below.)   Last, but not least, was the discussion on streamlining development and testing. We got an overview of Google's Web Starter Kit and all of it's goodies, like live reloading, synchronized browser testing, and a built-in, living style guide. And there was an audible gasp (from me) when they showed what browsersync.io could do; all devices on the network could look at the same local site, and when you scrolled down on one device THEY WOULD ALL SCROLL DOWN. Stunning.   The presentation was interesting, and the dev environment really parallels the dev environment we have home-brewed for ourselves here at Advomatic with a combination of Compass/Sass, Grunt, LiveReload, xip.io, and KSS. I quickly learned that there aren't many other shops doing this yet, so we couldn't talk the nitty gritty details (like gnarly compile times). So that conversation is to be continued.   I can't wait to hear next year how others are using these tools to improve their workflow.  

I ended my weekend drinking the best lemonade I will probably ever have, at Baraka Cafe just down the street from where I was staying. Photo credit: Nathan Cooke

Catégories: Elsewhere

Hideki Yamane: New Debian T-shirts (2014 summer)

Planet Debian - jeu, 07/08/2014 - 16:37
For these every 4 or 5 years, Jun Nogata made Debian T-shirts and today I got a 2014 summer version (thanks!  :-), looks good.

I'll take 2 or 3 Japanese Large-size one to DebConf14 in Portland. Please let me know if you want it.

Catégories: Elsewhere

Drupal Association News: From Poverty to Prosperity: How Drupal is Improving Lives in South Los Angeles

Planet Drupal - jeu, 07/08/2014 - 15:30

For many people all over the world, Drupal is a fun hobby or even a means to a career. But for some young men in South Los Angeles, it’s more than that: it’s a ticket to a better life.

Teens Exploring Technology is the brainchild of Oscar Menjivar, a social entrepreneur, programmer, and Drupal user. The program serves young men who are at risk of recruitment by gangs in Los Angeles’ southern neighborhoods by bringing them off the streets and educating them on community, leadership, academics, and technology.

Each year, thirty or more high-school boys are selected to participate in the program. Through it, they are introduced to computers and computing, and attend weekly classes held by the program and hosted in one of the classrooms at the University of Southern California (USC). Classes are instructed by volunteers who donate their time and expertise to the program, teaching the boys to improve their lives and their community through technological innovation.

“Currently, we partner with USC but we are starting to look at other universities for expansion” said Menjivar. “Our program is in demand and we need to expand. Right now, we’re building relationships with other universities, so in the next few years we’ll probably be meeting at USC and another university in the area."

The program, which is completely free for its students, has already made waves in its local community. Numerous alumni of Teens Exploring Technology are currently studying Computer Science and Information Systems at schools such as Stanford, Syracuse, USC, University of California Los Angeles (UCLA), and elsewhere; the projects that these students completed while participating in Teens Exploring Technology, meanwhile, are still doing good in their communities.

“Last year, one of the groups developed a Drupal website called South LA Run,” said Menjivar. "It’s an interactive map that displays safe places where people in south central LA can run. The site allows users to make accounts, and create and share routes with each other. Our students collected data and research from the community in South LA, then used it to build the site, which launched last summer.

"The project perfectly embodied our mission to help the kids recognize some of the problems in their communities, identify ways they can solve these problems, and give them the resources to solve those problems with technology,” Menjivar added.

Fighting poverty with technology

The program, which has won a Google Rise award, was inspired by Menjivar’s past.

"I grew up in South Los Angeles in the ‘90s and went to one of the worst high schools in the city,” said Menjivar. “They promised me a technology magnet program, but at the time we had nothing but typing classes. The lack of resources at my school made it harder for me to focus on bigger goals in life, like college.”

From a young age, Menjivar had been interested in computing and computer science. "I wanted to do computer science and learn how to code, and [my upbringing] was a huge barrier for me to overcome. Luckily, I had a good friend in college who took me under his wing.” Now, Menjivar is paying the favor forward by giving young men in rough neighborhoods the same help that he once received.

“Seven or eight years ago, I went back to my old high school and spoke to sixty kids. I asked if they knew what a website was, or knew what HTML was, and out of these kids only 5 of them knew what that meant. That was what opened my eyes,” he said. “I thought, there’s something that we need to do about this.”

For most young men who live in the inner cities, survival can be difficult. Many are recruited by gangs, or turn to crime to keep money coming in. "The biggest problem that I encountered with myself was that, in the '90s I had a lot of friends who… one ended up shot, another ended up in jail, and most didn’t go to college,” said Menjivar. "I was lucky because I had good mentors, but most of my friends didn’t have the same opportunity."

Now, Teens Exploring Technology is serving the neighborhood that Menjivar himself grew up in. The program focuses on educating young at-risk men about technology, inspiring them to use technology for social good, and instilling high-integrity values in the process. But Menjivar doesn’t want to stop there.

"The overall vision for what we’re doing is to develop leaders and change makers who can improve world through technology,” Menjivar said. “We want our students to go and use technology for good, and develop solutions for their communities. Our main focus is always on addressing problems in our students’ community, specifically how can we use technology to transform the lives of kids.”

Doing good with Drupal

In the Teens Exploring Technology program, the participants are introduced to a wide range of technologies— and Drupal is by far the most popular.

“We decided to use Drupal because it gives the kids a chance to learn on the spot and not have to wait for something to be pushed out,” Menjivar said. “They can practice their coding skills, and if they make a mistake they can redo it again easily in Drupal. The flexibility of it, the modules that the kids can play with, and the themes that Drupal can do all make it very popular. With kids, you have to be able to give them a choice for how to customize their website and make it their own, and Drupal does that really well.

“Last year, we had 8 different web apps and I would say 4 of them were Drupal-based. The other ones were Wordpress, Android, iPhone, and Shortstack, which is a Facebook app. This year we’re throwing in Unity, so the kids will be able to build games.

“Every year we experiment a lot but Drupal always stays at the core of what we do,” said Menjivar.

How Teens Exploring Technology is changing South Los Angeles

The pilot program for Teens Exploring Technology began five years ago.

“At first, we did recruiting,” said Menjivar. “We went out into the community and approached kids about participating in the program that first year, but it’s all word of mouth now. The kids call themselves TxTrs, and they really spread the word. It happens often that, in schools, an 8th or 9th grader will come to a current student and say 'I want to do this, how do I do this.’

“In the community, we feel that people are starting to recognize potential with technology. We had 150 applications this past year, and even though we were only able to pick 45 participants, we’ve created a database of kids who didn’t get in and their parents. We reach out to give them information whenever we can, and pretty soon we’ll have an open space that we’re opening up so that everyone can come, build with technology, and take workshops on different tools,” Menjivar added.

Helping at-risk young men build better lives for themselves and for their communities is at the heart of what Menjivar does— but he doesn’t plan to stop just with Teens Exploring Technology. Currently, the Teens Exploring Technology team is working to expand the program so that everyone in South Los Angeles has an opportunity to learn and grow.

“We’re about to open the first ever hacker/tech space in South LA where people in the community — not just boys but everyone else, girls, older people -- can come and learn how to develop and learn to make web apps,” Menjivar said. "We’re excited about it. We’ll be helping people learn about CSS, HTML, Javascript, and other different platforms. It's a huge step for us because we’ll be able to do summer programs with the boys in Teens Exploring Technology,” Menjivar added, “and then take those concepts over to our Hackerspace and encourage the community to initiate change through technology."

Menjivar’s vision for the Hackerspace isn’t one of a formal classroom, but rather a safe space for knowledge-sharing where people can help each other out-- or, in his words, “We want a ‘learn by doing’ space.”

“We want to build an organic community of technology culture so people can come in and do peer to peer teaching,” Menjivar said. “We want it to be a place where you can come hang out and have fun while learning to build online products. We aim to build culture of knowledge using the latest dev tools.”

“I find that the best way to build knowledge is together, instead of just doing workshops all the time,” Menjivar added.

“When we began setting the place up, picture a big mess right in the middle of the room: chairs everywhere and stucco and paint all over the place,” said Menjivar. “People came in and asked us what we were doing, and when we told them they could come and learn to develop, they got excited. In fact, as soon as we announced the Hackerspace to the community, we had tons of people coming in and asking how they could get involved.

“The community in South LA has a lot of talent, but it just isn’t being nurtured and fostered. So that’s what we want to do,” said Menjivar.

Getting Involved

Alumni of the Teens Exploring Technology program give back to the program by donating their expertise and recruiting for the community— but the program’s expansion means that more help is needed.

“Right now, we’ve got a summer leadership academy going on for boys who are between 14 and 17 years old,” said Menjivar. “We put the kids in production and development groups, and then everyone picks a different role: product developer, project manager, and so on. The boys go through process of identifying a problem and then using the technology to solve that problem, and to make this happen, we need mentors.

“Finding volunteers with exceptional skills is critical. We don’t just want people to volunteer, we want them to build relationships. Our volunteers become role models to the kids, become people they can look up to. Finding volunteers who can commit an hour to the program, and who are willing to stay in touch with the kids afterwards, can be a challenge.”

Beyond the need for more volunteers, resources are tight with the program. “getting funding is a challenge, especially since it’s a completely free program for the students,” said Menjivar. “Many of the boys we serve are from low income families, families whose annual income is about $15,000. In order for us to serve more students and provide new opportunities, we need to increase our income. This year we were invited to a startup weekend but we didn’t have transportation so going was difficult. Funding is definitely a challenge.”

“One of the questions we ask ourselves a lot is, how do we use this program to continue helping the Drupal community grow, and how do we get the Drupal community more involved in the future? One thing that would help would be sponsorship from companies for the program and for its volunteers.

“Our summer volunteers put in 20-25 hours a week helping the boys, and do so for no pay. Right now we’re looking for people or companies who can sponsor those volunteers, and maybe even give them a stipend,” said Menjivar.

"Currently, the culture of creating technology doesn’t exist in South L.A., so we’re building that technical dream and people are recognizing that. We’ve become the place where, if you want to learn to build or create, you go to Teens Exploring Technology or you go to Hackerspace. It’s a small space but I’m looking forward to seeing what comes out of it,” said Menjivar.

"Above all, the emphasis for me is our pillars of community, leadership, academics, and technology, because that’s what we anchor ourselves around. We want to help our kids understand how those pillars change the world, and really understand the technology that will make a difference in their lives and the lives of others as they become a developer."

For more information on the program, or to get involved, please contact the Teens Exploring Technology team, or reach out to Oscar Menjivar via Twitter at @urbantxt.

Catégories: Elsewhere

Forum One: The Road to Drupalaton

Planet Drupal - jeu, 07/08/2014 - 15:07

We arrived in beautiful Budapest on Tuesday night already excited for Drupalaton, Hungary’s premier annual Drupal event which takes place at the town of Keszthely on Lake Balaton (from which the event gets its name).

Yesterday morning we met up with our friends at the Cheppers office, and loaded our bags into the cars to caravan down. Cheppers is one of the major sponsors for Drupalaton, and a good example of the new breed of Drupal shops coming out of Eastern Europe. Incidentally they also happen to be a fantastic road trip crew.

On the way down we talked about what we all hoped to get out of the big Drupal event. Personally I’m looking forward to a couple of uninterrupted days of contributing to Drupal 8. In a regular work week it’s hard to get this much time for contribution all at once, and it will be great to feel like I’m making a dent in the issue queue. Adam Juran, one of our Interface Engineers, talked about the friends we’d get to see and the “community track” of discussing code over a beer, which seems particularly appealing given the dearth of local lakeside restaurants. We’re seriously considering extending that idea by hosting an unofficial Forum One code sprint on the beach!

Drupalaton promises to be a fantastic conference. These local Drupal events are one of the few places where you can rub shoulders with well-known contributors and local first-timers all at once. Most of these European Drupal camps are fairly intimate gatherings of only about a hundred participants, which means that everyone eats, codes, and hangs out in just one or two big groups. Not to mention, these events are much lower pressure than the larger Drupalcons for everyone involved. People are often running through their presentations for the first time, and very few of them have other project or marketing work to distract them. This means that everyone is there for the same reasons: to code, to learn, and to have fun!

Sure to be one of the highlights of the event program is my three-hour workshop: Coder vs. Themer: Ultimate Grudge Smackdown Fight to the Death! with my colleague Adam Juran. Adam, using only the theme layer, and I, using only the module layer, will compete and invite our audience to do the same to determine who is able to build the better Drupal website: Coder or Themer?! We’ve had a lot of fun with this session in the past and it’s sure to be a popular one among the Drupalaton crowd.

This conference will also include well known Drupal contributors like Morten DK, Wim Leers, Dan Wehner, Reuben Teijieroand of course Gabor Hojtsy. Big names in the community like Stephanie El Hajj and Steve Purkiss will be there too, alongside some of our favorite local Drupal organizers like Lauri Eskola and Zsofi Major. A lot of these people are old friends for us – but whom we often only see on the Drupal.org issue queues – so it’s a special treat to hang out in person, even if we essentially have the same conversations. As for the people we don’t yet know: it will be great to code, session, and enjoy some tasty Hungarian Palinka with them as well!

Drupalaton will also feature some of the best of the local Hungarian community, in a beautiful lakeside setting. At Forum One we talk a lot about the value of local engagement with open source products like Drupal, and it’s very rewarding to be a part of that core value in action. Hungarian Drupalists are some of the most talented – not to mention friendly! – in the European community. We’ll definitely post more when the con gets started!

Catégories: Elsewhere

Dirk Eddelbuettel: Rcpp now used by 250 CRAN packages

Planet Debian - jeu, 07/08/2014 - 14:03

Rcpp reached a nice round milestone yesterday: 250 packages on CRAN now depend on it (as measured by Depends, Imports and LinkingTo declarations).

The graph is on the left depicts the growth of Rcpp over time. Or at least since I started to write down some usage numbers: first informally, then via a script.

Also displayed is the relative proportion of CRAN packages using it. Rcpp cleared the four per-cent hurdle just before useR! 2014 where I showed a similar graph (as two distinct graphs) in my invited talk.

250 is a pretty impressive, and rather humbling, number.

From everybody behind Rcpp, I would like to say a heartfelt Thank You! to all the users and of course contributors.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Catégories: Elsewhere

Craig Small: WordPress 3.9.2 for Debian

Planet Debian - jeu, 07/08/2014 - 10:43

WordPress released today a security release 3.9.2 which they fix several security issues, including a denial of service issue around XML.  The corresponding Debian package 3.9.2+dfsg-1 is currently being uploaded to the Debian ftp-master server as I write this and should be available on the mirrors soon.

Unfortunately at the time of writing, there are no CVE identifiers to match these problems up with, but refer to the wordpress page for details about these bugs.

Andrew Nacin from WordPress has kindly outlined what versions are susceptible and it looks like the Debian squeeze (3.6.1+dfsg-1~deb6u4)  and wheezy (3.6.1+dfsg-1~deb7u3) are vulnerable to at least some of these bugs which means for me its patch reading and back-porting time


Related articles
Catégories: Elsewhere

Code Karate: Embed Panel Node View in code

Planet Drupal - jeu, 07/08/2014 - 03:48
There are times when you want to programmatically embed a node display in a block or panel pane.
Catégories: Elsewhere

Ian Donnelly: How-To: Write a Plug-In (Part 2, The Contract)

Planet Debian - jeu, 07/08/2014 - 02:14

Hi Everybody!

This is the second installment of my tutorial, How-To: Write a Plug-In. Previously, in Part 1, I went over the basic interface of an Elektra Storage Plug-In. For this installment, I will be focusing on one of the most important aspects of a plug-in, its contract.

The contract describes how a plug-in may behave. The main part of the contract describes to Elektra how it will modify the KeySet returned. This is what allows Elektra to work with various types of plug-ins. This guide will focus on one type of plug-in: the storage plug-in.

We already have a published specification for plug-ins on our repository but I will reiterate the details here. The first part of the contract you will need is the system/elektra/modules/plugin (where plugin represents the name of your plug-in). All this key does is let elektra know that your plug-in exists. The next key is system/elektra/modules/plugin/exports. This key lets Elektra know that your plug-in exports symbols to Elektra. Below this key you need to create keys for each function you want to export, in my line plug-in I implemented functions for get and set so I will create two keys as follows:
keyNew ("system/elektra/modules/line/exports/get",
KEY_FUNC, elektraLineGet, KEY_END),
keyNew ("system/elektra/modules/line/exports/set",
KEY_FUNC, elektraLineSet, KEY_END),
So far we have told Elektra that our plugin exists and will be exporting functions for getting and setting keys.

The next set of keys are the system/elektra/Plugin/infos keys. These are pretty self-explanatory. The first three children of this key, author, license, and description are pretty self explanatory. The infos/provides key tells Elektra the type of plug-in that is being used, this will be “storage” for any storage plug-in (which is what this tutorial focuses on). To be precise, it tells Elektra which abstract functionality is provided. This allows other plugins to reference abstract functionality instead of declaring a hard dependency to one specific plugin. For example plugins could state that they want to be placed before any other plugin doing the abstract functionality “conversion” instead of referencing for example the keytometa plugin directly.

The info/placements key tells Elektra which functions of the plug-in it should call. Since I implemented get and set in the line plug-in, I would set this key to “getstorage setstorage”. Next is infos/needs and infos/recommends, infos/needs should contain a list of plug-ins or providers that your plug-in needs to work (see the info/provides key above). Otherwise this key needs to be set to be blank “”. infos/recommends works exactly like needs except that a plug-in that needs another plug-in won’t form a valid backend if the other plug-in doesn’t exist but if it only recommends having the other plug-in, it will still work in the others absence.

Since Elektra 0.8.7, the best practice for creating a plug-in involves storing the info keys at the very top of a file named REAMDE.md in the same directory as the plugin source. For instance, in my line plugin, the first few lines of README.md are as follows:
- infos = Information about LINE plugin is in keys below
- infos/author = Ian Donnelly <ian.s.donnelly@gmail.com>
- infos/licence = BSD
- infos/needs =
- infos/provides = storage
- infos/placements = getstorage setstorage
- infos/description = Very simple storage plug-in which stores each line from a file as a key

The rest of the README.md file should contain an English description of the plug-in. You can include an introduction to the plug-in, its purpose, any shortcomings it may have, and examples of how to use it. This README.md file is standard for GitHub which will automatically be displayed when a user is browsing your plug-in’s directory in the repo. It is written in Markdown.

In order to generate the contract from this file you must edit the CMakeLists.txt file in your plug-in source directory to include the following lines:
generate_readme (plugin)
add_includes (elektra-full ${CMAKE_CURRENT_BINARY_DIR})
include_directories (${CMAKE_CURRENT_BINARY_DIR})
where you substitute plugin with the name of you plugin. This will generate a file called readme_plugin.c (once again, substitute plugin), in your plugin’s build directory when you run the make command.

The best way to declare the contract is within it’s own function, elektraPluginContract. This makes it easier to manage the contract and is much more readable. This is the contract declaration for my line plug-in:

static inline KeySet *elektraLineContract()
return ksNew (30,
keyNew ("system/elektra/modules/line",
KEY_VALUE, "line plugin waits for your orders", KEY_END),
keyNew ("system/elektra/modules/line/exports", KEY_END),
keyNew ("system/elektra/modules/line/exports/get",
KEY_FUNC, elektraLineGet, KEY_END),
keyNew ("system/elektra/modules/line/exports/set",
KEY_FUNC, elektraLineSet, KEY_END),
#include "readme_line.c"
keyNew ("system/elektra/modules/line/infos/version",

Next, you will need to make sure to actually set the contract. This is always done in the elektraPluginGet function since this is technically the only REQUIRED function in a plug-in. We just create a new KeySet, set it to our contract, and append it to the returned KeySet. You can see how this is done for line (note that this code is at the very beginning of elektraLineGet):

if (!strcmp (keyName(parentKey), "system/elektra/modules/line"))
KeySet *moduleConfig = elektraLineContract();
ksAppend(returned, moduleConfig);
return 1;

Note that the plugin contract is nothing special, but just a KeySet interpreted by the resolver forming an Elektra backend. Elektra will request the keys below system/elektra/modules/plugin (where plugin is the pluginname) as soon as it wants to know something about that plugin.

Notice also the line #include "readme_line.c". This line, pulls in the contents of readme_line.c in my plug-in’s build directory, which due to the lines we added in CMakeLists.txt will contain the contract as defined at the top of README.md. Any changes to the keys in README.md will be reflected in the plug-in next time it is built.

Part 2 of this tutorial focuses on the plug-in contract by explaining what each element does and explaining how to implement a contract.  For more information about plug-ins and more detailed examples I highly suggest reading Markus’ Thesis for Elektra. Chapter 4, which starts on page 61 goes into much more detail on Plug-Ins and explains the various features of the contracts. Look for Part 3 soon!

Catégories: Elsewhere

Drupal core announcements: This Month in Drupal Documentation

Planet Drupal - jeu, 07/08/2014 - 01:08

Here's an update from the Documentation Working Group (DocWG) on what has been happening in Drupal Documentation in the last month or so. Sorry... because this is posted in the Core group as well as Documentation, comments are disabled.

If you have comments or suggestions, please see the DocWG home page for how to contact us. Thanks!

Thanks for contributing!

Since July 1st (our previous TMIDD post), 260 contributors have made 800 total Drupal.org documentation page revisions, including 5 people that made more than 20 edits (gisle, lolandese, YesCT, adellefrank, and mparker17) -- thanks everyone!

In addition, there were many many commits to Drupal Core and contributed projects that improved documentation -- these are hard to count, because many commits combine code and documentation -- but they are greatly appreciated too!

Documentation Priorities

The Current documentation priorities page is always a good place to look to figure out what to work on, and has been updated recently.

If you're new to contributing to documentation, these projects may seem a bit overwhelming -- so why not try out a New contributor task to get started?

Upcoming Events Report from the Working Group
  • We finally finished our deliberations, and decided on our priorities for documentation-related software/infrastructure. These priorities were submitted to the Software Working Group, and are also listed on https://www.drupal.org/governance/docwg-goals. Ideas we considered but decided were not priorities for the next year are listed on https://www.drupal.org/node/2258139.
  • We are preparing for the sprints at DrupalCon Amsterdam (29 Sept.-3 Oct.) by updating and prioritising documentation issues. We'll be using documentation issue tag "docsprint" to tag issues that we think will be good for sprints, over the next two months especially.
  • After an initial period of setting ourselves up, we are now happy to open up the monthly meeting of the Documentation Working Group to anyone who would like to attend. Please contact Boris (batigolix) if you want to join the meeting and send hit the email address you use for Google, since we meet in Google Hangout.
Catégories: Elsewhere

Julian Andres Klode: Configuring an OpenWRT Router as a repeater for a FRITZ!Box with working Multicast

Planet Debian - jeu, 07/08/2014 - 01:01

Since some time, those crappy Fritz!Box devices do not support WDS anymore, but rather a proprietary solution created by AVM. Now what happens if you have devices in another room that need/want wired access (like TVs, Playstations) or if you want to extend the range of your network? Buying another Fritz!Box is not very cost efficient – What I did was to buy a cheap TP-Link TL-WR841N (can be bought for 18 euros) and installed OpenWRT on it. Here’s how I configured it to act as a WiFi bridge.

Basic overview: You configure OpenWRT into station mode (that is, as a WiFi client) and use relayd to relay between the WiFi network and your local network. You also need igmpproxy to proxy multicast packages between those networks, other UPnP stuff won’t work.

I did this on the recent Barrier Braker RC2. It should work on older versions as well, but I cannot promise it (I did not get igmpproxy to work in Attitude Adjustment, but that was probably my fault).

Note: I don’t know if it works with IPv6, I only use IPv4.

You might want to re-start (or start) services after the steps, or reboot the router afterwards.

Configuring WiFi connection to the FRITZ!Box

Add to: /etc/config/network

config interface 'wwan' option proto 'dhcp'

(you can use any other name you want instead of wwan, and a static IP. This will be your uplink to the Fritz!Box)

Replace wifi-iface in: /etc/config/wireless:

config wifi-iface option device 'radio0' option mode 'sta' option ssid 'FRITZ!Box 7270' option encryption 'psk2' option key 'PASSWORD' option network 'wwan'

(adjust values as needed for your network)

Setting up the pseudo-bridge

First, add wwan to the list of networks in the lan zone in the firewall. Then add a forward rule for the lan network (not sure if needed). Afterwards, configure a new stabridge network and disable the built-in DHCP server.

Diff for /etc/config/firewall

@@ -10,2 +10,3 @@ config zone list network 'lan' + list network 'wwan' option input 'ACCEPT' @@ -28,2 +29,7 @@ config forwarding +# Not sure if actually needed +config forwarding + option src 'lan' + option dest 'lan' + config rule

Add to /etc/config/network

config interface 'stabridge' option proto 'relay' option network 'lan wwan' option ipaddr ''

(Replace with the IP address your OpenWRT router was given by the Fritz!Box on wlan0)

Also make sure to ignore dhcp on the lan interface, as the DHCP server of the FRITZ!Box will be used:

Diff for /etc/config/dhcp

@@ -24,2 +24,3 @@ config dhcp 'lan' option ra 'server' + option ignore '1'

Proxying multicast packages

For proxying multicast packages, we need to install igmpproxy and configure it:

Add to: /etc/config/firewall

# Configuration for igmpproxy config rule option src lan option proto igmp option target ACCEPT config rule option src lan option proto udp option dest lan option target ACCEPT

(OpenWRT wiki gives a different 2nd rule now, but this is the one I currently use)

Replace /etc/config/igmpproxy with:

config igmpproxy option quickleave 1 config phyint option network wwan option direction upstream list altnet config phyint option network lan option direction downstream list altnet

(Assuming Fritz!Box uses the network)

Don’t forget to enable the igmpproxy script:

# /etc/init.d/igmpproxy enable

Optional: Repeat the WiFi signal

If you want to repeat your WiFi signal, all you need to do is add a second wifi-iface to your /etc/config/wireless.

config wifi-iface option device 'radio0' option mode 'ap' option network 'lan' option encryption 'psk2+tkip+ccmp' option key 'PASSWORD' option ssid 'YourForwardingSSID'

Known Issues

If I was connected via WiFi to the OpenWRT AP and switch to the FRITZ!Box AP, I cannot connect to the OpenWRT router for some time.

The igmpproxy tool writes to the log about changing routes.

Future Work

I’ll try to get the FRITZ!Box replaced by something that runs OpenWRT as well, and then use OpenWRT’s WDS support for repeating; because the FRITZ!Box 7270v2 is largely crap – loading a page in its web frontend takes 5 (idle) – 20 seconds (1 download), and it’s WiFi speed is limited to about 20 Mbit/s in WiFi-n mode (2.4 GHz (or 5 GHz, does not matter), 40 MHz channel). It seems the 7270 has a really slow CPU.

Filed under: OpenWRT
Catégories: Elsewhere

Janez Urevc: Drupal 8 from my media perspective - update #1

Planet Drupal - mer, 06/08/2014 - 23:15

Media team is very active. Purpose of this post is to provide the progress update to the rest of the community that might not be aware of everything that is going on in this field. I am planning to publish this posts on a regular basis. We'll see how it goes :).

Media sprint in Zurich

We had a very productive sprint about a week ago in Zurich were we've worked on various core and contrib issues (see below of details). Sprint was organized by MD-Systems. They did their best to bring everyone togehter and made sure that we felt comfortable and welocome. Thank you so much (special thanks go to @miro_dieteker and @Berdir)!


In Zurich @blueminds fixed [#2078473] Use entity access API for checking access to private files.

We are currently focusing on few issues:

Catégories: Elsewhere

Acquia: Don’t wait, update your codebase now!

Planet Drupal - mer, 06/08/2014 - 20:34

TL;DR: a security update for Drupal 7 and Drupal 6 was just released. All sites are affected and sites that are not updated immediately may experience Denial of Service (DoS) attacks leading to unexpected downtime.

Update: This vulnerability was covered on Mashable and one of the reporters published a detailed full disclosure of the vulnerability.

Catégories: Elsewhere


Subscribe to jfhovinne agrégateur - Elsewhere