markfrost frostmark

Golang installation guide

Since Golang version 1.11 this process is finally (almost) as easy as it should (!!). You can see full docs here. For older guides see here.

These are my notes, not a generic solution. They are not meant to work anywhere outside my machines. Update version numbers to whatever are the current ones while you do this.

Installing everything needed the first time

Install `asdf` and its golang plugin, then install golang

How to setup Next.js app on Nginx with letsencrypt

Next.js, Nginx with Reverse proxy, SSL certificate

UPDATE (07/20/2021):
- This process got simplified over the years of this gist being out
- Older version of this gist (without certbot): https://gist.github.com/kocisov/2a9567eb51b83dfef48efce02ef3ab06/33fdd88872a0801bdde58fccce430fa48737ae10
- I would also now recommend deploying to Vercel if you don't need custom server support

1. Install Nginx, Node and certbot

DigitalOcean Ubuntu 14.04 x64 + Rails 4 + Nginx + Unicorn + PostgreSQL + Capistrano 3

Create a Droplet

SSH into Root

$ ssh [email protected]

Change Root Password

Dependency Injection in Ruby 07 Oct 04

Introduction

At the 2004 Ruby Conference, Jamis Buck had the unenviable task to explain Dependency Injection to a bunch of Ruby developers. First of all, Dependency Injection (DI) and Inversion of Control (IoC) is hard to explain, the benefits are subtle and the dynamic nature of Ruby make those benefits even more marginal. Furthermore examples using DI/IoC are either too simple (and don’t convey the usefulness) or too complex (and difficult to explain in the space of an article or presentation). I once attempted to explain DI/IoC to a room of Java programmers (see onestepback.org/articles/dependencyinjection/), so I can’t pass up trying to explain it to Ruby developers.

Thanks goes to Jamis Buck (the author of the Copland DI/IoC framework) who took the time to review this article and provide feedback.

What is Dependency Injection?

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.

#Setting up Nginx on Your Local System ###by Keith Rosenberg

##Step 1 - Homebrew The first thing to do, if you're on a Mac, is to install homebrew from http://mxcl.github.io/homebrew/

The command to type into terminal to install homebrew is:

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

	# app/controllers/application_controller.rb

	class ApplicationController < ActionController::Base

	def not_found
	raise ActionController::RoutingError.new('Not Found')
	rescue
	render_404
	end

	AllCops:
	RunRailsCops: true

	# Commonly used screens these days easily fit more than 80 characters.
	Metrics/LineLength:
	Max: 120

	# Too short methods lead to extraction of single-use methods, which can make
	# the code easier to read (by naming things), but can also clutter the class
	Metrics/MethodLength:


	gem 'omniauth'
	gem 'omniauth-facebook'
	gem 'clearance'