railsbridge-boston / railsbridge-vm

Vagrant provisioning for the RailsBridge VM

We've moved repos!

We are no longer using this repo! If you're looking to contribute, please check out the separate website and curriculum repos.

railsbridge-boston

This was the website for the RailsBridge Boston Workshop for women and their friends.

railsbridge-vm's Issues

end-user setup instructions missing

http://www.railsbridgeboston.org/vm_setup results in "File not found: /vm_setup"

Brainstorming prompt visibility/consistency

A common point of confusion for newbies when using a terminal/shell is knowing what program they're actually using/typing at. We have:

• Shell on student's computer
  • The vagrant ssh command
    • Shell in the VM
      • IRB
      • rails in various modes

We've got the VM shell prompt in one color set (green/blue) and the IRB prompt/return values in another (red/cyan). I think the most common error I saw was students starting rails server and then typing shell commands into that process. Just coloring the entire Rails log something else could help. Is this possible without too much config complexity?

Really, for anything where the student is typing a command or expression, coloring that input line would also be nice, to distinguish input/output. I've never messed with this in my own environments. But anything we color has to be bold because non-bold was in practice unreadable for a number of Windows-using students, so our palette is limited.

For the shell in the VM, we can stub out commands. For ex, one of my test subjects typed "vagrant halt" in their VM shell without exiting (which results in command-not-found), so I added a vagrant help script that reminds you you're in the VM. Other scripts could be added. For IRB, maybe we could define some stub functions but that probably gets hairy quick.

