I’ve just rebuilt Wittenburg.co.uk. Here's what I set out to do:
- Control: Specifically, control of my content. I want it to be exportable and searchable, and I want absolute ownership.
- Access: I must be able to easily access, modify or delete published content from anywhere, using a phone, tablet, or PC - even if I don’t have an Internet connection.
- Speed: I have a son, and I have a job. Both of these are more important to me than messing around with my web site. My target was to complete the rebuild in no more than two days.
- Security: My family is forever hounding me for news, and photos of my son - not something I'll do on Facebook or Google+. I need a secure environment in which I can share content with people I’ve authorised to see that content.
These requirements meant two things –
- If the speed requirement was to be met I’d have to reuse anything I had lying around. In other words, proving the productivity claims I brag about to my girlfriend.
- I needed to build a native client app to manage content, and come up with a synchronisation framework to push that content to this web site, and all of my devices. While a sync engine seems a bit of an overkill, it made sense because I've been thinking about building sync for a while for Interact.
Lastly, I don't use frameworks (I usually find a tiny bit of them useful, which isn't worth the bloat they tend to add), so that excluded JQuery and Microsoft's Membership Provider, and meant creating my own data provider.
The Client App
This’s what the outcome looks like:
The UI is crude, but I can build that out over time. The underlying architecture is more interesting:
It’s not quite MVC, and not quite MVVM. All commands are issued as method calls to the object model, which communicates requests and changes in state through events. Separation of concerns is strict, and each component is really simple and obvious.
Application components respond to events from the model, and typically only have three methods – Load(), Save() and Delete(). They call a data access component, which has GetItems(), GetItem(), SaveItem() and DeleteItem() methods. This was lifted directly out of old projects, and I had most of it in place after two hours of replacing field names like “Customer” with “Photo”.
The photo editor and synchronisation engine are the only pieces of code I wrote from scratch. The photo editor was pretty straightforward. I needed to resize and possibly rotate images. There were bugs, and some unanticipated surprises (resizing an image does not reduce its file size by much, so I also had to drop images to ~72 dpi for the web), but mostly it went without a hitch.
The synchronisation engine is easily the most complex part of the solution. It sends content to a service on the web site using batching for smaller items (blog posts), and chunking for larger items (photos).
The Web Site
Because the web server doesn’t care as much about state, it’s a lot simpler. Again, separation of concerns was a big, um, concern.
Building the rest of the web site only required me to copy and paste in the entities and components I'd created for the client, and then dumbing them all down to use synchronous method calls rather than the event-driven model the client uses.
So there you have it - after about 22 hours' effort spread across 10 days, I have a brand new web site that looks ghastly, but functionally achieves what I'd set out to do.
There are some glaring functional issues (
blog posts and photos aren’t sorted using anything currently known to mankind fixed!). I’ll also add lipstick to the bulldog when I have time. I’ve only managed to build a desktop client, but will create a Windows Phone version when Microsoft releases the WP8 SDK, and a WinRT version for Windows 8.
Both client and server back end were written using Visual Basic.NET.
The coolest thing in, like, forever, is starting up a new install of the desktop client, clicking Sync Get and watching everything populate in real time.