Posts Tagged 'Programmers'

May 10, 2013

Understanding and Implementing Coding Standards

Coding standards provide a consistent framework for development within a project and across projects in an organization. A dozen programmers can complete a simple project in a dozen different ways by using unique coding methodologies and styles, so I like to think of coding standards as the "rules of the road" for developers.

When you're driving in a car, traffic is controlled by "standards" such as lanes, stoplights, yield signs and laws that set expectations around how you should drive. When you take a road trip to a different state, the stoplights might be hung horizontally instead of vertically or you'll see subtle variations in signage, but because you're familiar with the rules of the road, you're comfortable with the mechanics of driving in this new place. Coding standards help control development traffic and provide the consistency programmers need to work comfortably with a team across projects. The problem with allowing developers to apply their own unique coding styles to a project is the same as allowing drivers to drive as they wish ... Confusion about lane usage, safe passage through intersections and speed would result in collisions and bottlenecks.

Coding standards often seem restrictive or laborious when a development team starts considering their adoption, but they don't have to be ... They can be implemented methodically to improve the team's efficiency and consistency over time, and they can be as simple as establishing that all instantiations of an object must be referenced with a variable name that begins with a capital letter:

$User = new User();

While that example may seem overly simplistic, it actually makes life a lot easier for all of the developers on a given project. Regardless of who created that variable, every other developer can see the difference between a variable that holds data and one that are instantiates an object. Think about the shapes of signs you encounter while driving ... You know what a stop sign looks like without reading the word "STOP" on it, so when you see a red octagon (in the United States, at least), you know what to do when you approach it in your car. Seeing a capitalized variable name would tell us about its function.

The example I gave of capitalizing instantiated objects is just an example. When it comes to coding standards, the most effective rules your team can incorporate are the ones that make the most sense to you. While there are a few best practices in terms of formatting and commenting in code, the most important characteristics of coding standards for a given team is consistency and clarity.

So how do you go about creating a coding standard? Most developers dislike doing unnecessary work, so the easiest way to create a coding standard is to use an already-existing one. Take a look at any libraries or frameworks you are using in your current project. Do they use any coding standards? Are those coding standards something you can live with or use as a starting point? You are free to make any changes to it you wish in order to best facilitate your team's needs, and you can even set how strict specific coding standards must be adhered to. Take for example left-hand comparisons:

if ( $a == 12 ) {} // right-hand comparison
if ( 12 == $a ) {} // left-hand comparison

Both of these statements are valid but one may be preferred over the other. Consider the following statements:

if ( $a = 12 ) {} // supposed to be a right-hand comparison but is now an assignment
if ( 12 = $a ) {} // supposed to be a left-hand comparison but is now an assignment

The first statement will now evaluate to true due to $a being assigned the value of 12 which will then cause the code within the if-statement to execute (which is not the desired result). The second statement will cause an error, therefore making it obvious a mistake in the code has occurred. Because our team couldn't come to a consensus, we decided to allow both of these standards ... Either of these two formats are acceptable and they'll both pass code review, but they are the only two acceptable variants. Code that deviates from those two formats would fail code review and would not be allowed in the code base.

Coding standards play an important role in efficient development of a project when you have several programmers working on the same code. By adopting coding standards and following them, you'll avoid a free-for-all in your code base, and you'll be able to look at every line of code and know more about what that line is telling you than what the literal code is telling you ... just like seeing a red octagon posted on the side of the road at an intersection.

-@SoftLayerDevs

May 25, 2012

Tear Down the (Immigration) Wall ... Or at Least Install a Door

A few years ago, I went through a nightmare trying to get to permanent resident status in the United States. My file sat in a box for over a year, was lost, re-submitted and FINALLY rushed through by Ted Kennedy's office. And I was on a "fast track" due to a long record of published research and employment history. I had the means to pay lawyers and the time to repeat the filing and wait for a decision. If I didn't have the means or the time to wait for the process to complete, I don't know where I'd be, but in all likelihood, it wouldn't be here. It's no surprise that immigration reform is high on my list of priorities, and given SoftLayer's involvement in the USCIS Entrepreneurs in Residence program along with Lance's appointment to a Bloomberg committee focused on immigration reform, it's clear I'm not alone.

