These days, most of my work is very related to the online world. Building web sites, reviewing web applications, integrating with web services, coordinating people who are far away from each other, etc. Whenever I find a new tool or service or an innovative, interesting idea about working online, I share it in this category.
I came across a couple of CSS guidelines while catching up with my feeds over the weekend. Â Here they are:
Here’s some not so light coffee time reading on IPv6 –Â IPv6 non-alternatives: DJB’s article, 13 years later – an article that links, among other things to this Ars Technica article, which features some IPv6 statistics. Â Summary? Â Sure. Â IPv6 RFC celebrates 20 year birthday this month with 10% global penetration.
Exponential growth year-on-year is good. Â But the absolute numbers aren’t so bright yet. Â Especially considering some of the areas where it wasn’t so successful.
This year’s Jetpack annual report for this blog is ready – have a look. Â Here’s a teaser:
It’s been a busy year, so I haven’t been blogging as much as I wanted to, but overall, I think I did good (have a look at 2014 and 2013). Â Just to give you a quick comparison:
| Metric | 2013 | 2014 | 2015 |
|---|---|---|---|
| Visitors | 58,000 | 81,000 | 96,000 |
| Posts | 560 | 628 | 541 |
I blog mostly for myself, but it’s nice to see a slight grow in traffic. Although the fact that the most popular post in this blog throughout the years – how to check Squid proxy version – is a little concerning, yet funny.  Well, at least people still find my “Vim for Perl developers” useful, even though it’s been more than 10 years since I wrote that (and probably five years since I promised to update it soon).
But as I said, I’m quite satisfied with my blogging this year. Â Hopefully I can continue to do the same in 2016.
“5 AWS mistakes you should avoid” is a rather opinionated piece on what you should and shouldn’t do with your infrastructure, especially, when using AWS. Â Here’s an example:
A typical web application consists of at least:
- load balancer
- scalable web backend
- database
and looks like the following figure.
This pattern is very common and if yours look different you should have (strong) reasons.
It’s all good advice in there, but it comes from a very narrow perspective. Â The “mistakes” are:
- managing infrastructure manually
- not using Auto Scaling Groups
- not analyzing metrics in CloudWatch
- ignoring Trusted Advisor
- underutilizing virtual machines
So, it looks like I’m not the only one trying to figure out Amazon EC2 virtual CPU allocation. Â Slashdot runs the story (and a heated debate, as usual) on the subject of Amazon’s non-definitive virtual CPUs:
ECU’s were not the simplest approach to describing a virtual CPU, but they at least had a definition attached to them. Operations managers and those responsible for calculating server pricing could use that measure for comparison shopping. But ECUs were dropped as a visible and useful definition without announcement two years ago in favor of a descriptor — virtual CPU — that means, mainly, whatever AWS wants it to mean within a given instance family.
A precise number of ECUs in an instance has become simply a “virtual CPU.”
