Category: Community


Microsoft Web Dev Summit 2009

December 5th, 2009 — 10:44am

See my pics from the event here!

I had the opportunity this past week to go back up to Microsoft for the second year to attend the Microsoft Web Developers Summit. The event brings together a wide range of people related to web development in the PHP community. This year the group was made a bit more diverse because of the inclusion of a few members of some of three communities of PHP-driven applications: WordPress, Joomla and Drupal. It made for a nice mix and, really, for what I think was one of the more interesting parts of the event (but more on that later).

Over the three days we were there, presentations were given from groups all around the company including the Web Platform Installer folks, the IIS team, the SQL Server team and a pretty cool showing from the Bing group on their mapping offerings. Showing off the products seemed to, usually, be a secondary mission for most of the groups though. Out of the number of sessions crammed into each day, most of them were either the PHP community talking to Microsoft (in the form of free-form discussions) or the Microsofters sitting down and really talking with us and asking questions about what we were doing and how they can help us do it better.

In my opinion, these discussions were worth the cost of the whole conference alone. Last year’s conference seemed a bit more chaotic and less structured. There was a lot of miscommunication (it seemed) and several things that we, as a community, weren’t terribly interested in. This year was leaps and bounds over that in terms of both quality and planning. The sessions that weren’t the discussion times were mostly relevant and almost everyone that represented MS seemed to know at least a little bit about what was going on in the world of PHP (with the exception of the ASP.NET folks but really, they sort of have an excuse – they were very happy to get the answers to their questions, though).

Leaders make all the difference in events like this and we had some of the best – our own Cal Evans helped to keep things on task and get the conversation jump started when it needed it, Karri Dunn (the ringleader and organizer) did an excellent job of making sure things were moving along smoothly and that we were able to talk to other groups in the company too (even those not involved in the summit), Josh Holmes (evangelist extraordinate) who has really jumped into the PHP community feet-first and has become one of our key voices back to Microsoft in general and, last but not least, to the leadership within the PHP community – the represenatives from WordPress/Joomla/Drupal, the core developers, the user group leaders and general community members.

A major thank you to all of you (including those I haven’t mentioned that made the event a success) for taking the MS Web Dev Summit up to the next stage in its evolution. I love the direction the event is heading – don’t lose that momentum and don’t lose touch with the PHP community. Last year everyone took their planes home and there was some random communication between MS and us via emails/twitter/etc but most of the connection was dropped. This year there’s already an effort underway to keep those lines open and to make a real dialogue between the web-related groups of each side flow. This, in my opinion, is a real deal-maker. It’s one thing to have a company that brings you up to talk with them for a few days and that’s it. It’s a whole other thing to have one that’s really excited about what’s going on with you and your community and wants to engage you and get input on their next moves.
Web Platform Installer (WebPI). I seriously hope they consider some of the suggestions we gave them as to its future and what we thought could really make it more than it is without sacrificing the simplicity it already has.

3 comments » | Community, Microsoft, PHP, Web

Having Companies Involved in PHP (why not?)

October 28th, 2009 — 7:53am

After this year’s ZendCon, there’s a question that’s been sitting in the back of my mind, bugging me to come up with a good answer – what role should companies take in the developer community ecosystem? The problem with the question is simple, though, because no two user group situations are the same.

I’ve heard things from both ends of the spectrum on this one. Some groups prefer to keep the companies away from their groups and rely on the support of those that make it up (much like a lot of the general PHP community) and there’s others that swing far to the other side and want any and every company that could potentially help them out to come walk through their door. The tricky part comes up when you get into that gray area in the middle. Some groups want help when they need it, but don’t want a company coming in and using that same influence to change the course of the group or to try to leverage it for their own purposes (“sure, we’ll help you out with that if…”).

So, what I want to hear from all of you – where do you think companies fit in our corner of the world in the PHP community? There’s several large ones out there that can and do contribute and others that don’t…which is the right blend and, more importantly, what can we do to help the situation?

8 comments » | Community, PHP

Outside the Bubble

October 16th, 2009 — 3:33pm

So, given some of the comments from my previous post on conferences (and what they are/aren’t) I felt like I’d lost a bit of my “conference roots”. I’ve been to enough of them that my perception is, almost definitely, skewed in favor of the group of folks like me – the ones that seem to be making a career out of attending as many conferences as possible. We all know each other and we all have our own little bubble we float around in at most conferences. There’s comfort there, but there’s also one large problem – the bubble isn’t big enough.

