Article :: Exploring the Mythical Weekend Coding Project

Did you ever spend a weekend working through some kooky idea for coding an app you'd had in mind for years? Like many of us, Dhanji R. Prasanna has carried concepts around in his mental pockets, and one day he decided to go ahead and try it. The goal was a working app in two days. Would he succeed or fail miserably? Some things he learned were to be expected, but others he could never have predicted.

Categories: Agile Programming | Computers | InformIT | InformIT Agile Programming | Programming | Project Management | Technology

Error'd: amp, #039 and a0B30000004la04EAA&

"I saw this on my way home from work," Daniel Moore writes, "thank goodness CVS is doing something about Maryland's crippling shortage of whooping cough!"

 

"While trying to learn Open Bravo," writes Otmane Malih, "I learned that there are countries I've never heard of."

 

"My university has a site license of Mathematica for all Mathematics and Physics students," Simon Hollingshead wrote, "when trying to view some information about the license key, I got this message. Not to worry, it can go in my binder named 'Error messages from various websites'."

 

"Woah, bad password," wrote Micah, "that's cool man."

 

"Now that's a lot of readme," writes Frank de Weger.

 

"I was filling out a satisfaction survey after buying a new car," writes Jeremy Hutchinson, "even the optional questions required an answer."

 

"This is from a well-known vendor of libraries," writes Adrian Edmonds, "what to do next is a bit of a puzzle."

 

"This Mongolian ATM had a rather unique way to notify that it could not print a receipt," writes Matthew Asquith.

 

Categories: Computer Humor | Computers | Humor | Programming | Technology | The Daily WTF

Article :: Remote Control Software Solves "Friends and Family" Support Issues

In this lively autobiographical article, Ed Tittel describes his long-distance quest to help his father diagnose and fix computer issues.

Categories: Computers | InformIT | InformIT Programming | Programming | Technology

Article :: How TCP/IP Works

This chapter describes the TCP/IP protocol system and shows how the components of TCP/IP work together to send and receive data across the network.

Categories: Agile Programming | Computers | InformIT | InformIT Agile Programming | Programming | Project Management | Technology

Article :: Fluent C#: Application Development

In this chapter, we'll talk about development platforms, application architectures, development methodologies, design patterns, and best practices for C#, and where they all fit in the process of getting from here (an idea for some software) to there (a working application).

Categories: Computers | InformIT | InformIT Programming | Programming | Technology

Article :: Network Verification Commands Review

This article takes a look at some of the most basic network verification commands that can be used on Cisco equipment and discusses the information that can be obtained from these commands.

Categories: Agile Programming | Computers | InformIT | InformIT Agile Programming | Programming | Project Management | Technology

Save the Project for Failure

If it takes two contract developers six months to drive a project to failure, then four developers should be able to fail in half the time! Josh assumed that was why he and Sam were carted out to the client site and tossed into the oubliette of the PowerPac project. They were armed with nothing but a rusty spoon and a requirements document so old it needed to be stored in an oxygen-free environment.

The original development pair was Sally "I can code but I'm more of a designer" Jorgensen (the CEO's daughter) and Billy "I taught myself HTML in a week and am now a programmer" Jorgensen (the CEO's brother). They ran the project exactly like you'd expect such a dynamic duo to run it- directly into the ground. By the time Josh and Sam joined, it was already well past deadline and over budget.

To make a good impression on the client, Billy and Sally didn't work out of the consulting firm's office, but instead moved to the client site. The pair had improvised a server room to work out of. It could be easily distingushed from a broom closet by the piece of duct tape with "SEVER ROOM" sharpied onto it. Inside, an overheating rackmount server balanced on a crate of toilet paper. On a sagging plastic card table sat the developer workstation running VS2005, which doubled as their source control box, since it ran Visual Source Safe.

Josh thought their physical environment was bad, and then he looked at their application. Billy, it seemed, had read one website on database design and walked away with the idea, "if normalizing data across tables is good, normalizing it across databases bust be even better!" Their wheezing Sql Server instance hosted a dozen databases, one for each entity and an extra DB to hold tblIncrementingIDs(strCurrentID VARCHAR(50)), so that unique IDs could be consistent across all of these databases.

The first and last thing Josh noticed about the web code was the fact that each page had a multi-megabyte ViewState. Coupled with terrible coding practices, Josh and Sam junked the VSS repo and then started laying out a plan to rescue the application. They moved the dev team back to the consulting firm's main office, where they had a true development environment, complete with modern dev tools and a well administered TFS2010 instance, along with labs for automated testing. They rounded up people from the client and pinned them down on requierments. They beat Billy and Sally about the head and shoulders with three-tiered architecture until the two of them got it, and proceeded to wrench the project back onto course.

