Skip to main content

Saying it "Out Loud"

    If, for no one else, this post may wind up mostly for me. In that, I'm not trying to use it to communicate new information to you; I'm trying to keep track for myself, as a reference, a set of steps I've been instructed to take by another blog post. But, if it's not for other folks to read, why publish it at all? Well, the honest answer is: I also hope it can positively show my workflow, etc, in case someone else is looking to inspect my skills. Because, you see, it was a potential employer who sent me down this rabbit hole.

Time to put my thinking cap on.

    I should take a step back. In general, since my time in FlatIron School's Software Engineering Course, I have been really eager to keep my "backend" skills sharp, and been searching equally for "Frontend","Full Stack" and "Backend" entry level positions. Then, a company with a backend position got back to me :o
    But, their Technical Interview is not at all what I expected. I didn't have to return an email, I didn't have to fill out a form, I didn't have to answer even generic survey questions about a "challenging experience" and how I got through it. Instead: I need to build a JSON API in (Ruby-on-)Rails.

    Wait, what? I have to build a JSON server? Huh? I mean, I know I did that...but that was so long ago, and not in Rails, and also I thought backend was not the same as "Architecture", where I would need to be in charge of...everything! I thought they might only ask me for a series of commands and how to execute them (which, to be fair, I believe the "second half" of the same technical interview focuses on). 
    But, I quickly realized that my apprehension and anxiety around this assignment stems specifically from my apprehension and anxiety around architecture (as well as sys-admin work, port configuration, and other high level things, etc). So, what better way to conquer that anxiety than to dive right in!

    Which brings me back to my first paragraph: this post will be published immediately (as of 7:45PM on Mar 31, 2022). And, as an outsider, or someone not interested in reading through my trials nor tribulations of setting up a JSON server (let alone someone uninterested in whatever bugs or errors I may encounter in differences between Rails5 & Rails6), consider it finished!
    But, if any of those things sound interesting: feel free to come back! Soon, as this assignment is not supposed to be endless (they do want to read and evaluate it quickly, after all). And I'll keep you all posted on how it goes for me.

Wish me luck!
-----------------

04/03/22, an Update, and a Conclusion of Sorts:

I'm pleasantly surprised to say that this project (and, by association, this blog post), when more smoothly, and are over more quickly, than I had expected/anticipated. Which is not to say that I didn't learn a lot.
To start, I learned about some pretty nifty Ruby gems. For example, there was Shoulda Matchers, which is used to help write tests in much simpler terms. There was also JSON:API whose sole purpose is, you guessed it, to help programmers configure their data to be conveyed as JSON from an API. But ultimately, I decided to get started on the "real" test sooner than all that. Why?
Well, at a certain point, it hit me: configuring a JSON server with Rails isn't scary or foreign to me. I don't need to worry about the architecture or the configuration commands - it's literally something I've now done dozens of times.
I don't know why, but it took until I was reading the details around the JSON:API gem for me to realize: I don't need a special gem to do that. I don't need special configuration either. A JSON API is what I'm used to fetching from - it's what I'm used to setting up! Somehow it took my getting in that deep for me to realize that I was the one over-complicating it.
So, with these few paragraphs, I am slightly richer for the experience, and my GitHub stack is slightly fatter - and I also have a slight preview of what's ahead. For example, the initial "tutorial" (which, fwiw, is out of date by its own admission, as it's two years old and made for Rails 5) got into error handling within the controller. I didn't get that far in the practice - but I'm very excited to see if the actual assignment will also ask us to dive that deep (giving me the excuse, if nothing else, to look up some more contemporary syntax).

Again: wish me luck!!

Comments

Post a Comment

Popular posts from this blog

If It Ain't Broke...

     I write you now, on a blog that was created as a requirement for a class, as a Graduate of that class ( hooray! ). But, like all good things in life, this space as an idea for musings has taken on a life of its own, and so I feel compelled to share another thought from the tech world I had: when did Gmail become the standard for online email? Seriously - in the Career Services literature that's given to every student following said class, this office - in charge of helping students find work in the field of technology - has this ("hot") take:  Email Address(es) : Should be @gmail.com @me.com or @customdomain. Avoid AOL, Hotmail or Yahoo email accounts because employers may view users with those accounts as out-of-touch or not tech savvy.     Reading this, I felt the sting of injustice (actually, more like embarrassment). I use a Yahoo email account! In fact - I have since high school! And what's wrong with that? It works just fine! And as my Grandpapp...
Post a Comment
Read more

The Power Paradigm: Metaverse edition

      This blog post will be slightly off the kilter of my usual writing. Not that I don't want it to be funny or engaging, but I'm not writing it with the same lighthearted intention that I've written about other, less-consequential topics like how to create tally marks or what I made my first website about. This post is also meant to be less results-oriented; there's no final product I want to show off or "behind the scenes" descriptor I'm writing. Instead, I want to use this entry as a jumping off point for discussing an issue that seems to be plaguing every aspect of society nowadays: the rise and dominance and social destruction as a result of: Facebook.     But, in particular, I've been curious: what role has their software-baby, ReactJS, played in this power struggle? It's been a hard question to answer definitively. For one, news coverage seems very intently focused on "one side" or "the other":     -It's very easy t...
Post a Comment
Read more

Tales From the Other Side: e.stopPropagation();

 Hello Readers,      Greetings from a chilly November day in New York. The kind of day that forces you to forget that Fall is after Summer, and to remember that Fall is before Winter. The kind of day that makes one glad they spent several years in Vermont and now have several tricks up their sleeve. Namely: warm socks and vigorous walking . But I digress.     The first 'tale from the other side' that I wanted to share is actually the one I was most excited about (in real time!) when I learned about it. Spoiler alert from the title: it's the event.stopPropagation() javascript method. So...what the heck is it?     Well, here's a few things about it: It's a native Javascript method, so there's no extra libraries, packages, components, syntaxes, etc to import. It's in the same 'family' as event.preventDefault() , so those familiar with other common event handlers may already have a sense of where it can be called. Think about all the ways...
Post a Comment
Read more