I had hoped that this article will illustrate the scientific/technical reasons for PostgreSQL's superiority over MySQL. Alas, it just mentions that there was a bug that got fixed after 14+ years in MySQL. The author doesn't even mentions the severity of the bug and the negative effects it had. Overall, for me this article is nothing but the author just "blowing his/her own horn".
I bet with Hyperloop One becoming `Virgin Hyperloop One`, the hospitality and the customer care experience will surely be awesome, thanks to the Virgin Group :D :D
Articles on wikipedia should not be watered down for the common masses, especially if those articles require equations/mathematics that underpins them. In the following quote
"In making the general point that science uses its intrinsic difficulty as a mechanism for enforcing an otherwise artificial exclusivity"
the author doesn't want to accept the fact that, if every science article on wikipedia or for that matter on any website is written for novices, then it would needlessly become lengthy.
Also for many such articles the reference links would point to the articles for gaining a more fundamental understanding of the subject.
This manual, as I may call it, is hilarious. But its usefulness cannot be discounted. The first rule while dealing with people is "Individuals are who they are." And if in the past you had an encounter with someone who fits the label of "stupid", as described by these laws, then there is a high chance that the person is going to display stupidity even in the foreseeing future.
As a friend of mine once remarked in Hindi-- "Once a chutiya, always a chutiya."
(Translation ) "Once a stupid, always a stupid"
I have felt that learning Vim, does have a direct relation to productivity, especially if you are more comfortable with keyboard interactions as compared to a GUI. And yes, the learning of this editor can be viewed as a developers investment into improving his/her productivity.
Joel Spolsky - "Strategy Letter V". The article serves as an economics primer for any individual(though its much more relevant to software developers). Key Takeaway-- commoditize your products complement
For me the takeaway was getting familiar with the various licensing systems. Going forward, I think I would be giving heed to the license a particular OSS carries with it before using it for production level development.
At our firm we had used a few of the examples set out in this article. We stumbled upon them by trial and error. It is good to see them formalised here.
In the recent past there had been a burgeoning of startups that wanted to be the uber-for-x, specially in India. HyperTrack was created to address this segment of the market. However, many of these Uber-for-X hyperlocal vendors died a quick death after burning pile loads of investor money.With other startup's providing more end-to-end solutions in terms of route-scheduling and freight packaging(locus.sh) and also the downfall in the number of startups trying to be Uber-for-X, it surely will be interesting to see if HyperTrack's offerings are still relevant.
Btw in 2016, at my previous startup we had used HyperTrack services for tracking of sales personnel on the field. We had issues with accurate location reporting and also there were quite some bugs. We then decided to stop using their API's. I hope that by now these issues are resolved.
I think that any individual, who does some work creating/building a product/feature goes will identify themselves with the ideas presented in this article. However, the world actually belongs those who can get others to create and build. These usually are the people who have access to capital and use it to generate more capital.