Herding Unikitties

Coaching kids is hard. I mean, really hard. Last week, I had the awesome opportunity to be a coach for the first time. I’m coaching my son’s Junior FIRST LEGO League team. I’ve never coached kids for anything before. Sure, I’ve done a few show and tells in my kid’s daycare, and read a book to his Kindergarten class. But I’ve never sat with a bunch of kids for an extended amount of time with the expectations that they had to listen to me.

Before the first practice, I envisioned this:


But in reality, this happened:


And sometimes:


Holy hell, my repeated remarks of, “please take a seat,” and, “stop running,” were interpreted as “ZOMG-SHOWER-ME-WITH-MORE-LEGOS-ARRARRRHAHAHAHAHA-I-DON”T-KNOW-WHATS-HAPPENING-SUGAR-AND-PRETZELSTICK-LIGHTSABERS!”

The practice was pretty awesome. It was absolutely amazing to see a bunch of kids who didn’t know each other, almost instantly bond like some sort of human katamari (it literally looked like rolling a human katamari sometimes). The LEGO really interlocked these kids. And yet, every kid was completely different. Right away, we observed the clever thinkers, the shy ones, the rebels, and the storytellers.

I learned a lot in this first practice.
1. Adults are easier to coach than kids. Adults will mostly stop what they’re doing, pay attention to the speaker, and do as they are asked. Kids don’t. Full stop.

2. Use the session plan in the LEGO coach’s materials as a very general idealistic guideline. There is absolutely no way in hell that 6 year old kids will spend an hour and half going thru all of that material. We did an initial brainstorm for team names, but couldn’t get their attention spans in check to actually decide on a name yet. Forget making a logo in that first session. And once the BuildToExpress kits were introduced, we only made it thru 3 of the challenges.

3. Keep things moving. This is where I failed. I came in with a bulleted agenda based off of the lesson plan in the coach’s guide. I tried to go through the program and discuss the six “core values” for the program (e.g. “We are a team,” “We share,” etc). But I didn’t effectively cater to the short attention spans of the 6 year olds. And once the BuildToExpress kits were introduced, it was game over – it was buildin’ time.

4. The kids want to build with LEGO, so let them. Before the kits were given, they spent the whole time, just looking at the big tote of materials in the class asking, “When we can use the LEGO??!?” instead of listening to what I was trying to say. Once the kits were introduced, it seemed like they weren’t listening to what I was saying, but they sort of were. They’re heads were down and focused on building, but they would actually pick up on some of the words coming out of my mouth. The kids are there for the LEGO. So let them build. The stuff for the season challenge will come in time.

5. The most important thing is to make sure the kids have fun. I found it important to get all of the kids involved, creating, and sharing.

We spent quite a bit of time (probably too much time) brainstorming team names. The kids were all antsy (see the third picture above) and it was clear that they wanted to get they’re energy out. So we tabled the brainstorm and just had them open the BuildToExpress kits and start having at it. The decibel level in the room quickly dropped for the first time. We just let them play with the kits for a good 10min or so and not give any guidelines or challenges. I finally gave them a 2 minute warning and told them that they would all have to present their build. I had each kid do the following:

1. What’s your name?
2. What grade are you in?
3. Who’s your teacher?
4. Tell us 1 awesome thing that happened today.
5. Tell us about your LEGO creation.

This not only got each kid to initially present to the team, but served as a pretty good introduction. I’m pleasantly surprised that even work. Having each kid go through the intro actually took a lot longer than expected. A few of the kids got pretty…enthusiastic… about the story behind they’re model. Some of the stories were pretty elaborate. It’s hard to cut off a kid’s story, especially when they’re so excited and proud.

Next we went into the challenge cards. Sticking to the “2-3min” is nigh impossible. Every time I said that time is up, it was pitchforks and yelling of “MOAR TIME PLZ!” It’s more like 5-6min for the build. And again, the sharing part took way long. I found it super important to make sure everyone was involved. If someone was too shy to share or was stuck, I tried to lead them along with questions to get them thinking and building. We got through 3 builds and decided it was time to try to nail a team name from the initial list we had at the beginning of the practice.


Yeah, the team name didn’t happen. We were about an hour into the practice with about 20min still left, but the kids were done. My voice was background noise to their running and yelling. They were done with sitting, done with LEGO, done with humanity. I’m talking Lord of the Flies.

LordOfTheFlies 7

Ok, I may have exaggerated a tiny bit. In all seriousness, I’m really excited about this opportunity. It’s really cool to see the kids thinking and creating and working together. And this year’s challenge, Redefining Learning, looks incredibly fun. I’m super excited to see how this season goes.

Posted in JrFLL, LEGO, Projects | Tagged , | Leave a comment

Oh snap – I denied “Everyone” permissions from my MSMQ

Yeah, so in a brilliant move today, an MSMQ on my QA box was accidentally destroyed maliciously when I set Deny permissions for “Everyone”. Oops. Luckily this StackOverflow response from user Houman saved my ass. Simply navigate to C:\Windows\System32\msmq\storage\lqs and delete the queue. The names are cryptic, but lucky for me, that was the only queue that I touched and was able to locate it by ordering by timestamp.


