rstacruz

Arch Linux ARM on Crostini

I got Arch Linux ARM installed on a Lenovo Chromebook Duet! I mostly used the instructions from the Arch Wiki as reference.

0. Before we begin

chrismccord

defmodule DrainStop do
  @moduledoc """
  DrainStop Attempts to gracefully shutdown an endpoint when a normal shutdown
  occurs. It first shuts down the acceptor, ensuring that no new requests can be
  made. It then waits for all pending requests to complete. If the timeout
  expires before this happens, it stops waiting, allowing the supervision tree
  to continue its shutdown order.

  DrainStop should be installed in your supervision tree *after* the
  EndPoint it is going to drain stop.

jmazzi

<?php

/**
 * Run with `wp --require=import-cache.php import ...
 */
WP_CLI::add_hook( 'after_wp_load', function(){

	// Only intercept HTTP requests when the importer is running
	if ( ! defined( 'WP_IMPORTING') || ! WP_IMPORTING ) {
		return;

paragonie-scott

Hello software developers,

Please check your code to ensure you're not making one of the following mistakes related to cryptography.

I. General Mistakes

• Writing your own home-grown cryptography primitives (For example: Mifare Classic)
  • Exception: For the sake of learning, but don't deploy it in production.
• Using a fast hash function (e.g. MD5, SHA256) for storing passwords. Use bcrypt instead.
• Not using a cryptographically secure random number generator

seapy

RailsConf 2015 Schedule

RailsConf 2015 Room 202 Day 1

• Opening Keynote - DHH
• Prying Open The Black Box - Godfrey Chan
  • slide
• Riding Rails for 10 Years - John Duff
• DevOps for The Lazy - Aja Hammerly
• Docker isn’t just for deployment - Ben Dixon

treble37

# This file was generated by the `rails generate rspec:install` command. Conventionally, all
# specs live under a `spec` directory, which RSpec adds to the `$LOAD_PATH`.
# The generated `.rspec` file contains `--require spec_helper` which will cause this
# file to always be loaded, without a need to explicitly require it in any files.
#
# Given that it is always loaded, you are encouraged to keep this file as
# light-weight as possible. Requiring heavyweight dependencies from this file
# will add to the boot time of your test suite on EVERY test run, even for an
# individual file that may not need all of that loaded. Instead, make a
# separate helper file that requires this one and then use it only in the specs

pnc

Using OTP's observer (appmon replacement) remotely

$ ssh remote-host "epmd -names"
epmd: up and running on port 4369 with data:
name some_node at port 58769

Note the running on port for epmd itself and the port of the node you're interested in debugging. Reconnect to the remote host with these ports forwarded:

$ ssh -L 4369:localhost:4369 -L 58769:localhost:58769 remote-host

jashkenas

Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.

For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.

But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.

SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil

garybernhardt

This tool is used to compare microbenchmarks across two versions of code. It's
paranoid about nulling out timing error, so the numbers should be meaningful.
It runs the benchmarks many times, scaling the iterations up if the benchmark
is extremely short, and it nulls out its own timing overhead while doing so. It
reports results graphically with a text interface in the terminal.

You first run it with --record, which generates a JSON dotfile with runtimes
for each of your benchmarks. Then you change the code and run again with
--compare, which re-runs and generates comparison plots between your recorded
and current times. In the example output, I did a --record on the master

everaldo

---
- :cod_uf: '52'
  :uf: Goiás
  :city_id: '00050'
  :city: Abadia de Goiás
  :sigla_uf: GO
  :city_code: '5200050'
- :cod_uf: '31'
  :uf: Minas Gerais
  :city_id: '00104'