Bench Mark: What I Learned

I wanted to do a quick check-in to log what I learned in my second year of full-time work as an engineer.

My first year was mostly focused around JavaScript, CSS (SASS), HTML5, and getting familiar with some of the tools that support my work (transpiling, compiling, uglifying, module building, browser dev tools, github, Sublime Text).

This year has brought major changes.  As my company moves into a microservice architecture and doubles our engineering team, I’ve needed to grow as well.  This year I became a part-time nodeJS developer, learning a bunch of the tools that come with that — docker, async unit testing (jasmine), MYSQL queries.  I also dabble in PHP when the need arises.

Instead of being a front-end person on a large team, I’m now the only front-end person on a team of 2 engineers, so if I don’t know how to do something, I have to figure it out.

The biggest change is just this feeling of confidence.  The number of unknowns has gone down so much that there is no longer a nebulous cloud of questions around every bug.  Now I can systematically check through every possibility (environment, settings, versioning, error in current application, error in outside application) to hunt down the root cause.

Interested to see where I’ll be a year from now.  I’m reading up to become much proficient with the shell and to keep growing my SQL ninja skills.  I’m creating a list for my team of some best practices we can adopt that will make our  microservices less cumbersome to test.

Other than that — we’ll see.

Angst on Toast

I just realized that this month is the 2-year anniversary of starting school at Fullstack.  I’ve been programming full-time ever since, and knock on wood, haven’t gotten sick of it yet!

The reason I haven’t posted in a while is because I have been using every spare brain-watt on new work projects.  Like most dev shops, we are crazy under-staffed.  The plus-side of this is that I’ve gotten to get my hands into so many new projects.  Earlier this spring, we decided to build nodeJS microservices for some 3rd-party integrations, and I got to build one of them!

And when our in-house d3 wrapper needed to be expanded to include a new kind of chart, as well as adapted to some new data, guess who got tapped?

Needless to say, my emotions have been all over the place.  I spent a few weeks out of my mind with the overload of learning new things that felt way over my head.  Async unit testing?  SVG re-rendering?  Some nights I went home thinking, “At what point are they going to realize that I am not capable of doing this and should just be left doing HTML forms for the rest of my days?”  And then somehow, impossibly, I would figure out the next step.

Other nights I went home and thought, “Wow.  I am really doing this.”  But usually it was just trying to figure out what to spread on my toast before numbing my mind with 30 Rock and crawling into bed.  (Literal crawling, because my room barely fits my full-size bed.)  And now, the wonderful knowledge that my microservice will be deployed to production next week.

All these back-and-forths, these crushing doubts followed by breakthroughs (most of the time) or the mundane humiliation of needing help (also pretty often) — this is all part of the package you sign on for when you get into software.  Or you are a cyborg who has no need to waste time on doubts (or blogs) as you are finishing up your cure for cancer app as we speak.

If I could go back 2 years and decide whether to take this stressful, sleep-stealing, mind-altering journey again, would I?  Hell yes!  And maybe with a little less ‘can I even do this?’ angst next time.  But you know, probably still a lot of angst.

Project #1: Honeybee Spinner

My uncle Joe is a pretty amazing person.  Although he doesn’t label himself as an environmentalist, Joe devotes his evenings and weekends to improving the local ecosystem.  He has always been a good neighbor — in fact, he met my aunt 35 years ago when they bought townhouses next to each other!  Now he concentrates on cultivating some more unusual neighbors: his community’s bees.

If you’ve watched Vanishing of the Bees, you know that without healthy bee colonies, our grocery stores would be empty.   Joe maintains bee hives locally and and educates fellow beekeepers across the US on how to breed queens and nurture healthy hives.

Joe approached me last year with a request: he was schlepping a large beekeeper’s calendar out to the hives to help him figure out the larval stage of the queens.  Would it be possible to convert his calendar into a mobile app?

I said yes immediately.  I’ve been working in my company codebase for so long that I needed a refresher on setting up my own project.  Plus, it would be a great chance to practice animation.  The calendar is round, so it needed to be able to spin.

I don’t do any animation for work, so I ended up losing some time scrolling through the wrong kinds of libraries — number spinners and loading spinners and SVG generators that draw circles based on a model.  I needed a way to spin a wheel based on user input, preferably spinning it along with the user’s drag.

Finally, I resigned myself to writing the code from scratch.  I wrote something that did almost what I wanted:

var rotation = 0;
var wheel = document.querySelector('img');
document.querySelector('.spinner-large').addEventListener('drag', function (event) {
    totalDrag = (event.clientX + event.clientY);
    rotation += totalDrag / 720;
    wheel.style.webkitTransform = 'rotate(' + rotation + 'deg)';
    event.preventDefault();
})

What I didn’t account for is that the HTML5 ‘drag’ event is intended for drag and drop, so the user’s drag is going to cause a duplicate image to actually appear and move separate from the wheel spin (demo pen).  Not going to work.

After more research, I figured out that the way to do this is not with ‘drag’, but the ‘mousedown’, ‘mousemove’, and ‘mouseup’ events.  Thus, set draggable=”false” in the HTML to prevent that second image from appearing.  Then if ‘mousedown’ is happening inside the bounds of the image, allow ‘mousemove’ to change the wheel’s CSS rotation.

My wheel was now working.  The math on the rotation wasn’t precise, but it worked for Joe’s very basic use case.

Once I figured this out, I searched again with more specific search terms and was able to find this JavaScript Rotate Dial example, which spins the wheel with better precision and browser support than my code (demo pen). Deus ex machina, anyone?

I’m glad I didn’t find this at first, though.  By drafting the animation myself, I learned a lot about about JS vs. CSS rotation (CSS rotation was WAY easier), standard HTML5 events, plus I discovered some amazing libraries that I may want to use someday (jQuery knob, I’m looking at you).