First thoughts on our new wsu.edu

Today we launched a gorgeous new home page at WSU. For the most part everything went as planned and definitely without catastrophe. We’ll have a full stack write-up at some point soon on web.wsu.edu with more details (still a few more things to launch), but I’ve had a few thoughts throughout the day that I wanted to note.

Screen Shot 2015-03-24 at 11.24.01 PMWe’re HTTPS only. And that’s pretty freaking cool. It was a year ago today that we flipped the switch on WSU News to SPDY and ever since then I couldn’t wait to get the root domain. I had anticipated some push-back, though I don’t know why, and we haven’t heard a peep. I plan on running a script through a massive list of public university websites to see how many do this. Many don’t even support TLS on the home page, let alone force it.

Screen Shot 2015-03-24 at 11.28.24 PM

Our root domain is on WordPress. Typing that address in for the first time today after everything went live felt really, really cool. I don’t think that feeling is going to wear off. Even though this is site ~600 to launch on our platform, it’s a huge statement that the University is behind us on this. I don’t remember all of our conversations, but I don’t think that having the root on WordPress was really on our radar for the first 2 years. Dig it.

We’re pretty damn fast. That’s become a lot easier these days. But we have a lot of content on the home page—and a really big map—and we still serve the document to the browser super quickly. I actually screwed up pretty big here by microcaching with Nginx at the last minute. It made things even faster, but cached a bad redirect for quite a while. Lessons learned, and we’ll keep tweaking—especially with image optimization, but I love that we went out the gate with such a good looking waterfall.

And as I stormed earlier in my series of “I heart GPL” tweets, every part of our central web is open source. We publish our server provisioning, our WordPress multi-network setup, our brand framework, our themes, and our plugins. 134 repositories and counting. Not everything is pretty enough or documented enough, and will often serve more as an example than as a product. But, everything is out there and we’re sharing and doing our best to talk about it more.

Lots of this makes me happy. More to come! :)

Wired on Drone Geo-Fencing

“This is NOT something users want,” another critic added. “I have a good relationship with my local airports and have worked with every local tower or control center. I get clearance to fly and they have been great, but this ‘update’ takes away my control.

”Ryan Calo, a University of Washingtonlaw professor who studies robots and the law, traces the resistance to two sources. “One is a complaint about restricting innovation. The second one says you should own your own stuff, and it’s a liberty issue: corporate verses individual control and autonomy,” Calo says. “When I purchase something I own it, and when someone else controls what I own, it will be serving someone else’s interest, not mine.”

Source: Why the US Government Is Terrified of Hobbyist Drones | WIRED

Intersections of technology and government regulation are interesting.

When a piece of technology is so small and cheap, it’s easy to apply personal ideas of how you should be able to interact with it. At some level it make sense to compare geo-fence restrictions on drones to DRM on e-books. But really, it’s not the same concept at all.

When something is large and expensive, such as a private plane, then it’s probably easier to agree with (and understand) restrictions on where you can use it. The same thing applies to cars—just because I own a vehicle doesn’t mean I can drive it down a one way street or onto private property without consequence.

Academic publishing and scholarly communication: a status report | Harvard Magazine Jan-Feb 2015

That price pressure from commercial journal publishers highlights the core conundrum of academic publishing: the conflict between the scholarly ideal of universal, open sharing of information, and the economic model of business: to make money by selling things.

Source: Academic publishing and scholarly communication: a status report | Harvard Magazine Jan-Feb 2015

Various Networking Configurations in VVV

I dug in to some different configurations in VVV today and decided to write them up as I went. This will be posted in some form to the VVV wiki as well. There are other networking configurations available in Vagrant, though I’m not sure that any would be useful in development with VVV.

I would recommend using default settings for initial provisioning as things can get quirky inside the VM when trying to access outside sources. Run vagrant reload to process any network configuration changes.

Private Network (default)

config.vm.network :private_network, ip: “192.168.50.4”

