Thanks BTW for understanding - that's my intention here, which is to call out bad companies for doing egregious sorts of things (along with me being pretty frustrated in general, which could've been in poor form but whatever)
Forgot to mention: I don't expect anything positive to come out of it. I just want it to be a fair warning to anyone who would think about interviewing with them.
There was never an interview where you meet with Canonical execs. There was an interview panel where I met with higher ups and whatnot, but not at the executive level. That was a completely, 100% hidden step in the process depending on where they think you lay in the hierarchy (probably decided after the interview - the job I was interviewing for wasn't originally written for a senior level hire.)
Problem is, if I'm looking at hiring you I'm not sure if I'm going to get my money's worth. Hiring is not cheap, plus there's the ramp up time, and the impact on other people's performance while you're ramping up.
If your work history shows you're not likely to stick around for a couple of years, that will count against you in any consideration.
Some times you need to make decisions about how much crap you'll put up with, so that your job history makes you more marketable.
Your resume / work history is one of the first things a recruiter or hiring manager will see about you. It has to speak for you on what kind of employee you are, and you have to assume they're going to take it the worst way.
I got asked a lot of hard questions in recent round of interviews about the one gap out of a history that's quite long. Haunts you if you don't have a good story up front.
The same applies to short periods of employment. Take your time during updating the CV to create convincing language-neutral explanation, because „they were among the stingiest cheapskates in this part of the continent”, or „their codebase was monumental dried pile of Java” will not work in your favor.
I don't blame them for not having a paycheck, I blame them for handling this incredibly terribly. If I had known there was even an exec-level review of my application, I would've acted otherwise. I don't burn bridges often, but given the amount of bullshit that exists in the tech industry, I'm okay with calling it out and risk burning bridges than to keep mum and allow shitty practices to continue.
Everything was assured - I turned down other offers either due to some bad timing or seemingly worse fit, related to waiting for this particular position to get back to me. Of course, no one should ever turn down other jobs unless you have an official offer letter in hand, but even then, an employer can rescind the offer even if you sign the paperwork.
* No web UI. This may be a blocker for business folks who want to update a blog. This is a blocker for folks who are using devices like iPad's to update blogs (which is a huge reason why I moved away from things like Octopress and moved toward things like Ghost or Wordpress.) This may be a blocker for folks who don't always have the tools on whatever machine they're using at the time in order to generate the site.
* No imposed structure. It's easier to impose a web UI form that locks folks into certain workflows than it is to just give them a git repository with all sorts of stuff strung about, with no apparent structure other than the FS structure.
Whoops, I wasn't clear - I mean that using a static site generator has no downsides relative to writing HTML/CSS directly. Your downsides are both relative to using more tooling.
In terms of those downsides, I agree with you for larger sites, but not for the kind of really small sites the OP was talking about.
Surely that's not a static site? I think the author was trying to say that people rely to heavily on tools to achieve simple goals; using a tool or framework for your own amusement can sway you away from the actual goal, in his case making a static website for an animal shelter.
You can still have a web UI and produce a static website.
I've written blogging software that did just that. Every time the author edited/added something in the web UI (which saved to a db), it just re-'compiled' the particular pages.
IMO, Amazon gets 'DevOps' right. It's mostly just called 'ownership' over in Amazon. (source: I used to work in Amazon as a systems engineer)
You still have specializations - SDE's, systems engineers, DBA's, etc. However, if you write code and it ends up in production, you are responsible for the proper function of that code in production. As a friend of mine put it in terms of developers who don't want to be on-call: 'what, you don't trust the quality of your code?'
DevOps is simply a nicer way of just saying, "own your damn code." The corollary to this is that the organization must help you in getting to that state where you can effectively own your code - this means collaboration (so that you build maintainable systems) and building tools that enable fairly frictionless code ownership.
I've worked among devs who don't want to own their code in production, they'd rather just code and then throw new code over the wall for the sys admins to deploy.
The anti-DevOps developers don't understand how databases work so they want an ORM to make it easy for them, and they don't know how to configure a web server so they want PaaS solutions to let them do 1-click deploys, and system command prompts are scary to them. Frankly such developers just plain suck. They don't like DevOps because they don't have the skills to be DevOps.
Security is about mitigating risk, not about eliminating it.
Keep up with CVE's, don't provide a wide attack area (so lock down interfaces to your machine and don't expose much to the world), and keep blast radii as small as possible (so even if your machine does get owned, you can possibly restrict it so it doesn't automatically mean they gain access to other systems in your network.)
Oh, and model the threats to your network/application. Make sure you're securing against the right threat. As an example, anti-malware is wholly ineffective against social engineering - maybe it's more productive to train employees and make sure that each employee doesn't have total access to all privileged systems.
FWIW, if you do need ELB support right away (and keep in mind that you'll have to look at it from each server's point of view), you can probably use https://github.com/opscode-cookbooks/aws (and use the elastic_lb resource), and hook it into your own cookbook for setting up whatever ELB's you want (then set up your custom cookbook repo for your stack.)
(I'm trying to say that this platform is incredibly flexible, and you can reuse what's already out there. If you need support for X, Y, or Z, then you can likely write in support with Chef.)
