API integration

[ethanresnick]

What's the plan here in terms of pulling the jobs from the API (which would allow bd to add postings from the intranet)?

We already have a Job model, which I'm guessing y'all know about because it looks like the Jekyll .md files are already using it's structure almost exactly. So I'm assuming the jekyll files are just hardcoded now for easy prototyping.

Is there anything on the API side that's needed though for this to work? For example, the current Job model doesn't have location, which the Jekyll files do. I'm thinking we could maybe add Job.location and link that to a Venue, which has an address. Would that be sufficient? Are there any other cases?

[AbhiAgarwal]

The model totally fits I think! I just couldn't do it since I don't really have Node/NPM on my home computer. I'll try do this next week when I come to NYC unless @grungerabbit, @danagilliann, @oa495 can tackle this!

It's very similar to the ones we do for start-week, etc. Would be happy to give you an API key and what-not. Let me know.

edit: yeah location would be great. I don't think address would be useless, but if it's in Queens or San Francisco or Brooklyn, etc.

[ethanresnick]

@AbhiAgarwal awesome. Re location, it seems like we have three main options:

1. We could jutst add a city field on the Job model and ask people to enter that. The risk though is that well probably get inconsistent data/formatting. We'll have some people entering "NYC, others entering "New York", and still others entering "Brooklyn". Now, we might be able to counteract that with good prompt text in the admin ui, but it's still a small risk.
2. We could link a Venue to the Job resource. The Venue will have a full address (which we're already planning to format consistently). Then, we could either show the full address (linked to Google Maps)--which would be easiest, but could also be useful if people are interested in knowing how long their commute would be--or, we could use some script to extract the city from the address in a consistent way. The advantage of this is greater consistency (through mechanical address formatting and/or city extraction). The downside is much more dad entry, in the form of the creation of new venues that are unlikely to be reused--unless we happen to host an event at one of these companies.
3. The compromise option, I think, is to add a Job.address field, which would be validated (and so consistently formatted) just like Venue.address, but wouldn't require the creation and linking of a separate resource. The downside is that our data could get a bit redundant if we do want to reuse that address (e.g. to host an event at that company), but that seems like the smallest problem, so I think this is my preferred option.

Thoughts?