The Unexpected Bug

    If you have programmed, you have seen bugs.  The only bug-free code is no code at all.  Everything can break, it just depends on the conditions.   There are a few other programmer clichés, but they slip my mind at the moment.  All of these canards speak to one fundamental fact, you will find bugs in your code.  You may even grow to rely on errors or exceptions to handle your debugging and logic design.  I would not recommend this, but it illustrates that every programmer has their bug 'tolerance level'.   Once that level or alarm goes off, then that bug has to be fixed or scheduled for a fix before you go mad (or your boss sees it in action. During a demo. To the Client.)  
    Of course all bugs are not the same.  Some are irritating, slow down or hamper performance, or just do something wrong that only you, the developer, can notice.  All of these may trigger a hunt for the culprit, but usually can be cataloged, recorded, and ignored when initially found*.
    The bug that always gets the attention is the one that you did not see coming.  You are working your way through some test cases or running the code to see how your latest changes perform and POOF!  You app drops out and your debugger really has no clue why.  Well, some clues, but not enough to find the exact spot of the problem.  After your initial shock that the tools have failed you, you start wondering what caused the crash?  Can I recreate this crash?  Luckily, apps are not huge software programs, so getting back to where it crashed is usually pretty simple.  If it crashes again, great!  You have now found the problem area and are much closer to finding the root cause.  If it doesn't crash, you now wonder if you recreated it right or have a more subtle problem in your code.  (My C developer hat is shouting, "Check your pointers!")
    Now the catalog process begins.  If you can recreate it, chances are you can find the problem area and fix it on the spot.  If it is too big to fix, it can be logged as a TODO for the future.  Now you have to try to avoid doing that crash sequence until the fix is in, but sometimes it can wait.  Most of the times, it can't wait because it could be the symptom of something more serious in the your code.  Either way, it will take time to uncover, document, and fix.  This is the programmer's 'padding' when trying to estimate a how long a program will take to write.  If you mess up too much or don't get the design right initially, you can blow up your timeline pretty quickly.  The padding in your estimate allows smaller delays and bugs to be fixed without the stress of a missed deadline.  Of course, if you do finish early, then you can add some extra features.   Win/Win!
    On the other hand, a little extra testing might be a better way to use up that extra time.  You never know what might happen.


* Now that last statement depends on who found it.  My friends that perform testing on software will often disagree on the priority with the programmer.  They are usually right, as they are closer to a customer than the programmer, but priorities are sometimes tricky.

The Power of Boredom

I love the Wolverine look  of this selfie.

    When working on any project, there are points or days when nothing seems to get done.  Maybe some tweaks here or there, but nothing substantial.  For me, this is usually when I am planning an undertaking that will require extra thinking or effort to complete.  I form the original plan or concept and start my mind thinking about the various ways and variables that will be involved in completing the task(s).  This week it is more of the A.I. logic for the computer opponent, but other weeks it could be something else.  The point is that the tasks are going to require some effort and when you sit down to do the work, your mind just shies away from concentrating on the task.
    In my case, this is usually a few mental or physical non-related tasks that can distract from the actual work.  Maybe a bit of news reading, a study of a new programming constructs or language, or some household chores that need to be done.  We all have our ways of getting out of work, even when you work for yourself.   "If I catch up on this, I will be free to work on that", my thinking runs.  Sometimes it works, but most times, it just took you away from the required job.  This can lead to more inertia building up for the task and mentally making it harder to tackle later on.  Weird, but it feels like this at times.
    Setting an actual time to start work for the day or scheduling work periods, helps a lot avoid this procrastination.  Other times, you sit at your work area and just feel bored or uninspired.  It is easy to be bored with something that you do all the time, like programming, writing, or even driving a truck. It is pretty hard to avoid boredom in most jobs.  In my case, I find that embracing my boredom instead of trying to alleviate it helps break the cycle.  Recognizing that I am bored, especially when I have a tough task ahead, is the first step.  Once I catch on what my brain is trying to pull, it is usually better to just sit there and start reviewing the task at hand.  Maybe looking over previous notes or just throwing a few designs on a white board related to the problem will start overcoming the boredom and start the work moving forward.  After a bit of review or some 'blue-sky' ideas,  I find my interest starting to pick up and the old familiar feeling of fixing or solving a problem starts to show up.  Once I am programming and seeing the problem getting solved, then time flies and the boredom is just a memory.
    In short, if I recognize I am procrastinating or pushing the task down the road, it helps to pick at the problem edges until something triggers that old enthusiasm for the job.  Everyone loves doing something and hopefully it is something they do in their work.  In my case, it is design and programming.  I just need to get bored sometimes to get the work done.

What the heck is the A.I. doing?

