Hello again, Software for Good readers! It’s nice to be back on this blog.
As you probably don’t remember, I was last year’s resident word nerd at Software for Good. Since leaving, I’ve moved far from snowy Minnesota, enrolled in a software development school, and built some pretty wild programs that I never thought were possible.
I could write a whole post entirely about Software for Good’s support as I’ve journeyed down this web dev path. Instead, I’ll just say wholeheartedly that every success I have is thanks to their examples and encouragement. The team showed me that writing code is so much more than just cranking on keyboards. That building an app is a tedious yet enthralling process. That design should drive not only the front-end experience but also the back-end architecture.
Most memorably?
That tech vernacular is ridiculous, hilarious, and largely unintelligible to folks outside the know.
Below, I present to you a section from my official “Overheard at Software for Good” document, also known as the list that encouraged me to pursue software development because I legitimately had no idea what my coworkers were ever talking about.
On Unicorns
“Restart the unicorns.”
“So, it’s not just unicorns we’re talking about now.”
“Ahh, it was a zombie unicorn issue.”
“Kick the unicorns down!”
“In any case, it’s easy peasy. Just add another unicorn.”
“You need some unicorn action up in here.”
“Which unicorn?”
“I just kicked the unicorn. No good.”
“Unicorn kicked. Seems good now.”
“I haven’t bumped the unicorns yet.”
“Bouncing unicorns. I’m trying to bounce unicorns.”
“Yeah, I bounced the unicorns. I bounce the unicorns about once a day.”
“The unicorns are sad.”
“If I restart the unicorns, it works fine!”
“The unicorns just don’t respond. They just sit there and do nothing.”
Yep. From an outside perspective, Software for Good is an office full of people who abuse unicorns. Sorry, Peter.
What can I tell you now about unicorns? Here’s what I gather:
Unicorn is an HTTP server for Rack applications. It makes fast things move even faster. From what I understand, the main crux of Unicorn is that it splits up tasks, placing the focus on one major port, then delegating all other client requests to forked worker processes.
Pause. Forked? Not the utensil. Basically, something that’s been forked is something that was created as an independent entity simply by copying the entirety of something else. So, if you take this blog post, copy it, post it to your own blog and make a few changes, you’ll have a kind of a “forked” version of the original. (Please don’t actually do this.)
Anyway, within those forks, Unicorn finds and restarts broken workers, thus eliminating the need for a non-magical human to manage that tedious part of an app.
Pause again. What’s a worker? Basically, it’s a (union-friendly) term for a something that automates a repetitive task. In technology, functionality breaks. Dependences change. All kinds of surprises arise. Something that can swoop in and not only tell you what’s broken but also fix it is your best friend. Unicorn is your best friend.
Sometimes the unicorns are slow, though. They require a lot of memory. Fortunately, you can kill the unicorns, which is a really awful way of saying: Fortunately, you can restart the unicorns. With a simple install of the ‘unicorn-worker-killer’ gem, you’re all set to go. The gem automatically restarts the unicorns based on the maximum number of requests and the maximum memory allocated.
That’s all I’ve got for now. I’m still a little unclear about those Software for Good zombie unicorns and unsurprisingly, Google’s not helpful. Hopefully I’ll figure it out soon enough, then I’ll swing back around for a Halloween-themed guest post next October.
—
Check out Sara’s fantastic Course Report interview about her experience at Turing School.