gtrias

Better local require() paths for Node.js

Problem

When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:

const Article = require('../../../../app/models/article');

Those suck for maintenance and they're ugly.

Possible solutions

gtrias

module ControllerMacros
  def login_user
    before(:each) do
      @request.env["devise.mapping"] = Devise.mappings[:user]
      user = FactoryGirl.create(:user)
      user.confirm!
      sign_in user
    end
  end
end

gtrias

find ./db/migrate/* | xargs sed -i 's/create_table [^ ]*/&, :options => "ENGINE=MEMORY"/'

gtrias

import React, { Component } from 'react';

import TextField from 'components/base/TextField';

const WAIT_INTERVAL = 1000;
const ENTER_KEY = 13;

export default class TextSearch extends Component {
    constructor(props) {
        super();

gtrias

#!/bin/bash
beep -l 350 -f 392 -D 100 --new -l 350 -f 392 -D 100 --new -l 350 -f 392 -D 100 --new -l 250 -f 311.1 -D 100 --new -l 25 -f 466.2 -D 100 --new -l 350 -f 392 -D 100 --new -l 250 -f 311.1 -D 100 --new -l 25 -f 466.2 -D 100 --new -l 700 -f 392 -D 100 --new -l 350 -f 587.32 -D 100 --new -l 350 -f 587.32 -D 100 --new -l 350 -f 587.32 -D 100 --new -l 250 -f 622.26 -D 100 --new -l 25 -f 466.2 -D 100 --new -l 350 -f 369.99 -D 100 --new -l 250 -f 311.1 -D 100 --new -l 25 -f 466.2 -D 100 --new -l 700 -f 392 -D 100 --new -l 350 -f 784 -D 100 --new -l 250 -f 392 -D 100 --new -l 25 -f 392 -D 100 --new -l 350 -f 784 -D 100 --new -l 250 -f 739.98 -D 100 --new -l 25 -f 698.46 -D 100 --new -l 25 -f 659.26 -D 100 --new -l 25 -f 622.26 -D 100 --new -l 50 -f 659.26 -D 400 --new -l 25 -f 415.3 -D 200 --new -l 350 -f 554.36 -D 100 --new -l 250 -f 523.25 -D 100 --new -l 25 -f 493.88 -D 100 --new -l 25 -f 466.16 -D 100 --new -l 25 -f 440 -D 100 --new -l 50 -f 466.16 -D 400 --new -l 25 -f 311.13 -D 200 --new -l 350 -f 369

gtrias

Every so often I have to restore my gpg keys and I'm never sure how best to do it. So, I've spent some time playing around with the various ways to export/import (backup/restore) keys.

Method 1

Backup the public and secret keyrings and trust database

cp ~/.gnupg/pubring.gpg /path/to/backups/
cp ~/.gnupg/secring.gpg /path/to/backups/
cp ~/.gnupg/trustdb.gpg /path/to/backups/

or, instead of backing up trustdb...

gtrias

• With Docker 1.8.0 shipped new log-driver for GELF via UDP, this means that the logs from Docker Container(s) can be shipped directly to the ELK stack for further analysis.
• This tutorial will illustrate how to use the GELF log-driver with Docker engine.
• Step 1: Setup ELK Stack:
  • docker run -d --name es elasticsearch
  • docker run -d --name logstash --link es:elasticsearch logstash -v /tmp/logstash.conf:/config-dir/logstash.conf logstash logstash -f /config-dir/logstash.conf
  • Note the config for Logstash can be found at this link
  • docker run --link es:elasticsearch -d kibana
• Once the ELK stack is up now let's fire up our nginx container which ships its logs to ELK stack.

• LOGSTASH_ADDRESS=$(docker inspect --format '{{ .NetworkSettings.IPAddress }}' logstash)
• `docker run -d --net=host --log-driver=gelf --log-opt gelf-address=u

gtrias

Basic RESTful API with Symfony 2 + FOSRestBundle (JSON format only) + FOSUserBundle + FOSOauthServerBundle

The API we are creating in this gist will follow these rules :

• The API only returns JSON responses
• All API routes require authentication
• Authentication is handled via OAuth2 with password Grant Type only (no need for Authorization pages and such).
• API versioning is managed via a subdomain (e.g. v1.api.example.com)

The API will be written in PHP with the Symfony 2 framework. The following SF2 bundles are used :

gtrias

<?php                                                                                                                                                                                                              

use Symfony\Component\HttpKernel\Kernel;
use Symfony\Component\Config\Loader\LoaderInterface;

class AppKernel extends Kernel
{
    public function registerBundles()
    {   
        return array(

gtrias

#Meteor and Self-hosted Infrastructure

Meteor is an eye-opening JavaScript framework that runs on both the client and the server, giving developers a revolutionary take on software engineering. If you are not familiar with Meteor, I urge you to visit their website.

##An overview

In this brief gist, I am going to discuss the process of setting up a server (in my case, a VPS) to host Meteor applications.

My experience with Meteor has been brief, however it has not taken much demonstration for me to realise the significance of this stellar framework. Let's jump right in!