Cookie Walk

    Sorry for the disturbing cookie man walk, but I find it oddly hypnotic and funny.  It does appear to be knowing where it is going in a hurry.  It walks with purpose and fairly smooth if a bit repetitive.  As we all know now, this is just a series of images that are repeated in a loop.  Each 'cycle' of the loop  the program determines the next picture to show.  If you were to add some alternative pictures, like say a jumping action sequence, then Ginger would start to jump occasionally.  The key word here is 'occasionally'.  What determines the occasional hitch in his step?  Picking that decision to walk or hop at certain times is the Artificial Intelligence or AI of the program.  Granted it is pretty simple, but it does give the illusion of decision.
    Why am I explaining this?  Well yesterday, I got the flow lines working correctly.  (Drag to create.  Drag over on them to replace.  Deleting lines TBD)  In order to get this rework done, I had to disable the AI routines.  So its pretty easy to beat the opponent that just sits there.  Now seemed like a good time to revise the AI to stop picking the next square to attack and start using flow lines.  Hmm.  This means I have to change 'Larry' and 'Oscar', my AI routines.  They each attack the board in different ways based on the timestamp or cycle.   Since I need to change these characters to use flow lines instead of attacking squares, it seemed a good day for readdressing the AI problem.
    Today I put some more design into the AI of the flow puzzle/game we are building.  I like what Larry, Oscar, and all their future buddies do at various cycles.  Changing this behavior to work with the flow lines should not be too difficult.  After this, I will need to create a few more characters to join the merry band of AI opponents.  They won't do much or be complicated, but I figure I can add some more variability by switching characters depending on the situation or time.   This sounds like a good game plan for this week to get the game back to playing levels again.
    For example, run the AI as Larry 25% of time, and as Oscar the other 75%.  We can call this new player 'Joe', but his real identity is the percentage of decision time he has allotted to each of this personalities.  Joe is normally acting like Oscar, but occasionally he lets his inner Larry out.
    Joe now is really just a mix, but really, who are we to judge?  Aren't we all a bit mixed up?
 

Software Updates - Programmer Edition

    Have you ever had to upgrade the software that you use on a regular basis?   For example a word processing program or browser will get upgraded occasionally to add all the new bells and whistles you didn't know you needed.  Regardless of the selling pattern, we do eventually upgrade our everyday software and hope it goes smoothly.  Usually it does, but other times a document or program that was just fine before the upgrade is now giving you problems.  "Well this is unexpected," you think to yourself and proceed to lose more time to the upgraded software.  The price of doing business on a computer, I suppose.
    As a developer, I usually am trying out the latest and greatest software that deals with my work.  As long as I have the time to spare, that is.  Sometimes,  you have to upgrade to stay current in your programming circles.  Today was one of those days for me as I upgraded my main XCode development environment.  I have been testing it out in the past, but today is the first day of using it as the 'main horse' to ride.  It is pretty nifty and pretty, but also a bit more strict.  Thanks to this, I have new bugs to chase down now, but a quiet weekend to do this.
    It does make you wonder or even pine for the good old days where you just typed everything into a glorified text editor and then told the computer to show you the results of your program.  The upgrade cycle then was pretty rare and in smaller increments of additional functionality.  You actually got pretty attached to your editors and small software utilities you used everyday.  Even today, I can usually stir up old arguments with other programmers by saying VI is the pinnacle of code editors.
    Of course, back then we didn't really have internet lookup of technical specs or development samples.   We would read the books that were available and experiment with the few examples we could find to learn how to do the next trick.  Now more tricks are available using the advanced programming tools, so we adapt and learn to deal with upgrades.  Hey, at least we have the internet to look up any tips or information we desire.  Sigh.
    And tell those kids to get off my lawn with their loud music...
   

Design Decisions

    The 'Flow Line' changes continue on our strategy puzzle.  The lines are used to indicate where you want your colors to flow to attack the squares in a line on the board.  Now that the lines are being created nicely with the drag action, I need to find a way to remove the lines that are being overwritten or deleted.  I have a few choices on how to handle this:

1. The game board itself could determine if the line is a replacement or needs deletion.  Since the game board is the one displaying the lines and handling the interaction of flows on the screen, this could be handy.  On the other hand, the determination of which lines are replacements or not seems a bit out of the game board's responsibly.
2. Another method would be to have the Line class itself handle the determination of what is a good line or replacement line.  This moves this logic into the class that has to handle it which seems more appropriate.  Then the game board can just use the Line's methods to determine which lines stays or goes.  This would also handy if I decide to create something other than lines to move colors.  Maybe I want a square type operation in the future.  Who knows?  It would not matter as much to the game board.

    The design could work either way, but I suspect that the game board handling everything would eventually start to feel bloated and resistant to future changes.  In the words of Martin Fowler, who wrote one of the classic programming books on Refactoring, it would start to 'smell'.  That is a nice way of saying you are not happy with how the code is turning out.  

    The funny thing about design, is that it can only take you so far.  First of all, you can't spend too much time on design because invariably the actual coding will expose a problem that you did not conceive of in the design phase.  The design/code cycle needs to be iterative to remain flexible to these challenges.  Once the code is put into place, you might find that you don't like that design after all. 

    And something does not smell right...

