All I'm getting is a message: "Oops! Unauthorized F4map API usage. If you are this website administrator, please contact the support at support@f4map.com."
After I was corrected, I looked up the origin of the word. It first appeared as the name of a character in a comic strip, "Caspar Milqutoast" who the author described as "speaks quietly and gets hit with a big stick." He named it after the food which is the most meek of meals.
The Wikipedia says this: "The character's name is derived from a bland and fairly inoffensive food, milk toast, which, light and easy to digest, is an appropriate food for someone with a weak or "nervous" stomach"
I never knew that this comic was a thing, but now I want to read it
While I can understand not wanting to create a Google account (even just to use as a login), my understanding is that if you use Tiller via Excel, Google will not have access to any of your financial data.
Is this really what companies worry about? An insurance (edit: ha, I thought it was a beverage company until I read another comment) company is using a similar colour as our telecommunications company so let's get lawyers involved?
Well, based on a 2017 version of their site in archive.org, their 'pink' is rgb(214, 0, 109) while T-Mobile's current pink is rgb(226, 0, 116). Not the same, but as a graphic designer, I think they'd be visually indistinguishable for most people unless comparing bordering swatches.
But fuck T-Mobile though. Magenta is a primary color in most types of print. That they can somehow stop other people from using it is bullshit.
Apple got away with stealing the name OS9 from Microware so they were not really a position to sue others over similar names without getting their own court testimony from the earlier trial thrown back at them.
The laws are made by the lawmakers (congress, parliaments, etc.)
Justice is there as the supreme/ultimate power to resolve issues between parties. We can't go around smashing heads because "my colour/your colour". When two parties have an issue that cannot be resolved amicably (I don't mean crimes), then Justice gets to say the final word. We live in a civilized world.
Not sure where the line is, but this is a case that's far too close IMO because the shades here change depending on screen type more than they are different from one another.
Amusingly I have 2 LCD monitors here, an acer and a samsung, and when I put Tmobile on the Samsung and Lemonade on the Acer, the colors look functionally identical to the naked eye.
This reminds me of Yid++[0], a tongue-in-cheek C++ compiler with a bunch of keywords translated into Yeshivish[1]. (I apologize in advance if the humor is wasted on those unfamiliar with the Yeshivish / Talmudic world.) It's still in ASCII though :)
If nothing else, these things remind me how lucky I was to not have had to learn English while I simultaneously learned to program.
This is precisely the purpose of the OpenAPI Specification[0], an extended subset of the JSON Schema specification. Plus there a whole family of supporting tools, such as Swagger UI[1], and lots more[2].
Some searching turns up some articles on incompatibilities between OpenAPI and JSON Schema [0] [1], and it's not immediately clear if they fit together well at this point.
We've got some JSON Schema APIs in our services already and are using libs like the Python `json-schema` package to do validation with those. I also briefly experimented with Quicktype [2] to generate some TS types as a proof-of-concept.
We're getting ready to do a pretty big rework of a lot of our services, and I'm interested in any info folks can provide on pros and cons of using OpenAPI vs JSON Schema for API definitions, and tooling around request validation and TS interface / client generation.
The choice to fork[1] the schema standard instead of simply using it as is or with purely additive extensions) is so incredibly damaging. Yes, I get that it makes it a lot simpler to generate code for languages that have bad and static type systems. Meanwhile, the standard is still not powerful enough to describe everything JSON:API thinks is best practice due to not having any way to describe nested properties in queries.
[1] They don't want to call it a fork, but when they invent totally new extensions to support things that already is solved by parts of the standard that they don't want to support, then it is a fork.
Hi- I'm one of the main editors of the JSON Schema specification, and we and the OpenAPI Technical Steering Committee are actively working together to re-converge the specifications.
OpenAPI 3 was developed while JSON Schema progress was stalled due to the prior editors leaving and a new group of us (eventually) picking it up.
OpenAPI 3.1 will most likely include a keyword to allow using standard JSON Schema as an alternative to their customized syntax, and hopefully we can achieve full integration on OpenAPI 4. There are also some other ideas being explored for improved compatibility in 3.x.
Standards work is hard, but the relationship between the OpenAPI TSC and the JSON Schema editors is quite healthy and we are making good progress.
One challenge around OpenAPI right now is that most of it is still stuck in version v2, with relatively immature support for v3. And v3 is quite different.
Not too long ago, I tried to build a project around OpenAPI, trying to generate model structs in Go from OpenAPI definitions. The support just wasn't there. There were code generation tools for v2 and emerging library support for v3, but nothing that covered both.
I went back and used plain JSON Schema for my models, and used GraphQL instead of OpenAPI for the API, and that turned out great.
V3 support is good these days for most languages. It's a delight to generate TypeScript types and then have the compiler tell you all the places you need to change code because your schema changed.
We went with this exact approach in my previous job, using OpenAPI to do everything the blog post mentions, including code generation, diffs for API consumers (published to Slack, for instance), and more. I believe this has a very good shot at success, but it's not complete yet. For instance we had to do a lot of in house work to make code generation work.
Hi- I'm one of the main editors of the JSON Schema specification, and one thing we are doing with the next draft is making it easier to build extensions for things like code generation. We expect to work with the OpenAPI folks on this as it is very relevant to their interests :-)
Also, we and the OpenAPI Technical Steering Committee are actively working together to re-converge the specifications.
OpenAPI 3 was developed while JSON Schema progress was stalled due to the prior editors leaving and a new group of us (eventually) picking it up.
OpenAPI 3.1 will most likely include a keyword to allow using standard JSON Schema as an alternative to their customized syntax, and hopefully we can achieve full integration on OpenAPI 4. There are also some other ideas being explored for improved compatibility in 3.x.
Standards work is hard, but the relationship between the OpenAPI TSC and the JSON Schema editors is quite healthy and we are making good progress.
I agree, I've also invested a huge amount of time and effort into my openapi-generator setup [1], and there's tons of room for improvement. We've probably even done some of the same work for code generation (custom Java subclasses, etc.)
Not sure which code generation tool you used but if you've time, please try OpenAPI Generator (https://openapi-generator.tech) and let us know if you've any feedback.
As someone who works with this tooling nearly daily I can tell you that OpenAPI is unfortunately quite messy.
It seems like Swagger v2 was reasonably well-liked so the idea was to make OpenAPI the best possible way to describe any kind of REST API in existence. Since the spec got more or less merged with JSON Schema it has become extremely unwieldy and full of edge cases.
At my company we're trying to develop tooling around OpenAPI but a lot of things (especially related to the 'oneOf'/'anyOf'/'allOf' features) are extremely ambiguous.
Not to mention that at least the Java versions of the parsing libraries are full of inconsistencies as well. For instance, there's a OpenAPI parser which also has a 'compatibility' mode so it can read Swagger V2 specs as well. Unfortunately the data you get from reading a Swagger V2 spec via that compatibility layer is different from when you'd first convert the V2 spec to OpenAPI v3 through an external tool.
The project is certainly ambitious and I completely agree that this is a hard problem to solve, but honestly I would say that if you want universal adoption of a toolkit for writing API's then the API specification language itself should not be so difficult or ambiguous in its implementation.
I've really enjoyed working with OpenAPI / Swagger while building FormAPI [1]. I use rswag [2] to define and run a set of integration tests that test everything about the API, and then all the requests/responses/schemas are saved into a OpenAPI specification. I can then use that to generate API clients for any language [3]. Then I have test suites for each API client, which spins up the dev server and ensures that all the API calls have the correct behavior (to catch any bugs in openapi-generator, or my custom code that wraps some of the generated functions.)
It took a lot of work to get there, and there's still lots of room for improvement. My ultimate goal is to automatically generate the API client test suite based on the requests/responses. I also want to add some custom logic and workflow rules to the OpenAPI specification, instead of needing to write custom wrapper code in 10+ languages.
I've had to write the same basic code so many times: Make a POST request, then make a GET request once per second until the "status" changes from "pending" to "done", and then finally return the completed result. (I know it would probably be better to set up a websocket connection, but this works fine and it was easier to implement.) It would be so awesome if I could define this workflow inside my API specification, and then the auto-generated client code could include this polling logic without any effort on my part. (Apart from needing to write and support the higher-level generator code for each language, which would actually be a lot more work.)
The other really annoying thing is needing to figure out package managers and release steps for every single programming language. I've only figured this out for 6 languages so far (C#, Java, JS, PHP, Python, Ruby), but I want to support far more languages, and it's just exhausting to go through this process each time. It would be so nice if there was an open source project that wrapped all of the different package managers and provided a framework on top of openapi-generator. And if there was a CLI tool (or web UI) that walked you through the process of signing up for accounts and setting up API keys, and then keeping it all in one place. I would honestly be tempted to rewrite openapi-generator from scratch in a better language / template engine, because the Java code is so hard to read and extend. I'm mainly a Ruby developer, but I don't think Ruby would be a great choice for CLI / generator tools, because it gets pretty slow. So maybe Python or Go.
I feel like this would a really interesting project to work on, and potentially a startup idea. Would anyone be interested in using it? I should probably try to validate this idea. I've set up a Google Form where you can just click a checkbox to register your interest anonymously, or you can also submit your email if you want to get updates and try a beta version: https://forms.gle/7qWzWpC9QrTjUgnU7
Welp, now that my Imposter Syndrome has returned in full force, any concrete advice on leveling up in engineering skill (other than getting hired at Google circa 1999)?
Edit: I now see that Paul coined the "Don't be Evil" slogan[0]. I'm curious what his thoughts on its removal and what that portends for Google today. u/paul?
Get hired at any place where good engineering is done, or at a startup where no engineering is really done and you get to make the calls about how engineering is done. Work for 10+ hours a day, and on your free time read about engineering from blogs or books, see conference videos, and go to conferences.
After 4 or 5 years of doing this you'll maybe know enough about how "everthing works" and what books says how to do what, or what company did what in what way, or the "state of the art", at that time you can start doing original contributions in order to not fall back.
Oh and also the Imposter Syndrome sometimes never really goes away :(
This seems like generally good advice, except for having to spend every waking moment using your brain for work. Balance is important. Spending some of that free time on learning engineering is good advice, just not all of it. Make sure you spend some free time with friends/family, physical activities, and relaxation.
Balance is sometimes overrated because most of the expectation about how to be a great professional comes from overzealous 9 to 5 mediocre professionals. That doesn't mean life is about burning out and crashing against a wall of mind wrecks every few years of course, but for many people it's possible to keep let's say a 85% work 15% hobbies, relaxation and workout and society needs those guys at their maximum capacities.
> After 4 or 5 years of doing this you'll maybe know enough about how "everthing works" and what books says how to do what, or what company did what in what way, or the "state of the art", at that time you can start doing original contributions in order to not fall back.
For me personally, 5 years was the point at which you start to gain confidence, but still don't realize how much you really don't know. I see that in a lot of people too. Getting my CS degree, I was told I knew a lot more than my peers (and apparently more than some of the grad students...), and did better than most, but it wasn't really until a decade into my career that I would say I really started to "get it." That is after reading dozens and dozens of books, many hundreds of research papers, meetups, conferences (and later watching/listening through whole playlists of conference talks). You are always going to be an impostor somewhere, because there are always things you don't know. The best thing you can do is stop pretending that you know more than you do.
It really depends on the person. Also working on the exact same field and industry for 5 years is way different to getting a degree. Also note I said you could start making original contributions, not that they'll be meaningful or groundbreaking...
This is hard, but fair advice for anyone who wants to get "really good". Perhaps there are those who are born gifted with the critical thinking and analytic skills which makes this unnecessary. I am not one of them, and the past year has been intense but a great learning experience. And Paul says as much: you don't start of being good, but you work intensively on your skills over a period of time and get really good.
Impostor Syndrome is part and parcel of working with amazing people. Sometimes you'll feel like a goofball not because of anything you did, but because you're interacting with someone who is operating on a totally different level. But pushing through that emotion and learning from the experience is how you level up.
Strive to find people which are way better than you and learn from them.
Get a mentor, and any other opportunity of receiving feedback on your stuff.
(All of these things will automatically happen at a faang company)
Who are you hacking for or talking about what you read with? It's easy to believe you are getting better when no one is around to give a reality check.
Don't forget that "survivorship bias" is a very real thing. Don't let the rare success of engineers like Paul Buchheit make you think you're not as smart as you really are.
And that's how you start to beat Imposter Syndrome.
