Sample applications are a dual-edged sword. When you’re starting out with some new technology, you want them small and focussed, so you can learn just the single thing you’re trying to learn without getting distracted by unrelated bits.
However, once you know how the individual technologies work, the real question becomes about how you should combine them to build something larger so that it will be performant, maintainable, stable, etc. At this point small sample apps are useless, you want something more “real world”.
I’ve been thinking about this for RAD Server recently. We’ve been doing a number of RAD Server projects for customers, however none of them are applications we can share. What I really wanted, I decided, was a customer to come along who was happy to publicly share all the details about the app we built them. Unsurprisingly, those customers are not that common.
At the same time, one of the sales guys in Code Partners was grumbling about the manual processes we had to do around Update Subscription renewals. No worries I thought, we’re a software company, we can write code to fix that.
Then the penny dropped: We’re the customer we’ve been looking for!
So, I’m very happy to announce that we’ve started building a Subscription Management system based around RAD Server. I’ll go into further details about what it does in a future post, but at a high level, the initial features are:
- Manage all our customers who have Update Subscription/Maintenance for different products
- Make it easy to upload details of new renewals when we receive them from the vendor.
- Give plenty of notice on upcoming renewals, so there is time to budget. This will involve integration with our Marketing Automation system.
- Integrate with our Finance System to manage the quoting/payment process.
- Integrate with our CRM so that details of the renewal and communications with the customer are updated.
- Provide a web-based view so that the Renewals Managers from the vendor can see the status of their renewals at any time.
There’s more, but at a high-level this gives you an idea.
Along the way we’ll have plenty of opportunity to blog about the decisions made during development. From the server-side implementation using RAD Server and TMS Aurelius, to the web client, the mobile client, continuous deployment, automated testing, 3rd party integration with REST API’s, Cloud Hosting, etc, etc. It’s the rationale behind these decisions which I often find most useful to understand when I’m trying to learn a new technology, so I want to be very transparent about these. When we make the wrong design choices, we’ll make them publicly and come clean about them in public too.
But it’s not just the decisions that we’ll be transparent about. All code and other materials will be open sourced and available for you to grab and play with for yourself.
It’ll have to fit in around our paying customer work, so won’t be the number one priority, but we’ve begun which is the first step, and I’ll be sharing more details about where you can grab the initial source shortly.
Oh, and if anyone has a better idea for the name, I’m very open. I picked SubHub after about 30 seconds consideration, but the guys in the office have already started referring to it as Hubba Bubba, so I’m not sure that’s a good sign 🙂
Ah Malcolm, you’ve hit a nerve for me regarding the ‘real world’ value of demos. I was thinking of doing the same myself!
Looking forward to seeing how this project progresses, including (indirectly) your consideration to things like project folder structure, unit and class naming, unit testing, object mapping, etc.
Cheers, Ian