One of the things we’ve always tried to push here at Armor is that when you work with us, you’re not just working with some outsourced stranger from another country, but you’re working with a passionate individual with a depth of knowledge in their field. Well, my name is Stephen Kennedy, I am Armor’s Lead web developer, and let me tell you a little about how I got into this, and why I love it so much.

I’ve always had a passion for computers, and I’ve talked about it in some of my previous blog posts, but let’s go a little more in-depth into that statement. One of my earliest memories is using my Dad’s old DOS computer right after we’d just moved into a new apartment. He hadn’t had time to set up his office yet, so all of the software was just in boxes around the computer, most of it in 5 1/4″ floppies. I remember him showing me the level editor in Jetpack and it being one of my favorite things. He had a number of other games, a Racing game I don’t remember, a few episodes of Commander Keen, but none of them latched onto my little brain the way that level editor did.

For those of you not in the know, 5 1/4″ disks came between the 8″ behemoths and the 3 1/2″ ones you might see in the back of a closet these days.

I spent a lot of time when I was younger either playing games with my Dad or watching him play games. I watched him play Wolfenstein 3D (and was probably way too young to do so), I remember distinctly when DOOM came to our house. I grew up around 3D games maturing and becoming common. I watched from the sidelines as Epic Games and ID software each tried to push past the other with each new engine release, and I loved it. I loved the technology behind it, and I loved the way all the complicated things going on could be broken down into little pieces, simple to understand chunks of a problem that were recycled and reused over and over, like clockwork.

I made my first Mod for a video game (Unreal Tournament) in my early teen years. It wasn’t anything complicated. I opened up their code for the Minigun weapon, and I replaced the projectiles it spawned with rockets. I did it poorly too, because when I tried to share the code with another computer on a network, so I could show my cousin my Minigun Rocket Launcher, I somehow managed to prevent the player from moving their mouse. To this day, I don’t really know if it was my fault, or if her mouse was just malfunctioning, but it was a great introduction to the problem of compatibility. She was running a different operating system (Windows ME, which had its share of problems if you don’t remember it), and it fascinated me how much a little change like that could cascade if you didn’t understand what you were changing.

Like many adolescents, I thought this, but handheld would be amazing…

Right around the same time, I got into HTML with the help of my Aunt. I made my first website, a repeating tiny image of a dragon in the background with bright red text talking about how cool I was. It was awful, but I made it. Later, I got my first introduction to C++, by reading a few of my Dad’s computer science textbooks and following their tutorials. The grand sum of this experience was a wall-paper calculator that the book described line by line for me. But it gave me my first full realization that even the operating system was, at its core, just another collection of simple pieces, and I started exploring customizing things like the boot screen of my windows, looking into applications that would help me push my operating system past what Microsoft had laid out for it.

I was still playing with HTML, learning about more fiddly features like Image Maps and learning about JavaScript, and at the same time, I got a TI-83+ calculator for my math classes. I learned that the TI-83+ had an implementation of BASIC that could be used to automate a lot of the homework I was asked to do, so you can bet I did exactly that, and with the extra time I now had in math class, I made a really simple RPG. You could fight a monster, and if you won, you could level up. There was no way to save, so it was very limited, but it was a fun project to work on in 5 minutes here and 10 minutes there.

When I was in college, Minecraft was released. Minecraft, for those who don’t immediately see weird cubes and hissing noises at the very mention of the word, is a Voxel-based 3D survival/crafting/building game that was one of the first major Public Alpha success stories. Because the source was written in Java, and a Development Kit was freely available, the modding community swarmed on the game. What this meant was that one could either find a mod to make the game behave in almost any way one could imagine, or you could make your own. I fell in love with a number of mods that added a lot to the built-in “electricity” system, called “redstone” (which you may notice is now the name Microsoft is using for their core updates). One of the mods this led me to was called ComputerCraft, which implemented programmable Lua based computers and peripherals into the game. By programming the computers, you could automate all sorts of tasks for yourself, and this is where I fell deepest down the rabbit hole. I took my TI-RPG and turned it into a slightly more detailed game that I could play on the in-game computers while I waited for various timers to tick down.

My average Modded Minecraft session looked a lot like this.

Then I rebuilt the whole thing in JavaScript to teach myself the language, and I kept on developing it for years, adding all sorts of new systems. Magic systems that could set the environment on fire if you were in an area with wood. The ability to carry multiple weapons. A basic weapon crafting system. Just systems upon systems, not to make the game better, but to see if I could come up with solutions to the problems I saw other games tackling. Like, how do you implement inter-system interactions? How do you organize your code to allow features to be continually added to it? How do you take all this data and save it in such a way that no data is lost, but its “static” state is compressed and far less resource consuming than the “active” state? How do you make an application Mobile Responsive so that it can be enjoyed on multiple different devices? How do you randomly generate 120 years of history for a creature that takes into account the other creatures and people the player may have encountered to sell the illusion of a world that moves without them? How do you deal with language limitations, and how do you avoid running into them in the first place? How do you optimize a function that is taking too long to complete? It was a beautiful, ridiculous, poorly thought out mess of code, but it taught me first-hand how to solve problems that can be introduced as a project grows over time, and it taught me that I love solving the problems that spring up.

Then I started writing standalone JavaScript libraries. The first were of questionable usefulness, but they continued to teach me new things, like the importance of variable scope and how to encapsulate your project to prevent collisions with other code.

I was hired as a freelancer to help create an Inventory/POS system for a local business, and looking into the needs of the project, I tackled teaching myself PHP and MySQL to join my HTML and JavaScript experience in order to facilitate the project from the ground up. A little after that, I was offered a job at Armor Techs, and I’ve only continued to expand my experience since then.

Along with our team, I have developed a number of core systems that now power Arrow. Throughout the process, my work has focused on solving problems that slow our clients or our developers down, ultimately costing those clients money. I saw that our deployment process was complicated and error-prone, so we wrote a script to automate most of it and take the human element out, reducing the deployment time from between 15 – 30 minutes down to roughly 5. We saw that a number of our clients were vulnerable to creative new PHP shells as their frameworks aged, so we reverse engineered a number of the shells used against those clients and started writing defenses and detection methods that were framework independent. We noticed that our clients were asking more and more for API-dependent features, so we wrote a library to help us quickly develop and prototype communications with them without having to fiddle with small details like data-type conversions or manually configuring headers.

I work hard to make this work for you.

I love this work. I love solving problems with code. I love automating and simplifying tasks with creative problem solving. Come, get in touch with Armor, let us put my passion to work on the problems your business needs to solve. Not only do we have the skills to solve your problems, but time and time again we’ve proven that we have the ability to adapt our existing skills to new environments. We’re constantly training on new technologies with an eye towards what is important now and what will become relevant in the future. If you’re interested in working with our team, contact us below: