This snack has started appearing in Chennai as well. Pretty sure I have never seen it before 2-3 years here. I always was interested about the curiosity around it as a YouTube food reviewer asked some very specific questions and the vendor refused to answer.
Also pretty much everyone say it has no taste and only the lemon, salt and chili powder adds any taste but makes me wonder why it’s a profitable business if so.
I have programmed in Python, Ruby, JS, C, Go and Java.
The main reason Java receives so much flak is because it's setup is not beginner friendly.
JS, Python, Ruby make it so much easier to just write a program and run it. Naturally, any novice programmer would quit Java in the setup process itself. It's not easy in Java to just write a program and run it instantly.
But once you are through that painful process, there is no other ecosystem more stable than Java. Things don't move too fast and that's a good thing for production applications.
I do dislike the verbosity sometimes while doing something that would take just a few lines in python or ruby. But IntelliJ more than makes up for it.
I vividly remember writing my first few Java programs. It was the most ridiculous thing to get it to run. JRE can't find the program when both the source and class files are right there in the directory where you are trying to run the program from. You have to set the classpath first else it won't ever find your program. A beginner would be definitely frustrated. I was. I earn my livelihood writing Java code but I have recommended Python to both my brother and son who are just getting into programming.
Which form of jitter is better: adding a random wait time to a predetermined wait time that grows exponentially with each retry attempt, or following something like [0] where every retry attempt increases the possible wait time choices and the "jitter" is to randomly pick one of them?
To illustrate the latter option, suppose the smallest retry time unit is 1 second. The first attempt gives you a random choice in {0, 1}. The second attempt gives you a random choice in {0, 1, 2}. The third attempt gives you a random choice in {0, 1, 2, 4}. The fourth attempt gives you a random choice in {0, 1, 2, 4, 8}. This goes on until a ceiling in the number of attempts or a set wall clock time is reached.
It depends on what you want. The first option will tend towards longer waits, and the second towards shorter waits.
I would tend towards increasing the minimum wait at each iteration (until you get to some maximim wait), because it it failed 10 times in the last minute, it's likely going to fail many times in the next minute, so we don't need to try more than once or twice.
Also: in case the client random is broken, you don't want to accidentaly end up with everyone retrying after zero seconds forever.
exponential backoff will still kill the servers because the first thing people do is kill/restart the app or reload the webpage and it will just restart the backoff again
So just set 'backoff until [timestamp]' rather than 'backoff for [time interval]'. Generally users restart because they don't know what's going an assume the client is stuck in loop or something. Think of a client that can say 'internet is up but my.server is having [local, regional, global] problems. I will try again at 11:37am EST.'
Downforeveryoneorjustme is exploring an API for service monitoring and it seems to me like every cloud client should have a standardized approach of trying to reach its own server, then checking internet access, then checking a service monitor, then checking social media status updates.
Also think apps and devices should have limited peer-to-peer information sharing instead of only talking to the operating system. In many ways our devices are like a roomful of people whispering status updates to the operating system and/or user but never talking to each other because 'security'.
I make a mobile app and we do this. When the app wakes up it tries to GET a file from /.well-known and if that works, proceed. If it fails we have a notice with "will retry at T". Timing is random between 10 and 50 seconds
No I meant Lex Fraudman. Hotz is good in my book, the guy can actuary write code an has pulled sonys pants Down in a major embarsment for them. Kudos to hotz
So I happened to open this site on Firefox on Android and it's giving me strange bed timings.
For wake-up time at 6:00AM, it's showing me the following bed timings:
3:30PM, 5:00PM, 6:30PM
Further, I went ahead and opened it on Safari on iPhone where the timings are correct but time format is 24-hrs instead of 12-hrs
On Chrome, it works as expected.
I'm not a Front-End end dev, so I'm quite curious about what could be causing this difference.
BTW, great website. It's very slick and useful. I sent to this my parents who believe Sleeping amounts to wasting time and always keep me nagging about sleeping too much :P
I think the average Indian consumer has become more aware and conservative in their spending. Thanks to the wider reach of the internet, financial literacy is gradually increasing. Combine that with an economic slowdown and people are just more thoughtful about where they spend money. This is a natural consequence of a slowdown as Indian people are very risk-averse.
Prices of Cars and Houses have increased at a much higher rate than the Incomes, so people are delaying spending on expensive purchases. However, this is probably just one of the factors.
Demonetisation has definitely had an adverse effect on small individual businesses that operated on cash. Cash was the primary mode of transaction for maximum number of Indian people, especially the non-urban population. Unavailability of sufficient cash in the system for a long period of time has hit them hard. You cannot expect a barely literate rural person to suddenly start using digital form of payments.
Except, coins are not humans with emotions, and neither can they dupe probability to improve their outcome. The 50 heads(success) that you left are not going to do any better than the 50 tails you scolded. You are just changing the sample space in a biased fashion to prove your point.
I think you are totally missing my point. The whole point I am trying to make centers on the fact that the coins are all actually equal. The observed difference in performance is entirely due to chance.
While, of course, human performance is not always equal in the same way our coins are, the fact that performance (or whatever it is you are measuring) will still regress towards the mean still holds true. The coin example just gives an extremely obvious demonstration about what is happening when things regress towards the mean.
It was the only time I had seen this thing. There were dozens of vendors selling this lined up on the stairs to the temple.
It seems the snack has gone popular now. It's quite tasteless, felt like eating soft wood.
Never expected to find this on Hackernews!