Guilty Pleasures of an ex-hardcore gamer

Recently I've been enjoying causal games. I play them for easily two hours or more a day now. I prefer playing them on my kindle, but there are some I have to use my iPad for. It pains me to enjoy these games because I used to consider myself a hardcore gamer. It is even possible to be a hardcore gamer of causal games?

While some of these games can entertain me for hours, others feel incomplete. The promise of gameplay is there. But it's like the developers did "just enough" to be able to call it a game and put it up. Most of these games fall in the realm of "play for about 5-10 minutes, then wait a full hour or until you can do something again". Other games are just complete rip-offs of the already successful games.

The quality for each game is vastly different too. From the occasional hiccup in a game that cause it to crash or application destroying bugs that can only be fixed by completely reinstalling the application, and thus losing your data (which is totally not cool since nearly all the games have micro transactions and you can lose any of those purchases if the transaction was of the ones where you buy in-game currency and the game isn't played or saved on a server). I've had to stop playing more than one game on account of these kinds of problems, which saddens me because at least one of the games this has happened to me with I really enjoyed.

Anyway, here is a list of casual games I currently enjoy playing:

Family Guy: The Quest For Stuff, Puzzles and Dragons, AdventureQuest: Battle Gems, The Secret Society - Hidden Mystery, Book Of Heroes (some parts of it count as a MMO, but the energy system pretty much makes this a casual game), Theme Park, Minion Rush, Spider-Man Unlimited, Jurassic Park Builder, Honorbound, and Plants vs Zombies 2.

Wow, that's quite a list. No wonder I spend so much time playing on my Kindle/iPad. That doesn't include the pinball games I play or all the tiny games I play on these devices (hidden object games, digital game books, etc.).

Perhaps I am a hardcore causal gamer.

Nothing gets coded before 2 am

I'm not sure what it is about the night vs the day that makes me feel so much more motivated to code. Maybe it is because the day is nearly over and bedtime is approaching and I have things I need to finish, which makes me sit down and actually finish the tasks I have set out for myself. The whole procrastination thing that goes on that lets people do less important things. I also tend to want to keep the things I really want to do for last. Even while playing video games, I do the more chore-like tasks before the really fun ones, like getting a certain number of kills with a pistol, just so I never have to use the pistol ever again. Unfortunate that I'm also pretty tired and reading a computer screen hurts my eyes, making it hard to code even though I have a good amount of motivation right now.

Decided to read a book on MVC

I've decided that I should read a book on .NET MVC. I'm at a crossroads for which one to get though. There is Professional ASP.Net MVC 5 from Wrox (which I commonly call the red books) and Pro ASP.Net MVC 5 (Expert's Voice in ASP.Net), which is from the publisher Apress (whose Expert's Voice series I refer to as the black books). I have Professional ASP.Net 4.0 in C# and Visual Basic from Wrox and I really thought it was good, so my initial reaction is to go with the red book. But what if the other one is better? I decided to look up the authors for each book. The red book version of MVC has four writers, Jon Galloway, Brad Wilson, K. Scott Allen, and David Matson. The black book version has only one writing credit, Adam Freeman. After a very quick search, it seems like the better choice is the red book. Adam Freeman has written a lot of books, but the other authors, at least Galloway and Matson seem more active with podcasts and blogs. I could be wrong, it was a very quick one minute goggle search on each author. I'm going to go with the red book for now, but I would be interested in getting the black book too and seeing the differences.

I'm...not going to let you do that

I was currently working on some error handling code for one of my side projects when I came across this problem. I have objects stored in a database, which of course has a field Id for its primary key. However, when the user goes to create this object, the Id field has no value until it gets saved to the database, as which point the database engine gives it an Id. The object in my code includes a member for the Id field of type int? (which is a nullable int, it can have a value of null). The function I use to get the object from the database is defined as such

     public Object GetObjectFromDatabase(int? ObjectId) { }.

Inside this method, if the value of ObjectId was null then I would return null as the object.

     if (ObjectId.HasValue)
     {
          // Get and Return the object
     }
     else
     {
          return null;
     }

Adding in my error code, I thought about that behavior and decided that if I was going to the database to get an object, I would need to know its Id, so I decided that passing in a null would be considered an error. So I changed that else statement to read

     else
     {
          throw CustomizedError;
     }

I still wanted the function to accept a nullable int to avoid checking if there was a value for Id and then convert it to a regular int for every place I call GetObjectFromDatabase. I have other functions that take in similar parameters, including updating the object, deleting the object, and other various things that can be done with the object, After some debate with myself, I changed those functions to only accept a regular int instead of a int? for three reasons.

1) Programmers can only make mistakes when the code allows them to. This is why we have private variables and enforced type checking. In languages like Javascript, bugs arise when strings get treated like numbers and vice versa. Javascript doesn't force the programmer to choose a type for thier variable and stick with it. It's just var Name; Take the following code
  
     var Two = 2;
     var Three = "3";
     alert(Two + Three);

The pop up you get will display "23". This would be a bug if the developer wanted 5. It's a simple mistake, but it happens because it was allowed to happen. If you tried that in C#, you wouldn't be able to compile. If I don't want programers to pass a null into this functions, I just need to not let them at all.

