HN user

gr2m

65 karma
Posts1
Comments52
View on HN

CropSwapLA is in my neighborhood, they do amazing work! Just the fact that a single residential property can grow enough produce for 45 families _each week_ is astonishing. Their technology in their latest farm (https://www.cropswapla.org/degnan) is very special as well: they refer to it as terraponic. 100% recycled water, but also using some soil for temperature and moisture control. Best of both worlds between traditional farming and 100% controlled aquaponics farms. The growing boxes are entirely separated from the ground, which limits pests and maintenance. Nutrition is provided through the water, with exactly the right balance that the respective plants need.

Yes, I'm biased, I'm a big fan. Just wanted to share some highlights because I think the article doesn't do the amazing work of Jamiah and his team justice. I hope we get to see many more such micro farms all across Los Angeles and Southern California.

My kids are into superheros. We explained how vaccines are basically super powers! Now they are sad when they go to the doctor and don’t get one they also get all their friends and class mates pumped about vaccines which I take as a win

Our goal is to lower the barrier of entry to build fully capable applications. While using the simple email plugin is not a good idea in a production app, there is no problem to use it with an app that runs on your computer only, or in your companie's intranet.

I know this is nightmare to system architects / backend developers at first sight, but trust us, we know exactly what we are doing. We have excellent architects on our team, you just might not be our primary target group here.

But thanks for your feedback, much appreciated!

Hoodie doesn't provide any email privileges in it's core. There is an email plugin that does that, but it's just a showcase and we would not recommend to use that in a production app. The plugin is maybe 10 lines of code, you can easily use that as base and put all the security in it that you would do in a REST API as well.

I'd be also very interested in your basic use cases that you think Hoodie couldn't handle. It would certainly be great input for the project.

Besides the points already mentioned, Meteor is VC backed. Hoodie is an open source project first, that we founded & bootstrapped a company for to sustain its future, and that we will eventually turn into a non-profit. We are and will be not accountable to any investor with questionable interests in an open source project.

I'm more the frontend guy at Hoodie, but what you'll be able to do is to allocate roles to users and based on the roles you can give read/write access down to document level.

If you have a specific scenario in mind, I'm happy to elaborate.

we don't deliver all our business logic as JavaScript to the client, we just provide a nicer API. All security / scaling / business logic still lives server side.

Take hoodie.email.send(properties) as an example. It just the same as `POST /email` with email properties JSON, with the only difference that it's simpler to understand and to handle for frontend people, and it works offline (syncs when connection is back).

or you go away of AJAX calls entirely, by storing all data offline and having a separate process that synchronizes all changes, like remotestorage.io does it, or hood.ie

Let's say today 1 of 1000 people is able to create an app to solve a problem, let's say time time tracking. Now imagine we change that drastically, to 100 of 1000 or even more. People will start to build their own little apps to solve their own little problems. And if these break, nobody cares, but them.

For example, friends of mine like to go climbing. They've build an app in an afternoon, just for their group, to keep track of what tracks they finished and how they liked it. I think this is fascinating. I wonder what would happen if students would learn to build simple apps like that in school, instead of Excel?

In the current implementation, CouchDB takes care of it. In case of a conflict, both versions are kept, with one winner. The other version can be recovered and the conflict resolved, both automatically with a worker process or by the user.

> but what about non-js users or, maybe more importantly, SEO or crawlers

Hoodie is more of a tool for applications, with user authentication etc, so SEO is not relevant here. I wouldn't build a public website with Hoodie.

> Also, something else that really trouble me with javascript client-side is that, often, when something bugs, everything just stop working

Yes. That's something we have to handle if we want dynamic web apps build on web technologies. But there are great tools today that help you 1. prevent JavaScript by automated testing in all the browsers / OS 2. track JavaScript errors, e.g. with errorception. And 3. todays browsers are more relaxed about errors, they try to continue running the app, even if one function errored out.

> Is there a better solution than a hard-refresh? Would a first-level try/catch solve this problem

If you can keep the state of an app and store user's data immediately, there is no big problem to reload the page, I do that in several occasions at minutes.io, the user usually doesn't realize, it's very fast.

we definitely won't send any credit card information to a hoodie server. Instead we use a service like stripe, but then receive the payment notifications or errors, which lets us notify the user if payment worked or not.

Key difference: kan.so is Couch specific. Hoodie is not. We do not try to make another nice library to wrap CouchDB. We try to make a nice JavaScript API for the most common backend tasks.

We start with a dream API, and build from there.