Actually, this already works using VirtualBox’s NAT networking mode in your guest. What doesn’t work is resolving domain names from the guest that are only known in the VPN network.
So if you have a a domain like w3.mycompany.com that only resolves using the VPN’s DNS, you can resolve that name from your host (which is connected to the VPN), but not from your guest by default. You won’t be able to ping w3.mycompany.com from the guest. However, if you try to ping the IP address from your guest, that works.
To solve this, VirtualBox has a nice feature to allow you to set the Host DNS resolver as the DNS proxy of a VirtualBox VM. To configure this, you first need to figure out the id of your VirtualBox VM:
$ VBoxManage list vms
Note that uuid of your VM and then:
$ VBoxManage modifyvm <uuid here> --natdnshostresolver1 on
Now try to ping that VPN domain name again from your rebooted guest. Works!
“Code is read many more times than it is written. Abstractions add
changeability but increase cognitive load. The ones that are actually
needed save money, those that aren’t increase costs every time anyone
looks at the code.
Anticipatory complexity rarely pays off. Unless your Magic 8-Ball is far
better than mine you should avoid the guessing business. Guessing right
half of the time means guessing wrong the other half, and the code for
wrong guesses confuses everyone who follows. The barrier to
introducing a speculative abstraction is very high.
This is where the Open/Closed Principle (OCP) comes in handy. OCP is
one of the core object-oriented design principles. It provides both the ‘O’
in ‘SOLID’ and guidance about when to create an abstraction.
Open/Closed requires that you write code that is open to the next
change but it says nothing about when to do so. It doesn’t require that
you guess the future, instead it tells you to write the simplest conceivable
code today and then to remove your hands from the keyboard and wait.
Future change requests will tell you exactly how you should have
arranged the code you have.
When new requests arrive, you’ll rearrange existing code so that you
can extend it with new behavior. It’s a two step process, first you refactor
existing code to a more felicitous arrangement and then you write new
code to implement the change. Kent Beck says it best (but I’ll paraphrase
anyway): ‘Make the change easy … then make the easy change.’” — Sandi Metz
I recommend reading the whole post, but above is the core of the apple explaining in a new way why YAGNI is a practice that makes good business sense, but also why it needs to be used hand-in-hand with code refactoring practices.
Released on github
Prepends a blurb of text to any files you specify while respecting a list of includes and exclude patterns for maximum flexibility.
Add this line to your application’s Gemfile:
And then execute:
Or install it yourself as:
$ sudo gem install stamper
$ stamper --help
Usage: stamper -s STAMPFILE [options]
Prepends a blurb of text to any files you specify
while respecting a list of includes and exclude
patterns for maximum flexibility.
-s, --stamp STAMPFILE
Read the stamp from the specified file.
-p, --path DIRECTORY
Directory to scan for files. Defaults to current directory.
-i, --include 'REGEXP'
Only stamp files that match this pattern.
Can be used multiple times. Defaults to [".*\\.rb$"].
-e, --exclude 'REGEXP'
Do not stamp files that match this pattern.
Can be used multiple times.
Evaluated after includes. Defaults to ["^vendor/"].
-r, --respect 'REGEXP'
If the first line in the file matches this pattern,
place stamp under that line.
Can be used multiple times. Defaults to ["^#", "^<!"].
Report which files need stamping, but don't make
Do not print any output.
Show this message.
--respect option is nice for telling Stamper to leave any first
magic-encoding lines untouched and unmoved. The stamp will be placed under the
matching line. Will only respect the first line, however, if matched.
Hint: You may want to try a few runs with the
--dry-run option on to see what it is doing,
until you get all the options you want right.
# This is a glob. Will be fed into Dir.glob()
# Defaults to ['.*\.rb$']
# Defaults to ['^vendor/']
# Defaults to ['^#', '^<!'']
A PaaS that leverages Ruby on Rails and Docker. It implements a Heroku-like interface, with an API-first approach.
This issue affects VirtualBox VMs running with host-only networking. It prevents the host from reaching the VMs in the host-only network.
Turns out that the Cisco VPN, which I use on the Mac, adds a firewall rule that blocks traffic not going through its tunnel. To disable it, you first have to find the offending rule using ipfw, then delete the rule by its id.
Afterwards, you have to edit your routing table to get the proper traffic going to the vboxnet interface.
All this seemed kind of tedious, which is why I created a script that does it for me:
Watch out for this problem. On version 0.23.0, the Rubocop constant was renamed to RuboCop (camelcase).
See the commit for details.
A 2008 paper from the Lawrence Berkeley National Laboratory suggests it takes 13kWh to transmit 1GB.[…] According to EPA figures, the average U.S. power plant emits 1.2 pounds of carbon dioxide equivalent (called CO2e) per kWh produced. If we multiply 13kWh by 1.2 pounds, we get 15.6 pounds of CO2e—and that’s just to transfer 1GB of data. […] But these numbers do give us a framework for seeing the relationship between page size and carbon footprint—and make it clear that cutting gigabytes saves CO2.
The first place to start trimming? In our designs.
That’s why I am concerned by right-sounding technical demands for zero bug tolerance. This isn’t a technical decision that can be made by developers or testers or project managers…or consultants. It’s bigger than all of them. It’s not just a technical decision – it’s also a business decision.
From Zero Bug Tolerance Intolerance
Great post on why a zero bug attitude does not make business sense and why you need to be very selective about which bugs you fix in your project.