[Blogging this so I can easily find this solution the next time I do this same boneheaded move.]

Posted in testing, Work | Tagged , , | Leave a comment

Inspiration in Everyday Things

I was lucky enough to attend CAST 2014 last week. CAST is a wonderful conference bringing some of great minds of the testing community together under one roof. Michael Larson has great summaries of the two day conference on his blog. Out of all of the great keynotes, Ben Simo’s talk was probably the most entertaining from a purely geek perspective.


Ben’s keynote, “There Was Not a Breach; There Was a Blog,” shares his experiences visiting HealthCare.gov and the wonderful ways in which the site totally failed. Ben goes in depth into the functionality issues, usability problems, and potential security implications of how the site was implemented. The talk was truly inspirational. Ben captivated everyone in the room, going step by step into what he tried, what he found, and why it’s a problem. Exploratory testing at his finest. My key takeaway from this talk and what really inspires me is this – any one of those testers in that room could do this, too.

If you watch Ben’s talk, he starts off talking about the tools he used. Everything he used is pretty much on your machine already:

  • Chrome and IE? Check.
  • Developer tools? Checkit’s part of the browsers!
  • Fiddler? This was the only ‘special’ tool that had to be installed. And this is free. And if you’re a tester who’s testing a website or app with network connectivity, you should have this on your machine already. Check.

He didn’t have a spec or user stories. He didn’t have source code available. He had no special access to internal builds, log files, etc. He wrote no “automation” or code of any kind to find bugs. Everything he did was public facing using the tools that we all [should already] have. And that to me is inspirational. And it should be inspirational for you, too.

Posted in testing | Tagged , | 1 Comment

AppFabric v1.1 Installer Hates You

[Blogging this because we’ve hit this a few times at work in the past 3 months]

If all attempts for installing AppFabric v1.1 fail with the ever helpful 1603, look in your %TEMP%\AppServerSetup1_1_CustomActions(datestring).log file [where datestring is the last time you invoked the installer]. You may see a message like this:

6/23/2014 11:32:45 AM EXEPATH=C:\Windows\system32\\net.exe PARAMS=localgroup AS_Observers /comment:"Members of this group can observe AppFabric." /add LOGFILE=C:\Users\me\AppData\Local\Temp\AppServerSetup1_1_CustomActions(2014-06-23 11-32-31).log
Error: System error 1379 has occurred.
Error: The specified local group already exists.

Answer: Visit this StackOverflow answer: http://stackoverflow.com/questions/16655899/appfabric-installation-error-code-1603. Basically, blow away the AS_Observers and AS_Administrators local groups. Then try to run the installer again.

Then go grab some ice and Tylenol. That past hour of slamming your head on your desk probably left a bruise.

Posted in Work | Tagged , , | Leave a comment

Better Workaround for AppFabric Cache’s Tracing Hatred

As a follow up from my last post, here’s a simple extension method to forcibly restore the default trace listener every time you invoke an AppFabric Caching Administration Management cmdlet. It’s not the prettiest code, but it’s functional:

Posted in Work | Tagged , , , , | Leave a comment

AppFabric DataCacheServerLogManager Hates Your Trace.WriteLines

I like to fill my test code with TONS of logging. I log damn near everything because I hate it when the team has to waste time answering, “Can you get me a repro?” when we can just peruse the logs to see what went wrong. I also like to watch the traces get logged in real time using DebugView as my tests execute. So after I made some recent changes in my code to programmatically manage our AppFabric cache, I was super bummed to see my real time logging completely disappear.

The following code shows a snippet of what my test code is doing to repro the issue:

The traces simply no longer get output to the default trace listener. Sure, if I setup a text file listener in my app.config, the traces are properly logged to the file. But what fun is that? I need this stuff in real time now, not after my 100 or so tests run.

So I posed this question to @drub0y, Mimeo’s Chief Software Architect. Sure enough minutes later he responded with:


Well damn. JustDecompile to the rescue. Let’s see how we could have done this ourselves.

  1. Fire up JustDecompile, and then load %PROGRAMFILES%\AppFabric 1.1 for Windows Server\Microsoft.ApplicationServer.Caching.Core.dll to the assembly list.
  2. Click on the Search button
  3. Go to the Full Text tab and enter: “Listeners”

You should then get a single hit:


And sure enough, when you double click on that, you get the code that @drub0y sent me in the mail above.

The fix? Easy. I just had to add a simple Trace.Listeners.Add(“DefaultTraceListener”) in my code after invoking the powershell pipeline.

Posted in testing, Work | Tagged , , , , | 1 Comment

Migrating TFS shelvesets to another branch

I keep forgetting how to do this, so I’m posting it so I don’t have to keep Googling this with Bing every time:

tfpt unshelve "[shelveset name]" /migrate /source:"$/serverpath/branch1" /target:"$/serverpath/branch2"

Posted in testing, Work | Tagged , | Leave a comment