Skip to content

Instantly share code, notes, and snippets.

1488
8=D
A55hole
abortion
ahole
AIDS
AIDs
ainujin
ainuzin
akimekura
@karlding
karlding / downloading-vagrant-boxes-manually.md
Created January 14, 2018 05:45
how to download vagrant boxes manually

Download Vagrant boxes manually

In this example, we're going to download the Midnight Sun box.

# The box URL is https://app.vagrantup.com/uwmidsun/boxes/box/versions/2.1.0
# In general, we just take the box URL, and then append the provider URL
# https://app.vagrantup.com/<organization name>/boxes/<box name>/versions/<version>/providers/<provider>.box
wget https://app.vagrantup.com/uwmidsun/boxes/box/versions/2.1.0/providers/virtualbox.box -O box-2.1.0.box
@Vesnica
Vesnica / vscode_x2go_fix.txt
Created August 12, 2016 08:59
Visual Studio Code X2Go Fix
sudo sed -i 's/BIG-REQUESTS/_IG-REQUESTS/' /usr/lib/x86_64-linux-gnu/libxcb.so.1
Hint: You can copy modified lib to /usr/share/code/
[package]
name = "Django"
# version = ... # This is omitted, ``setup.py`` must be executed to read it.
summary = """
A high-level Python Web framework that encourages rapid development and\
clean, pragmatic design.\
"""
url = "http://www.djangoproject.com/"
author = "Django Software Foundation"
author-email = "[email protected]"

Serving Flask under a subpath

Your Flask app object implements the __call__ method, which means it can be called like a regular function. When your WSGI container receives a HTTP request it calls your app with the environ dict and the start_response callable. WSGI is specified in PEP 0333. The two relevant environ variables are:

SCRIPT_NAME
The initial portion of the request URL's "path" that corresponds to the application object, so that the application knows its virtual "location". This may be an empty string, if the application corresponds to the "root" of the server.

# -*- coding: utf-8 -*-
"""Demonstrate high quality docstrings.
Module-level docstrings appear as the first "statement" in a module. Remember,
that while strings are regular Python statements, comments are not, so an
inline comment may precede the module-level docstring.
After importing a module, you can access this special string object through the
``__doc__`` attribute; yes, it's actually available as a runtime attribute,
despite not being given an explicit name! The ``__doc__`` attribute is also
//Now with less jquery
//1) go to your my-list page, and scroll to the bottom to make sure it's all loaded:
//http://www.netflix.com/browse/my-list
//2) Next, paste this in your developer tools console and hit enter:
[...document.querySelectorAll('.slider [aria-label]')].map(ele => ele.getAttribute('aria-label'))
//or use this to copy the list to your clipboard:
copy([...document.querySelectorAll('.slider [aria-label]')].map(ele => ele.getAttribute('aria-label')))
@PurpleBooth
PurpleBooth / README-Template.md
Last active December 3, 2025 00:19
A template to make good README.md

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

@zsup
zsup / ddd.md
Last active October 28, 2025 18:25
Documentation-Driven Development (DDD)

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.