Skip to main content


Showing posts from 2014

Christmas as an adult

I was a part of several different Christmas gatherings this year. After spending time with family and friends and having given away or received many gifts, I came to the realization that the gift opening was not a very fun or exciting experience. I am unlikely to remember anything about the opening of presents. Looking back to when I was a kid, I feel like I remember a lot more excitement around Christmas. I would open up gifts to real surprise and delight, but now as an adult I have the means to buy everything I need and much of what I want, which makes it very difficult for a gift to be truly surprising in the way it would have been when I was younger. I remember  having a greater sense of anticipation as a kid. I looked forward to finding out what was under the tree. As I have grown older that anticipation has disappeared. Occasionally I still get nice surprises or have found a gift for someone else that I am more excited to give than anything I would receive. It seems to me that

JSHint for Visual Studio and WebStorm

I recently had the need to setup using JSHint between both Visual Studio 2013 and WebStorm 9. Below are the steps I took to accomplish this task. Must have Web Essentials installed to use in Visual Studio. Either choose to "Create Global JSHint settings" from the Web Essentials Menu, or add the following files to the root of your project. .jscsrc should look like this: {      "excludeFiles" :   [ "**" ] } Reason for this is to prevent this Linter from running, for some reason Web Essentials will use all of the Linters it can find, not just JSHint. By excluding all files here you tell WE to not use JSCS. .jshintignore will hold definition of files that should be ignored for JSHint: Scripts/vendor/** Scripts/angularjs/** Scripts/app/common/directives/vendorDirectives/** .jshintrc contains settings for what you want JSHint to verify: // Custom Globals      "globals"         :   {   "angular" :   true ,   &qu

How to make a good Free to play game.

Free to play games have become really popular recently and one would assume that a large reason for that popularity at least for the game makers is that they are likely more profitable than other business models. They all share the same basic concept for how to make money: give away the game for free and then charge customers for access to something within the game. The idea is that if you have a game that costs money up front you have a limited number of customers that will be willing to pay that up front price. If instead your game is free initially, then you open that game up to being played by everyone. With no price barrier to get started, even someone that may not normally have been interested in your game could give it a try. Now that the game is open to the maximum number of potential customers, you hope that a number of them will buy or pay for part of the game. This is where the difference comes, in how a game gets you to pay. I have experience with many games that follow t

My idea for Hearthstone to add more deck slots

Recently someone asked the Blizzard developers for more slots for decks in the game Hearthstone. The response was that they are talking about it and looking into it, but no decision has been made yet. One of the concerns over adding deck slots is that it could complicate the UI for Hearthstone and make it more difficult for new players to understand. I have what I think would be a good solution to add more deck slots without increasing the learning curve for the game much if at all. First I would take a look at the current selection screen for starting to play a game. It defaults to showing the decks that are custom built by the player if they have any custom decks, and there is an option to page over to the basic decks. This basic deck screen is perfect for how I would change this process. Instead of having 2 pages of decks, 1 for basic and 1 for custom, you would just see the select a Hero screen. Then once you selected the Hero you wanted, you would see all of the decks that

My idea for World of Warcraft: Free to Play

I used to play World of Warcraft, but for many reasons I have not played in several years. With the recently released expansion, Warlords of Draenor, I have been hearing a lot of positive things and find myself wishing I could play some of it again. Unfortunately, I do not have enough free time to justify paying for the subscription, but I do occasionally have free time once or twice a month where I could spend a decent amount of time playing WoW. This is my idea of how Blizzard could add a free to play option to World of Warcraft that would open the game up to more customers. First note, the existing subscription model would not go away. If people are enjoying the game as it is and can spend the time and money that a subscription makes sense, then nothing should change for those players. In fact, I think that the free to play option I am going to describe should encourage some players that have never taken a look at WoW to try it out and realize that they would be better off with th

Apply TDD to everything

Red, Green, Refactor; the TDD mantra is about breaking things down into small pieces and repeating steps, building up from simple to complex, until you accomplish the larger goal. It gives you a framework for how to approach a problem and confidently and consistently solve that problem. Coding using TDD leads to better code and is less stressful. So why not try to take what works well about TDD and apply it to everyday life? First stop and think about what you are doing. What do you want to accomplish? Do you want to get a new job? Are you planning a vacation? Do you want to get in better shape? Whatever your goal is, you need to start by figuring out what you ultimately want to accomplish. Once you know what you want to do, what is the smallest step that you can complete that will set you on your way? Update your resume, book a hotel room, go for a walk. Whatever makes sense for you to begin, do it and start the ball rolling towards completing your goal. Now that you have the

Trusting the TDD System

One of the great things about TDD is that it gives you a framework for how to approach coding problems and really how to approach work. You follow a pattern that has been proven to work by countless others. You start by proving the smallest piece of the code that you can and you work your up, bit by bit, to solve the entire issue. It sets you up for success, and makes solving complex problems easier because you don't have to worry about the entire thing. You can focus on a much simpler problem and solve that. But you have to use it, ALL THE TIME! It shouldn't be something that you only use once in a while or when you feel like it. It shouldn't be something that you fake by writing a few, relatively meaningless, tests after you have completed your work. You shouldn't claim that writing out the tests first will take too long, and then follow up your work by throwing together some tests. Start with tests and build up as you go. Trust that the system will work, follow th

Fear Continued

Previously I described what fear can do to a developer and how a company can build an environment that will allow their developers to not have fear. Today I thought I would look at what a developer can do for themselves to remove fear. Fear of not being good enough It seems to me that we as developers have a tendency to look at other developers and think that we do not match up to them. We don't correctly evaluate our own value so and assume that we don't have a lot of value or that no one would want to hire us because we aren't good enough yet. This fear can lead us to not realizing that we are more valuable to our current employer and that we should be treated as such, wether that is salary or benefits or vacation time or the ability to work from home, we don't think we are good enough to ask for the things that we want and the things that would allow us to be more happy at work. It can also lead us to not look at other job opportunities that may be better for


While reading, Test Driven Development: By Example , by Kent Beck, I came across this list of reasons why fear is bad for a developer. Fear makes you tentative Fear makes you want to communicate less Fear makes you shy away from feedback Fear makes you grumpy I feel like you could add another one to the list that would sum up all of the above: Fear is the mind-killer It's funny that the items written specifically about programming can be summed up really nicely in a fictional story about the desert. Its also a completely great way to look at how fear affects a programmer, it will literally kill their mind. Developers work on computers with keyboards writing code all day, but their mind is where their value is. If their mind is not in the right place, they are not going to be nearly as  productive and effective as possible. So as a company that employs developers, your goal should be to make their lives, at least their work lives, as free of fear as you can. How wo

Gamify TDD

I like it when things that would not normally be associated with games add concepts from games as a way to incentives you to accomplish things. Why simply go for a run if you can have an app that will track you and give you a gold star if you do better than you did the last time? Why go to the coffee shop that only gives you coffee if the other one will give you points that you can redeem for free drinks eventually? I was recently introduced to C odeSchool , an online training system similar to PluralSight, it has video courses and challenges you can take to prove that you retained what the video taught. CodeSchool also adds badges and tracks to your learning, so as you complete a video and its challenges you get a badge. Complete a collection of courses within a specific discipline and you become a master of that discipline. Some of these incentives are not tangible and really don't mean much in the real world, but they tend to work for me. If I start working towards a large g

iOS Tutorial Resources and UITableViewController

I began my app with a super simple view for the user's history. I used 1 huge label and just threw text at it. It didn't look pretty, but it got the data on to the screen. As I have been working with the app on a daily basis, it has become obvious to me that this is the biggest issue that needs to get addressed for the app to look more professional. Replacing this current view with something else will allow me to learn about the UITableViewController in iOS. As with everything I have learned so far, I seem to immediately expect iOS to have a similar control and functionality to .NET. I think that has probably done me a disservice by assuming something new will be similar to something I already know. Most of what I have learned to this point share aspects of what I know, but are almost never exact matches. UITableView I expected would likely work like either a listview or a repeater, and it has some similarities, but it also has some quirks that I find odd. At least based on t

More iOS Testing

Coming back to my project with a failing test worked great. I was able to immediately run my tests, see which one was failing and then figure out where to go from there. So I figured out my date issues and now have that logic working as I want. Next up is to test out the functionality in the app. Running through the app I found some more issues here and there. Another good reminder that while Unit Tests will help prevent bugs and regressions, there is still a need for manual testing as well. If it makes sense to add more Unit Tests as you find issues from your manual tests, then add those in as well. I was able to fix up the issues I found from manual testing and moved on to getting the app on my actual phone. This ended up being pretty easy and straight forward. I needed to get a certificate from Apple to sign my app, but Xcode took care of most of that and I was able to publish the app to my phone pretty easy. I have my own little ToDo list that I have been working through and

First Tests for iOS and Objective-C

Now that I have some basic UI elements working and some Data Objects defined and those Data Objects are persisted to a Database. Its time to start working on some logic, and before we do any logic, we want to have Tests in place. Red of the Red, Green, Refactor mantra. I want to keep track of every entry made throughout a day, and then when the day changes over, consolidate all of the previous day's records into 1 history record so that the user will be able to see how they have progressed over time. Date logic is always fun, so I am really glad to be starting out with a Test rather than assuming that my date comparisons will work as I expect them. In .NET you denote a Test Method by giving it an Attribute, and then treating it like any other method. Here in Xcode, you denote a Test Method, but having the method's name start with lowercase test, and then you add the test name after it. I've grown accustomed to naming my Test Methods very verbosely and descriptively to mak

iOS Persisting Data Part 2

So I started trying to find a way to save data in my app. I have been watching this PluralSight course to help me along,  Core Data Fundamentals , by Brice Wilson. Having thoughts of EF Code first in my head I thought things were going to be fairly straight forward after setting up my Model objects and then a connection to the data store. However, after getting those pieces setup the course shows some simple object creation and data retrieval. This ended up being nothing like I expected. Every call to and from the data store used strings to find objects and set or get properties. Yikes! I envisioned defining an object and then being able to use intellisense for that object and all of its properties. There is more to the course so hopefully we will get to that point, but if that is the case, this seems like an awful way to introduce using Core Data. Continuing on with the course I find that the reason my original objects do not provide any intellisense is that they are NSManagedObject

iOS Persisting Data

After completing the first PluralSight course and a working App, the first thing I noticed is that my app does not persist data. One of the main goals of this app is to help you track, over time, how many carbs you eat. You can enter data into the app, interact with that data, but once you close the app it all goes away. Thats not terrible useful, so I needed to find a way to store the data that is entered. I know a little about iOS, and knew that CoreData was a framework that iOS has to store data within an app, so I searched on PluralSight for CoreData and found one course, Introduction to iOS for .NET Developers , by Jon Flanders. I thought, "Hey! That is me, awesome." First major difference in this course over others I have watched, he has broken it up into almost all 1 minute segments. That sort of makes sense here because he is mostly just relating .NET to iOS development, and assumes that once you know how to translate what you want to do in .NET to iOS that you can

Building my first iOS App

I have been following along with a PluralSight video by John Sonmez , to learn the basics of developing for iOS. After creating a simple "Hello World" app, he moves into creating a protein tracking app. I have recently been looking into a diet change that would see me limit the amount of carbs that I eat significantly, so I plan on taking the protein tracking idea and apply it to carb tracking. Hopefully I can create an app that will be simple to use and will help me follow my new diet. After I complete the course, and with it a starter app, I will try to add to this app and give it new features while also expanding my knowledge of iOS development. So the first steps are to put some controls on the screen. This reminds me a lot of how Visual Studio works when in Design mode. You have a "toolbox" full of controls and you can drag and drop them onto the view. You align those controls with guidelines provided by the IDE. You can anchor a control to a part of the vie

iOS First Lessons

One of the items I was most interested in finding out about iOS Development was using Unit Tests. To my great delight, the first "Hello World" app walkthrough that I watched, pointed out that Tests come in the default project when you create a new App Project. So I immediately wanted to try out the Tests and see what they are all about. As someone that has been learning about TDD practices, it came as a bit of a nice surprise that the default Tests, actually fail when I tried to run them without any code. Based on the TDD mantra of Red, Green, Refactor; you would want your Tests to fail first to ensure that your changes would then fix the broken code into a working system. Looking into the Test Class, I see some code that looks fairly familiar to what I am used to when I create Unit Tests in .NET. There are setUp and tearDown functions that would be used before and after each test. And a single Test function that appears to be throwing an exception because it has not been

Learning iOS

I am a .NET Developer by experience and knowledge, but am a huge Apple user at home. Just about every piece of technology that I own is made by Apple, and I own just about 1 of every major product Apple sells. Given my affinity towards using Apple products, I thought it would be fun to expand my development knowledge by trying out iOS development and try to create an iPhone app that I could use for myself. My goal is to share what I learn, what hurdles I overcome, and how I feel about development differences between .NET and iOS. Some of my initial thoughts and questions. How will working in Xcode differ from Visual Studio. Visual Studio stands pretty far ahead of any other IDE I have ever used in terms of both built in functionality and amount of extensibility. One of my Must-Have additions for Visual Studio is NCrunch , and tool that continuously builds the Solution and runs Automated tests against the latest code. NCrunch is fantastic in that I can code away, and build my tests wi

.NET Automated Testing with Session and Microsoft Fakes

I am working on a project that uses session and application level calls nested deep within the code. It is not practical to refactor those calls to pass in the values needed and make Unit Testing possible through dependency injection, so I needed to find a way to create automated tests that would not crash on those calls. I researched and tried out many different approaches. Ultimately what I came up with was to use Microsoft's Fakes to mimmic the Session and Application calls. I was helped greatly by this post, Testing Untestable Code Thanks to MS Fakes , and commented my code with his link in case others at my company need to view it. I created a class that my Web Tests can inherit from that will handle the setup of these Fake calls. Imports System.IO Imports System.Web Imports System.Web.Fakes Imports Microsoft.QualityTools.Testing.Fakes <TestClass()> Public Class SessionTestBase Private _fakeHttpContext As IDisposable <TestInitialize()> Public Sub BeforeEa

The importance of iteration

Red , Green , Refactor is the mantra for Test Driven Development.  When I started out with Unit Tests the idea of creating tests to make sure that a function behaved properly was easy to understand, but the rest of the cycle didn't really sink in until later. Red , making a failing test, is important to the TDD approach. When practicing TDD, if you start out by creating a test and it passes without the actual code having been written yet, then there is something wrong with your test. By making sure that your test fails first, then you can be sure that whatever changes you make to pass the test will have been valuable changes that were needed to make the function work properly. If you are writing a test against existing code and it passes immediately, then you do not need to make any changes to your code as your are already passing whatever that new test is validating for. Green , making the test pass, is the obvious part of Unit testing.  You want lots of green in your project