Four months later, Josh and Sam had accomplished the impossible- twice. They had gotten Billy and Sally to turn out code that wouldn't flunk a 100-level college course. The slighly less impossible achievement was that they had turned the project around. It went from "this is never going to be finished" to "it's late, overbudget, but we're within striking distance of an actual deliverable product." They were on track to deliver in two more months.

This kind of success on a project draws accolades and back-pats and lunches paid for by the consulting company for a job well done. It also draws something far more sinister: project managers who want to steal that glory for themselves. Doug, from the client-site, was exactly that kind of project manager. In the closing months of the project, he swooped in with the promise to manage the hell out of this project and keep it on track.

Doug did everyone the favor of standardizing the process. The QA Officer (Doug) had to approve any code before it could be checked into source control. The Compliance Officer (Doug) needed a report of every file modified before any build could be run, down to the specific line numbers changed. He couldn't just extract this information from TFS because, "It's part of the developer's job!"

Only the Build Officer (Doug) could kick off a new build, and not using TFS (a developer tool). Doug would run builds from his own computer, and if he forgot to perform a Get Latest to ensure he had all of the changes, well, that was the developer's problem. They should have followed the communication plan.

Josh protested and escalated and did all of the things you're supposed to do when someone's tanking your project, but to no avail. He couldn't understand how Doug was getting away with this until he sat in on Doug's status meeting. Doug had compiled a PowerPoint full of pretty graphs and dashboards showing nothing but green boxes. He used words like synergy, Agile, "code coverage", "core principles" and "industry standard best practices". It was entirely fabricated nonesense, but management swallowed every drop.

When they didn't hit Josh's original target dates, the money officially ran out. The project was cancelled, and the client informed the consulting company that Josh and his team should never be assigned to one of their projects again. Doug got transferred to another "at risk" project for the client, so that he could "save" it.

Categories: Computer Humor | Computers | Humor | Programming | Technology | The Daily WTF

Article :: Analysis for Continuous Delivery: Five Core Practices

Jez Humble, coauthor of Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, urges teams to move away from the all-or-nothing design of traditional software delivery approaches. Following the practices outlined here, you can deliver single-feature or small-story batches that dramatically decrease the time needed to build a new product or new release, testing and moving forward on successful features and redesigning or dropping features that fail (or that users show they don't really want).

Categories: Computers | InformIT | InformIT Programming | Programming | Technology

InformIT: The Trusted Technology Source for IT Pros and Developers

I'm at CodeMash today (stop by the Inedo booth if you're there!), so I thought it'd be a great time for this classic. Rutherford, Price, Atkinson, Strickland, and Associates Dentistry, Inc was originally published on January 30th, 2008.

---

July 19th, 2004 marked a new chapter in New Portlandopolis’s rich dentistry history. It was on that day that the bitter rivalry between Dr. Rutherford, DDS; Dr. Price, DMD, DDS; Dr. Atkinson, DMD; and Dr. Strickland, DDS/DDS-PhD, had finally come to an end. Though there’s much debate on what exactly started the feud, everyone knows what brought the dentists together: the nationwide “denta-corps” that can out-price, out-service, and out-anything their small, family dental practices.

Although the partnership talks had begun years before, July 19th was their agreed-upon D-Day, wherein the four separate practices would officially combine to be Rutherford, Price, Atkinson, Strickland, and Associates Dentistry, Inc. In the months leading up to D-Day, and after much bickering and debate, the four dentists got everything ready from new signage to new logoed toothbrushes. The only thing that remained was combining their computer systems. That task was left to Aaron B, an IT consultant who had the pleasure of working with each office through many of the “ugly years.”

Fortunately for Aaron, each of the dentists used the same practice management system: Beaglesoft’s Practice EnterprisePlus. It certainly wasn’t the best software, but it was among the most expensive. Perhaps more-importantly, Beaglesoft offered all sorts of outrageously-priced add-ons that the dentists could buy to one-up one another. For example, a wand-shaped oral camera required a $7,000-per-site “camera driver,” in addition to the ungodly amount the camera cost in the first place. When Aaron plugged the camera into his laptop (which didn’t have any Beaglesoft software running), it was recognized as a plug-and-play camera and immediately started streaming video. Not that it mattered though; as soon as Dr. Price had his installed, the other three dentists had to get one as well. 

“While our prices might seem high,” a Beaglesoft rep once told Aaron, “keep in mind that you’re paying for quality. Our products are rigorously tested to work in today’s and tomorrow’s high-tech dental office.”

And for that reason, Aaron wasn’t too worried about Beaglesoft’s portion of the D-Day migration. They assured him on several occasions that their latest and greatest – Beaglesoft Practice EnterprisePlus Elite with Networking – could network a “virtually unlimited” number of practices. The four Aaron was linking together was “chump change” compared to what the system could do.

