I was asked to speak at this year's Career Day at our local high school, and thought it would be an awesome opportunity to skew the vision of young minds towards the possibilities that a work life in web design / development can offer. I did a similar talk a couple years ago at the last career day, and realized that in order to keep these guys from drifting off I had to make a concerted effort to break the third wall.

So, I put together this presentation that basically converts the room into a web development firm and introduces the multiple roles you can take on, all the while building out a spec for a popular web site clone (MySpace was the choice each time). I was really impressed with the kids' willingness to participate, and heard it went over pretty well.

Why you would watch this

I'm posting this video just in case folks out there are called upon to give similar presentations to one of the toughest audiences out there - the significantly-younger-than-you kind. The structure I used is low tech, brings the kids in for approachable tasks, and assigns roles to them based on what skills they see in themselves. I figured that if I could get them to connect what they consider their assets to a job title, it would have a greater chance of sticking in their minds, and when they get to the point of genuinely considering careers, they have at least a starting point. But, who knows, it was at least fun and allowed me to test out some ideas on how to make a presentation more compelling for a younger audience.

Stuff that worked well:

  • I started by asking for a volunteer to videotape the presentation. This insured that at least one student was going to be involved the whole time, and they were indeed the ones that asked the most questions. Plus, it also established a level of trust and broke that third wall immediately.
  • I asked the students what they were good at, and assigned them positions based on that. The idea was to give them a feeling like their positive qualities could have an impact on the roles they play down the road.
  • I gave them name tags and spoke to or about them when describing the position, making it less abstract. Also, if they kept the name tags on, I thought other kids might ask them about it and they'd have to articulate at least something that they learned during the talk.
  • I kept it low-tech, using just a white board. Doing this meant less technical overhead, and maybe making the whole idea more approachable, that you didn't need fancy tools to get a lot of the work done.
  • I practiced maybe 4 or 5 times while jogging to make sure I could fit everything into a half hour. I had to cut a bunch of stuff and really streamline the process to get this to work.

It's a horrendously long blog title, I know, but I wanted to mash in all the keywords I was looking for when trying to find a solution to this very sticky problem so that other folks running into the same issue can spend the next six hours doing something more productive.

jQuery makes grabbing one group of elements from a page, duplicating them and adding them somewhere else really easy. You just use a combination of clone() and something like append(), as in the following:


The problem with dynamically adding form elements in IE

Woot! So easy! Right, until you start goofing with forms and IE (Internet Explorer) (appropriate sound). The problem is that IE doesn't allow you to manipulate the 'name' attribute in the DOM directly. So, something like this won't work:

