Unfortunately I’ve had to remove the del.icio.us item from the sidebar. It appears that there’s some bad timeout values set in typo for retrieval of del.icio.us content – longer than the FastCGI process timeout.
This was resulting in the server becoming unstable, and causing machine load to spike which is no good, so until I can either fix it myself, or upgrade to the latest trunk of typo it’ll be switched off. You can still access it via the web or an RSS feed if you want though :)
This morning whilst waiting for everyone else to arrive in the office I took the time to catch up on emails and read through the various mailing lists I subscribe to. One of which, Extreme Programming
had a large number of posts regarding a single thread—regarding the XP practice of “Slack”.
Some of the communication was debate over whether slack within the plans was in the best interest of customers, and this seemed to be around the confusion of what slack actually meant. Surely if we’re in the business of better delivering customer value faster, it’s in our interest to complete more important work quicker? On the face if it that is true, but, as the posts clarify, it’s important for iterations to have a commital, rather than to just stand for merely an allotment of work from the release plan.
As with the rest of the pillars of XP, slack isn’t a hard-and-fast rule. Where I work it’s not something we do all the time. Indeed, it’s something I’ve often found myself arguing internally over. So, when I read a few of the posts I felt it really solidified my position.
Jim Shore has an excellent article regarding slack and scheduling, but it’s the snippet below that sums it up for me:
Any task that can be instantly postponed, indefinitely, is slack. The best slack tasks are also valuable tasks. Maybe even as valuable as the stories you’re implementing. In Stephen Covey language, they’re important but not urgent. Stories, on the other hand, are important and urgent. —James Shore: Successful Software
However, I disagree to an extent with his view that slack and stories should be considered separate, that slack is some external entity. In a post to the email list he writes:
“I don’t see Slack as being about doing more stories. In every iteration, I plan stories according to velocity. I also plan technical tasks. Some are explicit, like “update build script to install Feature X;” some are implicit, like “type on the keyboard” and “do test-driven development.”
“Among those tasks are some that I consider to be Slack. Some Slack tasks are explicit; some implicit. While they are all important, it’s possible for me to set some aside, on occassion, to meet my commitments.”
“I think the idea of Slack as ‘extra stories’ confuses the issue. I don’t see Slack as being stories at all.”
Speaking from the experiences our team has had with development, I think that slack is something that unless we add as low-urgency stories, wouldn’t get done.
Introducing a dichotomy between customer-focused stories and ‘slack’ tasks introduced a difference in perceived value—and since we had piles of customer work to do, we ended up swapping out the slack tasks for getting more stories in. If you change the language of James Shore’s post, so it becomes value and urgency on the 2 dimensions, and we’re essentially back to the same (basic) constructs of a story anyway.
I guess if you’re in a situation where it’s possible to retain value by introducing a distinction then you have no problem. With us (whilst working with the excellent Charlie Poole) we added our ‘slack’ tasks as stories that would be scheduled alongside everything else. The argument being that we were are own customers also—it was in our best interest to ensure this work was done to better enable us to work in the future.
We marked cards with a red border to indicate items that we felt we needed to address, that would ultimately deliver high value, but were not necessarily of great urgency.
This lack of a difference in value was (pardon the pun) invaluable to us, and to my mind, seems simpler than trying to maintain two lists of things to do—everything is managed (with great visibility) through our old system!
Although this practice dropped unconsciously from our process a while ago, the idea of dropping less important features for a more defined commital is something we’re improving at now, and something I’m glad to see again! Has anyone else approached this in the same way, or has the separation proved more useful?
This morning whilst waiting for everyone else to arrive in the office I took the time to catch up on emails and read through the various mailing lists I subscribe to. One of which, Extreme Programming
had a large number of posts regarding a single thread—regarding the XP practice of “Slack”.
Some of the communication was debate over whether slack within the plans was in the best interest of customers, and this seemed to be around the confusion of what slack actually meant. Surely if we’re in the business of better delivering customer value faster, it’s in our interest to complete more important work quicker? On the face if it that is true, but, as the posts clarify, it’s important for iterations to have a commital, rather than to just stand for merely an allotment of work from the release plan.
As with the rest of the pillars of XP, slack isn’t a hard-and-fast rule. Where I work it’s not something we do all the time. Indeed, it’s something I’ve often found myself arguing internally over. So, when I read a few of the posts I felt it really solidified my position.
Jim Shore has an excellent article regarding slack and scheduling, but it’s the snippet below that sums it up for me:
Any task that can be instantly postponed, indefinitely, is slack. The best slack tasks are also valuable tasks. Maybe even as valuable as the stories you’re implementing. In Stephen Covey language, they’re important but not urgent. Stories, on the other hand, are important and urgent. —James Shore: Successful Software
However, I disagree to an extent with his view that slack and stories should be considered separate, that slack is some external entity. In a post to the email list he writes:
“I don’t see Slack as being about doing more stories. In every iteration, I plan stories according to velocity. I also plan technical tasks. Some are explicit, like “update build script to install Feature X;” some are implicit, like “type on the keyboard” and “do test-driven development.”
“Among those tasks are some that I consider to be Slack. Some Slack tasks are explicit; some implicit. While they are all important, it’s possible for me to set some aside, on occassion, to meet my commitments.”
“I think the idea of Slack as ‘extra stories’ confuses the issue. I don’t see Slack as being stories at all.”
Speaking from the experiences our team has had with development, I think that slack is something that unless we add as low-urgency stories, wouldn’t get done.
Introducing a dichotomy between customer-focused stories and ‘slack’ tasks introduced a difference in perceived value—and since we had piles of customer work to do, we ended up swapping out the slack tasks for getting more stories in. If you change the language of James Shore’s post, so it becomes value and urgency on the 2 dimensions, and we’re essentially back to the same (basic) constructs of a story anyway.
I guess if you’re in a situation where it’s possible to retain value by introducing a distinction then you have no problem. With us (whilst working with the excellent Charlie Poole) we added our ‘slack’ tasks as stories that would be scheduled alongside everything else. The argument being that we were are own customers also—it was in our best interest to ensure this work was done to better enable us to work in the future.
We marked cards with a red border to indicate items that we felt we needed to address, that would ultimately deliver high value, but were not necessarily of great urgency.
This lack of a difference in value was (pardon the pun) invaluable to us, and to my mind, seems simpler than trying to maintain two lists of things to do—everything is managed (with great visibility) through our old system!
Although this practice dropped unconsciously from our process a while ago, the idea of dropping less important features for a more defined commital is something we’re improving at now, and something I’m glad to see again! Has anyone else approached this in the same way, or has the separation proved more useful?
I did finally get bored around boxing day so got back into the rails development, fortunately, with IPN now working. So here’s how I did it!
After checking through the application logfile and reading PayPal’s own IPN Notes I managed to get to the bottom of things.
Turns out my account was set so multi-currency transactions wouldn’t automatically be accepted. Consequently, transactions were being processed but recorded as “Pending” until the business user logged into PayPal. This was all as a result of me having not changed the the currency of the transaction to that of my account it was being processed through.
One other thing I noticed—the time between completing a transaction and then receiving the IPN callback was anywhere between 1 and 7 minutes – highlighting the importance of mocks/stubs I guess :)
Before we go any further, it’s important to note that for PayPal to work you must have a publicly accesible test machine – PayPals test servers attempt the callback using the URL you give – if you use localhost or some other private/firewalled machine it won’t work.
So, here’s how to get things started:
1. Signup for a PayPal sandbox account at PayPal’s Developer site.
2. Login to the PayPal sandbox, and create 2 accounts:
1. User account – this is for the ‘customer’
2. Business account – this is for the shop
3. Use the email facility in the sandbox to click on the 2 verification links sent for the 2 previous accounts.
4. Login to the business account through PayPal’s sandbox. Then go to your profile.
1. Enable IPN notifications – in the Selling Preferences column, click the “IPN Preferences” link. Enter the details and save.
5. Install the PayPal gem from RubyForge by doing a gem install paypal (along with all dependencies).
6. Add a PayPal IPN method to your controller as per the PayPal gem docs.
7. Knock together a simple order form, again you can use the docs from the PayPal gem. Make sure you set :only_path => false. Also make sure you set the currency of the transaction when using the paypal\_setup helper:
<%= paypal\_setup @order.id, Money.new(@cart.total_price \* 100, 'GBP')
Hopefully this ought to be enough to get you up and running!
In short it’s been a pretty fun couple of days getting things working, I’ve had to dabble with some other interesting areas such as confirmation mailing and custom routing which I’ll be sure to cover in some upcoming posts. Then all I have to get working is the Flash integration!
I did finally get bored around boxing day so got back into the rails development, fortunately, with IPN now working. So here’s how I did it!
After checking through the application logfile and reading PayPal’s own IPN Notes I managed to get to the bottom of things.
Turns out my account was set so multi-currency transactions wouldn’t automatically be accepted. Consequently, transactions were being processed but recorded as “Pending” until the business user logged into PayPal. This was all as a result of me having not changed the the currency of the transaction to that of my account it was being processed through.
One other thing I noticed—the time between completing a transaction and then receiving the IPN callback was anywhere between 1 and 7 minutes – highlighting the importance of mocks/stubs I guess :)
Before we go any further, it’s important to note that for PayPal to work you must have a publicly accesible test machine – PayPals test servers attempt the callback using the URL you give – if you use localhost or some other private/firewalled machine it won’t work.
So, here’s how to get things started:
1. Signup for a PayPal sandbox account at PayPal’s Developer site.
2. Login to the PayPal sandbox, and create 2 accounts:
1. User account – this is for the ‘customer’
2. Business account – this is for the shop
3. Use the email facility in the sandbox to click on the 2 verification links sent for the 2 previous accounts.
4. Login to the business account through PayPal’s sandbox. Then go to your profile.
1. Enable IPN notifications – in the Selling Preferences column, click the “IPN Preferences” link. Enter the details and save.
5. Install the PayPal gem from RubyForge by doing a gem install paypal (along with all dependencies).
6. Add a PayPal IPN method to your controller as per the PayPal gem docs.
7. Knock together a simple order form, again you can use the docs from the PayPal gem. Make sure you set :only_path => false. Also make sure you set the currency of the transaction when using the paypal\_setup helper:
<%= paypal\_setup @order.id, Money.new(@cart.total_price \* 100, 'GBP')
Hopefully this ought to be enough to get you up and running!
In short it’s been a pretty fun couple of days getting things working, I’ve had to dabble with some other interesting areas such as confirmation mailing and custom routing which I’ll be sure to cover in some upcoming posts. Then all I have to get working is the Flash integration!
I’m happy I’ve managed to prevent the application from dying on me – looks like it was because I was missing declarations such as the following:
FastCgiServer /var/www/sureboss_html/shop/dispatch.fcgi -initial-env RAILS_ENV=production -processes 2 -idle-timeout 600
This ensures that Apache handles the FCGI processes, rather than more just being created on request – this just ended up with processes kicking around doing nothing but unstability on my VPS.
So far I’m impressed with Rails:http://www.rubyonrails.org/ – I’ve got a prototype site up and running quicker than I would’ve previously expected (thanks to the Pragmatic Bookshelf’s Agile Web Development boo) and I absolutely love the way that it forces you to build stuff correctly. Things that have previously been considered ‘bad form’ or code smells.
For instance, take ASP.NET – the environment I do most of my professional work in – where a lot of the code for your average server control involves a very, very tricky lifecycle (incidentally i’ve still got a post in draft about writing a composite databound server control – the thing that has caused me most pain in the past). Well, the intended way is to build a control with private fields for each contained control, instantiate the types inside CreateChildControls, initialise the control (excluding any databound info) inside OnInit etc. The problem being, you must be aware of the implications for the rest of the lifecycle – when data has been posted back and the control tree re-initialised, when you’re allowed to access child and/or parent controls etc.
Rails is different and, to an extent, closer to a more traditional approach – that of the old-school classic ASP, PHP and other scripted languages – and also that of many Java web frameworks such as Struts, Spring MVC and Webflows etc. where the developer is more aware of the issues surrounding web development’s request/response model. Although I like ASP.NET, sometimes I get the feeling its made things more complicated than it needs to be – and I’m hoping the changed ASP.NET 2 model will have improved things.
I’ve got a basic shopping cart, and the final confirmation/checkout page sorted. For PayPal integration this generates some form data that is posted to PayPal, allowing the user to proceed through and pay etc.
However, IPN (Instant Payment Notification) should allow me to receive notification of when this succeeds/fails so I can update the database of orders, email people etc. I’m using PayPal’s developer sandbox to get this working but it just seems to ignore that I want IPN support – checking Apache’s access logs there’s no mention of any request for my IPN controller from PayPal.
This just seems to be solid proof for testing only things you can control – ideally I’d like to stub out PayPal and just test that my controller (with it’s use of the PayPal ruby gem) works as it should. I previously gave up with this as it seemed to involve mocking too much – something that’s been causing some furor on the TDD mailing list I’m a subscriber of. Maybe it’s worth another look. I’m told it’s the kind of thing Ruby is designed for?
In any case, if anyone’s actually had PayPal IPN working on the Sandbox could they leave me a comment and point me in the right direction please?
UPDATE: I’ve sorted most of the problems. I’ve also posted a more detailed guide of how I got it all working together.
I’m happy I’ve managed to prevent the application from dying on me – looks like it was because I was missing declarations such as the following:
FastCgiServer /var/www/sureboss_html/shop/dispatch.fcgi -initial-env RAILS_ENV=production -processes 2 -idle-timeout 600
This ensures that Apache handles the FCGI processes, rather than more just being created on request – this just ended up with processes kicking around doing nothing but unstability on my VPS.
So far I’m impressed with Rails:http://www.rubyonrails.org/ – I’ve got a prototype site up and running quicker than I would’ve previously expected (thanks to the Pragmatic Bookshelf’s Agile Web Development boo) and I absolutely love the way that it forces you to build stuff correctly. Things that have previously been considered ‘bad form’ or code smells.
For instance, take ASP.NET – the environment I do most of my professional work in – where a lot of the code for your average server control involves a very, very tricky lifecycle (incidentally i’ve still got a post in draft about writing a composite databound server control – the thing that has caused me most pain in the past). Well, the intended way is to build a control with private fields for each contained control, instantiate the types inside CreateChildControls, initialise the control (excluding any databound info) inside OnInit etc. The problem being, you must be aware of the implications for the rest of the lifecycle – when data has been posted back and the control tree re-initialised, when you’re allowed to access child and/or parent controls etc.
Rails is different and, to an extent, closer to a more traditional approach – that of the old-school classic ASP, PHP and other scripted languages – and also that of many Java web frameworks such as Struts, Spring MVC and Webflows etc. where the developer is more aware of the issues surrounding web development’s request/response model. Although I like ASP.NET, sometimes I get the feeling its made things more complicated than it needs to be – and I’m hoping the changed ASP.NET 2 model will have improved things.
I’ve got a basic shopping cart, and the final confirmation/checkout page sorted. For PayPal integration this generates some form data that is posted to PayPal, allowing the user to proceed through and pay etc.
However, IPN (Instant Payment Notification) should allow me to receive notification of when this succeeds/fails so I can update the database of orders, email people etc. I’m using PayPal’s developer sandbox to get this working but it just seems to ignore that I want IPN support – checking Apache’s access logs there’s no mention of any request for my IPN controller from PayPal.
This just seems to be solid proof for testing only things you can control – ideally I’d like to stub out PayPal and just test that my controller (with it’s use of the PayPal ruby gem) works as it should. I previously gave up with this as it seemed to involve mocking too much – something that’s been causing some furor on the TDD mailing list I’m a subscriber of. Maybe it’s worth another look. I’m told it’s the kind of thing Ruby is designed for?
In any case, if anyone’s actually had PayPal IPN working on the Sandbox could they leave me a comment and point me in the right direction please?
UPDATE: I’ve sorted most of the problems. I’ve also posted a more detailed guide of how I got it all working together.
It seems it’s not quite so easy getting Rails running fine.
I’ve given up trying to get Typo working with the latest release of Rails, along with numerous problems getting the correct MySQL gem working with the version of MySQL on my machine. This wasn’t even what I was trying to do – I was working on stuff for www.sureboss.com.
But, whilst trying to get PayPal testable on the server I ran into trouble – everytime I tried browsing the server just died. On my development machine it works absolutely fine, mind you that is with WEBrick. My guess is I’ve screwed something in the Apache/FCGI config. Ah well, time to halt for a bit of Christmas cheer and resume when I get a little bored on Boxing Day.
It seems it’s not quite so easy getting Rails running fine.
I’ve given up trying to get Typo working with the latest release of Rails, along with numerous problems getting the correct MySQL gem working with the version of MySQL on my machine. This wasn’t even what I was trying to do – I was working on stuff for www.sureboss.com.
But, whilst trying to get PayPal testable on the server I ran into trouble – everytime I tried browsing the server just died. On my development machine it works absolutely fine, mind you that is with WEBrick. My guess is I’ve screwed something in the Apache/FCGI config. Ah well, time to halt for a bit of Christmas cheer and resume when I get a little bored on Boxing Day.
I’ve been getting into some Ruby on Rails of late, and in the process of hunting down some information on incorporating PayPal IPN support I stumbled across a post on Tom Wilcoxen’s blog about Flock. I got sidetracked about having an integrated browser/blogger, and it’s shifted my browsing into a much nicer place to be.
was something I’ve been meaning to try, especially since Josh has pointed it out to me a few times.
To me, del.icio.us bookmarking has a good solid value proposition:
1. It ensures my bookmarks are available anywhere
2. Tags. Although they’re essentially analogous to the folders that IE uses for categorising bookmarks, they have an important semantic difference. They allow items to occupy more than one. They are also key to the powering of benefit 3 below. From a user experience point-of-view it’s important that you don’t need to create the folders first (as you would through IEs boomark support), they’re created when you bookmark. Something that now I think about it, almost every other bookmark feature gets the wrong way round.
3. Shared and social. Through tagging I can discover other related bookmarks, people that seem to be reading the same kind of things I am, and browse things they find interesting. Cross-selling for information.
In short it’s great. But, previously it just wasn’t integrated enough for my liking. Despite there being a couple of ways of making it quicker and easier to use when I’m browsing around, I wanted something more complete. So as soon as I remembered reading that Flock integrated del.icio.us for it’s bookmarking I decided to give it a go
Flock’s now my browser of choice. Although I’ve used Firefox, I never bought it as a fundamental replacement from IE, I just don’t buy a lot of the commentary about it being downright more secure than IE. I’d like to think I have enough Internet know-how to avoid killing my computer through browsing to malicious places. Flock adds value to my browsing experience, it integrates blog posting (although in a somewhat rudimentary way) such that I can blog in just 2 clicks on content I find. It includes a Shelf that I can place interesting things that I don’t necessarily want to bookmark, just come back to at some point.
So, if you want some joined-up browsing fun, get flock.
Incidentally, you should also note the addition of a my del.icio.us section on the right sidebar – this updates automatically with stuff I’ve bookmarked. If you want, you can even subscribe to an RSS feed of my bookmarks. How neat is that?