Hi! Hello! Good Day!

So we ran into a little bit of bother with some pull requests to GiveCRM: I had submitted a feature that had been merged in, but it was subsequently lost (in part) when a later pull request was merged in. It seems the submitter of the later pull request hadn't updated from the central repository before submitting his pull request, so when his pull request was merged my feature was overwritten.

My experience with Git is almost entirely as an individual developer, so I'm learning how to use it in a distributed team as we go with GiveCRM. I turned to my friend, colleague and resident Git expert Adam Wood for some advice.

This is what the graph of commits looked like

             o----------------o----------
            /                            \
-----+--+--+-------+------------------+-+-+----
                    \                  /
                     x-------x--x-x-x--

The +s are master; the xs are my feature's branch, and the os are the other branch.

I wondered initially if it might be resolvable by taking a branch at the point at which I finished my feature and rebasing that on master, but this didn't work, as might be expected. We tried a few other things, like revert and reset --soft, but eventually we worked out we could do the following, which was rather simpler. The following commands are what I did; there's probably a quicker/easier way to do some of them.

git checkout 12345abc

This puts you in "detached HEAD" mode at the given commit. This basically means, as far as I can tell, that the repository contents are at the specified commit, but you can't make any changes to the repository and expect to keep them: git's internal reference tracking is sort of "turned off". (Hopefully someone can explain that better than me!)

git checkout -b FeatureRescue

This creates a branch from the current detached HEAD state of the repository. There's probably a git branch FeatureRescue 12345abc that I could have done instead, but whatever.

git checkout -b integration

Create an integration branch to mess around in - you don't want to lose the branch you've created where the feature is still intact!

git merge abcdef123

Merge the commit(s) that overwrote the feature. I was lucky that the pull request only contained one commit.

git mergetool

Fix up the merge conflicts that should have arisen when the pull request was merged in...

git commit -m "Re-apply [x] change"

Commit the merge to the integration branch.

git checkout master
git merge integration

Switch back to master, and merge in the integration branch. Sorted!

Not quite. I ran into the unfortunate situation where there was another file that was correctly updated in the integration branch, but didn't get merged into master at the end. This, I think, was because the file was not changed on master after my initial pull request. I had to apply this change manually, but that was thankfully trivial.

If you know a simpler way to accomplish this, please leave me a comment!

Friday 21 October : "Sleep is a weapon"

I took Friday off work, did a spot of shopping in the morning, and hopped on a train down to London. Thank god the hotel and the venue were so close to Kings Cross; it was an absolute lifesaver not having to battle the Tube etc. Checked into the hotel, relaxed for a bit before meeting Adrian, then wandered over to UCL to register.

A little while later (we turned up quite early), the event got under way with an introductory talk from Rachel and the charities introducing themselves and their requirements. Many of the projects sounded really interesting! We then had the opportunity to mix with other volunteers and the various charities to decide which project we wanted to work on. I spent some time milling around, but the two projects I was particularly interested in were the CMS/repository of resources for the Charity Technology Trust and the Nathan Timothy Foundation's site to aggregate their various items of content. I was curious too about the wildcard project, which intended to build phase one of an open-source CRM geared towards simplicity, and purpose-built for the voluntary sector.

This "mixer" session was one of two bits of GiveCamp that didn't really work for me. It seemed that the choice of projects was quickly reduced before the session really got started:

• One project team had selected their technology before GiveCamp even started, and it was one with which I was unfamiliar (node.js). I was quite interested in this project and it was a bit of a shame to have to discount it. Mind you, I'm not sure I could have coped working with Gary Short and Rob Ashton ;-)
• Another project team seemed to be fully-assembled by the time I got to them, to the extent that they had started work! It seemed like I'd have a fair bit of catching up to do if I wanted to join that team.
• One charity had specified they want to work with WordPress. I've done enough PHP to know I don't want to touch it again if I can help it.

