Upon hearing about a Manchester-based PHP conference, I got quite excited; often conferences of this ilk are very expensive and once you factor in the travel/accommodation expense applicable to visiting London/Brighton/Dublin etc they quickly become unaffordable so a relative inexpensive conference on my doorstep was not to be missed.

What was good

• The price: Early bird tickets were only ÂŁ52.25 – tremendous value
• The freebies: Lunch was provided, lots of people won free books and there was also food and free drinks after the conference (although I had to miss that)
• The organisation: This was a very well run event. I’m no conference whore but I have been to a few before and PHPNW was certainly the best organised I’d been to.
• Two tracks of talks meant that there good choice of what to listen to.
• I won a book (or James sat next to me did, but he already owned it and gave it to me)
• Lots of developers from all over the place. I had expected this event to be Manchester-centric but I met people from Ireland, Europe and I was really impressed by that.

What wasn’t as good

I don’t wish to appear offensive or ungrateful here, as I thought the conference was great but my biggest grumble was a lack of verve from some of the speakers. The topics of the talks were great – I was really looking forward to hearing them, but I found myself struggling to stay awake in some. The speakers were all very professional but I didn’t get the feeling they had done lots of speaking events before – the presentations were mostly bullet-pointed powerpoint slide and a lot of the speakers appeared slightly nervous.

I’m no fool, I understand that the price of the tickets means Zeldman or Kevin Rose aren’t going to show up and wow us but I did feel the presentations that I saw lacked a little personality. Often, the presenters only came alive when the time came for questions at which point they became much more lively and actually seemed to be enjoying themselves.

It takes a lot of balls, to stand up in front of room of nerds and present your expertise – it isn’t easy and I respect all the people who did it on the day.

Disclaimer: The conference had two tracks and for all I know, the talks I didn’t go to could have been fascinating and full of beans.

PHPNW 2009

I hope there is a PHPNW 09 conference, I think the inaugural event has set some great groundwork and I fully believe any teething problems will be fully ironed out for next year.

There is also undoubtedly scope to increase the capacity of the event: I named-dropped PHPNW 08 quite aggressively to as many PHP developers that I came in to contact with prior to the conference but in the end I only saw one developer I knew there. I’m not sure what happened there -Â maybe people didn’t get to hear about this conference in time, but by next year I’m sure a bit of buzz will have been created by PHPNW 08 and the interest will be much higher.

Your opinion

Did you go to PHPNW 08? What did you think of it? Will you be attending PHPNW 09?

Whilst developing, Bean Counter, the one feature I’ve been most paranoid about is the PHP code quality. I certainly don’t consider myself to be the greatest PHPer in the world and I have this sense of foreboding, that when I finally release this app, the general consensus would be ‘Phil Thompson writes rubbish code’. If this app is successful then its code will be exposed to the criticisms of lots of PHP developers and they can be a cruel and unforgiving bunch.

These past two weeks, I’ve gone some way to ridding that feeling in the pit of my stomach by improving the app’s folder structure by I’ve turning it into a far more MVC-styled system. To be fair, it always was leaning towards MVC (even now it isn’t 100% of the way there) but I feel a lot more confident in it – it’s certainly a lot cleaner to look at.

Bean Counter file structure

• application
  • .htaccess
  • ajax
  • behaviour
  • class
  • controllers
  • images
  • inc
  • style
  • views
    • common
    • forms
    • layout
• site
  • .htaccess
  • cache
  • downloads
  • index.php
  • local_files.php

You may notice it takes a lot of inspiration from frameworks like Zend, Cake, etc. There is a solid reasoning behind this wholesale thievery; its familiarity should hopefully make developers, who download it, feel more comfortable with the codebase.

The idea behind this app is that it should allow easy updating/editing for people’s individual requirements so modelling it on a conventional MVC structure makes sense.

Some weirdness explained

The images, style and behaviour folders are in the application folder whereas the cache and downloads folder are in the site folder – they should be the other way around (and would be in normal circumstances) but all the beta testing so far been on my server and so by swapping these folders around, from their usual location, has allowed me to share the application folder between multiple installs whilst making sure the cache and downloads folders are unique to each install.

The file local_files.php takes requests for CSS, JavaScript, and images from mod_rewrite and routes them through the application folder’s relevant structure.

What no models folder?

Models live in the class folder. Not all classes relate to models so, yes, I know this is bad form and I should separate them out again but at this stage I think classes that relate to database models and classes that relate to the application’s functionality are best left together.

So when is the release date?

After months of inactivity, I’ve started working on this app again and its currently in another round of beta testing which I hope will only uncover minor bugs. I think I’m quite close to a release date, I have the following things left to do:

• Finish the sales site
• Write help documentation
• Decide whether it’ll be free or not
• Beta test people installing the app locally/on their own servers

Prevention is better than a cure

If I have to spend a long time debugging IE6, it’s likely it’s because I’m fixing someone else’s code. There are certain procedures you can undertake when writing your CSS which will make sure IE6 headaches are kept to an absolute minimum and unfortunately, not everyone knows about them.

Rule 1: Reset those default styles

Prior to resetting styles, I used to get all kinds of problems cross-browsers with IE and Firefox. I started off using this:

*{
margin: 0;
padding: 0;
}

before moving on to the YUI reset and then finally settling on Eric Meyer’s Reset.

Rule 2: Don’t declare margin/padding and width on the same item

You must have been living under a rock, if you don’t know about IE6′s crappy box model. If you need to set a width on an item try not to set a margin/padding (on the left or right) on it too. I get round this by declaring padding/margin (depending on the design) to my <p>,<ul>,<table>,<hr> , etc elements.

In most cases, a designer will set the same guttering on all text on a page – anywhere from 8px to 20px (but often 10px) so:

p{
padding: 0 10px;
}

is often a great trick. Side note: I’ll always use pixels for the left/right margins/padding because as soon as you start to use ems, you can get discrepancies when you have items in the same <div> with differing fonts sizes.

Rule 3: Use valid XHTML/HTML

I’ve lost count of the times, when I’ve struggled with a layout that looks perfect in Firefox/Safari but awful in IE6. If it also looks crappy in IE7 then more often than not the HTML will be invalid with a > or a < missing. For some reason, the other browsers allow this kind of thing to go by unpunished but IE is a stickler for the rules.

I use the HTML validator Add-on for Firefox to let me know if my pages are valid.

Rule 4: Float nearly everything

When I write CSS I make sure virtually all my elements are floated – this works fantastically provided designs are of a fixed width – if they’re not a fixed width (they should be – but let’s not get into that) then you’ll need to use the clearfix solution (a lot) because if an item is floated and its parent element isn’t floated too, the parent element will forget its responsibility to be at least long as its child elements.

Debugging

I have over 3 years of IE6+CSS experience so I’ve seen most problems – and instinctively I know how to fix most issues I stumble across, but there are times when I can’t fathom what’s wrong. When that happens here’s what I do:

• Load up Windows XP in VMware Fusion (OS X) which is better than Parallels (in my opinion)
• Load up Internet Explorer 6
• Make sure the IE Accessibility Toolbar is installed
• Use the Edit CSS option in the toolbar
• Then I start the ‘magic’

Trial and error

More often than not, problems in IE6 are caused by the width of items. An item one pixel too wide will knock columns underneath each other, but it can be hard to work out which element is causing the extra width.

Background colours

I’ll often set a background colour on major structural elements

#content{background-color: red;}
#sidebar{background-color:blue;}

This lets me see which element is causing the problem.

Hide elements

Then I’ll start to hide elements, starting with the biggest surrounding <div> and working my way in. So if I start with:

#sidebar{display: none;}

the problem should vanish (along with most the of the page) but does the problem still go away if I try the following?

#sidebar .sub-item{display: none;}

or

#sidebar .sub-item .sub-sub-item{display: none;}

Using this method I can establish which item is causing the problem. Often it may be a <div>, a <p>, or another item nested several layers deep.

Checking for solutions

IE6 is an outlaw; it often invents its own rules by which to render CSS. Once I’ve discovered a problem element, there is often no rhyme or reason why it is causing a problem so I’ll try the following rules:

