profile

Hi, Iā€™m a creator

šŸ„§ Pie Mail - Taking it to the limit šŸ„§

Published over 2 years agoĀ ā€¢Ā 4 min read

ā€‹

Hello friend! It's pie-mail time again!

Sorry this one is late, it's been a bit of a week, work has been super busy, and my family has moved to a new city!

We're now in the amazing Bay of Plenty, if you're in the area please let me know, would love to link up with some people here!

Despite being busy, I had the chance to do this fun Quality Engineering interview with TestSigma - take a read and let me know what you think!

I also managed to hit some rate limits this week, so this weeks learning is all about rate limiting.

Enjoy, and as always, let me know if you anything you want to see more or less of!

ā€‹


šŸŒ Rate Limiting šŸŒ

The theme for me this week has been rate limiting!

I think it's a software technique that anyone in testing will come across at some point, so I figured, it's a good opportunity to talk a little bit about it.

Rate Limiting is a technique used to constrain the use of services. What does that mean? Maybe we should try an example. Imagine there's an API endpoint in a system that, for whatever reason, is a bit resource intensive.

Hitting this endpoint once is fine. But, what if some malicious person tries to take advantage of this - and use a script to hit this endpoint thousands of times at once?

This could then suck up all the resources of the system, making it unusable for other users.

This is where rate limiting comes in to play!

ā€‹

By limiting the number of times an endpoint can be called in a given time frame, attacks like this can be avoided.

A rate limit would work by adding some code that says "this endpoint can only be called three times per minute", or something like that. The frequency, and duration, will depend on the context of what you are doing.

Rate limiting isn't just important for load and performance safety either. If your product has the ability to send Email or SMS, for example, it's important to think about what limits are needed there too.

What would be the consequence, if a user could use your software to programmatically spam tens of thousands of people?

ā€‹

So, some questions you can ask when you're testing:

  • what will happen to the load on our system when an action is done on a large scale?
  • what other consequences could there be, allowing a user to perform an action on a large scale?
  • what are some reasonable limits that should be placed on an action?

Testing rate limits is a great opportunity to try out some neat load testing tools. I'm a fan of K6 and Locust, and I've just recently heard about DDoSify, which I'd love to have a play with!

Finally, here's something that happened to me back when the internet was a bit more of a 'wild west', and ideas like rate limiting weren't really well established yet...

ā€‹

āœØ Some interesting links āœØ

What I learned from the Phoenix Project

Olesia Martushkanova writes up some of the things she learned from reading The Phoenix Project - some great lessons, from a must read book!

ā€‹

Pushpay and Hypergrowth

It's no secret that I have a soft spot for Pushpay - I learned a lot about culture and engineering there. Bradley Scott talks to Josh Robb, Paul Shingles and Audrey Cheng about the early days. The section on "not building your own CRM" screams at me. (This is part one of a series, I'll link the next one when it's up!)

ā€‹

Team Topologies for Quality Engineering

I love this post from Anne-Marie Charrett around where Exploratory Testing sits in your teams structure and flow of work.

(Note, you need a paid membership for this one - but at $9 a year for this kind of content, it's a no brainer for me. Do yourself a favour and subscribe!)

ā€‹

Michael Bolton on mabl

Michael Bolton wrote an experience report on the testing tool mabl. It's detailed, and doesn't paint it in a positive light. But worth a read, for sure.

ā€‹

Empty String Considered Harmful

Sam Jarman writes about why using empty strings to indicate 'null' or 'no value' is a bad idea. I learned things!

ā€‹


šŸ‘· Job corner! šŸ‘·

Haven't posted one of these for a while, but there's an opportunity for a Senior QA Engineer at FirstAML (Auckland based role).

Opportunities like this don't come up very often, if you're looking to get in early on what will surely be a high-growth organisation, I'd recommend applying!

Use the link, or I can put you in touch.

(Not a sponsored post or anything)

ā€‹


šŸ‹ļø Exercise - Rate Limiting šŸ‹ļø

Not so much a 'puzzle' this week, as just something to play with.

I'm a big believer that 'messing about' with new ideas and tools is a great way to learn about them, so - here's a little app that has an endpoint, with a rate limit on it.

(it's adapted from a tutorial on section.io)

Fire up the app, and do some exploration. Hit the rate limit, change the values, see if you can use one of the aforementioned load testing tools to exercise it.

Have fun!

ā€‹


šŸŽŖ Events coming up šŸŽŖ

Security testing AMA (Nov 3)

Ministry of Testing and Saskia Copeland answer all your questions about security testing, risk management and more.

ā€‹

Selenium Grid and Docker Workshop (Nov 4)

Another one from Ministry of Testing, this time a free 99 minute workshop on getting Selenium Grid up and running with Docker - if you've ever been curious about trying these tools, this one is for you.

ā€‹

DIY: Visual Testing Workshop (Nov 10)

I mentioned this last time, but it seems to have been pushed back a week.

Ministry of Testing Auckland are bringing you this hands on workshop, teaching how to do visual testing using Applitools.

ā€‹

Full Stack Dev Workshops (Nov 19)

Full Stack Dev New Zealand are offering two free workshops later this month:

ā€‹One on Serverlessā€‹

ā€‹Another one on building a web storeā€‹

It's a Friday, so make time in your day to do one (or both) of these if you can!

ā€‹

TAU: The Homecoming (Dec 1 & 2)

ā€‹A celebratory event from Test Automation University - workshops and talks from some key people in the automation space. Definitely worth a look!

ā€‹


šŸ‘‹ Thanks for reading! šŸ‘‹

That's all folks! Hope you're all safe and well out there, the end of the year is in sight!

Take care, and reach out to me any time on LinkedIn or Twitter.

Cheers,

James a.k.a. JPie šŸ„§

ā€‹https://jpie.nzā€‹

Hi, Iā€™m a creator

Read more from Hi, Iā€™m a creator

Hi all! It's flooding and cyclones here in NZ, especially those in Auckland. I hope this email finds you safe - if you're being affected by bad weather, please stay inside until this all blows over! šŸ¤ COLAB Before we get too deep into it, I'd like to give a small shout out to COLAB. I had the chance to take part in COLABs Equitable Product cohort last year. It's eight weeks of conversation and learning with like talented peers; covering subjects like data ethics, accessibility, inclusion and...

about 1 year agoĀ ā€¢Ā 4 min read

Well hello there! Happy new year everybody. I hope you all had a good break, and are well rested heading in to the new year. I've had a good long time off, getting some rest after a busy 2022. I've found myself really eager to get back to work though, I'm looking forward to what 2023 will bring - I hope you are too! šŸ™‹ā™€ļø The value of dedicated testers In my last email, I wrote about the importance of engineers testing their work (and not just leaving it for testers). But this leaves an...

about 1 year agoĀ ā€¢Ā 4 min read

Welp, the end of the year is upon us! It's been a long and busy one. It's definitely been fun, but I'm ready for a break! I've had some interesting conversations over the last couple of weeks about quality, and the lines of responsibility - so - that's the subject of today's email. Enjoy, and see you in the new year! šŸ’» Programmers and Engineers My first job was in a busy office. Our office constantly seemed to have a dirty kitchen - a pretty common office problem. Instead of rinsing their...

over 1 year agoĀ ā€¢Ā 3 min read
Share this post