jbr

Ruby Quickstart for Refugees:

--

# is a comment.
You don't need semicolons.
Ruby aims to be elegant and readable, so punctuation and boilerplate are
minimal.

--

hoffmann

import lxml.etree
def pprint(elem):
    print lxml.etree.tostring(elem, pretty_print=True)

class Bind(object):
    def __init__(self, path, converter=None, first=False):
        '''
        path -- xpath to select elements
        converter -- run result through converter
        first -- return only first element instead of a list of elements

quii

import scala.xml._
import scala.xml.transform._

object Main extends App {

	import Stuff._

	val sourceXml = XML.loadFile("metadata.switchaai.xml")

	val allEntities = sourceXml \\ "EntityDescriptor"

tmcw

OSM Lab is an organization for OpenStreetMap related projects - libraries, applications, and other code. We're liberal with membership.

Project Guidelines

• Use semver where appropriate
• README.md is required

blackfalcon

Git-workflow vs feature branching

When working with Git, there are two prevailing workflows are Git workflow and feature branches. IMHO, being more of a subscriber to continuous integration, I feel that the feature branch workflow is better suited, and the focus of this article.

If you are new to Git and Git-workflows, I suggest reading the atlassian.com Git Workflow article in addition to this as there is more detail there than presented here.

I admit, using Bash in the command line with the standard configuration leaves a bit to be desired when it comes to awareness of state. A tool that I suggest using follows these instructions on setting up GIT Bash autocompletion. This tool will assist you to better visualize the state of a branc

jwmalara

<select name="state">
  <option value="AL">Alabama</option>
  <option value="AK">Alaska</option>
  <option value="AZ">Arizona</option>
  <option value="AR">Arkansas</option>
  <option value="CA">California</option>
  <option value="CO">Colorado</option>
  <option value="CT">Connecticut</option>
  <option value="DE">Delaware</option>
  <option value="FL">Florida</option>

alexpchin

Setting up a new Git Repo

##Create a new repository on the command line

touch README.md
git init
git add README.md
git commit -m "first commit"

git remote add origin [email protected]:alexpchin/.git

LeCoupa

#!/bin/bash
#####################################################
# Name: Bash CheatSheet for Mac OSX
# 
# A little overlook of the Bash basics
#
# Usage:
#
# Author: J. Le Coupanec
# Date: 2014/11/04

wenfahu

    /\_/\     /\_/\
  =( owo )= =( owo )=
\\  )   (     )   (  //
 \\(_ _ _)   (_ _ _)//

1. C

joyrexus

Nice answer on stackoverflow to the question of when to use one or the other content-types for POSTing data, viz. application/x-www-form-urlencoded and multipart/form-data.

“The moral of the story is, if you have binary (non-alphanumeric) data (or a significantly sized payload) to transmit, use multipart/form-data. Otherwise, use application/x-www-form-urlencoded.”

---

Matt Bridges' answer in full:

The MIME types you mention are the two Content-Type headers for HTTP POST requests that user-agents (browsers) must support. The purpose of both of those types of requests is to send a list of name/value pairs to the server. Depending on the type and amount of data being transmitted, one of the methods will be more efficient than the other. To understand why, you have to look at what each is doing