5 Fancy Reasons and 7 Funky Uses for the AWS CLI

5 Fancy Reasons and 7 Funky Uses for the AWS CLI has a few good examples of AWS CLI usage:

  1. AWS CLI Multiple Profiles
  2. AWS CLI Autocomplete
  3. Formatting AWS CLI Output
  4. Filtering AWS CLI Output
  5. Using Waiters in the AWS CLI
  6. Using Input Files to Commands
  7. Using Roles to Access Resources

There also a few useful links in the article, so make sure you at least scroll through it.

AWS X-Ray – Analyze and debug production, distributed applications


I think I’m giving up on even knowing the list and purpose of all the Amazon AWS services, let alone how to use them.  Here’s one I haven’t heard about until this very morning: AWS X-Ray.

AWS X-Ray helps developers analyze and debug production, distributed applications, such as those built using a microservices architecture. With X-Ray, you can understand how your application and its underlying services are performing to identify and troubleshoot the root cause of performance issues and errors. X-Ray provides an end-to-end view of requests as they travel through your application, and shows a map of your application’s underlying components. You can use X-Ray to analyze both applications in development and in production, from simple three-tier applications to complex microservices applications consisting of thousands of services.

16 Linux Books and Videos for System Administrator

Having knowledge of Linux is essential for any system administration, middleware, web engineer job.

Linux is used almost everywhere in production or a non-production environment. There are thousands of article, book, video training to explore and learn but that would be time-consuming.

Instead, you can follow one or two related books or online training.

The following learning materials cover a large number of Linux Administration tasks from beginning to expert level. So pick the one suits you.

Source: 16 Linux Books and Videos for System Administrator

Spellbook of Modern Web Dev

Spellbook of Modern Web Dev is a collection of 2,000+ carefully selected links to resources on anything web development related.  It covers subjects from Internet history and basics of HTML, CSS, and Javascript, all the way to tools, libraries and advanced usage of web technologies, and more; from network protocols and browser compatibility to development environments, containers, and ChatOps.

  • This document originated from a bunch of most commonly used links and learning resources I sent to every new web developer on our full-stack web development team.
  • For each problem domain and each technology, I try my best to pick only one or a few links that are most important, typical, common or popular and not outdated, base on the clear trendspublic data and empirical observation.
  • Prefer fine-grained classifications and deep hierarchies over featureless descriptions and distractive comments.
  • Ideally, each line is a unique category. The ” / “ symbol between the links means they are replaceable. The “, “symbol between the links means they are complementary.
  • I wish this document could be closer to a kind of knowledge graph or skill tree than a list or a collection.
  • It currently contains 2000+ links (projects, tools, plugins, services, articles, books, sites, etc.)

On one hand, this is one of the best single resources on the topic of web development that I’ve seen in a very long time.  On the other hand, it re-confirms my belief in “there is no such thing as a full-stack web developer”.  There’s just too many levels, and there’s too much depth to each level for a single individual to be an expert at.  But you get bonus points for trying.

Rate Limiting with NGINX and NGINX Plus

Nginx blog (which, if you work with Nginx in any capacity, you should subscribe to) has an excellent guide to rate limiting.  The article explains rate limiting from the basics, through bursts, all the way to more advanced examples, with multiple rate limits for the same location.

Web Developer Security Checklist

Web Developer Security Checklist is a good collection of security issues to keep in mind when building web applications.  Not much new in there, but it’s nice to have all of these conveniently gathered in one place.  All items are grouped into a few sections – database, development, authentication, denial of services protection, web traffic, APIs, validation, cloud configuration, infrastructure, operation, etc.

HTTPS on Stack Overflow: The End of a Long Road

Way too often I hear rants from random people (unfortunately, many of them are also from the IT industry, with the deep understanding of the underlying issues) complaining about why company X or product Y doesn’t implement this or that feature.  As someone who has been involved a dozens, if not hundreds, of projects, I pretty much always can think of a number of reasons why even seemingly the simplest of features aren’t implemented for years.  These can vary from business side of things – insufficient budgets, strategic goals, and the like – to technical, such as architectural limitations, insufficient expertise, insufficient resources, etc.

