drupal

I was recently asked about what separates my company from others I have worked in the past. What immediately came to mind was the relationship with my team, the work we do, and the sheer talent. Those elements alone still make me get up in the morning. But, over a cold beer, something else struck with me. My company has no routine and I love it. Let me Google that for youYes, this may set you back initially. Routine typically has to do with schedules or habits. But, what I am referring to is very much about our culture. We're a newer company that is still applying polish to our offerings

If you're doing Drupal development, having a local sandbox is a necessity. Why? No one should be making untested changes on a production or staging server. And, a development server should be free of initial development errors where the developer should execute a small set of engineering tests before deployment. Plus, it can be time consuming to regularly deploy code developed locally onto a development server. To summarize: a local sandbox is absolutely best practice. I hope to summarize how to quickly get up to speed without having to rehash the lessons I have learned. DisclaimerThis blog

Rands' recent blog post Busy is an Addiction struck a chord with me. It's made me rethink many aspects of my day-to-day routine. Work Smarter, Not Harder It's so easy to say, I'm busy. In reality, I should be working smarter, not harder. Busy is as much of a state of mind, as it is the items on your plate. It's a routine, a lifestyle, and a shitty excuse. If you fall into the busy pattern, I personally believe it's easier to make mistakes. Your pace is more frantic, your getting pulled in thirty different directions, and you really don't have the time needed to pay attention to what your doing

In a previous job, I had a boss that I really admired. He's near the end of his career and his experience had made him wise. He was humble, but would chime in as needed. One of my favorites was his ability to bust out short one-liners that would hit the nail on the head. Around the water cooler, we regularly discussed open source. Here are some highlights: Free like a puppy This one always made me chuckle. But, it's true in so many ways. I look at the open source community. At times, people's evaluations of open source tools are skin deep. "Ah, they are free!". This typically follows two

PrefaceNodes are the unquestioned most robust data structure within Drupal. It has widely adopted integration, e.g. Views, Features, Context, Rules, etc that make the Node a popular Drupal entity for countless use cases.However, the default node structure comes with a lot of baggage. It has built in publication states, authoring information, and revisions. Most of the time, these features are advantageous. Others, not so much. Nodes with no pagesDue to the robust features available for nodes, a content type is often created for nodes that do not actually have viewable pages. Let's look at a

Push aside the user stories, contracts, and legalities. When push comes to shove, the developer delivers the goods. In my mind, there is huge risk to a project with the role of a developer. Let's be clear though. Every project has risks. Every project has some complexity behind it. What this means is that there is a dark art to the design decisions made by the developer. I've never seen a client accurately define what content types or modules need to be installed. Again, if they were that educated about what needed to be done, they wouldn't be paying you to do it. The developer must learn

Peter Nixey describes good developers as both technology proficient and hard working in his blog post. His concept of "simplicity" is worth noting. I highly encourage developers to create code that limits complexity. But, there is an even more important aspect of complexity: usability.Simplicity and excellence are most reliably attained by starting with something, anything, that gets the job done and reworking back from that point.Enter the noob. Every project should have someone in this role. Technologically detached. Familiar with project goals, but does not look at one line of code. No

The Migrate module is, hands down, the defacto way to migrate content in Drupal. The only knock against it, is the learning curve. All good things come to those who take the time and learn it. I have summarized some tips and tricks I have learned. Thank you to Mike Ryan and Alex Ward for helping me get up to speed. Drupal's Migrate module is a code-centric approach to migration. As such, I highly recommend leveraging Drush during development. Here are some tips I have used, some of which require Drush to be installed. 1. drush mreg Quick and dirty way to register new Migration classes after

This is a topic I have grown all too familiar with, as this is my thesis topic for my master's degree. I thought I'd share some basics to set the stage in this area of work. Background Users upload files as content to web-based systems. Think of Facebook and how user's upload images and/or videos to share with friends. The key concept is around the notion of sharing. What is appropriate file sharing (anonymous access, authenticated access, membership-based access)? What is not appropriate sharing? This question changes based on application-level policy, meaning it's difficult to find a one

The Coder module (http://drupal.org/project/coder) is well known for assisting developers in producing code up to snuff with the community defined standards. Such standards have been integral in helping the community grow in a consistent manner. The ultimate goal is to find an automated way to help developers out. Such examples include a code review and performing routine code manipulation. The standard for analyzing code leverages known static analysis approaches. There are two principle goals for code: consistency and simplicity. Consistency To understand what consistent code looks like, we