Some of my advice from before pertained to those attending these conferences that might not be a part of this bubble. This includes the large number of attendees that are at a conference for the first time. Ever. They may or may not have even been to a local user group meeting before and this could be their first wide-spread exposure to the Wonderful World of PHP (and might be for a while after). So, fellow residents of the bubble – what can we do to help make these people feel welcome in our community and leave them with the feeling like they’re appreciated and that they can contribute back to PHP in their own way? Here’s a few suggestions:

  • First off, an easy one – you were a newb once too, remember? No one was just born into the PHP community, it was a matter of discovery. Maybe you were working with Java or just learning HTML and how to design web sites. It’s possible you might have even glanced at PHP before but pushed it away as one of those “languages that’s just a fad” but have come back around. You explored the language, poking around in all of its nooks and crannys to figure out the best of the best practices for you and your code. How would one do this, you might ask? Well, it’s simple really – experienced users, much like you are now, took the time to sit with them and talk them through a problem they’re having. Or they did something as simple as stand at the front of a room and talk for an hour on something that interested you enough to want to devour any knowledge you could. In short, generations of folks from inside “the bubble” were the ones that helped you become the developer you are. Don’t forget that and don’t forget to follow their lead. We can’t have strong leadership in the language or community without guidance from those more experienced. Without it, our community will surely die.
  • Next, an even easier one – sometimes, it’s not really about the code. Trust me on this one…when meeting people at conferences, it’s only maybe 30% about the actual code. Sitting in the conference rooms and learning about the technology is one thing, but walking around and shaking hands with people you’ve never met before fills out the rest. After the sessions are done, you’ll be surprised by the number of people that just want to sit around and shoot the breeze about what they’ve learned or another related bit of web technology. If you’re lucky enough to be a speaker and happen to overhear someone talking about something you know well, stop and listen. Offer advice where it fits and help them on the path to understanding some of the more difficult concepts. I remember being at my first conferences and seeing the speakers walking around and talking with each other and wondering if I’d be able to break in and ask one of them my own questions. Remember speakers, it’s not always about the other attendees coming up to you – keep your ears open and listen for places you can offer advice. There’s going to be a *lot* of people at ZendCon next week, so be sure to be ready to be what you’re there for – some of the most knowledgeable in your area. Be sure to share!
  • And finally – the comfort zone is the danger zone (I bet you’re humming “Highway to the Danger Zone” now, aren’t you?) Jokes aside, this is just a quick one…don’t let yourself pass up an opportunity to share what you know with someone else because it’d be a step outside the usual. Remember, we’re all a part of the same community and if there’s no sharing going on, bad things happen.

Most of this is common sense and just about every speaker I know does this at one time or another, but I just wanted to remind those “bubble people” to get out there and mingle with the crowds and spread that knowledge around a bit. What you might see as one small comment to a random developer from a group could be the key to the problem they’ve been working on for months.

2 comments » | Community, PHP

It’s not a conference…

October 15th, 2009 — 10:24pm

As I sit here and prepare my liver for the onslaught coming next week (ZendCon, of course), I can’t help but think about those folks that’ll be attending the conference. I’ve been trying to think back to the first time I went to a PHP conference (php|tropics represent) and how I felt walking about with the people I’d only knew by name from books, blogs and articles I’d read. I was actually sitting there learning from *the* Wez Furlong and was there with *the* Andrei Zmievski learning about PHP and it was amazing and thought provoking and I felt like I could write and do anything while I was there, surrounded by all these great minds.

Fast forward a few years to 2009 and you’ll find me still attending conferences and still enjoying getting to be around some of the big thinkers in the PHP community, but it’s just different. It’s not the talks or the evening events – those are all pretty much the same. No, I’ve definitely changed my expectations of conferences and I think it’s something that can easily happen to any attendee, speaker or not: you forget.

Yup, two simple words sums it up. You’ve been to one conference, maybe three and the sameness of it all starts to catch up with you. You follow some of the same patterns: you wake up, you drink enough coffee to make it through the first session, head to a few more, then lunch and on through the afternoon. Lather, rinse, repeat for the remaining days of the conferences. You can see how it’s easy to get in a rut and just coast your way through the conference absorbing what you can and drifting out the other side to an airplane that will take you back home.

Here’s another two words for you – speaker or not, conference attendee or organizer: wake up! As much as it pains me to say it (being a speaker and all), these events are *not* about the talks. Want me to repeat that? Conferences are *not* about the talks. I think Keith hit the nail on the head with some of his comments in a recent post talking about the “hallway track” and meeting people. Conference organizers will promote the sessions and the panels and talks they’ve managed to pull in with the big names, both in the PHP community and outside it. They want you to come and see these people and feel good that you sat in a room listening to the folks that took a chunk out of their conference budget. This makes them happy and they hope it makes you happy.

