vitorgalvao

-- AppleScript --

-- This example is meant as a simple starting point to show how to get the information in the simplest available way.
-- Keep in mind that when asking for a `return` after another, only the first one will be output.
-- This method is as good as its JXA counterpart.

-- Webkit variants include "Safari", "Webkit", "Orion".
-- Specific editions are valid, including "Safari Technology Preview".
-- "Safari" Example:
tell application "Safari" to return name of front document

Avaq

const I  = x => x
const K  = x => y => x
const A  = f => x => f (x)
const T  = x => f => f (x)
const W  = f => x => f (x) (x)
const C  = f => y => x => f (x) (y)
const B  = f => g => x => f (g (x))
const S  = f => g => x => f (x) (g (x))
const S_ = f => g => x => f (g (x)) (x)
const S2 = f => g => h => x => f (g (x)) (h (x))

qoomon

Conventional Commit Messages

See how a minor change to your commit message style can make a difference.

git commit -m"<type>(<optional scope>): <description>" \
  -m"<optional body>" \
  -m"<optional footer>"

meigwilym

CQRS, Task Based UIs, Event Sourcing agh!

Posted by gregyoung on February 16, 2010

Many people have been getting confused over what CQRS is. They look at CQRS as being an architecture; it is not. CQRS is a very simple pattern that enables many opportunities for architecture that may otherwise not exist. CQRS is not eventual consistency, it is not eventing, it is not messaging, it is not having separated models for reading and writing, nor is it using event sourcing. I want to take a few paragraphs to describe first exactly what CQRS is and then how it relates to other patterns.

CQRS Command and Query Responsibility Segregation

Starting with CQRS, CQRS is simply the creation of two objects where there was previously only one. The separation occurs based upon whether the methods are a command or a query (the same definition that is used by Meyer in Command and Query Separation, a command is any method that mutates state and a query is any method that returns a value).

fatcerberus

Monads for the Rest of Us

by Bruce Pascoe - 1 May, 2019

"A monad is just a monoid in the category of endofunctors. What's the problem?" ~James Iry[^1]

The problem... is that there are several problems.

It's been said that monads bear a dreadful curse. Once you finally understand what they are, you begin to see them everywhere--but somehow become completely incapable of explaining them to anyone else. Many tutorial writers have tried to break the Great Curse--the Web is lousy with bold attempts and half successes that attest to this--and just as many have failed. Well, I'm here to address the elephant in the room[^2] and tell you that I intend to break the Great Curse once and for all.

There are basically two ways a monad tutorial tends to go. One is a paragraph or two of minimal descriptions of one or two common monads (Haskell's Maybe in particular is very popular), followed by a lot of intimidating Haskell syntax trying to explain--precisely--how it all fits together. This is well

kjmph

-- Based off IETF draft, https://datatracker.ietf.org/doc/draft-peabody-dispatch-new-uuid-format/

create or replace function uuid_generate_v7()
returns uuid
as $$
begin
  -- use random v4 uuid as starting point (which has the same variant we need)
  -- then overlay timestamp
  -- then set version 7 by flipping the 2 and 1 bit in the version 4 string
  return encode(