I’m Still Here!

I don’t know where the last two weeks went… well actually, I do, it just doesn’t feel like it’s been that long. I guess when life gets really busy, it is easy to lose track of the time. I wish I could say I was busy with programming; learning it, using it, thinking about it, anything, but that’s not the case. I did run most of a marathon (I wasn’t prepared for the distance and the heat). I also moved. Oh, and I made one and a half games using Game Maker Studio.

Neither of the games are great. I’m not sure it’s even fair to call them good, but they did help me explore Game Maker. The first one I started is something like a twin stick shooter, in the style of SmashTV, except no shooting. It’s still very early and very rough, but I’d like to keep refining the concept, because I feel like I have a good idea buried in there. The other one I’m calling “Catch You Some” (read it in Scooter’s voice, from Borderlands). Blocks fall from the top of the screen and you move a basket back and forth to catch them and score points. If the blocks hit the bottom, they stop. If a block lands on a stopped block, the game is over. It has a splash screen (technically two splash screens because Game Maker loads one too), a start screen, the game and, finally, an end screen.

“Catch You Some” is almost finished, i need to work on the end screen and work out a couple of kinks, but what I like most about it is, I spent about thirty minutes creating it. There is something to be said about using tools that let you focus your productive time wisely. Once I fix the last couple of things and figure out the best way to package it, I’ll post a link to it and do some kind of post-mortem on it. Game Maker is a neat tool, and it’s free. I highly recommend it, even if all you want to use it for is fast prototyping.

I also have been really trying to start some AngularJS development. I get the ideas, conceptually, but putting them into practice is stumping me a little. It can be disheartening to spend all my time trying to think through it and getting nowhere. Then, the next time I have a chance to program, I am more likely to choose another task. It’s a stupid cycle that I need to break out of. I feel like I am close though, so maybe that breakthrough is just one or two more brainstorming sessions away. I’ll keep plugging away!

Not Programming

I am feeling pretty energized by Code Camp, and I have lots of new ideas bouncing off the inside of my skull, but for some reason, I’m having a hard time taking any action. I haven’t coded at all, but I have done a lot of staring at the splash screen for WebStorm. Also, staring at the covers of several programming books. Instead of reading any of them, I picked up Neuromancer for the nth time.

I am a pretty avid reader. I started reading at a young age and never stopped. It is very easy for me to get engrossed in the written word. Carried off to whatever land has been created. I’m not picky either. I can recognize good writing and bad writing and abysmal writing, but most of the time I don’t really care. I am quality tolerant. This holds for most things I consume: food, coffee, scotch (but not beer), music, movies and books. It’s a rare book or movie that I actually have to walk away from.

In any case, Neuromancer is good reading. Especially for being the progenitor of an entire genre of creative fiction. Gibson hit on a perfect blend of setting, plot and character development. The mood is fantastic. The pacing is just right. It feels technical without being clunky. Most importantly, it feels of its time and yet also timeless. Reading it now, it is easy to see the influence it has had. It is a lot like listening to a Beatles record and recognizing how much modern music lifts ideas almost directly from their songs.

It has made a good distraction. I at least feel like I’m doing something, and I think it is giving my brain room to stretch out and digest and hopefully retain and integrate some of the knowledge that was being liberally blasted around at Code Camp. It’s tough though, because my most productive days are Saturday through Monday and I didn’t write a single line of code in that whole period. Worse, it seems to be a developing pattern. I should probably start setting aside specific blocs of time for coding instead of just coding “when I feel like it.”

In the next few days, I want to “dust off” my Angular and really try and wrap my brain around the guts. Directives especially. By this time next week, I want to have written a healthy chunk of code that does something. I’d really like to start working with APIs. I keep putting it off, but I think it is time to dive in. So, wish me luck and keep coding (and learning and writing about all of it)!

SoCal Code Camp

This past weekend was the Orange County edition of SoCal Code Camp. This is the first Code Camp, and in fact, the first programming related function I have been to. I had no idea what to expect and came close to letting my nerves get the better of me several times. Thankfully, I mastered my anxiety and attended, because I had an amazing time. I met a lot of really awesome people and listened to a dozen or so incredible talks. The atmosphere was friendly and inviting and it was actually pretty easy to just start up conversations with fellow programmers.

Hattan Shobokshi is one of the organizers and probably the second most prolific speaker at the camp. I attended several of his talks, and every one of them gave me more pieces of knowledge to fit into my puzzle. On day 1, I listened to his JavaScript Simplified talk, where he explained closures, prototypes and promises in a very approachable manner. On day 2, he gave the talk I was most anticipating, Angular JS with ASP.NET MVC and WebAPI. My friend Chris and I are working on a project with those exact technologies, so I was excited to see how it all worked together. The session immediately following Hattan’s talk was cancelled and so we were lucky enough to convince him to stay and make it a two part session. It was very informative and helpful, and as soon as I have a chance to decompress and go over my notes, I am going to start applying the lessons I learned directly to my code.

