From The Challenges - Memcached Server

Exploring the software engineering lessons we can learn from the solutions I've seen.

Hi this is John with this week’s Coding Challenge.

🙏 Thank you for being one of the 78,172 software developers who have subscribed, I’m honoured to have you as a reader. 🎉

If there is a Coding Challenge you’d like to see, please let me know by replying to this email📧

🎉 🥳 Happy Birthday Coding Challenges - Two Years Old! 🥳 🎉

Coding Challenges is turning two this week! To celebrate I’m running a special offer for this weekend:

• Get 30% off build your own Redis Server in Python or Go - use the code: CCTURNS2

• Get 20% off when you book any live cohort course, booking is now open for Learn Go With Projects (running in April and June) and Build A Redis Server: Master Systems Programming Through Practice (running in March, July and October). Use the code: CC2YEAROLD

All discounts valid until end of day Sunday 16th March!

Welcome To Coding Challenges - From The Challenges!

In this Coding Challenges “from the challenges” newsletter I’m sharing some of the common mistakes I see software engineers make when tackling the Coding Challenges.

I’m sharing both the mistakes people make and some thoughts on how you can you avoid making the same mistakes when taking on the coding challenges or when writing software professionally. Sometimes we have to make mistakes to learn from them, somethings we can learn from other people’s mistakes, then make our own new ones! 😀

Learn Go By Building Projects - Live With Me!

I’m launching a new course: Learn Go By Building: Master The Go Programming Language By Building Real Projects on the 7th April.

Over three weeks I’ll teach you Golang and walk you through how to complete five real-world projects using Go.

The projects are all based of past Coding Challenges, they are:

• cat

• sort

• curl

• wc

• Memcached server

If you’d like to learn Go, by building these projects you can read the full description of the course here.

As it’s a new course I’m offering anyone who signs up before 24th March 20% off! Use the code: LEARGOEBCCM when signing up.

Recapping The Memcached Server Coding Challenge

In the build your own Memcached server coding challenge the goal was to write a clone of the Memcached server.

Memcached is a free, open source, high-performance, distributed memory object caching system. It is intended for use in speeding up dynamic web applications by reducing database load.

Memcached is used as an in-memory key-value store for small chunks of arbitrary data retrieved from back end systems with higher latency. Like many useful software solutions, it is simple yet powerful.

Its simple design promotes quick deployment, ease of development, and solves many problems facing large data caches. Its relatively simple API is available for most popular languages. Plus the protocol is relatively simple to implement if there isn’t an API in your language.

Memcached was originally developed by Brad Fitzpatrick for LiveJournal in 2003. He originally wrote it in Perl and it was later ported to C.

Building a Memcached server is the capstone project in my upcoming Learn Go By Building course.

Five Common Mistakes Software Engineers Make Solving the Memcached Server Coding Challenge

I’ve pulled together this list of common mistakes from the hundreds of submissions I’ve been sent privately and the many shared in the Coding Challenges Shared Solutions GitHub Repo.

Mistake 1 - Treating TCP As Discrete Messages Rather Than A Stream Of Data

TCP is a streaming protocol when you a receiving data from a TCP connection you’re reading from the stream, you’re not guaranteed to be reading a full message, that starts at the beginning of your read and finishes and the end of it.

Consider this simple Python code. Note you’ll be using the same recv call in most other programming languages as they’re all wrappers around the Berkley sockets implementation for your operating system.

data = client_socket.recv(4096)

This call to recv on the socket will get back between zero and 4096 bytes. Assuming it got more than zero bytes then data will containe one of the following:

• A partial message.

• A full message - something we’ll often see when developing and testing with small messages on a local network, meaning inexperienced software engineers often miss subtle bugs because they don’t handle the other cases listed here.

• A full message followed by a partial message.

• A partial message followed by either a partial or a full message.

• Combinations of the above.

In short the data we get back is a window on a stream of data being sent to the server. It might help to visualise this:

So a key part of writing a TCP based server is to ensure you’re correctly identifying the start and end of a message in the stream, given you’re reading just a window into it.

N.B. You can’t just call recv() passing in the size of a message for several reasons:

1. The message might not be fixed size. In the case of Memcached they’re not.

2. Even if they are fixed size, they might still be sent as multiple smaller messages ‘over the wire’.

   TCP is a stream of data, but it’s built on top of a lower level protocol, such as Ethernet or IP. As a result only part of a message might have been received by the server’s network stack when you call recv(), the rest might still be in flight between the server and the client.

This is something I cover in depth in my course Build A Redis Server: Master Systems Programming Through Practice.

Mistake 2 - URLs In Comments With No Context

I came across several solutions that contained comments (good), but the comments were often just links to a Stack Overflow post, with no context provided. It’s great that the source of something was linked, I’d however urge you to also explain why it was linked. What can people find at the link and why is it relevant?

Mistake 3 - No Tests

Rust and Go make it so easy to write and run tests, Python has several great testing frameworks as does Java, C++, C and many other languages. Please use them. This will help ensure your code works, help avoid regressions in future and now, in light of the rise of AI in software engineering, it seems like a good idea to strengthen your testing skills. Consider this:

“Everyone will need to get a lot more serious about testing and reviewing code” — Steve Yegge

In other words if AI is going to take over writing code in many software development organisations, the ability to review and test that code will become a key skillset to have. I still think that’s a big if, but it’s certainly going to be used, so getting better at reviewing and testing code is going to be a worthwhile investment of our time.

Mistake 4 - 100+ Line Long Functions

I came across a couple of functions in several solutions that were hundreds of lines long. There isn’t a right answer to how long a function should be, nor are 100+ line functions necessarily bad.

However as Kent Beck recently observed: “Regardless of how long functions start out, they’re going to grow.” you can read more in his recent post How Long Should Functions Be?

Mistake 5 - Hard Coded Magic Values

A magic value is a unique value with no obvious meaning. Magic value are one of the oldest anti-patterns in software programming. They’re a problem because they obscure the programmer’s intent.

Instead of magic value it’s better to use named constant variables, where the name makes it clear what the constant refers to. In this coding challenge common magic values were the host, port and the commands.

Request for Feedback

I’m writing these coding challenges and this new from the challenges series to help you develop your skills as a software engineer based on how I’ve approached my own personal learning and development.

What works for me, might not be the best way for you - so if you have suggestions for how I can make these challenges more useful to you and others, please get in touch and let me know. All feedback greatly appreciated.

You can reach me on Bluesky, LinkedIn or through SubStack

Thanks and happy coding!

John

P.S. If You Enjoy Coding Challenges Here Are Four Ways You Can Help Support It

1. Refer a friend or colleague to the newsletter. 🙏

2. Sign up for a paid subscription - think of it as buying me a coffee ☕️ twice a month, with the bonus that you also get 20% off any of my courses.

3. Buy one of my courses that walk you through a Coding Challenge.

4. Subscribe to the Coding Challenges YouTube channel!