| root@ubuntu:/var/log# irb | |
| irb(main):002:0> require 'rubygems' | |
| => true | |
| irb(main):003:0> require 'yajl/yajl' | |
| LoadError: no such file to load -- yajl/yajl | |
| from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' | |
| from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require' | |
| from (irb):3 | |
| from :0 | |
| irb(main):005:0> root@ubuntu:/var/log# gem list |
| NEWUSER=chef | |
| sudo useradd -m ${NEWUSER} -s /bin/bash | |
| cat /etc/group | sed "s/^\(admin:.*\)/\1,${NEWUSER}/" > /tmp/group && sudo mv /tmp/group /etc/ | |
| sudo apt-get update | |
| sudo apt-get install -y git-core | |
| sudo su - ${NEWUSER} -c "git clone https://github.com/pikesley/catering-college ; cd catering-college ; ./install-chef-server" |
| node['amee_projects'].each do |a| | |
| user = data_bag_item(:amee_projects, a['project-owner']) | |
| execute "install rvm for #{user['id']}" do | |
| command "sudo su - #{user['id']} -c 'curl -L get.rvm.io | bash -s stable'" | |
| end | |
| execute "install ruby #{user['ruby']} for #{user['id']}" do | |
| command "sudo su - #{user['id']} -c 'rvm install #{user['ruby']}'" | |
| end |
| #!/usr/bin/env ruby | |
| @@scores = { | |
| "a" => 1, "b" => 2, "c" => 3, "d" => 4, "e" => 5, "f" => 6, "g" => 7, "h" => 8, "i" => 9, "j" => 10, "k" => 11, "l" => 12, "m" => 13, "n" => 14, | |
| "o" => 15, "p" => 16, "q" => 17, "r" => 18, "s" => 19, "t" => 20, "u" => 21, | |
| "v" => 22, "w" => 23, "x" => 24, "y" => 25, "z" => 26 | |
| } | |
| class Fruit | |
| attr_reader :score |
You know what would make cucumber-chef even more SUPERAWESOME? Support for Chef environments. I've tried (oh, how I've tried) to put support for this directly into the code, but chef_environments are apparently not like other attributes, so until I can work that out, here's a compromise solution.
Note: I lifted the stuff inside the step_definition pretty much directly from Jon Cowie's excellent knife-flip plugin. Thanks Jon :)
At AMEE, we've been using Sendgrid (to take care of delivering email) and KissMetrics (to help us understand in detail how our apps are used) for a while now (we'd never be able to deliver the same level of service internally as they can, and they get better for free), but as is often the case when working with disparate third party services, they don't always work together how you want.
One of the reasons we use these two services however, is that they provide a rich enough API to combine them to plug gaps like we mentioned above.
For example, we use Sendgrid for transactional email, and it does a sterling job when it comes to actually making sure email ends up in the right inbox. But if we wanted to see what a user did with an email it had arrived, and log that for analysis later, we could't find a simple way to do this.
Likewise with KissMetrics - it's straightforward enough to create a libary of events in the browser to log, that you can then combine in groups to build reports on how well a certain
In my spare time, I've recently been working with a few codebases that either are written in, or use enough code written nodejs, that make me keen to have some kind of testing framework in place to help put the same kinds of safety nets in place that I'm used to working with on Chef, Sinatra or Rails projects.
After losing a couple of weekends to trying to find an approach to BDD style development with node, and getting my head around asynchronous coding concepts, I think I've settled on an approach that feels enough like rspec to feel comfortable enough to use for future serverside js development.
It's way too much for a single post, to I'll be sharing the first of a three part series of posts, to help other Ruby developers used to synchronous development with rspec, adjust to asynchronous development, with the closest thing I can find to rspec right now, mocha.
I'll cover how Mocha syntax compares to rspec, then I'll cover implementing the code to pass these mocha specs, then I'll add a post to help keep
In my spare time, I've recently been working with a few codebases that either are written in, or use enough code written in, nodejs, that make me keen to have some kind of testing framework in place to help put the same kinds of safety nets in place that I'm used to working with on Chef, Sinatra or Rails projects.
After losing a couple of weekends to trying to find an approach to BDD style development with node, and getting my head around asynchronous coding concepts, I think I've settled on an approach that feels enough like rspec to feel comfortable enough to use for future serverside js development.
It's way too much for a single post, so I'll be sharing the first of a three part series of posts, to help other Ruby developers used to synchronous development with rspec, adjust to asynchronous development, with the closest thing I can find to rspec right now, mocha.
I'll cover how Mocha syntax compares to rspec, then I'll cover implementing the code to pass these mocha specs, then I'll add a post to help
| mkdir cuke-chef | |
| cd cuke-chef/ | |
| rvm gemset create cuke-chef | |
| rvm gemset use cuke-chef | |
| rvm rvmrc create | |
| git init | |
| git add * | |
| git commit -a -m 'just a rvmrc for now' | |
| mkdir github-gems | |
| cd github-gems/ |
| For one of my cookbooks, when I bootstrap a new node (on Rackspace, against my Chef 11 server), the templates do not make it to the node and the chef-client run craps out (see below). However if I then jump on the node and run chef-client by hand, the templates *do* make it and the run completes without a hitch. | |
| Does this sound familiar to anybody? It feels like I must be doing something dumb... | |
| It might be worth noting that this all works correctly on my cucumber-chef setup (which is Chef 10). |