Troy Miles was the first presenter I saw at the Code Camp and he set a high bar for everyone to follow. This guy is the real deal and his enthusiastic style drew me right into his talks, even when I was way over my head. He was also the most prolific speaker at the Camp (I think). I was at 4 of his 5 presentations ranging from intermediate JavaScript tips to Angular to testing with Jasmine and finally a long session on the Ionic framework (a mobile apps framework that sits on top of Angular & Cordova/Phone Gap). Troy was also kind enough to hang out after his sessions and answer questions and just chat about all kinds of programming topics.

The Ionic sessions were co-presented by Justin James, who made the drive from Arizona. He talked about the details of Ionic and his experience as a professional programmer. He also spoke a little bit about working on open projects (like the one Troy was presenting to show off Ionic) remotely with GitHub and the collaborative nature of modern indie programming.

Jason Weimann gave an awesome introduction to Unity. He covered both the 2D and 3D aspects of design and had a moment or two to showcase some VR. He highlighted how easy it can be to design with Unity and more importantly, how dead simple it is to package your games to different platforms. I enjoyed his easy command of the domain and friednly attitude to answering questions.

I wish I had more time to see Rob Richardson’s talks. I only managed to see his JavaScript and Node patterns and idioms talk. I’d love to hear his presentations on MVC, WebAPI, ASP.NET, web requests and, really, anything. I also only got to watch one of Daniel Lewis’s presentations, but I did get to interact with him several times outside of the talks. Like everyone else, he was genuinely friendly and willing to answer all kinds of questions.

More important than the presentations was the time I spent getting to know new people and talking about a wide range of programming topics. Josiah and I were at several sessions together and struck up a conversation about being new to the programming world. For the rest of the Camp, we would hang out between sessions and talk about the different things we were learning or what technologies we were using “at home.” Josiah has been much better about getting out into the world of programmers and already knew a lot of the people at the Camp. He has inspired me to find a way to start going to meetups and other gatherings.

I also met Jeff Neet, an indie game developer. Jeff has competed in several Ludum Dare events, and it was fun to talk about game ideas and the different tools on the market for game creation. Jeff, as soon as your domain name resolves, I’m going to check out your games!

All-in-all, it was an uplifting and encouraging event. it felt good to see so many people at so many different levels participating equally. I am almost constantly afraid that my ignorance is glaringly obvious, but, even if it was, no one seemed to care in the slightest. I had a few moments of almost zen-like peace where I would anticipate answers, even in the more advanced topics like Angular’s controllers and directives. It is empowering to see how wonderful the community is, and I look forward to being at many more of these events. I’m even toying with the idea of getting a presentation ready for the San Diego SoCal Code Camp in mid-late summer…

Thanks SoCalCodeCamp!

TDD Nitty Gritty

Last week I had a very nice exchange with two other developers (Valkyrea and Mark, thanks for the discussion!) about learning to code. We talked about the paths we’re taking and the progress we’ve made. I am fascinated by the breadth of available knowledge in this field and the multitude of ways that knowledge can be acquired. I think it’s fair to say that the three of us in that conversation are at roughly the same depth, but we have chosen to focus on different aspects. Hopefully, we continue meeting and talking about those things. It is incredibly important to share and support each other, and I think we would derive huge benefits from those kind of discussions.

One of the topics that came up was Test-Driven Development; what it is and how to get started with it. I initially sat down to start from scratch and talk about TDD as a philosophy and how to get it set up. That made me a little nervous, mostly because I am still very much a beginner, just scratching the surface of TDD. I also realized that I had covered most of what I know about TDD in my first article on the topic. Rereading the article, I could have inserted more detail, but it is still a pretty simple process. So here is some of that detail that was missing.

(I am running a Windows 7 desktop, a Windows 8.1 laptop, and using JetBrains’ WebStorm IDE, some steps and details may vary depending on how closely your environment matches mine.) First step is downloading and installing nodeJS. Pick your poison, I used the windows 64bit installer. The installer claims it will set up your PATH, and on my desktop, that seemed to work, on the laptop, it did not. So the next step was to set up PATH for npm. I did that right inside Webstorm’s terminal, although you cna use whatever CLI you feel comfortable with. The command I used was:

 set PATH=%PATH%;C:\Program Files\nodejs

Again, use whatever address you need to make it work. Once node is installed and pathed and ready to go, you can use npm to install mocha. It is also dead simple:

npm install -g mocha

