PurpleBooth

Project Title

One Paragraph of project description goes here

Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

Prerequisites

manigandham

Strictly Frameworks

• Mobiledoc - github.com/bustle/mobiledoc-kit - framework to build editors with a standardized JSON structure
• ShareDB - github.com/share/sharedb - framework to sync any JSON document using operational transforms, add real-time collaborative editing to anything else
• Bangle.dev - github.com/bangle-io/bangle.dev - toolkit built for building editors, based on prosemirror

Abstracted Editors

These use separate document structures instead of HTML, some are more modular libraries than full editors

parmentf

Inspired by dannyfritz/commit-message-emoji

See also gitmoji.

Commit type	Emoji
Initial commit	🎉 :tada:
Version tag	🔖 :bookmark:
New feature	✨ :sparkles:
Bugfix	🐛 :bug:

andymatuschak

A composable pattern for pure state machines with effects

State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?

There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.

Here I present a composable pattern for pure state machiness with effects,

huandu

map $http_origin $allow_origin {
  default "$http_origin";
}

map $request_method $cors_method {
  default "allowed";
  "OPTIONS" "preflight";
}

map $cors_method $cors_max_age {

CAYdenberg

Statement of Work

Between [company name]

And [customer name].

Summary:

We’ll always do our best to fulfill your needs and meet your expectations, but it’s important to have things written down so that we both know what’s what, who should do what and when, and what will happen if something goes wrong. In this contract you won’t find any complicated legal terms or long passages of unreadable text. We’ve no desire to trick you into signing something that you might later regret. What we do want is what’s best for both parties, now and in the future.

alyssais

tap "homebrew/php"

brew "php71"
brew "mysql"
brew "composer"

timvisee

Falsehoods programmers believe about time

This is a compiled list of falsehoods programmers tend to believe about working with time.

Don't re-invent a date time library yourself. If you think you understand everything about time, you're probably doing it wrong.

Falsehoods

• There are always 24 hours in a day.
• February is always 28 days long.
• Any 24-hour period will always begin and end in the same day (or week, or month).