Well hello, hello! It is the YEAR OF OUR LORD 2017 and I’m still only two blog posts deep.

Meaning I’m hot garbage at updating. This is the last time I will explicitly mention that I’m hot garbage at updating.

About 9 months ago, I was dealing with the ill-fitting API of a certain jQuery 1.6.4, which means, in essence, I was dealing with a giant rotting corpse of code, considering anything I built at that point had to work in IE8+, it was definitely a giant unoptimized square-peg tool for a round-hole job.

That’s how I received the impetus to see how far I could take a hand-coded replacement. I wanted this library to be functional and stateless and stress function composition, meaning I could reuse a lot of my methods elsewhere in the code and ultimately shrink the footprint of the result.

This is about to be a very scatterbrained writeup of some of the features of fQuery, it won’t make sense because it’s a friday and I’m tired, and I probably won’t clean it up. Here’s an autogenerated documentation website if you just want to browse the API. :)

It’s been about three months since my last post, and I’m starting to feel incredibly bad about it, so here I am slapping some words onto a text file hoping that it’ll eventually make its way out to you.

I want to take a minute to talk about adapting to your work environment. I recently moved from the AmazonUI team to the Prime Now UI team at Amazon, and much like any other job switch, it came with new coworkers, a new codebase, and a new way of doing things. The benefit being that the codebase was near non-existent just months prior to my arrival, so everything being built was slowly being developed from the ground up. As I began to work on features, I noticed something pretty horrifying:

I hated the code.

I didn’t like the camel case, I was groaning at the pedantic use of ES6, the lack of consistent structure, some functions were named to be 8 words long.

I began fighting.

If you couldn’t tell, I’m a man of jokes. A lot of jokes. In fact, suffice it to say that I’d probably sacrifice a lot of time and effort to make even the smallest joke. Does this make me a loser?

Yes. Yes it does. That’s probably why I’m writing this.

Writing Javascript for jokes is probably one of the most useful things I (or you) could do with your time. You’re using your knowledge to construct something that you ostensibly could show to other people and have a laugh about while demonstrating some skills. Unless you’re constructing a project that just outputs the word “BANANA” and all of its anagrams… I don’t think there are a lot of those.

I want to take some time to actually throw down some of my ideas of Javascript libraries that would be really fun to make. Am I a visionary? Well. Let’s just call me the Kanye West of Javascript.

If you haven’t already noticed, I haven’t touched on any futuristic javascript concepts or features in the history of the blog. And if I did… well, oops. I’ve been deliberately sticking to learning and advocating for the javascript stuff that you can do in-browser without a whole lot of fuss.

The “futuristic” part of javascript I’m talking about is called ES2015, or “ECMAScript 2015” or “ES6”. ES2015 is the direction that the ECMA-262 specification is going that will enable new features, syntax, and revolutionize code possibilities. Javascript as a language has been sitting mostly still for a while after the release of ES5, and it hasn’t had any devastating shake-ups that truly make the way we program easier or different. That changes with ES2015.

Let’s have a quick chat about hoisting in javascript.

When I say hoisting, I’m talkin’ about pullin’ yourself up by your bootstraps and DOING SOMETHING WITH YOUR LIFE. Focus on your craft! JUST FOCUS ON YOUR CRAFT! And then when you’re done doing that, let’s have a quick chat about hoisting in javascript

So, this is an interesting question in that when I was interviewing last year for various web developer positions, I was asked this question a few times despite getting pretty far in my career without hearing about it.

Now, it was fortunate that by reading a few archaic books on web development in my spare time, I managed to pick up the concept of function hoisting. Let’s have a look.

Objects are a fun data structure in javascript. Well, I guess if your definition of “fun” is creating a dictionary and then accessing that dictionary every time you need to know something.

Fun, right?

You bet your ass it’s fun.

There was a time when I thought that objects were just these simple data structures that held two things: a key and a value.

var object = {
  key: 'value'
};

It was great! I knew that if I needed a hash map, a dictionary, or a structure that I’d be using to look stuff up, I’d use an object. They were so simple! So brilliant!

