My brother Mendy, who deserves some credit for opening my eyes to this world of CS, technology, and software development/engineering, built a neat little tool called Whatsapptistics. Check it out- you might learn something interesting about your chat habits ;) You can also take a look at his code here- if you’re interested in Go and AWS, you might enjoy sifting through the code base (or contributing).

When he told me he was going to build this thing as a side project, I really wanted to join. He utilized many of the Amazon Web Services for his back-end, and it would have been awesome to learn more about those tools. In addition, he programmed it using Go, and besides for wanting to get a feel for the language, there’s a lot I can learn from his coding style and practices alone. He makes decisions by considering many possible outcomes and use cases, limiting the amount of future effort, work, and time he’ll have to spend refactoring his code. For example, he designed Whatsapptistics with dependency injection in mind, so if someone wants to modify the code and use different dependencies, there will be minimal effort required on their part later.

Unfortunately between my course load and other commitments, I wasn’t able to find the time to build it with him, so a joint project will have to happen another day (hopefully really soon! I’ll post about it when it does). Instead, I helped him with a couple small issues, like adding a dotenv file for some hard-coded dependency values.

If you take a look at this post I stumbled upon here, you’ll learn a thing or two about environment variables, which basically gives you a way to ‘decouple configuration from the application’ and more. Its value is set outside the program (vs constants or regular variables), and at run-time, the reference to the environment variable name in the code gets replaced with its current set value. Doing it this way avoids us having to modify, test, or re-release an application (because it will often leave source code untouched) when configuration data changes.

After my brother pushed the first version of his code to GitHub, he noticed he had many dependencies with hard-coded values. He opened an issue suggesting we use some form of environment variables. I figured a simple way to do this would be to create a .env file, and use this handy godotenv autoload package, so that import _ “github.com/joho/gofotenv/autoload will read in the .env file on import, giving us easy access to the variables via Go’s own os package. This way we can use the variable in ways like os.Getenv("TOPIC_ARN”), with TOPIC_ARN being an environment variable.

I made a .env file and created names for the values I thought were suitable, and then used os.Getenv() in place of where the original global/constant variables were being used. And voilà, no more hard coded strings.

Although this little contribution wasn’t a big deal, it got me doing some reading about environment variables and related security vulnerabilities. It seems they are good for short term token style values, but if you have something you really want to keep secure, you should consider other options like those mentioned here.

While the project does a good job of following modern coding conventions and maintaining a high degree of modularity, it does lack integration tests and fails to parse some formats of the chat exports. It can use some more parser tests and should probably make use of table driven tests to test for a variety of formats. If you have ideas for the format parsing issue, or feel like helping out by adding some tests, any and all contributions would be welcome and appreciated :)

One of the reasons I found this hobby project really interesting is because it incorporates AWS, Golang, and some additional tools in a way that really utilizes them for what they were built for (and cleanly at that). I’m kind of jealous of the amount of knowledge he gained working on Whatsapptistics, but it’s good because it only makes me feel that much more motivated to accomplish more 😈.