Friday, January 20, 2012

List of contributed modules for drupal developer

• Availability—allows availability information to be displayed for specified.


• Content Construction Kit (CCK) —allows custom fields to be added to nodes using a web browser.

Chaos tool suite (ctools) This suite is primarily a set of APIs and tools to improve the developer experience. It also contains a module called the Page Manager whose job is to manage pages. In particular it manages panel pages, but as it grows it will be able to manage far more than just Panels.


• Event—allows the creation of event-type content.


• Fivestar—enable the rating of content using stars or similar icons.


• GMap—allows the insertion of a Google map into a node.


• IMCE—gives the client the ability to upload and manage some files through the Admin interface.


• Image—allows users with the correct permissions to upload images.


• Image Field—provides image upload field for CCK


• Imagecache—allows presets for image processing

jQuery UIA wrapper module around the jQuery UI effects library that lets module developers add swooshy, swishy effects to their code. This is a utility module that won't do anything on its own.


• Location—allows you to associate a geographic location with content and users.


• Notify—allows users and admin to receive periodic emails about all the new or revised content and / or comments.


• OG—enables users to create and manage their own 'groups'


• Panels—this module allows you to create pages that are divided into areas of the page.


• Poormanscron—runs the Drupal cron operations without needing the cron application.


• Signup—allows users to sign up for content of any type.


• Simpleviews—an easy-to-use tool for building content listing pages.


• Taxonomy Menu—easily transforms taxonomy vocabularies into menus.


• TinyMCE—makes the formatting of all articles easier.


• Token—provides an API for modules to use tokens


• Tribune—provides an advanced discussion space, such as a chat room


• Thickbox—allows inline pop-ups for images


• Ubercart—the shopping cart on which the site will be based


• Views—allows you to create customized lists and queries from your database.


• Webform—allows the creation of web-enabled forms for use on this project.

Saturday, January 14, 2012

Why You’re a Bad PHP Programmer

We all have our bad habits. In this article, we’ll go over a list of bad practices that are worth examining, reevaluating, and correcting immediately.


You Don’t Plan Before You Start Coding

Before you write a single line of code, you should have a solid plan of attack. This helps keep you on track and avoids wandering code that will confuse you later, not to mention some other poor soul.
One approach that has saved me time — both in development and in commenting — is to write an outline in comments first.

You Don’t Comment Anything

It makes me sad that I have to write this down. When something is as easy as commenting, it shouldn’t be something we have to remind each other to do.
Yet the single worst problem with most code that I encounter is that it’s poorly commented, or not commented at all. This not only adds a good chunk of time to my initial familiarization with the project, but it pretty much guarantees that a fix made using an unconventional method out of necessity will confuse me. Then, if I end up doing any refactoring, I’ll inadvertently break the app because I haven’t encountered the extenuating circumstances that required the fix.
This process can take anywhere from 10 minutes to 6 hours. (And you’ve done this to me, I know where you live. I’m coming for you.)
So say this out loud:
I, [state your name], hereby swear to make comments in any situation where the purpose of the code I’ve written isn’t immediately apparent.

You Sacrifice Clarity for Brevity

It’s a universal temptation to get something done in as few characters as possible, but that temptation is kind of like the temptation to only have one pair of underwear: sure, the laundry gets done quickly, but the problems that arise from your choice hugely outweigh the benefits.
Good examples of sacrificing clarity for brevity include short, unclear variable names (such as $a — what does $a store?) and dropping the curly braces.
Dropping curly braces from control structures is a particular pet peeve of mine. If you don’t like curly braces, switch to Python. In PHP, it’s just too easy to lose the meaning without them.

You Don’t Follow a Coding Standard

Getting cute with your formatting might satisfy your artistic urges, but it does no good for anyone. Choose a standard (I recommend the PEAR coding standard) and stick to it. Everyone will thank you. (Including yourself, someday.)
Trust me. I was that guy once — I wanted to have a “signature style” — and I wasted a lot of hours fixing my atrocious formatting later on. There’s a time to be different and a time to do it like everyone else.

You Duplicate Code

Try to look at every single piece of your app as something that will need to change at some point. If it does, will you have to update more than one file? If you answered yes, it’s time to reevaluate how you write code.
If you’ve got code doing the same thing in more than one place in your app, you’re doing it wrong.

You Don’t Follow a Development Pattern

