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/"
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].
src='https://download.virtualbox.org/virtualbox/rpm/fedora/virtualbox.repo'
| 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) |
| 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 { |
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 "[email protected]"
npm set init.author.url "http://yourblog.com"
npm adduser
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
| # 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 |
| #!/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 | |
| # |
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
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.