William Richardson ginjo

If you're writing web applications with Ruby there comes a time when you might need something a lot simpler, or even faster, than Ruby on Rails or the Sinatra micro-framework. Enter Rack.

Rack describes itself as follows:

Rack provides a minimal interface between webservers supporting Ruby and Ruby frameworks.

Before Rack came along Ruby web frameworks all implemented their own interfaces, which made it incredibly difficult to write web servers for them, or to share code between two different frameworks. Now almost all Ruby web frameworks implement Rack, including Rails and Sinatra, meaning that these applications can now behave in a similar fashion to one another.

At it's core Rack provides a great set of tools to allow you to build the most simple web application or interface you can. Rack applications can be written in a single line of code. But we're getting ahead of ourselves a bit.

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

	/*
	Copyright (c) 2017 Chris Patuzzo
	https://twitter.com/chrispatuzzo

	Permission is hereby granted, free of charge, to any person obtaining a copy
	of this software and associated documentation files (the "Software"), to deal
	in the Software without restriction, including without limitation the rights
	to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
	copies of the Software, and to permit persons to whom the Software is
	furnished to do so, subject to the following conditions:

	# Encryption functions. Requires the GNUpg "gpg" commandline tool. On OS X, "brew install gnupg"
	# Explanation of options here:
	# --symmetric - Don't public-key encrypt, just symmetrically encrypt in-place with a passphrase.
	# -z 9 - Compression level
	# --require-secmem - Require use of secured memory for operations. Bails otherwise.
	# cipher-algo, s2k-cipher-algo - The algorithm used for the secret key
	# digest-algo - The algorithm used to mangle the secret key
	# s2k-mode 3 - Enables multiple rounds of mangling to thwart brute-force attacks
	# s2k-count 65000000 - Mangles the passphrase this number of times. Takes over a second on modern hardware.
	# compress-algo BZIP2- Uses a high quality compression algorithm before encryption. BZIP2 is good but not compatible with PGP proper, FYI.

	#
	# the following one liner creates a shell variable from every parameter in a
	# the query string in the variable QUERY, of the form p1=v1&p2=v2,... and sets it to
	# the corresponding value so that parameters can be accessed by its name $p1, $p2, ...
	#

	for p in ${QUERY//&/ };do kvp=( ${p/=/ } ); k=${kvp[0]};v=${kvp[1]};eval $k=$v;done

	# The filter_parameter_logging method, used to filter request parameters
	# (such as passwords) from the log, defines a protected method called
	# filter_parameter when called. Its existence is later tested using
	# respond_to?, without the include_private parameter. Due to the respond_to?
	# behavior change, the method existence is never detected, and parameter
	# filtering stops working.
	require 'action_controller'

	module ParameterFilterPatch
	def respond_to?(method, include_private = false)

	CLIENT/SERVER MODEL
	It is quite simple to build a very basic client/server model using nc. On one console, start nc listening on a specific port for a connection. For example:

	$ nc -l 1234

	nc is now listening on port 1234 for a connection. On a second console (or a second machine), connect to the machine and port being listened on:

	$ nc 127.0.0.1 1234

	There should now be a connection between the ports. Anything typed at the second console will be concatenated to the first, and vice-versa. After the connection has been set up, nc does not really care which side is being used as a ‘server’ and which

	#!/usr/bin/env bash
	#
	# Get the value of a tag for a running EC2 instance.
	#
	# This can be useful within bootstrapping scripts ("user-data").
	#
	# Note the EC3 instance needs to have an IAM role that lets it read tags. The policy
	# JSON for this looks like:
	#
	# {

	rm -f out
	mkfifo out
	trap "rm -f out" EXIT
	while true
	do
	cat out \| nc -w1 -l 1500 > >( # parse the netcat output, to build the answer redirected to the pipe "out".
	export REQUEST=
	while read line
	do
	line=$(echo "$line" \| tr -d '[\r\n]')

	readme.md
	rendered.html
	remain.txt