- Details
- Written by: Jason Ross
When your software has third party dependencies you’ll normally develop using the latest versions of those dependencies. This makes sense; the latest versions should have all of the latest features, bug fixes and security fixes, and during development it’s quite easy to handle upgrades to your dependencies.
Imagine then that you’ve developed a system, and you’ve released it. Of course, as you get closer to releasing your application you’ll generally fix the version numbers of the dependencies so that you can precisely control what gets deployed to your system.
Imagine your surprise then, when you run a build with some minor change, and it fails with a list of complaints about dependencies.
Or imagine you’re using a language like Python, where dependencies are downloaded during installation, and one day your installer suddenly starts failing even though it used to work. Again it’s complaining about dependencies.
What’s gone wrong?
- Details
- Written by: Jason Ross
Test code is an important part of the software development process – it can drastically improve the likelihood that the system that gets deployed actually does what it’s supposed to do. All of the test code, from unit tests through to acceptance and performance tests plays an important part in the validation of the system.
So, having gone to the trouble of creating all of these tests and watching as they help detect bugs in the system, it doesn’t seem to make sense to just dump them as soon as your code leaves the test environment. If the test code was useful in the development environments it should also be useful if you need to find bugs in production So obviously your test code should be included in the deployment packages and should be deployed alongside your software.
Or should it?
- Details
- Written by: Jason Ross
Most New Year’s Resolutions fail within the first few weeks of the year. Now that those weeks have passed, and you’re feeling bad about not exercising, eating that chocolate and washing it down with the beer or wine you promised you wouldn’t have, why not pick up a few suggestions that you MIGHT actually stick to?
- Details
- Written by: Jason Ross
In Updating An Old Web Site To HTML5 - Part 1 and Updating An Old Web Site To HTML5 - Part 2 - More Google Analytics "Opportunities" I described the initial updates I made to my site to bring it up to date. There are still plenty of things that Google Analytics and Google Search Console come up with so in this article I'll run through the ones that just won't go away - the image-related ones.
- Details
- Written by: Jason Ross
After I made the changes to my site described in Part 1 of this series of articles (Updating An Old Web Site To HTML5 - Part 1) most of the main warnings from Google Analytics went away, and the site settled down and seemed to be performing better in its new HTML5 form.
Then I received an email from Google telling me that my site was to have "Mobile First" indexing enabled, so that its indexing depended on how it rendered for Google's "Googlebot Smartphone" spider. Another change was that indexing would take the site's performance into account as well, with slower sites dropping down the rankings.
I waited until a few weeks after the change date to let the Analytics pick up the latest speed and HTML suggestions, and took another look to see what improvements I could make.
Read more: Updating An Old Web Site To HTML5 - Part 2 - More Google Analytics "Opportunities"
- Details
- Written by: Jason Ross
When you create a user in an AWS Cognito user pool using the AdminCreateUser API action, the email address you provide is not automatically flagged as verified. None of the lambdas that are called by other user creation or sign-up methods get called either. Why is this?
Without a verified email address, users cannot change their passwords again after changing from the temporary passwords that are assigned when the account is created. This isn't really too much of a problem, and the answer is even mentioned in the AWS documentation - either set the email_verified attribute to True in the call to AdminCreateUser, or use AdminUpdateUserAttributes to do the same thing.
However, when you follow the instructions and set the email_verified attribute of a user to True, you may see that the email_verified attribute of another user has been set to False, and the user is no longer verified, This happens even though you didn't tell Cognito to do anything. Why does it do this?
- Details
- Written by: Jason Ross
Sometimes you go away on vacation, then return to work and realize you've forgotten your password. Typically if you're working for a big company, you contact the IT department and they can help you. They'll usually reset your password and, if you're stuck at the login screen and can't reach your email, they'll tell you what the temporary password is while you're on the phone. That's usually enough to let you log on to your computer once, and immediately change the password to one that only you know.
But what happens if you're using an authentication system that doesn't let administrators reset passwords to a known value, something like, say, Cognito? If you need to reset a password to a known value for a user in a user pool, you've got a problem.
Read more: Amazon Cognito Peculiarities 1 - Reset A User Password To A Known Value