The bi-partisan Partnership for a New American Economy recently published a very interesting report — Not Coming to America: Why the US is Falling Behind in the Global Race for Talent — that speaks to a lot of the challenges plaguing the current US immigration policy. Because of those challenges, "the future of America's position as the global magnet for the world's most talented and hardest-working is in jeopardy." Here are a few of the projected economic realities of not reforming immigration laws to keep up with other countries:

SHORTAGE OF WORKERS IN INNOVATION INDUSTRIES: Jobs in science, technology, engineering, and math ("STEM" fields) are increasing three times faster than jobs in the rest of the economy, but American students are not entering these innovative fields in sufficient numbers. As a result, by 2018, we face a projected shortfall of 230,000 qualified advanced-degree STEM workers.

SHORTAGE OF YOUNG WORKERS: The US population is aging, baby boomers are retiring en masse, and the growth in the US labor force has slowed to historic lows of less than 1 percent. We cannot continue to produce the GDP growth the nation has come to expect without dramatic increases in productivity or welcoming more working age immigrants.

A STALLED ECONOMY: The US has faced years of stunted economic growth. History shows that new businesses are the biggest drivers of job creation, yet the most recent US Census data show that the number of business startups has hit a record low.

This concern isn't unique to the United States. With a global focus on innovation and technology, countries around the world are actively competing for the best and the brightest. In Canada, a report a few weeks ago spoke to Canada's need to double in size in the next few decades or risk losing relevance and becoming just another resource-rich colony. The nation's response? It's ready to open its doors to more immigrants.

The same applies to the United States ... It just may take longer.

Go back to how this country was built, and apply that to today. The biggest difference: The "skilled trades" we talk about in the most general sense are no longer carpenters like my grandfather but highly educated programmers, engineers and researchers. The idea isn't to replace the programmers, engineers and researchers in the US, rather it's to meet the existing unmet needs for programmers, engineers and researchers.

In all of SoftLayer's efforts to affect change in the US immigration policy, we have to make clear that our goal is not to drop the walls simply to add more permanent residents. It's about lowering many of the current artificial barriers that might prevent the next Fortune 500 founder from starting his or her business in the United States. If you don't think that's a serious concern, I'd point to a pretty surprising stat in the "Not Coming to America" report: "Today, more than 40 percent of America's Fortune 500 companies were founded by an immigrant or a child of an immigrant."

Immigration drives the economy. It's not a drain on the economy. Every country needs more smart people because smart people create new ideas, new ideas become new businesses, and new businesses create new jobs.

Because this is a politically charged issue, it's one I know many people don't necessarily agree with. Along with immigration, we have to look at how the education system can empower young people like my son to become the programmers, engineers and researchers that the US will need, and we have to be intentional about not simply adding permanent residents for the sake of adding permanent residents. If you have any thoughts one way or the other, I'd encourage you to share them with us here in a blog comment or link us to any of the resources you've found interesting in researching and discussing the topic.

-@gkdog

July 25, 2008

Thinkin' Like a Programmer

"I can't figure this out. My email client says I can't attach more than 10 M of data, but then it says I have 16501 K of data attached, and it can't send that. What's a 'M'? What's a 'K'? Why is the second number so big? I only attached a few files!"

I explained to my uncle that "M" stood for Megabyte, and "K" stood for Kilobyte. That a simple calculation to convert "K"s to "M"s was to take the last three digits off the "K"s and you had the size in "M"s, give or take one. That he had 16-17 Megabytes of data attached to his email, and he can only have 10.

His response was to wonder (1) why didn't the client just tell him he had "too much data," and (2) why did the program give him Ms AND Ks, instead of picking one?

My reply consisted of (1) it did, that's what the message said, and (2) because the programmer was thinking like a programmer.

See, my uncle is a very, very smart man. He worked in a video arcade as the guy who rewired the arcade machines when they exploded when somebody poured a Coke on them. He knew how the machines worked in and out. And got paid good money. When he moved back to Texas, he took up industrial and residential electric work, and is now a fully licensed foreman who's in high demand all through the area. When he says "I won't take a job that pays less than $20 a hour," it's not because he's picky, it's because he doesn't have to. Sharp as a tack. But he's not a computer pro. Not a problem, people can't be pros at everything. This ain't the 1700s, where you can pick up a test tube and learn everything known about chemistry in a few days.