I could have sworn that I’ve written about prototypes before this… I’m sure I’ve included enough information in articles where the prototype WASN’T the focus of my writing to justify feeling that way. You aren’t here to tell me whether or not I’ve actually done that. You’re here to READ.

So READ.

Anyways, today we’re going to talk about prototypes and how crazy cool they are.

So it’s been a minute, I’ll give you that. You’re probably wondering where I went. You’re likely hoping it was somewhere awesome.

It wasn’t.

I’ve actually spent time really thinking about the technology debt of my blog. It’s not huge, actually. In fact, The old incarnation of my blog is pretty much self sufficient thanks to the wonders of Wordpress. I’m incredibly thankful for the ease at which I’m able to get a site up and running. I’m NOT thankful that it takes me 50 menus and an image upload to post an article.

I’ve been spending a lot of time lately working on personal projects, and I honestly feel like it’s been time well spent.

It’s like, I go to work, code for some amount of hours, and then on the bus ride home I code some more. My eyeballs strain, my hands grow weak with each passing keystroke, My retinas burn…

…with passion. A passion that will probably lead me to eyeglasses before I hit thirty. Oh the joy.

I made a grid library today.

And by today, I mean I started making a grid library a year ago, so I just lied to you. I’m sorry, I’m an adult with priorities, albeit awful ones.

All in all, the process of developing Hagrid was a nice lesson in designing layout for HTML markup.

You are not so smart. I mean that in the nicest way possible.

When I say that, I really mean that if you think you know everything in a particular field, you’re wrong. Even if you DID know everything in a particular field, you know who would lose sleep trying to prove it wrong through a minor technicality? This guy. There’s always something to learn. That something is always present in the front-end space.

So I decided to source my local library in helping me improve my skills as a developer.

“Functional javascript, That sounds cool.” I said to myself.

Little did I know what I was getting into. As it turns out, functional programming is something that’s been around for a while ever since Scheme and LISP were like “Hey. We exist.” I suppose I wasn’t entirely prepared for it, because the book itself rocked (and continues to rock) my belief in my abilities as a programmer. Not that that’s bad, but I’ve mostly known imperative styles of programming.

Markdown is a brilliant invention. It’s insane how good it is. In fact, it almost feels to me like Markdown wanted to be everything that Microsoft Word ISN’T.

I recommend Markdown to everyone. You wanna write a paper? DO IT IN MARKDOWN.

You need a shopping list? MARKDOWN THAT BAD BOY.

Gonna take out a personal ad in the paper? WE’RE NOT IN THE 90’S. Y2K DIDN’T HAPPEN. COME OUT OF THE BUNKER AND JOIN THE REST OF US.

Dependency Injection. What is it? Why does it sound so cool?

Dependency injection is, in its simplest form, giving an object its instance variables. It means that when a given piece of code runs, it already has all the stuff it needs to do its job. Libraries like AngularJS use it, you can use the require call in Node.js to supply dependencies at runtime, there are a bunch of different technologies that allow you to inject dependencies.

But why, though? What makes it so good? Well, I’m glad you asked.

I had to present about AngularJS The other day.

I was asked to present about Dependency injection, a common concept in javascript, which I thought was going to be totally simple, but as it turns out, I was recommended to present Angular’s way of doing it, or, alternatively, the C# method of dependency injection. Luckily I stuck with the javascript.

I’m always looking for the next optimization or construct I can use to improve my javascript code. Here you are thinking “Well, I mean. With all these posts about javascript, DUH.”

I GET IT, ALRIGHT. WE KNOW. WE ALL KNOW I’M ALL ABOUT THE JS.

I just learn really interesting stuff in javascript!

In my opinion, it’s hard to know for sure when you’re doing something right unless you know exactly what ‘doing it right’ looks like. In fact, I’ve been blogging on this site for about a year now, and I still have no idea if you guys are reading.

I have no idea if what I’m writing is rich in content or lessons.

I, additionally, have no idea on how to improve those contents or lessons! I don’t have the feedback!

