A few days ago I was listening to a program on the radio that was discussing the current state of the building trade in the UK.
I wasn’t paying that much attention during the start of the show as they discussed the progress in 3D printing, which is allegedly now being used to produce prefabricated panels for buildings. The suggestion being that 3D printing makes building cheaper, quicker and less labour intensive. Prefabricated buildings have been around for many years in one form or another, so that wasn’t really news, but the 3D printing bit made it sound a bit cooler… 🙂
After extolling the virtues of 3D printing, the program moved on to the impact of all this on the building trade and that’s where it got interesting. To cut a long story short they said this method of building would have a big impact on employment levels in the building trade, saying bricklayers would be a thing of the past. Allegedly the UK building trade and the associated unions are resisting this change, but finance would inevitably make this happen and then what happens to all the builders? Allegedly there is no steer from the building trade, unions or government about how we will cope with the unemployment associated with this shift in the industry, or possible retraining necessary…
You’ll notice I’ve said allegedly a lot, as I don’t know how factual this discussion was, but it was interesting all the same…
So I was sitting in the car thinking, “That sounds familiar!” 🙂 I’ve been talking about the changes in our industry a lot recently. It’s not time to panic, but it’s not sensible to stick your head in the sand and wake up one day to find you are surplus to requirement…
Cheers
Tim…
Update: With reference to a comment, in the UK houses are still predominantly brick built. Offices and high-rise is a different story. 🙂
Over the last couple of years I’ve been doing talks about running Oracle databases in the cloud. In both my talks and articles I refer to the Licensing Oracle Software in the Cloud Computing Environment document. This morning I was reading a post on a mailing list and someone mentioned the document had been updated on 23-Jan-2017 and contained two rather interesting changes.
The Good
The document now explicitly mentions the difference between how vCPUs are licensed on different cloud providers. On AWS a vCPU is one Intel hyper thread, so you need 2 vCPUs to make a real core. Azure does not use hyper threading on their boxes, so 1 vCPU equals a real core. The previous version of the document did not make this clear, so it read like you were paying per thread on AWS, even though people who used cloud-savvy partners understood this issue and paid correctly (vCPUs/2 on AWS).
“When counting Oracle Processor license requirements in Authorized Cloud Environments, the Oracle Processor Core Factor Table is not applicable.”
Just digest that for a moment. The intel core factor is 0.5, so an 8 core physical box requires 4 cores of licensing. Now on the cloud, an 8 core VM (16 vCPUs on AWS or 8 vCPUs on Azure) requires 8 cores of licensing.
On the 23-Jan-2017 the intel core factor was removed from the cloud licensing calculation and overnight your cloud licensing costs doubled! WTF! 🙁
Update: For the new AWS bare-metal service, the core factor *should* still apply.
The same person also pointed out that in a MOS Note (Doc ID 2174134.1), last updated on 20-Aug-2016, Oracle pulled support for the Oracle Multitenant option from AWS EC2. WTF on a bike! 🙁 I assume they mean both non-CDB and Single Tennant (Lone-PDB) are still supported.
The Ugly
The reaction to this is going to be really bad! It’s getting really hard to remain an Oracle fanboy these days!
If you have been to one of my cloud talks over the last couple of years and you are basing your opinion on something you’ve heard me say, please remember things change. For those people I presented to at the UKOUG Database SIG on Tuesday, I’m sorry, but I was 2 days out of date on one slide. I’ve updated my slides and articles to reflect this change!
This is all so completely depressing!
Cheers
Tim…
PS. I’m not saying this policy document overrides your contracts. Just saying this is the most recent policy document produced by Oracle!
PPS. You might want to take a look at page 19 and the addendum on page 23 of this copy of the NoCOUG Journal.
After my recent rants about Oracle changing URLs and breaking stuff, I’ve actually done some changes myself. 🙂
From time to time change is forced on internet content producers. This might be because of platform changes, or changes in the way search engines behave. The important thing is how you handle that change.
Followers of the blog will know I recently made my website responsive. That happened in part because Google recently announced they would downgrade the rankings of sites that weren’t “mobile friendly” and “responsive”. The search ranking were only meant to affect mobile searches. What they didn’t say, but many people including myself believe, is that these rankings actually affect normal desktop-based searches as well. When this Google announcement was made, I noticed a drop in my hit rate. Once I changed the site to be responsive, the hit rate went up again somewhat. When I recently corrected about 100 of the remaining non-responsive articles, the hit rate went up again. It could be conincidence, but it certainly seems there was a bleed-over of this ranking change into the desktop side of things, which represents over 95% of my traffic. Those changes affected content, but not the URLs to the content.
Since I’m revisiting almost every article to fix broken links to Oracle docs, I thought I would take the opportunity to do some additional site maintenance, specifically in the following two areas.
HTTPS : About 9 months ago I got a certificate for the website to allow it to be accessed using HTTPS. This was also influenced by a Google decision that they would improve the ranking of content that was available over HTTPS, as well as HTTP. It was part of their “HTTPS Everywhere” campaign. Even though the site could handle HTTPS, I did not make it the default. As of a couple of days ago, you may have noticed all pages on oracle-base.com are now delivered over HTTPS. Unfortunately, this represents a URL change as far as the internet is concerned, so it means lots of broken links, unless you handle it properly. More about that later.
Removal of “.php” extension : You will notice many blogs and websites don’t display a file extension of pages, or display a generic “.htm” or “.html” extension. It’s pretty easy to do this using query rewrites in Apache or a “.htaccess” file. For a while, the site could be accessed with or without the “.php” extension. Now it is removed by default. The nice thing about this is you can change the underlying technology at any time, without having to support an inconsistent file extension. Once again, this represents a URL change.
So how do you manage this change without pissing off “the internet”?
The answer is rewrites and redirects done in real web pages, Apache config or “.htaccess” files. Essentially, you are supporting the old URL and redirecting the browser to the new URL, using a 301 redirect, so all search engines know the content has moved location and can be re-indexed in that new location. Over time, all the links from Google will go directly to the new URL.
So that means you can remove the redirects after a while right? NO! People will have links from their website to the old URLs forever. People will have bookmarks in their browsers forever. If you are going to change a URL, the old URL must be maintained forever.
Over the years I’ve made lots of structural changes to the site.
When my website started it was written in Active Server Pages, using a “.asp” extension.
After a while I switched to PHP, using a “.php” extension.
I used to name pages using initcap. A couple of years ago I switched to lower case and “-” separated names.
About 9 months ago I removed the “www.” because it seemed pointless in this day and age.
I’ve just swicthed to HTTPS.
I’ve just removed the “.php” extension.
If we look at a really old article, probably about 15 years old, we will see the history of these changes in the following URLs.
So all those structural changes over the last 15 years should have resulted in zero broken links, zero pissed off content producers who link to my content and zero uninformed search engines.
Now I’m not perfect, so if anyone finds something that is broken, I will fix it, assuming it’s not your bad typing or copy/pasting. 🙂
Cheers
Tim…
PS. Any structural changes, regardless of how well you do your 301 redirects, can result in lower search rankings, so it should not be done on a whim if you really care about hitting that top spot on Google. This is my hobby, so I will do whatever I want. 🙂