But why would a programmer write a error message for an email program that would be unreadable to end users? Because it's perfectly readable to him! When my uncle read out the message, my first response was "You have about 7 Megabytes too many attachments. Send a second email."

Therefore, a programmer checking his work would think this was a great error message. Not only does it tell you that the email can't be sent, but it tells you why. The limit is in Megabytes, but email messages are typically sent in Kilobytes, so the data is already there. See how helpful I am! And the unit conversion between Ks and Ms are very easy; programmers do it 10 times a day and wouldn't even notice it.

That's why we have end user testing, to try to catch these things that programmers won't notice. It's just a simple conversion of units! But for an electrician trying to send an email, it was as opaque as to him as if he had told me that I had a single pole dual throw make-break when I need a dual pole single throw break-make. It makes perfect sense, if you're used to it. And if I think about it for a minute, I could figure it out most likely… but the point is, his error message is useless to me as it's formatted. But it makes perfect sense to him.

So, what's the moral of the story? Well, moral 1 is, try to be sure that all users of your product can understand what you say. We have an extensive testing process here at SoftLayer to make sure our data screens are usable without any confusion. Moral 2 is that programmers don't "actively" attempt to "keep people from using their computers" by "making their programs too complex." For us, it's completely transparent and useful, as useful to us as a circuit diagram is to an electrician. Just let us know if we make something a bit to opaque; it wasn't on purpose, and sometimes it's an easy fix. We were just thinking like programmers.

-Zoey

Categories: 
May 14, 2008

On Site Development

I have a friend who worked at an internationally recognized fast food restaurant. It relies heavily on it’s computer systems to operate. Being a programmer (I’ve always preferred Computer Alchemist), I’ve always been fascinated with the command and control programs used at these restaurants, and have drilled many family members and friends to describe (in the most non-specific non-job-endangering way) what they do with those computers to do their job.

At the fast food restaurant, every order is entered into the cash register at the front of the line, processed by the computer systems on site, the orders are relayed to the kitchen in realtime and displayed on monitors, and various thermal ticket printers spit out meal tickets to be affixed to the various food items to describe their state (Double Cheeseburger, No Pickles, No Onions, Add Secret Sauce). It’s an amazing dance of software.

But I noticed that my friend the grill cook was constantly complaining about the system. Apparently, the order processing is really real time. When the guy up front presses the “double cheeseburger” button, it immediately lights up in the back but it doesn’t alert you that this is an order in progress! So, if the cooks are in a rush and just preparing orders as fast as possible, they might already have the pickles on the burger before the lady up front presses the “No Pickles” button, updating the display. Also, updated items are NOT IDENTIFIED by the system, so if the burger is already wrapped and the burger man is already moving to the next little square, it might not be caught! (Keep this in mind: most order “errors” at this internationally recognized fast food restaurant are caused by slow order takers, or slow customers, or customers who change their mind at the end of an order (Oh, could you make that burger with no onions?). Remember, if the guys in the back are rushing, get your order together in your head before you speak. If you say “Double Cheeseburger, no pickles, no onions, add secret sauce” just like that, it’ll pop into the system the right way!)

My question, of course, was “Why not rewrite the cash registers to be more awesome?” See, the old registers tied into a small computer in the back room that tied into the monitors in the kitchen. All state was held on that one machine, so obviously as soon as it was updated, it would appear on the monitors. But I couldn’t figure out why they kept using this stupid backwards system. It’s 2008! When I worked in the local greasepit in my small town, we used paper tickets we were more efficient than this fast food restaurant’s system! So why haven’t they updated? Simple: the people who can fix it aren’t there to use it.

Aha! That’s what makes SoftLayer so awesome. See, our programming staff is right here, in the same office as everyone else (except for those people who work in our datacenters, but they have our internal IM, email, and phone numbers and know they can contact us at any time.). If something breaks, or if something is built in a backwards or strange way, we know immediately and can turn around and fix it. In fact, we have a whole lot of programmers, as a ratio of developers to normal people. This high ratio allows us to have the best control portal in the world, and to add features quickly. See, if only developers worked at that fast food restaurant, and saw how the system was used, and were allowed to make changes (another awesome bit about SoftLayer: management is open to change. You’d be surprised how many obvious changes simply are not allowed by management in some dev shops…), then it would be a much easier place for everyone involved. And maybe I’d get my Double Cheeseburger right. Without the onions.

-Zoey

