For sure. Unrelated to GraphQL in this case. Very manual (in a good way!). Sometimes it's achieved manually via the UI. Sometimes manually via scripts, etc. Imagine you're creating a new field for Business Travel, and you've added some new fields via the API. One way or another you're grabbing 1-2 listings in development, modifying those listings to reflect the desired change, and then in the dev setup, you're saying "grab listings x and y and update their data for use in Storybook and unit tests."
In my experience, if the system is working properly, there's not a lot of room for type-driven inference. We often get a design with very explicit data present, and we want to bring that data in rather than calling on Casual or
We have a shared development environment with a persistent (and thus deterministic) dataset. So when one developer runs a query against that dataset, another developer could run the same query and get the same result.
The best thing about this, of course, is that if your Storybook data looks at listing 112358, you can also open that same listing in development and see the same result in the product. Very powerful.
Hey folks — this post got a great reception on the reactjs subreddit yesterday. Someone suggested I post this as a Show HN, and I think it's a great idea. I'd be happy to answer any questions or talk through our approach if folks are interested.
This is useful, but I am not sure at scale (i.e. a constellation of micro-services working together) I would want some of this functionality abstracted behind a library. I prefer gulp and wrote a couple articles talking through a simple process for local development, testing, and deployment if anyone finds it useful:
The absence of a clear response indicates to me that the brass is currently weighing the pros and cons of admitting there was a problem. This is the sort of thing where those who really weren't affected get way out ahead of this sort of thing with vivid detail. I deleted my account.
Cause and effect: A statistically insignificant number of fires in Teslas caused a disproportionate amount of news coverage (there was much less news coverage about Tesla's best-ever safety rating). This perception needs to be overcome, even if it means informed consumers having to pay for titanium underneath otherwise safe cars. Tesla is doing their part, but it's a shame to see so many outside factors driving up the cost.
The shame of all of this noise is that resources going into medical research today ends up getting spent on data security and building expensive, custom solutions that avoid using servers of a certain type or location in the name of privacy.
Sure, it would be more secure to conduct medical research without using computers at all, but what about all those people dying of nasty diseases? If I had 6 months to live, I probably wouldn't mind these "criminals" trying to find me a cure.
Instead, we have a deafening din of screaming about data privacy and little or no mention of the benefits of the medical research itself. If people could calm down a little bit about Big Brother, these guys could spend more time doing their jobs, helping sick people.
It's not reasonable to say that the Model S has a 25x increased change of catching fire. The sample size is orders of magnitude too small (there were 3 instances so far?).
Put simply, there is no statistically significant difference whatsoever between the Model S and the broader population in terms of fires post-collision, and Musk is understandably frustrated about the bogus press claiming there is.
Right on. In our particular case, we have an API that's fairly well built-out, so I would probably toy around with this on the next side project.
Rather than having a 100% there solution that's opaque, I think the cool thing would be to have an open source project that handles the boilerplate.
Then, you could fork, point to your blueprint, and deploy in minutes and then do whatever tweaking is required to cover the remaining 10% (there's always something).
Keep up the great work--I am definitely interested (and will check out swagger, as well!).
It's an interesting product as a tool for documentation, but where it gets really useful is that next step (presumably to come) where the structured content is not only used to mock a server, but to actually implement the server.
I would love to do a one-click deploy to express/everyauth (for node) or app simple sinatra/warden app for the ruby folks.
Once you define the auth requirements and the API itself, there's little left beyond the boilerplate.
I imagine a simple, closed-loop solution with semantic versioning that consumes the blueprint like a config file. As we update the blueprint and bump versions, the appropriate changes would be reflected on the server. Your live environment would be naturally in sync with documentation, and it would be versioned and tested.
Such a solution entirely frees us up to focus on the app itself, which would be very cool.
Agreed. JavaScript is the top language on github by a margin (https://github.com/languages), and some of the other languages you listed aren't really intended for web apps naturally. I would add JavaScript post haste and probably kill off Dart and VB.
+1. Communication and professionalism are your best bet, here. It's amazing how often engineers think the managers know all these things, as if they've mentioned it a million times, but no one is listening.
Sometimes the problem is that the issues are communicated, but not the severity. So, you might raise that the database is too complex with 100+ tables, but if the manager does not have an intuitive sense for the consequences of that problem, it might not register as a project-destroying issue. That becomes the disconnect later, and when things go pear-shaped, these disconnects become issues of contention.
The worst thing you can do is to raise these issues quietly and just keep trucking, as if you've done your job, and that's that. [wiping hands gesture] If management doesn't realize that the project is headed for disaster, that's on you (and the others on the team).
But, if you're able to convey the severity of these issues clearly and professionally, the conversation might turn to what can get done in the near term that would be valuable. Or, to the point of other commenters, there might be other factors at play, and the manager might want you to keep trucking anyway. In this case, provided you have been clear about the risks and threats, you really have done your job.
As a parting thought, you could also raise an issue around "what type of company" you want to work for. Perhaps if they need to rock out a rough proof of concept with no automated testing (or any testing!), that's one thing, but I wouldn't want to work at a company that doesn't take testing seriously. So perhaps if this is a manic sprint to prove something, we can all get on board with cowboy coding, but once the dust settles, it will take x amount of time to shore up the work with xyz types of tests. If they aren't on board with taking their medicine and putting the right tests in place, then that might be reason to depart even if the proof of concept succeeds.
To me, the disappointing thing about this spoof is that it treats the engineers on this platform like "code monkies."
One of the biggest gripes from top tier engineers is that they hate being treated like animals by jerky business guys, and here we have a group of people mocking these engineers and the platform. It all seems disrespectful to me.
I would learn from them. I am sure they are going to make as many mistakes as they make great decisions. Having someone out there with funding figuring out the space can be a real advantage if you can learn from what they do and bring your own sense of the marketplace to bear. Look at Wesabe, who launched with funding a year before mint...
Definitely NOT an MBA thing. :-) This is for startups and small businesses alike. Most people are modeling their businesses with an Excel file, and they are making the wild guesses in there. The problem is that it's tough to see the impact of changing any of these wild guesses in Excel, and it's a static document that can't link to actuals for comparison.
We want to help people plan/model their business, measure how they're doing, and then execute. (And the site could use a lot more of that verbiage within the app!)
I'm surprised that so many of the comments/replies to this post accept the premise that programmers are underpaid and don't get respect.
Everyone I know who writes code is making a hell of a lot more than people who aren't. The people I know at Google aren't making $150k. They are making a lot more and would be making a lot less as a management consultant or a politician or whatever else.
In fact, to say that top management consultants clear $500k is true, but top engineers clear a lot more, both of those industries strike me as massively paid industries.
Then there's banking. Engineers at banks make ridiculous amounts of money just like non-engineers working at investment banks.
Sure, there are engineers working for $60k just like there are management consultants working for $60k.
But I know a lot of unemployed management consultants, and I don't know a single unemployed engineer.
So I think people have raised very interesting thoughts about why doctors make more or less, but I couldn't get past the premise of the article. I think engineers are making a ton of money, and they deserve a ton of money. I think they get a ton of respect, and they deserve it.
Maybe that's just what I'm seeing. But particularly when you then say that teachers are paid more than the average American, I start to wonder who this mythical "average American" is, particularly knowing that my sister is a high school teacher and has to buy her own chalk. She would probably disagree with the article based on all the corvettes and teslas sitting in the Google parking lot.
In my experience, if the system is working properly, there's not a lot of room for type-driven inference. We often get a design with very explicit data present, and we want to bring that data in rather than calling on Casual or