November 2012 Archives
We're looking for a non-junior software engineer willing to work on non-web technologies. Candidates who will definitely make us sit up and take notice will have some of the following experience:
- Ruby (not just in Rails, but all by it's lonesome)
- NoSQL databases that can scale lots
- Massively parallel systems (Supercomputing experience would be cool, but distributed processing is just as nifty)
If you have enough generic experience under your belt, we can work with that. Multiple programming languages are a good thing, and you'll have a chance to learn a new one (or two). Having done interesting things recently helps.
And the extra-bonus qualification that's hard to find (so we plan on training you into it if you don't have it, and if you don't have it already that's OK, few of us did when we got here so if you already have it we'll forgive other missing things in your background): In depth knowledge of file-format specifications (PDF, PST, NSF, etc)
Some benefits of working here:
- Full self +1 health coverage, including Dental, Vision, and disability insurance.
- A "don't be stupid with it" unlimited paid-time-off policy.
- Liberal work-from-home opportunities.
- Plenty of dev-ops learning opportunities. If you want to try picking up the systems side of engineering, I can help with that.
- An office on top of a Metro station, so you don't have to drive into DC if you don't want to. Also, a monthly transit subsidy!
- A bike-friendly office. When the weather is right, there are several bikers. And when the weather is wrong, we still have one or two.
- An office a block from one of the major food-truck stops in the DC downtown area.
Is this a problem at Sysadminly conferences?
If you don't need Java JRE on your PC, get rid of it.
If you need it, patch it.
If you can't patch it because some silly application is not compatible with the patch, kick the [beep] of whoever supplies that application.
I heartily support that third point.
Being a sysadmin I have seen more than my fare share of appliance configuration utilities written in Java. And had those same utilities crap out on some minor point-rev update, or major update (1.2 to 1.3 was particularly traumatic, though 1.5 to 1.6 had it's own issues). And lived with the hell of two must-use utilities with opposing Java requirements.
Things are a bit better these days. Random appliances mostly come with nice html-GUI these days, which is very welcome. But there is legacy to consider...
Take, for a not exactly random example, a certain Ethernet switch model we use a lot of. It has a web-GUI to go along with the traditional CLI interface. This web-GUI loads a Java applet. I don't know how this Java applet behaves with modern Java because like the stylish sysadmin I am, I'm exclusively a CLI user when it comes to switch configuration. However, there is only one of me at this job, and my backup is a developer who has no other experience with switch configuration. He uses the Java applet exclusively because it's self documenting and makes sense, and allows him to be immediately productive.
If this particular Java applet had a problem with, say, Java 1.6u24 and higher, we'd have to wait a long, long time before we could get any patch in to update it. If a patch would even be produced. This particular switch model is getting on towards EOL, and the pace of switch OS updates has slackened quite a bit in the last year. The vendor would probably not issue an update just because the maximal Java version the applet will run in is no longer the latest, largely because there is an 'easy' workaround: use the CLI like most network engineers do.
And even if we did get a patch like that, we'd have to work in a major outage to get all the switches updated just so our admin users can use modern Java. Given the costs of downtime, us admin users would likely be told to just lump it.
It is for reasons like this that I've adopted a work-around of my own. Keep a VM that I use for admin-duties on which I keep older Java versions around, install ancient configuration utilities, and other such easy-to-get-old detritus of what I do, and never do general web-browsing from that VM. This reduces the attack surface, and so far I've been lucky enough to avoid malware incursions on my own stuff.
It is for reasons much like this one that many (if not most) sysadmins of some experience shake their fist whenever they get a new thingy that requires a Java applet for configuration, and hate on Java in general.