Categories: 
April 13, 2008

You Don’t Know What You Don’t Know

Around the office I am commonly considered a "low-level" software engineer. If you are in the business of computer programming you know this means I generally have various pieces of computer hardware strewn about my work area, and an ASCII chart hanging on my wall complete with a cheat-table so I can quickly convert numbers between binary, decimal, and hex. If you are not in the business of developing software, think of me as guy who couldn’t decide if I wanted to be an electrical engineer or a computer programmer and thus through my own indecision eventually found myself stuck somewhere in between. I know a bit about both but am not an expert in either. (I think the Roman word for this sort of limbo is purgatory, but I find it pretty cozy most days.)

At any rate when a project comes along that walks the fence between the realms of hardware and software my name naturally comes up. Such was the case a few weeks ago when one of our systems administrators had the need to retrieve the serial number from the RAM chips already installed in a number of servers. He asked me if it could be done. I looked and saw the information was reported in the BIOS of one of my machines, so I promptly responded with a “you bet”. After all, if the BIOS can display the information on the screen I should be able to as well. Right? I told him it would take a week.

The problem in this career field I have worked for some ten years now is you don’t know what you don’t know. Fast forward two weeks. Now think the Friday before Easter. That’s right, the one I am supposed to be off lounging around the house in my pajamas. It took a little longer to pull that serial number than I expected. If you’re interested the slow down turned out to be that the information existed at a physical memory address that was not easily accessible from Microsoft Windows (luckily for the BIOS it gets to display the data before an operating system is loaded).

Remember the old Chevy Chase movie "Funny Farm"? Chevy’s character is driving around lost when he passes the old man sitting on his porch in a rocking chair. Chevy stops his vehicle, rolls down his window, and says: “Excuse me Sir. Can you tell me how you would get to Redbud?” The old man leans forward, spits, and replies: “If I were going to Redbud I sure as hell wouldn’t start from here.”

Like Mr. Chase’s character in the movie, I didn’t get to pick where I started the journey from. We need the data available to us after the operating system boots. So I am hacking my way through it. I’m nearly there now. Close enough at least that I felt comfortable taking a break from the code and blowing off some steam by writing this blog. And the truth is, while I might have been whining just a bit I actually have enjoyed this project immensely. I appreciate the fact that the management here at SoftLayer gives us the opportunity to challenge ourselves and then grow to meet those challenges. We are encouraged to “get our hands dirty”. When I finish up here I will have a deeper understanding of how the BIOS relates to the operating system (and through the BIOS indirectly to the hardware).

As for our customers, well, it just so happens once I got to digging around in the binary mud there was a whole lot of other useful insight buried in the swirls of all those zeros and ones. Instead of extracting just the serial numbers I am pulling about a dozen pages of hardware data points we can use in statistical analysis for predicting failures, standards compliance, and availability trends. Like I said, you don’t know what you don’t know. But sometimes you are pleasantly surprised once you find out. By promoting such an amiable work environment, fostering creativity, and encouraging innovation, SoftLayer continues to boldly go where no other hosting company has gone before.

Alright, time to climb down from the pulpit and finish up my software.

Thanks for listening!

-William

Categories: 
March 14, 2008

From the Outside Looking In

Recently, as you know, SoftLayer released the new API version 3. We have all been working very hard on it, and we've been completely immersed in it for weeks (months, for some of us). This means that, for the developers, we've been living and breathing API code for quite some time now. The time came to release the API, and as many of you know, it was a smashing success. However, we were lacking in examples for its use. Sure, we all had examples coming out our ears since the customer portal itself uses the API, but those were written by the same developers that developed the API itself, and therefore were still written from an insider's perspective.

So a call went out for examples. Many people jumped on the list, offering to write examples in a variety of languages. I thought I would tackle writing an API usage example in Perl. Perl, for those of you unfamiliar, is an infamous programming language. Flexible, confusing, fantastic and horrifying, it is the very embodiment of both "quick and dirty" and "elegance." It is well loved and well loathed in equal measure by the programming community. Nevertheless, I have some experience with Perl, and I decided to give it a try.

I will attempt to describe my thought process as I developed the small applications (which you should be able to locate shortly in the SLDN documentation wiki) throughout the work day.

