Since the first caveman first discovered the concept of this is more valuable than that, the science of alchemy has captured the imagination of many an enterprising soul. Unfortunately, to date, nobody has had any real success in transforming worthless metal into gold. That was, until the wonder that is PHP came along...
Generally, Brad M, doesn't care who wrote what bad code as long as it gets fixed. This little PHP snippet however, made him look up the responsible programmer on Linked In:
Thomas was outrunning a hurricane.
Storm clouds loomed from the south, the outer fringes of hurricane Gustav. He and the other employees at a volunteer center in New Orleans had been mandatorily evacuated a few hours earlier. The battery LED indicator on Thomas’s phone shone red, the battery drained to 1%. He was still a few hours from Hattiesburg, where a couch at his brother’s house was waiting for him.
Jon C. was planning to outsource a very simple order tracking system. He interviewed many prospects, each more hopeful than the last. He viewed samples of the websites they had built, and picked the one he liked the best. Jon then commissioned the job for his order tracking system to a local developer.
Upon delivery, Jon discovered that the email notification function didn't work, so he glanced at the code to see if he could identify the problem. Before Jon got that far, he discovered this on the login page:
Joe worked hard every day fighting the good fight against viruses and malware for a large financial firm in the UK. Their security setup suffered flaws, but it worked well enough. Scanners on incoming email, an antivirus product on the mail servers, signature updates every 30 minutes, and a basic antivirus on desktops all worked at Joe’s command to protect their network. There was no default route back out to the Internet and a Machiavellian filter restricted web access. Despite all this, Joe had to contend with one vulnerability not even the most advanced security system in the world could defend.
Spam changed faster than their filter-rules, and sometimes bad things slipped through. Joe’s team hoped to lessen the risk of this by educating their users to NEVER, EVER, EVER OPEN SOMETHING THAT LOOKS SUSPICIOUS. As predictable as an Enterprise Red Shirt dying on an Away Team mission, users would always go ahead and crack open malicious EXE files from their “long-lost cousin Frank” and completely fry their computer in minutes.
Matthew was the system administrator of a smallish warehousing company. His responsibility was to more or less keep the facility's computer systems working at a reasonable pace and ensure that nothing unexpected would bring the company's business to a screeching halt. Due to the typical resource constraints (money, time, qualified people), companies of this size frequently contract the development work for their internal software out to a third party. Moreover, as you might expect, the quality of those 'third parties' varies widely. Luckily, John, the third party responsible for his warehousing company's software was an industry veteran and was held in very high regard. You could say that there were those in the company thought he walked on water, but that would be unfair to the original. John's following was more devout.
One Monday morning, calls started pouring in complaining that the systems had slowed down markedly. As any good administrator would do, Matt checked to see if a number of potential culprits that had previously been identified and corralled in the past had popped up again. In this case, however, none of the usual suspects were at fault so, Matt reached out to John.
“The Killer Robot program won’t run correctly.” An middle-school student beckoned Artyom to her computer in the lab.
“Let me have a look.” Artyom pulled one of the child-sized chairs and sat next to his student. He had given his class some educational, open-source C programs to try out. Killer Robot looked like good, text-based fun, according to the SourceForge description.
Hey everybody - just in case you missed it, about a week and a half ago, we announced the long awaited return of our programming contest The Olympiad of Misguided Geeks at The Daily WTF - Part 2, sponsored by our good friends at NewRelic. The contest runs until June 28th so there's still plenty of time to join in on the fun!
The Oracle database doesn’t allow you to execute a SELECT statement without a FROM clause. You can't, for example, do
SELECT 2 + 2, you must do
SELECT 2 + 2 FROM dual. “dual” is a fictional table which exists solely to allow these sorts of operations.
What it isn’t meant for is Aspirist’s sample, from the Sidebar.
The Abstractor, as Greg and his team liked to call him, was a contractor at their company. The Abstractor had built a C# framework architecture (affectionately called Big Momma) that quickly went from being the company's framework, to being his personal baby. At the heart of Big Momma were abstract "Values" collections that wrapped the normal microsoft.net collections. This was so that any time The Abstractor decided that using arrays, XML or List<T> was bad, he could easily change "Values" to store data in some other data structure, and the code using it would be none-the-wiser. After all, enlightened developers use encapsulation, right?
While The Abstractor tended to stay away from any code that involved business logic due to his time being too valuable to be spent researching anything, he was eventually forced into creating a service that populated a database table for the new e-commerce website. The table would be used as a quick "real time" check for determining if a product was available at a location for in-store pickup. The records for each and every product needed to be updated every 30 minutes. Using Big Momma and armed with his "Values" collections, The Abstractor quickly had a solution in place. Unfortunately, it took 3 days to process 500,000 rows in the database - once. Greg was amazed that it could run that slowly. That was until Greg saw this error exception: