metral

Uber engineers gave a great talk on distributed deep learning at the Mesosphere conference back in Oct 2017 where they discuss the problem space and Horovod in detail. Highly recommend it: https://www.youtube.com/watch?v=Ktc3GjshHcc

Adding integration of Vault into Secrets is an active discussion in sig-auth: https://github.com/kubernetes/kubernetes/issues/10439#issuec...

If you'd like to participate in these discussions, here are the details for the sig-auth's meetings & agenda items: https://github.com/kubernetes/community/tree/master/sig-auth

Great stuff! I actually just finished a long session of reading through many of the docs & source for Ingress Controllers and kube-lego.

One piece I still don't quite get is why the Ingress Controller requires a default backend/404-server at all.

Could you please elaborate on why default backends are needed in general for nginx Ingress Controllers? It almost seems a bit extraneous to have another webserver just serving a 404 at / and a 200 at /healthz, especially if I'm defining specific Ingresses and their associated Services which could handle their own versions of those paths.

I find it very interesting how they're naming each major functionality with an associated word of it in either the domain name or in its extension

i.e.

* Mobile landing page: http://peach.cool

* Webapp: https://peachwww.com

* API: https://v1.peachapi.com/

I thought I recognized the packaging. Turns out this was 'DoorBot' from Shark Tank that got renamed to 'Ring.'

They ended up getting a $28MM investment from Richard Branson for a $60MM valuation after getting a shoddy deal on the tank: http://www.businessinsider.com/ring-from-shark-tank-to-richa...

Good on them.

In https://git-scm.com/blog, scroll down to "The Role of Reset" - it's always helped me remember how reset moves up the various tree roles.

I will say, I personally rarely use --soft, it's either the default --mixed, or --hard in a more 'severe' case, so it's a bit easier for me to remember the roles and the relation to the flags.

Amazing news to see this! I made a Homemade Sports Ticker using a Model B almost 1.5 years ago and its still going strong.

Here's a couple of links:

* Blog post: https://medium.com/@mikemetral/a-homemade-sports-ticker-875c...

* Code to write to LED Sign: https://github.com/metral/led_sign

* Code to pull the scores: https://github.com/metral/scores

* The LED sign itself: http://brightledsigns.com/programmable/indoor/bs-4x16-mini

Fair Warning: I haven't touched the code in over a year so it's not maintained. If I were to do things today, I'd probably switch to Go to make the score requests a bit more streamlined than the single synchronous process I have now, and I would throw it into a container as the #1 request I get is people struggling to install both the code base and the dependencies.

Happy Hacking!

This is a talk I gave at OpenStack Tokyo yesterday around market analysis and R&D work I've done in the container ecosystem and specifically how the various projects compare to one another including: Docker, Swarm, Kubernetes, CoreOS, Flocker, Mesos, DCOS, Marathon plus more, as well as how it can relate to OpenStack.

If you're interested in the slides themselves, you can find them here: https://www.scribd.com/doc/287401286/What-Should-I-Know-Abou...

As a 2nd generation Colombian myself (parents were born in raised in Barranquilla but I grew up in the states) I applaud you and your team for this effort. Colombia tech has always been a bit "behind" the times from my POV and unless efforts like this continue to grow & thrive then we can't elevate the overall education for the status quo, so thank you. I will be purchasing the sticker & t-shirt

I'll start off by stating that I am not a frontend dev, but I've been trying to learn React to connect it to a backend API and I too find it difficult for the same reasons you stated plus some others:

- The FB React docs are a bit scattered in terms of content and not as intuitive / helpful for a beginner as I'd hope they be

- I often resort to referencing other people's code from Github, StackOverflow & Google and the mix of ES5,6 & 7 styling used is hard to wrap my head around, especially when I try to find a source of "truth" on how to adopt the more idiomatic way of doing things seeing how everyone is using a different version from docs to examples

- React-Router's docs & code samples vary widely from what they state in the repo vs what people are actually using, and the whole pre 1.0 / post 1.0 way of using it has bitten me more times than I care to count - this is most likely me jumping in at a transformative time in the project

- Learning tools like webpack, browserify, babel, gulp etc. have been nothing short of a learning curve and these tools are basically required to be useful in React without repeating yourself from running commands over & over again when developing

- I've learned Flux's architecture, understand the concept, have integrated its structure into my code and know that this is the proper decoupling required, but its definitely not been an easy process for me to have to think about how I need to modify the flux pipeline for new functionality and how I can cut down on repetitive code.

- I don't understand how to manage state properly when I navigate to another page - this creates issues for me around the combination of flux + react-router as my lack of experience with them as well as lack of proper examples to utilize make the two difficult to address some of the state management issues I encounter. i.e. If a user logs in & they have a token, do I make use of local storage, do I not, how do I navigate to another page seamlessly with information I want to pre-specify such as the fact that a user is logged in and some of their basic info so I dont have to hit an API etc.

- Lastly, I fear committing to an all-in javascript-dependent solution for a frontend will segment users in terms of it working or not - see http://maketea.co.uk/2014/03/05/building-robust-web-apps-wit... for the tidbit about how SquareSpace's page is completely blank if javascript is disabled - this worries me that I may have a user that can't even interact with my page either because they disabled javascript, or because their browser is outdated/lacks expected functionality.

I know most of these issues stem from my lack of exposure and knowledge in this frontend endeavour. Nevertheless, I have to assume others are getting bit by many of the same issues as well and I constantly question if I'm biting off more than I can chew with React, as well as if I should just go back to the more traditional way of doing things on the server-side which I happen to know & understand already.

/rant

I consider myself to be a generalist and pretty personable, the latter of which I don't think many folks remember to demonstrate during interviews, so I wholeheartedly agree with the points about chitchatting & showcasing your collaboration abilities. However, on the topic of working through a coding problem, I find myself struggling not so much with the asks per se, but rather, I focus too much on the fact that I'm thrown out of my usual dev/coding environments and working through a problem in a Word doc or some other non-text editor platform and it becomes a bit of a mental block. Compound that with the fact that my style of coding includes referring to existing code of my own or looking things up in mediums such as Google and StackOverflow to jump start me, and it becomes more of a crutch that does not aid me in these sorts of situations.

In Ashlee Vance's "Elon Musk" book, Elon discusses this very issue with Square drawing on his own experiences with PayPal. Elon states that the notion of controlling both sides of the transaction, or better put, how to avoid the end user from withdrawing from their digital bank account is what he criticizes most about Square. He believes that, like PayPal, they have to create new ways for users to be able to utilize the money Square is holding onto for them by either creating businesses around say a Square-owned debit cards (ala PayPal debit card), extending the payment capabilities to partners, and essentially, just finding ways to keep the transactions within their network is what is going to practically eliminate most of their costs.