Another issue: rails server instructs you to quit it with Ctrl-C (and you have to use this; it doesn't read input). In several places, we instruct the student to quit the shell by using the command exit. Would it improve consistency to exit both the shell and IRB with Ctrl-D? (I can't remember the last time I typed out "exit", but that doesn't mean sending EOF is better. Some students may not be accustomed to using any shortcut keys in any apps).

This is one of those things where you have to weigh the benefit of fundamentals (what is EOF, what is a signal, what is a control character, etc) against the time they take away from actual Rails instruction, so... I dunno. I am more knowledgeable about the Unixy stuff but less knowledgeable about Rails.

Fix the bind-address problem with an app template instead of on the `rails server` command

I want to get some feedback for this before PRing it, because we will need to remove all references to -b 0.0.0.0 in the instructions and update the curriculum. (For more details on the networking nitty-gritty: https://www.virtualbox.org/manual/ch09.html)

Having to specify the bind address every time you run rails server is hard on students. If we drop this file in the vagrant user's home directory:

https://github.com/railsbridge-boston/railsbridge-vm/compare/virtualbox-listen-template

Then you only have to provide an option to rails new, which most students will run only once:

http://guides.rubyonrails.org/rails_application_templates.html#usage

(in our case, rails new suggestotron -m ~/vm.rb)

This is a standard Rails thing (see, that's an official guide page there. And our use case looks like the first thing in the guide). I think that is better than including a nonstandard script that hides rails server and adds an option for you, or doing something with an untenable ongoing maintenance burden like monkeypatching rails or wrapping its entire cli.

Students are hopefully too busy writing and learning code to truly grok what any of these obscure options to rails subcommands mean, so we should try to minimize the harm done if they keep going later by copying and pasting the thing that worked at the workshop. Running with -b 0.0.0.0 outside a VM in a coffeeshop is dangerous; running rails new -m sometemplatethatdoesntexist.rb will just fail.

To worry about: it's not clear to me if this is a spectacularly bad idea, from a security perspective, to leave in the app when it is deployed to Heroku. It would be really nice if we could set it in the development environment config only, but my understanding of the order in which things are loaded is boot.rb first, then the Rails::Server is initialized, then environment stuff. From looking at several versions of this fix on Stack Overflow it seems like it has to happen at boot.rb time.

Consider purging Python/X11 deps

Removing landscape-client doesn't marked Twisted Python and dependencies for autoremoval. We'd have to list them manually.

This only saves about 8MiB for me, though, so it doesn't feel worth the complexity.

Remove protected_attributes gem since the curriculum uses Rails 4.0

Rails 4.0 does not use attr_accessible.

The code is in provision-user-install.sh.

Consider not having students install Vagrant (build a plain VM)

Currently, students log into the VM using vagrant ssh. This means:

1. They have to install Vagrant (100MiB+ download, requires a reboot on Windows)
2. They have to be able to find/operate their native OS's terminal (Macs generally have a functional one, Windows not so much, both in the actual terminal emulation department and the environment's lack of bash/ssh out of the box)

Most students (but not all! It's important to me to make programming more accessible to sysadmins, for instance) are not familiar with operating their OS's terminal at all, so this is a speed bump to learning.

Instead, we could consider building a non-Vagrant VM image, where students install VirtualBox and then start the VM within VirtualBox, getting a virtual display. A couple students had to do this at the 2014-01 workshop because of unfixably broken native terminals. This means they got an old-school 80x25 console display, IIRC. Not very usable, no copy/paste integration.

So, we could build something that was meant to be used that way. This would mean:

• Building a non-Vagrant image (removing customization, /vagrant, the vagrant user, repackaging as a .vdi file (or whichever format is preferred these days - Vagrant abstracts this away from me))
• Adding a user account (no security needed, so railsbridge/railsbridge is fine) and a GUI. The full GUI that you get when doing a Ubuntu 14.04 install is probably huge, so maybe look at lightweight alternatives. GNOME is preferable because copy/paste probably Just Works, but may be too heavy (not everyone can afford a fast/unmetered home internet connection).

What would still need to be set up if we just ship a VDI:

• Port forwarding on port 3000
• A shared folder

It's possible to have students set this up in the VirtualBox GUI during the Installfest with the time saved not installing Vagrant/finding their terminal, but it's going to be error-prone. Maybe one of those VirtualBox formats is some kind of config file wrapped up with the disk image?

If this works, they'd boot the VM from VirtualBox, go right into the GUI, and have a gnome-terminal (or, worst case, xterm) facing them, so they only have to learn how to use that terminal, which is much more clearly "in the box".

I don't know. Let's think about it after 2014-05? I'll shed a tear for the local command line, but I'm willing to put in the work.

Use zerofree

Ubuntu now includes a utility for zeroing out blocks in a more intelligent way than dding a huge empty file:

http://manpages.ubuntu.com/manpages/trusty/man8/zerofree.8.html

Figure out how to do this as part of the setup (requires that the filesystem is mounted ro), and see if it actually makes the image more compact.

Rails 4.2, Ruby 2.2

If we're going to be using the upstream curriculum, looks like it's expecting Rails 4.1: http://docs.railsbridge.org/installfest/create_a_rails_app

Comment here with any problems using 4.1. (I guess this is not a huge deal for September if we're focusing on Ruby?)

Git commit message editor confusion

This is an issue we discussed and proposed a solution for way back. But it could be relevant to the new VM and curriculum.

railsbridge-boston/railsbridge-boston#122

Proposed solution affects git config's core.editor variable:

https://gist.github.com/danchoi/6874170

@gabebw

Vagrant >=1.6 deals poorly with progress bar output

Hopefully this will be fixed in newer versions of Vagrant, but as of 1.6.1, the provisioner logs every write to stdout/stderr on a new line, even if a program was printing a line (like a progress bar) character-by-character. This looks especially bad for wget because it defaults to the "dot" progressbar when connected to a non-TTY and prints a "." for each 1K downloaded. This will overwhelm many people's scrollback and it's a good idea to always review the entire provision log.

If you want to work around it for now, use the change in https://github.com/railsbridge-boston/railsbridge-vm/compare/wgetrc . This just makes the dots represent 1M instead of 1K, so there are fewer of them.

In the meantime, remember to use curl -s.

Don't use a fork of chruby

If postmodern/chruby#268 is merged, and a new stable version of chruby is tagged, we can download it instead. Tags don't change, so it's safe to point at the upstream version.

For posterity: we also forked ruby-install, but now that 2.0.0p481 is out and fixes building against libreadline6 (which Ubuntu ships, having renamed readline 5 to libreadline-gplv2 or something for annoying GPL reasons), we can have chruby download upstream ruby-install.

Can we pre-install some of bundle?

It would be nice if some of the gems that rails new's initial bundle install were cached locally or just preinstalled in the VM. rails itself and all its deps are already installed, this is just the additional stuff. Should reduce time for students to get to a running app.