$('#form_element').clone().attr('name', 'new-name').appendTo('#my-form);

If you do that with a radio button, the interface will tell you that there's a problem, because since the new radio button has the same name as the original one, only one can be selected. Bugger!

Luckily, the solution is clear, but it took forever to figure it out. Instead of adjusting the name attribute directly with something like attr(), you need to edit it manually in a block of html and then add that html to the page. So, something like this would work:

replace(/orignal_name/, 'new_name').appendTo('#my-form');

There's a couple of key points here:

  1. Because we're getting the html using $.html(), we need to move up the DOM to grab the element surrounding the element we wish to add using $.parent(), then we can grab the html using $.html().
  2. I'm using the javascript replace() function to pass a regex pattern and replacement text to the html.

What about dynamically cloning groups of inputs with jQuery?

In my particular use case, I was grabbing a set of form elements and adding them this way. There were a couple of challenges, which was that I couldn't use $.parent() to get the outer element, and the other was that the names of the form elements were being set dynamically. I learned a couple of tricks to help with this:

Use the regex modifier /g to replace all insteances of a pattern. So, when doing replace(), if I needed to replace ALL instances instead of just one, it would look like this:

replace(/original_name/g, 'new_name')

Because I couldn't use $.parent(), in the end I had to wrap an element around the html using simple contatination, like so:

var newHTML = '<div>' + $('#element').html() + '</div>';

I hope that helps you, it was sure a bugger to figure out.

I'm going to be doing a talk in a couple of weeks called "10 reasons why Drupal (might) kick your CMS's a**" to a local group of web tech folks, only a couple of which use Drupal. I have some ideas, but wanted to crowdsource this a bit and see if I can get some input from the community. I have a very limited exposure to other popular CMS's, so any input on comparing and contrasting Jooma, Wordpress and Drupal would be appreciated. Also, any nifty graphs or diagrams that might hit the points home? So far, here are some items on my list:

  • Caching - The various caching tools enable Drupal to perform nearly as fast as static HTML
  • Community - Lots of IRC participation, local user groups, positive leadership
  • No forking - The community hasn't yet reached the point where a schism caused forking.
  • Central module repository - This has meant that all projects are supported in similar ways (version control, issue queues, etc) and that they are GPL compliant. Also, this adds exposure for the modules and they get vetted by the community.
  • Drupal is a programming framework plus a CMS - Drupal does a lot of heavy lifting, and helps you organize your code in a meaningful way other folks can plg into.
  • Drupal modules don't have to hack core to work - As opposed to other CMSs
  • Drupal scales well - And this will only get better with Drupal 7 and the new database layer
  • Drupal is mature - It's been around a while, it's stable and is being supported by a lot of big projects (need some good diagrams here)
  • Extendable data structures (i.e. fields in core) - Makes all data flexible at the interface level

I'd love to have some good visuals for this, and I'd also like to get some ideas on what I might be missing. I will gladly open source this presentation as well once it's complete.



Several months ago I managed to grab some tickets to Ignite Boise 2 from a friend. It was the most fun I've had watching a live performance in a while. Half of it was the fast-paced, multi-faceted topics and presenters, and the other half was a jam-packed room full of slightly inebriated, vocal participants. It felt like there was no third wall, and that it was more of a sport than a sit-on-your-hands-and-listen gig. So, as my family eagerly awaits the availability of tickets (attendance is free, but you can get tickets to get in early), I decided to go ahead and submit a talk for Ignite Boise 3 in November. I've been on this planet for a while now, and I've gathered enough interesting techniques for getting the most out of living to fill a 5-minute slot.

Life is short, we should be spending more of it doing what makes us happy!

And this talk will summarize just about everything I've learned about how to do just that. In Extreme Productivity, I hope to introduce the uninitiated into a slew of techniques for increasing enthusiasm (the very core of productive living), outline a mindset that attracts opportunity, and lay down some principles - many backed by scientific research - that will help you get more done in the limited waking hours of our life (and maybe even the non-waking ones!). Here's the one-minute bullet-pointed run down of some of the topics I'll be covering:

  • How to fit more in your head without a lobotomy
  • Increase your waking
  • How to make work suck way less
  • The myth of multi-tasking
  • Introducing multi-purposing
  • The body is a truffle - How to use your body to please your mind
  • How the people around you affect your attitude (and how you can affect their affect on you)

200908131139.jpgIt recently came to my attention that there are some gaps in my conceptualization of Drupal security. I was fortunate enough to have this pointed out to me by the Drupal Security Team, and not by a DOS, CSFR, SQL injection or XSS attack. After publicly bemoaning the mild lashing I received, four members of the Drupal community suggested I read Cracking Drupal. One of them even sent me a copy. No other book was even mentioned, which says to me that - considering how recently it was released - the book fills a void of knowledge that was seriously aching for coverage, and fills it well.

Over years of developing, I've become familiar with the various vulnerabilities that make their way into code, but I've never felt like I could build a complete defense. My knowledge has been piecemeal, drawing from documentation, books, interesting conversations and other people's code. In my case, Cracking Drupal did a fantastic job of gluing these pieces together into a comprehensive frame of mind.

What becomes clear very quickly in Cracking Drupal is that Drupal is quite a wily beast that gives developers real incentive to learn security. There are few functions in Drupal whose exclusive purpose is security, and Greg makes it clear that learning how to secure your site has definite side benefits: "When developers learn and use the API, they are not only safer but more effective and more efficient." When you learn how to use different aspects of the Drupal API (forms, translations, helper functions, theming) you gain bits of security as a bonus. If you set out to learn Drupal security, you'll come out the other end with a pretty solid grasp of Drupal APIs. Either way, it's a win.

Cracking Drupal is surprisingly brief. In 134 pages, Greg covers a lot of ground including:

  • An overview of the different types of attacks one is likely to encounter, from physical to social
  • Most (if not all) aspects of the Drupal API that have security implications
  • Coverage of security-related contributed modules
  • An introduction to the Drupal Security Team
  • Demonstrations of exploiting common weaknesses in Drupal modules and how to fix them

An interesting choice is made in Cracking Drupal to keep a somber atmosphere around the subject matter. In almost any other context, this would be an immediate turn-off. I appreciate humor and optimism to drive my enthusiasm when reading. In contrast with other instructional books which end a chapter with a "go for it, get things done!" message, this book ends chapters with lines like "This paranoid perspective is a good one to maintain as you write, review, and implement features on your site." and "Remember that it is nearly impossible to fully protect yourself from a dedicated and persistent attack." and "If nothing else, I hope this chapter has scared you a bit about the realities of just how easy it is to exploit insecure code and sites".

In a book covering attacks that can result in a very serious loss of time and money, this lack of optimism is probably a good thing. And the final chapter, "Un-cracking Drupal" does leave the reader with the sense that something can be done. It's difficult work, but it's doable. Ultimately, I think the book drives home the fact that the most effective way to make a module or theme secure is to do it right from the start.

The title chapter of Cracking Drupal was probably the most lively and hands-on part of the book. I came out of it feeling like I could really enjoy exploiting vulnerabilities for the greater good. Because of this reaction, I think it would have been a good candidate for a first chapter to really whet people's appetites.

Overall, I think Cracking Drupal does a tremendous service to the community by pulling together the most important aspects of Drupal Security into one solid, compact document. While I came into the book having already been introduced to many of the concepts, it filled in a few gaps, and made the subject matter finite and approachable (albeit a little scary). I suspect this book will serve well as a guide and quick reference as I dive into identifying and patching up vulnerabilities in the modules I maintain.

A couple things I learned

While the greatest benefit to this book was the broad, sweeping overview of security, there were a few additional gems that will come in handy later on:

  • There's a lot more to hook_menu() than I was aware of. Good coverage of examples on p.55
  • I didn't realize that you had to exit after using drupal_access_denied(). p.59
  • Ah, db_placeholders() - a useful function for passing a number of variables to db_query() p.65
  • I had no idea there was such a robust node access API. Wow!

Notes in the margin

Below are a few unorganized comments that constitute my wish-list for future versions and complements to the author:

  • Good quote regarding the definition of security: "For this book I’ll define site security as follows: A site is secure if private data is kept private, the site cannot be forced offline or into a degraded mode by a remote visitor, the site resources are used only for their intended purposes, and the site content can be edited only by appropriate users."
  • I would have liked to see more AJAX security strategies and techniques covered.
  • I liked all the Drupal 7 references, gives a good feel as to the direction of things
  • I was surprised that there were not more brutal admonitions about hacking core, but suspect that's because they represent much fewer vulnerabilities than badly designed contrib.
  • I was happy to see some coverage of CVS and DRUSH, namely using CVS to keep code up-to-date
  • Nice coverage of security-related modules starting around p.41
  • A brief mention is made that using mixed-mode SSL is pretty pointless. This is a big deal, I wish it had gotten further coverage.
  • Being more of an optimist, I appreciated this particular phrase: " Every day there are more and more techniques beingdeveloped to attack sites, but every day there are also Drupal users reviewing code and providing new modules and enhancements to core to keep your site safe." Ahh, a glimmer of hope!
  • Would have liked to see more coverage on the use of form tokens. If one must step outside of the forms api, this could be very important
  • I liked that theme safety was covered, and thought the take on it was interesting: Make the theme secure by giving themers no reason to make stupid mistakes.
  • Since the 'Vulnerable' module was patched up in the end, maybe it should actually be named to indicate that it's meant to be a useful module. That would feel more like a practical example.

I've spent a good bit of time the last couple of weeks getting my thoughts straight for a session I may present at DrupalCamp Colorado called "Plugging into the Drupal community - Essential tools". The process of formulating my thoughts regarding my experiences with the Drupal community and what the project is all about has been a really good one. As a friend pointed out the other day, I'm more of verbal guy, so I've been thinking / practicing out loud and jotting down good thoughts when they come out. I remember David Byrne once saying that he writes music in a similar way.

The idea of the session is to help atendees wrap their mind around the social channels used by the Drupal community so they can get plugged in quick. Not just the technological aspects, but also the cultural implications of how the community uses them. I've been involved with the community on some level for a couple years now, and in hindsight I think my climb up the Drupal learning curve would have been greatly accelerated if I had gotten plugged in to the community earlier. Drupal is really a social solution to a technical problem, not the other way around, and realizing that can have a positive impact on the speed of learning and the ability to make a meaningful contribution.

Based on the voting so far, the session is lagging behind a bunch of other great-looking sessions - probably the material I'm covering seems too basic for the typical DrupalCamp crew. But I think I like the idea of putting a session out there, regardless of if it gets presented, just for the nudge to get some ideas in order. If I end up not presenting, that's just one more session I can either attend or skip out on to rub real elbows with some virtual friends.

Syndicate content