First, you setup the URL pattern to trigger a callback function:

$items['product/%/add'] = array(
	'page callback'		=>'djg_add_product_to_basket',
	'type'			=>MENU_CALLBACK,
	'access arguments'	=>array('access content'),
);

Next, I setup a simple callback function, which would get the Node ID from the URL, and pass it to the uc_cart_add_item function and then redirect the user to the checkout.

function djg_add_product_to_basket() {
	$parts	= explode('/', $_GET['q']);
	$nid	= $parts[1];

	uc_cart_add_item($nid, 1);
	drupal_goto('cart/checkout');
}

I tried this, and it seemed to work, however I later realised that the delivery pane had been removed from the checkout. Several searches later, and all I could find were people with similar problems, but in their case it was because the product they wanted to buy wasn’t shippable.

Some more digging around, and I found that when you add a product pragmatically using uc_cart_add_item, it doesn’t pick up the shippable status from the product node.

The solution is to explicitly set the product as shippable using the third parameter, which is attributes, so the line of code should look like:

uc_cart_add_item($nid, 1, array('shippable'=>true));

query_posts(array(
	'post_type' =>'page',
	'meta_key'  =>'_wp_page_template',
	'meta_value'=>'page-portfolio.php',
));

It may have once been useful to be able to just specify the page template in the query with an additional parameter, but I feel the widespread need for this is now gone, as many cases which would use this can be done better using Custom Post Types and a custom archive page.

If we wrap this logic up in a function, it will be able to automatically display either just the single, current year, or a range from set year to the current one. Below is such a code snippet and examples of how to use it.

/**
 * Return the given copyright string, with an auto updating year
 * Will either return the single, current year, or a range if a start is supplied that's not the current year
 *
 * Examples:
 * echo dg_copyright("© Copyright Damian Gostomski %s");
 * Output: © Copyright Damian Gostomski 2012
 * echo dg_copyright("© Copyright Damian Gostomski %s", 2012);
 * Output: © Copyright Damian Gostomski 2012
 * echo dg_copyright("© Copyright Damian Gostomski %s", 2008);
 * Output: © Copyright Damian Gostomski 2009-2012
 *
 * @link http://www.gostomski.co.uk/snippet/better-auto-updating-copyright-date
 * @param String $text - The text using sprintf notation. Use %s as the placeholder
 * @param Integer $year - The start year
 * @return String - The input string with the correct year in the placeholder
 */
function dg_copyright($text, $year = '') {
	// We need to know the current year so we can compare it to the start
	$current	= date('Y');

	// Figure out what the year part of the message should be
	if(empty($year)) {
		$year	= $current;
	} else if($year != $current) {
		$year	= "$year-$current";
	}

	return sprintf($text, $year);
}

The above code snippet is well commented, but if you have any questions or suggestions for improvements, post them in the comments.

This was one of the best talks that I’d attended, despite not being about PHP, but about the problems with estimates and how to avoid them. Rowan wasn’t even shaken by the multitude of technical issues which delayed it, but I’m sure he’d factored in the risk of that happening.

The talk was split into two main parts, starting off with the possible mistakes, and then how to spot problems and resolve them. It’s certainly making a difference in the way that I now handle estimates (something I’ve always disliked doing). At the end of the day, it comes down to a few common sense rules for making estimates and managing risks and estimating appropriately.

Problem – The sales team creates estimates

This is something that everyone who’s ever worked in any sort of commercial environment can relate to, and it was most certainly true for me. I’m not sure if the sales team are just overly optimistic when quoting timescales and costs for a project, or if they think the only way to win the work is to massively underestimate, but it never works out.

The solution to this however is simple, let the person who will be doing the work, and has a much better idea of how long it will take, give the estimate.

Problem – Estimates from a single developer

Even when you give an “educated” estimate as a developer, it’s still easy to get it wrong, which is why you should ideally not get an estimate from just one developer. Ideally the estimates would be made independently and then an average would be taken (although any outliers would be investigated), but if that’s not possible, they should always be reviewed.

