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)

Perfect!

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(){
        dealCard("player");
        assert.equal(playerHand.length, 3);
        assert.equal(shuffledShoe.length, 47);
        dealCard("player");
        assert.equal(playerHand.length, 4);
        assert.equal(shuffledShoe.length, 46);
        dealCard("dealer");
        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
 deck
 √ should exist 
 √ should have a length of 52 
 makeShoe
 √ should be a function 
 √ should have a length equal to deck*numberOfDecks 
 shuffleDeck
 √ should return a shuffledShoe the same length as the shoe 
 initialDeal
 √ 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)

Intentionally Writing The Wrong Code

I decided to document the process of TDD with a short screencast that includes the first few steps of the TDD process. In the video, I write a failing test, write code that doesn’t pass, and then write “bad” code that makes the test pass. I’m hoping to demonstrate the principle, as I understand it, of writing the simplest code that makes a test pass. The last step in the video is writing an additional test that exposes the weakness of my simple code and will put me on the path to writing functional code. It’s just a few minutes long, but I suggest you watch in in HD (at least 720) and full screen, if you want to be able to read the code.

Test-Driven Development, part 2

Let me start off by saying, I’m new, I don’t know what I’m doing, and it is always possible I am a little wrong, a lot wrong, or even all the way wrong…

My understanding of Test-Driven Development is this: Start from scratch, write a failing test, run the test, write the simplest code that will make the test pass, write another test, etc. There is some nuance there that is hard to put into words but easier to put into practice. Usually your second failing test will require rewriting your simplest code from the first failing test into actual working code. Also, you want to keep writing tests about the same general thing until you are satisfied that thing is finished (or as finished as you need it for now). There will be some examples shortly.

I decided that I needed a very concrete and simple project to help me wrap my head around TDD. I have chosen to build the game of blackjack, with one player and the dealer. A fairly simple game with simple requirements. The dealer doesn’t even need “real” A.I. because the rules dictate the actions the dealer must take. If one is to think about how to go about playing a game of blackjack, it becomes very easy to list the steps in order. My list looks like this:

  1. Produce one or more decks of cards
  2. Combine those decks into a shoe of cards
  3. Shuffle the shoe
  4. Initial deal, 2 cards, player first
  5. Check for dealer blackjack
  6. Player input, check for bust
  7. Dealer takes cards as per the rules, check for bust
  8. Determine winner

For now I am not including betting. Point 6 breaks down into another list of choices like split and doubling down. But that’s the broad outline, and the order in which I think I am going to tackle the programming. So the first step is to have a deck. At this point I have no code at all, which means it is the perfect time to write my first test!

(I’m using mocha and node.js’s assert style. To get assert in there I added this line of code

var assert = require("assert");

)

The whole thing gets wrapped in a describe block, and then each logical separation gets a nested describe block too. Inside of those are the it blocks, the tests themselves:

describe('Blackjack Game', function(){
    describe('deck', function(){
        it('should exist', function(){
            assert.equal(typeof deck, 'object');
        });
    });
});

There it is. In the command line, I type “mocha”, hit enter and I get…

Blackjack Game
deck
1) should exist

1 failing

1) Blackjack Game deck should exist:
AssertionError: ‘undefined’ == ‘object’

Just the failing test I was looking for. I haven’t created deck, or anything else yet. Let’s fix that.

var deck = [];

Re-run the test, it passes!

Blackjack Game
deck
√ should exist

1 passing

That was simple, but that deck is empty, we wouldn’t play with an empty deck, would we? We need a deck that has 52 cards, let’s test that.

it('should have a length of 52', function(){
    assert.equal(deck.length, 52);
});

And of course, that test fails. Remember, failing is a good thing! So I filled the deck array up with 52 members. On some level it is probably important to know what those members are and to test against that as well, but I took the liberty of moving on. I can always come back once that is important.

In the same way, I wrote tests for the shoe and then built the shoe to make the tests pass. This image from my last post has the whole set of tests:

mocha