That’s a global install so you can use it in any project from there on. At that point it should (might?) work. It was long enough ago that I forget if I had to do the next steps on the desktop, however, I did have one more step for WebStorm on the laptop. I opened up the settings (ctrl-alt-s), navigated down into Languages & Frameworks -> Node.js and NPM and set the path to the node interpreter:

C:\Program Files\nodejs\node.exe

and then double-clicked the mocha package and selected install. I don’t know why that was necessary, it is possible I missed a command or step that would have done that automatically. I do know that once that step was complete, I could drop into the terminal and type “mocha” and it ran.

 0 passing (4ms)


I am still running without a test runner, and in a few other … lightweight ways, for lack of a better term. This isn’t really from any desire to keep it light or an informed decision or anything, I just haven’t spent the time figuring out how to get a runner working. I would like to, and I should get on that soon. I am hoping it integrates as well in WebStorm as I saw in Visual Studio. Grain of salt time, my friend Chris is using the Ultimate Version, and so it could be that some of the features I saw are high-level. Things like live-updating test status (which sits in the gutter) as he typed and running tests on save, etc. I won’t know until I get it running, but I will certainly share my findings when that happens!

I also got to spend a little time talking to my brother, a veteran programmer and informal TDD evangelist about my test writing and process and he gave me a lot of good advice to chew on. I will be rewriting the testing in my blackjack program to be more granular and more verbose. I have been trying to keep things “readable,” but I worry sometimes that I might be tempted to go overboard. It was nice to hear him tell me to make it even more readable.

Questions, comments, criticism and requests for clarification are always welcome. If I skipped over some vital steps or you followed everything and it still isn’t working, let me know. If you want more detail about some aspect of the process or insight into how my brain works, I’d be happy to oblige.

Keep coding, keep learning and keep writing about it! Sharing your stories helps all of us grow as programmers and as people!

Learning Progress

First post in March… how is it already March!?

I noticed that I tend to drift between the aspects of my learning, devoting most of my attention to one branch at a time. Sometimes I blog a lot, sometimes I code a lot, and other times I “hit the books” a lot. Usually the increased focus on one branch leads to less time spent on the others. I am trying to find a good balance, because all three of those activities help me learn.

I enjoy talking about programming and about learning programming. The social aspects keep me motivated. Exchanging stories and ideas with others who are at various stages of learning to program helps me through the rough patches. Also, getting my ideas out, “on paper,” or in a screencast or video, helps me understand those topics better. Figuring out how to explain something forces me to look at it from another perspective, and almost always it affords me a much better grasp on the subject.

Actually sitting down and writing code seems like the best way to learn, on the surface. I can get too caught up in it though and instead of learning anything about the language or the design, I just fall back on the three or four simple concepts I know and plug away. It’s not a totally bad thing, but I need to keep pushing myself forward. I have been learning a lot of advanced techniques, I just have to force myself to start using them. Lambdas and closures and currying and all of the beautiful things about first class functions, all that stuff is rolling around in my head. The sooner I put it in my codebase, the sooner I can really understand it.

For me, “hitting the books” covers actually reading books, as well as perusing documentation and other people’s code, and especially, it means things like freeCodeCamp, Codecademy and Code School. In the last week or so, I revisited the level 1 Angular course at Code School (give it a shot, that class and several others are free) and then used the momentum to finish their just-released level 2 Angular course. I also jumped back into their JavaScript courses. I had stalled out midway through level 3. It is some pretty heady stuff, but I realized that I shouldn’t back off every time something gets tough. So, last night at about 10:30 PM, I finished the last exercise with some fun prototyping tricks.

My friend Chris Gomez pointed me at an article by Eric Elliot that shines some light on a few ways JavaScript really gets it right. It’s an interesting article that everyone learning to program, for web especially, should probably read. I realized that I own his book, “Programming JavaScript Applications,” and so, after reading the article, I cracked the book open and dove in. It is definitely not beginner level reading, but it isn’t so advanced as to be unreachable. I’ve only been doing this for a few months, and although some of the concepts are still not totally transparent, he does a great job of explaining everything. It also dispenses with the (boring) beginner stuff that you’ve probably read in the first three chapters of every other JavaScript text you’ve looked at. He is concise and knowledgeable, and his style is approachable and very readable. I have a feeling this is going to be a great reference book for me while I incorporate “real” programming methods into my repertoire.

Next up, I want to try the Best Practices course at Code School and jump back into the challenges at freeCodeCamp. I also want to continue my series on Test-Driven Development and finish up my blackjack game. I hope everyone has a productive and happy March!

More TDD: Chipping Away

Over the past few days I have been using chunks of free time to figure out which tests to write next. In the last post, I was a little frustrated with the process, but almost immediately I found a groove and a style of writing tests that has been pretty productive. One of the biggest steps forward was to stop worrying about everything so much. The important thing is that I am trying, and I am moving forward. With that mental block out of the way, I got busy.