Now not everyone is fortunate enough to have other developers with which to review their estimates, but even with just the other tips, you’ll still improve your estimates.

Problem – Estimates from a detailed list of tasks

One of the common guidelines given when estimating for a large job is to break it down into smaller chunks and estimate each chunk. If this gives us more accurate estimates, logic would dictate that further breaking these down to very detailed tasks would yield even more accurate estimates, but unfortunately not.

If you get down to this level, your estimate is almost immediately void, as things always change, but you have misplaced confidence in your estimates as you think they’re accurate to the nearest 30 seconds. This also has the side effect of encouraging micromanagement, which no one wants!

Problem – Estimate in hours

Leading on from the above, estimating in hours not only encourages too much granularity but also doesn’t map to days conveniently (see next point). Think in terms of days, using an increment relative to the size of the project, but no smaller than a quarter of a day, up to a week at a time on larger projects.

Problem – Estimate work in 8 hour days

If you created a detailed list of tasks and durations as mentioned above and then divide the number of hours by 8 to get the duration of a project, you have a problem (or several):

1.       Taking a 9-5 job, you have an 8 hour day, but take out an hour for lunch, and you’re left with 7 hours of “work” time

2.       Of these 7 hours, you can’t work on a single task without any interruptions, breaks or context switches. Every time you switch task or get interrupted, you need to get up to speed again

A developer can expect to get about 6 hours of actual work done on a good day, and a lead developer just 4 hours.

Problem – Just estimating coding time

It’s far too easy to get caught up and just think about coding time, but unfortunately we need to deal with numerous other tasks including documentation (both internal API documentation and end user documentation), testing, deployment etc. On top of this, there will always be bugs and amends (no matter how perfect you think you are) as well as the overhead of running a team project (communication, management etc).

Problem – Waterfall estimates are next to useless

Although most projects involve some amount of boilerplate functionality which is easy to estimate, as you’ve done it a million times over, there’s still a lot you don’t know. With the Waterfall model, there is the “Cone of Uncertainty”. This means that at the start of the project, your estimates will likely be wildly inaccurate, and as you progress closer towards the end, the cone starts to close, and your estimates get more and more accurate. This has led to the growth of agile over the last few years, but unfortunately people using agile think they can’t estimate a whole project at the start.

Solution – The holy triangle

The holy triangle is based on 3 axis, where adjusting 2 affects the value of the third. The possible combinations are:

• Good, fast and expensive
• Good, cheap and slow
• Fast, cheap and bad

Although it is possible to have high quality and quickly, it will be expensive – Something most clients will fail to comprehend.

Solution – MoSCoW

This stands for Must, Should, Could, Won’t and help the client to understand that not all functionality is created equally. Unfortunately a client will initially think that everything is a must, so hopefully the following will clear up what’s a must versus a should, could or won’t:

• Must – Critical to the project, which would be a failure without it. The project could not launch without all the must features implemented
• Should – Most things that the client thinks is a must will actually fall into this category. Although you can launch without these, it’s best to do them if you can, as they will often help improve the usability or make it unique
• Could – These are the nice to have extras, but in no way, shape or form crucial to the project. If there’s enough resource left once all the must and should features are done, you can work on these
• Won’t – No, just say no to these features

So how does this help? Well, you’ll likely have just halved your workload as it turns out you don’t need all the bells and whistles the client thought they needed. It also helps to manage client expectations, because as long as you have all the musts implemented, you can still launch without the rest, reducing the risk of overrunning (for the initial release).

Mistake – Lose track of time

Unfortunately, we’re all terrible at tracking time for 2 main reasons:

1.       We dislike anything that’s not actual coding, so time tracking is seen as a chore

2.       If we’re switching between tasks regularly, the time tracking becomes very fragmented (although in this case, context changes are the bigger problem)

Despite this, it’s important to track time, so that you know where you are relative to your estimates and if they’re accurate. The sooner you can identify a problem, the better.

Mistake – Estimate bugs

