mosesschwartz

That’s fantastic. Is your 3D model on Thingiverse or anywhere else? I’ve been thinking about making exactly the same thing to use tripod mounts on the Moonlander.

I think the best solution is to use a tool like StackStorm, Rundeck, Wooey (https://github.com/wooey/Wooey) or even Jenkins (as mentioned in some other comments), and standardize on adding new scripts to that system. This has the benefit of not needing to cater to individual environments -- you can get it running on a server and call it good.

I wrote and open-sourced a tool called Scrypture (https://github.com/mosesschwartz/scrypture) some years back that partially addressed this need. It served as a central place that everyone could add their own scripts to, and it made it easy to expose the scripts through a web interface. Today I think going with one of the tools mentioned above would be more robust, but it goes to show that this is a real need for a lot of teams, and there really isn't a recognized single best solution.

I'm a little bit surprised to see StackStorm directly compared to Ansible and SaltStack. There's certainly overlap in capabilities, but in my mental model of the space Ansible and Salt are primarily configuration management, while StackStorm focuses on event-based orchestration.

In my environment we're using both Salt and StackStorm very effectively. Salt for CM and StackStorm as a platform for building automated, event-driven tools. They're really very complementary, especially since both are Python-based.

This is an interesting discussion, but unfortunately the term observability is overloaded. It is used in control theory as "a measure for how well internal states of a system can be inferred by knowledge of its external outputs" [1].

For several years I've been using the term "inspectability" to refer to the kind of observation of code execution to which the author refers. Inspectability is an important concept, especially for computer security, and is not often discussed.

It's interesting to note that malware written in a language like OCaml would often be harder to reverse engineer than malware written in C, precisely because of the points the author makes.

http://en.wikipedia.org/wiki/Observability

When I interviewed they did not ask for an NDA during the phone interviews, but they did have me sign one before the on-site interview.

For what it's worth, I had an overall positive experience interviewing with Google.

This article is an interesting read, and fits well with the recent theme of insourcing articles on HN.

However, the author gushes so much about the quality of these shirts that the article feels like advertising. Does anyone have any experience with the brand? Are their products as good as the author makes them sound?

He also leaves out the Airport Extreme/Express base stations, Cinema Displays, and keyboards and mice. The Apple TV (as it stands now) is really more of a peripheral than a core product.

Ruby's image to the programming public is inextricably linked to Rails, and so to web development, and making fun of web developers is a time-honored tradition among people who fancy themselves "Real Programmers."

Outside of this (friendly?) rivarly, I think even the most obstinate Pythonista has to recognize that Ruby is a perfectly capable language for non-web development.