This isn’t as crucial a problem as I’m leading you to believe. Blogging is fine. It can be inane, it can be silly, I choose to write to not only to cement my knowledge and think out loud, but also to give you a chuckle or fresh perspective along the way.

That said, the topic of this post is ‘Do Stuff’.

This is going to be a quick post. Again, about javascript/jQuery (WHO COULD HAVE GUESSED?)

However, it’s going to deal less with a certain function or facet of js and more with the separation of concerns.

Modules. That’s a cool word. Ain’t it?

If you’ve talked to me at any point about my javascript in the past few months, I get really excited when I say that my proficiency in the language has increased dramatically since I started working a full time job only six months ago.

I’m sorry you guys have to deal with me doting heavily on javascript these past few posts, but I’ve got to say that there’s a lot to learn and I’m having fun just dealing with all of the unique challenges that coding in javascript gives me.

This post is going to be relatively short! but I know that I haven’t written in a while so I thought I would talk really quick about javascript namespacing.

Text-editors. Let’s talk text-editors. A good text-editor is like the revolver a cowboy carries. It’s unique to them. They understand how their revolver feels, how fast they can draw it, they know its weight, if a cowboy and a revolver just CLICK, then all is right with the world.

We’re all cowboys, right? Keyboard cowboys, I suppose. Either way, regardless of the skill and experience of a web developer, they typically (and by typically I mean ‘always’) have strong opinions about their text editors. Now I’m not about to sit up here and bore you with what I use and why I use it, instead I’m just gonna supply you with a few options and you can scope ‘em out for yourself!

I’ve been dancing around that good ‘ol jQuery fire for a while now, and I’ve got to say that I’ve been learning a lot. The combination of books I’ve read and the application of the framework itself has taught me a lot about what I can do with jQuery. In this sense, it leads me to more effectively code up website behavior.

So I’d like to talk about click handlers!

The title of this post actually doesn’t ring too many front-end web developer bells. In fact,”DNS propagation” sounds like some web administrator buzzword. It stands to reason, however, that since I have a hand (and in most cases the only hand) in a few websites (including this website), I have some experience with websites behind the scenes.

That’s right! I can FTP, I can mess with the .htaccess file, I’m not the definitive worst person behind a bash console, but what I will tell you is that all that experience, all the knowledge and theory means nothing comforting when you decide to do something drastic. In this case, I moved a website to a different host.

I know that often I get up here on my website pedestal and I preach to you, the singleton that’s actually visiting me on a biweekly basis about things that I like about web development. Maybe it’s things I use, maybe it’s things I seem interested in. At the end of the day, I get my learnin’ in, and you and I both feel better for having been a part of my reflection on it.

Now that I’m done sounding as if I’ve just been enlightened, I’d like to talk about Stack Overflow

Polyfill. It’s a fun word to say.

Then again, almost any word that has the prefix ‘poly-‘ is pretty fun to say. Polyrhythm, polyurethane, polygraph. All fun, all the time.

As it applies to web development, a polyfill is a tool that is used to enable a legacy browser to support something a more recent browser would support as if it was native. The idea behind calling it a polyfill is obvious, it’s a tool that fills all the gaps presented by older browsers, making them behave in a more modern fashion.

If you ever find yourself in a situation where you’re in an interview and the first thing your interviewer asks you is:

what are your thoughts on progressive enhancement and graceful degradation?

Then what are you doing? Why would they jump straight to THAT question? Why couldn’t they say hello or ask you if you needed a bio break? Yeesh.

This seems like slightly trivial to write about, but this is more for my own edification than anything else. HTML5 has been around for WHATEVER years and yet I still find myself in a place where I’m learning how to be properly semantic with it.

A while ago I was asked a tricky HTML and CSS question that left me stumped even though I know I had seen the answer a thousand times on various websites.”

How do you make a chat style box using a single div?

Just this past week I actually received a chance to interview in two parts with Amazon, and while that experience in and of itself might belong in a different post, you can bet I was running all over hell and high water through the internet to find resources to help me study.