By their very definition, it’s impossible to estimate how long it will take to fix a bug, as the exact cause is unknown. I’m sure we’ve all spent numerous hours, if not days, to find a trivial, one line fix. As you can’t estimate the duration of finding the cause of the bug, you need to have this buffer factored into the overall estimate.

Mistake – Not learning from mistakes

At the end of every project, we should review everything that went well, but more importantly, what didn’t go so well. If estimate were under, identify the cause so you won’t make the mistake again. If there was something that took considerable time that wasn’t factored in, make a note do you remember last time etc.

I will write up all the talks I attended in the next few days, and the list so far is below:

• Estimates, or “How to dig your own grave”

I tweeted about this frustration and a few people responded with possible suggestions (here and here), but neither was quite right for me, but it did give me an idea. If all I want to do, is change one CSS rule to reduce the height of the row, I can use the excellent GreaseMonkey extension for Firefox.

I set about learning how to make a GreaseMonkey script, and it’s incredibly simple, as it’s just plain JavaScript. Within 5 minutes I had a working script which done what I wanted.

The GreaseMonkey script can be downloaded here, and the full code is shown below. All it does is create an inline style tag in the header and add the single rule. If I was doing more complex CSS I could load an external stylesheet, but for something this simple, the overhead of an extra request wasn’t required.

// ==UserScript==
// @name           Compressed Reader
// @namespace      http://gostomski.co.uk
// @include        http://www.google.com/reader/view/
// ==/UserScript==

(function() {
var head, style;
head                   = document.getElementsByTagName('head')[0];
style                  = document.createElement('style');
style.type             = 'text/css';
style.innerHTML = "#entries.list .entry .collapsed {line-height: 2.2ex; height: 12px}";
head.appendChild(style);
})();

The above script will allow you to fit as much as 33% more posts in the screen at once.

What else would you want to change with the new Google Reader, as I may carry on developing this script to make Google Reader even better.

Today marks my last day at And Digital. I’ve been here for 15 months, having joined right out of University. At the time, I wasn’t actively seeking employment, as I was freelancing so that I did’t have to settle for “any old job”. After a few jobs at And Digital, they offered me the job, and shortly afterwards, I was a full time employee there.

In my time here, I’ve worked on a wide range of projects and moved from being “just a developer” to having a wide range of roles, and become very competent with WordPress. I’d also started to take on a much more client facing role and been involved in the early, cenceptual phases on many projects?

So, if things are going so well, why move on?

Hello MC2

As of the first of September, I’ll be taking on the role of lead developer at MC2. Just as before, I was never actively seeking new employment, but every one in a while, a great opportunity presents itself – This was such a case.

As well as an element of client work to begin with, there is a lot more to this new role than just developing websites for clients. There will be a heavy emphasis on using the latest technologies and having a much more R&D driven role.

This continual learning and being able to develop to solve both internal needs as well as just building cool stuff for the sake of it appeals to me a lot more than a role in a traditional client service agency.

Due to the nature of the work I’ll be doing, I should also have lots of interesting things to write about, and maybe even the time to write them, so be sure to look out for lots of new, fresh content coming up.

The reasons for wanting to leave can vary from cost, a change in your requirements, or simply a better product/service elsewhere. Whenever you need to switch, there is always a cost associated, be it money, time or both.

At work (And Digital), we’re currently going through a significant change in terms of the services we’re using. These changes include:

1. Condensing all our servers to one, fully managed server from Layershift
2. Migrating issue tracking from Lighthouse and Codebase to activeCollab
3. Migrating our SVN repositories from Beanstalk and Codebase to self hosted repositories

I’ll be focusing on the last 2 tasks, as that’s where the issue lies. Lighthouse allows you to export your entire account as a directory structure with a JSON and CSVfile for each ticket. Although activeCollab can’t natively import this, we have the data in a usable format, and the primary need for this data is archive/backup, as 99% of the tickets are completed.

Beanstalk allows us to download an SVN dump of each repository which we can then load into a new repository using the svnadmin load command.

