The blog of TheConnMan2017-01-17T00:22:04+00:00http://theconnman.comTheConnManbrian@theconnman.comJukeBot2017-01-16T00:00:00+00:00http://theconnman.com/development/2017/01/16/JukeBot<p><img src="/assets/images/JukeBot.png" alt="JukeBot" /></p>
<p><a href="https://demo.jukebot.club/">Demo</a></p>
<p><a href="https://github.com/TheConnMan/jukebot">JukeBot</a> is a Slack-enabled synchronized music listening app similar to the now deprecated Google Hangout YouTube app. Originally JukeBot was intended for an office setting where lots of devs (and others) want to jam to the same music, but be able to plug in and out at will. Also, many teams have remote members where a real jukebox doesn’t work so well. Some friends and I have used it a lot outsize of work hours for gaming and virtual hangouts. It pairs particularly well with <a href="https://discordapp.com/">Discord</a> for gaming.</p>
<p>Overall we’ve tried to keep the JukeBot feature set slim. Many enhanced chat features have already been requested, but replicating Slack (as much fun as it might be to try) is extremely difficult and not a differentiating feature for JukeBot. Instead it provides some basic chat and is a chat log of video and user events such as videos being added or other users entering the room.</p>
<p>So far I and others have had a great time using JukeBot, hopefully you’ll try it out!</p>
Development Black Boxes2016-03-20T00:00:00+00:00http://theconnman.com/philosophy/2016/03/20/Development-Black-Boxes<p>I’ve recently moved from primarily developing in the realm of <a href="https://grails.org/">Grails</a> to one level deeper with just <a href="https://spring.io/">Spring</a>. Both are Java frameworks and Grails is built on Spring (Grails 3 recently being built on the popular <a href="http://projects.spring.io/spring-boot/">Spring Boot</a>). Taking a step down into Spring has started to open my eyes to some of the “black magic” that Grails takes care of for you. Even Spring Boot is a very <a href="http://stackoverflow.com/a/802064">opinionated framework</a>. These opinions (aka defaults) can be black magic if you don’t know what they are when you dive in. This has lead me to the question: How much black magic is too much and is this just the new development world we live in?</p>
<h1 id="black-boxes">Black Boxes</h1>
<p>I may be being a little too harsh when I label these defaults and frameworks as black magic. By definition anything a developer uses which they didn’t write (or wrote and have since forgotten) is a black box to a certain degree. There are lots of ways to compartmentalize services (that’s what <a href="https://en.wikipedia.org/wiki/Object-oriented_programming">Object Oriented Programming</a> is all about, right?), but these frameworks and projects take that to a whole new level. The example I like to give is the following scenario:</p>
<blockquote>
<p>Imagine you are running a Grails application locally (no need to delve into infrastructure issues…). You go to refresh a page and you are presented with a 500 error. Where’s the problem? Is it a GSP (Groovy Server Page) rendering error? What about a Grails controller issue? Illegal <a href="http://www.groovy-lang.org/">Groovy</a> syntax? Maybe a <a href="https://grails.github.io/grails-doc/latest/guide/GORM.html">GORM</a> (Grails Object Relational Mapping) issue? <a href="http://hibernate.org/">Hibernate</a>? The <a href="https://www.mysql.com/">MySQL</a> DB you’re using? How many of these technologies are really black boxes to you?</p>
</blockquote>
<p>The scenario above has happened to me so often that I consider it the norm. Thankfully, I went into developing Grails apps with a little MySQL and Java experience. But still, someone learning everything in the above scenario will have a hard time figuring out where the boundaries are between the technologies. This is exactly what I’m finding out by taking a step back into Spring. I’m now discovering how much of Grails was because of Grails and how much was from Spring. It’s giving me a better understanding of both frameworks.</p>
<p>Full stack developers are more users and integrators of frameworks than developers of a particular set of languages. Yes, there’s basic syntax to follow (or is there really with <a href="http://coffeescript.org/">CoffeeScript</a>, <a href="http://www.groovy-lang.org/">Groovy</a>, and <a href="https://babeljs.io/">Babel</a>?), but most of the rules we follow and use are conventions created by the particular framework. Even <a href="https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller">MVC</a> is a construct of these frameworks, just another way of organizing conventional code. I’m sure I’d be hard-pressed to write straight Java that really did anything of significance.</p>
<h1 id="the-third-age-of-development-languages">The Third Age of Development Languages</h1>
<p>This is, however, the natural progression of things. You don’t see anyone (ok, maybe <em>many</em> people) building their own OS’s anymore. New development languages don’t come out very often. Most of what I see on GitHub is new frameworks. Just search for “mvc framework [insert language here]” and I’m sure you’ll find many results. This isn’t even getting into the proliferation of JavaScript everything that is happening these days. We’re in what I believe to be the third generation of application development languages.</p>
<ol>
<li><strong>Bare Metal</strong> <em>[C, Assembly]</em> - These are the early development languages which interacted directly with the moving parts of a computer. If something went wrong you could probably trace the issue all the way back to the true source and have full control over everything in-between.</li>
<li><strong>Object Oriented</strong> <em>[Java, .NET, JavaScript]</em> - These are some of the largest first-level abstractions away from bare metal. The <a href="https://en.wikipedia.org/wiki/Java_virtual_machine">JVM</a> is a very interesting abstraction which allows developers to interact with it on a higher level than they would be able to interact with the host machine.</li>
<li><strong>Frameworks</strong> <em>[Grails, Node.js, ASP.NET MVC, Spring]</em> - These are the next level of abstraction away from the base languages. Frameworks are not a new concept, but they have really taken off in the last decade. Much of what end developers interact with are the conventions put in place by the framework(s) they use, not just the syntax requirements of the underlying language.</li>
</ol>
<h1 id="the-new-development-landscape">The New Development Landscape</h1>
<p>I believe that the ability to pick up new languages and frameworks is important now more than ever. Debugging simple issues has become trivial with the internet and anything basic in an application has already been done many times by someone else. We are continually building on the shoulders of giants and being able to look all the way down to the ground and debug is extremely valuable. Much of what we debug day-to-day is not actually our own code, instead debugging our own misuse of someone else’s.</p>
<p>Black magic and black boxes are definitely here to stay. I continue to strive to be as good of a generalist as I can so that I can jump in and help wherever I can. I think even the definition of a specialist is changing. I doubt anyone truly only works in one language anymore. Everyone has had to write a little Bash, tweaked some CSS, or debugged some JavaScript. All of these languages and frameworks are some intertwined that it’s hard <em>not</em> to use multiple languages. Most of us don’t even notice, it’s just part of the job. The key is to know how much you need to know about a language or framework to build on top of it: too much and you don’t have enough time to move fast, too little and you become irresponsible and create more work for yourself down the line. For each person it is a different balance.</p>
Transient - A Simple Non-Persistent Chat App2016-01-03T00:00:00+00:00http://theconnman.com/technical/2016/01/03/Transient<p>One of the items on my “To Learn” list recently was <a href="https://en.wikipedia.org/wiki/WebSocket">WebSockets</a>. WebSockets are another of the next-generation (at least five years ago when it was standardized) web technologies which make using websites even nicer for users. From Wikipedia:</p>
<blockquote>
<p>WebSocket is a protocol providing full-duplex communication channels over a single TCP connection.</p>
</blockquote>
<p>This means messages can be broadcast to connected clients near instantaneously, so no AJAX polling and no page refresh.</p>
<p>My first experience with WebSockets was when I built a small trivia game which required all connected sessions to show and hide the trivia question simultaneous. That experience was tarnished by extensive use of Internet Explorer 8 and 9 by many of the users (older versions of IE don’t support WebSockets and attempt to fall back to polling, often with poor results), so I hoped this experince would be a little better (and a little less “Enterprise”). I figured I’d try building the same thing everyone else seems to use WebSockets for: a chat app.</p>
<p><img src="/assets/images/Transient.png" alt="Transient Screenshot" /></p>
<p><strong>NOTE:</strong> The full repo of the following project can be found at <a href="https://github.com/TheConnMan/Transient">https://github.com/TheConnMan/Transient</a></p>
<h2 id="functionality">Functionality</h2>
<p>The basic functionality is simple:</p>
<ul>
<li>Set a username</li>
<li>Receive all messages to the chatroom after that point</li>
<li>That’s it</li>
</ul>
<p>Because users can’t see messages from before they join the room there doesn’t need to be any persistence of messages (aka no database).</p>
<p>I ended up adding the concept of multiple rooms meaning users can join different rooms and only see the messages sent in that room.</p>
<p>A working demo can be found at <a href="projects.theconnman.com:8080">projects.theconnman.com:8080</a>.</p>
<p>Now that we know the very basic functionality, let’s take a look at how it was built.</p>
<h2 id="toolstack">Toolstack</h2>
<p><a href="https://nodejs.org/en/">Node.js</a> has very good WebSocket integration and many of the apps I have seen using WebSockets use Node.js, so it seemed like a good choice. <a href="http://expressjs.com/">Express</a> is a very simple web server which I used to serve up the small <a href="angularjs.org">AngularJS</a> app. <a href="http://socket.io/">Socket.io</a> was used to manage the WebSocket connections. I then used <a href="semantic-ui.com">Semantic UI</a> as my CSS framework. As I mentioned in <a href="/philosophy/2015/12/20/Frontend-Development.html">Frontend Development for Full Stack Devs</a> my toolstack has recently shifted to use many of the latest-and-greatest frontend dev tools. I have to make sure I don’t jump on the bandwagon too much…</p>
<h2 id="building-transient">Building Transient</h2>
<p>The resulting code for the initial version of <strong>Transient</strong> (which can be found on <a href="https://github.com/TheConnMan/Transient">GitHub</a>) is somewhat underwhelming. The use of Socket.io and <a href="https://github.com/btford/angular-socket-io">angular-socket-io</a> made the WebSocket connections extremely easy to manage.</p>
<h3 id="express-app">Express App</h3>
<p>The Express app’s main responsibility is to receive and broadcast messages. This functionality is shown below in an excerpt from the Express app (<strong>app.js</strong>) and a helper class (<strong>rooms.js</strong>).</p>
<script src="https://gist.github.com/TheConnMan/40b9c918a91b074adf51.js?file=app.js"> </script>
<p>The code above shows just how simple the WebSocket connections are. After a connection is made five commands are registered with callback functions.</p>
<p>One benefit of WebSockets (and reason for refactoring halfway through the project’s initial build) is that socket connections can persist user data within them. This allows the Express server to store a session’s username and current room so that data doesn’t need to be sent with each message. This has serious security implications which I won’t go into here.</p>
<script src="https://gist.github.com/TheConnMan/40b9c918a91b074adf51.js?file=rooms.js"> </script>
<p>Above is the helper code used to make the Express socket callbacks a little cleaner. There isn’t much to it other than a few more socket commands. The <code class="highlighter-rouge">rooms.send</code> function takes care of all broadcasting to connected clients. All broadcast messages are small JSON payloads to be rendered by the Angular app.</p>
<h3 id="angular-app">Angular App</h3>
<p>The WebSockets parts of the Angular app are even simpler than the server. In the Gist below I ignore all the Angular routing and view updates and only show the code responsible for sending and receiving messages.</p>
<script src="https://gist.github.com/TheConnMan/40b9c918a91b074adf51.js?file=public-js-app.js"> </script>
<p>The Angular plugin lets the app make a similar <code class="highlighter-rouge">socket.on</code> call to register message callbacks and then can emit messages with <code class="highlighter-rouge">socket.emit</code> as well.</p>
<h3 id="docs-and-docker">Docs and Docker</h3>
<p>Normally after the actual app is built I would just leave it as-is. Recently I’ve been trying to make an effort to make sure all software I build, including small side projects, have all the appropriate documentation to be run by someone else. This is as much to get in a good habit as it is to help others run my open source software (if that day should ever come…).</p>
<p>Conveniently, writing install docs for Node (especially when using Docker) is extremely easy. A Dockerfile and install docs are both included in the repo.</p>
<h2 id="conclusion">Conclusion</h2>
<p>The <strong>Transient</strong> app is, as promised, very simple both in functionality and construction. It was a fun project to build (I ended up spending more time on it than anticipated) and it provided a good experience into WebSockets. Unfortunately, I found out afterwards that pretty much everyone has made a simple non-persistent chat app, so I didn’t make anything unique. Regardless, I learned some things and have yet another project to cannibalize for future projects.</p>
Frontend Development for Full Stack Devs2015-12-20T00:00:00+00:00http://theconnman.com/philosophy/2015/12/20/Frontend-Development<p>A few months back I went to the SpringOne 2GX conference to learn about the latest and greatest for Spring and Grails. The talks I focused on were mainly on server-side Grails and system architectures (like <strong>microservices</strong>, which I’ve been <a href="https://github.com/TheConnMan/microservices">playing around with</a> quite a bit lately). The last talk I attended, however, was called <a href="https://2015.event.springone2gx.com/schedule/sessions/modern_frontend_engineering.html">Modern Frontend Engineering</a> and focused on frontend development. I consider myself a full-stack dev, so frontend development is just part of the job. I went into the talk expecting to learn a few things, but instead I got a wakeup call.</p>
<p>The talk, which has slides <a href="http://www.slideshare.net/SpringCentral/modern-frontend-engineering">here</a> dove into everything from frontend dependency management (<a href="http://bower.io/">Bower</a>) and task running (<a href="http://gulpjs.com/">Gulp</a> and <a href="http://gruntjs.com/">Grunt</a>) to CSS frameworks (<a href="http://getbootstrap.com/">Bootstrap</a> and <a href="http://semantic-ui.com/">Semantic UI</a>) and MVC frameworks (<a href="https://angularjs.org/">AngularJS</a>, <a href="http://emberjs.com/">Ember</a>, and a dozen others). This doesn’t even begin to consider everyone is using <a href="https://nodejs.org/">Node</a> to run all of the above tools and to serve up their <a href="https://en.wikipedia.org/wiki/Single-page_application">single-page applications</a>. Apparently nobody writes heavy, coupled web applications anymore.</p>
<p><strong>That was news to me.</strong></p>
<p>I’ll admit I came out of that talk a bit scared. I thought that if I just found enough cool tools and put in a few hours outside of work to focus on frontend development and that “User Experience” thing I’d be OK. That talk was a wakeup call that I can’t truly compete with frontend devs as a full-stack dev. It might have been at one point, but those days are definitely over.</p>
<h2 id="reaching-acceptance">Reaching Acceptance</h2>
<p>Since the conference in September I’ve had to come to terms with a few things:</p>
<ul>
<li>The apps I build frontends for will not have the quality, flexibility, or customization of frontends built by frontend devs</li>
<li>I need to find tools and frameworks to augment my own development ability, as much as I might like to build from scratch</li>
<li>I will need to live with the “out of the box” functionality of those frameworks</li>
<li>Most of my apps will look the same</li>
<li><strong>I will never be on the cutting edge of frontend development</strong></li>
</ul>
<p>That last one can be generalized to:</p>
<blockquote>
<p>As a full-stack dev, I will never be on the cutting edge of anything</p>
</blockquote>
<p>That’s a bit grim (and a bit of an exaggeration), but I’m beginning to believe it’s more true than not. <strong>There is too much ground to cover today and being a full-stack dev means not being an expert in anything.</strong></p>
<h2 id="toolstack-overhaul">Toolstack Overhaul</h2>
<h3 id="the-old-stack">The Old Stack</h3>
<p>Over the past couple months I’ve taken a hard look at my toolstack. It generally was:</p>
<ul>
<li>Grails, jQuery, and Semantic UI for web apps</li>
<li>Python or Groovy for small utility scripts</li>
<li>Bash or Python for command line utilities</li>
<li>Crossed fingers for containerization</li>
</ul>
<p>The stack above is, besides a little old-fashioned, not scaleable. It’s great for smaller apps and scripts, but those are fewer and further between. It’s also very manual. Web app frontends become a mess very quickly when everything is wired with jQuery.</p>
<h3 id="the-new-stack">The New Stack</h3>
<p>Now compare the above with my new stack below:</p>
<ul>
<li>Grails or Express, AngularJS, and Semantic UI for web apps</li>
<li>Node.js for small utility scripts</li>
<li>Node.js for command line utilities</li>
<li>Docker and Vagrant for containerization</li>
</ul>
<p>You could say I’ve jumped on the bandwagon.</p>
<p>The move to learn AngularJS was caused by many reasons, but one big one was the announcement that <a href="http://grails.github.io/grails-doc/3.1.x/guide/introduction.html#webApiAndAngularProfiles">Grails 3.1 would have an AngularJS profile</a>. Learning AngularJS has been great so far, especially when <a href="https://docs.angularjs.org/api/ngResource/service/$resource">AngularJS Resources</a> is combined with <a href="http://grails.github.io/grails-doc/latest/guide/webServices.html">Grails REST Web Services</a>. Those alone have saved me a ton of time writing CRUD functions for REST services.</p>
<p>And if you’re going to learn anything like Bower or AngularJS you’ll have to learn Node.js. One thing lead to another and I’ve started using Node.js for just about everything.</p>
<p>Finally, Docker has been a necessity for a few projects and it works really well with the above tools (though I would have learned it just for the amount of time it’s saved me when trying to run other people’s projects).</p>
<h2 id="conclusion">Conclusion</h2>
<p>The moral of this story is that these days in web development you do have to specialize, even if that specialty is being good, but not great in everything. I’ve only got so much time, so I look for the minimum tool stack that can do the most for me so I’m not spending all my time keeping up with the updates to my stack. I’ve also come to terms with not making the most beautiful, most interactive applications by myself, there just isn’t time for it all.</p>
<p>There’s a lot of great frontend devs out there making a lot better stuff than I can. I can’t wait to start using it on my apps.</p>
Becoming a Better Developer: By Any Means Necessary2015-12-06T00:00:00+00:00http://theconnman.com/philosophy/2015/12/06/Better-Developer<p>Recently I’ve been reading a lot of articles about two topics:</p>
<ul>
<li>How to find, filter out, and retain great developers (or employees in general)</li>
<li>How to <em>become</em> and <em>be</em> a great developer</li>
</ul>
<p>Both topics are very related and reading about them has given me a better understanding of the bigger picture. This post will focus on the second point, though I imagine a future post will discuss the first.</p>
<h2 id="table-stakes">Table Stakes</h2>
<p>I want to be up front about what I’m about to discuss. This article isn’t about being just a “good” developer, it’s about being the absolute best developer you can be. There are many people out there who just do development as a way to pay the bills or just want to put in their eight hours a day. <strong>That’s fine, but this article isn’t for them.</strong> I got lucky that I get paid to do my hobby every day. I work on development outside of work because it’s what I’m passionate about.</p>
<p>The expectation of anyone who is getting paid to develop software, regardless of if they like it or not, is for them to work hard, solve problems, and keep up to date with their given technology. <strong>Those are the table stakes.</strong> If you’re not already excelling at those then stop reading this and do what needs to be done. Going above and beyond doesn’t count if you’re not meeting basic expectations, you’re just not doing your job.</p>
<h2 id="discipline">Discipline</h2>
<p>The core of becoming and staying a great developer is discipline. This comes in many forms (<a href="http://blog.codinghorror.com/discipline-makes-strong-developers/">as Coding Horror describes so well</a>) from maintaining consistent code styling to rigorous evaluation of new tools before jumping on the bandwagon. Discipline is you putting in the work before and after performing too, not just during. And I don’t mean you have to learn a bunch of things outside of work (though that usually helps), I mean taking the time to evaluate yourself.</p>
<ul>
<li>Are you using the right tools for the current problem?</li>
<li>Do you have an understanding of the big picture?</li>
<li>Are you just coding the way you are because that’s how you always have?</li>
</ul>
<p>It’s critical to stick your head up above water every once in a while to make sure that you are doing everything as well as you can, or, more likely, to identify your own process to find what you should work on. A phrase I’ve heard is <strong>those who make it look easy are the ones who put in the most work</strong>.</p>
<h2 id="self-acceptance">Self Acceptance</h2>
<p>This one was a big mental shift for me: <strong>you are not the best developer you could be</strong>. Originally I was going to put “you suck at development”, but that’s not necessarily the case. You could be a great developer, but you’re not as good as you could be. This should be your driver. Assuming you want to become the best developer you can (which if you made it past <strong>Table Stakes</strong> I’m assuming you do) you should be seeking out ways to become better. The critical word in the last sentence is <em>seeking</em>: how to become a better developer won’t find you, you have to find it. This means read articles, read other people’s code, <em>fix</em> other people’s code, write code, write a ton more code, and <strong>seek out feedback</strong>.</p>
<p>The different mindsets of someone who has accepted the above and someone who hasn’t is best shown through an example. Everyone knows that <a href="http://blog.codinghorror.com/pair-programming-vs-code-reviews/">pair programming and code reviews</a> are great, so let’s say someone just reviewed your Pull Request and gave you some feedback. You could have one of two reactions:</p>
<blockquote>
<p>How dare you suggest that I didn’t write the code in the best way? Have you been working on this module for the past three weeks? Then how do you know what’s best for it? And who cares that you can’t understand the logic? It’s definitely not because it’s unmaintainable, it’s probably because <strong>you</strong> aren’t a good developer.</p>
</blockquote>
<p>Or:</p>
<blockquote>
<p>Awesome, thanks. I didn’t realize that the code wasn’t readable, thanks for letting me know. How could it be better? What parts were tough to read? Let’s have a discussion to find out what the best solution is.</p>
</blockquote>
<p>Ok, so maybe I went a little overboard with the negative reaction, but can you think of someone (even yourself in a past life) who would react like that?</p>
<p>The first reaction has all sorts of issues with it, so I rather focus on the positive reaction. Your reaction to feedback about your code, style, process, or anything else should pretty much be <strong>Awesome, thanks for the feedback</strong>. And I don’t mean this in a “be polite and professional” sort of way. I mean this in a “thank you for giving me another perspective on how I as a developer write code and participate as a member of the team”. If someone says your code is hard to read, is it? Did they suggest a better way of writing that module? <strong>That’s friggen awesome, thanks for teaching me something.</strong> Your whole goal is to become a better developer, right? Isn’t a huge part of being a developer recognizing how you best fit within the team?</p>
<h2 id="continuous-improvement">Continuous Improvement</h2>
<p>So you got some feedback from a coworker or an article you read. This is where the “before and after” work I mentioned above comes in. Many of these action items require actual work like practicing a different coding style, reading about best practices, and refactoring your code. Sometimes the work is more reflective by asking yourself where your own weaknesses are, how you can improve them, and how you can best use your strengths to help the team. These are all supplementary, i.e. you could still probably do your job without them, but these are what actually make you a better developer.</p>
<p>An example of how this is important is in the disparity between “years of experience” and how good of a developer you actually are. One could do the exact same bad development for ten years yet be woefully unqualified for a job when someone with one year of self-aware experience and be far more qualified. I care much more about the <em>quality</em> of someone’s experience than the quantity of it. Make sure that the experience you are gaining actually improves you as a developer instead of just piles up on your resume.</p>
<h2 id="by-any-means-necessary">By Any Means Necessary</h2>
<p>So finally we get down to the phrase “by any means necessary”. This is the phrase that I think best describes how you should become a better developer. I want to become the best developer I can be <em>by any means necessary</em>. Do I need to put in work outside of work? Do I need to step out of my comfort zone and work on things I’m not an expert in? Do I need to shine the light on my own weaknesses and work on them? Do I need to accept that I know far from everything and that there are lots of people out there I can learn from? A resounding yes to all of those. I can’t get defensive about feedback. My job as a developer is to provide as much business value to the customer(s) through software as possible, so I will do whatever it takes to make sure I am the best developer I can be, <strong>by any means necessary</strong>.</p>
Game Engines Part 32014-07-06T00:00:00+00:00http://theconnman.com/technical/2014/07/06/game-engines-part-3<h1 id="recap">Recap</h1>
<p>In my <a href="/technical/2014/07/03/game-engines-part-2.html">last article</a> I discussed how we could serialize different behaviors by storing functions within data objects. This article will finish up my game engine trilogy by talking through the underwhelming amount of code needed to render these serialized functions.</p>
<h1 id="the-grand-finale">The Grand Finale</h1>
<p>The last piece of the puzzle is to create an engine to evaluate the serialized behaviors we developed in the last article. If we were smart in our conventions earlier then the heavy lifting should be over. The code below if the finalized game engine and the amount of code may be a little underwhelming (most of it is comments).</p>
<script src="https://gist.github.com/TheConnMan/66d904156ddf8a0d3ac7.js?file=Engine.js"> </script>
<p>The fact that the total amount of code used to define each circle and re-render them can be compressed to under 40 lines is a very good thing. This means that we’ve done such a good job in our definitions that we don’t need to waste code catching corner cases, enabling additional functionality, or looking for exceptions. The engine could easily be 5x as long if the code had been <em>added to</em> instead of <em>refactored</em>. I can imagine myself writing this game a year ago and seeing if statements all over the place. Let’s take a look at each component of the code.</p>
<h2 id="definitions">Definitions</h2>
<p>Below is a comparison of the new and old definitions section.</p>
<script src="https://gist.github.com/TheConnMan/66d904156ddf8a0d3ac7.js?file=CompareDefinitions.js"> </script>
<p>The general structure of both definitions doesn’t look terribly different. We still define each circle’s data inside a single object, there’s just a bit more of it. Notice that we only check to see if one element is a function: starting angle (line 37). It would have been very easy to put a lot of if statements in this section to check if elements are functions or not and deal with them accordingly. Instead, we pass them through and deal with them inside the <code class="highlighter-rouge">redraw()</code> function.</p>
<h2 id="engine">Engine</h2>
<p>Below is a comparison of the new and old re-render section.</p>
<script src="https://gist.github.com/TheConnMan/66d904156ddf8a0d3ac7.js?file=CompareEngine.js"> </script>
<p>Again, at first glance both <code class="highlighter-rouge">redraw()</code> functions look very similar and again this is good news. Some smart refactoring occurred to preserve the same structure (the nature of the game wasn’t changing) but make it more flexible. Circles still move, but <em>how</em> they move can change. Let’s take a closer look how each circle can change in a single refresh:</p>
<ul>
<li>Radius (lines 28 and 55)</li>
<li>Momentum* (line 30)</li>
<li>Position (lines 46 and 47)</li>
<li>Position when reaching a boundary (lines 36 and 42)</li>
<li>Trajectory angle when reaching a boundary (lines 37 and 43)</li>
<li>Angle during a random angle change (lines 49-52)</li>
</ul>
<p>When you list out what can change on a single redraw, it really isn’t that much. It can basically be summed up by “where it is” and “where it’s going”. The true flexibility comes from how these changes are evaluated. A recurring theme in the code above is <code class="highlighter-rouge">physics.[function](arguments)</code>. Instead of predefining behavior, the engine acts and a glorified function caller. How far does the circle move? However far <code class="highlighter-rouge">physics.xx()</code> and <code class="highlighter-rouge">physics.yy()</code> say. What is the new radius? Whatever <code class="highlighter-rouge">d.radius</code> evaluates to.</p>
<p>* I chose to change <strong>velocity</strong> to <strong>momentum</strong>. To convert momentum into velocity I divide the momentum by the current radius squared. I wanted the physics to be more realistic in that way…until I had momentum change too.</p>
<h1 id="conclusions">Conclusions</h1>
<p>It seems a little like cheating because there really isn’t any magic happening. All we’re doing is abstracting out a few standard functions and evaluating they each time the viewport is refreshed. The heavy lift was figuring out which functions we could abstract and essentially creating an internal API for ourselves. Even as I write this I’m thinking “Why can the trajectory angle only change at a boundary?” and “Why can’t the circle color change?” Theoretically <em>every</em> aspect of a circle (rectangle? polygon?) can change on <code class="highlighter-rouge">redraw()</code>, it’s just a matter of what is supported.</p>
<h2 id="my-experience">My Experience</h2>
<p>I had a great time creating Circles. It was a new type of project for me and I learned quite a bit about how to structure projects. The amount of code wasn’t overwhelming, but the complexity was a challenge to wrap my head around. As I said before, I could have written Circles a lot faster with a lot more code, but I wanted to spend the time to do it right. After many, many refactorings I got it to the stable place it is now. I haven’t worked on it much lately, but expanded on the game engine idea with <a href="/ShapeEscape">ShapeEscape</a> (especially the physics part). I hope to write a post about that expansion at some point, but these three posts have been a lot of writing this weekend.</p>
<p>Thanks for reading, I got to get back to coding.</p>
<p>TheConnMan</p>
<p><strong>NOTE:</strong> All code examples used in the posts in this series can be found in a <a href="https://gist.github.com/TheConnMan/66d904156ddf8a0d3ac7">gist</a> found on <a href="https://github.com/TheConnMan">my GitHub account</a>.</p>
Game Engines Part 22014-07-03T00:00:00+00:00http://theconnman.com/technical/2014/07/03/game-engines-part-2<h1 id="recap">Recap</h1>
<p><a href="/technical/2014/07/02/game-engines-part-1.html">Last article</a> I laid out the problem of having very restrictive code within my game <a href="/Circles">Circles</a>. This post will describe how to reshape this interior code to intelligently evaluate parameters instead of relying on those parameters to be fixed. We’ll also explore a little of the flexibility which falls out of developing this game engine.</p>
<h2 id="a-little-generalization">A Little Generalization</h2>
<p>Now that have an idea of what we should do we can make some improvements. Let’s work on serializing behaviors first. We’ll stick with the notion of embedding data within an array of objects and just tweak it a little. We’ll define a <code class="highlighter-rouge">levels</code> object which contains metadata definitions of each level. A trivial example (level 1) is shown below.</p>
<script src="https://gist.github.com/TheConnMan/66d904156ddf8a0d3ac7.js?file=LevelExample1.js"> </script>
<p>By convention the keys of <code class="highlighter-rouge">levels</code> will be the level numbers and the values will be metadata objects. Lines 2-9 are fairly straightforward and we can see how they would fit into the engine. On level initialization the data for that level will be passed into the renderer as, say, <code class="highlighter-rouge">params</code>. Instead of a fixed number of circles we’ll use <code class="highlighter-rouge">params.ballNum</code>, instead of a fixed expansion speed we’ll use <code class="highlighter-rouge">params.expandSpeed</code>, and so on. We can even give the level a custom name with <code class="highlighter-rouge">params.title</code>.</p>
<p>So now the game is a <em>little</em> more generalize, but come on, we can do better. Parameterized, yet fixed, values give us the flexibility to define different levels, but once the level has been initialized all behaviors are static. Let’s see what else we can do.</p>
<h2 id="getting-functional">Getting Functional</h2>
<h3 id="a-slight-digression">A Slight Digression</h3>
<p>Recently I read a book on functional programming in JavaScript and found it a bit abstract. I learned programming through a lot of for loops and if statements, so passing functions into other functions which return functions seemed very unnecessary. I had to check the cover a few times to make sure the author wasn’t Xzibit. (Ok, I lied, it was a Nook book, it didn’t have a cover). Little did I know that I had been using functional programming for the past year.</p>
<p>Over the past year I’ve learned a lot of Groovy (the lazy sibling who mooches off of Java) and have used a lot of closures. Closures are at their core functions passed into other functions, which is functional programming. A simple example is shown below.</p>
<script src="https://gist.github.com/TheConnMan/66d904156ddf8a0d3ac7.js?file=GroovyExample.groovy"> </script>
<p>One of the many great things about Groovy is that it is readable. That one line says:
- Take the array <code class="highlighter-rouge">[1, 2, 3, 4]</code>
- Square each element
- Sum the elements of the resulting array</p>
<p>For those of you interested in the JavaScript version, it’s shown below.</p>
<script src="https://gist.github.com/TheConnMan/66d904156ddf8a0d3ac7.js?file=JavaScriptExample.js"> </script>
<p>The JavaScript example is much more explicit in passing functions into other functions. It is very clear that the arguments of the <code class="highlighter-rouge">map()</code> and <code class="highlighter-rouge">reduce()</code> functions are functions. Groovy is just a bit more subtle (lazy).</p>
<p>It was this exposure to functional programming which got me thinking about functions in a very different way. What if instead of passing static values into a level we passed functions…?</p>
<h3 id="back-on-track">Back On Track</h3>
<p>Our tangent leads us into the next type of level abstraction shown below.</p>
<script src="https://gist.github.com/TheConnMan/66d904156ddf8a0d3ac7.js?file=LevelExample2.js"> </script>
<p>Here we notice a very similar setup to before, but with one striking difference: <code class="highlighter-rouge">expandSpeed</code> is now a function.</p>
<p>A very reasonable question is “What is <code class="highlighter-rouge">d</code>?” This is where a strict convention comes in. We need to decide what data will be passed into the parameters during execution so our behavior serialization and game execution line up. For simplicity and flexibility I chose to pass in the entire user circle definition object for functions referencing the expanding circle (e.g. expandSpeed). This object holds the current position, trajectory, momentum, size, etc so it seemed a reasonable parameter to pass in. One component of the circle definition is <code class="highlighter-rouge">o</code>, a random double between 0 and 1.</p>
<p>Let’s take a closer look at the function in lines 8-10. Expand speed is the speed at which the user’s circle expands, so setting it to a function means that the speed will fluctuate as it’s expanding. This particular example fluctuates between an expand speed of 0 and 2 with a period of 1 sec. Where the expand speed starts between 0 and 2 is random based on the current time (<code class="highlighter-rouge">new Date()</code>) and a random offset (<code class="highlighter-rouge">d.o</code>). This is what gives level 23 a little unexpected flavor. This might trip up a user at first, but the game dynamic is more or less the same. What if we <em>really</em> wanted to frustrate the user?</p>
<h3 id="so-close">So Close…</h3>
<p>I got a lot of complaints about level 24, so I figured I did a good job with it. It’s also a good example in feedback loops. Take a look at the code below.</p>
<script src="https://gist.github.com/TheConnMan/66d904156ddf8a0d3ac7.js?file=LevelExample3.js"> </script>
<p>As you may know, the expansion speed of level 24 goes down as the size of the circle gets bigger, leading to a log of games where you were “so close”. That behavior is reflected in the code where expandSpeed is approximately proportional to how much bigger the circle needs to be to win. My apologies to everyone who quit on this level. My apologies, of course, for not being sorry.</p>
<h2 id="gettin-physical">Gettin’ Physical</h2>
<p>The last example adds one last kind of tweak to the serialization. In the code below different physics are applied to the circles.</p>
<script src="https://gist.github.com/TheConnMan/66d904156ddf8a0d3ac7.js?file=LevelExample4.js"> </script>
<p>The physics defined in lines 2-17 are also stored within an object of functions. These functions will be executed along with the other parameters inside the game engine. The notable differences between <code class="highlighter-rouge">ghostPhysics</code> and <code class="highlighter-rouge">defaultPhysics</code> (not shown) are lines 6-13. Lines 7 and 9 make the new x and y positions the old positions plus the change mod the width or height. In non-code speak, if a circle hits a border it flips over to the other side (like a ghost). Because there is no need to reflect the circle’s trajectory lines 11 and 13 return the original angle.</p>
<h2 id="next">Next</h2>
<p>It’s amazing how much flexibility can come from just a few abstractions. Pulling out level definitions into a single <code class="highlighter-rouge">level</code> object helped us define distinct levels, but it was really the leap to setting those metadata definitions to <em>functions</em> that brought the flexibility. Once that was in place we could define all sorts of dynamic behaviors. This is only half the battle, though, because now we need to refactor the hard coded <code class="highlighter-rouge">redraw()</code> function to something that can render these behaviors. Check out the next post to see how we can transform it into a game engine.</p>
<p><strong>NOTE:</strong> All code examples used in the posts in this series can be found in a <a href="https://gist.github.com/TheConnMan/66d904156ddf8a0d3ac7">gist</a> found on <a href="https://github.com/TheConnMan">my GitHub account</a>.</p>
Game Engines Part 12014-07-02T00:00:00+00:00http://theconnman.com/technical/2014/07/02/game-engines-part-1<p>I have a tendency to generalize code and often get carried away. On occasion I get right and come up with a nifty set of clean, extensible, generalized code. This is one of those occasions.</p>
<h2 id="background">Background</h2>
<p>After creating <a href="/ShapeEscape">ShapeEscape</a> I realized I needed to take a very different direction in game design. ShapeEscape had some unique game play, but overall it wasn’t intuitive and didn’t have much of a learning curve. Small games should be simple, addictive, and easy to jump into. My goal for my next game was to get all three of these.</p>
<p>Out of the smoldering ruins of ShapeEscape came <a href="/Circles">Circles</a>. The goal of the game is much simpler (click and don’t get hit) and there is more variety throughout the levels. It was this variety that I generalized into the game engine.</p>
<h2 id="problem">Problem</h2>
<p>Initially Circles had fairly hard coded levels. There was flexibility on the number of circles and their speed, but that was about it. Let’s take a look at some of the code. The Gist below is take almost verbatim from <a href="https://github.com/TheConnMan/Circles/blob/b2266f5e55616811114e5ea2f55b9443848acb27/js/circles.js">this commit</a>.</p>
<script src="https://gist.github.com/TheConnMan/66d904156ddf8a0d3ac7.js?file=HardCoded.js"> </script>
<p>Not the greatest, right? When you put these two chunks of code next to each other it’s fairly easy to see where some generalization could take place. A lot of rendering using D3 goes on around this code, but these are the guts of the <code class="highlighter-rouge">redraw()</code> method. Essentially <code class="highlighter-rouge">redraw()</code> says take the old position (stored in the <code class="highlighter-rouge">d</code> variable), check if the circle is bouncing off the edge (lines 16-24), and update the position accordingly (lines 26-27). Not terribly exciting.</p>
<h4 id="so-what-do-we-do">So what do we do?</h4>
<p>The improvements we need are twofold. First, we need to generalize the behavior serialization of lines 4-8. Right now the size, speed, radius, etc are a <em>little</em> random, but we can do a lot better. What about a changing radius size? Variable speed? Starting angle? Even different physics?</p>
<p>Once we are able to serialize behaviors we need a way to execute them. This will come from generalizing the <code class="highlighter-rouge">redraw()</code> function. Essentially we’ll have to check to see if a variable is a function (i.e. a variable speed) and execute it if it is. This generalized renderer paired with standardized serializations of behaviors is what will become our game engine. Check the next post to see how these generalizations were implemented.</p>
<p><strong>NOTE:</strong> All code examples used in the posts in this series can be found in a <a href="https://gist.github.com/TheConnMan/66d904156ddf8a0d3ac7">gist</a> found on <a href="https://github.com/TheConnMan">my GitHub account</a>.</p>
Hello World2014-07-01T00:00:00+00:00http://theconnman.com/general/2014/07/01/Hello-World<h1 id="hello-world">Hello World</h1>
<p>About three years ago my coding career started by accident. I worked at the U of M physics lab writing a physics simulation of the Milky Way in C. I learned a few things from it:</p>
<ul>
<li>Coding is pretty cool</li>
<li>Never try to learn C as a first programming language and Linux at the same time from a book</li>
</ul>
<p>It was a pair of lessons I will never forget and to this day I have not tried to write C again.</p>
<h2 id="fast-forward">Fast Forward</h2>
<p>Fast forward a few years and I now get paid to program. It is an odd turn of events I never expected, but I can’t complain about the results. On a day to day basis I normally work with:</p>
<ul>
<li>HTML</li>
<li>JavaScript</li>
<li>Groovy</li>
<li>Grails</li>
<li>CSS</li>
</ul>
<p>These days my work is a lot of web development and my outside-of-work work tends to follow that vein also. My side projects have tended to be mainly front end (a couple <a href="/#plugins">jQuery plugins</a>, a <a href="/#games">few games</a>, and an <a href="/#itunesAnalyzer">analyzer</a>), but I work server side a little too.</p>
<h2 id="projects">Projects</h2>
<p>My <a href="/">homepage</a> describes most of my projects, so I won’t go into any detail on them. Instead, I wanted to talk about what <em>types</em> of projects I’ve been working on.</p>
<h3 id="games">Games</h3>
<p><a href="/Briangles">Briangles</a>, <a href="/Circles">Circles</a>, and <a href="/ShapeEscape">ShapeEscape</a> are the three games I’ve made so far both as experiments in game development and as a way to better learn D3. Briangles wasn’t terribly popular and taught me that games need to simple and addictive. Next in line was Circles which was significantly more popular (relatively of course) and is where I developed my first game engine. ShapeEscape was bootstrapped off of the Circles game engine and hasn’t been released yet (aka posted anywhere). My next post will be about the game engines I developed.</p>
<h3 id="plugins">Plugins</h3>
<p>My two jQuery plugins were my first open source contributions. At least now I don’t feel quite as bad when I use other people’s code.</p>
<h3 id="analysis">Analysis</h3>
<p>One of my most recent projects was the <a href="/iTunesAnalysis">iTunes Analyzer</a>. It was born from my interest in analytics and near obsession with listening to music. I’ve always looked for good iTunes analyzers, but haven’t found any over the years so I made my own. I made sure to allow other users to upload their own iTunes data so they can share in the analytics.</p>
<h2 id="conclusion">Conclusion</h2>
<p>I hope others can learn from the problems I’ve encountered and code I’ve created, but even if no one reads this I aim to get something out of writing posts like learning to write better and gather my thoughts about lessons learned after (or during a project). If you are one of those elusive readers, happy coding!</p>