#sidebar .sub-item .sub-subitem{
position: relative; /* try setting this if it's not already set - it sometimes works wonders */
display: inline; /* display: inline often fixes the double margin float bug and */
display: inline-block; /* Sometimes this just fixes problems - no idea why */
margin: 0; /* margin can be a killer so take it off completely see if the problem goes away */
padding: 0; /* same as margin */
background-color: transparent; /* Sometimes IE6 hates background colours not being declared */
overflow: hidden; /* can sometimes stop columns too wide from breaking a layout */
zoom: 1; /* Sometimes forces hasLayout and fixes things */
}

I’ll often experiment with a few of these different rules with margin or display being my most popular problem solvers. I’ll also check Google for answers to see if anyone else on the web has encountered a random bug.

Fixing

Once I have my solutions I’ll put them in a separate stylesheet often called ie6.css and include it onto a page with a conditional comment. Making sure it is the last stylesheet imported/linked on the page. This is better than putting your fixing in with the rest of your CSS as it allows you to manage it better – that’s my opinion anyway.

Summary

That’s how I debug CSS in IE6. Do you have a similar method?

Google Chrome is only available for Windows right now so Mac users will have to wait for the time being. Although to be honest, Google Chrome isn’t enough to switch people from Safari nor Firefox for that matter. However, it is more than enough to encourage people to switch from Internet Explorer 6 and 7.

As a developer, I’ll continue to use Firefox (for now) because the Web Developer toolbar, Firebug, LiveHTTPHeaders and all the other add-ons are just too good to be without.

Target market

Where I hope Google Chrome (terrible name by the way), will catch on is with a less technically-minded audience. Provided Google can convince them to download it (and if anyone can Google can) then this will be a major success that could really reduce the number of people using Internet Explorer to the minority.

Appearance

Some people have criticised the new browser’s looks but, for me, I think it looks just fine. It doesn’t look garish nor does it look boring and I think it will appeal to the audience it is aimed at perfectly.

I do think that the choice of name, Chrome, is a bit bizarre. Safari, Netscape and Internet Explorer are great browser names – they give the user the idea that they are exploring the world which is what you do when you go online. Internet Explorer is an especially great name, because it literally tells the user what it is for whereas Chrome doesn’t at all but as the Chrome brand develops this will probably become a trivial non-issue.

Usability and speed

I can’t really fault Chrome for how it works. Prior to downloading it I thought having the tabs above the address bar would be weird but it isn’t at all. In fact, it may more sense in many ways. In terms of speed, I haven’t noticed it to be particularly quicker than other browsers but then I haven’t used it extensively yet.

What do you think?

Have you downloaded Google chrome yet? What are your thoughts?

What the test involved

Did I say test? Actually it was more like a challenge and no I won’t tell you what the challenge was nor who the agency is so as to save them having to change their test. Suffice to say, the challenge was to create a PHP version of a simple game.

They didn’t ask me to perform the challenge there and then – they asked that I go away and have a solution within a day or two. This first part of the challenge is all about time management and ensuring the employee is capable of meeting (relatively) simple deadlines.

After getting over my initial frustration and bewilderment, I thought, ‘How dare they ask me to do work without paying me!’, ‘Don’t they know how busy I am?’. Once I started the assignment, I discovered that I actually loved doing it. Although, the agency stated they were more interested in how I went about the implementing the game (in an MVC fashion) – if I did 30 minutes work in the right way and it wasn’t finished – that would be better than spending 4 hours, getting it to work but in the wrong way. I actually wanted to get this challenge finished to perfection but I wonder if that says more about my personality and than the test per se.

The advantages of testing

I fully understand why these guys test their programmers, they’re a very busy web agency, producing top level work, and they need experienced people to hit the ground running. They don’t want to hire someone who talks the talk in the interview but on their first day they admit to not knowing any PHP5 or CSS.

The more Manchester web agencies I speak to, the more I hear the same thing – that they are struggling to find good web developers – to be honest, a lot of them are struggling to find bad web developers. Although testing potential employees might not gain you more applicants it could get you better employees and enhance your reputation amongst developers as an agency where they want to work.

Since working at this agency, I’ve seen quite a few developers and they all seem to know their stuff. I’m convinced (and so are the agency in question) that this test is responsible for weeding out any bad apples who otherwise may have found themselves employed.

Summary

If I had a web agency would I challenge the programmers before hiring them? Yes, I think I would unless I had already seen their code and knew it was up to scratch.

