Blog

Post

What time of the year is it? New laptop stickers!

This is one developer cliche I embrace with pride. I love getting new stickers and putting them on my laptop, sketchbooks, notepads, boxing gloves, battering rams, and whatever else. I love them for the same reasons I love buttons - simple, fun, shares ideas, and are convenient drag-and-drop personality. Part of me sees the vanity and consumerism behind them, but that doesn’t outweigh their benefits. Namely their being a testament to the dev quirks I love.

What better way to express individuality than RedBubble stickers?

I aimed for these assorted stickers to send four total messages.

1) Front-end Dev Pride

Despite my increasing focus on back-end code like Ruby and Node/Express, front-end is still what I do best. I figured stickers to convey this would be most important. People have especially enjoyed the one on how “awesome” CSS is. One would be surprised how often text or images not fitting in containers pops up in my work. Those in the field would be less surprised and more filled with frustration bordering on murderous rage.

Those are the rare times I enjoy helping others overcome their murderous rage.

2) The JS Back-end

In my personal projects and research, the closest I’ve gotten to back-end is Node and Express. Mostly since it’s all in JavaScript, so it’s easier to wrap my head around the architecture, syntax, and other areas. I’ve dabbled around with Express apps and am excited to try more later.

Many programmers I know can’t stand this. Most hate JavaScript enough on the client-side, and the thought of it on the server-side is sickening. One literally tried to strangle me over this (not a joke).

I considered their arguments. Then I considered that I’m not using it for my actual job, and I already knew the language and could make programs with a back-end faster and more efficiently this way. Those considerations stuck with me more.

3) Ace Attorney Awesomeness

As my “About Me” page states, I’m a clear Ace Attorney fanboy. As such, whenever I see a search form on a site, I search that before anything else. It’s lead to some amusing search results, but on RedBubble I found many good stickers I couldn’t refuse.

I ordered at least three, but only one got some coveted laptop real estate. The others, which are just different stickers of Athena Cykes, are to be saved and/or admired until my world needs them most.

4) Favorite quote

Simply put, I saw one of my favorite quotes and had to include it. Not much more to say. Not much I’m allowed to say either, less I risk the wrath of a certain pair of demon overlords living under my bed.

Post

Many things can be reliably said about almost all web developers:

  • They’re willing to fight it out over what tools, conventions, and frameworks are best.
  • They’re never 100% satisfied with what they name something.
  • They have stickers on their laptops.
  • They drink lots of coffee (I’m an exception to this one).

But of all the blanket statements/annoying stereotypes, the worst will always be:

  • They’ve dealt with Impostor Syndrome.

Impostor Syndrome is Prevalent in Web Development

Impostor Syndrome (IS) is a feeling of not being able to accept or internalize one’s successes. Basically, one isn’t confident in themselves, feels like a fraud, and is afraid of being exposed. It’s not exclusive to web development, but it’s extremely common in it. Go ahead and search “impostor syndrome web dev” online and just see how many results pop up. Popular and respected devs deal with it. Virtually everyone in my front-end Slack channel has talked about struggling with it. Now as the only junior dev in a company full of much more experienced ones, it’s certainly hit me hard these last few months. Left unchecked it can make one’s life extremely stressful, which hurts their health and their career in the long run.

Image Credit to <a href='https://www.flickr.com/photos/cogdog/7995080450/in/photolist-poP8XT-dbuSSE-SJDXMX-L6tYVG'>Alan Levine/Flickr</a>. Image has been cropped from original version.

It’s not surprising IS is such a problem for devs. It’s an industry built on knowledge, full of people who will always know more than another. No matter how much someone learns there’s always more, so it’s hard any progress was made.

This drag on for weeks, months, years, for one’s whole career. It will hit hard. It will sting. It’ll be hard to get back up. And once they do it’ll happen again. And again. And again.

What Defines a Developer?

Overtime I’ve found my own solution to IS. It’s rooted deeply in what devs do everyday and how we view ourselves, so I adjusted my definition of a web developer. I define my career less around how much I know in total, and more around how much I learn each day. This is something I can control over regardless of the dev landscape, or how much smarter other devs are. It makes me a better dev and helps me feel accomplished. So far it’s worked great, even as the only junior dev at my current company.

Devs should measure themselves more by how much they learn, not how much they know.

I break down this “learn fast and often” mindset into four specific habits:

1) Focus more on fundamentals than specifics

Regardless of what tool is hot or been overused by a company, 95% of the time the principles behind it will be the same as others. For example, most frameworks in many languages use the MVC model, so knowing that will cover the basics of how most work right away. Syntaxes can easily be looked up or searched. The principles and fundamentals are what smart devs remember and emphasize instead.

2) Learn at least one thing a day, even if it’s small