I lumped a set of three “subtests” into one test that checks that the decks add up to the right number of cards. I don’t know if that is the right way to do it, but it works well enough. Below is the totality of the blackjack code I have written so far. Not very impressive, but it all does exactly what I want it to do, for now. Next up is shuffling the shoe. I have to figure out how I am going to test that and then how I am going to actually shuffle. I copied a shuffling algorithm from a stack overflow post a few days ago that I know works, but I didn’t really understand how. I need to sit down with that for a while and see if I can make sense of it. I think the test I will have to compare, somehow, the starting shoe array against the shuffled shoe array. The details elude me, but I am working on it!

testedCode

Test-Driven Development

(Fun fact, I looked up capitalization rules for hyphenated words in titles. I was going to capitalize Driven no matter what since it is the first D in TDD, but I thought it would be interesting to know the proper grammar)

I feel like testing in general and test-driven development in particular might be a very polarizing subject for some. Maybe being new to the field helps me have a much more blasé attitude toward the topic. Maybe, for once, my naivety is working in my favor. Or perhaps I am strolling blindly down the biggest primrose path in programming. Only time will tell!

Today I wrote my first ever tests. I even started with a blank slate of a program and made sure that every test fails the first time around. Some of them continue to fail after that first time. Eventually I get them to pass. I’m even up to four tests! It has been an interesting process.

Like everything else in learning to program, the first step is the most daunting. There are so many choices. And, once again, my knowledge and ability isn’t really up to evaluating the choices… at all. So, I turned to Google. Having just purchased WebStorm, I thought it would be a good idea to see what integrates well there. That lead me to some WebStorm documentation (here) that narrowed my choices down. Kind of. It now looked like I needed to pick a test runner AND a unit testing framework. Well, ok. On the list for test runners are:

When I was looking at all this, last night, all of these names were new to me. I dug further into the docs and it looked like Karma had the most extensive write-up, so I chose it. First step to installation was installing node.js, because everything else from here on out would be installed using npm, the node package manager. From there you get some choices. You cna use WebStorm’s GUI to select packages from a list or go straight for the command line. It’s the same process for the frameworks, here are the choices:

I had actually heard of (and did surface research on) both QUnit and Jasmine before, so I thought I would try those out. I spent a while typing away on the command line and getting everything setup and then the moment of truth… how in the world do I actually write my tests? It was pretty late by the time I got all of this accomplished so I decided to get a fresh start in the morning.

What really happened was, I had a long talk with my friend Chris about testing and he even showed me how he got it working in Visual Studio. We went over some tests and the ideas of writing an initially failing test and some of the philosophy behind TDD. In some ways, he is almost as new to testing as I am, so it is interesting to get a grizzled veteran’s take on the whole thing. When that was over, it was really bedtime, and my brain was fried anyway, so off to dreamland I went.

This morning I cleaned out my project and started from fresh. I looked at the WebStorm docs some more and looked at other testing docs, specifically Mocha’s. It actually looked pretty simple to set up, and it turns out I can use it without a test runner, so for the sake of actually getting something done, I gave it a shot. At first, it was pretty hairy. There are still pieces of the puzzle missing for me, so I just copied chunks of the tutorial to get things working. I got tests working to some degree, but I kept (and continue to keep) banging up against the edges of both my comfort zone and my actual knowledge base.

I’m not entirely happy with the details of how I have mocha running, but for now, I am prioritizing having it working over having it working just right. Here is the fruits of my labor:

mochaThe tests are on the top and the result on the bottom. Four passing tests! I really have no idea if my tests are too simple or too complex or if I am using the correct syntax, or a million other things that point out my already completely obvious newness to programming. I am learning to get over the nervousness about exposing my ignorance. I will sometimes post stupid example or ask stupid questions, and I have to be ok with that.

In my next post, I will dive more into the details of how I got this all working and the steps I took once I had it working to jump into the TDD way of doing things. As always, I’m always happy to answer questions or explain specific nuances of my process. Thanks for taking the time to read this and, keep coding!