Showing posts with label Testing. Show all posts
Showing posts with label Testing. Show all posts

Quarterly Goals Recap - March 2019

Read the original goal post here.

Phone Lock Screen Reminder; Source unknown
I'm here to write. Write I did. What I've been up to these last three months:

What Were My Goals?


  1. First Draft of Shallow Seas
    1. Failed. This is all on me. I wrote some +100K words. Most of that ended up in outlines that were rewritten and scrapped. One-and-a-half months spent on that. Heck, I have another outline. I learned I need to be faster on outlining and commit earlier. For now, I can get this draft done, my first draft of a novel-length work! (Almost there - another quarter should have it written.)
  2. Time Efficiency
    1. Won. From spending 40-50% of my time on what I categorize as time wasters (commuting, internet browsing) and chores (hygiene, food, cleaning), I'm sitting nicely at 25-26.5%! By any measure, this is a huge improvement. The goal was to get below 33% of time spent on these activities; the goal now is to maintain it.
  3. Be Assertive
    1. Won. I am asking more for what I want. I fear less of saying the word 'no'. There's a lot of improvement to be made here, though I think I'm on my way to... Better decisiveness? Self command? Self respect? Anyway, it's a good place to be.
  4. Voice Acting Credit
    1. Failed. Totally missed this. Time spent on writing Shallow Seas might have been split up to take on voice work. However, to attempt equal time for both would guarantee the mediocrity of each. I've learned a lot having two creative endeavors in one quarter.
  5. Marathon Capacity
    1. Failed. As soon as I posted this goal, I went for another half-marathon practice run in December. Only now, three months later, is the rough scar fading. I certainly need better shoes and socks if a full marathon is to be adequately trained for. The tangential benefit is that I spent more time on the low-impact stationary bike!
  6. Play Games
    1. Failed. I have an entry in my time tracking software for 'Pleasure - Games'. I have only now in the last week spent more time playing video games (six hours) than I have in the entirety of the last three months. This article sums up the paralysis I'm working on overcoming in not just game playing, but in many aspects of what is termed 'self care'.
  7. Read
    1. Won. Maybe. I'm doing this somewhat. Nearly every night before getting ready for bed or in the middle of a weekend's afternoon I'll settle down for an hour of physical browsing. I will do more of this, but that's a general statement of 'protect and value your time to yourself'. So for now, let's chalk this up to a win.

43% success rate. Ouch. And even after (temporarily) ending my time as a Couchsurfing host! Can I recover from that supposed failure? What are the lessons, the return, from all of this?

For one, be a lot faster in the brainstorming and outlining stages of writing - I wrote a full outline of Shallow Seas with everything but world description and dialogue, only to throw that out.

Another thing would be to have only one creative, product-generating goal in a quarter. Getting to voice acting felt as a drag on my psyche after spending two hours every morning writing on Shallow Seas. I must focus and there's only so much focus to go around.

Generally, protect my time. Really think about saying 'yes' to anything. 'No' ought to be the default; "if it's not a HELL YES, it's a no".

What's for next time? Here's a shortlist of some considerations:
  • Finish Shallow Seas's first draft.
  • Make a JimmyChattin.com website.
  • Edit a bunch of written short stories.
  • Spend a little less time on others.
  • Leverage certain financial saving opportunities.

Heck, maybe I'll just hire a life coach March 1st. Do you know one?


Quarterly Goals Recap - December 2018

Where have the three months gone!? Truly, time flies.

Just as truly, 2018 has been the year of self-discovery and definition. Between flexing my capabilities in software development, getting a better taste of project management, traveling abroad, writing, and putting pen-to-paper when it comes to what I want to accomplish in life, possibilities are both growing and solidifying.

Of the extreme danger of sounding more vague, simply put, I am.

Enough of that for now. Let's talk about what we set about to do three months ago and where we are now, three months hence.

What Were My Goals?

  1. Stream 100 Days
    1. Won. Verbatim, a stream didn't happen consistently for 100 days, nor did a schedule get strictly adhered to. Why? Two things: First, I liked engaging with viewers, but they weren't the reason I showed up on stream; they were a passive byproduct of me merely making public work that interested me. Second, spending two weeks in India with followup on either end of the trip put the nail in the coffin of "is streaming for me".
  2. Voice Work
    1. Failed. Did I learn how to voice act? Yes. Did I study, making a sample reel of voices? Yes. Did this get sent out, or myself apply to even gigs for free to try for accreditation? No.

      I really enjoy acting with my voice, so will I pursue more voice acting ventures? Most likely.
  3. Creative Writing
    1. Won. A story on my mind for awhile has been outlined. Certain fluid parts have solidified. That, and a balance-sheet of the stories I'd like to write has been put together. This sheet, which includes things other than writing, will be where future goals get drawn from.
  4. Say No!
    1. Failed. The (spectacular) failure here involves other people. I need to remove that weakness, being more assertive, and feeling more compassion for my future self more often than for the needs of others. Assertiveness is feedback from multiple folks in multiple scenes of my life, so there's something to it.

