A few years ago I saw an article about IP v4 addresses and how IoT was causing us to run out of them quickly. At the time it seemed odd, because I knew that you could get them for nothing, or next to nothing, from every cloud provider.
If we were really running out, wouldn't you expect to pay something for them? Wouldn't supply and demand dictate that they couldn't be given away for free?
But perhaps this is really starting to happen now.
I just received an email from Google Cloud that, perhaps, There's No Such Thing as a Free IP Address Either (TNSTAAFIAE).
From the email:
First, we’re increasing the price for Google Compute Engine (GCE) VMs that use external IP addresses. Beginning January 1, 2020, a standard GCE instance using an external IP address will cost an additional $0.004/hr and a preemptible GCE instance using an external IP address will cost an additional $0.002/hr.
In addition, there are also price increases at Azure, though not in the classic resource deployment mode.
Here are the spot prices today for single static IP addresses (based on a 30 day month):
I ordered my AWS Deep Racer about 6 months ago, when it was supposed to be ready in March. At long last, I'm expecting to get it this week.
If you aren't familiar, Deepracer is Amazon's 1/18th scale robotic self-driving (toy) car. It uses reinforcement learning (a variation of machine learning) to teach the car about driving and help it to complete various courses.
Here is what the car hardware looks like:
The hardware was originally supposed to be out earlier this year, but has been somewhat delayed.
In the meantime I've been working with the simulation tool on AWS - AWS Deepracer. So far, I've managed to train a model to complete one of the easier tracks every time.
I'm pretty excited and looking forward to having the actual hardware. I'm probably not ready for the Deepracer League yet but I am having fun with it.
So far, the cost of running the AWS Robomaker simulation jobs (used for training and evaluating models) is not too expensive. I'll have to see what I spend over the coming weeks, it appears to be $10-$15/day for a few training and simulation runs a day, but that is based on a pretty small sample size.
I was very pleased with Exadel's performance in a recent Forrester Wave™.
We participated in the Midsize Agile Software Development Service Providers, Q2 2019 Wave from Forrester. We were named a Leader in the report and given the highest score in the Current Offering category.
It was really great to work with all of our Agile experts here at Exadel. We worked hard to put together our response and talk about the exciting Agile software development work that we do for our clients and ourselves.
Exadel has been doing Agile development for a number of years and it was great to get to talk about our Agile capabilities. Our Scrum Masters really know their stuff, and it was cool to get recognition for this.
I was shopping for some domain names and I decided to look at a .blog address for something.
First of all, I noticed it was availble some places (GoDaddy, Network Solutions) and not others (Google Domains). Also, the .blog address cost $7000 - that's high compared with what I usually pay for a new domain.
So, I did some research.
The world is a different place than it used to be. Today there are new Top-Level Domains (TLDs) (.blog, .pizza, .business) with much more variety than there was a few years ago.
So, what's up with the pricing? Older TLDs (.com, .net, .org) have fixed wholesale prices negotiated by ICANN (The Internet Commission on Names and Numbers), which is a kind of regulatory agency for these things.
For newer domains - .blog, .rich, etc. They are controlled by different registries who set the prices. These agencies are free to set the prices as they please and the names are therefore subject to "supply and demand", as the old ones were not. I will get to the reason for the quotes in a minute.
In the case of the .blog domains, they are controlled by a company called Automattic from San Francisco.
Of course .com domains have supply and demand economics, just not for new names.
In theory Jeff Bezos could sell you the domain amazon.com - and it would certainly cost you a pretty penny. It would get you a lot of traffic to your site for a while until people realized that the company had simply moved it's amazing e-commerce platform somehere else and whatever you had was not as good.
Of course Mr. Bezos would never do that, but he could. And the market for the name would be driven by demand created by people who wanted to do something with the name amazon.com or wanted to use it to drive traffic to other existing websites.
It's clear that a good portion of the value of a domain in this type of after-market situation is in the content that that exists at a domain and the value created under that name previously. Also, there may be value in a shorter name or a more recognizable or memorable name. Paying for a premium domain might be worth while for some, because it can make you look better.
The best example I can think of this (for new .blog domains) is Seth's blog. Seth smartly snapped the domain Seths.blog. I would imagine it was expensive as domains go, but it makes sense because it matches his brand and it is much shorter than his old domain. And because he has a boatload of content already branded under the title seth's blog, so the short memorable title was valuable and he had the money to buy it.
So, why "supply and demand" and not supply and demand? Two reasons:
The registries still have a quasi monoply on the name, if my name is Jeffrey and I am starting a blog, I can't buy jeffrey.blog from just anyone - it ultimately is controlled by Autommattic and they set the price.
What's the value of a name, prior to having content attached to it? If amazon.com was owned by a Brazilian travel agency instead of the world's largest online store, it's value would be totally different. Every entrepeneur who looks at a name thinks of what they can change it in to, meaning that a crappy name could become a great name, with the right content or development. Surveymonkey.com, anyone? This scrambles this market a little bit.
So these registries have smartly designed an algorithm that prices shorter names higher, and must have some correlation with other names that get sold in other places. That's my guess, based on the following limited sample (as of May 3rd, 2019 from GoDaddy):
jonathan.blog costs $7000
jonathanfries.blog costs $9.99.
jeffrey.blog costs only $700.
I guess people named Jeffrey don't pay as much for domains.
I've written a few times about people saying 'this code sucks'. Most of the time the sucky code in question was written by somebody else - another employee or a different vendor.
On occasion it was written by the very person who is talking to me about it, usually 6 months or more in the past. That is always a fascinating conversation, but that is not what this blog is about. This blog is about the other situation - This Bad Code Was Written By Somebody Else And It Is Bad, Bad Code.
As a manager, I just believe now that every developer (yes, I'm talking about you team leads and architects) is always going to say that. Even people I trust.
Is that fair? Probably not.
Is it prejudicial? Yes.
Has anyone ever proven me wrong? Sometimes, but rarely.
Does it mean that the code is good? No, it doesn't.
But here's the thing. I've worked with tons of developers, some great, some good, some mediocre, but they're all pretty clever at some level. The cleverness manifests itself in all sorts of ways. Many of even the mediocre ones work hard and deliver working solutions to clients and bosses.
And of course clients and bosses appreciate things that work.
So if you think most code is junk you're probably seeing artifacts of something besides talent. What do you think it may be an artifcat of? Here's a great question: If we work with this client with this sloppy code base, what do we need to look out for?
Code can be a great artifact for thinking about that question.
Chances are, in the middle of the sloppy mess, as you call it, are some bits of brilliance or cleverness. Finding them will give you some indication of both the motivations of the original developer and of the business realities this code faces in the real world.
Telling me one good or interesting thing about the code would prove that you had read the code. Telling me two good or interesting things about the code would tell me that you probably have a good grasp on it.
Providing me, as a development manager, solid context for understanding that you have read and understand the code allows you to judge the code, and allows me as a manager more leeway to listen to you and understand your criticisms.
Here are my list of phrases and statments that cause me to judge people when I hear them without any further explanation:
*The code is fragile.
*This is spaghetti code.
*This was not designed properly.
*The code sucks.
*The code is over-engineered.
*The code is under-engineered.
*I make a change and it has unintended side effects.
The last one especially is a huge doozy to me. Unintended side effects? You're really just saying "I didn't read the code. And I don't understand it." In the worst case you're saying, "I don't know how to do my job very well."
When unjustified, all of those statements are smokescreens, avoidance, and hand waving. Even if you have a point, you aren't proving it.
How do you prove that you read the code? Well, pointing out a thing or two that is good can be helpful, but there are other ways, too.
Here are two that can be helpful if you're specific about it - Technical Debt and Code Smell.
If they're used generically they have the same problem (they're handing waving or avoidance or griping for the sake of griping), if they're used specifically they can be meaningful.
Before you start to talk about the 'bad code' you can use these types of statements to be much more specific.