I've been on two previous teams for The Nerdery Overnight Website Challenge and in each of those events I've had very different experiences. In the first event, I was a late arriving member of an already established team. The team leader already had a plan of attack and merely needed me to follow. I did my best to build out functionality and features for the site but in the end it was our lack of strong Drupal-driven frost end experience that hampered our progress. We weren't able to finish.

The second time around, I was the team captain. I organized the team meetings (before and after the event), I planned out how development was going to happen, and how deployment was going to happen. I researched prospective team members and actively campaigned and recruited so that we would have a well balanced team. Most of those efforts paid off, but it was a giant consumer of my time as I was pouring precious sleep-time hours into ensuring we had the best team we could field. We improved our showing though, we finished in third place.

Now that the next Overnight Website Challenge in the Twin Cities is coming around, I've resisted the urge to micromanage the early team organizing efforts. I'm not holding 15 minute scrum meetings before the event. I'm not spending countless hours mining data on the prospective team members and pondering if I should send them an invite to the team. I've learned my lesson.

I also don't need to. This year I have a lot of nerds on my team (nerd being the affectionate term of poeple who work at The Nerdery). I have in all six nerds on my team with the remaining spots filled by local Drupal superstarts or enthusiasts. It has been MUCH easier to source the team.

The biggest lesson that I learned from the previous efforts is that a team needs strong UX and design. It's really hard to get from the non-profit what it is that they want to build. The more prepared they are the better.

The other lesson I learned is that it really pays to have virtual machines of the development environment ready to go.

Finally, the last hurdle any team overcomes is the question of, "How do I get my content in". That's a problem that sounds like it has an easy solution, you just use the provided UI in creating each piece of content individually. But that's usually not the problem that we need to solve at 3 in the morning at the OWC event. The problem is usually, "I've prepared this giant binder of content, how do I get all of this in while I'm running at 10% efficientcy." This time around I've been focusing my pre-event planning on solving this problem. I'm thinking a migration process could help. Or a Feed to import data. Either way it's going to be tougher than it should be.

This week, i've been coding up a new implementation of Paypal's Web Payflow Pro API so that I can create subscriptions when purchasing products of a specific product type. When I started it sounded like a huge undertaking. I mean we're talking e-commerce right? There's a ton of complexity there that is required by the various business cases for what can be done in this space. But my current project requires this functionality and I didn't find anything that precisely implemented what I needed.

There was Commerce Subscription, which by its name alone, sounded like what I needed. But it supplies too much and it doesn't seem to actually implement the CreateRecurringPaymentsProfile API Operation that I needed so I just decided it would be easier to write my own and then look for ways to merge our work later.

To start, I looked for ways to extend the Commerce Subscription module but quickly found that what I really needed to do was extend the Commerce Paypal payment method module. I intended to write my implementation of the service call i needed and then hook it into the existing code, since that sounded easier. But I quickly founded that I just didn't agree with the structure of the module. The urge to refactor was too strong and I eventually seperated out the _info hooks from the callbacks, and the paypal api implementations from the callbacks.

My work in progress of this effort is here:

Today, I have something that installs and I'm going through the process of debugging it. I have a Tuesday deadline to make it all work, so I'm going to pushing myself over the weekend to get this working well. My QA team will find all the edge cases, I just want to make sure It's going to actually create subscriptions.

After this sprint is over, I intend to write implementations of the reset of Paypal's API. Perhaps that would be better suited to be it's own module since other modules could just pass in the data, send the data, and handle the response.