9am: "Wow, I really don't remember as much Perl as I thought. This may be difficult."
10am: "I need to install SOAP::Lite, that shouldn't be hard."
11am: "Where the heck are they hiding SOAP::Lite? There are articles about it everywhere, but I can't actually find it or get it installed!"
12pm: "Ok, got SOAP::Lite installed, and my first test application works perfectly! Things are going to be ok! Wait…what's all this about authentication headers?"
1pm: "What have I done to deserve this? Why can't I pass my user information through to the API?"
2pm: "Aha! Another developer just wandered by and pointed out that I've been misspelling 'authentication' for 2 hours! Back on track, baby!" (Side note: another "feature" of Perl is how it never complains when you use variables that don't exist, it just assumes you never meant to type that. Of course, you could tell it to complain, but I forgot about that feature because I haven't used Perl in 4 years.)
3pm: I finally get example #1 working. It queries the API and shows a list of the hardware on your account.
3:30pm: Example #2 working, this shows the details for a single server, including datacenter and operating system
4pm: Combining examples #1 and #2, the third example shows all hardware on your account, plus the installed OS and datacenter, in a handy grid right on the command line. Success! I put Perl away, hopefully for another 4 years.

The whole experience, though, really gave me an insight into how fantastically awesome the API is. I was looking at it from an outsider's perspective. I was confused as to how everything worked, I was working with an unfamiliar language, and I was browsing through the API looking for anything that looked "cool and/or useful." Getting a list of all my account's hardware to show up in a custom built application that I wrote as if I knew nothing about the API was a great feeling. It showed that not only was the API perfectly suited to the tasks we expected of it, but even a novice developer could, with a little effort, make an API application like mine. Expanding on it to show more and more information, and all the possibilities that it opened up in my mind made me realize how useful this API is that we made. It's not just something that a small percentage of our customers will be using. It's something that is truly revolutionary, and that all clients can take advantage of. I'm assuming, of course, that all clients have at least rudimentary skill in at least one programming language, but given the level of success everyone has had with our other offerings, I can assume that assumption is accurate.

If you have been thinking recently "look at all the noise they've been making about this 'API' nonsense," I highly recommend dusting off an old programming book and at least looking at it once. Think of all the possibilities, all the custom reports that you can make for yourself, all the data that we have provided right at your fingertips to assemble in any way you wish. We try our best to make the portal useful to every customer, but we know that you can't please all the people all the time. But with the API, we may do just that. If you're the kind of customer that is only interested in outbound bandwidth by domain, write an API script that displays just that! If you want to know the current number of connections and CPU temperature of your load balanced servers, get that data and show it! The possibilities are endless, and we're improving the API all the time.

-Daniel

March 10, 2008

Everyone is so Helpful Around Here!

Here at SoftLayer, all the developers stay on Jabber all day so we’re all accessible. As you know, we’ve recently been doing a major piece of software development: the new API. During development, we all were trying to get things finished as well as continue our day to day operations.

No fewer than 4 times during the last 3 weeks I have had the following conversation with a fellow developer.

Me: Hey, I need you to do something on this API class you wrote.
Other developer: Ok, no problem.
Me: Wait, you didn’t write this, did you?
Other developer: No, I didn’t.

Each time, when faced with a request to understand and modify something that they didn’t write, in addition to their already overwhelming workload, my fellow developers were more than happy to accept the new task.

It just goes to show what kind of environment we all work in here. Everyone is always willing to help, and it’s this attitude that allowed us to develop the API so quickly with such robust features. Each developer was willing to help the others, and that resulted in a tightly integrated product that we’re all very proud of.

The same sort of attitude pervades all of SoftLayer. I have had help on tasks from Networking, Accounting, and Sales since I got here, and each time everyone is more than happy to help out. The end result is, of course, that the customer gets their problems solved faster, and gets higher quality services out it the deal.

But really, fellow developers, if you’re reading this also, it’s acceptable to say “I didn’t write that” when I ask you to change it. I won’t be offended. Half the problem is that we have 5 developers with names starting with J, I just clicked the wrong guy!

-Daniel

February 28, 2008

Companion Cube

For the gaming/programmer community, Portal is THE GAME. Seemingly from nowhere, this game burst upon the scene and took the nerd world by storm. Excellent storyline, snappy dialog, challenging puzzles, and an awesome space-warping gun combine to create an incredibly memorable game.

