Contracting out an API - comments on the spec, or even a bid?(docs.google.com)
docs.google.com
Contracting out an API - comments on the spec, or even a bid?
https://docs.google.com/document/d/1-OQrDRvoHk-fX0Yc9NJ_Os9y9wbxK_W2-jMXAKbFCRg/edit?hl=en_US
5 comments
So basically only one user can login per UUID? There are no means of unregistering the device? A user can log in on multiple devices but can't logout. Also store the APNS key @ device_register you might wan't to sent pushes in the future. Put password in basic auth and use ssl (at minumum)..
Yes, one user per UDID for now. If you want to unregister a device, you can email me, and if we get multiple requests, we'll code a solution.
Storing APNS sounds like a good idea.
As for security, I am ok that this would be susceptible to a wifi sniffer. We will note that it is insecure for users, but they won't care. If we get a bid that implements security, we'll consider it, but I'd rather have it work than be secure.
Storing APNS sounds like a good idea.
As for security, I am ok that this would be susceptible to a wifi sniffer. We will note that it is insecure for users, but they won't care. If we get a bid that implements security, we'll consider it, but I'd rather have it work than be secure.
> We will note that it is insecure for users, but they won't care. ... I'd rather have it work than be secure.
I would have an easier yet more profitable life if I could manage to adopt that attitude for my projects.
I would have an easier yet more profitable life if I could manage to adopt that attitude for my projects.
You might be better off having 2 people, one to make your web API and 1 to handle the 'backup' portion of it. One is programming and 1 is systems work, and it can be difficult to find 1 person that does both well, and it affordable.
First you have to tell us your budget! You should always have a budget. But also be prepared to stretch that budget
Otherwise, the spec is pretty well written. Some of the finer details will probably come out as the project progresses, but this is a good starting point :)
Otherwise, the spec is pretty well written. Some of the finer details will probably come out as the project progresses, but this is a good starting point :)
I think you should always have a budget, but that it is probably unwise to reveal that budget.
I certainly don't expect to pay a few hundred bucks for this. The spec is clear, and I'll accept a reasonable bid, either for the project or at an hourly rate with an estimate.
I certainly don't expect to pay a few hundred bucks for this. The spec is clear, and I'll accept a reasonable bid, either for the project or at an hourly rate with an estimate.
I can't find the link or remember the name of the service, but a few days ago I saw a website for a company that allows you to easily create a "cloud backend" for your mobile application.
I've tried every search term I can think of but can't find it. Maybe someone else has seen it?
I've tried every search term I can think of but can't find it. Maybe someone else has seen it?
There have been two mentioned on HN recently: zStack and StackMob (the latter is run by a friend and former coworker of mine.)
Ironically, zStack has the OP listed as their only reference customer. Er, guess that's not working out so well?
Ironically, zStack has the OP listed as their only reference customer. Er, guess that's not working out so well?
HA! Yes zStack was it. I only know now because I just received an invite to zStack (now called Parse) - then I returned here to see if I could still tell the OP about it, I guess they already know ;)
* Use KML or other existing standards.
* You get what you pay for.
* You get what you pay for.
The track files will be stored in the flat file format we use within the app. The server won't really do anything with them besides ferry them around.
We do have client code that converts those files to GPX though, because we do data exports.
We do have client code that converts those files to GPX though, because we do data exports.