Thursday October 28th, 2010
SELU .NET User GroupZen Testing
6:30-8:00pm
Fayard Hall Room 126
Southeastern University Campus
More Info
As software practitioners, we are in pursuit of two things: the acquisition of skill, and the acquisition of knowledge. It is the acquisition of the latter that I want to focus on in the next series of articles – specifically history.
Many developers are deficient in the knowledge or concern of how our profession was born and how it has evolved, or why that information matters. This is, in part, due to the fact that we live in the present, and plan for the future. But, historical perspective provides us with insight that cannot be derived from the present. Studying our history provides reason and basis for the ideas, principles, techniques, and practices that have shaped this industry and craft. It also provides the context in which these concepts were incubated, developed, extended, and, in some cases, abandoned.
In this installment, I would like to introduce you to Douglas Engelbart. He, among other things, invented one of the most ubiquitous computer peripherals, the mouse. He and his team also introduced the world to hypertext and computer networking. Among his other contributions are: collaborative hypermedia, knowledge management, community networking, and organizational transformation, display editing, windows, cross-file editing, outline processing, hypermedia, and groupware. Mr. Engelbart’s biography is truly impressive, inspirational, and worth taking a few minutes to read.
On December 9, 1968, at the Fall Joint Computer Conference (FJCC) in San Francisco, he demonstrated the first computer mouse, as well as interactive text, video conferencing, teleconferencing, email, hypertext and a collaborative real-time editor. This demonstration has been posthumously named "The Mother of all Demos". The original 100-minute video of this event is part of the Engelbart Collection in Special Collections of Stanford University and can be viewed here. Enjoy.
Have you ever had the “sounds like user error” knee-jerk response without taking the time to find the real cause of the problem? Have you ever heard a colleague do likewise? The concept of user error is so prevalent, we have created our own set of slang - “Problem exists between keyboard and chair”, “Problem in chair not in computer”, “ID-10T error”, etc. But is the user really to blame? I say the answer is no.
I once inherited a codebase where all lookup lists were implemented as Singletons. When the administrator went to add a new lookup value, it never showed up in the web form that displayed the list, so she re-booted her machine and then it “magically” appeared the next time she fired up the application. She blamed herself for the issue. She figured it was something she had done wrong, not that it was in fact an issue with the code.
Every problem a user encounters while using your application was created by you, the developer. You allowed it to happen. You put the user in a position to, or gave them the opportunity to fail. Whether it be from a lack of ability, QA, testing, or education, domain ignorance, laziness, or just a simple oversight, you are to blame. If you do get burnt, do not take it personally. Take responsibility and view it as an opportunity to learn and grow as a professional.
Houston TechFest
Zen Coding
12:00-1:15pm
University of Houston Campus