- Feature Articles
- Other Articles
When you want to store data in Amazon’s S3 cloud-based storage, you have to assign that data a key. In practice, this looks and behaves like a filename, but the underlying APIs treat it like a key/value store, where the value can be a large data object.
S3 is flexible and cost-effective enough that Melinda’s company decided to use it for logging HTTP requests to their application. These requests often contained large data files for upload, and those files might need to be referenced in the future, so a persistent and reliable storage was important.
Larry worked in the IT department of a medium-sized financial company. Bright and early on what should have been a promising day, the phone rang. Larry cursed the caller ID for informing him that Graham was on the line. The resident old man of the office and bane of IT, he frequently disregarded sound advice and policy to satisfy his own whims.
How about those NoSQL databases, huh? There’s nothing more trendy than a NoSQL database, and while they lack many of the features that make a traditional RDBMS desirable (like, um… guaranteeing writes?) , they compensate by being more scalable and easier to integrate into an application.
Chuck D’s company made a big deal out of migrating their data to a more “modern”, “JSON-based” solution. Chuck wasn’t involved in that project, but after the result went live, he got roped in to diagnose a problem: the migration of data from the old to the new database created duplicate records. Many duplicates. So he took a look at the migration script, and found piles of code that looked like this:
Leslie, head of IT at BlueBox, knew there was trouble when one of her underlings called her at 3AM. “The shared server’s down,” she said. “Disk failure. Accounting can’t issue invoices, design can’t get to its prototypes, and the CEO just lost his PowerPoint for next week’s conference speech.”
BlueBox, like many companies, kept many important documents on a shared server. It also held personal directories for every employee, and many (like the CEO) used it to store personal files. That data, totaling 100 GB, was backed up to a remote server every 24 hours. “Okay, swap out the disk and restore it.”
Consulting. It's as much art as science. You apply for a job to create/change some system, and need to bid an amount that not only covers your time, but leaves a little something extra in your pocket. Of course, we all know that requirements are never absolute, or even well thought out. As such, you need to build some extra cost into your bid to take this into account. Build in too much and you will be overpriced and not get the job. Build in too little and you will be under-priced and get the job at what will inevitably become a loss.
Writing a contract that restricts the work to a specific list of features is nearly impossible because nobody ever thinks through what they want in advance (think about your last outsourced project). Given that, you need to be skilled at letting the client know that you will be nice and implement tiny things that are not in the spec for free, but anything that is outside the contract spec and takes any real time will be at an added cost (the art of saying no: why yes, we can add that feature, but it will take x weeks at a cost of y).
One day, James’s boss asked him to take a look at a ticket regarding the “Cash Card Lookup” package, which had an issue. James had no idea what that was, so he asked.
“I don’t know,” his boss replied. “I just know the call center uses it. You’ll need to talk to them.”