600 karma · joined November 16, 2014
If you look at their Showcase section[1], you can't tell it's using TailwindCSS for most of them (imo).
[0] https://ethanzuckerman.com/2015/05/28/the-death-of-tidbit-an...
Stripe Sandboxes[1] aim to solve this problem!
(Disclaimer: I work for Stripe but not on this feature)
[1] https://bazel.build/rules/language#differences_with_python
Is the end of semester Leisserchess competition still going? I believe I heard that the year you TA'd it (might have been a year before or after) a group finally compiled an opening playbook and beat everyone in the class
Several groups are. They're offering anywhere between 60 to 80 cents on the dollar for the uninsured amounts. https://www.reuters.com/business/finance/hedge-funds-offerin...
It seems this tool isn't meant mostly for testing how different components behave under different scenarios and/or load. This is probably particularly helpful for custom controllers or operators. What happens to your controller if it's constantly reconciling 100k pods? What about 5k nodes? Something else? If this tool makes creating a "loaded" cluster easy, it's definitely handy. Would have saved me some time doing something similar a few months ago.
Even if you have traditional REST endpoints, you still have to potentially orchestrate their usage client-side.
Job hopping a few times is not a bad thing by itself but the reason why you’re doing so might be. In my case I didn’t want to hire a new manager only to repeat the process again in 6 months (their track record suggested they’d do it again). There’s also a _huge_ difference between having 8 years of experience and 8 first year experiences. As pointed out by GP the hard and complicated things/decisions come after a while in the job and you’ve onboarded and gotten context.
I think either approach is valid as long as you're consistent. You can make a case for either 404 or 403 when you don't have enough permissions. In GitHub's case you can argue that it's a 404 because the resource does indeed not exist through your auth context. In AWS' case you can argue that a 403 makes sense because you don't have permission to know the answer to your query.