So I’ve been getting a lot more into working with a hybridized javascript and JQuery coding syntax. Which is problematic because it means that I’m not quite there in terms of being independent of JQuery entirely, but I decided to post a (hopefully growing reference) that may help both you and I in working on developing native javascript skills.

I find it interesting that the idea of developing a new feature and the actual development of that feature are often times on two totally different planes of difficulty. On the one hand, you think “Oh man. That would be so cool. Why didn’t I do that? That’s so frickin’ EASY to DO.”

And then you get to the other hand when you start developing, angry that your own idea lied to you about how easy or simple it was going to be… Why, idea? I thought we were going to be friends!?

Since I’ve been working for Pixelkin as a web developer, you can bet that I’m typically bombarded with “Can we…” and “is it possible to…” on a frequent basis. Since Pixelkin runs on a custom theme developed by ThemeNectar, it’s important that I watch where I’m stepping and try my best not to completely kill what makes the theme so magical.

A while ago I got in touch with my good friend Robby Harvey who often finds himself in the middle of cool web based projects. If anything, I feel like Robby tinkers in some of the coolest things, and when he starts playing with something, he takes it pretty far. A while ago, we tried our hand at starting an online T-shirt store called DownPixel, I took it upon myself to help beautify the way the website looked.

One night, in a sleep-deprived stupor, I felt that our product pages weren’t visually popping. This could largely be attributed to the fact that I think standard HTML select menus are pretty ugly, instead I wanted to see if I could use JQuery to make a better menu.

It’s something that almost came to me in a dream, except I was awake. a fever daydream if you will. I always saw people using nifty menus for selecting shirt sizes. Ones that involved boxes that looked like buttons, and the active size was highlighted in some way. It was an exciting design! So much better than the depressingly bland HTML select!

Now, Unfortunately, after some migrations and a switch to a Woocommerce WordPress platform, we lost the actual visual of it. However, I’ve recreated the spirit of it all in a JS fiddle! So all is not lost!

And now, if you wanted to, you could tack a display: none; onto the select so it’s not rendered to the user, and you end up having a nice little set of boxes that can pick dropdown options for you!

Thinkin’ outside the box. RIGHT THERE!

Yeah, I know I’m not doing you any favors by adding yet another top five post to the ever growing number of ‘Top X WordPress Plugins’ articles, but just as any other developer wants to share their knowledge about what’s useful to them, I feel like I could best articulate that to you in a nice section-by-section piece!

Plugins are an important part of the WordPress ecosystem, they’re more than just plug and play modules, they represent communities, a deeper understanding, and most important of all, the continued use of a blogging platform that grows in power and function by the day.

If you ever find yourself in a conversation with me about the the interview process, I can almost guarantee that I’ll be talking about how unfair and ineffective it can be. I’ve fallen victim to a bad over-the-phone screen as well as a few bad in-person interviews. The problem with the interview process, in my eyes, has always been how subjective it is based on the thoughts and opinions formed by the interviewer on the day you meet with them. It sucks! If they’re having a bad day, there’s a chance that your interview won’t go well, and that doesn’t put every candidate on a level playing field. Enter the take-home screen and my experience with it.

If you ever get inside my head, you’ll immediately discover that I’ll go on large thinking sprees about things I can make. You’ll also notice that the thinking sprees usually involve topics that are interesting in some way or topics that I enjoy. Extension Against Humanity was a running idea I had at the end of a thinking spree on a Friday night. I wanted to make a generator of Cards Against Humanity Cards and turn it into an extension.

“Wait, hasn’t someone already made a Cards Against Humanity extension?”” I’d ask myself.

The answer, fortunately enough, was a resounding “Nope.”

I’m one of those bums that really likes to do things the way that they’ve been done before. That’s not to say that I’m not open to change, but I feel like at any given point along the route of a project, I’m likely to take a path that I’ve stomped over a few times. While I was creating my portfolio website I was looking for a solution that utilized some really strong, really robust boilerplate technologies. The kind of stuff that would scale and the technology that would allow me to build a site in a smart way. I had no idea that LESS was going to be a part of that solution.