Thought about this Tweet a lot today. Yes, I agree that Parler will come back, but I have yet to see people talking about just how powerful it is that the major players in the build-yourself-an-app starter kit have decided not to support Parler.
Back in "the day", you had to run your own servers and build most of your app by hand. You needed a small army of technical talent to scale your site, and even then it was still slow going.
Today, you can build and scale an app like Parler user mostly off-the-shelf components.
By denying Parler their services, companies like AWS and Twilio have deplatformed the platform.
It will now take an app like Parler years, if ever, to support the kind of viral adoption it has been seeing.
Second-order deplatforming is a MUCH more powerful tool.
I'm not an expert on social networks and virality, but as an expert on developer tooling, I believe people should be talking A LOT more about how easy it has become to build social networks that themselves go viral, and how these tools are often proprietary.
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
When I was and undergrad and junior grad student, I regularly burned myself out on deadlines. I actually work WAY harder now. And I'm able to do it because I learned to manage my energy better. Here are some lessons I learned.
Thread. π
The most important thing I learned was to recognize if I'm not working productively on something and step away. To make a sports analogy, pushing through fatigue is how you get better but you shouldn't push through injury. Taking a break early can give you a lot more time back.
Another lesson was to take recovery seriously. Previously, this meant sitting in a catatonic state after I had overworked myself. I now have processes for winding myself down daily, weekly, monthly, and annually. They include meditation, yoga, writing, and doing non-work things.
"Abstract interpretation: a unified lattice model for static analysis of programs by construction or approximation of fixpoints," Cousot & Cousot, 1977. Introduced abstract interpretation for statically analyzing program properties. Now used by Airbus.
"Design and synthesis of synchronization skeletons using branching time temporal logic," Clarke & Emerson, 1981. The first paper on model checking for program correctness. Led to the 2007 Turing Award.
Just had an good conversation with @panmanphil about data flows:
π§ Why enforcing privacy/access policies in software is hard
π« Why static and dynamic analysis aren't the solutions of people's dreams
π£οΈ Why data visibility/data mapping is The Way
THREAD π
@panmanphil π§ Enforcing security/privacy policies on data flows is not as simple as checking a rule as data leaves the database. *Which* rule you check for *what* data matters and is hard to keep track of. Either devs need to track this or software needs to track this. It's hard for devs.
@panmanphil π« Automatic policy enforcement requires automatic data tracking. Tracking data at runtime comes with unappealing performance overheads. Tracking it statically, before you run, gives you way too many false positives. Anything short of this leaves major gaps.