Rebecca: Settled into summer?

Since Fall officially starts in less than 2 weeks, I am left wondering what happen to summer.  In June, the kids finished up school, and I dreamed of all I would accomplish during the lazy days of summer. Without the chaotic schedule of school and activities, I planned to dedicate some time and energy to Zenerdgy.
As the family prepared for Back to School, I stood in disbelief about how little I accomplished for our young company.  I am not sure if I should feel guilty or not.  We had a great summer.  We had several great camping trips, hosted several visitors, and we enjoyed the sights in the beautiful NW.  It was a summer full of family and close friends.  Honestly, I do not feel guilty; but I wonder about how to give Zenerdgy the time and energy it needs.
Should I try to blog?  What should I be doing for social media?  Marketing research?  Sales? How many downloads?  When I start thinking about all the TO DOs, I become overwhelmed and want to return to the blissful days of summer.
As the saying goes, "one step at a time."  Today, I will post a blog.  Today,  I will dust off the TO DO list and update it.  Tomorrow...

Office Hours

  Well this was the first week of School for our kids and the quiet has been appreciated.  I finally got the attack flow lines working correctly on the screen.  Colors flow down the line attacking the next square as requested by the user.  Sounds simple, but once I switched from the previous (single touch attack) method, I realized I had a bit more redesign to get it working the new way.  Of course, the stuff I ripped out was running the A.I. opponent moves, so those have to be reworked.  The A.I. opponent engine needs lots more smarts anyway, so this work was expected.  On the plus side, it is really easy to kill the A.I. for the user...
    Although this was a short week, I did find a lot of good design/discovery/coding was accomplished in the 4-6 hour window of time when I had the house to myself.  Sometimes your brain just needs a bit of uninterrupted time to properly analyze a problem and find a solution.  This week has given me a few of those periods to really dig into the code and refactor* the problem parts.   Sometimes when you are looking at multiple files and parts of the code you find yourself 'code juggling'.  This juggling of ideas and things to do can keep you from getting the work done.  Its distracting.  You either get serious tunnel vision to fix an issue or eventually drop the balls and go do something else entirely.  You usually need to fix one issue to reduce the number of items juggled.   I find that if I can get a few hours on my own, I can juggle a few more balls and get stuff fixed.
    Where am I going with this?  I guess I am thankful to get back to work on a more consistent basis and grateful for those occasional distraction-free periods.  It is good to "be back".  Now onto those A.I. flow lines...


 
   * In programmer language, we call this revamping of the code as "refactoring".  I use the term a bit generally, because true refactoring is a series of steps to clean up poorly designed or maintained code.  You start by setting up some tests to prove the code works the proper way.  Then, you redesign the code to shrink the problem areas and hopefully make the area more clean and understandable for the next programmer.  Lastly, you run the original tests to insure you did not wreck the original purpose of the code.

The Lost Summer

    Wow.  Finally another blog post.  Today is the first day of school for our children in Washington and also the time to get back to a normal work schedule.  Our very busy Summer left little uninterrupted time for programming.  Most of the last 8 weeks have had some form of interruption involving the kids, family or camping.  Not a bad problem to have, but not much work has been accomplished.  I found myself doing more small bug fixes and experimenting with designs for the current puzzle game and other future projects.  This meant more white board and less actual code time.
   Today the whole family got back to work/school and hopefully the current project will start showing more progress and less inertia on my part.  This blog post is meant to be one of the steps that will help be accomplish this goal.  If you write it, it will come.  Or something like that.
    Our latest project, the Flow War / Puzzle game has had a few setbacks lately.  I did not like the single touch system used for moving flows from one 'square' to another.  I changed this system into more of a drag arrows to indicate flow instead of touching a lot of squares in sequential order.  In order to do this, I had to build the new flow arrows to work with the drag behavior and also disable the old system of single touches.  So now I have a game board that accepts arrows being drawn on the board, but have not implemented the replacement for the 'touch flows'.  This means the board shows the computer opponent filling it's squares just fine, but the human can only draw pretty arrows with no flows.  I would say that the user will expect more from a game.
    I did also put together a nice screen for selecting the level to play.  It uses the swipes to pull the desired level to the forefront like turning pages.  To get that working consistently, I had to add in some rudimentary file saves to allow the user to keep the level selected.  It looks nice and helps me in trying out the various A.I. opponent programs that I have come up with for testing.  
   I also still have to add in the Player components to the game.  This is the part of the game that keeps track of the various players, their levels and achievements completed, and other progress items.  Since this is pretty common for most games, I am trying to design this as one 'drop-in' module so that future games can just plug and play to get this functionality.  I am hoping to get this all wrapped up in the coming week, but we will see.
   It was a great summer, but it is good to be back coding.