Got some mild positive feedback on the last post like this, so let's do another one.
News in AWS land
- EC2 Instance Console Screenshot is about letting you, assuming you're on HVM virtualization, take a screenshot. Click a button, get a screenshot. Awesome.
- Cross-Account Snapshot Sharing for Amazon Aurora is especially exciting, because cross-account snapshot sharing is a great way to implement off-site, separately ACL'd backups (don't forget to add cross-region as well).
- Amazon Aurora now supports cross region replication. And that's just great for building high-availability database clusters on Aurora.
- EC2 Run Command is an interesting way of managing your servers without ever touching Chef or Ansible or any of those thingies. I'm not sure I'd ever use it, but there's a certain charm to having a button that installs all Windows updates on your node.
- Export Redis Snapshots to Amazon S3 is another one where you can take a backup off-site, this time for Redis-backed ElastiCache.
Soft, squishy, managery
You know that guy, Seth Godin? His blog is like a feed of daily motivational quotes, except they're management / startup related thoughts that seem to make sense. Here's a few I liked recently:
Sometimes I share at Prezi the most interesting articles I find online. Someone asked to maybe make these publicly available, so let's see how that works out.
A Look Back at One Year of Docker Security (2016-04-20) is a look at the security-focused changes that happened in Docker in the past year. I love the "secure by default" philosophy. Daemon-side ulimits, user-namespaces, and other fun thingies.
Amazon EMR Update – Apache HBase 1.2 Is Now Available (2016-04-21) is AWS announcing that they've released new features for EMR, their hosted big data stack. The second half of the post veers off into a "getting started with HBase", in case you want to give it a quick spin.
Longer EBS and Storage Gateway Resource IDs Now Available (2016-04-28) is just an announcement that the newer, longer, better IDs are now available for more resource types.
Kafka Inside Keystone Pipeline (2016-04-27) talks about how Netflix uses Kafka inside their Keystone data pipeline. Challenges of running at scale, failovers, some configuration, deployment strategies, the good stuff.
Communication is such an overloaded word. It means so many things that the real meaning often is defined by context and - ironically enough - when communication is sub-par, different people will infer different meanings from the same context. Worse yet, the person you're talking to may be in a very different context than you are, even in the very same conversation. (Say, "Your project is interesting, but today I care more about my new-born daughter")
So for the purposes of this post, communication is about reaching the same understanding about an idea. Not consensus on whether it's a good or a bad idea; just a shared understanding of what the idea is. I'm not an expert at this by any means; have no formal education (or otherwise, really), but I've been told I usually do a good job of conveying ideas; so here's a few ways I think about communication.
When working on internal tools, I often find ourselves talking about quality as a value in itself (an intrinsic value, if you will); both when considering plans, and when communicating with our users (developers, in this case).
Last week I came across a (taxi|cab) sporting a tagline along the lines of "committed to quality". What I realized is that I have no idea what it means for a cab or cab company to be of high quality. What I care about is getting from A to B in reasonable time, for a reasonable price, without anything bad happening (like, say, an accident, or the driver being rude, which is arguably even worse than an accident).
I don't care one bit about the size of the engine, tire pressure, or the color of the toe-nails of the driver. All I care about is having a pleasant experience while getting the results I expect.
So here's a thought: the same applies to developer tools, even internal developer tools. Quality, as in code quality, is only interesting in that it allows us to implement new features and fix bugs faster. What matters in the end is the experience developers have while using our tool - that they get the result they want, that they have a good experience on the way (the tool is "delightful"), and that nothing bad happens.
This of course leads to a more generic and stronger point: developer tools are products. Especially internal tools: they need to create very real value, otherwise it doesn't make sense to work on them as opposed to working directly on the product of the company. Since companies usually have very limited resources for working on internal tools, the trade-off between spending time on refactoring code and spending time on fixing bad UX is extremely pronounced.
In short: internal tools are a product with scarce resources; plan accordingly.
Last Thursday Carol S. Dweck spoke to a packed room about growth mindset in Budapest at an event organized by HVG Extra. (You know someone’s serious when they have their own Wikipedia article). These are my notes from the talk.