This is less about building a obscure knowledge toolbox and more about being able to absorb new things fast -that’s much more valuable. Even if it’s just skimming new info on something different, it should be a habit. This week my focuses are Vim and Git on the command line. Even if it’s just a few new tricks or basics, I spend an hour a day looking them over.

3) Ask questions, even if they’re silly

No question is stupid in the sincere pursuit of new knowledge. Even if it is, it’s better (and cheaper) to ask a stupid question now than to make a stupid mistake later. Lately I’ve been asking “stupid” questions, but they paved the way to do more useful work while relying less on co-workers.

4) Experiment, even in small ways

A dev doesn’t need to make a groundbreaking app with every new tool or language they learn. It’s more important to get just comfortable enough with something. That way if a serious project comes up, it’s easy to dive right in. Set up the basics, know the problem areas, and make a scalable starting point. One only needs to play with something for a short time to get that far. Save it as a skeleton and then see if there’s something else you want to try. It’ll be waiting when you need it later.

Redefining what a Dev Does

All the above has helped keep IS almost completely out of my mind for weeks. When I see devs making advanced apps, writing about topics over my head, or making great stuff with shiny new tools, I keep these four habits in mind. I remember that for me, a dev isn’t defined by the amount they learned, but instead how they learned it. That tightness in my chest and biting in my skull quiet down.

As long as I keep my learning fast and flexible, those knowledge gaps will never get to me. As far behind as I may get, I’m still in the same race. I won’t be leaving anytime soon. I’ll only get faster.

Post

My first official app idea came in a weird way. I needed placeholder text for a web project and thought, “There’s lots of weird Lorem Ipsum makers out there. Is there one for my favorite video game?” That game is the Ace Attorney franchise. And no, there wasn’t. Cue personal outrage.

Fast forward to today, and Ace Attorney Ipsum is now available for all, deployed on Heroku as a simple Node app.

It doesn’t have much complex code since, unsurprisingly, spitting out random text isn’t that tough. But I thought I’d break down the steps to making a custom Lorem Ipsum generator with JavaScript, since it was an easy yet enjoyable challenge. Hopefully someone reading this can make placeholder text from their favorite franchise available to the world too!

Make an Array of all the Text

The first step was obvious: I needed quotes. A LOT of quotes. In my case I got lucky and found the WikiQuote page for all the released Ace Attorney games at that time. The page was just what I needed - I just had to copy the HTML, remove the tags, put them in a JS array, clean up the punctuation, and it was done. My final result looked like this:

const lines = [ 
"Random sentences go here, one at a time!",
"Here's another one! Just keep adding them on.",
"Look, here's another one.",
"And yet another. Along with dozens of others."

// ...lots of other lines here
];

The more lines the better, and mine has at least 1300. Obviously this is overkill, and 100 lines should be a safe minimum. You can maybe get away with less, since people likely won’t care about some repeat lines every now and then.

Get a Random Line

I worked backwards from my final goal of creating paragraphs of Lorem Ipsum. For that I’d need to make a paragraph. For that I’d need a random bit of text.

I started with getting a single line from the array. The function is simple with ES6 and fits in one line:

const random_quote = () => lines[Math.floor(Math.random() * lines.length)]

Make a Random Paragraph

Using random_quote() now gives me a random quote! Now I needed to do this several times to make a paragraph.

The function for that was slightly less simple. The only difference is setting the number of lines. I wanted some variance for a mix of short and large paragraphs. This function gets 3-6 random quotes and puts them together like so:

const random_paragraph = () => {
let
num = Math.floor(Math.random() * (6 - 3 + 1) + 3),
lines = ''
;

for (var i = 0; i < num; i++) { lines += (random_quote() + ' '); }

return lines;
}

Make Lots of Random Text

Now random_paragraph() makes a placeholder paragraph. The last task was making lots at once.

The catch is I wanted to let users decide how many paragraphs. This function accepts a parameter to do just that. Plus this is final function the app used, so I needed to export it.

exports.ipsum = function(num) {
let ipsum = [];

while ( ipsum.length < num ) { ipsum.push(random_paragraph()); }

return ipsum;
}

Now it can make any number of Lorem Ipsum paragraphs a user asks for! Here’s how it’s used in the app itself, using Express for the routing:

let
express = require("express"),
router = express.Router(),
generator = require('./_javascript/ipsum')
;

router.get("/", function(request, response) {

response.render("index", {
title: "Ace Attorney Ipsum",
ipsum: generator.ipsum(3)
});
});

router.post("/", function(request, response) {

let paragraphs = request.body.paragraphs

response.render("feed", {
title: "Take That!",
ipsum: generator.ipsum(paragraphs)
});
});

I use this generator.ipsum function twice. The first creates three example placeholder paragraphs on the homepage. The second creates however many a user asks for from the homepage. The output is an array without <p> tags, so the template adds those when looping through the ipsum variable.

Keeping a Modular Approach

