-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
-
aws-lambda-java-libs
Official mirror for interface definitions and helper classes for Java code running on the AWS Lambda platform.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
In dynamic and typed languages, linters are used. These are used before you run or compile the code. They vary in purpose, but all typically format code, help find common errors, and help guide on language best practices. For typed languages, these tools work alongside the compiler, giving you extra quality checks that the compiler doesn’t provide natively. Examples include PyLint for Python, ESLint for JavaScript, Vet for Go, and PMD originally for Java. These can prevent many runtime exceptions.
That’s how Promises or Futures work. JavaScript has them built in, and Python & Lua have libraries that support their usage.
In dynamic and typed languages, linters are used. These are used before you run or compile the code. They vary in purpose, but all typically format code, help find common errors, and help guide on language best practices. For typed languages, these tools work alongside the compiler, giving you extra quality checks that the compiler doesn’t provide natively. Examples include PyLint for Python, ESLint for JavaScript, Vet for Go, and PMD originally for Java. These can prevent many runtime exceptions.
In dynamic and typed languages, linters are used. These are used before you run or compile the code. They vary in purpose, but all typically format code, help find common errors, and help guide on language best practices. For typed languages, these tools work alongside the compiler, giving you extra quality checks that the compiler doesn’t provide natively. Examples include PyLint for Python, ESLint for JavaScript, Vet for Go, and PMD originally for Java. These can prevent many runtime exceptions.
First used (from my limited knowledge) in the Apollo Guidance Computer, and later popularized by Erlang, rather than avoid crashes with lots of work and still missing them, many developers today are just accepting crashes can happen. In Erlang/Elixir and the Akka framework, it’s common to create a lightweight process that’s sole job is to watch child process. The child process is what runs the actual code. If the child process crashes, the parent just spawns another one. This philosophy has moved from software to hardware in the disposable hardware movement, and now it’s just assumed if the software crashes, you just spawn an entirely new server.
Examples include Docker containers running on Elastic Compute Service (ECS) or Elastic Kubernetes Service (EKS) for Amazon, automatically assigned Dyno’s on Heroku, or simple functions running in AWS Lambda / Azure Functions. In these situations, entire applications can be run, and if even 1 has an unexpected runtime exception for whatever reason, that Docker container is shut down, and a new Docker container is spun up. For Lambda, it’s about the same; your function runs, and it fails, whoever is listening to the response from the Lambda gets notified it crashed. Both Docker and Lambda allow you to spawn thousands of these at the same time, quickly, with confidence all errors are handled, and you can control how often, and how many, are spun up in their place in case of an error.
First used (from my limited knowledge) in the Apollo Guidance Computer, and later popularized by Erlang, rather than avoid crashes with lots of work and still missing them, many developers today are just accepting crashes can happen. In Erlang/Elixir and the Akka framework, it’s common to create a lightweight process that’s sole job is to watch child process. The child process is what runs the actual code. If the child process crashes, the parent just spawns another one. This philosophy has moved from software to hardware in the disposable hardware movement, and now it’s just assumed if the software crashes, you just spawn an entirely new server.