2) Bugs make it through testing all the time. I or someone else will eventually make the mistake of passing a null into that function, and, if I had testing for my project, since it would be a special case there is a good chance it would make it through testing.

3) It is always better not to have to throw errors. Even if it means more code to write. Sometimes having to write more code means you have to think through what you are doing. Also, bug-free code is sort of the goal and writing code that actually prevents bugs before it even compiles is preferable.

Book Finished: Mythical Man-Month

I just finished reading Mythical Man-Month by Frederick Brookes. It was pretty good, although a bit dry at times. It is a bit dated too although the 20th Anniversary Edition tries to updates the old material with a new chapter that includes discussions with others on the original material. Some of the points I took away from the book that I think are still applicable today for software projects are:

     - Adding people late in a project makes it late, or makes it later if it is already behind schedule. There is an initial overhead cost of training and the new worker to find their way and become familiar with the  project before they can fully contribute to the project. If you need more people, add them sooner than later to mitigate that cost.

     - The system architects and designers should stick to only architecture and designing and the coders should only stick to coding, that may you have a separation between design and implementation, otherwise implementation may influence or change the design to fit the implementation, which may cause problems with what is intended or if a decision is made to change platforms.

     - There should be as few designers and architects as possible, or at least as few people making decisions as possible, in order to preserve conceptual integrity and uniformity.

     - Communication is the hardest part about working on a team. The effort to communication and coordinate grows exponentially as the team grows in size. This means that doubling the work force will not double the productivity because the effort of communicate will more than double.

     - As much documentation as possible should be completed before any other work starts on a project. Writing documentation forces you to make decisions and ask questions you would otherwise put off or not know you had to make or ask. It is easier to implement things from the start rather than add them in later.

     - Despite the above point, the only real constant in a project is change, and so one must plan for changes to occur, not just in specifications in the project, but also for changes in the organization or the team performing the work.

     - Milestones need to have a clear and precise definition, otherwise confusion about progress may arise. If the definition is precise you cannot lie to yourself about progress and a person receiving a progress report will have close to the same understand of the progress as the person giving the progress report.

I've seen this book on a few required reading lists that some software developers have up on various blogs and website. I think it is worth a read as long as you pick up the 20th anniv. edition so you can understand what may or may not be still be applicable.

Double Post To Start Off Renewed Blogging Attempt

I'm doing two posts today in my renewed effort to blog. Don't expect this pace from me though. in fact, keep your expectations low.

Today I'm pointing out that clever code is not a good thing. You should code in a way that even non coders understand what you are trying to achieve (if you are using a high level language that is, if you are using a low lever language, then go ahead and ignore this advice, nobody will be able to understand anything you could write without a great deal of effort no matter what).  A quote by Brian Kernighan is "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

So you should write code like this:

          public string GetMonthAbbreviation(int MonthId)
         {
             switch (MonthId)
             {
                   case 1:
                              return "JAN";
                              break;
                    case 2:
                              return "FEB";
                              break;
                    case 3:
                             return "MAR";
                             break;
                    case 4:
                             return "APR":
                            break;
                     default:
                            return "N/A";
                            break;
'              }
          }

And NOT like this:

               private Dictionary<string, string> Monthlist;

               public Constructor()
               {
                     Monthlist = new Dictionary<string, string.>;
                     MonthList.Add("1", "JAN");
                     MonthList.Add("2", "FEB");
                     MonthList.Add("3", "MAR");
                     MonthList.Add("4", "APR");
                }

              public string GetMonthAbbreviation(string MonthId)
              {
                       return (MonthId != null && MonthList.ContainsKey(MonthID)) ? MonthList[MonthId] : "N/A";
               }

Which seems easier to understand?

Changing things up

I'm changing the way my blog works. Instead of posting only longer articles that are checked for spelling and grammar and then revised to sound better, I've decided to do much shorter posts. I'll still do the longer pieces, and there will be a post about them with a link as well as links to them on the site, but I want be more active with this. Attempting to write articles that equated to a school essay or paper doesn't seem to be working well for me, so I'm trying something different. Short posts for the most part, longer articles as pages on the site which will be accompanied by a blog post with a link to it, and I'm going to set up my google drive to host my custom code that people can download and use or just look at, which I will update a page with links to it and of course a short post to inform when I do updates. I most likely will not be putting up links on my Facebook and G+ accounts to new posts, but I will when I do something substantial. I'm not sure if I'll use Twitter to announce new blog posts. I've really stopped using Twitter, last time I was on it was just to tweet that I had a new post up (yeah, that long ago). Hopefully this get me writing more, unless blogging just really isn't my thing.

Hey look....code!

So I posted up a page of code today. You can see a link to it on the right titled intTextField. This page is a work in progress as I'm unsure exactly how I want to use the pages feature on blogger. . I want to showcase general purpose code that I write that I think would be useful for others and get feedback from others on it, and update it when I can.  So here is my first tiny piece of code for people to see. It is a user control that show a textfield that does server-side validation on it as a number and includes an asterisk that displays/hides depending on if the validation fails or not.

http://codetimecharlie.blogspot.com/p/inttextfield.html