takeokunn

Wandbox

Requirements

• AntonHakansson/org-nix-shell

System

fetburner

From mathcomp Require Import all_ssreflect.

Section Dijkstra.
  Import Order.TTheory.

  Variable V : finType.
  Variable C : orderType tt.

  Variable adj : V -> V -> C -> C.
  Hypothesis adj_increase : forall v u c, (c <= adj v u c)%O.

ivan

#!/usr/bin/env bash

# Generates an RSS feed for a list of audio files, for consumption by Overcast
# and other podcast players.
#
# Usage:   make-audio-feed TITLE BASE_URL FILE...
# Example: (cd directory && make-audio-feed 'My Audio Files' 'https://your.server/directory/' * > .feed.rss)

set -eu -o pipefail

lukas-h

Markdown License badges

Collection of License badges for your Project's README file.
This list includes the most common open source and open data licenses.
Easily copy and paste the code under the badges into your Markdown files.

Notes

• The badges do not fully replace the license informations for your projects, they are only emblems for the README, that the user can see the License at first glance.

Translations: (No guarantee that the translations are up-to-date)

• 🇫🇷 Cette liste en français

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

akheron

[alias]
	st = status --short --branch
	dc = diff --cached -M -B -C
	typo = commit --amend
	fixup = commit --amend --no-edit
	logk = log --graph --pretty=\"format:%C(yellow)%h%C(red)%d%Creset %s %C(green)%an, %ar%Creset\"
	ffpull = pull --ff-only
	ffmerge = merge --ff-only
	ri = "!f() { rev=$(git rev-parse $1 2>/dev/null) || rev=HEAD~$1; git rebase -i $rev; }; f"
	rc = rebase --continue

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.

evandrix

Here are a list of headless browsers that I know about:

• [HtmlUnit][1] - Java. Custom browser engine. JavaScript support/DOM emulated. Open source.
• [Ghost][2] - Python only. WebKit-based. Full JavaScript support. Open source.
• [Twill][3] - Python/command line. Custom browser engine. No JavaScript. Open source.
• [PhantomJS][4] - Command line/all platforms. WebKit-based. Full JavaScript support. Open source.
• [Awesomium][5] - C++/.Net/all platforms. Chromium-based. Full JavaScript support. Commercial/free.
• [SimpleBrowser][6] - .Net 4/C#. Custom browser engine. No JavaScript support. Open source.
• [ZombieJS][7] - Node.js. Custom browser engine. JavaScript support/emulated DOM. Open source.
• [EnvJS][8] - JavaScript via Java/Rhino. Custom browser engine. JavaScript support/emulated DOM. Open source.