Have you been tested before starting a job? What did you think of the process?

I must admit, my working arrangement is downright bizarre – my employer Soapy Co Ltd allow me to work from home and pay me a salary but they also allow me to spend 20% of my time (the equivalent of 1 day a week) on my own projects. This allows for a couple of distinct advantages for me and them.

1. Allows me to experiment with new ideas
2. Allows me to freelance with other agencies and gain more experience
3. Allows me to fit work around my life

The most important thing my employers care about is that my work gets done – and it does. So does it matter whether I sit still from 9am-5pm spreading out my tasks so they last a full working day or is it more important that I get done what needs to be done on time?

Experimenting with new ideas

Whilst writing Cart45, I was simultaneously writing Bean Counter, this allowed me to experiment with new ideas and techniques in Bean Counter that if successful could be transferred across to Cart45. As Bean Counter is all my own, I haven’t been constricted to any deadlines (except my own), which has enabled me to be less stressed about how quickly I developed it. This in turn, meant I could concentrate on ensuring the code looked good and worked well regardless of how long it took – whereas with Cart45 it is always a rush to make sure the product works as quickly as possible. That’s simply the nature of a commercial product whose sales will guarantee the success of its parent company.

Freelancing

This unique working environment allows me to freelance more and more than a 9-5 office job would. As I mentioned above, provided my work is done my employers don’t care what hours I work. If I wish to blitz an entire week’s worth of projects over the course of 2-3 days I can – often I choose not to because when I take into account the cost of the RedBull and ProPlus it works out unprofitable in most cases.

Blitzing the odd week does allow me to get some freelancing for other agencies done – it even enables me to work onsite when required. Getting out and about and seeing how other people operate is massively helpfully to my career development and any insights I can gain can be taken back to my employer to help improve their practices.

Fitting work around my life

Doctors appointment, hair cuts, trips to the butchers/fishmongers – all these errands used to be crammed into the weekend leaving me with no time whatsoever to relax, but because I now work from home I can do these things quickly during the day without losing much productivity and in fact, it helps me to take my mind off programming.

We bought our first house 20 months ago and we’ve been renovating it ever since. Working from home has definitely sped up the DIY a lot. If I’m stuck with a certain aspect of Cart45 development I can go off for 20 minutes and paint some walls or sand down a banister and that little break clears my mind and often helps me solve my programing problem.

FAQ

Friends and co-workers often have these similar queries about my work situation:

Is it hard to motivate yourself when you work from home?

Actually, it’s surprisingly easy to motivate myself and I don’t think I’m atypical here, just ask my parents – they used to tear their hair out over my unmotivated approach to school and life. In my opinion, you have to be a lot more motivated to physically get up and get yourself out of the house on time every day regardless of the weather or how you’re feeling.

Do you spend all day working in your underwear?

Yes. Monday-Thursday it’s high class Agent Provocateur and Friday’s is casual big pants day. Seriously, though I try not to work in pajamas and dress as I would if I were at the office. This approach seems to make me concentrate a little more – although it may be (more than) a little psychosomatic.

Is it lonely?

Yes sometimes it is. I can go full days without talking to anyone except my girlfriend once she gets home from work. Freelancing on-site for other agencies can help to break up this monotony.

Do you lie in everyday?

No. As a teenager I could sleep-in until mid-afternoon but those days are now long gone. Nowadays, I find myself most productive in the morning and the later I sleep in, the later I want to go to bed at night and as my girlfriend starts work at 8am it make sense to try and keep our bod clocks in time.

What about you?

Do you work from home? What are your experiences like?

What went wrong?

I made a few mistakes in terms of the testing.

• I accepted anyone into the testing programme
• I didn’t create a set test plan for them to follow
• I didn’t provide any clear feedback procedure

The biggest error of judgement was simply to accept anyone who wanted to test the application. In reality, it only makes sense to test people who will either test the application really strongly and try to break it or people who form part of your target market.

I chose people who, despite their enthusiasm, didn’t actually do very much testing. Sorry guys, if you’re reading this but here are the stats:

• 10 beta testers
• 5 didn’t even look at their test page
• 4 people installed the system but didn’t get any further
• 1 person installed the system went away and logged back in the following day

