Archive for Development
GiveCamp UK – Start a CRM in a Weekend
Posted by: | Comments
As part of my recent trip to the UK I got a chance to participate in GiveCamp UK. Gibraltar Software was a sponsor, but more than that we like to really participate in the community. I got selected as a team lead which made it doubly interesting – leading a GiveCamp team is always challenging but made that much more so when you account for leading a team of UK developers.
When talking with the charities that were interested in having something done at GiveCamp a common thread showed up – many needed a basic customer relationship management (CRM) capability to replace their existing paper or Excel process. Nearly every charity has the need to track donors, volunteers, and people they help. Additionally, these charities often have little or no in-house IT talent so self-hosting an option of any complexity wasn’t a good option. Instead of helping one or two of them by implementing an existing CRM option (like SugarCRM or a commercial option) we saw an opportunity to use GiveCamp to kick off a greater initiative: A free hosted CRM tuned just to small charities.
The core idea is to provide just what small charities need in the easiest to use fashion through a software-as-a-service platform. This way the charities wouldn’t have to worry about security or backups and could shave off a lot of time that otherwise went into basic recordkeeping. In many ways, this CRM would be distinguished by what it didn’t do more than what it did. The primary goal is simplicity of setup and operation and setup, not flexibility to handle any scenario.
Before GiveCamp UK started, I’d had a range of conversations with the organizers to make sure we had a clear reason for why we weren’t taking something off the shelf. We looked at a few open source offerings to see if we could just make a customization engine on top of them but in the end it was clear that the risk and complexity of those options overweighed the head start they would give us. We didn’t want to risk suitability for small charities in exchange for capabilities they wouldn’t need.
What’s a Minimum Viable CRM?
The initial requirements we got from charities were, not surprisingly, very general. Fortunately, we had a few members of our team that had experience developing CRM solutions and were able to give us a starting point that made a lot of sense. Our goal for the weekend was to get just far enough to handle the most essential requirement: track donors and campaigns.
Besides making the application useful we had to make it easy enough to set up that individual charities could create their own CRM instances. Immediately this pushed us to design it as a Software-as-a-Service (SaaS) to eliminate the need for installation and deployment by the charity. Instead, they would just go to a web site and enter the bare minimum information to get going and receive instructions.
Once we had the functionality outlined we wrote out exactly what we wanted to demo on Sunday. You don’t want to end up with nothing to show at the end of the weekend, so it’s useful for everyone to have clarity on exactly what you’re going to show. Things that the application will ultimately need but aren’t part of that demo are lower priority.
Have a demo plan before you start building the application so everyone knows what you have to get done.
Building the App
Day One (Friday night)
At first it appears that you have 43 hours to get it done – from 5 PM on Friday through to Sunday noon. But, knock out the time to form the teams (about two hours, including the introduction) and then six hours a night for sleep (sleep is a weapon!) plus another 5 hours total for eating and breaks and you’re down to 24 hours. Given that, we broke it down into requirements, planning, and framework (Friday night), construction (Saturday) and integration/defect fixing (Sunday morning).
With one day to build out the user interface and process flows it was essential to make sure we had the foundation set up Friday night. We worked largely from back-to-front with the database and data access layer as well as a generalized Excel import/export capability being done by the end of the day Friday while the rest of the developers worked out the exact flow and wireframes for the UI. I made tea and asked for status updates.
Break your project into independent modules that can run in parallel. The Team Leader should keep a close eye on whichever module is currently the critical path.
Day Two (Saturday)
Saturday morning began bright and early with most of the team in before breakfast. We had made our goal for Friday with a complete data access layer for the application set up and tested. It’s very tempting to drop parts of your normal development process when working in such a hurry, but basic unit tests put in as you go dramatically reduce the odds you end up with nothing to show on Sunday because things don’t work when you put them together.
The main applications were being built using ASP.NET MVC3 which most of the team was at least somewhat familiar with. Since we expected the system to have significant data storage requirements that would grow over time we opted for a SQL Server back end. For data access, Simple Data was selected over other options in part because Mark Rendle was on the team which made it emphatically the fastest way to get our goals accomplished. Several of the team were impressed with it and I suspect will use it on some of their future projects.
That mug isn't going to fill itself now, is it.
We were fortunate enough to be able to draft in another UI developer that could work strictly at the HTML/JavaScript layer. To accelerate development he recommended and we adopted the Twitter Bootstrap library. This gave us a pre-packaged set of styles and scripts that define the visual language of the application. We now were working down several fronts at the same time – the provisioning application that would be used to set up new users, the main web application, Excel import & export, and the critical search capability for creating campaigns. Meanwhile, I made tea and asked for status updates.
Saturday is the long day where you want to end with each of the components of your system feature complete and working at least in isolation. Once you leave on Saturday you’ll only have a few more hours available on Sunday to get everything wrapped up. As the day progressed things were looking up that we’d be able to deliver on our goal for the weekend.
To help with testing and prove that our application could scale we wanted to load it up with test data that would feel like the real thing. There were two approaches that occurred to us – write a programmatic code generator to run on top of the data layer, or use a data generation tool (like Red Gate’s SQL data generator). We weren’t sure if the off-the-shelf tool would get us good enough results in time, particularly since no one on the team had used it. Alternately, it wasn’t clear how much time it’d take to generate plausible data on our own. So we did both for a while – running down both paths for a few hours to see which would bear out. In the end we found the Red Gate tool did great with people and addresses, but our custom coded tool did better with donations and more interesting edges of the data.
When you aren’t sure which way to go – do both. You have more people than time. Pick a winner when it’s indisputable or you can’t spare the effort any more.
Around dinner time we did a walkthrough of the complete demo we’d laid out and noted the missing elements and problems. We’d come a long way, but there were several minor changes that appeared useful for the best experience. With the user interface coming together, I went around to other teams to find a graphic artist that could make us a logo for our project. We’d settled on the name GiveCRM and a logo would be a great touch for the demo. Fortunately another team was already done and was willing to lend us a hand with a family of logo graphics we could incorporate. Meanwhile, I made tea and asked for status updates.
Day Three (Sunday morning)
Sunday morning was a later start for most people since they’d stayed late to accomplish our Saturday goals. Once there was no more tea to make I’d left and gotten a good night’s rest so I was able to whip up a presentation on Sunday morning for our demo later that day and review where we were. We started off the day with another demo walkthrough to see what gaps remained. It was clear one thing we wanted to have done – a proper authentication system – was not going to make it in time. Instead of risking the demo we decided to have that team continue working on a branch while we finished up the rest.
About every hour we continued this pattern – do a demo walk through, note the issues, make progress. Naturally, I made tea and asked for status updates. By the time it was pencils down at high noon we had the whole thing put together, along with some extra bells and whistles that weren’t in the original plan.
Keep tracking your progress against your demo. This keeps you looking at the whole picture instead of just the individual modules and function points
Well, that didn’t work
The monkey wrench that got thrown into our plans was challenges with configuration management. We’d opted to use GitHub as the central repository for the code despite very few on the team being familiar with it. This was my mistake – it was mentioned by one person and I assumed I was the only one that was in the dark on how to use it on a real project.
DVCS tools are very powerful for distributed development but can get you in real trouble. Several times we had to stop work and enlist a Git expert (Ben Hall) to rescue us from merge oblivion. Ultimately we addressed this with external locking: I had a squeeze toy which you had to come get if you were going to change project or solution files (or add a new file to the solution). Combined with a fair bit of manual coordination we mostly avoided merging problems going forward, but it did cost us a lot of time.
Think hard before relying on tools your team doesn’t know. Time is your greatest enemy.
Where’d we end up after one weekend?
When I originally discussed the project with the organizers of Give Camp UK I didn’t give us much odds of having an interesting demo at the end of the weekend. Our first goal was just to make progress that could be built on in the future. After our Friday night planning it seemed quite possible we’d have something ready for charities which was quite exciting indeed.
The main application was in pretty good shape: You could import data, export it, create and manage campaigns. Donors could be individually added, donations recorded, and an easy-to-use campaign generator let you build up a filtered list of donors. Even the authentication system that had been such a concern earlier had picked up its pace and was ready to be merged in. We decided not to do it for the demo in case it introduced a problem, but it was checked in and ready for merge.
The provisioning system was similarly looking good: It gathers the necessary information, creates the right database entries, generated a nice introduction email (in HTML and text formats no less) and could import initial donor data from Excel. Like the main application it too needed to be merged with the authentication system which we left out for the demo.
What’s Next?
There were a few things missing before we could release it to charities for use. Most notably, there are some back end features missing in the provisioning system for creating new charities and you can only have one account for each charity. For the most part these issues will be straightforward to address and the team is set up to get these handled.
Before we go live, we need to find the right place to host the system. We have a test server up and running at GiveCRM.org.uk but we need a real home – one that can scale up to handle hundreds if not thousands of charities. Our goal is that the service is free for these small charities. The incremental cost to host each will be quite small, but any charge will shift how charities will approach a decision to adopt it.
Interested in Helping Out?
This is just the beginning of the development of GiveCRM. Our goal is to continue development with a volunteer team to refine the existing features (and address the gaps we need to go live) but then at each of the coming GiveCamp UK events add another module to the system. While we believe we’ve hit the most critical feature charities need, it’s far from a complete solution. If this is interesting to you, be sure to sign up to hear more about the schedule for the next Give Camp UK event.
Gibraltar for Silverlight and Windows Phone 7
Posted by: | CommentsWe have a lot of customers using Gibraltar with the server-side Silverlight apps, but until now, you had to roll your own solution to get client-side log messages into Gibraltar. There were options such as using NLog or CLog to forward client-side messages to Gibraltar, but we didn’t provide any out-of-the-box capability for client-side logging.
We’ve just released sample code (both source and binary) that will ultimately form the basis for built-in Silverlight and Windows Phone support in a future version of Gibraltar. It supports Silverlight 3 & 4 as well as Windows Phone 7.x. You can use on binaries as-is (we even provide a NuGet package to make it super easy to integrate), or you can start with our implementation then tweak the code as you wish. Either way, it gives you an easy way to get a more complete picture from your Gibraltar logs today including both client- and server-side logging.
Please check out the bits and let us know what you think!
Understanding the Design
Our support for Silverlight comes in two parts: a client-side library that is a subset of the current Gibraltar.Agent shipping release, and a server-side AgentConnector that acts as the “message sink” for each Silverlight client that writes client-side messages to the Gibraltar log, which is then packaged up and pushed to the Hub and/or Analyst just as you would expect.
The Agent Connector is a REST-based WCF service that leverages WebActivator to automatically configure the service route, give you near-zero-config that will have you up and running in less than 5 minutes.
Log messages are continuously streamed from each client to your web application with client-side message buffering to ensure that no more than one outbound request to to the Agent Connector is active at once for each client. Server-side, each client is assigned a unique ID to make it easy to analyze multi-user behaviors and trace individual client sessions from Gibraltar Analyst.
Getting the Bits
There are two different ways you can get the code. The first is through NuGet.org. If you’re not familiar with NuGet, it is a free Visual Studio extension that manages assembly dependencies including automatic downloads and updates. The “Server” component of this design leverages NuGet to pull down Gibraltar.Agent, as well as WebActivator, so either way, you’ll want to check it out.
The second option is to download a zip file containing the same binaries included in the NuGet packages as well as the full source code, an end-to-end sample application and a ReadMe file with details on building and integrating the code.
Installing the Server Bits with NuGet
Your solution will likely have two parts, a Silverlight client app, and a Web Application. To start, you’ll want to have the NuGet Package Manager installed in VS2010. You’ll also want to have already configured the Gibraltar Agent on your web app. If you have not done so, please follow the directions on this page of our User’s Guide.
Right-click your web project, and select “Manage NuGet Packages”. In the resulting window, type “Gibraltar.Agent” into the search box in the top-right corner. You should be presented with a number of packages. Select ‘Gibraltar Agent for Silverlight – Server”. This will add the assembly references, as well as a clientaccesspolicy.xml file, to the root of your app. You can also open up the NuGet Package Console and type “Install-Package Gibraltar.Agent.Silverlight.Server”, which will accomplish the same thing.
Installing and Configuring the Client Bits with NuGet
Now right-click your Silverlight project, call up the NuGet Package Manager again, run the same search, and this time select the “Gibraltar Agent for Silverlight – Client” package. You can also open up the NuGet Package Console and type “Install-Package Gibraltar.Agent.Silverlight.Client”. After it installs the proper assemblies for your project type (the same package has the SL3, SL4, and WP7 binaries), there is one more thing you’ll need to do. You need to add the following string to the ResourceDictionary in your App.xaml file:
<system:String x:Key="GibraltarAgentServer">http://YOURSITEHERE.com/</system:String>
This value needs to be the root of your application, be it a domain, subdomain, or IIS application. This will be combined with the built-in WCF route auto-registered by the Server binaries (“/GibraltarAgentService/”, to be exact). Now, you should be able to use Gibraltar.Agent.Log just like you always have:
Log.TraceCritical("This is a critical message.");
Since multiple clients will likely be connected, the service assigns each IP address a unique integer ID, so you can easily track which messages come from which clients or have Gibraltar filter the view to only show messages from a single client. You’ll see results similar to the screenshot below:
Well, there you have it. Get the bits and tell us what you think. Even with this early sample, we’ve sought to make it as robust and forgiving as possible, in line with our goal to “First, Do No Harm”. Your feedback will help us extend and harden our Silverlight support and become an easy-to-use and rock-solid part of the standard distribution for a future Gibraltar version. So, if you find any issues, please do not hesitate to leave a comment and let us know.
Philly.NET Code Camp 2011.1 – Presentation Notes and More
Posted by: | CommentsThe Gibraltar team was there in force for Philly.NET Code Camp 2011.1. Since it’s right in our backyard we brought more of the team and had a booth set up. We were just thrilled at how many people stopped by to talk – not just to check out Gibraltar and VistaDB (but that’s always great!) but also to talk about past presentations we’ve done.
Kendall Miller presented a new talk at this Code Camp – Easy Application Scaling with Microsoft AppFabric and AOP. You can read the slides below as well as download the source code for the demos. This is an extended version of the webinar we did a few months ago, with a lot more code samples.
The key idea is that AppFabric cache creates a number of opportunities for high performance, highly scalable applications but you’ll want to do some up-front work to make it easy to use in your application. The code samples walk through how to do it all by hand, then show how to use PostSharp to inject the code at compile time and make it a whole lot easier. You can Download the Code to see for yourself
Philly .NET was very well run as usual – all the food set up and ready to go, good places to network, lots of tracks and sessions to attend. This year they also added an open spaces area for folks to hotly debate common challenges in a semi-moderated forum. It was a fun place to sit and listen to the passionate, divergent opinions on the range of software construction topics. Of course we were happy to see our friends from DevExpress there as well as the rest of the community.
Southern Maryland Give Camp – What a Blast!
Posted by: | CommentsLast weekend I was at the Southern Maryland Give Camp which really was an event not to be missed. In one weekend we designed and built a system to track and report on all of the services provided by the Tri-County Youth Services Bureau (TCYSB), an organization that provides important help to youth and families in Maryland. Their key goal was to automate the reporting they needed to do to the various state agencies and grant providers that otherwise took about a man year of effort to assemble by hand.
Held in the really beautiful St. Mary’s College of Maryland (a state school – who knew!) we set about building system to track all of the people TCYSB provides services to, all of the services that were provided, and then provide the data back out to satisfy the various reporting requirements. To get a feel for the complexity of the system, here’s the entity model:
When you have less than two days, it really focuses you on what’s important. For the most part we stuck with technologies we either knew or were willing to risk everything figuring out. We built the system using Entity Framework 4 (Model First), ASP.NET WebForms, and DevExpress Reporting. This was my first time using EF4 on a complete application, and it worked out amazingly well. Frankly, compared to the prototypes I did on EF1 they have really come a long way. Naturally we used DevExpress reporting not just because I know it (I know SSRS as well) but because ease of deployment is a big concern when you’re handing off a bunch of files to a customer with just this side of no IT support. Like a few vendors, DevExpress offered free licenses to the non profit organizations for solutions developed at the Give Camp.
Another thing that acquitted itself well was TFS – we had everyone on the team using our TFS server (since it was readily accessible and everyone had the client installed) and despite the high odds of merge hell it all came off without a hitch. Frankly, no one was more surprised than me.
At high noon on Sunday, 41 hours after the kickoff, we backed away from the source code, did a final check in and went into the group room for wrap up. Every team demonstrated what they built for their non-profit which was something to see. The results ranged from redesigned web sites to real line of business applications like what we did. Technologies spanned the range as well, with Microsoft pretty well represented as well as some interesting uses for Google Docs and Google Calendar.
That's right Rachel - enough Pizza for everyone to take whatever they wanted
What made it all work was behind the scenes – for me the biggest piece were the outstanding requirements documents we got prepared by Ann Scharpf before we got there. Combined with round-the-clock access to both the TCYSB staff and Ann we never had to guess at what we were trying to deliver. Frankly, I’ve never worked with a better BA than her and it made all of the difference.
Everything we might ask for was right there – more food than could be eaten, more caffeinated drinks than could be drunk, and roving specialists in design and technologies (a big shout out to Steve Michelotti for helping me with EF questions).
Are you done yet? Well get on it!
Finally, we had Jim Pendarvis doing his best impression of R Lee Ermey. When he says coding is over at high noon, coding is over at high noon! I can’t imagine how much work he personally had to put into making this happen.
If you have the chance, I really encourage you to check out a Give Camp near you. It’s a great experience to build something completely in a weekend that will make a huge difference for people. Regardless of your level of tech skill or even if you’re a designer, analyst or even (gasp) a program manager you can make a difference. Give it a shot!
