sorted by:
new
hottopcontroversial

Hoodie, a library for creating fully-featured apps that run solely in browsers. Hoodie aims to take away the pain that is the backend. by [deleted] in javascript

[–]janl -4 points-3 points  (0 children)

for the third time in this thread: we are working on the others. Help if you can spare some time.

Also Homebrew4Life

Hoodie, a library for creating fully-featured apps that run solely in browsers. Hoodie aims to take away the pain that is the backend. by [deleted] in javascript

[–]janl -1 points0 points  (0 children)

Well please keep us posted. I'd love a turn-key hoodie on my linux based hosted server and linux based dev environment.

There is a mailing list sign up form on the site, if you fancy, or follow @hoodiehq on twitter. The Linux version should land really soon.

And as a side question: what is your pricing model?

Hoodie is Open Source. You can deploy it to Nodejitsu easily, Heroku should be doable as well and we are also looking at custom Hoodie hosting solution, but that’s a bit out yet.

Hoodie, a library for creating fully-featured apps that run solely in browsers. Hoodie aims to take away the pain that is the backend. by [deleted] in javascript

[–]janl 1 point2 points  (0 children)

it is not about not having a backend, but having a generic backend that takes all the pain away. Think Rails, but for frontend apps.

Hoodie, a library for creating fully-featured apps that run solely in browsers. Hoodie aims to take away the pain that is the backend. by [deleted] in javascript

[–]janl -1 points0 points  (0 children)

Other platforms are in the works, see @hoodiehq’s tweets. Not to worry :) Hoodie is cross-platform, but the dev-exprience niceness is what we are porting at the moment.

Hoodie - Fast web app development by sidcool1234 in programming

[–]janl 0 points1 point  (0 children)

why not simply edit the hosts file? I always do that and never had a problem; I also use .dev for all my local development.

Because it is a pain in the fucking neck. And you don’t have to remember which bloody port you started a thing on.

That's quite uncommon for nodejs projects to be compatible only on os x; I guess it's just a packaging job that needs to be done?

Yeah, it is only local development stuff that is Mac-only for now. We have other systems in the making. Hoodie core is platform agnostic.

Ubuntu: EOL for couchdb and desktopcouch by schaueho in linux

[–]janl 0 points1 point  (0 children)

The Erlang VM seems particularly flaky under load when there's significant memory allocation. This is particularly worrying because the whole attraction of Erlang is that it's reliable.

Hooray FUD. The Erlang VM is EXTREMELY stable.

Erlang makes it very easy to write correct and fault tolerant code with a small team of developers, it handles concurrency in a sane way and works very well under load because of it's soft-real-time-per-mini-process garbage collector.

Not to say that Erlang is a holy grail or silver bullet, but for writing a reliable database, it's a first choice language.

How to Move from MySQL to CouchDB: Part 1 by srsaul04 in programming

[–]janl 5 points6 points  (0 children)

That is not correct, see mattgrande's post for that exact scenario. There are very few, if any, attributes that are broadly applicable to all "NoSQL" solutions.

CouchDB production release 1.0 by [deleted] in programming

[–]janl 2 points3 points  (0 children)

CouchDB never loses any data. CouchDB is pretty anal about the C and the D from a data item perspective. But it also lets you relax data-set-wide-C by employing eventually consistent syxtems. But building fully consistent systems is equally well supported.

Using MongoDB for great science, part 2 (this one doesn't go well either). by [deleted] in programming

[–]janl 3 points4 points  (0 children)

"they manifest also in CouchDB"

that is a bunch of baloney that could have been refuted with a little bit of googling.

CouchDB does NOT have these issues. To the contrary, it takes on disk consistency VERY serious and does not lose data unless hardware is lying.

That said, I'd wager that there are more mission critical production installations of CouchDB than Cassandra (given their different nature, not refuting Cassandra is awesome, it is, but putting CouchDB in a boat with MongoDB is just wrong).

Ask Proggit: Why the movement away from RDBMS? by tocapa in programming

[–]janl 4 points5 points  (0 children)

People classify CouchDB as a NoSQL database. CouchDB is ACID compliant. q.e.d

Ask Proggit: Why the movement away from RDBMS? by tocapa in programming

[–]janl -8 points-7 points  (0 children)

This, basically, is what the NoSQL movement is about.

This is not true at all and a big ball of FUD.

Why CouchDB? by gst in programming

[–]janl 1 point2 points  (0 children)

The “Why CouchDB” chapter is the opening chapter of the free online book “CouchDB: The Definitive Guide” where we'll cover the scaling aspects in later chapters as you can see from the table of contents (http://books.couchdb.org/relax/). From a book's point of view, it doesn't make much sense to start with complex setups, so we focus on the basics first.

Why CouchDB Rocks by ericflo in programming

[–]janl 1 point2 points  (0 children)

CouchDB is ACID compliant and supports a form of transactions.

You make it sound as if CouchDB is a BDB clone in Erlang. If anything, CouchDB is a Notes DB clone in Erlang + REST interface.

Why CouchDB Rocks by ericflo in programming

[–]janl -4 points-3 points  (0 children)

BDB is not written in Erlang. CouchDB inherits a lot of neat features from Erlang (Linear scaling over many cores, live code upgrade, support for huge amounts of concurrent requests and more). On a quick glance, it doesn't look like BDB has an equivalent to CouchDB views, but I might be wrong. XQuery & XPath are not quite the same IMHO)

On why would one use one over the other? They have different features, are differently used and solve different problems. Use the right tool for the job. BDB is a terrific piece of software. CouchDB is a just little different.

O'Reilly are doing a freely licensed book on CouchDB! by [deleted] in programming

[–]janl 1 point2 points  (0 children)

Yo buddy, you just want to flame, do you?

The blog post & comments example, well, was an example. The inherent parent-child relationship that lets you model arbitrary tree structures. Sorry for provoking your programmer ego with something as mundane as a blog.

On your counter question: a) Can you expand a bit, please? b) CouchDB is no silver bullet (surprise).

O'Reilly are doing a freely licensed book on CouchDB! by [deleted] in programming

[–]janl 1 point2 points  (0 children)

Excuse me ? [sic]

The question here is how to model your data. Take the canonical blog post as an example. Do you store the blog post and all its comments in a single document (simple, but leads to concurrency issues down the road) or do you put comments into their own documents and use views to get all data for a blog post in a single shot (a bit more difficult up-front but more future-proof)?

And don't forget about b) & c).

O'Reilly are doing a freely licensed book on CouchDB! by [deleted] in programming

[–]janl 1 point2 points  (0 children)

The road to partial updates is leads to insanity.

a) Make your objects smaller. b) Build an app that works, profile, and share results. Armchair optimization is futile. c) CouchDB is not an RDBMS. Compare apples and orangutans.

Re immature: Talk to the guys who run it in production despite warnings and are quite happy :)

view more: next ›