kamaljoshi

# Except sqlite3 all the libraries are standard that should be present with a Ruby installation.
# If you don't have sqlite3 installed. Use `gem install sqlite3`

require 'fileutils'
require 'sqlite3'
require 'uri'
require 'net/http'
require 'set'
require 'thread'

andreicristianpetcu

An Ansible summary

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

Configuration file

intro_configuration.html

First one found from of

jnoller

Internal Communication DRAFT

• Use asynchronous communication when possible (issues and email instead of chat), issues are preferred over email, email is preferred over chat, announcements happen via email or team standup, and people should be able to do their work without getting interrupted by chat.
  • More importantly, a verbal or chat record does not spread communication widely and can vary based the person delivering the message (bias) or other tribal interpretation. A written record is always critical when it comes to questions, strategy and decisions. When decisions or information is ad-hoc is reinforces the idea that people are treated unequally, do not have a voice and are kept in the dark.
• It is very OK to ask as many questions as you have, but ask them so many people can answer them and many people see the answer (so use issues or public chat channels instead of private messages or one-on-one emails) and make sure you try to document the answers.
• If applicable, use github to track

hangyan

function brew_check() {
  brew $2 info $1 | grep -q "Not installed"
}


function brew_install() {
  tool=$(echo $1 | awk '{print $1}')
  cask=$(echo $1 | awk '{print $2}')
  brew_check $tool $cask
  [[ $? -eq 0 ]] && echo -e "Installing $tool..." && brew $cask install $tool

adamkaplan

# SSL request to hostname that is not in DNS

> curl -o /dev/null -w @curlformat https://beta.finance.yahoo.com
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  255k    0  255k    0     0   233k      0 --:--:--  0:00:01 --:--:--  233k

Size:     261255
DNS:      0.522
Connect:  0.536

imjasonh

* {
    font-size: 12pt;
    font-family: monospace;
    font-weight: normal;
    font-style: normal;
    text-decoration: none;
    color: black;
    cursor: default;
}

wkjagt

#How I built an audio book reader for my nearly blind grandfather

Tweet this - Follow me

Last year, when visiting my family back home in Holland, I also stopped by my grand-parents. My grand-father, now 93 years old, had always been a very active man. However, during the presceding couple of months, he'd gone almost completely blind and now spent his days sitting in a chair. Trying to think of something for him to do, I suggested he try out audio books. After finally convincing him -- he said audio books were for sad old people -- that listening to a well performed recording is actually a wonderful experience, I realized the problem of this idea.

####The problem with audio devices and the newly blind. After my first impulse to jump up and go buy him an

staltz

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

---

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

---

Chaser324

Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.

In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.

Creating a Fork

Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j

elsewhat

//TODO in this script
//1. Add board id in url used in TrelloAPI method (line xx
//2. Add your email in sendChartsByEmail
//3. Add your Trello keys from https://trello.com/1/appKey/generate to authorizeTrello
//4. Setup daily trigger in script editor that runs TrelloAPI()
//5. Run once in google apps script editor to authorize trello for access
//6. Lookup values and aggValues are hardcoded to the labels I use in Trello
//
//In the Trello board use scrum for trello syntax (http://scrumfortrello.com/) 
//Example title: <name of task> (estimate hours) [work delivered in hours]