I can tell you one thing from my years of going to PHP conferences – if you listen to them, you’re missing out on the best part of the conference. See, the other benefit of having large events like this that companies can feel good about sending their employees to is…well…that it’s a large event with lots of people at it. That’s the key right there – the people. Enlightenment is fun, but sitting around having beers with the “internet famous” people you know from blogs and articles is so much more interesting. I’ll say it again just to be sure it sinks in – conferences are not about the sessions, they’re about the people.

So, what can you do to make sure you get the most out of your conference experience? I’m going to blatently steal some of these ideas from Keith but with a few of my own dropped in:

  • Sessions are interesting, but people are fun – there are a *ton* of sessions happening at ZendCon this year. So much so that I have no clue where I’ll end up. Chances are, you’ve picked out a schedule that interests you and are just waiting to know which room they’re in. Do me a favor – each day, pick one talk that you’re on the edge about (yeah, you know the one) and don’t go. Yup, that’s right – don’t go, hang out in the hall or commons area or something. If you’re hesitant to go, chances are you’d just sit there and check your email or chat on IRC most of the time anyway. Do yourself a favor and get out and meet people. This kind of thing only comes around every once and a while, so make the most of it!
  • Make connections – Keith recommends business cards because they’re easy, but I’d say take it a step beyond that. Really get to know people – it’s funny how a “camp” atmosphere can help people bond more quickly than usual. Take advantage of this time and really talk with people – go beyond the “hi, so what do you do?” kind of thing and find out who someone is, why they’re there and something interesting about them. Then exchange the cards…and IMs…and IRC nicks…etc. Get to know these developers! They’re your comrades-in-arms, after all!
  • After-hours For The Win – The conference will have events after each of the full days of talks, that’s pretty much a given with any sort of conference. It’s what happens after that is some of the real fun. No, you don’t have to go out and party until the break of dawn (though there’s sometimes that too). I’m always a little bit disappointed that more people don’t stick around to hang out after whatever evening events might be going on. They scatter to the four corners of the hotel, not to be seen again until the start of the next day’s sessions. If you’re one of those types, trust me – being out just a bit longer won’t kill you. Plus you get an *amazing* benefit from it…you get to see people, speakers and non-speakers, how they are “off the clock”. Once the day is done, no one has to report to the next talk or worry about what the conference organizers will think. They sit down, stretch out and shake down until they’re just them. *This* is when real conversations start. If it hadn’t been for this time of the day joind.in might not even exist. Come, relax and just enjoy being around people – it doesn’t matter if they’re speakers, core developers or rockstars.

8 comments » | Community, PHP

The Beginner Pattern

September 6th, 2009 — 10:15pm


You were there once, remember? You were the cautious explorer, venturing out into an unknown language with little idea what it might hold in store. You learned functions, found tutorials to help you take your first steps and maybe even reached out to other developers to help you along the way. You were a beginner – everyone has to start somewhere, after all – and every little bit helped.

So, it worries me when I see things like this talking about a move of the PHP community away from those introductory topics that we all came to know and love as we moved forward into our PHP development careers. Samuel doesn’t think it’s the PHP community’s fault, not by far. He does suggest, though, that we’re “forcing newcomers to our community to build their PHP homes from attic to basement” by not pointing out or writing up as many tutorials and articles targeting the introductory developers.

In the spirit of trying to bring PHP back to the masses, I’m going to suggest a “design pattern” of sorts that the PHP community can help to bring even more people into the language and help them really find the heart of the language and what it’s all about:

  • Learn – The first step in the pattern is to learn about the task you’re trying to accomplish. Obviously you can’t teach others if you don’t know about it first. Find out the best way to do it – the tips and tricks if you can – and remember them. They’ll come in handy in the next piece of the pattern.
  • Write – You don’t have to be the Hemingway of PHP to write a tutorial. This piece has an obvious fit with the first step of the process. Take what you’ve learned and write it up into something anyone can follow. Just posting a list of commands and code isn’t enough – sorry. Write it so that someone who doesn’t know anything about the topic can pick it up and run with it. Plain english (or whatever your native language is) is best…technical terms are good when they’re needed, but don’t try to use them to make yourself look important by using too many multisylabic words in too many places con only lead to trouble. And remember, tutorials don’t have to be about anything fancy. Find out something cool about an everyday PHP function? Write it up! Trust me, no one will think anything about an “advanced developer” writing about a cool thing they figured out about str_replace.
  • Share – Obviously, a good tutorial or article isn’t any good unless people know about it. Sharing is an integral part of this pattern. If you don’t let others know, you might as well not write it. You never know when someone might need a little nugget of the wisdom you’re sharing, so broadcast it out there. Don’t be ashamed to bring it to the masses in the forums or post about it on your blog. There’s nothing wrong with a little self-promotion if you can help out some developer in need with exactly what he needs.
  • Learn – Wait, this again? That’s right, the pattern loops back on itself in an endless cycle. Once you learn a new skill, write about it and share that knowledge with at least one other person, you’re back where you started. You’re moving forward in your development and coming across new challenges each day. So, guess what? Write about them! Share it! You get the idea…

