angelamancini

# Before running this script, go to Quiver and export all notebooks into json/quiver format
# Place them in a folder called `exports` in the same directory as this script.
# In terminal, run `ruby quiver-to-evernote.rb`
# Check for presence of required gems.
# If not present, install the gems
["rubygems", "sanitize"].each do |gem|
  begin
    gem "#{gem}"
  rescue Gem::LoadError
    `gem install #{gem}`

kitschysynq

ps -ef | awk -e '/qemu/ && !/awk/' | sed -e 's/[^/]*//' -e 's/ -/\n\t-/g'

xpepper

When you do your first Sonar run on your project, you get a lot of new quality numbers to play with, but no trends. You only have one data set for comparison, the now picture.

Wouldn't it be nice if you could see the current trend of the project without waiting a couple of month for the 'daily/weekly' Sonar runs to fill up the data? Well, you're in luck! And if you're using git as a version system as well, this is your day. :)

In the Sonar Advanced Parameter documentation you will find a System Property called sonar.projectDate. The property let you tell Sonar when in time the running analysis was ran.

By combining this property and what your version system does best, track changes to source, we can now play back the history of the project as far as Sonar is concerned.

This little Bash script illustrates the concept. To spell out what it does in human readable form:

smford22

name 'base_linux'
description 'A base role to be applied to all linux nodes'
run_list 'recipe[chef-client::default]','recipe[chef-client::delete_validation]','recipe[audit::default]'
default_attributes({
  'audit' => {
    'reporter' => 'chef-server-automate',
    'fetcher' => 'chef-server',
    'profiles' => [
      {
        'name' => 'linux-patch-baseline',

JCotton1123

knife search node '*' -a chef_packages.chef.version | grep "chef_packages.chef.version" | cut -d" " -f4 | sort | uniq

smford22

name 'base_windows'
description 'A base role for all windows nodes'
run_list 'recipe[chef-client::default]','recipe[chef-client::delete_validation','recipe[audit::default]'
default_attributes({
  'audit' => {
    'reporter' => 'chef-server-automate',
    'fetcher' => 'chef-server',
    'profiles' => [
      {
        'name' => 'windows-patch-baseline',

jphenow

#!/usr/bin/env ruby
# Go to emoji customization page on your Slack org
# download the html for that page
# Also need "nokogiri" installed
#
# Usage: scrape <htmlfile>
require 'nokogiri'
require 'open-uri'

file = ARGV[0]

stevenringo

Sessions

Code	Title	Duration	Link
Keynote	Andy Jassy Keynote Announcement Recap	0:01	https://www.youtube.com/watch?v=TZCxKAM2GtQ
Keynote	AWS re:Invent 2016 Keynote: Andy Jassy	2:22	https://www.youtube.com/watch?v=8RrbUyw9uSg
Keynote	AWS re:Invent 2016 Keynote: Werner Vogels	2:16	https://www.youtube.com/watch?v=ZDScBNahsL4
Keynote	[Tuesday Night Live with Jame

hallettj

# Makefile for transpiling with Babel in a Node app, or in a client- or
# server-side shared library.

.PHONY: all clean

# Install `babel-cli` in a project to get the transpiler.
babel := node_modules/.bin/babel

# Identify modules to be transpiled by recursively searching the `src/`
# directory.

lamont-granquist

Notifications from Resources "Bubble Up"

Release in Chef 12.9.41 via PR #4741 core chef now has a feature which has been available in Poise for awhile, which is that notifications from within resources will now notify resources in outer run contexts. This means you can write a recipe with a service resource and send a notification to it from a resource that you write.

Notifications will bubble up from arbitrarily nested resources, so users that write resources that wrap resources which wrap your resource will still find the service resource in your default recipe.

At the same time the resources collection #find() and #lookup methods and the more commonly-used DSL method resources("service[ntpd]") has been changed to also match