From The Challenges - Chat Client and 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 86,723 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📧

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! 😀

Recapping The Chat Client and Server Coding Challenge

In the build your chat client and server coding challenge the goal was to write your own real-time chat server and client.

The server is able to support multiple client connections. Every time a client sends a message to the server, the server distributes the message to all the connected clients except the sender.

📌 Next Systems Programming (Redis) Course Starts 14th July

Would you like to build a network server from scratch with me?

Learning about network programming, concurrency, testing, and systems software development?

If so check out my course: Build A Redis Server Clone: Master Systems Programming Through Practice.

It is designed to be intense! It’s 11 hours of instructor time over two weeks. With the goal of having you build a clone of the original Redis server by the end of the two weeks.

If you sign up before 30th June you can get $100 off using the code: EARLYBLIJ

If You Enjoy Coding Challenges Here Are Three 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 ☕️, 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.

Five Common Mistakes Software Engineers Make Solving the Chat Client and 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 - Using A Pub-Sub Tool To Handle Passing The Messages

The idea of this challenge is to learn to build a network server using the sockets API and then to implement a simple protocol and client and server on top of it. If you use a middleware product that does the publishing and subscribing for you, you miss out on a key part of the learning experience.

Mistake 2 - Creating Multiple Programs, One For Each Client

A network client program should be user configurable, you should be able to subscribe a client for a protocol to any server that ‘speaks” that protocol. You should also be able to run multiple instances of the client to create separate distinct connections. You should not need to compile a separate binary for each client.

To avoid that, ensure that the client program takes either command line arguments or another form of user input to allow configuration of the server address and port number as well as any specific config or commands.

Mistake 3 - Not Using RAII Or Equivalent To Manage Resources

When ensuring resources (sockets, files, memory) are going to be correctly closed/released in the event of errors, try, finally works, but it is easy to make a mistake. Where possible, if the language you are using supports the Resource Acquisition Is Initialisation (RAII) idiom, use the support for it.

Mistake 4 - Not Ensuring Resources Are Closed / Released

Be aware of exceptions and errors that could occur and ensure that in the event of an exception or error any sockets / files / memory that is in use and no longer require/in a known state, are closed / freed if an exceptions or error occurs.

For languages that support a RAII style idiom, use that where possible, in other instances make use of try, catch, finally clauses.

Mistake 5 - Don’t Index State Using A Mutable Id

Be careful not to index any of the state in a server against an value that a client could change. For example in this coding challenge if your server keeps a list of client connections, don’t index them by the username of a client connection’s user. The user could change their username during the session which would invalidate the data the server is using. Instead use something that is immutable / guaranteed not to change, i.e. the client’s IP address.

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!