The pattern is simple Learn then Write then Share. Learning is handled by one object (you) and then writes to a local resource (your brain, duh) and the resources are exported into external data sources for other objects to use. Simple, right?

So, go out there, learn something new, write a tutorial about it and share it with the masses. Idling in your development on a project? Think about the things you’ve learned so far and share those.

Remember, there’s new developers starting every day – help them out and share the tips and tricks you have stored in that head of yours. They’ll thank you for it.

Photo from pagedooley Creative Commons Attribution License

16 comments » | Community, PHP

(More) PHP Worst Practices

August 22nd, 2009 — 3:47pm

I got such a great response from my previous “worst practices” post (thanks for all the great feedback!) I thought I’d forge on ahead with a few more to add to the list. A few pointed out that most of the recommendations from the first post could apply to just about any language out there – that’s great news to me. That tells me that PHP developers are just like any other developer out there, regardless of the language they “speak”.

On to the next round! Here’s four more “worst practices” that, if you care about being any sort of good developer you’ll avoid like the plague.

  • Speed is King (except when it’s not)
    Everyone wants their applications to perform well. It’s a well known fact that customers are wanting more and more each second and putting up with delays in a web app is almost unacceptable. They want it all and they want it now. Easy, right? All you have to do is make your apps work the best they can and do it as fast as possible. But which way is the fastest? We’re talking speed here, and you should do all you can to get those load times down and the customer satisfaction up. Optimize the hell out of those methods and cache whatever you can. Good planning (see “Unplanification“) from the start can make these kinds of decisions easy and smooth out the wrinkles that might pop up. Be careful, though…keep optimization in mind from the start, but don’t make every decision about shaving those seconds off. This can lead to some pretty bad code if you’re not careful. Good structure and standards should never be ousted by over-optimization.

    While I’m on the topic, there’s also another so called “silver bullet” that a lot of blogs, tutorials and books set up as a good option for making your site run faster: micro-optimizations. I’m sorry, but most of the things they suggest are really only doing one thing – giving you a false sense that your application will get a huge speed jump from using them. Granted, there are special cases where shaving one billionth of a second off the execution time can be helpful, but in most applications, that’s just not that helpful. If you’re serious about optimizing your applications, look into things like memcache or other caching tools so you don’t have to go all the way out to those databases/resources and pull down that data each time. Your application will thank you for it.

  • Be a Hermit
    Want a quick way to lose interest in a language? Don’t talk to anyone else that uses it. I know, I know – there’s lots of developers out there that have gotten very good at their language of choice, but there comes a point when they come across something even they don’t know. They get stuck on it for hours trying to figure out why changing the value of this one variable is breaking everything. What’re is options? He could keep trying, working for hours, even days on the issue before figuring it out. He could also take a look at the manual and see it shines any light on the problem – but that’s pretty limited. What’s the next step? Something that, sadly, a lot of developers just don’t do – ask!

    I’m not even talking about real-time communication here, this can even be just hopping on a forum and posting your question. Remember, as much as you’d like to think it, you don’t know everything. There’s going to be issues you come across (sometimes even bugs in PHP itself) that someone else out there has come across in the past. The collective knowledge of the PHP community is so vast that, given the right place and time, I’d dare say that just about any question could be answered. There’s even people out there that are happy to help you figure out the answer even if they haven’t come across it before (bless them)! Trust me, you can only benefit from having more than one developer poking and prodding your code into submission. Forums are just one teeny tiny slice of the pie when it comes to resources for help. There’s even *gasp* “face-to-face” things like IRC, local user groups and conferences where you can hit up other developers for ideas and suggestions. Don’t limit yourself! Use the mass brain power of the community to your advantage….after all, they’ll do the same!

  • Slight the Newb
    When was the last time you talked with someone just starting out with PHP? Last week? Last month? How did you treat them? Were you helpful and did you take the time to look at their application before slapping them with a big, fat RTFM about their problem. Don’t forget – you were a newbie once too.

    Have I made you feel a little guilty yet? If not, then you’re a better person than I. I’m guilty of this just as much as a lot of developers out there are. We forget that there was a point in time when we didn’t understand PHP’s object model or some of us even know how to use an array (yup, they’re out there). Some of us have come a long way since those early days of the endless “hack, reload, hack, reload, hack, reload” cycle spent learning the inner workings of that latest bit of code we grabbed from freshmeat. Those long sessions tend to blur together into one big fading memory of our early times with PHP and that’s where we get in trouble. We forget how much hard work and how many lines of code we’ve put in to know what we know. It doesn’t matter how far along you are in the process of learning PHP, I’m willing to bet there’s someone that knows less (“I just finished my first ‘hello world’ script!). I’m begging with you – pleading to you – that you don’t forget your early days. Remember how hard it was for you to wrap our head around that one feature, and be willing to help when someone comes looking for help.

    Give help when you can – a language is only as good as the people that make up the lifeblood of its workings and providing a well-lit path to the answer someone needs is an excellent start. This is the other side of “Be a Hermit” – you can be the one that’s there to provide the exact answer someone needs if you just take the time and work with them. Trust me, they (and the community) will thank you for making their code a better place for data to live.

  • Trust the Everyuser
    You’ve built an amazing application. Every feature is where it should be and everything has been tested to the last little drop. You’re caching things right (see “Speed is King”) and the server is humming along nicely. You’re ready to sit back and wait for the fame and fortune to come rolling in except…wait…where’s all your data? It was here just a second ago. Panic rolls over you as you frantically search for a backup or something that can help you recover from this mess. It’s too late, though – they’ve gotten in through a exploit in your code you never saw coming and have wiped the database clean. You’re hosed.

    At this point it doesn’t matter what the actual problem was, the real issue here is that, at some point in your code, you trusted someone who either A) wasn’t you or B) wasn’t someone who works on the code. That’s right – you forgot to filter, and this is one of the cardinal sins of web development. Think managing user input (filter in, filter out) is too much trouble? Tell that to the guy that just lost all his data in about 5 seconds. There’s even things in PHP that make it easier! There’s no excuse for filtering the things that users hand off to your system to be parsed. Depending on the data, it can even be something as simple as a filter_var or a regular expression check to be sure the format’s correct. Trust me, whatever time you spend adding in input variable filtering and escaping functions for the resulting output, the happier you’ll be. It might seem like a lot of trouble on the front end, but it’d all be worth it when that random user decides to run a SQL injection on one of your form fields.

    We’d all like to think that our users will all play nice and that there’ll won’t be a need for any kind of data protection. Back in reality some users are out for just one thing – your data. Don’t give them the satisfaction. Protect that data the best that you know how. And if you don’t know how, ask (“Be a Hermit”)!

