Shaved yaks nothin’!
The first draft of this rant came out with a pretty negative tilt to it. I think this is mostly because I felt frustrated and let down. I’d really bought into the concepts that were being offered, and after having some stuff go right, having something go wrong is even more frustrating. I’ve reworked it to take a more objectively-critical attitude, rather than a pissed-off one. Hopefully I managed it!
Zimki recently announced a £10k competition to be given to the person who builds the best business off the back of Zimki. The aim behind the idea seem to be sound — give Fotango some real life products they can point at to show that Zimki *is* a viable choice — but the framework just plain isn’t ready for building a business on.
The big selling point of Zimki seems to be taking out the grunt work so that you can get on with the important stuff. From the blog of Fotango’s MD:
The point of Zimki is to take care of the now mundane (setting up servers, configuring databases, backups, scaleability, yada yada yada ... stuff we call “yak shaving”) and allow developers to focus on the interesting stuff of building something new by providing “pre-shaved yaks”.
Simon Wardley
A vision which has much in common with existing frameworks, plus a little extra around the edges. Unfortunately, plenty of stuff seems to be getting in the way of that perfect vision.
Problems
Development environment
Zimki provides a web based interface — Portal — through which you could theoretically do all your coding. Unfortunately they have ommited the capactiy to edit files, so your static CSS and Javascript files have to be edited offline and then uploaded.
But nevermind, to solve this, and get around the problem that coding in a textarea is a nightmare (do you ever use the tab key?), there are a couple of remote syncing scripts: Zync or Zwim. Yes, the wordplay is intentional, that’s how the guy who wrote Zwim came up with the name.
Both these scripts push files from your system onto the Zimki server. Of the two, Zwim is a far better option, allowing yanking, shoving, and syncing — Zync only allows shoving. However, neither Just Work, leaving the user to fiddle with things even before they’re up and running.
Incidentally, neither of these tools are public domain yet, I just got hold of them because I know a developer.
To really sell this product to developers, you need a good development environment in place. I believe the remote syncing apps are the right direction to take, leaving the developer to keep their own well tuned environment, but they’re just not polished enough yet.
Forms and validation
Every website that needs the power of a framework and a server side language will use input forms. Every. Single. Website. But somehow, there’s nothing in Zimki to handle display and validation of forms.
At the very least, I’d like to see some sort of validation framework included where you can specify which fields are required, what regexs they must match, and custom functions for more complex validation like “does that email already exist”.
Email
Where is email sending? After picking through the results of a search for “email”, I find the one page which mentions what I’m after:
Premium services
- There is an additional charge for certain services, such as sending email. This is levied on a per unit basis.
Zimki Billing Overview
So, one mysterious mention for sending email, which implies it is a pay-for service. If I’m supposed to be building a business on Zimki, I’m not filled with confidence.
Registration and login
One thing which I think would work really well in Zimki’s favour is a walk through for developers to build registration and login functionality in 10–15 minutes. This would make for an incredible first experience with the system, and wouldn’t be too much work for the Zimki team to pull off.
The way things work on a technical level could also do with a little tightening up: User registration cannot even be made case insensitive — at least, not with a simple flag: you can search for the username case insensitively and reject registration or use the found username to login — so if you don’t do the check yourself you can have a “Dom” and a “dom” registered in the system. Confusion ahoy!
Image manipulation
Whilst there is good support for creating thumbnails, there’s no support for image rotation or cropping. Given that I’m used to the flexibility offered by GD and ImageMagick, the lack of control here is a little annoying.
This isn’t such a biggy, because not everyone needs it, and I’m reliably informed that a future version will support these features.
Documentation
Features aside, the documentation provided by Zimki is shockingly lax. Search seems to work ok, but both the content and presentation — especially the handling of <code> fragments — of the docs needs a lot of work to make it a useful resource.
There is a “Cookbook” to introduce you to the system, but as noted above I think this would be better off dealing with something like login and registration rather than what is effectively a Hello World demo.
Conclusion
Zimki is not ready for market. They have a nice concept, and with a little more work to make what they have really shine, it could become very competetive. However, this competition to build a business on Zimki is entirely premature. Give me a choice between a possible £10k with a development process full of hacks and work arounds to use the framework, versus a smooth development process where I don’t get a cash gift after 6 months, and I think I’d pick the latter.
I think they need to start getting feedback from developers about the weak points in their product. A pair of developers building an application will run across plenty of problems in a pretty short time frame, even only working on it 2–3 evenings a week. They could regularly report back on areas that were harder than they ought to be, and the dev team could work on improving them.
![[SIGNED]](http://perlitist.com/static/common/images/lock.png)