Nearly overnight, the hacker lexicon got some new words and phrases. This guide will help you make sense of most hacker conversations you may hear that refer to Portal.

The Cake is a Lie

The artificially intelligent computer that runs the series of puzzles (known as the Aperture Science Computer Aided Enrichment Center) goads your character along by stating that "cake" will be served to you if you survive all the tests. However, graffiti on the walls of the center proclaim otherwise... stating that the cake being promised is a great, big lie.

Hackers generally use this phrase either as an icebreaker or as a description of a situation where somebody is motivated to do a difficult task for a promised but unverified reward.

I'm making a note here: Huge Success!

At the end of the game, the computer gives you your final review. At the beginning of the review, it says "This was a triumph. I'm making a note here: Huge Success!"

Like Trekkies shouting "Qua'pla!" (Klingon for "Success!"), programmers are now known to say that they are "making a note here: Huge Success!"

The Companion Cube

The Companion Cube is an inert storage cube imbued with a personality by the game programmers to trick game players into carrying this cube throughout a puzzle, but then requiring them to destroy it at the end. They did such a good job, however, that game players have become attached to this "Companion Cube," going so far as to build little paper models or buy plushies of this "character." Generally, you'll hear a hacker talk about how they would never let go of their companion cube, or something along those lines.

Aperture Science Thing We Don't Know What It Does

Programmers find long multi-word names for products to be humorous. The game developers played on this concept:

  • It's not the lab. It's the Aperture Science Computer Aided Enrichment Center.
  • It's not a storage box. It's an Aperture Science Weighted Storage Cube.
  • It's not a button. It's an Aperture Science 1500 Megawatt Superconducing Super Button.

The joke is to take, say, a mouse, and turn it into an "Aperture Science Rotational Axis 2 Dimensional Vector Detecting Peripheral".

Now You're Thinking in Portals

With this guide handy, you can start to understand the conversations of your Portal crazed coworkers. You will no longer be confused when a coworker bursts out laughing when holding a slice of cake. You won't wonder why he has a background with little hearts all over it, displaying a strange box. You can now safely laugh at any name longer than 4 words, knowing that it's most likely a joke. This won't help with any of the other strange things developers say, but at least their conversations should be a little more transparent now.

For more information, check Wikipedia, or better yet, Watch the trailer and play the game.

-Zoey

January 29, 2008

Where is All the Noise?

Earlier in the week, Shawn Boles wrote a post that included some nostalgic feelings for old-fashioned computers. As I read it, I was thinking of my own experiences with the grandfathers of our desktop computers. I vividly remember getting the floppy disks out of the big dusty box, sliding them into the drive, and listening as the drive began its slow, crunching march towards the data I needed. That’s when it hit me. I can’t hear my computer! Sure, there’s a cooling fan in it, and if I stick my head under my desk I can hear not only the fan, but my coworkers quietly asking each other why my head is under my desk in the middle of the day. Other than that, there’s nothing! No drive heads moving, no crunching, no system beeping, no modem noises, and certainly no death rattles.

That’s right, death rattles. Those of you unfamiliar with the dinosaurs we used to call computers don’t know about the death rattles. The large floppy drives were the worst offenders. Every faulty sector on those disks caused a loud grinding sound that you could FEEL, indicating that the pencil-sized drive head was none too happy with encountering the data equivalent of a marching band at a funeral. Now that we’ve moved away from media that comes in physical contact with the drive head, we’ve moved away from the death rattles. However, hard drives can occasionally produce them, even to this day. When a hard drive goes bad, it emits this high-pitched chirping sound, akin to what you would expect a robotic sparrow to make.

When I was in high school, my best friend’s dad was a programmer. One day we were working on a bad hard drive for a friend and had a brilliant idea. We took a microphone and recorded the sounds the hard drive was making. With some Mp3 editing tools, we added roughly 10 minutes of silence in front of that sound. Then, we made the sound into his dad’s windows startup sound. So upon turning on his computer, he would work for 10 minutes and then hear the DEATH RATTLE. Watching his pasty frame lunge for the power button was hilarious for a good 24 hours after it happened.

Browsing computer message boards (yes, I’m a nerd, that’s why I work here as a developer) I occasionally come across people who are still cursed by dial-up modems, and they invariably ask how they can disable the noises their modem makes when it connects. I want to scream to them “DON’T! You’ll destroy your last audible connection to your machine!” The noises a modem makes are iconic, and a sufficiently trained guru can tell the connection speed simply by listening to the connection noises. From the industrial clanking of the 2400 baud to the sci-fi whooshing of the 56k, each remaining hardware noise is precious.