So, there you have it – four more horrible things you can do if you’d like to crush any of your PHP hopes and dreams into the dust. Hopefully, combined with the previous list, these can provide the opposite – a handy reference of things to push you to be a better developer and to become a strong member of the PHP community as a whole. Trust me, the language is fun but the people in the community, they’re…er…funner!

5 comments » | Community, PHP

PHP Worst Practices

August 20th, 2009 — 10:17pm

We’ve all seen design patterns and heard about best practices in PHP development, but there’s a darker, more sinister side to the “practices” examples that is usually just the stuff of folklore and legend. Many a PHP developer brushes off their existence with a quick “oh, I’d never do that…” or “I’ve seen other people’s code like that…” What am I talking about? Why, only the very things that threaten to tear apart the language and the community as a whole! That’s right – PHP Worst Practices – and they’ll sneak into your development as quick as you can bat an eye. I’m here as a guide through some of these. The way I see it, if I can share as many as I can, you can see them coming a mile away and code around them.

So let’s get on with the list – the sooner the better:

  • Beware the Outsiders
    This practice (“Not Invented Here”) can be particularly deadly if you don’t keep an eye out. As developers, we’re tempted to have a “I can write it better” mentality. Don’t try to deny it – you’ve looked at an application and thought it just the same as the rest of us. It’s even worse when you’re starting something new. There’s fresh clean horizion out there and who would want to muddle it with someone else’s code (SEC)? Our code would be more pristine (and probably work better) if you take out an unknown like that – our would it? Stop and think for a second about this one. Sure, you could cobble together your own library to add that feature and yes, it might integrate excellently with your code, but what does that gain you? One of the points of Open Source development is to share your knowledge with the rest of the community. One way to do this is via code – posting your library so other can use it and *gasp* contribute to it for future versions. Its this shared knowledge that you’ll miss out on if you block SEC from your application. Sure, it’s not all good code, but there are some great sources out there (PEAR, PHPClasses, Freshmeat) to pick up just what you need. Plus, it’s win-win…you get a quick solution to your issue and you don’t have to maintain that library in the future.
  • Unplanification
    That’s right, I said unplainification. If you’ve ever charged into a project full force without taking even a single second to think about its structure, you know where I’m coming from. It’s that sinking feeling you get in the pit of your stomach when you’re half way through the second library and you realize there’s a much better way to do things. This revelation is usually followed by a whispering in your ear….”I told you so.” This would be the combined voices of everyone in your past that tried to teach you the mantra: “Plan First, Code Later”. Sure, you can get away without planning for the small stuff – test scripts, little cheesy two-page websites – but when you start talking web applications a plan is a must. It doesn’t have to be much, even some scribbles on the back of a napkin counts. Just something to say you’ve thought through the structure and pieces that’ll make up the application. Obviously, larger applications call for larger plans and it may require a team of people to work on the resulting project. If you’re not familiar on how to work with a development team, you’d do well to read up on it a bit. There’s nothing quite like a good development team firing on all cylinders and drawing up a unified plan for the development to come. Planning is a good thing and, while it might seem to be a hassle when all you want to do is code, do yourself a favor and take a deep breath and plan before a single line of code is written.
  • The Documentation Wasteland
    We’re all guilty of it. If you say you’re not, be prepared to be called a liar and to have ASP.NET stickers applied all over you and your computer. Scripting is just so much damn fun that writing the code is what it’s all about – make it work and make it awesome. Isn’t that what really matters in software development? I hate to break it to you, but that’s only half the story…really about three-fourths. If you’re writing your code without any sort of documentation, you’re dooming you and possibly future maintainers of the code into many a pointless search to try to figure out why method a() returns two completely different value types depending on which parameters it’s given. Sure, you can trace through the code and figure out what’s getting executed, but wouldn’t the world be a happier place if all you had to do was read a description. Just a few little lines of comments (like something phpDocumentor would parse) and the problem is solved. Sure, it’s not going to provide every step the data takes, but it lets you know the “why” instead of just the “how” the code gives you. Automatic documentation generation is a great step in the right direction (and dead simple too) as well as external documentation sources like wikis or standards documents. Do yourself a favor – as you write your code, add some comments and write up some documentation. You’d be surprised how often you’ll find yourself referring to it once it’s reliable.
  • Free Your Mind
    This one goes hand in hand with “Beware the Outsiders” but takes a slightly different turn. It’s too easy to get used to what you’re doing and focus in on just those technologies. You get used to the way your code works and you think that that’s the only way it can work. Except you’re wrong. You, as a developer, know that there’s always more than one way to solve a problem. Take that and carry it up one level and think about all of the technology that PHP can work with. Your LDAP authentication might be working pretty well for what you’re working on, but what if there’s another component out there that could make it even easier (and more customizable!) Don’t let yourself get fooled into thinking that you have to stick with “your way” to do things just because that’s how it’s “always been done”. There’s too much awesome PHP code out there to be so narrow-minded. There’s even frameworks like the Zend Framework or CakePHP to give you some great ideas on component and framework structure. Leave the confines of your cozy IDE and version control repository and look around – there’s plenty of great code out there to learn from!

