I've seen "Network is unreliable" being used as an argument to hide laziness. I do agree you can have flaky network, but the biggest give of the laziness behind the argument is not inspecting error codes at all. In this particular case 508 for example is clear indicator of some error status. Why would you even keep blind retries in place? I hate the argument of devs arguing for "dumb clients" and server "taking care of everything". Even for network failures IDK how having a retry within millisecond will actually help. It will be more detrimental to your infra, bandwidth, battery than a once or twice snappy experience argument.
IDK why mobile dev folks do blind retries thinking server is some kind of mage. I’ve had debates on how much retry makes sense for a login service I built. People have the tendency of hey this endpoint used to work with these parameters didn’t work? Fine I will keep retrying! The only difference here I think is in company paid job you step up immediately put in a server side fix to fix outage and then make these changes to roll them out. All of this is achieved in matter of hour or so rather than 12+ hours.
Circuit breaking, exponential backoff, bulkheading should be key pillars and no dev should be allowed to write a client without these key skills.
Edit: Please add Jitter to the list of items. Any good library like https://resilience4j.readme.io/ will give you all of this for free out of box!
Almost 6-8 cofounders, nobody other than woz as big or as impactful. Weirdness on chain validation and all over the site. TBH I wonder if woz is really with them really co-founding or this is just like a kick-scammer.
Have used it in a go mono-repo. It’s own convention on packages and bad integration with IDE makes it a hard sell for me. I mean I just paid for Goland IDE why would I waste my time integrating with something that might or might not work for others. It’s a very hard sell.
With this argument iOS should have never taken off. Yet it’s better than “open” Android standards. Thing is Apple rewired people to stop thinking about RAM and CPUs and made developers write software that works on 4 year old iPhone. Try that in Android or Windows. Yes there is a down side to it but as long as consumers can win with the outcome I personally think it should be fine.
I am really curious why the response to Apple Silicon is so prompt vs when Microsoft did WinRT or ARM versions nobody really cared. What is the difference? Was there some problem in compilation tool-chain or what?
Amazon was a magical thinking! Google was a magical thinking! iPhone was a magical thinking! This article makes confusing arguments on sustainability and unsustainability.
I have personally been in position of living with $70K a year in SanFrancisco startup. This is back in 2013. While I accepted the offer thinking it will suffice I was living hand to mouth. I was spending my energy fighting with budgeting and spending my energy trying to save up while other with settled backgrounds were fine. In the end I lost my motivation and ended up leaving for a higher paying offer in 9 months.
I have no sympathy for any of these low paying companies. They should pay what an engineer deserves. It’s pure exploitation and I walked right into it.
Beanstalkd is probably the only beautiful queue I instantly fell in love with. It shares it's DNS with memcached, and makes life so much simple! I know people have the tendency to write complex abstractions and questionable choices around simple things. But sometimes simplicity and capability to reason well is the answer to everything.
I can’t express how many times htop has made my life easy by giving me this nice interactive UX. There is a reason it’s part of every docker image I create.
Would somebody say it can hold data as reliably as postgres. I’ve been very very impressed recently with Postgres and how long a DB can go (using Aurora right now). I would love to try it out but I am just too iffy on if it will withstand the load reliably (even in events of a crash).
2 years back we had huge debate to choose between Kotlin or Java. While Java folks thought it was immature to even discuss anything other than Java, we ended up adopting Kotlin company wide. Looking back at it we don't regret the decision even single bit! We are using Kotlin and Coroutines to run extremely heavy services (almost 1K req/sec per pod, with complex logic, few hundred threads, 6GB RAM and 2 CPU cores). People concerned with Project Loom, should remember it's backwards compatible & upgrade path can be done multiple ways. I would highly recommend Kotlin for backend services, you won't have to code review IDE vomit, depend on annotations, or live with callback hell (project reactor, rx-java).
Just bought my wife a Oneplus 8 because there were no decent phones in US at that time. Now looking at 4a I am like ️ I should have convinced her to wait a little more.