nateps

47 ms·

151.
What Getting Fired Taught Us About Hiring(blog.lever.co)
7 points by nateps 13y ago|0 comments
152.
Lever (YC S12) - Build hiring software that engineers love using(jobs.lever.co)
1 points by nateps 13y ago
153.
by nateps 13y ago
Congrats! Glad to see you ended up with such excellent investors, and will be looking forward to continued improvements in Firebase! Looking forward to more progress making all web apps realtime.
154.
by nateps 13y ago
While we've only written a MongoDB plugin so far, we have designed specifically to be work with any similar datastore. Contributions of other database plugins are welcome. The Mongo implementation is here for reference: https://github.com/
155.
by nateps 13y ago
This module is intended specially for spiders to be able to see something of what the rendered page would look like. That provides an SEO stop gap, but it does not have any effect on regular users. Server-side rendering the first request gr
156.
by nateps 13y ago
OT is done at the document level. Documents are JSON objects of arbitrary complexity. Any mutation of the JSON object can be composed against any other mutation of the JSON object. Firepad doesn't actually do OT of JSON. In Firepad, a strin
157.
by nateps 13y ago
Definitely try playing the collaborative story game demo explained in the post: http://stories.derbyjs.com/
158.
Derby v0.5.0 – The first OT-powered realtime web app framework(blog.derbyjs.com)
154 points by nateps 13y ago|55 comments
159.
Preview of Racer 0.5 and ShareJS for scalable Derby apps(blog.derbyjs.com)
6 points by nateps 13y ago|0 comments
160.
by nateps 14y ago
http://sharejs.org/ is in use for a number of production sites, and we've had users report that it is quite reliable. How would you like to see it further generalized?
161.
by nateps 14y ago
We are still actively developing Derby and Racer. We are currently working on a re-write of Racer's internals on top of ShareJS that will make Derby useable for a production app. See: http://blog.derbyjs.com/2013/03/26/getting-derby-ready-
162.
Getting Derby ready for prime time(blog.derbyjs.com)
8 points by nateps 14y ago|1 comments
163.
Derby authors hiring software engineers for next generation talent software
1 points by nateps 14y ago
164.
Derby.js – Creating a Twitter Bootstrap Input Component(codetype.wordpress.com)
6 points by nateps 14y ago|0 comments
165.
Node.js Frameworks Comparison(ocdevel.com)
18 points by nateps 14y ago|6 comments
166.
A Derby Version of the TodoMVC Project(micknelson.wordpress.com)
11 points by nateps 14y ago|0 comments
167.
by nateps 14y ago
To clarify, I agree that RDBMS's are fantastic, and you pointed out many of the benefits. We are not religious about SQL vs NoSQL. For our particular use cases, we think that document stores are a better fit, but I am not arguing that docum
168.
by nateps 14y ago
Actually, we are big fans of modular libraries. We know that a lot of the code in Derby and Racer is too monolithic, and we intend to restructure as the projects mature. For example, we already refactored out Derby's simple HTML parser ( ht
169.
by nateps 14y ago
Thanks, Zach!
170.
by nateps 14y ago
This is correct. We have been developing and testing auth with our own app, and we'll publish a simple example using it soon.
171.
by nateps 14y ago
Thanks for the support! We understand that authentication and authorization are critical, and we have been ironing our issues with them using the app that we are developing as a first test. Pretty much all of the required code is already in
172.
by nateps 14y ago
In the future we would like to make it easier to do relational queries, but we plan to continue to use document stores instead of RDBMS's. Document stores are more easy to map to the way that data is represented in JavaScript, and they make
173.
Things I’m loving about derbyjs(micknelson.wordpress.com)
62 points by nateps 14y ago|7 comments
174.
by nateps 14y ago
Personally, I agree that sticking with npm is the best solution. We have managed to do this with Derby ( http://derbyjs.com/ ) while still providing easy app creation, automatic packaging, realtime data syncing, and reactive model-view bind
175.
by nateps 15y ago
I can't speak for Meteor as much, but Derby's bindings support pretty much everything that Knockout and Ember can do. The big difference is how you connect the bindings to model data. Knockout has a generic API that you can pass pretty much
176.
by nateps 15y ago
The reason we use a document based datastore is that it is easier to think about conflict resolution, and it maps more easily into how JavaScript represents data in the browser. It is common for large-scale eventually consistent systems to
177.
by nateps 15y ago
Comparing PHP and Rails to Node.js is not quite right, as PHP and Rails are application frameworks and Node.js is primarily a platform for creating application servers. There are a number of more analogous frameworks being written on top of
178.
New syntactic sugar in Derby(blog.nateps.com)
1 points by nateps 15y ago|0 comments
179.
by nateps 15y ago
This is the approach that we took with the Derby framework ( http://derbyjs.com/ ): we use a template engine that parses Mustache-like templates and infers bindings at the same time. You don't have to write any additional bindings declarati
180.
HTML Comments: The Unlikely Solution to Valid DOM Bindings(blog.nateps.com)
2 points by nateps 15y ago|0 comments

More ›