I’m Vishisht Makkar, a BTech Computer Science + MS Economics (Integrated program) student at Jawaharlal Nehru University, New Delhi. This blog was written at the end-point of the internship I did during the summer of ‘23.
“ Our programming paradigm is changing. If that sentence doesn’t scare you,
let me try again. The rules that govern typical everyday programming are
changing. That doesn’t happen often. When it does, something important is
going on. ”
– from the book “Learn Functional Programming with Elixir by Ulisses Almeida”
This summer, I was fortunate enough to gain experience in this new paradigm of functional programming (Elixir) by interning with Project Tech4Dev. I applied through the Code for Gov Tech ’23 platform, which aims to foster an open source community around Digital Public Goods (open-source software for sustainable development).
How I got in is an interesting roller-coaster journey in its own right, and I have written about it in my previous blog. In this one, I’ll mainly be walking you through my project and the challenges I faced along the way.
About the Tech: Elixir, Erlang, LiveView
Elixir is a functional programming language, as opposed to the object-oriented languages we’re all used to like Python and C++. To code in it required me to fundamentally approach problems differently, and this rethinking was both challenging and very rewarding.
It is built on top of, and depends heavily on Erlang, a general purpose development platform that provides special support for concurrency, scalability, fault-tolerance, distribution and high availability.
In fact, Erlang has been powering telecom systems since the 80s, where such qualities are required.
My project specifically focused on using a library of Elixir: Phoenix LiveView, which is a framework for building single-page flows on the web. It helps create apps that are interactive and very resistant to failure.
Instead of a direct request-response cycle, LiveView holds state with something called a socket in a long-lived process that loops through a set of steps continuously. The application receives events, changes the state, and then renders the state, over and over.
My Project: Internal Dashboard
My organization, Project Tech4Dev, works on creating Tech that enables NGOs to have a wider impact. As part of the internship, I had to work on a general purpose, interactive and real-time dashboard that would enable NGOs to visualize their data and impact at a glance.
This dashboard was a part of Glific, an app that mainly lets NGOs create conversation flows and automate them for their clients.
Issues I worked on:
The first issue I worked on, perhaps as a warmup, and unrelated to the project, was to create an API. Glific uses a service called Gupshup to send template messages that are approved by WhatsApp. Gupshup had created their API to edit approved templates, and I had to create a Glific API that worked with our frontend, our DB and with their API.
After this, I created several PRs making various charts and tables. On the way, my project partner and I realized that it was perhaps not the best idea to call JS hooks to render charts when we’re working with LiveView and instead look for something more “pure” that utilized LiveView’s strengths. But things were going smoothly, and as such, if it ain’t broke, why mess with it?
It was when I was working on the issue of filters (the ability to filter charts to only display data in a certain date range) that I couldn’t make Chart.js hooks re-render after filtering and realized that this approach isn’t working anymore. I created an experimental branch on my own and tried out a new library called “ContEx” to render charts. I call it “new”, both in the sense that it was new for our app, but also because it’s fairly newly developed. It has limited capabilities, and limited documentation.
As such, exploring how it worked (with a lot of IO.inspect()) and making it fit in with our existing code was a challenge I had the most fun with during the entire internship period. It stores chart data in the socket in the SVG format, and therefore, utilizes the core strength of LiveView of re-rendering automatically when something in the socket changes.
I also worked on a feature that enables chart data to be exported as CSV. And of course, after switching to ContEx, building chart filters was extremely satisfying and fun.
What I want to stress on is how much I appreciate the approach my mentor Akhilesh used when assigning issues. We were just given a high-level description of what to do, without many details, and were left to find out the rest ourselves. Finding out the right files, right functions, and figuring out on my own how everything interconnected in such a large codebase was a process I really enjoyed. It would have been much more boring if we were spoonfed the files and functions to work on. Of course, when stuck, he was extremely patient and very generous with his time in helping us understand things. This mix of freedom and support is what I really liked.
To conclude, I’m very grateful for
- the opportunity to work in an organization whose values I really believe in (enabling Tech for NGOs),
- being a part of the Glific Sprint at Udaipur, and the lessons, memories and friends I made during it,
- and most importantly, to be able to make open-source contributions using Elixir, work with and understand a large codebase, and see my code go to production.
Frankly, it’s also worth noting how great the work culture is at this startup. Everybody is just extremely nice to each other. There is an atmosphere of collaboration, not competition. Everybody is on a first-name basis. Nobody calls each other Sir/Ma’am. It was almost unbelievable for me to simply have a nice conversation with the CEO at lunch and refer to her by her first name “Erica”. This humbleness and spirit of collaboration makes everybody very approachable and welcoming. It incredibly accelerates learning in my opinion, because you can learn a lot more from somebody you can easily approach and talk to.