Resistance is not futile, no matter what that infamous collective would have you believe. This is just their propaganda machine lowering the resistance of their foes.
Hang in me, you get a couple short paragraphs of electronics context before the good stuff.
What is resistance? In the world of electronics, it is an inverse measure of the conductivity of a material. It is measured in "Ohms." Conductivity is measured in "Mhos" how cute. Resistors are electrical devices that are created to give a specific resistance within a specified tolerance. Resistores are available ranging from milliOhms to MegOhms, quite a few orders of magnitude. Resistors are critical to the proper operation of nearly every electronic device, gadget and system we use on a daily basis.
There is one electrical system where any resistance is extremely detrimental to proper operation. The starter motor on a car. One ohm of resistance will cause the entire system to fall on its face. Such a little amount of resistance, how does this happen? Lets take a super quick hopefully painless look at Ohms Law. E=I*R. E is the Voltage drop across a conductor, I is the current flowing through, R is the resistance. In a car starter the object is to get as much power from the battery to the starter as possible. so if we have one Ohm of resistance how much power will that steal from the system? We can figure this out from some things we know. A typical car starter will draw 100-200 amps while starting the car, we will go with 100 amps. Drawing 100 amps through a 1 ohm resistor will drop voltage by 100 volts (I think this would use up approximately 1.21 jigawatts.) Oh we start from 12 volts. Thats where things get complex. Lets go with one tenth of an Ohm of resistance, now we are only dropping 10 volts. Leaving 2 volts for the starter. We need another equation P=I*E, the PIE equation (makes me hungry) Power = Current * Voltage. That gives 1000 watts going to the resistance and 200 watts left for the starter. Guess what? The car is not going to start! Where does this resistance come from? Usually loose battery terminals or corrosion somewhere, been there done that.
Good you made it through the mumbo jumbo. How does this apply to you?
Resistance can come in many forms and in many places. Office place resistance, boss says prepare the TPS reports, it is natural to respond with a little resistance. This is a low current request, so even a lot of resistance will not generate a lot of wasted effort or extra heat. Two year old resistance, ask any two year old to do anything, will will find out what two year old resistance is. Teenager resistance, see two year old resistance.
At times resistance is a good thing. We are assigned a test and hesitate to do it. We mull it over and eventually decide on the best course of action and the product is better for the resistance.
Some times resistance is very bad. A high current system must transfer as much power to the end result as possible. Like a car starter any resistance is likely to stop the entire project dead in its tracks. A business startup is like this as much energy as possible needs to transfer to the end product. A little corrosion in the line, such as an uncooperative business partner, non-availability of food money or stiff regulations. Will make it very difficult to get started.
Resistors when connected in parallel lower the over all system resistance. If you see a system where someone is being a resistor you can choose to short-circuit the system to make things happen. You see where someones lack of experience is slowing down a project and you pitch in. This is something to feel good about. It is also a time to be careful. Like a two year old that will not learn to tie his shoes if you keep doing it for him, people will keep needing a bailout if you keep bailing them out. I think this is where the old saying about giving fish and teacking how to fish applies.
At times people will be the resistance on purpose, and out of spite. Please try to recognize if you are doing this yourself, please try to help people along if possible, or at least to not cause them resistance along the way.
If you want more on this let me know, I have some thoughts on internal resistance.
Thanks for reading,
David
Friday, September 16, 2011
Wednesday, September 14, 2011
"Checking is not Testing" GR-Testers recap 9/13/2011
I had a great time at the Grand Rapids Software Testers meeting last night. The main topic was "Checking is not Testing" which inspired a great deal of lively conversation.
We gathered once again at Salvatore's in Grand Rapids. We started on the deck but decided it was a bit to chilly and moved inside for the rest of the evening. There was a great showing, with Wade coming all the way from Traverse City just for our event (really this time.) Todd, Pete, Greg, Anita, Mrs. Walen, ??? (a delightful young lady, guest of Pete's but I can not remember her name), Rob, Mel and David were there too. That is ten in all if you are playing along at home.
We ordered food and waited for later arrivals. Starting our usual catchup time, it was a busy month. Rob brought many entertaining stories from his trip to Chicago. Pete brought news from CAST including this outstanding quote:
"Counting test cases to assess coverage is like using frequent flyer miles to see how much of the world someone has seen. It doesn't work" -- Benjamin Yaroch at CAST 2011
Captured by Mel at http://t.co/mNECSq2
The food arrived, it was excellent, perhaps even more so than usual. We noticed that it was getting a little late, and discussed moving the main discussion ahead of the food for next month. After eating and clearing dishes the main discussion ensued.
"Checking is not Testing"
We wanted to explore the similarities and differences in checking and testing. Both activities has a place and are useful in the process of improving software but is one over emphasized, is one seen as a silver bullet and over used to try to solve problems it can not solve?
We started with a little activity you can try yourself at: http://www.hopasaurus.com/cint.html
This is a little exercise to emphasize the point. There is a big difference between checking and testing. With pure checking to specification the calculator "works" that is it passes all of the "tests". It is quite impossible to miss some of the glaring problems. But. If it was an automated test it surely would pass. What if there were only a mechanism to indicate that the prescribed "tests" passed? The result would be "Ship it!" As facilitator of the activity I was accused of sounding a lot like a product manager , I took this as a compliment to my acting skills. After running the prescribedtests checks, we really tested the calculator. It was not hard to find problems, they were put there on purpose but what if this were a real product, with problems not so obvious?
After the introduction, a lot of really good discussion took place. We talked about testing only to specification, the problems that arise, the ethical dilemma. Can a professional tester test only to specification? Should a professional tester test only to specification? Can testing be automated? What is the difference between checking and testing? When is checking useful and when is testing required? It was great discussion. I encourage you to use these questions to seed future discussion.
Some of our observations were that testers do not have the narrow focus of the machine. We see "what else happened" (the '5' changed color when the '8' is pressed.) We discussed how testers try things that are outside the vary narrow test plan, what happens when I try the '6' (nothing.) We talked about noticing things that are just plain wrong, there is no zero, the numbers are in a zig-zag pattern, the '9' is not styled and so on. These are things that do not get tested with automated checks.
We talked about the value of automated checks. With TDD and automated checks are useful to ensure the program works to specification. Automated and scripted checks are also useful as a way of defining and checking on problems that have occurred in the past to see that they have not returned. It is very important to recognize the limitations of automated check.
We discussed the terminology. "Checking" vs. "Testing" these words are thrown around so loosely that it is easy to get confused. It is understandable that people less interested in testing are confused also, they do not care of semantics, they want their bonus, they want it to work right, they want it now. I think we must all bear the burden of educating those we work with on the proper terminology. We must also present the value and limitations of checking and testing. These words are deeply ingrained in the language, sometimes in a way that may be a little wrong. "Unit Tests" are not tests. "Automated Acceptance Tests" are not tests. TDD may be better termed as CDD. Hoping that these will be corrected in the language may be like hoping the talking head on the nightly news will learn the difference between "hacker" and "cracker" it just ain't gonna happen.
We discussed "Requirements" and testing to them. We talked about how they are a mysterious moving target and that there quite often seems to be a stated or unstated requirement of "... and none of my existing data or functionality are harmed." We talked about how this is the very essence of the argument for doing real software testing.
We shared some war stories. Some involving real war. A missile being tested (in front of top brass) failed. Performance testing (not testing the performance of the product, showing the product off) running the product in such a way to "prove" it ready for shipment by carefully avoiding known pitfalls. Pete shared the dismay he received when he developed a set of tests which were "missing" the "answers." The expectation was that the answers were to be specified with the test. Pete's point being that is not a test. The tester should know when the output is wrong. The tester should observe the other side effects of running the program.
Some of the group read and used portions of this article to seed the discussion: http://www.developsense.com/blog/2009/08/testing-vs-checking/ we thank Michael Bolton (the software tester not that other guy, or the other other guy) for sharing this.
I had a really great time, judging by the time we wrapped up everyone else did too.
At the end of the evening we discussed topics and times for next month. The tentative topic is "Education and Software Testing" it will be an interesting discussion for sure. The time and venue are up for discussion. The outside venue as Salvatore's is most likely out, and inside is a little difficult and we do not want to disrupt the other guests. Be sure to watch the email list and check http://www.meetup.com/GR-Testers/ for details.
We gathered once again at Salvatore's in Grand Rapids. We started on the deck but decided it was a bit to chilly and moved inside for the rest of the evening. There was a great showing, with Wade coming all the way from Traverse City just for our event (really this time.) Todd, Pete, Greg, Anita, Mrs. Walen, ??? (a delightful young lady, guest of Pete's but I can not remember her name), Rob, Mel and David were there too. That is ten in all if you are playing along at home.
We ordered food and waited for later arrivals. Starting our usual catchup time, it was a busy month. Rob brought many entertaining stories from his trip to Chicago. Pete brought news from CAST including this outstanding quote:
"Counting test cases to assess coverage is like using frequent flyer miles to see how much of the world someone has seen. It doesn't work" -- Benjamin Yaroch at CAST 2011
Captured by Mel at http://t.co/mNECSq2
The food arrived, it was excellent, perhaps even more so than usual. We noticed that it was getting a little late, and discussed moving the main discussion ahead of the food for next month. After eating and clearing dishes the main discussion ensued.
"Checking is not Testing"
We wanted to explore the similarities and differences in checking and testing. Both activities has a place and are useful in the process of improving software but is one over emphasized, is one seen as a silver bullet and over used to try to solve problems it can not solve?
We started with a little activity you can try yourself at: http://www.hopasaurus.com/cint.html
This is a little exercise to emphasize the point. There is a big difference between checking and testing. With pure checking to specification the calculator "works" that is it passes all of the "tests". It is quite impossible to miss some of the glaring problems. But. If it was an automated test it surely would pass. What if there were only a mechanism to indicate that the prescribed "tests" passed? The result would be "Ship it!" As facilitator of the activity I was accused of sounding a lot like a product manager , I took this as a compliment to my acting skills. After running the prescribed
After the introduction, a lot of really good discussion took place. We talked about testing only to specification, the problems that arise, the ethical dilemma. Can a professional tester test only to specification? Should a professional tester test only to specification? Can testing be automated? What is the difference between checking and testing? When is checking useful and when is testing required? It was great discussion. I encourage you to use these questions to seed future discussion.
Some of our observations were that testers do not have the narrow focus of the machine. We see "what else happened" (the '5' changed color when the '8' is pressed.) We discussed how testers try things that are outside the vary narrow test plan, what happens when I try the '6' (nothing.) We talked about noticing things that are just plain wrong, there is no zero, the numbers are in a zig-zag pattern, the '9' is not styled and so on. These are things that do not get tested with automated checks.
We talked about the value of automated checks. With TDD and automated checks are useful to ensure the program works to specification. Automated and scripted checks are also useful as a way of defining and checking on problems that have occurred in the past to see that they have not returned. It is very important to recognize the limitations of automated check.
We discussed the terminology. "Checking" vs. "Testing" these words are thrown around so loosely that it is easy to get confused. It is understandable that people less interested in testing are confused also, they do not care of semantics, they want their bonus, they want it to work right, they want it now. I think we must all bear the burden of educating those we work with on the proper terminology. We must also present the value and limitations of checking and testing. These words are deeply ingrained in the language, sometimes in a way that may be a little wrong. "Unit Tests" are not tests. "Automated Acceptance Tests" are not tests. TDD may be better termed as CDD. Hoping that these will be corrected in the language may be like hoping the talking head on the nightly news will learn the difference between "hacker" and "cracker" it just ain't gonna happen.
We discussed "Requirements" and testing to them. We talked about how they are a mysterious moving target and that there quite often seems to be a stated or unstated requirement of "... and none of my existing data or functionality are harmed." We talked about how this is the very essence of the argument for doing real software testing.
We shared some war stories. Some involving real war. A missile being tested (in front of top brass) failed. Performance testing (not testing the performance of the product, showing the product off) running the product in such a way to "prove" it ready for shipment by carefully avoiding known pitfalls. Pete shared the dismay he received when he developed a set of tests which were "missing" the "answers." The expectation was that the answers were to be specified with the test. Pete's point being that is not a test. The tester should know when the output is wrong. The tester should observe the other side effects of running the program.
Some of the group read and used portions of this article to seed the discussion: http://www.developsense.com/blog/2009/08/testing-vs-checking/ we thank Michael Bolton (the software tester not that other guy, or the other other guy) for sharing this.
I had a really great time, judging by the time we wrapped up everyone else did too.
At the end of the evening we discussed topics and times for next month. The tentative topic is "Education and Software Testing" it will be an interesting discussion for sure. The time and venue are up for discussion. The outside venue as Salvatore's is most likely out, and inside is a little difficult and we do not want to disrupt the other guests. Be sure to watch the email list and check http://www.meetup.com/GR-Testers/ for details.
Wednesday, August 10, 2011
GR-Testers "Tester Games" recap
Good Morning Testers,
Had a great time at GR-Testers last night, here is a recap for the unfortunate tester who missed out on the fun.
We encountered the first game early in the evening, the door would not budge. Two of us tried, then moved on to other doors to find the same thing. Moving back to the main door we decided to give them a call and found it to be a mechanical malfunction. I was worried for a few minutes we would need to relocate.
After we found our table we started with some catchup and discussion. We congratulated Mel and the Booker App team on the recent media exposure see http://www.bookerapp.com/ and http://www.fox17online.com/
We welcomed a special guest, Phil, who came all the way from England just for GR-Testers (or something like that. Phil liked our meeting so much he is thinking about staying.) Rob, Steve, Mel, Greg, Todd and David were there too.
We also shared in Rob's excitement for his weekend plans to attend a conference in Chicago. This required and inspired some pop-culture education for some of us which was informative and entertaining.
We played the first game "Art Show." Mel Taught us this easy to learn but difficult master game. Every one caught on quickly however we were unable to solve the algorithm set forth by Mel. We played again with Rob's algorithm and failed again. But we had a lot of fun so did we really fail? At this time the food arrived and much pleasant and intriguing conversation ensued.
After the food was gone we wrapped up with a game called "Set" suggested by Matt Heusser. The was also a game that is easy to learn. The game requires finding a set of three cards that have either completely matching or completely different attribute. There are four attributes color, shape, number and shading/opacity. The concept is easy but the competition is fierce.
I know I had a great time and am sure the others did as well. It is always good to see the cooperation and collaboration towards a good time in the GR-Testers group.
We left with an unclear plan for next month, I am making a proposal here. I think we could do "Checking is not Testing." The idea is before the meeting, collect instances where checking (automated or not) has failed and discuss why this has failed and how good _context driven_ testing can improve on checking and highlight the value of good testing.
I also propose that we maintain the same location and time, it seems to work well for many, this would work out to be Tuesday September 13, 6:30pm at Salvatore's in Grand Rapids.
If you are looking for something fun, educational and entertaining to do on August 19 or 20 check out http://barcampgr.org/
Have a great day,
David Hoppe
Had a great time at GR-Testers last night, here is a recap for the unfortunate tester who missed out on the fun.
We encountered the first game early in the evening, the door would not budge. Two of us tried, then moved on to other doors to find the same thing. Moving back to the main door we decided to give them a call and found it to be a mechanical malfunction. I was worried for a few minutes we would need to relocate.
After we found our table we started with some catchup and discussion. We congratulated Mel and the Booker App team on the recent media exposure see http://www.bookerapp.com/ and http://www.fox17online.com/
We welcomed a special guest, Phil, who came all the way from England just for GR-Testers (or something like that. Phil liked our meeting so much he is thinking about staying.) Rob, Steve, Mel, Greg, Todd and David were there too.
We also shared in Rob's excitement for his weekend plans to attend a conference in Chicago. This required and inspired some pop-culture education for some of us which was informative and entertaining.
We played the first game "Art Show." Mel Taught us this easy to learn but difficult master game. Every one caught on quickly however we were unable to solve the algorithm set forth by Mel. We played again with Rob's algorithm and failed again. But we had a lot of fun so did we really fail? At this time the food arrived and much pleasant and intriguing conversation ensued.
After the food was gone we wrapped up with a game called "Set" suggested by Matt Heusser. The was also a game that is easy to learn. The game requires finding a set of three cards that have either completely matching or completely different attribute. There are four attributes color, shape, number and shading/opacity. The concept is easy but the competition is fierce.
I know I had a great time and am sure the others did as well. It is always good to see the cooperation and collaboration towards a good time in the GR-Testers group.
We left with an unclear plan for next month, I am making a proposal here. I think we could do "Checking is not Testing." The idea is before the meeting, collect instances where checking (automated or not) has failed and discuss why this has failed and how good _context driven_ testing can improve on checking and highlight the value of good testing.
I also propose that we maintain the same location and time, it seems to work well for many, this would work out to be Tuesday September 13, 6:30pm at Salvatore's in Grand Rapids.
If you are looking for something fun, educational and entertaining to do on August 19 or 20 check out http://barcampgr.org/
Have a great day,
David Hoppe
Tuesday, July 12, 2011
Success Secrets*
"Action is the foundational key to all success." - Pablo Picasso
Success is achieving your goals, what does is take to do this? Action. You must get up, out of the cave kill something and drag it home. That is how is was anyway, now it looks a lot more like driving to the office and sitting still in your cube. That is a big problem it is easy to look successful and slide by. In the days of yore it was not working meant not eating. Now it is easy to do just enough to get by. If you want success that is not good enough. The good news is it would appear there are not many that know this. Many many people are busy doing just enough to get by. A little effort will catapult you toward the the top of your field. Not that it is easy, success is not about easy most things worth doing are not easy, hard work and consistency are required.
Typically success is a good thing, joy and happiness follow success closely. Not always, success can bring sadness. Success in parenting means the little birdies leave the nest. Success in other ventures will bring a similar result. A short term sadness associated with the end of the assignment but in the long run the reward is great. Also there is a greater good associated with the project as whole. For the most part however, success is about increasing the joy and happiness of the lives we live.
"I honestly think it is better to be a failure at something you love than be a success at something you hate." - George Burns
Success means different things to different people. It means different things to the same person for that matter. There is internally recognized success and external success. Internal success is when you accomplish you own goal. External success is you accomplishing someone else's goal. Someone else may be you boss, your family or society in general. Becoming wealthy or famous is a societal goal. Many things are a combination of the two. Mowing the grass, spending time with family and things like that are internal and external goals. The same goal can mean different things at different times. Buying a car can mean any jalopy that can get from point A to point B, later sporty and red may be added to the requirements.
"I'm a loser baby……" - Beck
Winner and Loser relate to success, these ideas of are closely tied to external ideas of success. That is winner is usually tied to other peoples idea of success. A winner looks cool, a winner has lots of money, a winner gets the girl and so on. Loser is simply the opposite of winner. A really successful person should be able to separate from other definitions of winner and loser. A real winner takes time to teach their children, a real winner takes time to learn what is needed for success. These are alternate definitions of winner, you must make your own. You must decide what your definition of winner is you can decide what success is for you.
"Failure is success if we learn from it." - Malcom Forbes
Titanic, Challenger, that thing that missed Mars. Complete failure? Lets hope not. Failure is an integral part of success. It is rare that success is achieved in a straight line unhampered by failure. A road to success is paved with gold and unimpeded may be considered an ominous sign. A complete failure does not need to be. Nearly always there are lessons to be learned, a key to pulling success from failure is finding these lessons. Add more lifeboats, develop better failsafes, check you units. What can you learn from recent failures?
"I don't know the key to success, but the key to failure is trying to please everybody." - Bill Cosby
I think Mr. Cosby really hit the nail on the head with this one. Being a people pleaser is a sure fire way to go nuts, you will find yourself agreeing to competing objectives and working long hours for no good reason. Projects suffer from the same fate, adding a feature here and a feature there soon the project is massive and focus is lost. The group or individual must at the outset decide what success looks like and regularly measure against that, deciding if movement is toward the original goal or if the goal must be changed. This must be done regularly and on purpose or success will quietly slip away while you are not looking.
“The more you read, the more things you will know. The more that you learn, the more places you’ll go” – Dr. Seuss
Zig Ziglar, W Clement Stone, Napoleon Hill and a ton of other people have written on success. There is a lot of material prescribing different methods to attain success. I suggest the reader read these works with care. Make sure the idea of success presented in congruent with your own. There is a lot of good material, there is also a lot of fringe martial that is a bit out there. Be careful what you put in your mind, the same will come out.
*Yes I know there are no secrets here. It make a good title though and from casual observations of the world around me it would appear that some of these things are secret. Go prove me wrong, make a plan and follow through, claim your success.
Tuesday, June 28, 2011
The comment contribution
A lot of people want to be better at writing. We know what we need to do. We know we should practice. We know reading is a big part of writing. But the person who stares at me from the mirror keeps lying to me. Its too hard he says. You will never be any good he says. You have to many other things to do, I don't have time to do this I say.
Yes I am the one in the mirror. I am the one to blame for my problems. In this case, I want to do more writing. I was thinking about that while driving around today. I realized there is a good simple low risk way to practice. There are people I know writing columns, these columns are interesting to me and I read quite a few. Most have room for and encourage comments at the end.
This is a great opportunity not only read some great material and think critically about the material. This is also a time where I can absorb the material more deeply, providing a broader range of ideas to draw from for my future writings. If I want to retain the material, I should try to comment on the material. I want my comment to be well thought out, I want people to think "hey that is a great point." I also want to be able to support the writer of the original post. I want to read more material by this person so I should encourage the author by letting him know I like it.
I can also make critical points on the article. I try not to criticize the author. Snarky, snide and just plain rude are not rare enough elements. If I do not agree that is ok, if I can not make a point without resorting to these elements that says more about me than anyone else. I need to learn why I feel the way I do. I may learn my feelings on the issue are wrong. When this happens, it is a great opportunity to share what you have learned. This can either be a comment on the authors work or fodder for your own place on the web.
So help yourself and others with comments. Read more, think more and write more. Lets learn together.
Your comments are welcome and encouraged
Yes I am the one in the mirror. I am the one to blame for my problems. In this case, I want to do more writing. I was thinking about that while driving around today. I realized there is a good simple low risk way to practice. There are people I know writing columns, these columns are interesting to me and I read quite a few. Most have room for and encourage comments at the end.
This is a great opportunity not only read some great material and think critically about the material. This is also a time where I can absorb the material more deeply, providing a broader range of ideas to draw from for my future writings. If I want to retain the material, I should try to comment on the material. I want my comment to be well thought out, I want people to think "hey that is a great point." I also want to be able to support the writer of the original post. I want to read more material by this person so I should encourage the author by letting him know I like it.
I can also make critical points on the article. I try not to criticize the author. Snarky, snide and just plain rude are not rare enough elements. If I do not agree that is ok, if I can not make a point without resorting to these elements that says more about me than anyone else. I need to learn why I feel the way I do. I may learn my feelings on the issue are wrong. When this happens, it is a great opportunity to share what you have learned. This can either be a comment on the authors work or fodder for your own place on the web.
So help yourself and others with comments. Read more, think more and write more. Lets learn together.
Your comments are welcome and encouraged
Friday, May 27, 2011
Engage! - Boldy going.
Going where no one has gone before is hard.
Going where people have gone before is hard enough.
How do you get there?
Lets spy at the crew of the USS Enterprise for a few moments. In a typical episode we start out calmly enough, then something happens. The Romulans, Klingons, Borg or whatever show up and start wrecking havoc. It is almost always a dire situation. Life and death for all aboard the ship, an entire planet or even the entire human race. What happens next? The command crew assembles and comes up with a brilliant plan. Every thing is going to be ok, they have a plan. All of the details are worked out. Every one knows what they are to do. It is all going to be better now. It is time. Time for the Captain to give the order.
Engage!
The order must be given. All the planning is worthless unless you engage the project. Get moving and "make it so" (another of the captains tag lines)
So who is giving you the order? Who is giving me the order? Are you going to "Engage" or just sit back and watch the universe go by?
You are your own captain, you have to make things happen. Make you plan. Plot your course and Engage!
This is part two of my micro series inspired by GR Testers pop culture lightning talks night. Watch out for the final chapter coming soon.
Going where people have gone before is hard enough.
How do you get there?
Lets spy at the crew of the USS Enterprise for a few moments. In a typical episode we start out calmly enough, then something happens. The Romulans, Klingons, Borg or whatever show up and start wrecking havoc. It is almost always a dire situation. Life and death for all aboard the ship, an entire planet or even the entire human race. What happens next? The command crew assembles and comes up with a brilliant plan. Every thing is going to be ok, they have a plan. All of the details are worked out. Every one knows what they are to do. It is all going to be better now. It is time. Time for the Captain to give the order.
Engage!
The order must be given. All the planning is worthless unless you engage the project. Get moving and "make it so" (another of the captains tag lines)
So who is giving you the order? Who is giving me the order? Are you going to "Engage" or just sit back and watch the universe go by?
You are your own captain, you have to make things happen. Make you plan. Plot your course and Engage!
This is part two of my micro series inspired by GR Testers pop culture lightning talks night. Watch out for the final chapter coming soon.
Monday, May 16, 2011
GR Testers - Lightning Talk
GR Testers is a Software Testing group based in Grand Rapids, Michigan. On May 9, 2011 we hosted a round of lightning talks. The talks centered around pop culture references we had talks referencing books, television shows and movies. My talk referred to the Back To The Future series of movies. I have recreated the talk and recorded as was recommended by someone the night of the talks. This version runs about ten minutes, I do not know how long the original was. It is surprising how short five minutes really is the first attempts at recording this came in much longer.
Enjoy: http://www.hopasaurus.com/bttf_lightning_talk.mp3
Also look for two more blog posts inspired by the pop culture references: "Engage: what we can learn from Jean-Luc Picard" and something inspired by Ferris Beuller's Day Off. (Coming Soon)
Enjoy: http://www.hopasaurus.com/bttf_lightning_talk.mp3
Also look for two more blog posts inspired by the pop culture references: "Engage: what we can learn from Jean-Luc Picard" and something inspired by Ferris Beuller's Day Off. (Coming Soon)
Monday, January 24, 2011
Grand Rapids Perl Mongers - Coming up Friday 28th
When: Friday January 28th at 11:30am
Where: "The Factory"
What:
We will be participating in a group coding Kata, transforming "The Factory"
into a coding dojo. The Kata practiced will be doing PragDave's Kata number 4, it may be helpful to practice, but not required. Please bring a laptop if you have one available, we will be practicing in pairs so do not worry if you have no laptop.
A link to the details:
Please RSVP with your pizza and pop preferences and number attending to dave@hopasaurus.com
Watch for an update and parking information to come out on Wednesday.
For more information on "The Factory" see http://workthefactory.com/
Parking information:
75af35ad5dcb8a90f&ll=42.962547,-85.672116&spn=0.008982,0.011973&z=16
same but tiny: http://tinyurl.com/yeg5u7l
"Monroe Center 2 Ramp" looks good if you are just coming for the meeting, the lot between Ottawa, Ionia, Louis and Monroe center features first hour free and $1.00 per half hours after however there is no daily max. See the link above for more options and directions.
May be card only "Arena Area Lot 3" looks great for all day with a $3.00 daily max. Expect it to fill up quick it is located near Fulton and Weston.
May be card only The "Ottawa & Fulton Ramp" between Ottawa, Ionia, Fulton and Louis seems good if you will be there all day and the Arena Lot 3 is full ($9.00 max).
Hopefully this helps, but I usually end up circling around several times, get irritated and find the next thing I see.
Other area events of interest:
GRLug Monday January 24th at 6:00pm
Al Tobey will be talking about Linux at scale, start with infrastructure as code and devops but cover a lot more than just those areas.
See: grlug.org
Grand Rapids Software Testers February 16th at 6:30pm
GrWebDev Monday, January 31st at 5:30pm
See @grwebdev on Twitter for more information.
Subscribe to:
Posts (Atom)