ferris.svg - The rust mascot crab (called "ferris") with the face and color of Gopher (the golang mascot)
github.svg - GitHub in a Gitlab styled logo
javascript.svg - JavaScript written in a Java-styled font + the Java logo (Sun/Oracle)
pip.svg - Pip (the python package manager) styled in the npm logo style (node.js package manager)
rails.svg - Ruby on Rails with pretty much the rails logo, but in the color of WordPress. Also the "RubyOn Rails" text theming is in the style of the WordPress logo typography
react.svg - ReactJS in a the Angular logo, including the font style
rust.svg - (this one was truly painful, personally :P) "Rust" (the language) displayed in the node.js logo font styling, including colors
ubuntu.svg - "Ubunutu" styled in the debian (linux distribution) font styling, along with the debian logo. This one specifically, is where the hybrid feels the most accurate since Ubuntu is a debian-based linux distro, but I do believe the communities don't get along very well (or at least that's the running joke)
vscode.svg - VS Code (Visual Studio Code, the IDE/Text Editor) displayed in the "Vim" logo font styling and the logo with the stylized "V"
Thanks: I couldn't figure out the Rust one thought the font was indeed very familiar, or the Ruby on rails thing (looked familiar too).
FWIW, I wouldn't say Ubuntu/Debian communities don't get along well, Ubuntu is officially built on top of Debian (it imports packages from Debian unstable archive verbatim for majority of its archive), and many Ubuntu devs are Debian devs too. There are certainly some Debian devs who have held a grudge for Ubuntu becoming more popular by focusing on better integrating a subset of packages in the Debian archive, but I think we are waaaay past that.
Thank you! Could not figure out Rails, was thinking about Django, Laravel but didn't think of Wordpress. I think (Django) with a PHP-like oval background would have been funnier.
Don't know if it is the HN effect or what, but the article says that the channel has 100 subscribers whereas at the moment of writing this comment, the number is around 12.2K.
Not OP, but I think they are referring to the basic premise of evolution. We still don't have a concrete theory on what causes mutation to occur, only one about which mutations end up surviving and sustaining across generations.
As such the evolution of human intelligence is largely an enormous chain of favorable mutations having been coupled and survived over billions of years. And each mutation that did occur was owing to nothing more than chance.
Since, as you say, we don't have a concrete theory on what causes mutations to occur, how can you then go onto say the reason they occur is nothing more than chance?
I think that is what it is meant to be. Mostly an exchange of opinions and discussions. Stackoverflow happens to be much more formal and precise. So, while a question like "How do I use RxJava primitives with Spring MVC" is better suited for StackOverflow, a question like "Do you believe reactive programming is highly misplaced in most situations" is more quora-ish... or at least that's the way I think of them.
Back at my previous company, which was a travel startup, there was a list of curated vacation packages that were created for every weekend. So, the itineraries team used to spend 5 days designing the packages and getting vendors on board, and then they used to fill up a google sheet with the details in it and the devs used to run a script, which used to populate this rows in the database and make any other updates required and it used to show up on the website. The reasons why this worked so well for us:
1. There were at the most 30-40 rows. Google Spreadsheets works amazing for small table sizes (although not as small as 30-40, I'd assume upto 1500-5000 should be fine as well).
2. All non-dev teams were EXTREMELY comfortable with Google Spreadsheets. For people with non-engineering backgrounds, a spreadsheet is an amazing, low-barrier entry to structured data which I believe is what made this solution amazing.
3. The dev team was completely removed as a dependency, and we had staging environments where they would run it first to ensure it was working properly, so a dev could be engaged only if their spreadsheet run wasn't working as expected or due to some other issue. The previous method was a huge email sent out to the devs, who would handcraft it into a JSON, which would then be passed to a script and then written to the database. This required every run to be effectively final.. there were only so many times one could engage a dev.
4. While we had to engage a dev to execute the script, it actually is very easy to integrate a menu option within the google sheets interface itself (if you are using Google Apps) for your domain, which would say something like 'Deploy to Staging', although we never got around to actually building this.
For startups where product turnaround time is required to be short, this works as an amazing solution as it makes so easy for non-tech guys to input data into the system. While there is no doubt that a fully developed panel for these operations would be the best solution, one doesn't always have the luxury of time.
Definitely Kotlin. I had a meeting with my team and talked about the advantages of Kotlin and why I believe we should start writing a proportion of the new modules in Kotlin and have asked for their input. This is one of the cases where it needs to be unanimous decision, but so far everyone seems in favour of it and looks like we'll be writing a good amount of Kotlin in the coming months.
The reason why I believe Kotlin is a great way ahead is - Great java interop, removes a huge amount of boilerplate, results in very readable code and extremely easy to learn (one of the reasons we could not switch to Scala was the steep learning curve which would be a big problem for new developers joining us).
>one of the reasons we could not switch to Scala was the steep learning curve which would be a big problem for new developers joining us
I think this is overblown. Yes, the language has a deep learning curve, but you're really trading off language complexity for lack of framework complexity. Because the language is so powerful, you'll see a lot less 'magic' frameworks (no need for a DI framework, no need for AOP, etc) so applications tend to have a really low barrier of entry to work with. We hire new developers all the time and they are productive way before they master the language.
This attitude happens all the time FP in the job comes up and it essentially means the parent commenter's company has no time or resources for training or mentoring.
NoRedInk (among other companies) use non-mainstream FP languages and hire juniors all the time. Turns out that people can learn things quickly if they're smart (which is why you hired them, I hope) and are given mentorship.
i am really excited about how the language is evolving. its becoming silly to use anything else on Android now.
on the server Spring 5 is building official support for kotlin as is vert.x. Reactor is integrated closely with kotlin... and the developers are putting in a lot of effort around scripting.
I worked NA logistics back when I was with Amazon, and was with the team behind the LA fresh and the team which works with intermediate FCs (they don't stock goods, but do store-and-forward at crucial locations in the logistics pipeline). And you are right, Amazon does an incredible amount of stuff when it comes to logistics. There is an entire building that houses trans & metrics team, and the hyderabad center in India is mostly just the transportation team.
Amazon is way ahead in the logistics game, even further than some of your flagship logistics companies.
and typed 'd' for True and 'f' for False in the array, bringing the accuracy of the predictor down to 53%. Theoretically, I'm guessing doing it for large enough numbers should make it exactly 50%.