Precious to humans anyway. When I was younger I saved all my money for weeks to buy a 56k modem. I painstakingly researched (at 24,000 baud) all the different kinds of modems I could purchase, and finally decided on a US Robotics 56k modem. I arrived home from my triumphant shopping trip and promptly tore the cover off the family computer to install my new toy. Once installed, I powered up the computer, installed the drivers, and attempted to connect. Sweet, sweet screeching poured out of the modem, to my delight! However, my dog was also in the room. He had, until this point, tolerated the noises the computer had been making in “his” room. However, how there was a new noise. A new, screechier noise. And it was coming from an OPEN COMPUTER CASE. That’s right, in my excitement, I had left the case cover off just in case I had to tinker some more. My dog got up, walked across the room, and promptly ripped the modem right out of the case with one mighty chomp. He threw it on the ground, chomped it once more and then, satisfied that it would no longer disturb his rest, flopped back down onto his bed in the corner. I still cannot hear a connection sequence without bringing up that memory.

Of course, we don’t have to worry about these things at SoftLayer (dogs OR noises). We developers work on silent machines with no rattles or screeches, while the servers in the data center are attended to by dozens of employees, aware of any slight problem. The noise in the data center is substantial. Each employee wears hearing protection, and even with that the noise of thousands of cooling fans will get to you. Each time the developers have to spend a morning in the data center installing new servers, we spend the rest of the day shouting “WHAT?!” to each other. But computers will continue to get quieter, and our connection to them will continue to be less and less physical. Our customers know this already: none of them have even seen their servers, they rely on our skilled datacenter staff to monitor their hardware for them, day and night. But there are no death rattles, no screeches, just cooling fans.

The last of our noisy connection to our computers is starting to fade. Already we’ve stopped using magnetic media like floppy disks, and the noisy CD and DVD drives of yesteryear are being replaced with silent models. Even the hard drives that caused my friend and I so much joy are being replaced with mechanically simple solid state drives, which run much faster and have no noise at all. Come to think of it, I think I can learn to live in the new silent computing future.

-Daniel

Categories: 
January 16, 2008

Where Have All the Gurus Gone?

When I was growing up, computers were these wonderful things that sat at the back of the classroom (usually one, or maybe two if the class was lucky). If the school was lucky, there was a "computer lab" where you could have access to the latest and greatest in government approved hardware.

My favorite of the time was the Apple IIe. Our school district had so many of them, they handed 'em out to classrooms (The school district now uses them as very effective door stops). In fact, I got my start with computers by tinkering with a IIe. My first computer experience was hooking up a printer to a IIe, and the wonder of this experience (plug something in, type a command, and print came out!) completely captured me (I was in first grade), and from that moment on I was completely wrapped up in the wonder of computers.

Anyway, I graduated to PC compatibles and DOS. Trying to get a grasp on this computer thing, I got a copy of DOS for Dummies. Near the beginning of the book, they had a paragraph that had some important words of wisdom. While I don't have the book any more, the message is still with me: "This book will teach you the basics of the computer, what you can do, what you can't do, and what you really shouldn't ever do. However, for anything you don't know, contact your local computer guru."

Computer Guru? What is this "Computer Guru"?

According to Wikipedia, Guru means "Teacher, in a religious or spiritual sense." And as luck would have it, I was able to get into contact with Computer Gurus throughout my life. These were the computer equivalents of the small town mechanic: you pull up for some gas and Harvey the mechanic walks around the corner. "Howdy! I heard you pull up. You've got a bit of a timing issue, and I think one of your spark plugs are bad. I can change 'em out in a few minutes, if you like." It's almost like Harvey has a supernatural connection to vehicles. He can hear issues, he can smell problems... he's one with the Motor Vehicle Force.

