I’m annoyed. Ever since I got my MacBook Pro several months ago I held out some hope that iSync in Leopard would support my BlackBerry 8800. Nope. Still unsupported.
I would imagine that Apple has kept the support out because of the iPhone. It’s obvious that RIM is in direct competition with Apple’s iPhone.
Oh well. I’ll continue to use mising sync for blackberry.
I confess: I’ve been very lax with development on evedb. The biggest reason why is because too many features have been creeping their way into the application before other ones are completed. I have no project management going on here and I’ve let the project get away from me.
The moral is: track large projects and stick to a fixed roadmap. I must organise this project. I think I’ll give Trac a look.
One part of code optimisation that is relatively easy is to cache the results of expensive operations. It’s really simple. CACHE.set. But it isn’t so simple. There are a seemingly endless possible ways the cache can be used improperly or otherwise fail. Handling these problems is the real work of caching.
The last checkout (around rev 250?) I did of Cache_fu (the acts_as_cached rewrite) it was pretty immature, chiefly in our need: An easy way to do arbitrary key names. n.b., I’m aware that there is a way but it seemed against the flow of this codebase. I use it, still, for the magic :all keyname.
But I need more, to store created JSON (To create what results in 100KB of JSON is a lot of objects and a lot of create time!) with a dynamic key in several distinct situations.
That round of caching improved API calls from 3 req/s to 300 req/s.
For the application most of the data can be cached but it needs to be done smartly: memcache server failures need to be handled (I suspect they are not, currently), server layout needs to be better (One daemon on each app server is not good, long term, IMHO), expiration of caches on data changes across the entire farm need to be smarter, deciding how long to cache data needs to be done.
CACHE.set and CACHE.get is really misleading; there’s a lot of things to consider!
I relish these challenges and look forward to solving them.
This is quite possibly the coolest thing I have seen all year.
Check out: fudgie.org and the Slashdot post here.
Here’s the screenshot he posted when he got slashdotted:
On Monday one of our clients from work will begin a campaign to market the product to the public.
This means that the API I’ve written for it is stable and will be put to the true load test. I suspect I will be busy this week attempting to improve the performance of the Rails code. It’s my hope that it will turn out to be perfect and we’ll surpass Twitter in terms of concurrent users. 
Probably not since Twitter has about 450k registered accounts, the client doesn’t expect that many.
With the bulk of the programming done the next phases come into play: optimisation and scaling. Both of these I’m a big fan of and I can’t wait to get into it.
It’s coming.
The new REST helpers are most appreciated.
Moving the proprietary adapters to a separate repository without any tests makes it impossible to modify the adapters. That irritates me a lot. How are we supposed to test patches that improve thing?
Powered by WordPress