I had an opportunity to attend Refresh OKC's July meeting. They are a group of web developers and designers that meet on topics that generally tie into their work, but don't limit themselves to striclty web design/development.
If this is of any interest to you, check out their website.
Also, there is a information security group DC405 that meets monthly. I haven't checked them out, but hope to in the next month or so.
What other groups would you recommend?
Thursday, July 23, 2009
Monday, July 20, 2009
Meeting Announcement - Thursday, July 23rd 11:30am
Time and Location
The Red Earth QA's meeting will be held on the 3rd floor of 100 N. Broadway from 11:30am-1pm on Thursday, June 25th. Look for the signs to direct you to the correct room.
Topic
Frank Roland will talk about his quest to prove that his Soduku solving application works as it supposed to.Directions
- You can park in Main Street Parking on Main or you can find street parking.
- From I-40, take the Robinson Exit. Go North on Robinson to Main. Right on Main. You can either go to Main Street Parking or continue to Santa Fe Parking. You will see 100 N Broadway on your left across Broadway. The building says 'Chase' at the top.
Thursday, July 02, 2009
A Child's View of Debugging
This summer, a friend of mine asked me if my eight year old son would be interested in a Summer Robotics Club. Completely thinking of my son (wink wink), I agreed.
The group meets about every other weekend over the summer covering various topics such as basic theory of atoms, introductory programming and of course, assembling a robot from a kit.
It was my job to do several sessions on introductory programming skills. We used a program called Alice, a free tool for learning programming skills by building 3D animations and even some simple games.
The first session was to go through a tutorial of the User Interface and modify a simple pre-made animation. The second session was troubleshooting a 'broken' animation.
The 'broken' animation showed a top view of an airport, with a single car in the parking lot. The car attempts to drive around the airport, but it goes through the building at one point. It also goes 'too fast' at other times.
Here is one solution by one team of kids. Note that these two were nine years old.
Here are some observations from this solution. They were time-limited, and didn't quite finish.
- The car ends up going off the screen at a couple points
- The car speed issue wasn't addressed
- In the original animation, the car ended up at the exact same spot it started from. In each solution, including this one, the car ended up in a different location (even if just slightly).
- etc.
Overall, I saw some very familiar themes in the whole process. See if any of these sound familiar.
Kids
The car ends up going off the screen at a couple points
Adults
Some attempts at repair cause other issues, even if the attempts don't have any impact on the issue being solved.
Kids
The car speed issue wasn't addressed
Adults
Some bugs will never get fixed.
Kids
In the original animation, the car ended up at the exact same spot it started from. In each solution, including this one, the car ended up in a different location (even if just slightly).
Adults
Sometimes, we break existing functionality when we fix issues. Functionality that isn't listed as a requirement is the most succeptible.
Kids
Note the pause at the end of the video, followed by a short drive forward. This was an attempt to get the car closer to the original location.
Adults
Not all solutions are elegant. It may get the job done, but it could be done more easily.
Kids
Is this close enough?" was a question I got in regards to getting the car back to it's starting point.
Adults
While it may be possible to get an 'exact' solution, 'good enough' may be all that is done.
Kids
"Just a minute! I'm almost done!" was a protest I heard when I told them we needed to move on.
Adults
Debugging is difficult to estimate.
Everyone wants to do a good job and finish the task given.
Kids
In the beginning, changes were being made to the wrong part of the code. There wasn't a clear understanding of where the actual issue was. When a change was made to the wrong part of the code and the animation didn't change as they expected, they blamed the computer for not working right.
Adults
Sometimes we get stumped by a problem. We think we are doing the right thing, but we don't see any progress.
Overall, we had a great time. We still have more sessoins left, so there may be more stories.
The group meets about every other weekend over the summer covering various topics such as basic theory of atoms, introductory programming and of course, assembling a robot from a kit.
It was my job to do several sessions on introductory programming skills. We used a program called Alice, a free tool for learning programming skills by building 3D animations and even some simple games.
The first session was to go through a tutorial of the User Interface and modify a simple pre-made animation. The second session was troubleshooting a 'broken' animation.
The 'broken' animation showed a top view of an airport, with a single car in the parking lot. The car attempts to drive around the airport, but it goes through the building at one point. It also goes 'too fast' at other times.
Here is one solution by one team of kids. Note that these two were nine years old.
Here are some observations from this solution. They were time-limited, and didn't quite finish.
- The car ends up going off the screen at a couple points
- The car speed issue wasn't addressed
- In the original animation, the car ended up at the exact same spot it started from. In each solution, including this one, the car ended up in a different location (even if just slightly).
- etc.
Overall, I saw some very familiar themes in the whole process. See if any of these sound familiar.
Kids
The car ends up going off the screen at a couple points
Adults
Some attempts at repair cause other issues, even if the attempts don't have any impact on the issue being solved.
Kids
The car speed issue wasn't addressed
Adults
Some bugs will never get fixed.
Kids
In the original animation, the car ended up at the exact same spot it started from. In each solution, including this one, the car ended up in a different location (even if just slightly).
Adults
Sometimes, we break existing functionality when we fix issues. Functionality that isn't listed as a requirement is the most succeptible.
Kids
Note the pause at the end of the video, followed by a short drive forward. This was an attempt to get the car closer to the original location.
Adults
Not all solutions are elegant. It may get the job done, but it could be done more easily.
Kids
Is this close enough?" was a question I got in regards to getting the car back to it's starting point.
Adults
While it may be possible to get an 'exact' solution, 'good enough' may be all that is done.
Kids
"Just a minute! I'm almost done!" was a protest I heard when I told them we needed to move on.
Adults
Debugging is difficult to estimate.
Everyone wants to do a good job and finish the task given.
Kids
In the beginning, changes were being made to the wrong part of the code. There wasn't a clear understanding of where the actual issue was. When a change was made to the wrong part of the code and the animation didn't change as they expected, they blamed the computer for not working right.
Adults
Sometimes we get stumped by a problem. We think we are doing the right thing, but we don't see any progress.
Overall, we had a great time. We still have more sessoins left, so there may be more stories.
Subscribe to:
Posts (Atom)