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
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.
Ring pulls it off better, in my opinion. Installation is dead simple, the app works fairly well, and the product is well-designed, all the way down to the packaging/install kit.
I've tried a few other similar products and just haven't been nearly as satisfied with the experiences (mostly due to software quirks).
Ring, like Nest, was simple enough that my technically inept parents managed to deploy and use it without my intervention. That says a lot.
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.
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.
That's cool man, I'm sure you're friend was stoked. Props on the write up. I've got an old monitor I want to connect to the Pi, just not sure what info is worth displaying yet.
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.
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.
To your last fear... we're using a noscript > meta element combination to refresh/replace to a noscript.html page for users without JS... same for old Ie (conditional comment) for that matter.
Higher in the thread there's a reference to a Full Stack Redux Totorial that looks really good so far, only skimmed it... as a starter point.
Your state is best as one big state tree passed through components as props... your events/dispatchers can then trigger requests to load from stores... these stores then signal when data is loaded, which can trigger an update to state, which causes an update/render to your ui. The Redux workflow is a distillation of the flux framework overall, and might be an easier place to start, and stay with.
As for local storage, your stores can use local/session storage to save information locally for requests... for that matter, you could save your current state to session storage in case of a reload/refresh, etc.
As for router... not all SPAs need to change routing... It makes it a bit more complicated, and your stores can/should be your interaction with data that may be available locally or via server.