Codebase on the other hand, doesn’t provide an automated way to export projects or code repositories. I even contacted support who suggested a few tools/scripts which would help, but confirmed there is no official way to do this. And it’s not like Codebase is a new application either, as it’s soon to have version 4 released!

I’ll end with this plea to all web application developers:

The last interaction your users will have with your application is when they leave. You can’t force them to stay with you any longer by locking down all their data. Make it easy for them to leave and make their last impression a good one. This way, they can become your evangelists, as even though you may no longer meet their needs, they will know plenty of people for whom you’d be perfect.

Today I launched my new site, but unlike most site launches, it’s half missing. Currently, the only real content is on the homepage and the blog. There are some screenshots of a few websites in the portfolio section, but the text is all “Lorem ipsum”, as is the about page.

So why have I done it? Why would I take down my existing site and replace it with this one? Firstly, this version has no less content as the old site has almost nothing for the about and portfolio sections. If anything, this site now has more content, as there are an additional 2 blog posts.

But that’s not the real reason for launching my site just yet, it comes down to the key benefits of agile/iterative/release early, release often/call it what you will.

1.       Get user feedback
2.       Changing needs
3.       No such thing as a perfect version 1.0
4.       Time
5.       Motivation

User feedback

User feedback is one of the most important aspects of any project. Without this valuable feedback, anything you do is purely a guess as to what you think the user wants. This may traditionally apply more to software/web applications but I think it works with a web site as well.

So what do you think works well and what doesn’t? What sort of content do you want to see in the coming months? Tutorials? Articles? Code?

Changing needs

Not only would I be second guessing what a users goals are with this site, I would also be second guessing what I want to achieve from it long term. If I wanted to release a perfect version 1.0 and then my needs significantly changed, I would either delay version 1.0, or I would probably have to build version 2.0 while leaving the existing site to stagnate.

This way, I can make lots of small revisions to the site and keep releasing them helping me to change direction quicker if need be and making sure the site is always fresh.

Perfection & Time constraints

I can be a bit of a perfectionist, so much so, that it makes me cringe to have to put a hack in place to meet a tight deadline. I could easily find 100 things that need doing/improving before launching this, and then a hundred more. The problem with this is that it would never be 100% perfect – This, coupled with the fact I have no actual deadline for the launch of this site is a huge issue, one that can be solved by releasing it now and constantly iterating it to make it better.

Motivation

One of the reasons my old site stagnated is because there was never any urgency to do anything with it. It was performing well and generating leads. This lack of urgency means I didn’t find the time to do the things I wanted with it, be it more content, promotion or design tweaks.

Now, I will have to make time, not only for the content but also design tweaks. One thing I plan to do more in the future is split testing so as to get a better understanding of what works well and what doesn’t.

Going forward

Now that this site is up, I can just sit here. First, I’ll be replacing all the “Lorem ipsum” throughout the site, then I have a couple of ideas for some interesting articles/tutorials I’ll be publishing in the next few weeks and also some design tweaks to experiment with, including some more colour options (I have a total of 50 colour options to experiment with).

So, what do you think of the site and my reasoning for launching it in this state? Let me know your thoughts in the comments or contact me.

As part of the registtration process, we collected numerous pieces of information, and many of the same fields would appear in other forms within the site. Why should users who have already registered and given all that infoamtion once have to do it again. In that case, there where up to 8 fields, dependant on the form, which we could hide for logged in users, but in these examples, so as to keep things nice and simple, I’ll be focusing on a single field – The users email address.

The form

To start with, you will need to create a form with at least two fields – An email address and something else (just so we know everything still works and can test it). Embed this form into a test page and test it all working. Also, make both of these fields required.

Hiding the field

To do this, we will need to add some code to the functions.php file found in your theme. If you haven’t got this file, just create it. I’ll start off by showing the code for removing the field, and I’ll then go through it and explain each part.