You should always have a structure when you code. I don’t mean to imply that you need to be following the MVC pattern or something equally rigid, but I do mean that you should know how to classify components and where they should go.
By following a logical development pattern, many decisions become automatic, and someone coming into your code doesn’t have to guess much when looking for a certain functionality in your codebase.
It doesn’t take long, and it really will clarify your apps in a big way.

You’re Too Clever for Your Own Good

There’s a fine line between a crafty solution and an overcomplicated one.
It’s always tempting to try out some sweet new trick you’ve learned, but we have to resist the urge to force a complex solution into a space where a simple one is sufficient.
On a basic level, the simplest solution is usually the most appropriate. You’re trying to get from point A to point B — taking a detour through point Awesome is fun, but really doesn’t add any benefits.
Your super-sweet solution does, however, pose a problem in which someone else may not have seen that particular solution and will just get lost. It’s not because they’re not as smart as you, either; it’s likely because they didn’t see that particular article or weren’t trying to force a square concept into a round problem.
Don’t dumb yourself down, but remember to avoid overcomplicating things “just ’cause.”

You’re a Wang

When I was first getting into development, I worked with a guy that was a self-proclaimed “expert” programmer. Whenever I had a question about a concept, he never gave me a straight answer; in order to get the answer to my original question, I had to answer a couple preliminary questions to “prove you can handle the answer.”
This guy was also really good at writing code that was cryptic,obfuscated, and just generally confusing.
Files like his are the result of programmers who think that they need to make their code hard to read in order to “keep the idiots out.”
The general philosophy behind this tends to be, “If you’re not smart enough to understand this code, you shouldn’t be in it in the first place.”
This is a deeply misguided and anti-social approach to programming. It’s a very elitist way of looking at things, and it shows that the programmer has lost touch with his beginner roots, when he himself needed help.
Avoid actively making your code hard to understand at all costs. It doesn’t make you any cooler or smarter, and it doesn’t bolster respect. It just makes you a wang.

Dude, What Are You Talking About?

In addition to the shortcuts and general laziness above, another thing that might be holding you back is a lack of continued learning and forward progress.
Technology isn’t changing because the community at large is bored and we decided to redecorate; most new technologies emerge to more efficiently and easily solve existing problems. Choosing to ignore progress is choosing to start the slow process of marginalizing your skillset.
Here are a few things we can all stop doing to make sure that our skillsets are up-to-date, all without having to give up our weekends.

You’re Trying to Do It All Yourself

You can’t keep up with the whole community. As anyone who’s ever tried to keep up with a subscription to 200+ tech blogs will tell you, it simply can’t be done within a reasonable timeframe.
Fortunately, there are those within the community who dedicate their time to watching the progression of technology and reporting their findings. If you take the time to find out which of these programmers has a similar approach and style, you can let them fill you in on the big news.
Watching 2-5 of these “early adopter” type bloggers can be more beneficial than subscribing to every tech blog you come across for several reasons:
  • If you trust their opinion, they’ll be screening technologies for you.
  • If a technology pops up on more than one of these blogs, you know you should at least take a few minutes to learn more about it because it’s obviously popular.
  • Often, these blogs will feature a quick intro tutorial, which can save you the headache of starting from zero with a new technology.

You’re Not Out of Your Comfort Zone

If you’re not doing something that challenges you, something is wrong. Finding new challenges within projects is most of what makes programming rewarding (or at least it should be).
Try asking yourself the following questions when you start looking at new projects:
  • Is there a new technology that interests me that applies here?
  • Have I learned of a better way to do this since the last time I took on a project like this?
  • Is there a best practice I need to enforce that I could make sure to follow throughout this project?
Keep in mind: I’m not talking about doing anything grossly complex, here.
It can be as simple as remembering to add Docblocks to your objects, or as complex as making your app compatible withXMLRPC so it’s easier for users to post updates.
Just try not to settle in and convince yourself you’ve learned everything you’re going to learn. That’s when it’ll start getting ugly for you.

You’re Not Sharing

The best way to improve is to discuss your code with your fellow programmers. This can be done through multiple avenues: if you’re feeling particularly outgoing, write a tutorial or release an open-source project; if you don’t feel up to something of that scale, maybe you could hang out on a community forum and offer help to the newcomers.
“How does helping the noobs help me progress?” you ask. Usually, if you post a solution that could be optimized, other experienced programmers are going to hop in and offer tweaks. So this approach is a double-whammy of awesomeness: you’re not only helping progress the community by offering your knowledge to beginners, but you’re sharpening your own skillset by hanging your chops out for everyone to see and help you develop.

We’re All Guilty

