fknappe

Signing VirtualBox & VMware modules

Source

Creating a key

You can change "MOK".priv/.der to any desired name; "CN=" MUST hold your username, signing the modules may not work otherwise (on shim, possibly due to a bug).

$ openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=John Doe/"

fknappe

Signing VirtualBox Kernel Modules

These are the steps I followed enable VirtualBox on my laptop without disabling UEFI Secure Boot. They're nearly identical to the process described on [Øyvind Stegard's blog][blog], save for a few key details. The images here are borrowed from the [Systemtap UEFI Secure Boot Wiki][systemtap].

1. Install the VirtualBox package (this might be different for your platform).

   src='https://download.virtualbox.org/virtualbox/rpm/fedora/virtualbox.repo'

fknappe

require "active_record"

namespace :db do

  db_config       = YAML::load(File.open('config/database.yml'))
  db_config_admin = db_config.merge({'database' => 'postgres', 'schema_search_path' => 'public'})

  desc "Create the database"
  task :create do
    ActiveRecord::Base.establish_connection(db_config_admin)

fknappe

import org.eclipse.paho.client.mqttv3.MqttCallback;
import org.eclipse.paho.client.mqttv3.MqttClient;
import org.eclipse.paho.client.mqttv3.MqttConnectOptions;
import org.eclipse.paho.client.mqttv3.MqttDeliveryToken;
import org.eclipse.paho.client.mqttv3.MqttException;
import org.eclipse.paho.client.mqttv3.MqttMessage;
import org.eclipse.paho.client.mqttv3.MqttTopic;

public class SimpleMqttClient implements MqttCallback {

fknappe

Getting Started with NPM (as a developer)

If you haven't already set your NPM author info, now you should:

npm set init.author.name "Your Name"
npm set init.author.email "you@example.com"
npm set init.author.url "http://yourblog.com"

npm adduser

fknappe

Models, Roles, Decorators, and Interactions

A modest alternative to DCI that might be worth further thought

One of the problems with advancing the discussion on DCI is that we lack a comparable alternative pattern that has the same goals, but favors a low ceremony approach. The closest thing we have to that is Rails concerns, but they are more like distant relatives of the DCI concepts rather than first cousins, and that makes comparisions between the two approaches not especially fruitful.

I am considering the idea of experimenting with my own paradigm that captures the intent and purity of DCI, but with the convenience of concerns. Please note that this is just the starting point of a conversation, it is NOT a promise of comercially available cold fusion or a cure for cancer. It's just a gist with an idea on it I'd like to hear your thoughts on.

What if we had a top-level topology that was split into Models, **Rol

fknappe

# Expand print panel by default
defaults write NSGlobalDomain PMPrintingExpandedStateForPrint -bool true

# Disable the “Are you sure you want to open this application?” dialog
defaults write com.apple.LaunchServices LSQuarantine -bool false

# Enable subpixel font rendering on non-Apple LCDs
defaults write NSGlobalDomain AppleFontSmoothing -int 2

# Disable press-and-hold for keys in favor of key repeat

fknappe

OS X Shortcuts References

Clipboard

⌘ + C - Copy a text to clipboard

⌘ + V - Paste a text copied to clipboard

All Applications

fknappe

#!/usr/bin/env sh

##
# This is script with usefull tips taken from:
#   https://github.com/mathiasbynens/dotfiles/blob/master/.osx
#
# install it:
#   curl -sL https://raw.github.com/gist/2108403/hack.sh | sh
#

fknappe

RSpec Intro

RSpec is a testing framework widely used along Ruby projects. Its paradigm is contained within the Behavior Driven Development (BDD) context, so it can be used to define internals and externals aspects of Ruby web applications. However, most developers see its major use for unit testing within the BDD context.

##Philosophy

• Clarity X Cleverness

Always regard clarity over cleverness in your specs. This approach is based on the fact that, when you practice Test-Driven, you should make clear what are the intentions of the code that you are writing not just for you, but for others that are collaborating on the same project. Besides, a clear spec contributes as a documentation of the internals aspects of the project.