Month: August 2009

(More) PHP Worst Practices

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!


PHP Worst Practices

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.

Mom Always Said to Share

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!

PHP is the Future

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.

What Firefly/Serenity Can Teach Us About PHP

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.

Search or Settle?

Let me start by posing a question to all of you other groups looking for PHP developers right now – should we just settle?

Sure, I’d love for that perfect candidate to come walking through the door, shiny resume in had that fits close to what we need (no, I’m not naive enough to think they’ll be perfect). We could sit there in the interview and he or she could give all the right answers in all the right places. The choice would be easy and, with a few shaking of hands, the deal would be sealed.

If that’s your impression of hiring a developer, you’re in for a serious kick in the shins by the software development industry. Right now (and it seems especially right now) finding good developers is even harder than the needle in the haystack trick. I’d go so far as to say that, for the parameters that most companies can afford, there’s almost no good, skilled developers out there – the real problem there being that pesky S-word.

If you’re not at all concerned about code quality or serious development, by all means hire the next interviewee that walks through your door. Don’t check his criteria, don’t look at his experience and by no means ask him any questions about how many years he’s been developing PHP. Now, a skilled developer, on the other hand, is something that should be sought after and held onto as long as possible. They’re the ones that will think about the structure of the code they’re writing and continuously look for ways to improve the application. As I explained it to a coworker of mine:

“You want a developer, not a hobbyist.”

I’m not saying that kids fresh out of school (or whatever) are to be discounted because they don’t have much development experience. I will say to be careful with them, though. As anyone that’s worked in development can tell you, there’s just that “something” you can see in the eyes of a developer when they talk about the technology they work with.

So, back to my dilemma – how to find a good developer in a wasteland of good talent. After a few interviews with widely varying candidates, I’ve been getting a bit more discouraged, but I just have to keep reminding myself of a few things:

  • Don’t be too picky (except on the important stuff)
  • No matter what the resume makes you think, don’t assume
  • Remember your roots, assess them based on theirs
  • Don’t settle.

Yes, I know I’m sort of answering my own question, but that doesn’t stop me from asking it. You go through enough applicants and your have to start wondering…

“Done done”

As I’ve been reading through “The Art of Agile Development” (from O’Reilly, by James Shore & Shane Warden) there’s been a whole load of great suggestions for development practices and not all of them are restricted to an “Agile Only kind of world. One of the major ones that’s stuck in my head (and is repeated quite a bit in the book) is the idea of being “done done” in your development.

The average PHP developer seems to say they’re “done” when the code works from their simple testing, usually just entering values to ensure that things work correctly. I hate to break it to them, but this shouldn’t be considered done. Getting the code working correctly is only the tip of the iceberg – there’s so much more to do to get everything ready to deploy. Besides the code being complete, “done done” also means:

  • Having documentation, both in the code and about the code. If future generations of developers were to come around and need to update your code, good documentation is a must. One line comments aren’t going to cut it…at the very least use something like the formatting for phpDocumentor to provide some automated docs
  • Making those unit tests pass every time is essential. (You do unit test, don’t you?) Writing tests for all the bits and pieces of your application may be a pain, but it can save you in the long run. Imagine being able to fire off a test suite and being confident that those changes you just made haven’t broken anything.
  • The code has to work in the build for your project. Some projects are small enough to where they don’t really need a build, but if your project is much more than a simple site with a database backend, you could benefit from a build[1]. Developers should be able to do local builds to check their work prior to a commit and push.
  • I must fulfill what the customer wants in the update or new feature. Sometimes, it just happens – you get to writing your code and you think about “this one cool feature” or “that other fun thing” that PHP makes so easy. You wonder why the customer didn’t want that in the first place. Be very careful with thinking like this, it could lead to some pretty random stuff in the end. In the end, the customer needs to be happy with what you give them – be sure it’s what they asked for (user acceptance testing).

Being “done done” means that, if you handed over your code to the testers or even the end customer, you’d be confident that it works and is ready to be integrated. Sure, it’s about the code being tested and correct, but its also about making it behave as a part of the larger whole. Your code (code ownership is a whole new can of worms) shouldn’t be viewed as “this part that does this” but more of a piece to the larger puzzle of you/your team’s application.

[1] What’s a build? A build lets you automate several things you might currently do by hand to get your code ready for production. This can include things like: building out databases, minifying code, running unit tests and checking syntax on all files to be pushed.

Working with WebTests (Help?)

Well, I wish I could say that this was going to be a guide to getting WebTests (an automated front-end testing tool that sits on top of Ant) but it seems as though I’m having a bit of a Java issue to content with myself.

Here’s what I’ve done so far:

  • First, I noted happily that Ant was already installed on my MacBook’s OS X install (seems a strange choice to have bundled, but who am I to judge), making for one less thing that I’d have to get up and running
  • Next I grabbed the latest install of WebTest from the Canoo website and unpacked it to a testing directory. It comes as a nice, neat binary so there’s no messy compiling to worry about.
  • I wrote up a simple test and PHP page to try it all out:


  • Finally, I gave it all a whirl: “bin/webtest -buildfile /my/path/mybuild.xml

This is where I hit the first snag…apparently since OS X’s Java install is just a bit different than some of the normal ones, a few of the files aren’t where they need to be. In my case, I was getting an error:


After poking around a bit on the web, I happily came across this that recommends copying a jar file over to the Java extensions directory. A simple “cp” later and the build made it past that point. Unfortunately, not much past it, though – another Java error popped up that seems a bit more difficult to find information on:


So far I haven’t been able to find much that’d help me solve this one, so if there’s anyone out there that’s seen it before, help would be appreciated. It seems like it actually runs the test just fine (according to the output reports) but it’s not very useful if the build always fails.