These are just a few…there’s many, many (many!) more out there that could be added to this list to avoid. We’ll always be tempted as developers to slip into these worst practices when its the easy way out. You can your code deserve better, though. Focus on the best practices, the right ways to do things and make them maintainable and easier to work with overall.

8 comments » | Community, PHP

Mom Always Said to Share

August 15th, 2009 — 10:54pm

There’s something that most people’s parents taught them from the beginning – to share. You’re supposed to share your toys and be nice to the other kids and they’ll share with you. So, you’re all grown up now – do you still share?

I’m talking about knowledge in this case (of course. though sharing toys could be fun too) and how you share it with those around you. As a developer, you have two charges in your professional life – to make the best damn software you can with the time given you and to spread what you’ve learned through out the rest of the community. No one person can know everything – sure, lots try – and so they have to stand on the shoulders of giants and glean what they can from those around them. Thankfully, the web is flowing over with tutorials, articles and comments in general about the development methods and languages of your choice.

I want to focus on the PHP community here – I know it best. So, what can you, a member of either the general web or PHP community do to help the cause? Here’s a few suggestions:

  • Share a tutorial – just learned something awesomely cool as a part of the work you’re doing? share it! Trust me, you don’t have to be eloquent to make a good tutorial author. All you have to do is be willing to copy and paste a bit of code and explain it. No, really – it’s that easy, I promise. Post it and they will come, especially since Google Finds All. The best part about sharing knowledge is that it keeps it from dying. If you keep all the cool stuff to yourself, the community as a whole suffers. What to make the community flourish? Spread the word!
  • Share the code – this one’s pretty obvious…write some code and share it with the world. This can go hand-in-hand with my first example, but doesn’t always have to. To coders, sometimes how the code all works together is more interesting than reading an article about it. They’re the ones that immediately download the source of a new, cool application just to see the pieces mesh. The comments in the code are enough for them to know what’s going on (you do comment your code, right?) and they like it that way. Put your code out there for the world to see – it doesn’t have to be perfect. In fact, it’s usually better if it isn’t…more room for contribution!
  • Be a mentor – believe it or not, there’s a little bit of a mentor inside each developer out there just begging to get out. The second you switch from writing the code to showing someone else how to use it, you’re being a mentor. Most people think that mentors have to be experts in their field and know-it-alls. The real truth is that anyone – and I do mean anyone – can be a mentor. This goes hand-in-hand with the two previous points in my list and can provide the human connection between them. Write the code, write the tutorial and be there when others have questions – either via email, in-person or on something like IRC. Everyone has something to give back because everyone has different experiences. You may know the best practices for combining Oracle and PHP while another developer might know the ins and outs of your PHP-based content management system. Join forces! All of a sudden the knowledge grows and you both are learning from each other. Thankfully there’s groups like the PHP Women that have forged the way and have set up formal mentoring programs to help spread the knowledge around.
  • Share yourself – Don’t feel like you’re qualified to be a mentor? Think your code isn’t quite where it needs to be to release it? You can still contribute! Trust me, there’s a lot of developers out there that can do some good works just by being there and being themselves. It takes all kinds to make up a community and not everyone can be all about the code. Yes, I know that PHP is a language and that it’s really all about the code (or is it?) but there’s plenty of room for those members of the community that focus on the community. They’re some of the glue that holds things together and can most easily be identified by keeping an eye out at conferences and other social gatherings (like your friendly neighborhood PHP user group) for the social butterflies. They know their code and they know the community – they’re just happy to bring the two together. Becoming one of these sort of people is easy…don’t try to. Just meet people, talk with them and enjoy being around them. All it takes is one “hello” and you’re on your way…