These stats left a problem – what were the reasons behind their lack of interest once being given the keys? It could’ve have been a number of reasons: a lack of time, a confusing application, a lack of a test plan. At this stage I do not know why.

I was so excited that anyone wanted to beta test my application and give up their time to help me for nothing. Beta testing does seem to create a buzz and if someone asked me to beta test a new web app that looked remotely interesting – I’d probably agree too – but I’d probably also lose interest when it quickly became obvious that I’d have to put some effort in for literally no reward.

No test plan

I suspect a missing test plan didn’t help. I foolishly asked people to simply play around with the system and casually email me back with their thoughts. This isn’t a good way to do things – without some kind of formal procedure, people are unlikely to test an application properly add to the fact that these testers were vetted – I have no idea if they wanted from the system what the system was offering.

No feedback procedure

By failing to create a formal procedure for feedback and relying upon casual email correspondence, meant I got very little feedback from the testers. Nobody emailed except maybe to say it was good or ok. Which when you’re trying to find bugs and see how useful something is – isn’t very helpful.

What I should have done

Next time I beta test anything, I’ll be choosing the testers very carefully and finding some way to reward them properly. I’ll be creating a test plan and asking the testers to make sure they perform a few key tasks and finally I’ll be writing some forms (preferably built into the application) that allow for quick and easy feedback possibly in a questionnaire format with simple options.

The (almost complete) failure of this test was my fault and not the testers’ and I don’t want to appear as though I am blaming other people for the mistakes I made.

There was one saving grace from the trial, I did learn that my installation technique for multiple customers needed improving, which it now has. At the start of the trials, setting up a new account took about 20 minutes whereas now it takes 5 minutes.

In a bid to make my PHP code even more readable I’m dumping the curly brackets traditionally used with control structures (e.g. ifs, fors, switches) in favour of the colons and semi-colons of PHP’s alternative alternative syntax for control structures.

PHP’s traditional syntax for control structures – with curly brackets {}

1. <?php
2.  
3. // If statement
4. if(1==1){
5. doSomething();
6. }
7. else if(1>1){
8. doSomethingElse();
9. }
10. else{
11. doSomethingSpecial();
12. }
13.  
14. // For loop
15. for($i = 1; $i < 5; $i++){
16. echo $i;
17. }
18.  
19. ?>

Upon quick glance the usage of curly brackets it is obvious which bracket belongs to which control but it soon becomes more difficult to read when functions/methods are thrown into the mix and lots of nested controls exist.

Too many curly brackets {{{{{{}}}}}}

1. <?php
2.  
3. // Nested if's and foreach's statement inside a function
4.  
5. function myFunction(){
6. if($trees == 'green'){
7. if($trees > $children){
8. foreach($array as $key => $value){
9. if($trees != 'dead'){
10. doSomething();
11. }
12. }
13. }
14. else{
15. doSomethingElse();
16. }
17. }
18. else{
19. doSomethingSpecial();
20. }
21. }
22.  
23. ?>

The example above, shows it becoming a little more difficult to follow which bracket refer to which control. The very fact that my method of displaying code samples (codeviewer) removes indentation/tabs from the code makes this even ore evident.

PHP ‘s alternative alternative syntax for control structures :;

1. <?php
2.  
3. // If statement
4. if(1==1):
5. doSomething();
6. elseif(1 > 1):
7. doSomethingElse();
8. else:
9. doSomethingSpecial();
10. endif;
11.  
12. // for loop
13. for($i = 1; $i < 5; $i++):
14. echo $i;
15. endfor;
16.  
17. // nested if statements inside a function
18. function myFunction(){
19. if($trees == 'green'):
20. if($trees > $children):
21. doSomething();
22. else:
23. doSomethingElse();
24. endif;
25. else:
26. doSomethingSpecial();
27. endif;
28. }
29.  
30. ?>

For me, I find this so much easier to read. Replacing the last curly bracket (}) is a statement of the following endif;, endfor;, endswitch; etc. This means there less confusion as to what things are referring to.

Summary

It is imperative to write code that makes sense for other developers in your team or for the developers will inherit your code.

I find this alternative control structure much easier to read but what do you think? Do you find it easier or harder to read?