It's more a matter of learning how you can use them in various ways, and also of really getting into the habit of thinking with deferreds. I've been using them for about 7 years (mainly in Python) and I'm still finding interesting new ways to think about them, new tricks, etc. [Disclaimer: I'm also one of the book's authors.] BTW, if you use AUTHD as a discount code on the O'Reilly site, you'll get 50% off the e-book price or 40% off a dead tree version.
I agree, our website is very poor. We're planning to improve it over the next week. There are quite a few hands-on programming examples and videos on our blog, at http://blogs.fluidinfo.com/ that might be helpful.
I hope that helps! Please feel free to mail me (terry fluidinfo com) or drop by #fluidinfo on irc.freenode.org to ask questions or give us a hard time :-)
Get a lawyer. Go check out the list of suggested good start-up lawyers on http://venturehacks.com
You do NOT want to sell without a negotiated contract for your (all of you) ongoing employment. You need a lawyer for that, DON'T do it yourself.
Some of what the other side is telling you is clearly manipulative (no surprise). If they want to buy you, insist that they do it properly. You owe it to yourselves, and the other side will respect you for it - guaranteed.
I'd be happy to answer questions about Tickery. The point of it is not what it appears to be from just looking at the web app. Read the Huh? dialog on the advanced tab, and also see the text on the About tab. It's not really about sets of Twitter friends, it's about FluidDB and what happens when an app (e.g., Tickery) stores its data into an openly writable database.
FluidDB is very exciting technology once one gets past the initial "WTF". I'm looking forward to more user-facing applications.
Not really a Tickery question, but I'm curious about how one could extract subsets of data for off-line use and then replicate this when back online. Understanding that the plan is to open-source FluidDB, what kind of resources would be required to run a "mini-FluidDB"?
Hi. I don't really know the best way to do this, though I have thought about it over the years. I think things like Google Gears will be a big help with this sort of thing. But it should also be possible to write smart client-side libraries that let you you modify objects locally and only sync when they can. That would certainly be fine for new objects you create, and for tags you have control over, but would be more involved if you (and others) were offline changing tags over which you all had control. Those kinds of things tend to run into difficult issues - which is mainly why I say I don't know how to solve this (fully). Running a mini client-side FluidDB shouldn't be too hard, especially with things like sqlite being built into some browsers. But again, lots and lots of details.....
The information model takes some time to sink in - at least for most people (including me). Examples will help people to "get" it better. We have one coming out soon (next couple of weeks). I can give you an early look if you're ineterested.
I guess I'll get the ball rolling. We're building (and close to releasing) an app that's focused on Twitter users. It has FluidDB objects that each correspond to a Twitter user. Because the FluidDB objects aren't owned, other apps can put their tags onto the objects too. The query language lets you search on objects based on any tags (that you have read permission for), so we're hoping we'll soon see a wide variety of tags on these objects, which will give us a bunch of new ways to identify users on Twitter, to tag them arbitrarily, etc. The are obvious things like ratings, or people you've met, but there are also lists (a tagged set of users is just a list, more or less) including queries that cross lists, and things like http://tunkrank.com scores about Twitter users. FluidDB gives a place to put all that stuff - without requiring you to ask permission or for your needs to be anticipated - and it gives you a way to query on it too.
That's just a first app. We'll open source it. I can think of many more, as you might hope :-)
Terry Jones
(disclaimer: I work for Fluidinfo, makers of FluidDB)
