Wednesday, March 11, 2015

Coding in Anger - Adventures in Quality of Life

During a tech meeting at work, my manager started off an explanation with "It's been a while since I've coded in anger, but...". This simple sentiment really resonated with me. Often times I've made the argument for particular choices that ultimately enhanced quality of life, but I've lacked the ability to properly articulate why those choices were beneficial even if the surface value seemed to be that it would make my life easier. That simple phrase has given me a lot to think about in terms of framing the justification here.

I've heard the argument that your user doesn't care about your test suite, or how easy it was for you to write something. While I think there's merit in such an argument, the black-and-white perspective of it simply makes it untrue. There's an implication that we should consider ourselves lucky when we get to do things like test drive, pair program, use good tools, and make good architecture. It's like we as engineers are compulsively driven to want to put things in nice and neat little boxes for organization's sake. When we can't do that or something disrupts the organization, we throw a tantrum because we're simply children. While I believe there are certainly cases where this applies, it's blatantly incorrect to paint all of us under such a stroke.

The thing is we get frustrated and angry at our cools, codebase, process red tape, etc because it hinders our ability to perform. If I'm too busy jumping through the hoops of broken framework X then that means I'm not delivering awesome stuff. Instead it usually means I'm writing harder to maintain code. When something is hard, it doesn't get done. Or at least it doesn't get done as much or as well. Sure, you can build entire empires on PHP, but by that reasoning it means the next grand project akin to the Pyramids of Giza can be done without any modern trappings, right? If logs, rope, sweat, and blood were good enough for them, then it must be good enough today, right?

A software shop should fight tooth and nail to stay on top of the curb. Does that mean we have to go back and rewrite? You betcha. But if our technical debt is reduced, if the engineers are able to get closer to the features or pull out 3rd party modules to assist in development, then isn't that a big win? Avoiding rewrites is a lost cause. How many banks are glad they are still running on COBOL today? Sure it was probably great at the time, but that time has passed. Everything we use now will eventually become archaic and dated. We may as well embrace the idea that code is a living document that needs small and big adjustments both over time. Does that mean we should jump on every shiny new framework the moment it comes out without evaluation? Of course not, but this entire "suck it up and get back to typing" attitude needs to go. Your user might not care if you're using punch cards to enter your code, but they certainly are going to feel impact of such a choice.

Something to consider.

Wednesday, December 3, 2014

Javascript - Retro is in vogue

8 months experience (which you might say more, given the OT that was put in) using Angular.js apparently is enough to make you a guru in development shops that are new to it, as that is now my role at a local gig in Portland. They've decided to transition me to full time from contracting, so I must be doing something right.

Javascript hasn't changed much since I learned bits and pieces of it years ago. It started getting pretty fancy when jQuery was hot, but now that we have full MVC(ish) stacks in Javascript, I must say doing client side development is pretty awesome. Is it without problems? Of course not, but as a JS developer I get to live the dream of a thick but universal client that runs on any device that matters, but keep the server away from buffering giant HTML files and having to handle flow through a series of dynamically generated web pages. Now I get to think in terms of web applications. No more redirects here.

Javascript still has many blemishes. 'use strict' helps a lot, but there's still many gotchas. I've come to stop hating Coffeescript, even though it still feels pretentious. I recommend it now to teams, but if it doesn't stick, no skin off my back. As I learn more about Javascript and its quirks, I want to start turning more and more flags off the jshint settings.

My most recent personal project has been to take my Roid Miner game (formerly Star Skirmish) and convert it to full-on Javascript. My familiarity with Angular, Node, and friends had given me affordances I didn't have when working purely in Unity. It also made me turn up my nose to a lot of the hoops I felt I was jumping through in Unity. A recent update of Unity caused me to lose all of my data in my Scriptable Objects which I had labored intensely to make good editors for. Combine this with some prior experiences where Unity simply lost data while making changes to objects, and this distrust made me decide to abandon Unity's serialization in favor of something I could trust, and something I could easily publish in a web-friendly fashion. As a result I replaced large portions of the editor with an Angular app in a short amount of time. At the end of that road I still wasn't happy. In my prior job doing educational/impact game development, we started using Angular in an embedded browser inside of Unity to do the UI, and it was amazingly awesome. HTML, CSS, and Javascript all have their problems, but at this point everyone knows them. Making game UI using a web stack is pretty easy and flexible, it turns out - and the best part is you don't have to write some poor approximation of html/css to accomplish it.

After some consideration, I decided to abandon Unity altogether and start picking up Three.js. I'm still very far away from something useful with it, and there's a ton of stuff I'd have to write just to catch up to Unity's capabilities, but the cool part is I've already embedded Three.js in my existing Angular game editor. The game and the editor can kind of be one in the same if I choose it, and I think that's what I'll do. I loved the talk by Bret Victor and I always wanted Unity to do some cool live-updating stuff. Unity just doesn't have good hooks for that kind of thing, but with this editor I'm free to build that up as I wish. I have a lot of work to do just to get back where I was, but this is an exciting time.

Hopefully I can start making some more posts. Some technical, some not. I'd love to get back to doing a weekly post.

Saturday, December 8, 2012

Portland, Oregon

As of next week I'll be in Portland, Oregon. I've wanted to live there for some time but kept getting reeled into interesting things here in Phoenix. I also have some good friends there as well that I've done great at keeping in touch remotely. However, the main reason for moving is because the wife just can't handle the climate here, and basically stays locked indoors for 8 months out of the year.

I was willing to let go of my current and awesome job doing educational game development for ASU to make this move, but was really sad to do so. I expressed interest in working remotely and they decided to allow me a trial for two to three months. Needless to say I'm pretty stoked. This is just about all I could ask for in terms of employment and location of living. Working remotely has its benefits as well - no more commutes, I can play games at lunch if I like, etc.

I will be moving away from a lot of really good people, but fortunately most of these people I know personally I can spend time around in various ways online or even at work. I know that's not quite the same but it's certainly better than nothing.

With a job in tow the move is something I'm really looking forward to, and it's only a week away. Now if only I could get packing!

Wednesday, May 9, 2012

Star Skirmish

After some crazy work hours I'm finally able to put some time into my own game a little here and there. Destroxels is feeling really difficult due to how complicated networking can be. I'm trying to make a simpler single-player game. A single player game needs AI and dynamically built games seem like they would be easier in 2D, so I decided to make an asteroids rogue-like. Let's see if I can do anything useful with it.

You can check out the game itself at the Star Skirmish page.

Wednesday, September 21, 2011

Peaks of DOOM

Using the awesome power of Perlin noise, I bring forth the Peaks of Doom!
Watch your step!


Thursday, September 15, 2011

Destroxels Update - More artwork

Not a whole lot this update, except for unifying the theme of the game a bit. I've added better rockets, a good rocket launcher model, and some spiffy particle effects. I think the rocket launcher is done now.
Voxelized Explosions

Tuesday, July 19, 2011

Destroxels Update - Rockets

The rockets fired from the rocket launcher now has a whole new voxel model!

This is all thanks to the editor I made, with tons of help from David Koontz. The editor is a long way from being great, but it's somewhat workable at the moment at least.

Clicking in the yellow area adds cubes at that level. Scrolling changes the editable level

You can try out the new rockets in the Destroxels page.