When Friday, July 16th – the weekend before D-Day – had finally come, the dentists were ready. They closed their offices at noon and, per Beaglesoft’s instructions, initiated the migration process. Over the next twelve hours, so the plan went, each practice’s system would upload its data to the Central Server at Dr. Strickland’s office. Naturally, none of the other dentists were too thrilled about having a “Central Server”, especially one at Dr. Strickland’s.

Aaron arrived at Dr. Strickland’s office early Saturday morning to find a surprising message on the server: “Migration Completed Successfully.” He ran through some initial smoke tests and it appeared that the migration did, in fact, complete successfully. After a trip to the other three dentist offices, Aaron verified that he could access any patient’s file from any office. He called up the four dentists to share the good news: come Monday, they should be in business.

Monday came and, shortly thereafter, the four offices were out of business. The system had completely grinded to a halt. Every click of the mouse was met with a several-minute delay, and every delayed response was met with more clicking. Aaron, who happened to be on-site “just in case,” immediately suspected the newly-installed T1 lines.

Aaron called up the phone company. They ran a few diagnostics on their end, only to find that each office’s T1 line was completely pegged. Most certainly, the technician claimed, the problem was on their end. Perhaps a router gone haywire?

Aaron checked and rechecked the switches, the hardware, the ports, and the routers. He rebooted once, twice, and thrice. Everything seemed functional, aside from the fact that the Central Server was firing packets off non-stop.

Not sure what else to do, Aaron bridged his laptop between the Central Server and its switch. Within seconds, he logged hundreds of megabytes of data, far too much for anyone to go through in the middle of such a crisis. He had no choice but to take the “satellite” dentists offline to investigate the problem. They grew suspicious of this and, of course, Dr. Strickland, and demanded that there was foul-play involved.

With only a couple users accessing the Beaglesoft system, Aaron was able to get a handle on the traffic. As he assuaged the other dentists over the phone, Aaron noticed that a lot of the data seemed to be coming from SQL Server. Specifically, it was from queries like this:

 SELECT * FROM Patients

Digging further, Aaron figured out that, whenever a user wanted to look up a patient, the program would run “SELECT * FROM Patients” query, returning the entire Patients table to the client computer.

What’s worse, the query would run any time a character was typed in the patient search box. Searching for just his first name – A-A-R-O-N – resulted in five SELECT * queries.

What’s still worse, the same method of client-side filtering was used for appointments. It wouldn’t just get, say, today’s appointments. Or this week’s. Or, say, any that haven’t happened yet. It would query for every appointment that they ever had or would have in the future. That’s about 100,000 rows.

And since each appointment involved a patient, it’d have to fire off queries for each appointment to download and filter information about the patient.

It was apparent that Beaglesoft’s “rigorous testing” of “Practice EnterprisePlus Elite with Networking” involved, perhaps, a single computer and two, maybe three patient records. He immediately called Beaglesoft to report their issues and a demand a resolution.

(an actual screenshot from Beaglesoft’s install directory)

Within a few hours, three of Beaglesoft’s finest were on a plane to New Portlandopolis. When they arrived, two of them split off to work on “de-migrating” the system into the original four databases. The other Beaglesoftie, a product manager, worked on “damage control” – and boy did she have a lot of damage to control.

By that time – ten hours into Rutherford, Price, Atkinson, Strickland, and Associates Dentistry, Inc’s first day – the dentists were at each other’s throats. Dr. Price blamed the mess on Dr. Strickland who was “online the entire time, ” while Dr. Strickland was convinced that Dr. Atkinson had somehow “spiked the T1s,” while Dr. Rutherford believed that Dr. Price “wanted to retire, and was bringing everyone else down.” Eventually, Dr. Atkinson stormed out and tore down the new "Rutherford, Price, Atkinson, Strickland, and Associates Dentistry, Inc" sign. As he stomped the sign into pieces, he vowed never to work together again. Things pretty much went downhill from there.

After things cooled down a bit with the dentists, the product manager met with Aaron. Angered that his future prospects looked like a repeat of the “ugly years”, he lambasted Beaglesoft’s latest and greatest, and asked why, oh why, they couldn’t have done some client-side caching. Or, at the very least, use the magical WHERE clause.

She was astonished by Aaron’s technical knowledge and eagerly asked more questions on “WHERE clauses and other optimization techniques.” Near the end of their conversation, she actually offered Aaron a job as a Lead Developer at Beaglesoft.

Aaron ended up declining the position. He figured that they’d never be willing to tar and feather the existing development staff. That, and after the Beaglesoft Fiasco of 2004 (as it’s called today), he’d have a lot of cleaning up and intra-dentist diplomacy to do. Besides, how could he miss taking part in the latest exciting chapter in the dentistry history of New Portlandopolis?

Categories: Computer Humor | Computers | Humor | Programming | Technology | The Daily WTF

Article :: Objective-C Memory Management

This chapter provides a broad look at memory management in Objective-C.

Categories: Computers | InformIT | InformIT Programming | Programming | Technology