The comments here seem very negative compared to e.g. the Google employee protests over Project Dragonfly. [1]
There are two questions here: whether GitHub should allow ICE to buy its software, and whether employees should influence the direction of their company via protests, petitions, and threats to quit.
GitHub specifics aside, I think employees absolutely should organize and quit over issues they feel strongly about (at least when they have the flexibility to find other jobs). Company policy should be guided by the people who work there, and the a company's leadership structure is set up well to resolve the conflict.
The important distinction is that Project Dragonfly was being built to serve a single customer and purpose, both of which employees were not comfortable with. GitHub is built to serve any customer and has a defined purpose that is generally useful. Employees are now uncomfortable with their generally useful tool being used as intended by a customer they do not approve of.
Thats because HN is a US-based website, and that automatically entails "US = good, China = bad" comments. (Even though in this case both US and China = bad)
I made this for a really minimal version of daily time tracking. The touch bar turned out to be a great place for a stopwatch: tapping is easy, and you can easily check if it's running or not - even in fullscreen mode.
In light of the upcoming GDPR laws in Europe and the right to be forgotten, that’s quite short sighted and could stop a number of developers using your system- I know I certainly couldn’t use it without this available via API or console
If you made a charting app that used an anchor tag to load data like you described, and made the resulting chart embeddable, I'd actually be interested in using it to power charts in blog posts. Cool idea.
Easy - I'll just inject text-based ads into the saved data!
(Kidding, of course...)
I think it's unlikely that this site can be monetized, so I don't have my hopes up. The clearest direction would be to move up the "backend-as-a-service" spectrum into Headless CMS land (which I have a diagram for here: http://alexzirbel.com/npoint). But I think it would be hard to balance that with the quick setup / unstructured data nature of the project.
One feature (maybe a premium feature) I'd love to add is form-based data editing. Theoretically you could generate the right kind of input fields (text, date, number) from the JSON schema and expose that as alternative editing interface. That would make the tool more like a CMS.
For my side project, I've been coming at essentially the same problem from the CMS angle. n:point is very neat by the way - great job!
I'm building a service that makes it possible to quickly create reusable content objects using Trello. The flow is: you write your content objects as cards in Trello, then you hit my service to get an array of self-contained JSON objects.
In terms of monetization, I'm building the service on stdlib.com. This means that I can charge a very small fee for each API request. (My service is not intended to be called from front end code.) Each user will also have an allowance of free calls. And I've already open-sourced the core functionality [1]. Definitely open to suggestions on this approach, though.
I keep thinking about adding support for schema validation. Your project has given me more to think about on that front! However, my immediate goal is to get the MVP ready to share.
Right now the MVP is live, but the landing page is not done yet. Feel free to get in touch if you're interested in more details - my email is in my profile.
It's quite cool actually (depending on how much you love/hate Angular though).
Something like that might be good to have as a premium feature, albeit I would think not something you could charge an arm and a leg though... or perhaps you can, if you add something like schema versioning perhaps?
Hi HN! This is a side project I've been working on for a while now.
It's similar to https://jsonbin.io (which was an inspiration!), but focuses on the second step of prototyping with data - once you're editing JSON online, how do you make sure you don't break your app? npoint.io lets you enforce a structure using JSON schema (http://json-schema.org).
Could you add that to your FAQ? I was like, what the heck is a json bin, what is actually validating this schema, is this something I run on my machine or in the cloud, is this self-hostable, how am I supposed to actually use any of this, what am I suposed to use it for, etc. Cloning jsonbin's about page would be great.
Sounds like the homepage copy could use some work. Thanks for the list of questions you had, that's very useful. jsonbin definitely does a good job of explaining it.
Ah, they're just tools that can be learned. I had to run around the company quite a bit to make sure I got all the information right.
We don't require experience in any of these tools to get a job at Opendoor. Most programming experience can be transferred between different technologies. We do a lot of pair programming to bring people on board, plus feedback in code reviews.
Just to add to what Alex said. We also wouldn't expect you to be knowledgable on _all_ the tools we use. We have a very open team that's happy to help and mentor.
Thanks for the answer! If there is any resource that you remember had an important impact in your learning path as a scalable application programmer I'd very much appreciate to hear about it. Cheers.
I think reading about (and looking at the code) for things you use and trying to understand how they work under the hood has been super useful: http://aosabook.org/en/index.html
Having smart people around to learn from is extremely helpful too.
Happy to chat more if you'd like. Just drop me a line: connor[at]opendoor[dot]com
Thanks for the comment -- and it's very accurate in terms of where we'd like to go.
On a tangential note: empowering untrained individuals is important, but we often do the opposite too. Many of our internal tools are designed to make trained professionals/experts as efficient as possible.
yup, i also wrote a deeper analysis after someone posted about opendoor in december.
what will be super interesting to watch is how the market size (i.e., annual real estate transactions) changes in response to reduced friction. historically, disruptive technology like uber widens the market substantially because it unlocks all this demand artificially suppressed by friction. because of opendoor and similar startups, will transaction volume increase by 10%? 50%? 200%?
opendoor is the classic VC investment: huge upside with controllable, sane risks.
It would be great to move as a home owner and be able to avoid the 5-6% realtor cost on both ends (10-12% total). This could enable millions of people choose better living arrangements. Unfortunately for people in California, Prop 13 will still create huge costs to moving.
There are two questions here: whether GitHub should allow ICE to buy its software, and whether employees should influence the direction of their company via protests, petitions, and threats to quit.
GitHub specifics aside, I think employees absolutely should organize and quit over issues they feel strongly about (at least when they have the flexibility to find other jobs). Company policy should be guided by the people who work there, and the a company's leadership structure is set up well to resolve the conflict.
[1]: https://news.ycombinator.com/item?id=18542830