In case you haven't heard the news, Shomeya is on Hiatus for a bit. Mike is working full time at Puppet Labs, and I've been busy having daughter #3 this year. We're still open for a few hours here and there, but it's mostly been a year of reflection.
It'd be great if the code we write and work with only needed to live in our editor, but in reality we need to share it unexpected ways all the time. Reports, presentations, and emails are all places where from time to time you need to share some code, and wouldn't it be nice if it was syntax highlighted?
Well if you're on a Mac here's a simple screencast that shows you how to do this.
We've all had clients we love to hate. You know, the client that eats into your bank account, your sleep, and drives you nuts via the modern torture device of email. They are NEVER happy, don't seem to know what they want, never give you the right content, and can't understand why you can't just make a $1.5mil project for $25,000.
It's easy to vent and blame it all on the client, but how do you know that the failed relationship is all on the client? In my experience there are two main reasons that client relationships don't work out, and both are preventable as a web consultant if you pay attention and prepare ahead of time.
If you think back, you can probably remember that moment. The proverbial light bulb clicks on and a smile forms that won't go away, even though you're just staring at the computer screen. Everything finally clicks into place and the power of Drupal unmasks in front of you.
Most Drupal developers I know have had a moment like this after learning about Content Construction Kit (CCK) and Views. A new way of working with the web is unfurled and hard problems seem simple. In no time at all, every feature request and user story is filtered through the lens of the tools and hand.
Why you need to design your API
Everything seems simple enough at first, but after a few more iterations you've implemented custom validations via hook_node_validate and you're saving custom data via hook_node_update and hook_node_insert which ends up loading in hook_node_load. Since the code started out simple enough, you never bothered to design an API to the feature, just using node_load() and other functions to access your data. Before you know it you're trying to explain to a frustrated co-worker where the scattered code lives and what queries to copy so they can load the correct data set since there is no API function that provides the desired functionality.
What happened to the joy of that light bulb moment?
One of my favorite all time quotes comes from Dale Carnegie demonstrating a human response to a form letter in How to Win Friends and Influence People: "You desire! You desire. You unmitigated ass. I’m not interested in what you desire or what the President of the United States desires. Let me tell you once and for all that I am interested in what I desire— and you haven’t said a word about that yet in this absurd letter of yours."
If you're building sites that only satisfy your clients, but not their users it's time to rethink things. Clients need to know how to take the care they give their customers in the real world and translate that into their web existence. You as their developer can see their site, the analytics, and how their users interact with it. What a powerful opportunity to actually help your client's grow and build amazing things! It's so easy to leave those decisions to the marketing department with little or no web experience, but a site that is self-focused doesn't make the world a better place.
Drupal distributions are often like manufactured homes. They're easy to get up and working, they come pre-made with a variety of features. By all appearances they meet all your needs, and maybe even then some. But just like manufactured homes you often don't know how difficult it is to remodel them until you try to run pipe through the walls or refinish the cabinets.
Whether you are a client trying to save your company money, or just a consultant trying to give your clients a better bang for their buck a distribution can be a tempting solution. The ability to change colors and layout with just a click and a scroll is so much easier! Before you download and start clicking your way around, there are somethings you need to be aware of.
When you go to the salon what are you buying? Shorter hair? A different color, look? Why? What is it that you are really getting when you get your haircut? Conformity? You won't stand out at the next meetup, or maybe it's the opposite, you want to stand out more?
What you are buying is not a haircut, you are buying a statement about who you are. How well your stylist understands you and knows how to make your hair 'behave' is essential to how you feel when you walk out the door. Websites are no different. From the design to the UI, websites are statements about our clients to their users.
You may not think about what your hair will say every time you go to see your stylist, but your stylist should be. They know what their work has done for other clients, and you should know what your work can do for your clients too.
There is no more important thing you can do for your life and your business than to know your own value. But how do you measure the subjective? Here are some simple ways to breakdown what you are worth to your clients.
Many times, building out the features on a Drupal site seems easier with contributed modules. Why reinvent the wheel? Next thing you know, you're standing on your head trying to read module code backwards to understand it. Hours in you're making custom tweaks to keep your client happy and spending more time tweaking and overriding behavior than if you had just written the code for the feature from scratch.
Shortly after Drupalcon Portland wrapped up, I came across an excellent blog post by Mike Crittenden: Drupal and "Invented here". If you haven't read it yet, I'd highly recommend checking it out. Not only is it funny and entertaining, it is also quite informative and describes very well the dilemma presented to Drupal developers of using contributed modules versus writing custom code.
Feel like your clients always want too much? Wish you could do more than break even? Tired of feeling like you jumped into the deep end of the pool every time there's a Drupal upgrade? Here are some simple ways to make Drupal consulting fun again.
1. Listen to what your clients are actually asking for
Say your client wants to have a block that they can put 'anything' into. Obviously Drupal data is in many forms, views, content types, nodes, beans, entities...it's not that simple especially for non-technical clients. (See Mike's upcoming book Model Your Data with Drupal for more info on how to keep Drupal's data structures nice and tidy.)
Stop and ask yourself what is it that the client really needs?
On the surface, Drupal makes a great content management system. Flexible fields, custom types of content, and more make it seems ideal and ready to take on any content or application requirements. Work with Drupal past the surface and soon you'll find that those dream features have very real limits and running into them can hurt. Badly.
A little history
The sheer number of different solutions that have presented themselves over the years makes it obvious that there isn't an easy one size fits all solution to data modeling. From the original node system (with types defined each in their own module), the Content Construction Kit, to Drupal 7 Fields, the solutions have always been evolving. With all the flexibility that comes with the sanctioned version there is often a tradeoff. In Drupal 7 Fields API, that tradeoff is usually performance, with large numbers of fields bringing a site to a crawl.
A better way
Imagine a system that allows you the flexibility to construct your database schema anyway that you want, one that gives you performance, and ease of imports while better representing the relations between your data. What if you could have all this without giving up the power of Drupal, with it's easily extended field types? What if you could build your site this way, knowing that you could integrate your data with any contributed module, without having to rewrite everything, or write your own integration code?
I sincerely believe that this isn't just my fantasy, but that of just about every developer out there. Being able to reuse as much code as possible (DRY) but having the flexibility to quickly control the things that matter the most to you without fighting the system you are integrating with. It kinda sounds like the future, right?
The future is here
The surprising truth is that this dream is much closer to reality than you would think. Drupal 7's Entity API is a bit of a sleeper, waiting to be fully discovered and put to work. It was added at the last minute as a way of encapsulating the ideas required by the new Field API in order to function across Nodes, Users, Taxonomy terms and in a unified way. What Drupal actually got, was the hint of core system for modeling data.
When combined with the Entity API contributed module, this system becomes much more complete, eliminating the need for repetitive code to handle things such as saving or deleting custom entities. Despite the ease of use, I've found a bit of a disconnect when talking to folks about the Entity API.
I think alot of folks don't know just how easy it is to model your data with custom entities. Or maybe they don't know how easy it is to encapsulate their domain logic within their models. Maybe the most important feature to them is being able to have control over their schema.
Whatever it is, I think it's important to get more people using the Entity API. Which is why I've decided to write Model Your Data with Drupal, a book dedicated to understanding and utilizing the Entity API in real world situations. Model Your Data with Drupal will cover the core APIs such as Entity, Fields, Schema, Forms, and more along with contributed modules such as Entity API, Views, and others. While it's not an all inclusive module development book, it will give you all the information you need to write a module that will let you simply, and easily model your data.
To learn more, and keep in touch, visit http://modelyourdatawithdrupal.com and sign up for updates for more info.