463 karma · joined May 4, 2021
WhatsApp first value proposition has been to enable cheap ("free") messaging while, at least here in Argentina, SMS would still cost a lot of money. The Android SMS experience is bad, too - or at least it's not a nice one.
Add groups, multimedia, audio calls with no long-distance fee, or even video calls (I don't think the phone system offers an alternative, at least here), and all of that being "cross-manufacturer" (we have 92% Android users here, so you still don't want to leave your two iOS friends out) and it's pretty much clear why WhatsApp works best.
Signal & Telegram could have make it, too - but WhatsApp was probably first, and they offered support for some feature phones back then when they still were around.
I want to move out of Docker services because of the "The new terms take effect on August 31, 2021" part of the email I've just received, even if it's followed by a "with a grace period until January 31, 2022".
I'm OK with them trying to get money. I'm not OK with them changing things overnight.
This is usually (at least marketed as) a spam prevention system, so you don't blast people with a really cheap, disposable SIM card.
Were I work, we've implemented a couple of nation-wide general population surveys regarding non-communicable diseases (working with those countries health authorities, of course). For the actual surveys, we get SMPP contracts with the local telcos because of this limit (and to get a vanity shortcode, reverse billing...).
We started thinking it would also be cheaper, too (due to the scale pricing) - but the human time required for working out contracts with developing-world telcos for a project involving state actors can easily counter that.
The throttling is something we need to take into account for the tiny-scale pre-tests we ran (while working out the contract) using an SMS Gateway App[0] we've built, similar to the one from this thread. The main difference is ours uses a queue-based protocol to exchange messages with a controlling server.
So my attempt to find a counterexample is to start at (2^68)+1, and perform the 3x+1 or halving until I get to a number that's lower than the one I'm testing - then I know it's not a counterexample.
Since even numbers start by halving (ie, getting lower), I only test odd numbers.
295147905503560000001 and counting. No counter-examples found yet.
https://commonvoice.mozilla.org/
There are many languages available to pick from.
Not sure how active it is, though.
Matz even mentioned Crystal as a study case while explaining what Ruby's static type system would be like - back in 2016[1].
[0] https://manas.tech/blog/2016/04/01/the-story-behind-crystal/ [1] https://youtu.be/1l3U1X3z0CE?t=1755
EDIT: PR submitted. Feel free to create one next time :)
https://github.com/crystal-lang/crystal-website/pull/172/fil...
I had the idea that browsers were showing a grayed-down padlock for standard HTTPS certificates (ie, "connection is encrypted") vs a full-blown green icon with the company name next to it for the HTTPS certificates that also validate identity (DV? EV? I don't recall the meanings and acronyms).
I guess that's where we should go now: make HTTPs the default (thus showing a standard icon that doesn't call for any attention), a big red ugly icon alerting non-encrypted connections, and a green one with identity attached meaning you can indeed trust this particular site to really be your bank.
(I work on Manas.Tech, the partners of InSTEDD that developed the Reporting Wheel and today run nation-scale surveys using Surveda: https://manas.tech/projects/surveda/ )
Hi there! If you've liked the Reporting Wheel, you can see a couple of screenshots (and link to the source code) of the tool built to generate the wheels in Manas' site[0].
We work on lots of projects in unconventional contexts like this one. Feel free to lurk around the site and read our handbook[1] - and you bet we're hiring[2].
[0] https://manas.tech/projects/reporting-wheel/
Have a generic link in which they could find most of their answers. When they ask something that's in the docs, reply with a link. When they ask something that's not, add it to the docs, and reply the answer + "that was missing - I've just added it to the docs" to reinforce the fact that this time it was OK to ask and that they helped you improve the docs.
The more someone asks you things that were searchable, the more you delay the answer with the link. If you make it quicker to search than to ask, that'll encourage them to search.
If they still don't change the attitude, let your manager work. If that doesn't bring any other change - it may be time to move to another team/manager.
It doesn't matter when you read this.
The default for most of the tools/frameworks is to generate this bloat without a nice fallback for slow connections. Because the industry is focused on people with good connections, because that's where the money is.
Whenever I develop a webapp whose users won't be having a good Internet connection, there's a requirement to support that use case, and I spend time making sure the thing is usable on bad connections, and it's OK to sacrifice some UX to get there.
But on most cases, customers (both end-users and companies that pay me to code something for them) prefer shiny & cheap rather than "works OK for faceless people I don't know they still live like I did 15 years ago".
TL;DR: it's an economics issue, as usual.
----
PD: I've spent five hours yesterday to avoid a 70% packet loss to the router in the place I've recently moved to. There's a (top) 6Mbps connection on the other side of the router. I'm suffering not being on a top-class connection - but that's _my_ issue, not my customer's, nor my customer's customers.
Manas.Tech is a team of doers, and what we do is unconventional software. From firefighting drones to city planning tools, and from biotech to Crystal (https://crystal-lang.org/), a programming language for humans and computers.
We are looking for more doers, particularly full-stack engineers (leaning heavier towards backend), REMOTE (Europe based). Reach out at https://manas.tech/join/