These are just four points out of a long list of ways that you can give back. There’s a huge list (maybe I’ll add another list in the future), but this’ll give you a good place to start. Don’t be afraid to put you and your code out there!

1 comment » | Community, PHP

PHP is the Future

August 12th, 2009 — 10:09pm

Catchy title, eh? I have to admit, I used a bit of an inflammatory title to pull you into the rest of the post, but I think you’ll like what I have to say. The title is true, but probably not in the way you think. No, PHP is not going to be the language that comes out on top, not the “one language to rule them all” sort of thing. Instead, I’m proposing that PHP, the flexible and powerful language that it is, has a very large roll to fill in the future of the web.

There’s lots of little things that the language has done along its life to help make the world wide web a better place to live. Most importantly it’s given the world an Open Source alternative to some of the other closed languages that some of the major companies of the world offer (okay, so I’m pretty transparent). PHP packs a lot of power in a little package, and the general developer community has definitely taken notice. This plucky little language that started as a handy tool for Rasmus to keep track of things in his personal pages has evolved into something that major companies around the world are implementing into their core software. Hear that? *Core* software. PHP isn’t some fly-by-night language that’s the latest fad being passed around like so many YouTube videos. PHP is strong, its powerful and it is most definitely here to stay.

But I digress…let’s get back to the point that the title of this post was trying to make. PHP is the future. No really, it is – trust me on this. Of course, there’s a difference between being the only path to the future and one of many means to getting there, but we’ll toss that aside for now. We want to focus on PHP and what it can do to make all three Ws in the WWW a better place to develop.

So, lets talk a little bit about what PHP has to offer to the world at large.

From its humblest of beginnings, one of the core values of the PHP project has been to provide the most power in the best code possible. Sure, it has its quirks and it can be a little rough around the edges, but line of code for code, PHP packs some serious features into a neat little package. There’s even the extension system that makes it super easy to add in new bits of functionality without even having to recompile the main engine. Oh, and did I mention it’s free? Open Source, well supported and very very popular among both the usual Open Source crowd and among other certain large entities (even those that might live in Redmond)

