I recently came upon the web series The Guild, it's absolutely hilarious. It follows a group of MMORPG players and their lives after meeting each other in real life. The writing is absolutely hilarious and delves well past the typical geek humor of most video game-centric humor. I especially love the character of Vork. He's overly frugal, constantly analyzing the cost of everything possible, and loves to operate by a strict set of rules. He's also always cooking food right next to his computer (toast, eggs, tator tots, etc.). Here are some of this best quotes: (Oh and some of these videos have bad language. So POSSIBLE NOT SAFE FOR WORK.)
Season 1 Episode 5
At 2:50 you see Vork's excellent mathematics. "Cheese Gouging!"
Season 3 Episode 2
I love Vork's commentary on the formation of a "line" at 1:25.
Season 3 Episode 10
At 3:10, just nonsense.
Season 2 Episode 6
As an added bonus, from 3:45 to 4:10 is my favorite quote in the entire series. I just can't get over it.
"I don't participate in shoddy craftmanship! Use the stencil! Do it!"
Thursday, March 17, 2011
Sunday, March 13, 2011
Ann Coulter vs. Al Franken
I was at dinner with friends last night and somehow Ann Coulter came up. It reminded me about perhaps my favorite YouTube video of all time.
There are so many subtleties to the video that I love. I love how Ann Coulter trys to twist the original question into a political message. Al Franken jumps on the twist with a way better answer. You can tell Al Franken uses his comedic background well. He adds the appropriate pauses and facial expressions to make the answer come out so much more hilarious. I also love the look on Ann Coulter's face at 0:54 in the video. You can tell she is just p*ssed.
There are so many subtleties to the video that I love. I love how Ann Coulter trys to twist the original question into a political message. Al Franken jumps on the twist with a way better answer. You can tell Al Franken uses his comedic background well. He adds the appropriate pauses and facial expressions to make the answer come out so much more hilarious. I also love the look on Ann Coulter's face at 0:54 in the video. You can tell she is just p*ssed.
Friday, March 11, 2011
Roundpegg
I just learned about a company called Roundpegg, that is (as called by Techcrunch) the "eHarmony for jobs". They give you a personality test and use that to fit you to different companies/jobs with different types of corporate culture. Similar to my discussion about Codility, these kinds of websites bother me.
It's not that Roundpegg isn't a good company. I think their personality test is probably very good and would be very useful for companies and candidates. Many companies use similar tests when employees apply for a job (Zappos comes to mind). The issue is that there is a strong likelihood such a systemcould be abused will be used poorly. The best way to use such a system is to use it to weed out the absolute worst candidates, not to find the best candidates. (Similar to the argument in my Codility argument.)
Update (3/15/11):
I suddenly had a thought. Similar to my comments in my Codility comments, how does Roundpegg recommend candidates to companies? Do they give a score like 0-100%? Or like many dating websites, do they give broad "strong match" vs. "maybe match" vs. "no match" grades? I suppose a more subjective grading criteria like the later might make a Roundpegg less susceptible to poor use.
It's not that Roundpegg isn't a good company. I think their personality test is probably very good and would be very useful for companies and candidates. Many companies use similar tests when employees apply for a job (Zappos comes to mind). The issue is that there is a strong likelihood such a system
Update (3/15/11):
I suddenly had a thought. Similar to my comments in my Codility comments, how does Roundpegg recommend candidates to companies? Do they give a score like 0-100%? Or like many dating websites, do they give broad "strong match" vs. "maybe match" vs. "no match" grades? I suppose a more subjective grading criteria like the later might make a Roundpegg less susceptible to poor use.
Tuesday, March 8, 2011
Monday, March 7, 2011
Bret the Hitman Hart the programmer
I saw this video clip around 10 years ago on a now defunct website, and I remember it for one line in the video.
For those who don't know about him, Bret the Hitman Hart is a legendary WWF/WWE professional wrestler (Wikipedia entry). He's known as the "Excellence of Execution." He is so talented, that he's also awesome programmer. Check out his skills at the 1:54 mark in the video below.
I love thinking about the staff putting together this video. At some point in time, they probably approached the programmers and asked them "Give us a line for Bret Hart to say." I'm sure they came up with all sorts of phrases:
Alas, the producers selected the best line he could say, "You're dereferencing a NULL pointer."
For those who don't know about him, Bret the Hitman Hart is a legendary WWF/WWE professional wrestler (Wikipedia entry). He's known as the "Excellence of Execution." He is so talented, that he's also awesome programmer. Check out his skills at the 1:54 mark in the video below.
I love thinking about the staff putting together this video. At some point in time, they probably approached the programmers and asked them "Give us a line for Bret Hart to say." I'm sure they came up with all sorts of phrases:
- "You have an off by 1 bug"
- "You have a buffer overflow"
- "You're using a single equal sign instead of a double equal sign."
Alas, the producers selected the best line he could say, "You're dereferencing a NULL pointer."
Friday, March 4, 2011
How did I end up a software engineer?
One day, I began to think about how I became a computer scientist/software engineer for a career. How did I get here? Here's what I recall.
Gradeschool
My dad purchased several computers when I was younger. I can't remember all of them, but there was atleast one Apple II and one Commodore. At this relatively young age, these were mostly just for my sister and I to play games on. I have faint recollections of playing Stickybear, a Conan game, and some game related to cleaning teeth.
Perhaps the most important thing I learned with these early computers was how to touch type (a skill I learned through a program purporting itself to be a game). It's a skill that I now realize was useful for becoming a great programmer, because you weren't wasting time figuring out how to type.
I also was taught very beginning BASIC programming on the Apple II. (Again, I think through an educational program purporting itself to be a game.) I didn't understand much of it, but I technically did write my first code on it.
At some point late in gradeschool my parents also got our first machine w/ Windows 3.1. This was key because ...
Junior High
Thanks to my friend Brian Soucy in junior high (where are you Brian, I've lost track of you) I began BBSing and participating in the local St. Louis BBS community (and later setting up my own BBS). This was the first time I began fiddling with computers in earnest and participating in an online community. I opened up a computer for the first time and installed a modem. Later I installed a soundcard because I wanted to play some games with better sound (non-NPD software, I swear!). Through BBSing I was learning more things about computers and figuring out many tiny things about them. Things like meddling with autoexec.bat, stacker, and defrag.
Highschool
I was quite fortunate. A lot of schools didn't offer programming classes in my area, but thanks to Mr. Hottelman, my highschool did. I was able to take BASIC I, BASIC II, Visual BASIC, and C in highschool. I didn't learn any advanced algorithms or anything. My recollection was only learning bubblesort. I remember learning about pointers in the C class and thinking it was really dumb (for any recruiter reading this, I no longer think they are dumb :P).
The highlight of my work in these classes was a program I wrote in BASIC that displayed the periodic table of elements. You could move your arrow keys around to select an element and bring up details on the element. It was technically useless (any book could have given you the same information) but it looked neat and awesome. I believe the code is still sitting in a 3.5 diskette in my parent's basement.
Looking back, the coolest thing I ever did in this periodic table project was my intellectual "creation" of functions. I was never taught how to do functions in BASIC, I was only taught about gosubs (I was still young enough in my programming life that the concept of a function was not fully there). With so much repetitive code in my periodic table program, I wanted to condense code so I wasn't cutting and pasting all over the place. I eventually created a system where I would set global variables (I wasn't knowledgeable of local vs. global variables yet either, everything was global) to certain values. The globals were generically named things like val1, val2, val3, etc. I would set them and then call common gosub-routines that would know what globals to read and how to operate on them. I'm quite proud of the fact that I was able to figure out this way to condense code. (Note: My recollection is that gosubs in BASIC don't take parameter arguments. If they do, then the above technique was obviously very dumb. But I'm still quite proud of my ability to condense code this way.)
At some point, I also made a webpage for myself. Not something crappy like on Geocities, but a real hosted one. I made some fan pages for my favorite St. Louis sports icons like Ozzie Smith and Brett Hull. My Ozzie Smith homepage actually got some references in newspapers and sports magazines. All these pages are gone now, but I was able to find my homepage on the internet archive (Most of this was written when I was 15/16 years old, don't laugh!). While I didn't understand how the internet worked and how the pages I uploaded to some server would magically appear at a web address, this was my first introduction to FTP, Unix, and the chmod command (at the time, I had no idea why I had to type 'chmod 644' on these files).
Picking A Major
Well, with interest in the internet, making a homepage, liking programming classes in highschool, and hearing computer people made good money, it was easy for me to pick "computer something" for my career. The "computer something" was a tough choice though. I remember reading the descriptions for "Computer Engineering" or "Computer Science" and not knowing the difference. I think I ended up picking "Computer Science" because I didn't consider myself a hardware guy (other geek friends of mine liked to build computers, but I wasn't as into it). I got accepted to several schools and ended up chosing UIUC.
Final Thoughts
In hindsight, there were a lot of lucky circumstances along the way. What if I had never met Brian and installed a modem in Junior High? What if my dad never got an Apple II? What if my highschool never taught a programming class? Would I even have this career? What would I be doing if I didn't major in Computer Science?
Gradeschool
My dad purchased several computers when I was younger. I can't remember all of them, but there was atleast one Apple II and one Commodore. At this relatively young age, these were mostly just for my sister and I to play games on. I have faint recollections of playing Stickybear, a Conan game, and some game related to cleaning teeth.
Perhaps the most important thing I learned with these early computers was how to touch type (a skill I learned through a program purporting itself to be a game). It's a skill that I now realize was useful for becoming a great programmer, because you weren't wasting time figuring out how to type.
I also was taught very beginning BASIC programming on the Apple II. (Again, I think through an educational program purporting itself to be a game.) I didn't understand much of it, but I technically did write my first code on it.
At some point late in gradeschool my parents also got our first machine w/ Windows 3.1. This was key because ...
Junior High
Thanks to my friend Brian Soucy in junior high (where are you Brian, I've lost track of you) I began BBSing and participating in the local St. Louis BBS community (and later setting up my own BBS). This was the first time I began fiddling with computers in earnest and participating in an online community. I opened up a computer for the first time and installed a modem. Later I installed a soundcard because I wanted to play some games with better sound (non-NPD software, I swear!). Through BBSing I was learning more things about computers and figuring out many tiny things about them. Things like meddling with autoexec.bat, stacker, and defrag.
Highschool
I was quite fortunate. A lot of schools didn't offer programming classes in my area, but thanks to Mr. Hottelman, my highschool did. I was able to take BASIC I, BASIC II, Visual BASIC, and C in highschool. I didn't learn any advanced algorithms or anything. My recollection was only learning bubblesort. I remember learning about pointers in the C class and thinking it was really dumb (for any recruiter reading this, I no longer think they are dumb :P).
The highlight of my work in these classes was a program I wrote in BASIC that displayed the periodic table of elements. You could move your arrow keys around to select an element and bring up details on the element. It was technically useless (any book could have given you the same information) but it looked neat and awesome. I believe the code is still sitting in a 3.5 diskette in my parent's basement.
Looking back, the coolest thing I ever did in this periodic table project was my intellectual "creation" of functions. I was never taught how to do functions in BASIC, I was only taught about gosubs (I was still young enough in my programming life that the concept of a function was not fully there). With so much repetitive code in my periodic table program, I wanted to condense code so I wasn't cutting and pasting all over the place. I eventually created a system where I would set global variables (I wasn't knowledgeable of local vs. global variables yet either, everything was global) to certain values. The globals were generically named things like val1, val2, val3, etc. I would set them and then call common gosub-routines that would know what globals to read and how to operate on them. I'm quite proud of the fact that I was able to figure out this way to condense code. (Note: My recollection is that gosubs in BASIC don't take parameter arguments. If they do, then the above technique was obviously very dumb. But I'm still quite proud of my ability to condense code this way.)
At some point, I also made a webpage for myself. Not something crappy like on Geocities, but a real hosted one. I made some fan pages for my favorite St. Louis sports icons like Ozzie Smith and Brett Hull. My Ozzie Smith homepage actually got some references in newspapers and sports magazines. All these pages are gone now, but I was able to find my homepage on the internet archive (Most of this was written when I was 15/16 years old, don't laugh!). While I didn't understand how the internet worked and how the pages I uploaded to some server would magically appear at a web address, this was my first introduction to FTP, Unix, and the chmod command (at the time, I had no idea why I had to type 'chmod 644' on these files).
Picking A Major
Well, with interest in the internet, making a homepage, liking programming classes in highschool, and hearing computer people made good money, it was easy for me to pick "computer something" for my career. The "computer something" was a tough choice though. I remember reading the descriptions for "Computer Engineering" or "Computer Science" and not knowing the difference. I think I ended up picking "Computer Science" because I didn't consider myself a hardware guy (other geek friends of mine liked to build computers, but I wasn't as into it). I got accepted to several schools and ended up chosing UIUC.
Final Thoughts
In hindsight, there were a lot of lucky circumstances along the way. What if I had never met Brian and installed a modem in Junior High? What if my dad never got an Apple II? What if my highschool never taught a programming class? Would I even have this career? What would I be doing if I didn't major in Computer Science?
Sunday, February 20, 2011
Expectations When You Support Open Standards
I've spoken about this topic with many engineers, managers, sales folks, etc. So I decided it might be interesting to post about this topic and my experience with it.
Organizations/vendors often advertise support for software or protocols based on open standards. However, I've had many experiences where it does not appear vendors understand the consequences of that advertisement. The following is an example of something I've encountered in my work.
I'm the co-author and present maintainer of FreeIPMI. If you're not familiar with what IPMI is, you can read about it in the FreeIPMI FAQ. For this discussion, the most important part to understand about IPMI is that it is an open standard which you can download here.
The IPMI standard supports many things, one of which is the ability to read sensors off a motherboard. For example, it supports the ability to read CPU temperatures and report them back to the user in Celsius (e.g. 50 degrees Celsius). The types of sensors that could exist on a motherboard are very large and cannot always be handled by IPMI. So the IPMI specification supports the ability for vendors to add OEM extensions to read non-standard sensors. For example, I've encountered a motherboard where a CPU temperature sensor was not reported in Celsius, but instead reported by flags indicating "low", "medium", "high", or "overheat." This type of sensor is not defined by the IPMI specification and is specific to just one manufacturer's motherboard.
Normally, I (as potential motherboard customer) do not know how to read and interpret an OEM specific sensor. The question is, is it fair or unfair for a vendor to keep information about an OEM specific sensor closed/hidden/secret? Is it fair or unfair to only allow an OEM specific sensor to be readable by a vendor's software instead of third-party software?
In my opinion, it depends on the sensor. In the case of a OEM CPU temperature sensor above, I believe hiding this information to be unfair. A CPU temperature sensor is a standard IPMI supported mechanism. An OEM specific CPU temperature sensor is what I call a "minor permutation" from the specification. A user/customer of IPMI would expect they could read CPU temperature sensors using third-party IPMI software.
In contrast, suppose that a sensor on the motherboard supports the ability to read a sensor quite different than what is supported in the IPMI specification (i.e. it is not a "minor permutation"). In this case, I do not believe a user/customer would have reasonable expectation for third-party IPMI software to read the sensor. So in this case, I would consider it fair to keep the information closed/hidden and only readable by vendor software.
Now, you might ask, what are reasonable expectations of a customer/user? In my opinion, it comes down to how the product is advertised. Does the product brief say that you can read motherboard sensors via IPMI? Or does it say you can read them via software X? If a vendor says the former, they should be prepared to deal with questions from customers about third party software. If they say the later, I believe customers cannot have expectations of support for third-party software.
Why is this a conversation that always comes up for me? You may have guessed it by now, but many vendors do not wish to open up and share their OEM extensions with me for inclusion in FreeIPMI. As an example, the following are several IPMI standard mechanisms.
Despite the fact that they are standard mechanisms, due to minor implementation differences, they have also been implemented as OEM extensions by some vendors (see ipmi-oem). The first two (configuring MAC and IP address) are particularly egregious OEM extensions, because the OEM extension (and possibly vendor specific software) are now required for basic setup and configuration of IPMI (let alone using all the features of IPMI). [1]
Hopefully, this illustrates the expectations a user/customer/software developer would have when a vendor supports an open standard. As an addendum, I do not wish to imply that companies with IPMI OEM extensions are being evil by keeping some of their OEM extensions hidden/closed/secret. Many companies I have worked with on IPMI have been very gracious in (eventually) opening up their OEM extensions for addition into FreeIPMI (see FAQ). I believe that initial resistance from vendors is often due to poor communication rather than evil intent. For many vendors, I am a strange corner case in their customer base. Support staff folks just aren't prepared to handle the kinds of support requests I make, so their initial reaction is naturally "No, we can't do that."
[1] - As an interesting aside, I once reported to a vendor that their standard IPMI MAC address configuration functionality was broken in their firmware. The vendor responded that it was working with their software, and the bug must of have been in FreeIPMI. After much back and forth, I was able to determine that their vendor specific software was configuring the MAC address using an OEM extension, not the standard mechanism. So in this particular case, the vendor support staff was completely unaware that their software used an OEM extension. Ugh ...
Organizations/vendors often advertise support for software or protocols based on open standards. However, I've had many experiences where it does not appear vendors understand the consequences of that advertisement. The following is an example of something I've encountered in my work.
I'm the co-author and present maintainer of FreeIPMI. If you're not familiar with what IPMI is, you can read about it in the FreeIPMI FAQ. For this discussion, the most important part to understand about IPMI is that it is an open standard which you can download here.
The IPMI standard supports many things, one of which is the ability to read sensors off a motherboard. For example, it supports the ability to read CPU temperatures and report them back to the user in Celsius (e.g. 50 degrees Celsius). The types of sensors that could exist on a motherboard are very large and cannot always be handled by IPMI. So the IPMI specification supports the ability for vendors to add OEM extensions to read non-standard sensors. For example, I've encountered a motherboard where a CPU temperature sensor was not reported in Celsius, but instead reported by flags indicating "low", "medium", "high", or "overheat." This type of sensor is not defined by the IPMI specification and is specific to just one manufacturer's motherboard.
Normally, I (as potential motherboard customer) do not know how to read and interpret an OEM specific sensor. The question is, is it fair or unfair for a vendor to keep information about an OEM specific sensor closed/hidden/secret? Is it fair or unfair to only allow an OEM specific sensor to be readable by a vendor's software instead of third-party software?
In my opinion, it depends on the sensor. In the case of a OEM CPU temperature sensor above, I believe hiding this information to be unfair. A CPU temperature sensor is a standard IPMI supported mechanism. An OEM specific CPU temperature sensor is what I call a "minor permutation" from the specification. A user/customer of IPMI would expect they could read CPU temperature sensors using third-party IPMI software.
In contrast, suppose that a sensor on the motherboard supports the ability to read a sensor quite different than what is supported in the IPMI specification (i.e. it is not a "minor permutation"). In this case, I do not believe a user/customer would have reasonable expectation for third-party IPMI software to read the sensor. So in this case, I would consider it fair to keep the information closed/hidden and only readable by vendor software.
Now, you might ask, what are reasonable expectations of a customer/user? In my opinion, it comes down to how the product is advertised. Does the product brief say that you can read motherboard sensors via IPMI? Or does it say you can read them via software X? If a vendor says the former, they should be prepared to deal with questions from customers about third party software. If they say the later, I believe customers cannot have expectations of support for third-party software.
Why is this a conversation that always comes up for me? You may have guessed it by now, but many vendors do not wish to open up and share their OEM extensions with me for inclusion in FreeIPMI. As an example, the following are several IPMI standard mechanisms.
- Configure MAC Address
- Configure IP Address
- Get firmware version
- Get product name/serial number
- Set LED
Despite the fact that they are standard mechanisms, due to minor implementation differences, they have also been implemented as OEM extensions by some vendors (see ipmi-oem). The first two (configuring MAC and IP address) are particularly egregious OEM extensions, because the OEM extension (and possibly vendor specific software) are now required for basic setup and configuration of IPMI (let alone using all the features of IPMI). [1]
Hopefully, this illustrates the expectations a user/customer/software developer would have when a vendor supports an open standard. As an addendum, I do not wish to imply that companies with IPMI OEM extensions are being evil by keeping some of their OEM extensions hidden/closed/secret. Many companies I have worked with on IPMI have been very gracious in (eventually) opening up their OEM extensions for addition into FreeIPMI (see FAQ). I believe that initial resistance from vendors is often due to poor communication rather than evil intent. For many vendors, I am a strange corner case in their customer base. Support staff folks just aren't prepared to handle the kinds of support requests I make, so their initial reaction is naturally "No, we can't do that."
[1] - As an interesting aside, I once reported to a vendor that their standard IPMI MAC address configuration functionality was broken in their firmware. The vendor responded that it was working with their software, and the bug must of have been in FreeIPMI. After much back and forth, I was able to determine that their vendor specific software was configuring the MAC address using an OEM extension, not the standard mechanism. So in this particular case, the vendor support staff was completely unaware that their software used an OEM extension. Ugh ...
Subscribe to:
Posts (Atom)