function remove_fields_for_logged_in_users($form) {
	if(!is_user_logged_in()) return $form;

	$fields_to_hide = array('Email');

	foreach($form['fields'] as $key=>$field) {
		if(in_array($field['label'], $fields_to_hide)) {
			unset($form['fields'][$key]);
		}
	}

	return $form;
}
add_filter('gform_pre_render', 'remove_fields_for_logged_in_users');

We start off by adding a filter to hook into the Gravity Forms core. In this case, we’re using the gform_pre_render filter, which is called nearthe start of the get_form method, which gets and renders the form. This has one parameter, which is the form object we’ll be modifying.

if(!is_user_logged_in()) return $form;

As we want to remove fields for users which are already logged in, the first thing we need to do, is check the user is actually logged in. If they’re not logged in, then we don’t have this information so we leave the form object as is.

$fields_to_hide = array('Email');

Next up, we need to declare a list of all the fields which we want to remove for logged in users. The values in this list need to correspond to the labels of the fields you used when creating the form. If you called the email field something other then “Email” you will need to change the above.

foreach($form['fields'] as $key=>$field) {
	if(in_array($field['label'], $fields_to_hide)) {
		unset($form['fields'][$key]);
	}
}

return $form;

Lastly, we need to check if any of the fields in this form match up the ones we want to remove for logged in users. As part of the $form array passed in, there is a sub array called fields, which contains all the fields which make up this form. For each field, we check if it’s in our array of fields to remove, and if so, we remove it.

Lastly, we need to remember to return the form object.

Testing it

If you now view the form and are logged in, the email field should not be there, where as if you view the form when not logged in, both fields will be there. If you fill out both forms, they will both submit (even though the email, which is a required field wasn’t filled in for logged in users).

However, there is a problem. If you view the entries, you will see we obviously have some missing information, as the email field wasn’t shown.

Filling in the gaps

So now we need some additional functionality to fill in the missing fields, so we have all the information when viewing the form entries. To do this, we need to following code.

function add_missing_fields_for_logged_in_users($lead, $form) {
	global $current_user, $wpdb;

	if(!is_user_logged_in()) return;

	get_current_user();

	$original_form = RGFormsModel::get_form_meta($form['id']);

	foreach($original_form['fields'] as $key=>$field) {
		if($field['label'] == 'Email') {
			$lead_detail_data = array(
				'lead_id'=>$lead['id'],
				'form_id'=>$form['id'],
				'field_number'=>$field['id'],
				'value'=>$current_user->user_email
			);

			$wpdb->insert("{$wpdb->prefix}rg_lead_detail", $lead_detail_data);
		}
	}
}
add_action('gform_post_submission', 'add_missing_fields_for_logged_in_users', 10, 2);

As before, we need to hook into the Gravity Forms core, this time using the gform_post_submission action. By the time this is executed, the form submission has already been saved. The function takes two parameters, the lead, which is the users answers to the form (plus some additional data) and the form, which is the same as before, however the form may have been modified using the above filter.

We need to start by making sure the user is logged in, as there would only be missing fields for logged in users, and we then get all the user details for the current logged in user.

$original_form = RGFormsModel::get_form_meta($form['id']);

As the form which is passed in has gone through the gform_pre_render filter, it may be missing certain fields for logged in users, in this case, the email address field. So that we have the original form, we need to get it directly, using the form ID we’re passed in as part of the form.

foreach($original_form['fields'] as $key=>$field) {
	if($field['label'] == 'Email') {
		$lead_detail_data = array(
			'lead_id'=>$lead['id'],
			'form_id'=>$form['id'],
			'field_number'=>$field['id'],
			'value'=>$current_user->user_email
		);

		$wpdb->insert("{$wpdb->prefix}rg_lead_detail", $lead_detail_data);
	}
}

For each field, check if it’s one of the one we removed. If it is, we need to manually add it to the database linking it to the users lead. Each lead detail as linked to the form and the lead, we then have the ID of the field and the value, we we get from the user object.

Making this more flexible

Soon, I will update this to show you how to make it even more flexible.