After doing the rounds and spending some time in the discussion on the wild-card project with Kendall Miller, it became obvious which project I was going to pick. Kendall has great energy and enthusiasm, and I figured that was something we were going to be in need of at 3am Saturday night when nothing worked. (Thankfully, it didn't come to that!)

We started going over the full half-page of requirements and working out how we wanted to tackle the solution. Whilst the aim was a free open-source CRM aimed at charities, what we decided to go with was a cloud-based SaaS solution that would be super-simple to deploy: you just can't beat the power of the cloud for making deploying an entire system easy. The CRM needed to be able to import data from Excel to make it easy for charities to get their existing data into the system. The CRM had to be able to manage campaigns, donations and members, and much more besides.

(Aside: This was the second bit of GiveCamp that didn't quite work for me. All teams were discussing their projects in the very echoey hallway/corridor that was our base for the weekend, and it made it really difficult to hear half the discussion. It would have been useful if we'd had separate rooms for the project teams at this point. Luckily Kendall had a loud voice!)

And with that, GiveCRM was born! We started dividing up the work: one team would work on the back end database, one team would work on an API for importing and exporting data from Excel, one team would work on the setup and provisioning site, and one team (the largest) would work on the core CRM web app. With our billets posted, we broke up to go start planning our teams' work.

Here's one of the things I loved about GiveCamp: when discussing what technologies we were going to use, someone threw an idea out there (e.g., ".NET 4.0", "ASP.NET MVC 3", "Git", etc.), and unless someone had a particular problem with it (which no one did), we just went for it. No lengthy evaluations, no dithering, just good swift decision making. Kendall was exceptionally good at keeping up the momentum on the decision making all weekend, which meant that we were able to execute massively faster than I had thought possible.

I was working with Robin Minto on the setup/provisioning side of things. We spent our time in the excellent Balsamiq mock-ups, figuring out what the minimum required information was that we needed to set up a site, and constructing a workflow for the provisioning process. We were later joined by Ben Scott, a web developer, who provided invaluable expertise in constructing these mock-ups.

Whilst the two UI teams were discussing UX design, simplicity, etc., the database and Excel teams were beavering away working to create something we front-enders could build on the following day. A big thanks to Chris Diver, Anthony Steele and Mark Rendle for getting us set up with a SQL database, dummy data to go in it, and a Simple.Data data access layer over the top, respectively; and to Nathan Gloyn and Johan Barnard for building a really nice, fully-tested API for working with Excel spreadsheets (and taking my improvement requests the following day). Great work guys!

Around midnight, we retired to catch some precious sleep before starting in earnest shortly after 8am the next day.

Saturday 22 October : "We've resorted to using a physical token to 'lock' items in Git"

I woke up shortly before my alarm went off at 7am, dreaming about the solution we were going to implement and some of the problems we had to solve. No, really I did. We arrived back at GiveCamp shortly after 8am, I swear the earliest time I have been at University in my life (even earlier than DDDs!). What greeted us there, however, was a feast: bacon and sausage baps/batches/rolls, muffins, pastries, croissants, pains au chocolat, tea, coffee... We sure weren't going to go hungry or thirsty this weekend!

By 9.30 or so, we'd divided up the development tasks amongst ourselves. This was where things started to get interesting. It soon became clear that my laptop was not happy and that my development VM was borked: no network connectivity in or out was going to make it very difficult indeed to work on anything at all (thanks, Parallels). That would have been game over for me, had Kendall not stepped in and lent me his laptop for the weekend. The guy is a legend.

A larger problem for the team was our use of Git. It was clear (unfortunately, only in hindsight) that we were using the wrong workflow for a distributed version control system, and everyone committing to master and pushing and pulling from the same remote repository resulted in us having to repeat a fair bit of work. We probably lost a good couple of hours' work to our Git problems. Robin had to repeatedly blow away his local repository and re-clone from the remote. The main issue for us was conflicting changes in the csproj and sln files. We ended up solving this in the time-honoured tradition of centralised version control systems: a MUTEX lock. (This is how, in hindsight, it's obvious we were following the wrong workflow.) Interestingly, at least two other teams had the same issue. Git sadly got very little love that weekend.

