audreyt

11 ms·

61.
by audreyt 13y ago
Coco: I'd rather be writing Perl-flavored Ruby. LiveScript: I'd rather be writing Perl-flavored Ruby, with a Haskell syntax. ( http://livescript.org/ )
62.
by audreyt 13y ago
Well, limiting the range, commonly associated with a paging (or infinitely scrolling) UI, entails tie-breaking somehow. A simple tiebreak function — such as lexicographic sorting on keys — means when the user requests "next page"
63.
by audreyt 13y ago
Agreed on all accounts, with one small, specific clarification: If computation is local to each of many long-running threads, and the two-way messages being passed around is small enough (so the serialization overhead is negligible), then t
64.
by audreyt 13y ago
Hi, maintainer of https://github.com/audreyt/node-webworker-threads/ here. We're using it happily in production, and it's proved to be quite stable, and there's quite a few users — certainly more th
65.
by audreyt 13y ago
Yes, we're certainly inspired by Kanso. PgREST was originally designed for a large, in-production Postgres app (i.e. Socialtext), so we can get all the model, validation, view & trigger code in one place, getting the benefits of Co
66.
by audreyt 13y ago
... it was, in fact, partly inspired by the Markov chain hack. #BuzzwordBingoButTrue :-)
67.
by audreyt 13y ago
For authentication (authn) it's quite easy, and in production we do have a separate authn daemon. For authorization (authz) it's IMHO a bit better to handle it in the DB level, similar with Firebase's ACL lists.
68.
by audreyt 13y ago
Excellent question! The REST API part should be familiar to any Rails programmer. The main difference is that back-end models, validation rules, triggers and views are coded in DB level via stored procedures written in Node.js-compatible mo
69.
by audreyt 13y ago
Well, this is more like an open-source (partial) reimplementation of Firebase so anyone can host it... :-) Firebase++ for an extremely well-thought-out API, though!
70.
by audreyt 13y ago
Very likely so for the majority of use cases, yes.
71.
by audreyt 13y ago
For backend programming, SQL is certainly the most familiar language. We don't generally send SQL over the wire, though. :-) That is to say, front-end programmers usually work with a middleware (or backend-as-a-service) layer that tran
72.
by audreyt 13y ago
Yup. Nested hstore and JSON are going to be semantically equivalent ("cast" works both ways), and PgREST will support them equally once 9.4 is released. PgREST also comes with a shim JSON type for Postgres version 9.1 and earlier,
73.
by audreyt 13y ago
The main motivation is to use the same set of npm-managed modules for backend and frontend model+logic. A secondary motivation is using two familiar APIs — MongoLab and Firebase — to access existing PostgreSQL databases. (We're using t
74.
PgREST: Node.js in the Database, compatible with MongoLab and Firebase API(pgre.st)
109 points by audreyt 13y ago|33 comments
75.
by audreyt 13y ago
The romanized form "Saumfa" is also shown in https://www.youtube.com/watch?v=vYVoM8tgbvA#t=0m26s .
76.
The Performance of Open Source Applications(aosabook.org)
1 points by audreyt 13y ago|0 comments
77.
by audreyt 13y ago
Flow-control macros often become plain functions in Haskell, thanks to a combination of lazy evaluation and monadic syntax. `while`, `for`, `or` etc are all just regular functions. That said, macros are still useful for embedding foreign la
78.
by audreyt 13y ago
A viable alternative may be in-vitro fermentation: http://www.chinapost.com.tw/taiwan/national/national-news/20... There was a marketing campaign earlier this year in Taiwan around the animal-cruelty-free pro
79.
by audreyt 13y ago
The regex-genex SMT constraint solver ( previously covered in https://news.ycombinator.com/item?id=2579783 ), as demonstrated by @LeventErkok ( https://gist.github.com/LeventErkok/4942496 ), is pretty
80.
by audreyt 13y ago
Poetic: "Antes de Morir, Yo quiero Dormir."
81.
by audreyt 13y ago
The Chinese translation makes it much, much more accessible to the general public, though: http://artsbeat.blogs.nytimes.com/2013/01/30/finnegans-wake-... A page from the Claybook, for the Abcedminded among u
82.
by audreyt 13y ago
In addition to JavaScript, the plv8 module also supports CoffeeScript and LiveScript ( http://livescript.net/ ) procedures, with "CREATE EXTENSION plcoffee" and "CREATE EXTENSION plls" respectively.
83.
by audreyt 13y ago
At Socialtext, we're working on https://npmjs.org/package/plv8x that installs npm packages into Pg, and maps Node methods directly into Pg functions. This provides a safe and modular alternative to PL/PgSQL and PL/Perl, and lets us re-use
84.
by audreyt 13y ago
TBH, this seems more like porting perl 1 ( https://github.com/TPF-Community-Advocacy/perl1.0 ) to Haskell. :-)
85.
by audreyt 13y ago
The plv8x project ( https://github.com/clkao/plv8x ) adds convenient JSON and JS/LiveScript selector operators: https://speakerdeck.com/audreyt/pgrest-node-dot-js-in-the-da... covers the basic usage and the motivation, as well as the on
86.
by audreyt 14y ago
WebWorker with native threads is available on Node.js: https://github.com/audreyt/node-webworker-threads For an alternate model of parallel computing, WebCL (OpenCL) has been ported to Node.js as well: https://github.com/fifield/node-web
87.
by audreyt 14y ago
It's a 2-dimensional presentation; one can use the up- and down-arrow keys for subsection navigation instead of clicking links.
88.
by audreyt 14y ago
The way this works is that it essentially reduces two independent guesses (A=X && B=Y) into one guess (A=B).
89.
by audreyt 14y ago
The team of A and B can increase the chance from ¼ to ½ by consistently taking their output from step 2 and using it as the guess for step 3. Same thing if they both agree to guess the inverse of step 2.
90.
by audreyt 14y ago
This is a draft for an upcoming book, and comments/feedback would be much appreciated! BTW, for environments where WebWorker-Threads is not an option (e.g. Node.js 0.6), https://github.com/audreyt/ethercalc/commit/0f41d20324833885... prov

More ›