Once the functionality was done, I decided against combining these three functions into a single exportable one in the name of maintainability. Three simpler functions are always better understood than a single, large one. Plus if I want to use these pieces elsewhere, each is already separate and easy to carry over. The code’s more readable and flexible in the long-run.

I encourage keeping this modular approach if someone uses these three functions for their own Lorem Ipsum generator. Or even better, find a different approach! One of my favorite parts of coding is the same problem has near-infinite solutions. And Lorem Ipsum generators are one of those great projects that’s simple, but allows for creative solutions.

So choose your own favorite video game or television franchise, find some quotes, and give it a try! I’m sure your fellow fans will enjoy it too.

Post

I recently had the pleasure of presenting at Bethel Middle School’ yearly career day. It was the same fare as last year: explain front-end and back-end programming, describe my own job, show some examples, deal with students that were either too loud or too quiet, and make cryptic remarks how my sister was likely their English teacher.

Something I made specifically for this was a tic-tac-toe game written with JavaScript. My goal was more than the opponent randomly selecting open squares - it actively tries to block the player’s wins and take its own. We played a couple rounds, I explained some of the code, showed them said code, got uncomprehending stares, felt a bizarre satisfaction, and repeated.

In this post I thought I’d explain the general structure of the game’s code. I could explain the specifics, but that’d take away the fun of discovering it yourself, wouldn’t it? But I will write how, despite the complexity, I kept it maintainable, organized, and DRY.

Using Containerized JS

Containerized JS is a pattern a past colleague taught me to keep JS functionality from leaking out. While working on a Pattern Library, we had issues where one component’s JS was inadvertently affecting others. This happened even more with multiple component copies on that page, and click events hit each one in the DOM.

This pattern fixes that by limiting all JS to the DOM within that component, “containing” it to stop leaks. The basic structure I use is below:

function containerized_function(patternId) {
let pattern = $("#" + patternId);

// Consistent component variables
const v = {};

// Reusable functions, used frequently the component
const f = {};

// What to do when the page loads
function init() {}

// Events triggered by the user, mostly click events
function setEvents() {}

// Running the initial and event functions when page loads
function docReady() {
init();
setEvents();
}

$(document).on({ ready: docReady() });
}

$(".component").each(function() {
var id = $(this).attr("id");

if (typeof id === typeof undefined && id !== false) {
id = "IDUNIQUE_" + Math.floor(Math.random() * 999999999999 + 1);
$(this).attr("id", id);
}

containerized_function(id);
});

First is the “containerized function” - that’s where the most important stuff happens. There’s a few important parts to be aware of:

  • pattern is declared right from the start, storing the components entire DOM for easy reference. We’ll come back to common uses for it in a bit.
  • const v stores any consistent variables for the component. For example, if an array of strings must be used or mapped in several events, I’d place them here. It’s stored in the variable v so it’s easy to reference. When someone sees v.bank_limit, they’ll know it’s a consistent variable outside of that specific event.
  • const f is the same as above, but with consistent functions. Any frequently used mapping or calculation functions go here, stored in a similar variable for the same reasons.
  • init() is for any functionality triggered when the component first loads before anything else. I access the DOM through the pattern variable, such as pattern.find('.element').text('new text here'); This ensures I change the DOM of that specific component and nothing else.
  • setEvents() is where most of the important stuff goes - click events. Triggers are also set through the pattern variable. For example, pattern.on('click', '.element', function(){ ... }); sets a click event for the targeted element only in this component. This syntax works even if the initial DOM changed.

After that, that small bit of code below does the rest. It scans the page, finds every components for the function, gives them unique IDs (if they need them), and runs the function.

There you go! Each component has that functionality contained in its own DOM. Even with several on one page, the functions and variables are independent of each other.

There’s some obvious benefits to all this:

  • It’s very modular, easy to add and remove into a project without complications. In the containerized function itself, each piece - variables, functions, events - are separate and easy to organize.
  • The pattern’s scope is limited to avoid accidental triggers in anything else.
  • It can be easily used as a JS module. The code triggering the containerization can be separated like this:
exports.component_init = function(selector, component_function) {
$(selector).each(function(){

var id = $(this).attr('id');

if ( typeof id === typeof undefined && id !== false ) {

id = 'IDUNIQUE_' + Math.floor((Math.random() * 99999999999999999) + 1);;
$(this).attr('id', id);
}

component_function(id);
});
}

In the JS file with the containerized function, it can then export the function:

let f = require('./functions');

function containerized_function(patternId) {
// Function stuff goes here!
}

exports.activate = function(selector) {
f.component_init(selector, containerized_function);
}

Finally, you’d require and use it in your main file with the selector:

let component = require('./component');

component.activate('.component-class');

There it is - easy, portable, and customizable.

Containerizing the Game