If we’re doing it right, we should always be improving. And logic tells us that if we’re better now, then we were worse before. And if we follow that line of reasoning back far enough, there was a point where we were terrible.
I know that when I look back at some of the code I wrote in the past, I’m horrified.

So… Stop It.

We’ll never be perfect. But we can do everything in our power to make sure that we’re getting as close as possible.
What are your pet peeves when dealing with other developers’ code? Let me know in the comments!

10 skills developers will need in the next five years

If you’re a developer looking to get ahead in your field (or in some cases, to simply stay employed), this is not a good time to be complacent. The lists of skills you’ll want to work on now to maximize your future job prospects.


1. One of the “Big Three” (.NET, Java, PHP)

Unless there is a radical shift in the development world (akin to an asteroid hitting Redmond), most developers will need to know at least one of the Big Three development systems — .NET (VB.NET or C#), Java, or PHP — for the near future. It’s not enough to know the core languages, either. As projects encompass more and more disparate functionality, you’ll need to know the associated frameworks and libraries more deeply.

2. Rich Internet Applications (RIAs)

Love it or hate it, in the last few years, Flash is suddenly being used for more than just animations of politicians singing goofy songs. Flash has also sprouted additional functionality in the form or Flex and AIR. Flash’s competitors, such as JavaFx and Silverlight, are also upping the ante on features and performance. To make things even more complicated, HTML 5 is incorporating all sorts of RIA functionality, including database connectivity, and putting the formal W3C stamp on AJAX. In the near future, being an RIA pro will be a key resume differentiator.

3. Web development

Web development is not going away anytime soon. Many developers have been content to lay back and ignore the Web or to just stick to “the basics” their framework provides them with. But companies have been demanding more and more who really know how to work with the underlying technology at a “hand code” level. So bone up on JavaScript, CSS, and HTML to succeed over the next five years.

4. Web services

REST or SOAP? JSON or XML? While the choices and the answers depend on the project, it’s getting increasingly difficult to be a developer (even one not writing Web applications) without consuming or creating a Web service. Even areas that used to be ODBC, COM, or RPC domains are now being transitioned to Web services of some variety. Developers who can’t work with Web services will find themselves relegated to legacy and maintenance roles.

5. Soft skills

One trend that has been going for quite some time is the increasing visibility of IT within and outside the enterprise. Developers are being brought into more and more non-development meetings and processes to provide feedback. For example, the CFO can’t change the accounting rules without working with IT to update the systems. And an operations manager can’t change a call center process without IT updating the CRM workflow. Likewise, customers often need to work directly with the development teams to make sure that their needs are met. Will every developer need to go to Toastmasters or study How to Win Friends and Influence People? No. But the developers who do will be much more valuable to their employers — and highly sought after in the job market.

6. One dynamic and/or functional programming language

Languages like Ruby, Python, F#, and Groovy still aren’t quite mainstream –  but the ideas in them are. For example, the LINQ system in Microsoft’s .NET is a direct descendent of functional programming techniques. Both Ruby and Python are becoming hot in some sectors, thanks to the Rails framework and Silverlight, respectively. Learning one of these languages won’t just improve your resume, though; it will expand your horizons. Every top-flight developer I’ve met recommends learning at least one dynamic or functional programming language to learn new ways of thinking, and from personal experience, I can tell you that it works.

7. Agile methodologies

When Agile first hit mainstream awareness, I was a skeptic, along with many other folks I know. It seemed to be some sort of knee-jerk reaction to tradition, throwing away the controls and standards in favor of anarchy. But as time went on, the ideas behind Agile became both better defined and better expressed. Many shops are either adopting Agile or running proof-of-concept experiments with Agile. While Agile is not the ultimate panacea for project failure, it does indeed have a place on many projects. Developers with a proven track record of understanding and succeeding in Agile environments will be in increasingly high demand over the next few years.

8. Domain knowledge

Hand-in-hand with Agile methodologies, development teams are increasingly being viewed as partners in the definition of projects. This means that developers who understand the problem domain are able to contribute to the project in a highly visible, valuable way. With Agile, a developer who can say, “From here, we can also add this functionality fairly easily, and it will get us a lot of value,” or “Gee, that requirement really doesn’t match the usage patterns our logs show” will excel. As much as many developers resist the idea of having to know anything about the problem domain at all, it is undeniable that increasing numbers of organizations prefer (if not require) developers to at least understand the basics.

9. Development “hygiene”

A few years ago, many (if not most) shops did not have access to bug tracking systems, version control, and other such tools; it was just the developers and their IDE of choice. But thanks to the development of new, integrated stacks, like the Microsoft Visual Studio Team System, and the explosion in availability of high quality, open source environments, organizations without these tools are becoming much less common. Developers must know more than just how to check code in and out of source control or how to use the VM system to build test environments. They need to have a rigorous habit of hygiene in place to make sure that they are properly coordinating with their teams. “Code cowboys” who store everything on a personal USB drive, don’t document which changes correspond to which task item, and so on, are unwelcome in more traditional shops and even more unwelcome in Agile environments, which rely on a tight coordination between team members to operate.

10. Mobile development

The late 1990s saw Web development rise to mainstream acceptance and then begin to marginalize traditional desktop applications in many areas. In 2008, mobile development left the launch pad, and over the next five years, it will become increasingly important. There are, of course, different approaches to mobile development: Web applications designed to work on mobile devices, RIAs aimed at that market, and applications that run directly on the devices. Regardless of which of these paths you choose, adding mobile development to your skill set will ensure that you are in demand for the future.

PHP to Drupal: Get up to speed with drupal from a php developer background

While working on various projects with drupal I realized that there is really no one definitive place which lists the concepts that you need to become familiar with when dealing with drupal. So I decided that I would put them in one place for people who maybe are experienced php developers who are trying to learn to work with drupal for the first time.

The main important components when working with drupal on a serious project are:

1. Pages

A page is a unit that most web developers are most familiar with already. And that is the problem, because when you are creating a website with drupal, the code is not organized in these bite sized chunks. The beauty of the drupal model of work is that drupal separates what you need to write into re-usable chunks of code which can be used on numerous pages, and is not confined to one page in particular.

That being said, there are still instances where pages are used, but not in the same way as in a website you have to program from scratch. Often times pages are used instead as a means to configure areas of drupal, as admin pages etc.

2. Blocks

A block is a small chunk of code which can be placed on the same page as page content, or on a node (which I will explain next). The block is a handy thing because it is easy to put blocks across a large number of pages, and it is also possible to let the admin user configure the visibility of a block based on the user's permission level (called a user role) via the admin interface.

These properties make blocks powerful in that you can put them in almost any configuration on a page, but not care ahead of time what else is on the page. In effect leaving page design to a designer or site admin.

3. Nodes

A node is a very important part of drupal, because it ties in so deeply with the drupal structure. A node is an object in drupal. The node can be displayed and expanded and acted upon by modules. In the drupal module repository there are many modules which will act on nodes allowing for some really cool things.

The node can be a somewhat difficult concept to grasp, but thinking of it as a procedural object which can be acted upon, displayed, filtered, and restricted as a group. So a grouping of these "nodes" (known as a content type) can be exposed to different user roles. This means that if you want a bunch of pages which do the exact same thing you would create a new content type and then the individual nodes would all have the same structure.

4. Theming

Theming is important in drupal as it makes any code which is written and enables the designer to alter the output of that code, by adding tags, markup and css in order to make the website pretty. In this it is important to expose all html to drupal when you are writing it so that a designer can later open up the theme folder and overwrite your theming function adding these ever important tags.

The theming engine in drupal is quite powerful and it is possible to procedurally theme small subsets of a page consistantly on a website by using this theming technique.

5. Modules

A module is where the exciting things happen in drupal. Because as a drupal developer you will want to avoid hacking drupal core as much as possible. This makes upgrading simple and easy, as well as keeping the codebase clean for your modules, making it possible for them all to work together instead of having one module vs. another.

The module system in drupal again is very powerful because of the node structure, and drupal's ability to edit queries which are written in one area of drupal, or written in one module by another.

6. Menu

The menu structure in drupal is also important. This is the area of drupal which exposes certain menu items based on permissions, and also changes based on where you are in your website's tree structure. It is important to use the menu structure on your drupal websites because this structure is much more powerful than doing it by hand. And because of the permission based feature.

7. Testing

Going forward into drupal 7 testing is becoming increasingly important in the drupal community. This testing is becoming a part of the core list of modules, but also it is very helpful even in drupal 5 and drupal 6. Unit testing ensures that if you make changes to your code, that it does not effect the code you have already written.

There has recently been a big push for testing to increase the productivity of coding and reduce the number of errors in the code. Drupal's testing is mostly done with the simpletest module found at http://drupal.org/projects/simpletest.

So this is my broad overview of what concepts a php programmer needs to know when starting to work with drupal. Please let me know if I forgot anything.

src: http://www.westwesterson.com/blog/php-drupal-get-speed-drupal-php-developer-background