Skip to main content

Posts

Logical Fallacies and the Art of Debate

Contents: Introduction So why learn logical fallacies at all? Logic as a form of rhetoric Committing your very own logical fallacies The list of fallacies : argumentum ad antiquitatem argumentum ad hominem argumentum ad ignorantiam argumentum ad logicam argumentum ad misericordiam argumentum ad nauseam argumentum ad numerum argumentum ad populum argumentum ad verecundiam circulus in demonstrando complex question dicto simpliciter naturalistic fallacy nature, appeal to non sequitur petitio principii post hoc ergo propter hoc red herring slippery slope straw man tu quoque Introduction This is a guide to using logical fallacies in debate. And when I say "using," I don't mean just pointing them out when opposing debaters commit them -- I mean deliberately committing them oneself, or finding ways to transform fallacious arguments into perfectly good ones. Debate is, fortunately or not, an exercise in persuasion, wit, and rhetoric, not just logic. In a debate format that limits...

The missing guide to OAuth 2.0

The modern human likely has profiles on dozens of applications. Whether it’s social media applications, music/video streaming, or workspace resources, each of us must manage accounts that contain personal information. Over time, these siloed applications have become increasingly connected. Twitter allows news sites to directly tweet, Discord searches Facebook for suggested friends, and Jira creates user accounts using Github profiles. This trend of allowing applications to talk to each other on your behalf is called “Delegated Access” and has become a necessary part of our online lives. However, because of the way these applications protect their data, developers run into a challenge:  How  do we delegate access? Almost every application is protected by a basic username/password schema. To allow Application A to access the data it needed from Application B would require constantly logging into Application B on behalf of Application A - how unwieldy! The workaround was to give ...

The missing guide to useful Python 3 features

Numerous people started to shift their Python version from 2 to 3 due to Python EOL. One of the most well-known changes is;  print  function in Python 2 is replaced by the  print()  function in Python 3. However, parentheses work in Python 2 if a space is added after  print  keyword because the interpreter evaluates it as an expression. Below, I introduce a few illustrations of amazing features you can find only in Python 3 in the hopes that it will solve your Python problems easily. All examples are coded in python 3.8.0 f-strings (3.6 +) It is hard to perform anything in whatever programming language without strings and you expect a structured way to work with strings to stay productive. Most people who use Python prefer to use the  format  method. user = “Prince” action = “coding” log_message = ‘User {} has logged in and did an action {}.’.format( user, action ) print (log_message) # User Prince has logged in and did an action coding. In ad...

Unit Testing is overrated

Unit testing is a popular approach for testing software, but mostly for the wrong reasons. It’s often touted as an effective way for developers to test their code while also enforcing best design practices, however many find it encumbering and superficial. It’s important to understand that development testing does not equate to unit testing. The primary goal is not to write tests which are as isolated as possible, but rather to gain confidence that the code works according to its functional requirements. And there are better ways to achieve that. Writing high-level tests that are driven by user behavior will provide you with much higher return on investment in the long run, and it isn’t as hard as it seems. Find an approach that makes the most sense for your project and stick to it. Here are the main insights: Think critically and challenge best practices Don’t rely on the test pyramid Separate tests by functionality, rather than by classes, modules, or scope Aim for the highest level ...

Book Summary : Designing Data Intensive Applications by Martin Kleppmann

I. 4 fundamental ideas that we need in order to design data-intensive applications. Reliable, scalable, maintainable applications. Reliability means continuing to work correctly, even when things go wrong. Common faults and preventions include: Hardware faults: hard disks crash, blackout, incorrect network configuration,… Add redundancy to individual hardware components to reduce the failure rate. As long as we can restore a backup onto a new machine quickly, the downtime is not fatal. Software faults: bug, out of shared resources, unresponsive service, cascading failure,… There’s no quick solution other than thorough testing, measuring, monitoring, analyzing. Human errors: design error, configuration error,… Enforce good design, good practice and training. Decouple the places where people make the most mistake. Automate testing: unit test, integration test, end-to-end test. Allow quick recovery rollback strategy. Set up detials monitoring Scalability describes a system’s ability to co...