cinbun8

I would rather say 'Never give your information to a startup that does not handle it responsibly'. Not every startup is irresponsible with data.

In this case you have a strong point. Good work finding the security issue and reporting it.

Its a matter of perspective and preference. When you are young you don't mind fidgeting with things, leaning their inner working and trying to get something to work. When something is done you can point to it proudly and cry 'I did that'. As you get older you start to lose your patience with technology and sympathize with the user a little. Your perspective could be - 'Why wont this just work !'.

Perhaps it is a matter of patience. I would not know since I'm not 56 yet. OP - A toast to the fire that is still burning within you. May it keep burning for a long time. Have fun writing code.

I tried to teach my nephew to code with python. He is 7. It didnt stick on the first attempt. However when I showed him how to use a for loop, he printed a multiplication table, turned around to his mom and exclaimed 'homework done' ! :)

It comes down to conversion rates from free -> paid users. Is there an itch that your customer must scratch and is willing to pay for ? As long as that motivator exists you will see good conversion rates. However if the idea is to sell 'cool' things that add bling to a service / app, it is less likely to sustain profit.

Why would you even need a json document to modify another json document ? Could you not author a DSL to reference XPATH like structures and have operations performed on them ?

Secondly I don't see what additional benefit this adds to JSON documents across various use cases (HTTP servers / parsers / persistence / etc). From an API's perspective, are parsers expected to accept this patch-document and apply them to json-documents that they already loaded ? The closest match you get to something like this in the XML world is a XSLT. Feed one XML document in and it can be converted to an XML or output of another kind. You cannot expect HTTP servers to accept these via PATCH and update documents atomically. Resource modification is not atomic in eventually consistent systems.

For those systems where an update / patch can be made atomically, updating a field on a document without replacing it makes sense. However doing it via another json document is not the way to go IMHO. Use a DSL instead.

It comes down to whether you can make a living in India if you get into sports. The economics around it are strong enough to force out anyone considering sports. Cricket is the only sport in India that can get you top dollar whether you make it big or small. The compensation provided to a person playing hockey or table-tennis is meager in comparison.

Those that are talented and have the will + passion for the sport shine as long as they have enough funds. Then there are those [1] that have to sell their bow to make ends meet despite securing a silver medal at the south asian championships. It was heart breaking reading that.

[1] - http://www.thehindu.com/news/states/other-states/article3278...

Any ad network is susceptible to this sort of fraud. A group from China managed to amass large sums from Google ads until they were caught and shut down a year or two back (Techcrunch ran an article about this). I am sure there are some that still manage to do it successfully. The true value of a click is one that is quantifiable beyond likes. * How many users signed up because of the click with a valid email ? Captchas / honeypots can be used to filter spammers. * Of these users that signed up, how many are active ? * How many users bought the product as a result of the click ? etc You many need to drill down deeper to avoid some layers of spam users. But yeah, the way the value is measured should not stop with how many users 'liked' a product. It needs to go deeper.