The final result using this pattern worked nicely and is on CodePen. Here’s a broad overview of what’s in each part of the containerization:

  • The variables have frequently referenced game data: all the board positions, winning combinations, and near-winning combinations. I wound up writing out all 24 near-wins, along with how to win them, so it’s the largest variable by far - but also the most important for a challenging game.
  • Functions is vital since it has several key pieces: checking if the match is over, letting the player or opponent select a square, finding what spaces are open, and so on. Most are simply shortcuts for getting info, often using the variables and board DOM, and only a few change the visible game.
  • No init functions needed here.
  • As you may have guessed, there’s only one click event: when the player makes a move. It references variables and functions already made, so creating the event itself is easy.

The final game is below - scroll through the JS and play a round or two!

See the Pen Tic Tac Toe by Maxwell Antonucci (@max1128) on CodePen.

In Conclusion

This containerization pattern didn’t make the code for key game functions any easier to figure out. Having the computer play smarter than some random square selection still gave plenty of puzzles to solve and walls to bang my fist on. But it did give an easier structure for laying out all the different puzzle pieces and putting them together.

So if you’re coding in a modular environment, especially something like a pattern library, and need a reliable JS component pattern, this one’s definitely worth a try!

Post

To this day, one of my favorite online articles is The Oatmeal’s comic on being “Perfectly Unhappy.” For a while I wasn’t sure why. Could have been his usual humor and insight was better than usual. Or I read it for the first time while in a good mood.

But I’ve found the real reason: I’m not a happy person either.

This doesn’t mean I’m miserable or don’t like my life. But the parts of my life I enjoy the most don’t fit common definitions of happiness.

I remember going to a typical party event in college. There was a big crowd of students, a band playing music, alcohol passed around, and lots of visible skin. It all felt pleasant, but I didn’t feel happy. Instead I felt stale and self-indulgent. I was zoning out in my own little world. I’m not saying it was boring and others should have felt that way. That’s how I reacted to it.

The basic gist of my thoughts during it was I felt the gathering lacked meaning. Lots of people indulging in whims and pleasures was enjoyable. But it was also meaningless. People were just following their base desires. I realized I cared more about meaningful activities than happy ones.

But I had no idea what I found meaningful.

Tear Myself Apart, Put Myself Back Together

Since leaving college, I’ve been searching out activities I find meaningful. Whether they make me happy is secondary.

And I’ve found that meaningful activities are ones that make me a better person. Even if I’m not too happy doing them. Even if it’s painful.

Sometimes it’ll feel like I’m beating myself down or tearing myself apart. But I’ll put myself together and be a little better than before. In a physical, mental, or emotional way. But it makes what I did feel meaningful. Like I made good use of my time on Earth. It wasn’t wasted remaining the same while everything else around me kept on moving. I moved forward in some way. Any way.

All the things I love the most fit this in different ways:

  • Coding - Coding is puzzle-solving. There’s an endless supply of puzzles it gives that may or may not be possible. With most I likely can’t tell which it’ll be from the start. It’ll be a rough time figuring it out. So I need to prune and update my knowledge constantly. Learning nothing will make me useless in a few years. I whack my body of knowledge with a hammer to check for weak spots. I feel the stress, repair them, and do it again.
  • Reading - I enjoy reading things many people wouldn’t like. Things that make my heart squirm and my brain yell. New ideas I’d never considered that shake up my head. They make me question my core philosophical, political, and religious views. They push my mind into turmoil. I discard everything I’d accepted as normal and start building again. Only to break it all again later for something stronger.
  • Boxing - Boxing is an easy sport to push myself in. Each workout lasts eight rounds. At the end of each I’m covered in sweat, I’m sore, and sometimes fall over. My knuckles will be cut, my core aching, my legs trembling. The rest of the day, I pull my body back together. Then I do it again in a day or two.
  • Volunteering - I helped at a soup kitchen a few times in college. I’ve started doing so again after work. It’s tough to see another side of society I’m rarely exposed to, even if it is to help. To see people struggling, and be greeted with everything from thanks, indifference, or hostility. But it makes me question my own perspectives on life as a whole. What matters to me, what I should care about, and how I should (and shouldn’t) judge others. My heart gets twisted and I try to straighten it out before I return.

All these meet my definition of meaningful, so I’m drawn back to them. But they usually don’t make me happy.

They make me feel frustrated and inadequate, insecure and lost.

They make me feel astounded and intrigued, busy and complex.

They make me feel like a human going headfirst into the turmoil of existence. Seeing a spectrum of ideas and feelings that push me up, drag me down, and toss me somewhere else. To find something new. To struggle with a new obstacle. To discover a new strength.

Most of all, they make me feel I’m making the best possible use of my time alive.

So like The Oatmeal, I’m not happy by the typical definition. And that’s okay.

Post
It's easy to see why pattern libraries are useful, but tough to successfully maintain them over time.