Disqus - Latest Comments for deanlandolt

Re: The Definitive TypeScript Guide

deanlandolt — Wed, 15 Jan 2014 13:02:22 -0000

"Enums that use bitwise operators should be specified to explicitly use 2n values for each item"

Should this say n^2 instead?

Re: cyberhoboing with dominic tarr, Some Thoughts on the Economics of Software Development

deanlandolt — Thu, 02 Jan 2014 08:55:53 -0000

This a great breakdown of the space -- I'm looking forward to seeing what you're cooking up.

In your "one more way" section you mention the funding model I'm particularly familiar with (bespoke systems) but you stop short of closing the loop and mentioning the coopetition model. This is where likeminded companies with a shared need band together to fund the development of an open platform they can build on. This has worked for the web (and it may yet work for payments) but it hasn't really caught on like it should have. Small to medium sized businesses spend a fortune on shitty "ERP", for instance. And the poor saps that need a database for something? We both know how screwed they are, even today. There's a fortune to be made in providing companies (even large ones) a migration path out of the Excel-as-database trap.

If this isn't what you're starting to tease at I really hope someone starts grinding on this. There's just so much shitty software being written that's nothing but waste. The only way this can fly is with buy-in from a small proportion of some industry, but there has to be a middle ground between spending a little on licensing a terrible product and a ton on building a bespoke cross to bear.

Re: Should I use a single LevelDB or many to hold my data?

deanlandolt — Tue, 08 Oct 2013 16:42:58 -0000

Brilliantly put, especially the notion that we need not be stuck in one dimension!

I've been trying to get across the idea that the world -- and every damn database table and spreadsheet in it -- exist in one very large (and abstract) tuple store with some fancy namespacing. It's surprising to me how foreign this concept seems to be to people, but also how easy it is to prove to people, even RDBMS skeptics.

Re: http://metaduck.com/post/1618386212

deanlandolt — Fri, 19 Nov 2010 12:48:23 -0000

The sum of what you're asking for is a pretty tall order, but given the momentum server-side js is getting I think it'll come to pass sooner rather than later.

*Most* of what you're asking for is already implemented in perstore [1] (and then some). Some time ago I implemented a node-dirty-like store for perstore [2] (that has since been refactored by Kris Zyp to support transactions and other fun stuff and become the default store)...

It's append-only and while you can forEach and filter your results programmatically, you also get an awesome query language [3] where you can take advantage of in-memory indexes.

In perstore your models are like the buckets you describe, so you'd have one model per bucket. When using the persistent memory store you'd have a different database file for each "model" (in other stores, like couch, mongo or sql, you can have multiple models stored in one database). You can also (optionally) provide a schema to define their structures.

As for metadata, the models are persisted in a class model and can be accessed and managed just like your other models, all while the application is running.

Timestamping is easy -- you get hooks into each model's lifecycle so you can tack on a timestamp (or increment or a revision number, or whatever) on every `put` if you wanted, or if it's something you'd do to all your models it's easy enough to write a decorator for all your models.

We do replication at the application level with a store wrapper so you can even replicate things stored in one type of database to an entirely different database if you wanted -- the benefits of a uniform interface cannot be overstated!

The persistent memory store doesn't do compaction but it ought to be easy enough to implement -- the hard part is picking the right strategy. I fancy the couch approach of on demand compaction in another file and swapping when finished. The nStore approach of doing it on each full query is interesting too but may be a little aggressive. There may be other strategies more appropriate for a given workload, so this too seems like something that ought to be configurable.

As for durability, I'm not sure if we have an option to force an fsync but that would be an interesting config option, both on a per-model basis as well as a per-request basis.

[1] https://github.com/kriszyp/...
[2] https://github.com/kriszyp/...
[3] https://github.com/kriszyp/rql

Re: Open ID Is A Nightmare

deanlandolt — Thu, 18 Nov 2010 13:10:23 -0000

But there's the rub: you can't just say "replace {non-scarce good} with {scare good}, ipso facto".

Re: A Universal Package Manager for JavaScript

deanlandolt — Mon, 19 Apr 2010 15:50:04 -0000

Awesome work! One question though: where does the actual package index live? I can't find any reference to it on the site. In the CommonJS announcement Charles mentions that seed is "pre-seeded" with some packages -- are these just bundled with the seed package? Are there any plans for a package index?

Re: http://thechangelog.com/post/501053444

deanlandolt — Tue, 06 Apr 2010 16:28:43 -0000

Great talk...

Just to clarify around the fab conversation. The Rack standard is called Rack (yeah, confusing). Jack was the JS version of rack but it was suggested that calling the standard and an implementation of it the same thing was a bad idea, so the name of the standard was changed to JSGI (also a hat-tip to python's WSGI, which inspired Rack).

Another clarification: JSGI fully supports asynchronous responses and request and response streaming. As far as I know neither Rack nor WSGI can do this but JSGI managed to get this nailed down. Oh, and it works on node:

http://github.com/kriszyp/j...

Re: Brian Beck's Text Adventure - highlight.js language file for Python profiler output

deanlandolt — Wed, 18 Jun 2008 23:51:49 -0000

Wow. The profiler plugin's great and all, but I'm highlight.js itself looks brilliant. Is there _any_ good reason for server-side highlighting now?