This is the default configuration provided in VVV. A private network is created by VirtualBox between your host machine and the guest machine. The guest is assigned an IP address of 192.168.50.4 and your host machine is able to access it on that IP. VVV is configured to provide access to several default domains on this IP address so that browser requests from your host machine just work.

Outside access from other devices to this IP address is not available as the network interface is private to your machine.

Port Forwarding

config.vm.network “forwarded_port”, guest: 80, host: 8080

One option to provide other devices access to your guest machine is port forwarding. Uncommenting or adding this line in VVV’s Vagrantfile and then running vagrant reload will cause any traffic on port 8080 directed at your host machine to instead communicate with port 80 on the guest machine.

This configuration will work with private or public IP configurations as it deals with port forwarding rather than the IP of the virtual machine itself.

An immediate way to test this once configured would be to type your host machine’s IP address into a browser followed by :8080. With port forwarding enabled, something like http://192.168.1.119:8080 would bring up the default VVV dashboard.

Of course, this doesn’t do you much good with the default WordPress sites, as you’ll be stuck adding port 8080 to every request you make.

The easiest hack around this is to setup port forwarding on your router. Point incoming requests for port 80 to port 8080 on the IP address of your host machine. Requests through the router will then traverse ports 80 (public IP) -> 8080 (host) -> 80 (guest) and your development work can be shared with devices inside and outside of your network.

Say my router’s public IP is 14.15.16.17 and my computer’s local IP is 192.168.1.100.

  • Enable port forwarding in Vagrantfile.
  • Configure router to forward incoming port 80 to port 8080 on 192.168.1.100.
  • Visit src.wordpress-develop.14.15.16.17.xip.io on my phone, connected through LTE.

There are other things you can do on your local machine to reroute traffic from 80 to 8080 so that it forwards properly without the use of a router. Sal Ferrallelo has posted steps to take advantage of port forwarding directly in OSX using pfctl.

Public Network

config.vm.network “public_network”

Replacing our default private network configuration with a public network configuration immediately provides access to other devices on your local network. Using this configuration without specifying an IP address causes the guest machine to request an address dynamically from an available DHCP server—likely your router. During vagrant up, an option may be presented to choose which interface should be bridged. I chose my AirPort interface as that is what my local machine is using.

==> default: Available bridged network interfaces:
1) en0: Wi-Fi (AirPort)
2) en1: Thunderbolt 1
3) p2p0
4) bridge0
5) vnic0
6) vnic1
    default: What interface should the network bridge to? 1

Once the guest machine receives an IP address, access is immediately available to other devices on the network.

  • vagrant ssh and type ifconfig to determine the IP address of the guest – mine was 192.168.1.141.
  • Visit src.wordpress-develop.192.168.1.141.xip.io on my phone, connected to the wireless network.

To me this is most desirable as it provides access to devices on the local network, not to the outside. If you are using public wifi or another insecure network, be aware–this does open your machine up to other devices on that network.

config.vm.network “public_network”, ip: “192.168.1.141”

The same configuration would be available without DHCP by specifying the IP address to use. If you know what subnet your network is on, this may be a shortcut for providing access without having to use ifconfig inside the guest machine.

Science for the People!

Partly inspired by the experience, BSSRS staff member David Dickson later wrote in New Scientist magazine calling for “Community Science Resource Councils”. The idea, which sadly never took off, was a sort of scientific equivalent of legal aid. It would have provided scientific knowledge and technical expertise to minority and under-represented groups, and also allowed them a greater chance to shape what questions get asked and answered by science. “Perhaps the greatest gain would be in public education,” he wrote. “Members of the community would be able to answer back.”

People today often call for evidence-based policies, but the problem is that the power to collect evidence isn’t evenly distributed. In the 1970s, BSSRS worked to change this – and build a science for the people.

There are some fun parts to this story, which was passed to me in an internal email thread today. Especially great in the context of land grant universities.