A couple of days ago I was asked to look into animations that would work on iPad. You could use CSS3 tranformations, but I was excited to see what I could do in SVG instead. Why? Because why not!
Off I went, and not too much longer I had this: http://www.tabeoka.be/downloads/svg/blokskes.svg . Cute. Works smoothly on all browsers that matter. Is a little jittery on Opera.
Turns out SVG is a lot of things I've wanted HTML to be in the past. Have you ever created a DIV just to make a rectangle? SVG is for you. It's HTML for making pretty pictures. It supports css and most of the javascript DOM methods you're used to. Pick it up and go.
Back to my image though: I could slap an image on there, and pretend the website is being swallowed by a maelstrom. Right?
Well, here's a unicorn with an unfortunate case of being torn into rectangles: http://www.tabeoka.be/downloads/svg/blokskes_fill.svg . The most unfortunate part though, is that the unicorn is being torn up very slowly. Unfortunate for the unicorn, certainly, but more unfortunate for my ambition to animate stuff using SVG. What's up with that?
I must be doing something wrong. I can't believe my computer can render this, but not chop up a unicorn (where are its priorities?). Internet Explorer 9 is supposed to have hardware accelerated svg rendering. If this is the result, it must have needed that acceleration real bad. And I can believe Microsoft messed up SVG performance in IE, but every damn browser is slow!
In the past I did some animation where I would suspend rendering while updating the object hierarchy, and then restart rendering. But this article suggests browsers are not stupid; that's too bad. I think I am to conclude that fully SVG-driven animations are not quite ready from prime time. But when the performance catches up, the object model will be ready. I like SVG, but it's such a tease.
Menno
Code Highlighting
Monday, November 26, 2012
Monday, November 19, 2012
Drupal: open-source CMS
Drupal has been pretty popular with the various Belgian governments. Any new websites created for a government agency are supposed to use an open-source CMS. Drupal's popularity (and its Belgian roots?) have made it the perfect candidate. Heck, even the king uses it. A new initiative is Drupal-as-a-service: pick your features and click "Create website". Off you go!
With the government's zeal to convert everything to open-source the buzz has been increasing. Universities request websites built on Drupal, marketing people want their new website in "Druple".
So what's up with this love for open source? I will now wield my razor-sharp intelligence to shamelessly make up what I think is most likely:
With the government's zeal to convert everything to open-source the buzz has been increasing. Universities request websites built on Drupal, marketing people want their new website in "Druple".
So what's up with this love for open source? I will now wield my razor-sharp intelligence to shamelessly make up what I think is most likely:
- Avoiding vendor lock-in
Every few years, the government is required to field a project to get price quotes from a number of parties, and then pick the best price quote.
If a project has been written using a proprietary framework/platform/language/etc the best candidate will likely be the candidate who initially set up the project. Any other candidate would need to either swallow the costs of a steep learning curve, or be more expensive.
Not so for open source. Anyone who knows Drupal/Joomla/Wordpress/But mostly Drupal can pick up a website and go! Money savings galore! - Open data
Whether you have access to the source of your CMS or not, the data on your site is yours. If you switch to a different system, you want to keep your data. If a proprietary system perishes, your data could perish with it. In an open source system, you have the ultimate data spec: the source code. - Security updates
Whenever a security leak is found, noble developers will flock to it, and release a security patch in no time at all. Government sites need to be secure, right? - Oh! The modules!
If you have a Drupal-based website and you want to add a online shop, you only need to install Drupal commerce. Works instantly! Hardly any configuration required! Money savings galore!
More to the government point: integrate with the Belgian electronic ID card (currently has some security issues). - Open source means no license means cheap! Right?
No it doesn't. And I doubt the government is stupid enough to believe this.
Some of those are pretty solid reasons. I want the government to spend my tax money wisely (frugally even), and store my personal data on secure servers! Who wouldn't?
But here's the thing: when we make a Drupal website, the customer comes back and tells us
"We don't like the way this editing form works. Can you make it do x and y instead?"
And we can. The customer's request makes sense: core Drupal is pretty spartan, and a lot of modules are a tad confusing. We just code up a nice custom module that does exactly what the customer wants.
But here's the catch:
Those custom modules can be neither open-source, nor secure (nor very well-written for that matter).
That includes some modules that I've written. It's vendor lock-in all over again.
That includes some modules that I've written. It's vendor lock-in all over again.
We inherited a Drupal project from a competitor, and the last few weeks I've been poring over custom modules that implement some form of url rewriting using taxonomy terms. It's a very neatly commented and indented mess, and has a fair number of bugs - I'm not sure I can do better. I'm familiar enough with Drupal, but my employer has had to swallow these costs anyway. You can't pick up a major website and run with it. Open source doesn't matter that much here.
As far as the open data is concerned, I think that's a valid point. I have written a proprietary CMS in .NET, and I encrypt all website data using AES-256 before storing it in the database using an 'optimized' version of Base64. I double-dare customers to switch to a competitor (I kid, of course). But I could do such a thing, call it 'Enterprise-level security', and sell it to the banking industry.
Using open source, getting my data is not necessarily easier, but I know it can be done.
Using open source, getting my data is not necessarily easier, but I know it can be done.
Lastly, about the security updates. The sysadmin is usually the weak link here. Nobody will likely ever find a security hole in my proprietary CMS, because nobody cares. There will, 100% sure, be security updates for Drupal. For all eternity: either you patch or you're vulnerable. My CMS may actually be safer than Drupal. Not by virtue of its technical qualities, but just because it's a tiny fish in a pretty small pond.
After all: wasn't Apple repeatedly the first to be hacked at pwn2own ?
After all: wasn't Apple repeatedly the first to be hacked at pwn2own ?
Menno
Subscribe to:
Posts (Atom)