With setting up a shoe and dealing hands out of the way, I knew I needed a way to score the hands, so I built a test for a scoreHand function. Usually each test block, wrapped in an ‘it’, will have a couple of tests. Sometimes it will have more. They don’t start this way, I try to start each one with one test case, like this:

describe('scoreHand', function(){
    it('should check the dealerHand score', function(){
        assert.equal(scoreHand([5,5]), 10);

Eventually they grow larger. I try to encompass edge cases if I can think of them and both pass and fail cases where applicable. Currently, the scoreHand test is a medium sized test (for me) and it looks like this:

describe('scoreHand', function(){
    it('should check the dealerHand score', function(){
        assert.equal(scoreHand([5,5]), 10);
        assert.equal(scoreHand([10,8]), 18);
        assert.equal(scoreHand([3,5,8,2]), 18);
        var testHand = [6,5,10];
        assert.equal(scoreHand(testHand), 21);

An example of a simpler test case is the very next test, testForBlackjack. I envision using this test just after the initial deal to determine if anyone has a blackjack. Simple function, simple test:

describe('testForBlackjack', function(){
    it('should check for 21', function(){
        assert.equal(testForBlackjack(scoreHand([10,11])), true);
        assert.equal(testForBlackjack(scoreHand([5,5])), false);

Occasionally a test gets longer, and sometimes more complicated. I am learning to take this as a warning sign. It tells me that either I am trying to do too much with one test or too much with one function (or both). It can also start to feel brittle, too reliant on some not-quite-hashed-out syntax. A great example of that is my dealCard test and function:

describe('dealCard', function(){
    it('should deal one card to the correct player', function(){
        assert.equal(playerHand.length, 3);
        assert.equal(shuffledShoe.length, 47);
        assert.equal(playerHand.length, 4);
        assert.equal(shuffledShoe.length, 46);
        assert.equal(dealerHand.length, 3);
        assert.equal(shuffledShoe.length, 45);

I do not like the parameter I am passing, and I know I will have to rewrite the test when I clean up (redesign vs. refactor) the function. In fact, looking at the function again, I hate it even more. I will have to give that part of the code some attention soon.

Along the way, I did have an “ah-ha” moment with TDD, especially about the “Driven” part, so I made a little screencast about it for my YouTube channel. The video is up here, and I will talk about that in more detail in a later post, along with a neat bit of coding I learned thanks to WebStorm. As always, I try to keep my code up to date in my GitHub repositories, so if you want to look at the guts, blackjack is right here. Comments, questions and criticism welcome!

TDD part 3: Arrrrrrrrrrrrrrrrrrrrrgh

Testing is… not going perfectly. I’m not even sure it is going well. I can make the tests work. The asserts and whatnot are real, they check the right things, and they pass. But the format of my tests is starting to suck. I am sure this is due partially to my lack of familiarity with the testing syntax and partially to my lack of basic JavaScript knowledge, but that doesn’t make it any less frustrating.

This is what I mean by sucky syntax:

it('should have removed four cards from the shuffledShoe and dealt the right cards out', function(){
    var shuffledShoe = shuffleShoe(makeShoe(1));
    var card1 = shuffledShoe[0];
    var card2 = shuffledShoe[1];
    var card3 = shuffledShoe[2];
    var card4 = shuffledShoe[3];
    assert.equal(48, initialDeal(shuffledShoe).length);
    assert.equal(card1, playerHand[0]);
    assert.equal(card2, dealerHand[0]);
    assert.equal(card3, playerHand[1]);
    assert.equal(card4, dealerHand[1]);
it('should deal two cards each to the player and the dealer', function() {
    assert.equal(2, playerHand.length);
    assert.equal(2, dealerHand.length);
     //need to figure out this set of tests

I want to do this right, I just haven’t been able to hack my way into right yet. I’ve tried assigning the variables outside the it block but in the describe block. I have tried a beforeEach block. I don’t know what to try next. I’ll keep trying though!

The other thing I struggle with is a question of granularity. Are my tests granular enough? Too granular? Should I be testing everything? I don’t know the answers to those questions either. One day I hope to be able to use this post as a kind of reminder of what it was be like to be honestly ignorant. To hopefully remember that, there really are very few stupid questions.

The nice thing is, my test results look like this:

Blackjack Game
 √ should exist 
 √ should have a length of 52 
 √ should be a function 
 √ should have a length equal to deck*numberOfDecks 
 √ should return a shuffledShoe the same length as the shoe 
 √ should have removed four cards from the shuffledShoe and dealt the right cards out 
 √ should deal two cards each to the player and the dealer
 7 passing (14ms)