That helps a ton! Thankyou pal. Explained well

The storyboard feature of xcode is pretty cool. I've been learning some objective c and playing around with some simple apps using xcode. I think once I get the hang of it I'm going to move back to rubymotion.

I found it kind of awkward but I never got a really good sense of how to use it for non-trivial things.

Seriously awesome discovery. There's apparently a million ways to create comment systems, but the closure table is simply incredible, powerful, and elagant:

Copy / pasted (somewhat) from PgAdmin. It's interesting to see how much extra code is generated by PostgreSQL:

Holy ****.

What kind of people come up with this stuff? Two little tables creates a complext graphing system that is extensible, infinite, powerful, modifiable and adhears to referential integrity constraints.

why do you need descendents? can't it be inferred from ancestor?

usually with hierarchies whenever someone deviates from a schema that just has a parent ID it's a denormalization for performance reasons.

Yes, but you run into problems when you go N-depth.

The genius of the closure table is that everything is an ancestor, even to itself:



To use the table, you'd have something like this:

Thus query as > n gets all the comments from that part of the tree.

Has anyone messed around with PostGIS? Looks pretty cool so far, but I haven't done much with it yet.

Planning to get much deeper into database stuff. I've been planning to get this open-source marketing program put together. Seems like it'd be a great opportunity to learn a bit of PL/PgSQL.

Has anyone in here used Parse?

I'm sort of confused by Parse and similar services. I've looked at them briefly, but I always end up wondering what you are supposed to do with an app that has any significant business logic on the server side. Where does it go? It seems like it might be good for a simple app where you are just saving users and doing simply queries...

I'll let you know when I get there. They do have something called Cloud Code.
https://parse.com/docs/cloud_code_guide

Right now I am just trying to figure out how to retrieve a bunch of data from javascript on a website without allowing just anybody to change that data.

honestly, at that point why not just write your own API in the framework you're already familiar with and host on heroku. Seems like about the same level of convenience with a lot more control. Maybe I don't get it though....

Wow. That is a metric ton of documentation. I guess I get, but still.

g_m: that is the second time you suggested someone roll their own API for stuff. I'm intrigued.

With Parse's SDK it only takes about 4 lines of code to save the object to the cloud DB. I don't have to do any threading. I don't have to handle cases where the user isn't in cell phone range, etc. I just type
That's it. Now I assume it's about as easy on the JS retrieval side from a webpage. Seems easier than creating an API on heroku.

Well with pretty much any modern framework, setting up APIs for basic CRUD stuff is out of the box, and learning it can't be much harder than learning Parse. Heroku would take care of you for server management... so the combo of those two things means I'm not really sure what I get out of Parse. I guess you don't even have to figure out how to add on a db to heroku, and I guess your db stuff scales automatically? But then how are you unit testing your business logic? Just talking out my ass though, I've never used them.

Yeah, but you also suggested that I build an API for site searching instead of working with Elastic Search.

Just wondering where all that comes from.

Seems like the problems are hard either way, just a matter of where the mess is located.

If that's all you're doing, sure. But there's not business logic there.

What if you have a referral system, and upon saving a user you need to check if he email was referred by someone else, and if it was send a thank you email to the referer, and also a welcome email to the new user. and also, if this is the 5th referred person for the referer, then the email sent to him should include a free promo code for X, where X is one of your promotional items that has not already been claimed 10 times, and whose dollar value is at least $5 but not more than $10, etc, etc.

All that **** that I know how to design and architect already in ruby/sinatra or whatever, do I figure out how to do that in the Parse Cloud thingy? Can I program plain unit-testable business objects that I can just plugin there? Or am I tied to their framework at every turn? (that's what i'd expect)

I believe I *asked* why I wouldn't, since I was trying to understand what elastic search provides, and you are or someone gave a good answer. It comes from wanting to know what advantage one thing has over another.

In most cases, when choosing between two messes, one mess is much worse than the other ime.

All I need right now is the data storage. Whatever makes your life easier, you should use. I am still learning about this, so it's entirely possible I will have to move to some other solution soon.

and possible i'm just not getting it and they have answers to all my supposed problems.... anyway, i'm sure it saves time for apps doing simple CRUD stuff, so good luck

Just saw this posted on HN, seems relevant to the current discussion:
If You Are Designing Your Own REST backend You're Doing It Wrong

I'm not sure if I'm just groggy still but it doesn't seem like he's saying much. It seemed like one of those blogs designed for hits - I'm going to say something really controversial in the title but then not really back my argument up in my article.

Compare that to something like a Steve Yegge post and it's a tiny fraction of the size. And that's because there doesn't seem to be any of the hard substance behind any of his statements.

i read that too and i confess i didn't really follow what he was saying...
1. i haven't used couchdb
2. at what kind of scale do his comments come into play? it seems like he's talking about pretty massive traffic, like hundreds of thousands of hits per second, but again, i didn't completely follow

I had the same thoughts.

He has a rough point but it mostly strikes me as a CouchDB-fanboy post. I agree it's pretty confusing as well. Wish I hadn't posted it :P