Amazon Web Services (AWS) has made Lambda available at the Edge. By edge they mean the edge nodes of their CloudFront (CF) content distribution network (CDN). This mash-up of the two services allows for processing of final data all the way out to the point where it is almost reaching the client and allows for processing requests and the information passing through from the origin to the client / browser that made the request, but I am getting ahead of myself. For those of you who are not aware of what AWS, CF, or Lambda is, let’s start with what they are…
PHP has released versions 7.0.16 and 7.1.2 (these versions are not security releases, just bug/patch releases)
Amazon Web Services (AWS) has come out with a number of new features to compete with the likes of Google, Microsoft, and a litany of other cloud service provider’s push into the enterprise user space. Google has had Google for Work for quite some time. Microsoft introduced Office 365 within the past couple of years and Amazon has added many of the same features — just offered as separate pay-as-you-go services.
A couple years ago Amazon Web Services (AWS) introduced one of the most requested features: a mountable file system that could be used across multiple server/elastic compute/EC2 instances. In addition to that it would scale automatically — no setting a storage size — with however much data you used, just like their simple storage service (S3). It was called Elastic File System (EFS). However, elastic block storage (EBS) is still used by most to mount operating systems and often even for file storage (partially due to legacy use and since it is seen as more stable). So what happens when you reached your EBS limit? In the past it was no different than running out of hard drive space on a personal computer (or Mac). Most people panicked, freaked out, panicked some more, then started the long process of adding a new, larger drive (EBS volume) and copying all the existing data over from the old drive or adding a new drive then altering a bunch of software code to split where it can find the data.
Pretty much everyone knows what the blue screen of death is. That dreaded complete system failure that happens every so often. Sometimes for no reason at all. It can happen on any device – PC, Mac, Android, iOS/iPhone… most of the time the device just reboots.
Any number of issues can cause them – software bug, hardware driver issue, poorly manufactured hardware, an operating system (OS) error, malware (like viruses, adware, etc.). However, those times when it just seems to happen out of the blue (pun intended) might be because of space. Yes, that big blue-in-the day, black-in-the-night thing above you.
I built this new WordPress plugin, RequireWP, to help speed up the web. It extends WordPress’s WP_Scripts class to write your script requirements out with Require.js syntax. I have seen a ~20% speed increase (decline in load time) on this site which is using the plugin as well. After installing I just had to modify the theme’s required scripts since a few were not set correctly.
Amazon Web Services (AWS) had added a new feature to it’s Rekognition facial recognition service: age range. The artificial intelligence cloud service has added age ranges to it’s analysis of peoples’ faces. When you feed in a photo (image) it will estimate the minimum and maximum age range of each person in the photo:
The recently released version 4.7.2 of WordPress had an additional security fix which was not disclosed in the changelog when it was released. The issue? A privilege escalation / content injection bug in the REST API that allowed for the potential that anyone could edit any post.
Part of the REST API had an improper check for a valid post. If it was not a valid post ID but still contained a valid ID within a string such as “134A” it would be converted to an integer (the A gets stripped away making it just “134”) which gives any user access to update the post via shortcodes (and possibly other routes).
This issue was fixed in 4.7.2 so make sure your WordPress install is updated!
elastic has released version 5.2 of their search software, Elasticsearch. Here is what you can expect from this release:
- Numeric & Date range fields: New field types (integer_range, float_range, long_range, double_range, and date_range) were added allowing you to define a minimum and maximum numeric or date range when you post data to the document field. For example, an event lasting an entire weekend can now be easily added and can then be searched by checking if the event’s date range lies inside or outside a search range or a specific date falls within the event’s date range.
- Cluster Allocation Explain API: For Elasticsearch admins, when a cluster went down because of shards not being allocated often required a number of queries to different APIs to figure out what exactly happened to a cluster. The new Cluster Allocation Explain API combines the information scattered around different APIs to make it easier to diagnose the problem and get it solved quicker.
- Keyword Normalization: For the new keyword type added in version 5.0, it was not easy to do things like lowercase the characters since it was meant for aggregations & scripting. This update allows you to use normalizers – tokenizers that only affect individual characters, not entire terms. This allows you to use character modifiers on the field when you need to.
- Term Aggregation Partitioning: Elasticsearch defaults term aggregations to the top 10 but can be set to higher values. However, many were requesting if there was a way to just return all top terms (such as using a negative value). However, it is not possible. Why? Because can take much longer for databases with many thousands, millions, or even billions of terms. However, people were persistent so they came up with another way. An example is looking for all the accounts that have not logged in recently. In this update you can partition the terms across a set number then request the terms from each partition individually.