One Word

One Word

"Our words. They describe us and inspire us. They fuel us and drive us. When we put our words together they have the power to bond us like never before. Behind every word is a person with goals and dreams. And behind each of them is a company of people committed to pushing each other to make those dreams a reality. That’s why we celebrate our words, and post them for the world to see. Individually, we are as good as our word. But together, we are so much better."

Last year, we were asked to build this site. The development ended up going to our office in London, although they had me write the backend admin for approving submissions.

This year, the ask was to allow word submissions for each year. No problem! But the developer who built the site was no longer at the agency. My boss came to me and said, "Here's the spec, can you do this?" Sure, I'll take a look.

Three code repositories (one was mine, so two new to me). Hmm. React. I use Vuejs. MongoDB. Ok, I have a strong background in RDBMS. Let's look at the API. Node server. Hmmm, haven't worked with that. Requirements were very clear. Good. I went through the code to see what needed to change. The code was beautiful. Kudos to they guy who wrote it. Everything was easy to find.

But other work beckoned. Stuff with deadlines and paying clients. So the project was handed over to another developer. He got exactly what I got but with file names with line numbers of what needed to change, and a description of the remaining question - how do you make this "relational."

A month goes by and in a status meeting I'm informed that they're asking about this project, we need to get this done. So it comes back to me. OK MONGO - IT'S ON!

Each person has one word. Now they can have many. The big remaining question is how do you store this? My RDBMS background wanted to add a new document. My gut said, no. So I opted for a subdocument within the user document. That seemed like the NoSQL way to go. Every find had to be changed to an aggregate. Most of the changes were cosmetic and pretty easy to do, but I did have to re-write every single query.

Now the admin portion. I wrote that in Laravel because that's what I'm really good at. For a non-paying job you pick the fastest tool. But Eloquent is really geared to relational databases rather than NoSQL databases. With a little bit of mindset change, I got that done.

OK - now to put it up on a server for review. Wait, what? I don't have access to the staging server. OK - so I built a server. Let's set this up. Wait, nginx? My background is Apache. OK, let's deploy. The other agency was using Jenkins. We don't. OK. This can live without a deployment server. Hmm. Now how do you start this thing, this node server running through a proxy port on nginx? And how do you make sure this thing restarts on reboot? Let me just say, I love Google.

It's done. It's live. It appears to work as intended. I love learning new things. But, wow, that was a lot of new things to learn at once. And being the only one working on the development I got to be an analyst, front-end developer, back-end developer, database developer, and system administrator.

I’m bummed I can’t “Love” this.

Like
Reply

The 'new document vs. sub-document' dilemma has been tricky for me, as well. Great story!

To view or add a comment, sign in

Others also viewed

Explore content categories