Lambda LAN…Everyone’s invited.

Here we are in LABS32 everyone awaiting their assigned team/project. What did we get? What did we get? LAN-A? Wait a minute… Are we?

No, we aren’t headed to a friend’s basement to play our favorite game for the next 15 hours with 5 of our fellow gamers. We are building the Lambda Alumni Network. What is it? Lambda Alumni Network is a unified, private community for Lambda school alumni to connect, advance their careers, and provides an opportunity for alumni to give a little something back. Lambda as a teaching organization realized they were missing something, a network of connected alumni that could essentially become brand ambassadors for the company and pillars of support for their future graduates. Some may ask if this is necessary? Can’t we just use another platform? There are plenty of programs that we as Lambda School students interact with one another every day, for example, slack( for all your class info needs, lecture prompts, zoom meetings, after hours, help!) but I mean what happens when we graduate? LinkedIn, all of us have been busy polishing our resumes, re-uploading them, branching out our networks, but it isn’t exclusively ours. Lamba LAN will allow for communication on important factors for alumni in endorsement and outside of Lambda School, such as job opportunities, interview prep, events (hackathons, conferences, speaking opportunities, etc.)

Alumni Logo

On to the project. My main role during this project was identifying and solving bugs that were present within the current codebase. Our team was not building this application from scratch, we had inherited it from the LABS team before us, therefore we knew there were bound to be things that could be polished and refined. Our approach was to get acclimated with the existing codebase by walking through the application as a fully immersed end-user and document anything that we felt may not be functioning optimally. Quickly we learned of several bugs plaguing the application. One that I found myself specifically tasked with was solving an issue in which our discussion upvotes were incrementing incorrectly. As a user, you have the ability to upvote discussions that you like. Ideally, this should only be allowed once per user per discussion but we discovered that on a refresh of the browser it enabled the user to like the same discussion again.

example of our discussion component
example of our discussion component with an upvote

How did I fix it? I found myself walking through this code step by step examining both the front-end logic and the back-end data model. Was this an issue in the way we are sending data to the back-end or is the data not being normalized? For those of you not familiar with data normalization it is the process of structuring a database, usually a relational database, in accordance with a series of so-called normal forms in order to reduce data redundancy and improve data integrity. After thoroughly stepping through the code I was able to identify that the issue was not related to our front-end logic. Within our application, we have two slices of state being held in regards to this specific feature. “Likes”, which is storing the total likes of a particular discussion, and “liked” which is a toggle state that is checking whether the user has already liked a post or not.

on click handler checking for “liked” state and incrementing/decrementing “likes” accordingly

I then moved to the backend to check the data model. In our discussions table model, we were storing the total likes of each discussion but had no constraints to check whether or not a user had already liked a particular post therefore we were creating redundant data and unexpected behavior. Working in collaboration with one of our back-end developers we were able to implement some middleware to provide that user constraint. The middleware checks as to whether or not the user has already liked a particular post and if so will not allow the user to like the same post again.

middleware implementation

What is the current state of the Lambda LAN product?

During our tenure in LABS we were able to implement features including:

A more polished UI/UX which overall has enhanced the feeling of a functioning real world application

before and after of UI upgrades

Optimized moderation features including the addition of a roles table so that moderators can have different degrees of allowances.

Administrators and moderators can now pin and feature posts at the top of the forum.

What is the future of the Lambda LAN product?

Future features may include the ability to toggle between dark and light modes, adding time stamps to discussions so that the user can see when a discussion was originally created, and adding some sort of GIF or emoji library to enable our users to be more expressive in their discussions.

What Technical challenges do I forsee for the product?

One huge technical challenge I forsee the product facing is the reorganization and refactoring of the redux store. As the application scales larger the use of combineReducers would be highly recommended. The combineReducers helper function turns an object whose values are different reducing functions into a single reducing function you can pass to createStore. This refactoring will help maintain code readability and allow the application to scale easier.

Conclusion:

Labs was overall a great experience. The first opportunity of mine to really dive deep into some higher level problems and discuss them amongst my peers. I learned so much in regards to communicating effectively as a team in order to maintain a productive atmosphere. I look forward to seeing the Lambda LAN product evolve and progress to a polished fully functioning application that I myself will get the chance to use in the future.

Currently enrolled in the Full Stack Web Development program at Lambda School. Former Culinarian