Every time I look the future of the web (linking services, making things seamless, integrating technologies), I can see PHP at every major crossroads. Its the flexibility of the language that does it. Sure, there’s still a bit of a niche that PHP fits into, but once you take a step out of that safe little shell, you really start to realize what the language has to offer and where it fits in the world. PHP has the potential for being the glue that binds the web together. There’ll always be other languages out there – to dismiss them would just be silly – but PHP, with its flexibility and power really has the feature set to help propel Open Source web development into the spotlight and shine for what it is.

The web needs a language that’s quick to adapt, easy to configure, comes in at a low cost and is popular enough to find good, talented developers for (yup, that’s a big point too). If you ask me, PHP fits all the above and more.

I believe that PHP can be the future of the web and be a key player in the web applications to come.

14 comments » | Community, Deployment, PHP, Solar

What Firefly/Serenity Can Teach Us About PHP

August 8th, 2009 — 8:49pm

At the risk of alienating some of my readers out there…who am I kidding – most of you liked Firefly, didn’t you? Having just watched Serenity yet again and recently seeing several episodes of the canceled-before-its-time series Firefly, I noticed that there’s some similarities between it and PHP as a whole. So, here’a quick list of a few I’ve noticed – feel free to add some of your own in the comments:

  • Just because it’s not the latest and greatest version, it doesn’t mean it’s not good. Sure, everyone wants to run on PHP 5.3 – we all love the thought of late static binding, namespaces and the whole list of lovely enhancements that come with this latest PHP version, but for some it’s just not a reality. Most of use are using a ship…er, code that’s been around for a while (except the fortunate enough to be doing new development each time) and has been coasting along in the land of PHP 5.2.x series. It’s not the latest model and it’s probably going to take a little doing to get up to the sort of things PHP 5.3 has to offer, but that’s not an excuse to abandon the code and not try to get as much out of it as you can. Squeeze that last boost that caching that data gives you, refactor that part of the code you just found a better method for – but don’t forget where the code came from and all that you’ve been through to make it exactly what it is
  • Just because you don’t understand something, it doesn’t mean you shouldn’t embrace it. Sometimes the real power of something sits just under the surface and without really getting to know it, you might miss out. Much like the skills of a certain female in the TV/movie, only the right situation brought out the real value of her skills. There’s features in PHP that you might now be using, but don’t dismiss them just because you haven’t used them before. Sometimes there’s a hidden gem in there that you might not see unless you took the time to check it out. So you’ve been using simplexml for a while? Why not see what kind of things XMLReader can do for you. Never checked into the Standard PHP Library? You should! You might never know what you’re missing out on unless you look around and find the right PHP pieces for the right situation.
  • There’s nothing stronger than a bond between those who care. Much like the crew of the Serentity, there’s nothing more powerful than people helping others when they really care about the outcome. A lone PHP developers is only as good as his own skill level. As soon as he reaches out to other developers, he interacts with a whole new skillbase and a whole world of new people. It can be posts on a forum, chatting in IRC or even attending a conference – as long as the bonds are formed, that developer has something more than they did before. Before long, they’ve made connections with other developers with other skillsets that can help to broaden their knowledge and make them stronger as developers.
  • It takes all kinds to make the ‘verse go ’round. Despite what those hiring PHP developers lately want to think, there’s divisions in PHP developers in the same way there are in any other social group. Some developers focus on how the language works and adding features the entire web will enjoy. Others look at the current feature set and think of ways to to squeeze every drop of performance out of it. Still others are working their way up, trying to do their best with the code they’ve been given. PHP developers are as varied as population in general, and it’s definitely a good thing. The PHP language will only develop into something even more robust with a panel of varied developers at the helm.
  • Use only what you need. Just because there’s something out there that’s shiny and looks good to use, it doesn’t mean your application really needs it. Remember, the real key to applications is the performance – that’s what the world tests it on. Don’t worry about the latest and greatest if it’d not going to help. Features shouldn’t be included if they’re not needed – they’ll only cause trouble otherwise.
  • A good team is nothing without good leaders. The PHP community has some excellent “captains” at the helm – people like Cal Evans, Keith Casey, Eli White, Derick Rethans, Andrei Zmievski, Chris Shiflett and Stefan Koopmanschap have helped to shape the PHP language and community into what it is today. There’s countless others (largely ones with the CVS….er, SVN access needed to make updates to the C code that powers the language) that have made their marks on PHP to help it grow and evolve into the powerful development language that it is.

As it can be said that life imitates art, so it can be said that programming, in this case PHP development, shows the same strong points as those that flow from the mind of Joss Whedon – emphasizing the good, venturing into the unknown, the power of a human-to-human bond, diversity is good, use just what you need and, of course, a community is only as good as those who lead.

5 comments » | Community, PHP

Back to top