nifl

Answer by Jim Dennis on Stack Overflow question http://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118

Your problem with Vim is that you don't grok vi.

You mention cutting with yy and complain that you almost never want to cut whole lines. In fact programmers, editing source code, very often want to work on whole lines, ranges of lines and blocks of code. However, yy is only one of many way to yank text into the anonymous copy buffer (or "register" as it's called in vi).

The "Zen" of vi is that you're speaking a language. The initial y is a verb. The statement yy is a simple statement which is, essentially, an abbreviation for 0 y$:

0 go to the beginning of this line. y yank from here (up to where?)

jeromer

# LICENSE: public domain

def calculate_initial_compass_bearing(pointA, pointB):
    """
    Calculates the bearing between two points.

    The formulae used is the following:
        θ = atan2(sin(Δlong).cos(lat2),
                  cos(lat1).sin(lat2) − sin(lat1).cos(lat2).cos(Δlong))

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.

soarez

How to setup your own CA with OpenSSL

For educational reasons I've decided to create my own CA. Here is what I learned.

First things first

Lets get some context first.

AdamOssenford

An Ansible summary

Jon Warbrick, July 2014, V3.2 (for Ansible 1.7)

Configuration file

intro_configuration.html

First one found from of

marians

This is an unofficial manual for the couchdb Python module I wish I had had.

Installation

pip install couchdb

Importing the module

leonardofed

A curated list of AWS resources to prepare for the AWS Certifications

A curated list of awesome AWS resources you need to prepare for the all 5 AWS Certifications. This gist will include: open source repos, blogs & blogposts, ebooks, PDF, whitepapers, video courses, free lecture, slides, sample test and many other resources.

---

dcode

GitHub Flavored Asciidoc (GFA)

briandominick

AJYL DocStack

AsciiDoc

Jekyll

StevenACoffman

Set GOPRIVATE to match your github organization

I keep fixing this up, but if it fails for you, check if these are better maintained https://tip.golang.org/cmd/go/#hdr-Configuration_for_downloading_non_public_code and https://golang.org/ref/mod#private-modules.

Cloning the repo using one of the below techniques should work correctly but you may still be getting an unrecognized import error.

As it stands for Go v1.13, I found in the doc that we should use the GOPRIVATE variable like so:

GOPRIVATE=github.com/ORGANISATION_OR_USER_NAME go get -u -f github.com/ORGANISATION_OR_USER_NAME/REPO_NAME

The 'go env -w' command (see 'go help env') can be used to set these variables for future go command invocations.