Another problem for us was conflicting changes to the database project (and the database itself). This we solved more practically: Chris set up the database on his laptop, and Kendall ordered us an 8-port switch so we could all connect to Chris' database. Less than an hour later, it arrived, and the problem was instantly solved.

Lunch was a super-tasty burrito provided by Luardos burrito van. Check them out, their food was really good!

By about 3.00pm, after a singularly frustrating morning with little perceived progress, stuff suddenly started coming together. The pace ramped up throughout the rest of the day: feature after feature slotted in to place. Throughout the day, I was working on the import-from-Excel functionality that is a key part of the setup story. I was quite happy with how this work progressed, as I was able to implement the feature with relatively good test coverage (not great, mind; something I'm now rectifying) and following best practices like dependency injection.

That evening, Kendall found a wandering designer from VerseOne to create us a logo:

I later discovered that I had implemented the Excel importer in the wrong place: I had been thinking of it in terms of the setup process, so implemented it in GiveCRM's Admin site (where charities can sign up to GiveCRM, have their instance created, etc.). In fact it's part of GiveCRM itself, where charities can add and manipulate their own data. That was going to have to be a task for Sunday morning, if it got done at all.

Sunday 23 October : "Down to the wire - I know because we're now saying 'nope, don't even try that.'"

I woke up shortly before my alarm went off at 7am, dreaming about the solution we were going to implement and some of the problems we had to solve. This time, I also felt hungover (although no alcohol had been consumed since Thursday night): the caffeine and sleep deprivation was starting to take its toll.

I rolled into UCL a little later than the previous day, at about 8.30am. We were again greeted by the same breakfast feast as Saturday, and we soon agreed the concept of "breakfast pudding" was a Good Thing™.

All development had to stop at midday Sunday, so we were now coding against the clock. The sugar and caffeine injection, combined with the adrenaline of working to this deadline, left me a little bit buzzy:

I'm so tired, I woke up feeling hungover. I need the largest, strongest cup of tea ever right now. Called in the big guns: two cups of tea at once. Chain drinking tea. It's all good. Phrase of the weekend, as coined by @nbarnwell: Breakfast Pudding. Feeling a bit too enamoured with this carrot cake muffin. The lack-of-sleep madness is starting to set in. I saw my two cups of tea and raised it a bottle of water. Busy busy busy. And buzzy buzzy buzzy.

I had a few bits to finish off with the import work, such as integrating it with the main site (tricky, given that it was in the wrong bit of the site) to produce a smooth demo, and add the final polish. With regular progress checks throughout the morning, but ultimately with some time to spare, we were done:

...and that's it. End-to-end demo WORKS. I am so proud of the work we've completed this weekend.

We spent a bit of time practising our demo and taking team photos before lunch, which turned out to be a truly excellent hog roast. Later, we moved across the road to UCL's Cruciform Building, a large red-brick building, for the demos.

Everyone had made excellent progress with their projects over the GiveCamp weekend, and this came across in the demos presented. Massive respect to the team working with the YouCan Hub for going live that weekend, and to Dylan Beattie's team working with Scene and Heard UK who completed the brief on Friday night and worked with the charity to build out a whole bunch of other stuff for them.

Photo copyright © Bert Craven 2011. Used with permission.

Thank yous

I've marked links in bold where I or my team used a product or service from that sponsor over the course of the weekend. An extra-special thanks to them!

Sponsors

• EduServe
• SQLBits
• Gibraltar Software
• InFusion
• Red Gate
• FusionIO
• Black Marble
• JustGiving
• DevExpress
• CounterSoft
• JetBrains
• Telerik
• Quest
• ThoughtWorks
• Kentico

Contributors

I've marked links in bold where I or my team used a product or service from that contributor over the course of the weekend. An extra-special thanks to them!

• PostSharp
• LeanKitKanban
• InformIT
• AppHarbor
• Pusher
• PluralSight
• LogicNP
• HasBean
• TeaPigs
• SqlSentry
• TX Text Control
• O'Reilly
• Dominos Pizza
• TypeMock
• DiscountASP
• SaaS Made Easy
• BeanStalk
• Heroku
• SyncFusion

People

A MASSIVE thank you to Paul Stack and Rachel Hawley for being mad enough to run this event, and all their efforts organising GiveCampUK; it is a truly phenomenal achievement.

Huge thanks also to the GiveCampUK assistants, Phil Winstanley, Andy Westgarth, Dave Sussman and Kim Richmond for their efforts in ensuring everything ran smoothly, resolving problems.

UCL's loan of their building for the weekend was hugely appreciated, in spite of the various wireless connection issues. As Paul mentioned, no other venues were willing to offer us a space for free, which UCL very kindly did. Fabulous generosity from them.

Most of all, a big thank you to the GiveCRM team for being such a great bunch of people to work with!

L-R: Anthony Steele, Kim Richmond, Chris Diver, Saqib Shaikh, Robin Minto, Kendall Miller, Adrian Banks, me (Alastair Smith), Johan Barnard, Mark Rendle, Neil Barnwell, Nathan Gloyn. Photo copyright © Bert Craven 2011. Used with permission.

Conclusion

This was the first ever GiveCampUK, and a number of people I have spoken to about it in the last few months since it was announced indicated an interest but a reluctance to take part, borne I think out of not knowing what the experience would be like. I started this blog post by saying that GiveCamp UK was one of the greatest experiences of my life, and I stand by that statement wholeheartedly. I hope that, with the inaugural event behind us, those people interested in it this time around but that didn't sign up will have a better idea of what to expect and might be more willing to sign up next time. From the excellent organisation of the event, to the chance to work with some top developers and interesting technology, to the massive sense of achievement and the pride in the work completed, this was utterly unique and electrifying and inspirational.

See you at GiveCampUK 2012.

Bootnote

GiveCRM is under active continued development. You can fork us on GitHub, follow us on Twitter (@GiveCRM, and "Like" us on Facebook. We're in the process of putting together a coherent plan to take the project forward in a more structured way; keep an eye on the Twitter account for details!

So earlier today, I posted on Twitter that Meanwhile, I'm quietly shitting myself about #givecampuk which is in just two days' time!

This prompted a slew of replies, not least from Paul Stack, one of the GiveCamp UK organisers, who said

"I wish there was no nerves over #givecampuk - we are all in the same boat - noone is better than anyone else :)"

There was some discussion on this topic a few weeks back, which Paul addressed in an excellent blog post at the time, essentially stating that no one person knows everything about software development, and everyone (including the likes of Scott Guthrie) considers themselves to be learning from other people all the time.

Here's the thing: I get all that, and I agree with it; the continual learning process is why I love this career that I've chosen as much as I do. But still I'm nervous. Why?

Paul said that GiveCamp UK is "NOT A JOB INTERVIEW" (emphasis his), and I do agree with that statement, but I think it is like the first day of a new job. It has the same unknowns: people, project, product, practices and processes, and in that regard I think those nerves I'm feeling are perfectly healthy. They're the same nerves I felt when I started at Granta a little over a year ago. They're the same nerves I feel when I play a solo bassoon gig. They're same the nerves I still feel sometimes when playing an orchestral gig. They're the same nerves I'm feeling for my new role leading a small Agile team at work. It's not so much performance anxiety (although there is certainly an element of that) as jitters fuelled by excitement and the unknown; it's the build-up of adrenaline as I get to face another great challenge.

GiveCampUK is going to a fantastic experience and, most likely, a massive rush. These nerves are just the start of it.

Here's a handy trick I discovered whilst fixing a bug. You can initialise a collection from another collection and add new items to it as follows:

Note that the collection initialiser on AllFoo runs before the constructor, so the Foo created with constructor parameter 4 will appear first in AllFoo, followed by everything in BaseCollectionOfFoo in the expected order.

Very often when I'm writing a script in PowerShell, I will need to obtain the directory in which that same script resides. This is sadly not completely trivial in PowerShell, but the following function achieves the desired result:

Hopefully, having created a gist for this and blogged about it, I won't have to keep resorting to Google in future to remind me how to do this. This particular version was posted to the PowerShell Code Repository by Andy Arismendi.