Stop Checking the Moving Averages; Get Notified through Go, AWS Lambda & Telegram!

Blending Technology, Data & Technical Analysis Indicators

Candlesticks {Photo by Maxim Hopman on Unsplash}

Using Moving Averages in the Context of Short/Mid-term Investing

Before we go further on the use of technical analysis (TA) indicators, I strongly encourage that you read my previous post — An Opinionated Framework on Personal Finance, to understand the context and framework I have. This post is as much a sharing on my thoughts and practices of using moving averages for short/mid-term investments, as it is about software engineering and architecture. More importantly, I recently decided that it was just too much hassle to check TA indicators manually, and as an engineer at heart, I need to automate this process and get notified instead!

There are tons of resources out there, of varying technical detail and sophistication, that tries to explain the concepts and utility of simple moving averages (SMA). However, I want to describe 3 key concepts about how I think and use the SMA, before going on to the subsequent chapters to cover the cloud technologies I set up over the week to get notified every day over the Telegram chatgroup — EzStockIndicators. Feel free to join too!

My 3 key concepts about SMAs are:

1. What is a SMA?
   Simply, it’s the average price of a stock over a set period of time (e.g. a 50-day SMA is a stock’s average closing price over the previous 50 days). SMA is typically considered a lagging indicator.
2. What is the significance of the 50-day and 200-day SMA?
   The 50-day and 200-day SMA are some of the most commonly used TAs in stock trading. They are often used by traders to observe the market’s momentum and calculate the best time to enter and exit an asset. At face value, it might seem odd to believe that TAs have any bearing on the stock markets. However, due to their popularity, my take is that such TAs have psychological effects on market participants and often trigger self-fulfilling prophecies.
3. How do I use the 50-day and 200-day SMA?
   As a rule of thumb, these are not buy/sell signals, but additional data points to inform my decisions to make an entry/exit on a position (you might be interested in my other post on Going from Data to Ta-da!). I typically use the 50- and 200-day SMAs in 3 ways:
   a) Understand near-term and longer-term bullish/bearish sentiment of the market. A stock’s price above the 50-day SMA is usually considered near-term bullish, while prices below the 50-day SMA is usually considered near-term bearish. A similar logic applies for the 200-day SMA. The difference is that the 200-day SMA signifies a much longer-term trend.
   b) Enter/exit position in a range-bound market. If the price meets the 50-day SMA as support and bounces upwards, consider a long entry. When the inverse happens, consider a short entry. Use the 200-day SMA for longer-term plays.
   b) Spot incoming Golden Cross. This occurs when the 50-day SMA crosses the 200-day SMA to the upside and is typically considered a strong bullish signal. Unfortunately, as the SMAs are lagging indicators, calculated risk and action should be taken before the fact.

Getting Notified with a Concoction of Go, Amazon Web Services (AWS) Offerings, and Telegram Services

With the introduction of SMAs out of the way, it’s time to get a little more technical. As mentioned earlier, I just found it too troublesome to manually check SMAs. Instead, I want to get notified automatically. I also wanted to learn and do something new this week and continue to “sharpen the saw” and stay technical and relevant as a leader in an engineering unit. I spent the week (scrapping whatever time I had at night) writing Go codes, understanding and assembling various AWS offerings, and making use of Telegram services to get twice daily notifications of SMAs of the S&P 500 and other major US stock tickers.

In the spirit of learning, I’m documenting what transpired behind the scenes and reflections as I completed the week-long exercise. I’ll be most happy to hear your feedback, comments and thoughts on what I’ve done and improvements I could make. Nonetheless, the result is an architecture as shown in the image below, and a Telegram chatgroup — EzStockIndicators. Essentially, the architecture seeks to achieve 2 goals:

1. Send stock quotes and SMAs to Telegram twice daily
2. Use Telegram (as a user interface) to process and display stock quotes and SMAs

Architecture of Serverless Notification Service (of Stock Technical Indicators) using AWS and Telegram Services {Desmond Loh}

Sending Stock Quotes and Simple Moving Averages to Telegram

With the goal defined, I went on to explore the various offerings by AWS. While I knew I would be able to get the job done with AWS, I was pleasantly surprised that the entire solution could be completed and maintained with just the free tier😄. Below are the tools, resources that I used, and some of the thought process and my rationale for the choices I made:

