From The Challenges - Grep

Welcome To Coding Challenges - From The Challenges!

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

I’m sharing 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.

But first, thank you to the IEEE for sponsoring this issue of Coding Challenges !

Unlock the Power of High Performance Computing with IEEE

Did you know that High Performance Computing (HPC) operates at speeds over a million times faster than the fastest commodity desktop, laptop, or server system in the market today? Start your online learning journey with the IEEE course on HPC and?explore supercomputer architectures, the era of computing and evolution of HPC, and more!?Get 50% off using the discount code?JOHN50.

Answering Your Questions About Coding Challenges Live

I’ve had a number of questions about the Coding Challenges Live series beginning with the?Redis edition . Particularly around timezones and attendance live versus watching the recordings.

So to clarify, it is a?cohort?based,?live, intensive course that runs for?one week. During the week you’ll implement a lite version of a?Redis server. As it is a live workshop where you write the code you need to attend live or you’re not going to get the benefit.

Secondly, the timezone is aligned with the US as most of the interest I had was from those timezones. If there is interest in a future cohort aligned to European or Asian timezones, please let me know.

Recapping The Grep Coding Challenge

In the build your own grep coding challenge the goal is to write your own implementation of grep. Grep is a Unix command line tool that searches any given input files, selecting lines that match one or more patterns.

Common Mistakes Software Engineers Make Solving the Grep Coding Challenge And Good Things They Do

I’ve pulled together this list of common mistakes and great things people do from the submissions I’ve been sent privately and those shared in the Coding Challenges Shared Solutions GitHub Repo or on LinkedIn / Twitter.

Mistake 1 - Not Building Your Own Regex Engine

Writing your regex engine is quite a significant bit of work and a huge learning opportunity. You’ll learn the regex grammar - making you a better user of it and you can learn about parsing and finite state machines. All of which are very useful skills for handling data - which is ultimately what a lot of software engineering ultimately boils down to.

If you’d like to dig into it, check out these two blog posts:

1. Implementing a Regular Expression Engine
2. How to build a regex engine from?scratch

You’re learn a lot about data structures and algorithms and their application to real-world software.

Mistake 2 - Not Allowing For Scale

A common mistake I see people making for all of the Unix command line tools like grep is to load the whole file into memory.

The problem with this approach is that it doesn’t scale, if someone tries to use the program on a large enough file the program crashes having run out of memory. This is entirely avoidable and relatively simple as nearly every tool only needs to parse the file a line at a time.

If you’re writing code to handle files, please remember to check you can handle large files. Sure it’s not easy to test this - you might not have the disk space for a 100GB test file for example, but there are ways around this. For example to test?sort?with a large file we can leverage the power of the Unix command line tools to generate one on the fly without actually taking up any disk space.

Here’s how:

seq 1 300000 | xargs -Inone cat test.txt | grep limitation        

Mistake 3 - Binary/Dependencies In Repo

This remains one of the most common mistakes I see software engineers make, both professionally and in solving the Coding Challenges.

Source code repos are for source code. Binaries do not belong in them. It should be possible to re-create the binary from the source code so there is no need for the binary. Equally it’s not obvious from a binary if the current binary is built from the current version of the code or an earlier version.

The same can be said for dependencies, they don’t belong in a source code repo. If you want to ensure they’re available, and carry out some level of security audit, consider a local mirror or proxy. There are many artefact repository tools that provide this functionality, i.e. JFrog’s Artifactory.

Great To See 1 - Use of Automated Testing

It was great to see that nearly all of the solutions included automated tests. Some were are a unit level and others tested the tool, running it against test input using BATS .

Great To See 2 - Good READMEs!

It was brilliant to see that the majority of the solutions include a README.md at the top level that explained how to use the solution and how to run the tests. Writing production software doesn’t stop at writing the code. Documentation is important too.

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.

Thanks and happy coding!

John

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

1. Refer a friend or colleague to the newsletter. ??
2. Buy one of my courses that walk you through a Coding Challenge.
3. Subscribe to the Coding Challenges YouTube channel !