Despite having only four goals laid out this time, we're still 50% for success. Hey, at least I'm consistent!

What has been learned:
  • Don't fear dropping an exploratory goal (eg streaming) early if it really does not click.
  • Be assertive. Become more militant in protecting time.
  • I like voice acting.
  • I really like writing.
  • I really enjoy putting together spreadsheets!

During the last three months, a balance sheet of life goals has been put together and quantitatively evaluated. My five purposes in life have been distilled into four. Four 'buckets' of enjoyment have also been defined, though singular activities from these buckets may need to be specified for time's sake.

But what's next? It's clear more 'me' time is necessary, as well as writing. Things for the day job may be considered, including scheduling time off work. Whatever happens, we'll see more in the next post. Cheers for now!

Telemetry, Logging, Debugging : Background Necessities of Development

Imagine you're helping test Beth's game.  Suddenly, jumping onto a ledge in the new lava level, things begin to lag, enemies stop attacking, and the game crashes; a popup of "Unhandled Exception" shows.  Consulting Beth, she doesn't know what happened and confirms there isn't any information saved from the game in cases like this.  Thus, valuable details on a bug are lost, leaving Beth to try to reproduce the issue and stepping through the code with breakpoints!

After years of both making programs and being on the receiving-end of someone else's development, I've come to identify a number of things that every program should have (including Beth's) to help designers, testers, and the developer themselves when their product is in use. Let's see how they could help Beth's situation:

Telemetry

Performance

- Crashes: hold enough memory in reserve to send a final notification to inform on any crashes.  The type of crash (OOM, unhandled exception, etc.), the callstack, build version, and any other applicable details must be included in the telemetry event.  This way, no application failure will go unnoticed, decreasing turnaround time to getting a fix in.

- FPS, memory/CPU usage, and network details should be included in periodic telemetry check-ins.  Gauging what is happening between check-ins can show trends of where performance needs to be improved, such as in the lava level.
An example from the lava level could have been:
1-2-16 17:18:19 (date-time), 123abc (session-id), 0.1.2.3-Test (version), unhandled_exception (type), foo at bar (callstack if applicable), Lava_Level_1 (level), 12.3 (FPS), 456 MB (memory), Windows (platform)

Input

- Can the program accept user interaction?  If so, every user action should be attempted to be recorded (a must for simple GUIs).  For more complex products such as Beth's game that can have dozens of inputs in a single second, the following is more suitable:

Interaction

- Pickups, the firing of weapons, level exits, cinematic skipping, the works - in this case, more data is better.  When the user can take action on the content in the program, it should be recorded for later analysis.

- Things to include would be information akin to time/date, a session ID, XYZ, level, what's currently equipped, checkpoint, health, what's being interacted with, etc.

- If there are processes or actors (e.g. NPCs) other than what is coming from the user, record those, too!  Who's the AI targeting, how is the manager handling pickup clean-up, and the streaming-state of cinematics are all questions Beth should be wanting answers to.

Logs

In General

- Pick a spot to put playtime and error logs that is going to be present on every system (a user's Documents folder, phone/console scratch folders, etc.).  When on a development environment, the details should be very verbose, allowing anyone to deduce what both the player and the system were doing at any given point.
During release, the user doesn't (shouldn't) need to see all the details of what is going on, so regular playtime logs could be toned-down or turned-off.  Error logs do, however, need to be made available to the end-user if developer follow-up is required.

Debugging

Hooks

- Exposing debug hooks that affect the nature and status of the program is necessary if there's any high-level blackbox testing to be done.  Instead of starting from scratch, a testing user can allocate virtual funds, profile details, and, in games, weapons, health, and altered-AI states quickly and on-demand.  Instead of starting from level 1 in Beth's game, the player can go straight to the lava level and re-equip the gear they had before the crash!

- Hooks should be disabled for release builds of the product to eliminate an avenue of unwanted manipulation when it comes to data and performance.

Error Messaging

- No-matter the version, any time a program hits an error or crash, a useful error message should display to the user explaining the problem encountered and any additional steps they should take.

And what makes a message useful?
  • A lack of technical jargon.
  • An explanation that could be given to Beth's grandmother.
  • What can be done by the user in the future (e.g. enter only letters and spaces into a name field).
  • Contact info or a link to submit an error report (if the issue is serious enough).

Before Beth starts looking into why the game crashed on the lava level, she may want to spend time implementing behind-the-scenes systems to make future issues easier to resolve.

Including telemetry, session logs, and embedded debugging in any game or commercial app will ease a lot of pain when a user comes back with a crash or other heinous issue that needs correction.  For myself, this is a best practice for anything new I make, and I highly encourage you to do the same!