1. Function written in Go (or Golang). My primary goal was learning, hence the choice of Go. It’s also supposed to be simple to learn, intuitive (i.e. easy to maintain/handover), fast to execute, and designed with scaling/concurrency in mind. The function I wrote simply gets the stock quote and SMAs from Yahoo Finance and sends them to Telegram via the Telegram Bot APIs (explained in the next chapter).
2. VSCode & AWS Toolkit for VSCode. It’s free and offers really good support and extensions for many languages and ecosystems. The credentials to your AWS account can be managed by the AWS Toolkit.
   - Visual Studio Code
   - AWS Toolkit for Visual Studio Code
3. AWS Lambda. This is Amazon’s serverless technology offering. It provides the compute service to run my function without me having to understand, create and maintain any server. This was a key consideration in my architecture right from the start.
   - AWS Lambda for Go library
   - Working with serverless applications (using AWS Toolkit for VS Code)
4. Amazon EventBridge. A scheduling service that I used to call my function twice a day (think Cron job 😅).
   - Creating an Amazon EventBridge rule that runs on a schedule
5. S3, CloudFormation, CloudWatch, IAM. These were pretty much complementary services that were required to run, manage and deploy my function efficiently and securely.
   - S3 stores the codes, libraries, and other assets
   - CloudFormation automates the deployment of codes and other resources with infra-as-code
   - CloudWatch provides logs and metrics managements
   - IAM manages identities & access control

Using Telegram to Process and Display Stock Quotes and Simple Moving Averages

With the serverless function pumping out stock quotes and SMAs twice daily, all I needed was a user interface (UI) to receive and display the information. Telegram was a natural platform to consider. It is used widely, does not require me to code a UI from scratch, has APIs for my function to interact with, and is free! Fortunately, the Telegram ecosystem was less complex. Similarly, here are the tools and resources I found useful:

1. Telegram Bot API. This was essential for my AWS Lambda function to interact with and have the data sent over to Telegram.
   - Bots: An introduction for developers (telegram.org)
   - How do I create a Bot? (telegram.org)
   - Getting started with Go Telegram Bot API
   - Golang bindings for the Telegram Bot API
2. Telegram Group Chat. Since I wanted to share this service with like-minded people, I needed a group chat with the Bot as a member to push the notifications into the chat.
   - Stack Overflow — how to get a group chat id?
3. Environment Variables. Last but not least, I make use of environment variables to store the token to my Telegram Bot that is accessible to the AWS lambda function. I chose environment variables as it simple and avoids the use of config files that could be accidentally committed into GitHub.
   - Using Powershell on Windows (for my development): “[Environment]::SetEnvironmentVariable(‘<key used in code>’, ‘<actual token value>’, ‘Machine’)”
   - On AWS Lambda: Using AWS Lambda environment variables (amazon.com)

Reflecting on the Exercise

I’m used to self-hosted solutions in my organisation. The first and most apparent observation was the comparatively lesser effort and time needed to complete everything. It took me about 10–12 hours (despite endless interruptions at home) to understand, learn, assemble the various cloud technologies, and code my serverless function. In the self-hosted world, this is fast. Really fast.

My second reflection is that we need to value our DevOps engineers a lot more. The majority of my time and energy was spent on provisioning, platform and DevOps toolchain management, and configuration management. I haven’t even gotten around to setting up my GitHub repository. Another fun fact — the lines of code that I wrote is about 60, which is even less that this post.

I want to conclude on the point of learning, the impetus for why I even started this exercise. I think we all know it’s important to always be learning and exploring. However, we often focus on the Inputs (e.g. reading a book, listening to a podcast, watching a video), but neglect spending quality time on the Outputs to really internalise the knowledge. Outputs could take many forms, such as reflecting, sharing the new knowledge to others (like writing a Medium post), practicing. Some studies even indicate that we should spend at least twice the time on Outputs than Inputs!

Finally, I thought it was only apt that I end with the wisdom of Confucius.
Until the next post!

“I hear and I forget. I see and I remember. I do and I understand.” — Confucius <Doctrine of the Mean>

吾听吾忘,吾见吾记,吾做吾悟 — 孔子《中庸》