Data directories are created in /home/coreos and mounted into the container using volume cli options of docker run. All data the container writes is stored on the host and as long as the host persists safe against container restarts / recreates.
Last night, Brian Shirai unilaterally "ended" the RubySpec project, a sub-project of Rubinius (the alternative Ruby implementation which Brian was paid to work on full-time from 2007 to 2013). The blog post describing his reasons for "ending" the project led to a big discussion on Hacker News.
When a single, competing Ruby implementation tells that you its test suite is the One True Way, you should be skeptical. Charles Nutter, Ruby core committer and JRuby head honcho, spent a lot of time last night on Twitter talking to people about what this decision means. He's probably too busy and certainly too nice of a guy to write about what is a political issue in the Ruby community, so I'm going to do it on behalf of all the new or intermediate Rubyists out there that are confused by Brian's decision and what it me
NOTE: this is out of date - refer to moby/moby#9694
Here is a preview build of two new features we’re working on concurrently: container grouping (docker groups) and stack composition (docker up). Together, they will eventually form a complete replacement for Fig.
Hello,
Over the past months I've been thinking on ways to improve current RubyInstaller experience for users -- including DevKit -- aiming to make it more Windows-friendly.
While RubyInstaller in its current form has fulfilled my personal needs, I acknowledge that, for newcomers or Windows-centric developers, its usage is problematic and sometimes cryptic.
Below are the common list of complaints I often hear (via Twitter rants,
I've been using a lot of Ansible lately and while almost everything has been great, finding a clean way to implement ansible-vault wasn't immediately apparent.
What I decided on was the following: put your secret information into a vars file, reference that vars file from your task, and encrypt the whole vars file using ansible-vault encrypt.
Let's use an example: You're writing an Ansible role and want to encrypt the spoiler for the movie Aliens.
| source 'https://rubygems.org' | |
| gem 'rake' | |
| gem 'lotus-router' | |
| gem 'lotus-controller' | |
| gem 'lotus-view' | |
| group :test do | |
| gem 'rspec' | |
| gem 'capybara' |
| group :production do | |
| gem 'unicorn' | |
| # Enable gzip compression on heroku, but don't compress images. | |
| gem 'heroku-deflater' | |
| # Heroku injects it if it's not in there already | |
| gem 'rails_12factor' | |
| end |
Intention revealing method is simple and yet I see it frequently slip through programmers' code. Developers don't like lengthy methods, or find it inconvenient to read through chubby if-else branches, and if they are nice enough they'll leave comments like those.
If we change spaces by underscores in the comments, delete the comment characters, and define the resulting methods in the same file (as private helpers for example), we get code that explains itself, instead of through verbose long methods, or human code comments which get stale.
Intention revealing methods is the most basic, no brain-teaser, easiest rule that I know. Combine it with Sandi Metz's rule of a maximum of 5 lines per method and you'll get simple code that explains itself, that is a pleasure to read, improving communication and productivity of the team (even when it's only yourself).
| # Public: A module to be mixed in another class with common methods to index | |
| # records in ElasticSearch. | |
| # | |
| # The host object needs to respond to 'indexed_attributes', which will return | |
| # an array of the attributes names to be indexed. | |
| # | |
| # It's also recommended to override the 'save?' method to make sure only | |
| # records that match some specifications are indexed. | |
| # | |
| # The type used for the ElasticSearch index will be extracted from the name of |
