rohanprabhu

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"

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.

spring break

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.

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).

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.

So, I tried a simple python one-liner:

[os.urandom(1)[0] < 128 for x in xrange(0, 100)]

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%.

Just my 2 cents, but how gitlab has constantly improved over all other features, I would really love to see issues get the same treatment. The current issues system is simple, easy to use and works fine but we really didn't find it to be scalable when moving to bigger teams. Labels as a primitive method of categorization is fine, but it very soon becomes unmanageable. Getting to a feature set like JIRA is too much to ask I guess, but a middle ground would really help keep everything in gitlab.

Kind of off-topic, but the work GitLab is putting in and the things they come up with every other day is crazily impressive. We moved from Github to GitLab sometime ago and we believed that to be a trade-off for moving to our own infrastructure. It always seemed like GitLab wasn't "quite there". Today, however it is a whole different story. We pretty much cannot go back to Github at all because of how well-integrated, stable and beautiful this product is.