The first draft of this rant came out with a pretty negative tilt to it.\nI think this is mostly because I felt frustrated and let down. I’d\nreally bought into the concepts that were being offered, and after having\nsome stuff go right, having something go wrong is even more frustrating.\nI’ve reworked it to take a more objectively-critical attitude, rather\nthan a pissed-off one. Hopefully I managed it!
\n\nZimki recently announced a
The big selling point of Zimki seems to be taking out the grunt work so\nthat you can get on with the important stuff. From the blog of\nFotango’s MD:
\n\n\n\n\nThe point of Zimki is to take care of the now mundane (setting up\n servers, configuring databases, backups, scaleability, yada yada yada ...\n stuff we call “yak shaving”) and allow developers to focus on\n the interesting stuff of building something new by providing\n “pre-shaved yaks”.
\n \n \n
A vision which has much in common with existing frameworks, plus a little\nextra around the edges. Unfortunately, plenty of stuff seems to be getting\nin the way of that perfect vision.
\n\nZimki provides a web based interface — Portal — through which\nyou could theoretically do all your coding. Unfortunately they have ommited\nthe capactiy to edit files, so your static CSS and Javascript files have to\nbe edited offline and then uploaded.
\n\nBut nevermind, to solve this, and get around the problem that coding in a\ntextarea is a nightmare (do you ever use the tab key?), there are a couple\nof remote syncing scripts: Zync or Zwim. Yes, the wordplay is intentional,\nthat’s how the guy who wrote Zwim came up with the name.
\n\nBoth these scripts push files from your system onto the Zimki server. Of\nthe two, Zwim is a far better option, allowing yanking, shoving, and syncing\n— Zync only allows shoving. However, neither Just Work, leaving the\nuser to fiddle with things even before they’re up and running.
\n\nIncidentally, neither of these tools are public domain yet, I just got\nhold of them because I know a developer.
\n\nTo really sell this product to developers, you need a good development\nenvironment in place. I believe the remote syncing apps are the right\ndirection to take, leaving the developer to keep their own well tuned\nenvironment, but they’re just not polished enough yet.
\n\nEvery website that needs the power of a framework and a server side\nlanguage will use input forms. Every. Single. Website. But somehow,\nthere’s nothing in Zimki to handle display and validation of\nforms.
\n\nAt the very least, I’d like to see some sort of validation\nframework included where you can specify which fields are required, what\nregexs they must match, and custom functions for more complex validation\nlike “does that email already exist”.
\n\nWhere is email sending? After picking through the results of a search for\n“email”, I find the one page which mentions what I’m\nafter:
\n\n\n\n\nPremium services
\n \n\n \n \n
- There is an additional charge for certain services, such as\n sending email. This is levied on a per unit basis.
So, one mysterious mention for sending email, which implies it is a\npay-for service. If I’m supposed to be building a business on Zimki,\nI’m not filled with confidence.
\n\nOne thing which I think would work really well in Zimki’s favour is\na walk through for developers to build registration and login functionality\nin 10–15 minutes. This would make for an incredible first experience\nwith the system, and wouldn’t be too much work for the Zimki team to\npull off.
\n\nThe way things work on a technical level could also do with a little\ntightening up: User registration cannot even be made case insensitive\n— at least, not with a simple flag: you can search for the username\ncase insensitively and reject registration or use the found username to\nlogin — so if you don’t do the check yourself you can have a\n“Dom” and a “dom” registered in the system.\nConfusion ahoy!
\n\nWhilst there is good support for creating thumbnails, there’s no\nsupport for image rotation or cropping. Given that I’m used to the\nflexibility offered by GD and ImageMagick, the lack of control here is a\nlittle annoying.
\n\nThis isn’t such a biggy, because not everyone needs it, and\nI’m reliably informed that a future version will support these\nfeatures.
\n\nFeatures aside, the documentation provided by Zimki is shockingly lax.\nSearch seems to work ok, but both the content and presentation —\nespecially the handling of <code> fragments — of the docs needs\na lot of work to make it a useful resource.
\n\nThere is a “Cookbook” to introduce you to the system, but as\nnoted above I think this would be better off dealing with something like\nlogin and registration rather than what is effectively a Hello World\ndemo.
\n\nZimki is not ready for market. They have a nice concept, and with a\nlittle more work to make what they have really shine, it could become very\ncompetetive. However, this competition to build a business on Zimki is\nentirely premature. Give me a choice between a possible £10k\nwith a development process full of hacks and work arounds to use the\nframework, versus a smooth development process where I don’t get a\ncash gift after 6 months, and I think I’d pick the latter.
\n\nI think they need to start getting feedback from developers about the\nweak points in their product. A pair of developers building an application\nwill run across plenty of problems in a pretty short time frame, even only\nworking on it 2–3 evenings a week. They could regularly report back on\nareas that were harder than they ought to be, and the dev team could work on\nimproving them.
\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.6 (GNU/Linux)\n\niD8DBQFGE7Dq25rVNeBWZU0RAsjuAJ43Ypg3LwmkqDpT8fnud8kARioLtACfVNQZ\nJ+6Jo1YisGDy10gqEdHz2Lw=\n=pFCk\n-----END PGP SIGNATURE-----\n" signed: 1 summary: " SHAVED YAKS NOTHIN’! -------------------- The first draft of this …" tags: - bitching: 0 - zimki: 0 text: "\nSHAVED YAKS NOTHIN’!\n--------------------\n\nThe first draft of this rant came out with a pretty negative tilt to it.\nI think this is mostly because I felt frustrated and let down. I’d real-\nly bought into the concepts that were being offered, and after having\nsome stuff go right, having something go wrong is even more frustrating.\nI’ve reworked it to take a more objectively-critical attitude, rather\nthan a pissed-off one. Hopefully I managed it!\n\nZimki recently announced a £10k competition [1] to be given to the per-\nson who builds the best business off the back of Zimki. The aim behind\nthe idea seem to be sound — give Fotango some real life products they\ncan point at to show that Zimki *is* a viable choice — but the framework\njust plain isn’t ready for building a business on.\n\nThe big selling point of Zimki seems to be taking out the grunt work\nso that you can get on with the important stuff. From the blog of\nFotango’s MD:\n\nThe point of Zimki is to take care of the now mundane (setting up\nservers, configuring databases, backups, scaleability, yada yada ya-\nda ... stuff we call “yak shaving”) and allow developers to focus on\nthe interesting stuff of building something new by providing\n“pre-shaved yaks”.\n\nSimon Wardley [2]\n\nA vision which has much in common with existing frameworks, plus a lit-\ntle extra around the edges. Unfortunately, plenty of stuff seems to be\ngetting in the way of that perfect vision.\n\nPROBLEMS\n\nDevelopment environment\n\nZimki provides a web based interface — Portal — through which you could\ntheoretically do all your coding. Unfortunately they have ommited the\ncapactiy to edit files, so your static CSS and Javascript files have to\nbe edited offline and then uploaded.\n\nBut nevermind, to solve this, and get around the problem that coding in\na textarea is a nightmare (do you ever use the tab key?), there are a\ncouple of remote syncing scripts: Zync or Zwim. Yes, the wordplay is in-\ntentional, that’s how the guy who wrote Zwim came up with the name.\n\nBoth these scripts push files from your system onto the Zimki server. Of\nthe two, Zwim is a far better option, allowing yanking, shoving, and\nsyncing — Zync only allows shoving. However, neither Just Work, leaving\nthe user to fiddle with things even before they’re up and running.\n\nIncidentally, neither of these tools are public domain yet, I just got\nhold of them because I know a developer.\n\nTo really sell this product to developers, you need a good development\nenvironment in place. I believe the remote syncing apps are the right\ndirection to take, leaving the developer to keep their own well tuned\nenvironment, but they’re just not polished enough yet.\n\nForms and validation\n\nEvery website that needs the power of a framework and a server side lan-\nguage will use input forms. Every. Single. Website. But somehow, there’s\nnothing in Zimki to handle display and validation of forms.\n\nAt the very least, I’d like to see some sort of validation framework in-\ncluded where you can specify which fields are required, what regexs they\nmust match, and custom functions for more complex validation like “does\nthat email already exist”.\n\nEmail\n\nWhere is email sending? After picking through the results of a search\nfor “email”, I find the one page which mentions what I’m after:\n\nPremium services There is an additional charge for certain services,\nsuch as sending email. This is levied on a per unit basis. Zimki Billing\nOverview [3]\n\nSo, one mysterious mention for sending email, which implies it is a\npay-for service. If I’m supposed to be building a business on Zimki, I’m\nnot filled with confidence.\n\nRegistration and login\n\nOne thing which I think would work really well in Zimki’s favour is a\nwalk through for developers to build registration and login functional-\nity in 10–15 minutes. This would make for an incredible first experi-\nence with the system, and wouldn’t be too much work for the Zimki team\nto pull off.\n\nThe way things work on a technical level could also do with a little\ntightening up: User registration cannot even be made case insensitive —\nat least, not with a simple flag: you can search for the username case\ninsensitively and reject registration or use the found username to login\n— so if you don’t do the check yourself you can have a “Dom” and a “dom”\nregistered in the system. Confusion ahoy!\n\nImage manipulation\n\nWhilst there is good support for creating thumbnails, there’s no sup-\nport for image rotation or cropping. Given that I’m used to the flexi-\nbility offered by GD and ImageMagick, the lack of control here is a\nlittle annoying.\n\nThis isn’t such a biggy, because not everyone needs it, and I’m reliably\ninformed that a future version will support these features.\n\nDocumentation\n\nFeatures aside, the documentation provided by Zimki is shockingly lax.\nSearch seems to work ok, but both the content and presentation — espe-\ncially the handling of fragments — of the docs needs a lot of\nwork to make it a useful resource.\n\nThere is a “Cookbook” to introduce you to the system, but as noted above\nI think this would be better off dealing with something like login and\nregistration rather than what is effectively a Hello World demo.\n\nCONCLUSION\n\nZimki is not ready for market. They have a nice concept, and with a lit-\ntle more work to make what they have really shine, it could become very\ncompetetive. However, this competition to build a business on Zimki is\nentirely premature. Give me a choice between a possible £10k with a de-\nvelopment process full of hacks and work arounds to use the framework,\nversus a smooth development process where I don’t get a cash gift after\n6 months, and I think I’d pick the latter.\n\nI think they need to start getting feedback from developers about the\nweak points in their product. A pair of developers building an applica-\ntion will run across plenty of problems in a pretty short time frame,\neven only working on it 2–3 evenings a week. They could regularly report\nback on areas that were harder than they ought to be, and the dev team\ncould work on improving them.\n\n-- \n [1] http://promo.zimki.com/Business_Competition/index.html\n [2] http://swardley.blogspot.com/2006/10/commoditisation.html\n [3] http://docs.zimki.com/Billing%20Overview\n"
title: Shaved yaks Nothing'!
type: html
uri: http://perlitist.com/articles/shaved-yaks-nothin
xhtml: "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”.
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.
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.
"