The same with the Computer Gurus I knew. You walked in and turned on your machine, they'd make a "Hmm" sound (in computer science, "Hmm" is similar to the Indian sacred syllable "Aum" or "Om". It's ritually chanted by a computer guru whilst contemplating your computer's connection to the Universe), type some sacred symbols into the prompt, then tell you the problem and offer to fix it. Most times they would happily fix your computer in exchange for a pizza; sometimes just getting a cup of coffee from the ever present drip dispenser could net you a small fix. And if you were truly interested in computers, you could even ask to become a follower of the Guru. You'd spend your spare time in his or her office, ask meaningful questions about the nature of the Universe, contemplate ancient tomes and user manuals, and take care of the mundane tasks of life (like formatting floppies or installing software) so the Guru could spend their time connecting with his or her latest project (generally spent looking at an arcane flowchart or design document and saying "Hmm" a lot). You knew, one day, with practice and patience, you too could become a Guru, have followers to format your floppies, and say Hmm.

However, the computer industry started changing. User interfaces became simpler, USB made the promise of true plug-and-play a near reality... the command line all but disappeared. Computers stopped being a specialized device and became a commodity. Computers were EVERYWHERE. And there was this belief that computers will become so "user friendly" that there was no need for the long learning process of the Guru.

And for the most part, this has happened. Programs are very user friendly now. There's tons of documentation, and most don't expect you to have a PhD in Computer Science to understand them. Workflows have become "point and click link" instead of "chant this esoteric string into the command prompt".

However, sometimes I really miss my Guru. For example, just this last week, my roommate's computer (which I built) started randomly crashing. There wasn't a specific program that crashed, and it didn't crash at a set time. I knew something was wrong, so I tried to diagnose. 'Course, Vista being user friendly, the computer would automatically reboot, without showing the Bluescreen, except for the subliminal hint of blue to let you know that the computer had crashed. See, blue screens have "Technical Information" (it says so right on the screen!)... and user friendly computers (1) don't crash, and (2) are NOT technical. So I was stuck with a computer that wouldn't run, and a bored Roommate who just realized he has a $1200 paperweight.

As Dr. McCoy would say, "I'm a programmer, not a hardware doctor!" Hardware issues are right outside my realm of experience. I longed for my Guru. I knew how to diagnose; I pulled hardware, changed orders of cards, swapped the memory sticks back and forth... all the standard religious rituals for modern computers. I knew that if I could but approach a Guru, tell him or her my issue, they could give me leads to check. I didn't have the money to buy all new parts at random; I had to work with what I had. I knew I had all the data for a real diagnosis... I simply wasn't able to pick out the error. Working the next day at SoftLayer, I mused about my lack of Guru leadership. At the end of the day, I turned to a coworker and said "Now I get to tinker for a few more hours on this stupid computer. I wish I knew a Computer Guru!"

My coworker smiled and asked what the problem was. I told him and he looked at the ceiling. "Hmm" he said. "Could be a power supply issue. Maybe the power coming out of the supply isn't clean and it's resetting the motherboard." Just then, another coworker walked around the corner.

"What about a power supply?" he asked. The first coworker told him the issue. "Hmm," he said, looking intently at the wall. "I bet it's a RAM issue. I bet your ram is bad. Swap it out with some good RAM and see what happens."

So I went home and crosswired some power supplies. Rebooting the machine, I finally got a bluescreen that crashed itself, locking up the computer and letting me read it. "PAGE_FAULT_IN_NON_PAGED_AREA" "Page Fault?" I thought. "Hmm." My roommate walked in. "What are you doing, meditating? Have you fixed it yet?"

We went to Fry's and bought some new RAM sticks. Going home, I popped 'em in and started the machine. And it worked! It's been running 6 days nonstop. My roommate was really happy. I was finally able to look up the bluescreen message up on the Internet. Sure enough, that specific error almost always pops up when there's bad ram.

So, where have all the Gurus gone? Where else? They all work at SoftLayer! Whenever I've had a software or hardware issue, or an operating system issue, I've found somebody here who knows the issue. They look at the wall, say "Hmm", sip their coffee or Monster (depending on their level of enlightenment), and give me the answer. The guys here are at one with the Network. The DC guys almost seem to be able to FEEL a power issue or a drive problem before it happens. SLales is able to think about your problems and provide a tailor made solution to help. And Development is where all the action takes place; we get to write all the behind the scenes magic.

"You must be some kind of Computer Genius!" shouts my roommate (lucky for me, he's gotten to play some Call of Duty 4, so he's already forgotten the previous week of frustration). "No, not yet." I respond. "I'm working on it, but I'm not a Guru yet."

-Zoey

Subscribe to programmers