Rahul Goma Phulore missingfaktor

Serverless Concept

This document describes the general outcome we want for users as well as a few ideas on how we should do this. It shouldn't be considered prescriptive or precise though; if we come up with better ideas along the way, we should do them instead!

Onboarding

Users should be able to run something like the following:

$ sbt new typelevel/serverless.g8 --branch aws/http

Program Analysis, a Big Happy Family

The idea behind program analysis is simple, right? You just want to know stuff about your program before it runs, usually because you don't want unexpected problems to arise (those are better in movies.) Then why looking at Wikipedia gives you headaches? Just so many approaches, tools, languages 🤯

In this article I would like to give a glimpse of an overarching approach to program analysis, based on ideas from abstract interpretation. My goal is not to pinpoint a specific technique, but rather show how they have common core concepts, the differences being due mostly to algorithmic challenges. In other words, static analysis have a shared goal, but it's a challenge to make them precise and performant.

Code is meant to be executed by a computer. Take the following very simple function:

fun cantulupe(x) = {

Fibers

Fibers are an abstraction over sequential computation, similar to threads but at a higher level. There are two ways to think about this model: by example, and abstractly from first principles. We'll start with the example.

(credit here is very much due to Fabio Labella, whose incredible Scala World talk describes these ideas far better than I can)

Callback Sequentialization

Consider the following three functions

Thread Pools

Thread pools on the JVM should usually be divided into the following three categories:

CPU-bound
Blocking IO
Non-blocking IO polling

Each of these categories has a different optimal configuration and usage pattern.

Some thoughts on building software

Lately I have been busy reading some new books on Domain Driven Design (DDD) and software architecture -- including a short yet eye-opening one in Python and a great one in F#. At the same time, it seems that more people in the Functional Programming world are looking at more formal approaches to modelling -- some examples here. This has brought some thought from the background of my brain about how we should model, organize, and architect software using the lessons we've learnt from functional programming.

Before moving on, let me be clear about this being just a dump of some thoughts, not always well-defined, definite

Zebu https://github.com/modernserf/zebu

Constraints - Crista Lopes tagide.com/blog/research/constraints

Little Languages - Jon Bentley staff.um.edu.mt/afra1/seminar/little-languages.pdf

Purpose-Built Languages - Mike Shapiro

In Haskell, if you want to create a hierarchy of types (and there will be needs at times), you use an encoding like below:

data CustomerCreatedAction = CustomerCreatedAction { ...stuff... }

data JourneyRunnerAction = JourneyRunnerAction { ...stuff... }

data Action = AC CustomerCreatedAction
            | AJ JourneyRunnerAction

	// 3D Dom viewer, copy-paste this into your console to visualise the DOM as a stack of solid blocks.
	// You can also minify and save it as a bookmarklet (https://www.freecodecamp.org/news/what-are-bookmarklets/)
	(() => {
	const SHOW_SIDES = false; // color sides of DOM nodes?
	const COLOR_SURFACE = true; // color tops of DOM nodes?
	const COLOR_RANDOM = false; // randomise color?
	const COLOR_HUE = 190; // hue in HSL (https://hslpicker.com)
	const MAX_ROTATION = 180; // set to 360 to rotate all the way round
	const THICKNESS = 20; // thickness of layers
	const DISTANCE = 10000; // ¯\\_(ツ)_/¯

	Introduction
	============

	Industry statistics as a whole have failed to improve much since 1968, when software engineering and
	scientific management were introduced as means for resolving the "software crisis". Unfortunately
	abandoned projects, cost/time overruns, and bloated, buggy software still dominate the landscape.

	In spite of the efforts to mitigate this situation --like XP, agile, software craftsmanship or DDD-- the
	reality is that a usual software project stack involves an increasingly larger number of programming
	languages, DSLs, frameworks, systems, tools, techniques and processes, so it is a fact that the