One of the recent frequent rant that keeps coming up is “Why don’t they just enable HTTPS?”.  Again, as someone being involved in HTTPS setup for several different environments I can think of a number of reasons why.  SSL certificates used to cost money and were quite cumbersome to install until very recently.  Thanks to Let’s Encrypt effort, SSL certificates are now free and quite easy to issue and renew.  But that’s only part of the problem.  Enabling HTTPS requires infrastructural changes, and the more complex your infrastructure, the more changes are needed.  Just think of a few points here – web server configuration (especially when you have multiple web servers, with varied software (Apache, Nginx, IIS) and varied versions of that software), load balancers, web application firewalls, reverse proxies, caching servers, and so on.

Apart from the infrastructural changes, HTTPS often needs changes on the application level.  Caching, cookies, headers, making sure that all your resources are HTTPS-only, redirects, and the like.

All of the above issues are multiplied by a gadzillion, when your project is publicly available, used by tonnes of people, and provides embeddable content or APIs to third-party (hello, backward compatibility).

This is not to mention that HTTPS itself is a complex subject, not well understood by even the most experienced system administrators and developers.  There are different protocols and versions (SSL vs. TLS), cipher suites, handshakes, and protocol details.  Just have a look at the variety of checks and the report length done by Qualys’ SSL Labs Server Test.  Even giants like Google, who employ thousands of smart people, can’t get it all right.

But for some reason, people either don’t know or prefer to ignore all this complexities, and whine and cry anyway.

Recently, Stack Overflow – a well known collection of sites on a variety of technical subjects, has completed the migration to HTTPS everywhere.  These are also people with a lot of knowledge and expertise and with access to all the information.  Just have a look at their long way, which took not months, but years: HTTPS on Stack Overflow: The End of a Long Road.

Today, we deployed HTTPS by default on Stack Overflow. All traffic is now redirected to https:// and Google links will change over the next few weeks. The activation of this is quite literally flipping a switch (feature flag), but getting to that point has taken years of work. As of now, HTTPS is the default on all Q&A websites.

We’ve been rolling it out across the Stack Exchange network for the past 2 months. Stack Overflow is the last site, and by far the largest. This is a huge milestone for us, but by no means the end. There’s still more work to do, which we’ll get to. But the end is finally in sight, hooray!

So next time you are about to start crying about somebody not having feature X or Y, just give it a minute first.  Try to imagine what goes on on the other side.  You aren’t the only one with low budgets, pressing deadlines, insufficient knowledge, bad colleagues and horrible bosses…

Introducing Moby Project: a new open-source project to advance the software containerization movement

Docker Blog is introducing the Moby Project:

The Moby Project is a new open-source project to advance the software containerization movement and help the ecosystem take containers mainstream. It provides a library of components, a framework for assembling them into custom container-based systems and a place for all container enthusiasts to experiment and exchange ideas.

This just had to happen, given the nature of the Open Source and the importance of the container technology for the modern infrastructure.

The Ultimate WordPress Security Guide – Step by Step (2017)

WPBeginner, a website for beginner guides to WordPress, has published an updated and comprehensive guide to WordPress security – “The Ultimate WordPress Security Guide – Step by Step (2017)“.  Most of the things are well known to seasoned WordPress users – keep things updated, use strong passwords, remove unnecessary plugins, make sure to pick the right hosting, add security enhancing plugins, etc.  But it’s a good place to start for  people who are not too technical and those who don’t think about security implications of having a publicly accessible website on a daily basis.

There are plenty of questions, answers, simple explanations, and links to other resources in the article.  So even if you are an experienced WordPress user, you might find a useful thing or two in there.

You might also want to checkout my earlier blog posts:

Building the Right Alerting System

Here’s something I wanted to get into for a while now, but haven’t had the time yet – switching the monitoring / alerting system from server-oriented to business-oriented.  The gist of the story is:

If it’s not actionable and business critical, then it shouldn’t ring.

The article has some statistics and summaries as well.  The reasoning behind the switch is obvious, but it’s good to have it formulated:

After a few months, I can tell reducing our alerting rate should have been a top priority before things got out of hands, for a few reasons.

  • Constant alerts prevented the team to focus on what was important. Being interrupted even for things that can wait for a few hours lowers our productivity when we work on things that can’t wait.
  • Being awaken every night, several times a night exhausts a team and make people less productive at day, and more prone to do errors.
  • Too many off hours interventions cost the company a lot of money that could be invested in hardening the infrastructure or hiring someone else instead.