executive-blog

August 29, 2012

Demystifying Social Media: Get Involved

A few weeks back, Kevin handed me The Thank You Economy by Gary Vaynerchuk and said we should give it a read. I'm only halfway through it, but I thought I should share some of Vaynerchuk's insights on social media with the SoftLayer blog audience while they are still fresh in my mind.

The best summary of The Thank You Economy comes straight from its pages:

"The Thank You Economy explains how businesses must learn to adapt their marketing strategies to take advantage of platforms that have completely transformed consumer culture and society as a whole."

The book looks at how human nature hasn't changed, but everything else has. The rise of social media is as game-changing as the radio and the television were, and that presents a combination of challenge and opportunity for businesses. In Vaynerchuk's words, "What we call social media is not media, nor is it even a platform. It is a massive cultural shift that has profoundly affected the way society uses the greatest platform ever invented, the Internet."

I've been "in the trenches" with SoftLayer's social media presences for over a year now, and I realized that I take advantage of the fundamental openness of the company. Vaynerchuk urges businesses to dive into social media, and he shares some of most common reasons companies aren't getting involved — I could list all eleven reasons here, but you'd probably recognize them all as excuses you've heard.* The common theme: People (and companies) fear uncertainty, and while that fear is understandable, it shouldn't be paralyzing. The opportunity and necessity of engagement outweigh the excuses.

When you clear all the hurdles preventing your entrance to the world of social media, you need to execute. Vaynerchuk explains how "Cultural Building Blocks" of a company dictate that company's success in social media, and while they aren't exactly an Easy Bake Oven recipe to viral success, they are profound in their simplicity:

  1. Begin with Yourself
  2. Commit Whole Hog
  3. Set the Tone
  4. Invest in Employees
  5. Trust Your People
  6. Be Authentic

The "trust your people" and "be authentic" building blocks resonated the most when I thought of how SoftLayer's social media is managed. The level of trust my boss has in me is both refreshing and challenging, and I find myself working harder to prove I deserve it. A cynic might read that sentence and scoff at its over-the-top positivity, but I'm as honest as I can be ... And that's an example of the challenge of being authentic. SoftLayer employees are passionate about their responsibilities and the company culture, and that kind of enthusiasm is so rare that there's a tendency to assume that it's manufactured.

If I see someone talking to us via social media about a bad experience at SoftLayer, I'm more concerned about changing their experience than I am about what they share with their social network. Often, when I follow up with those customers, when the problem is resolved, it's amazing how surprised people are that someone actually took the time to make things right. I want to hear if someone has a bad experience because I take pride in turning it around. Are we "in control" of what people say about SoftLayer on social media? No. We are in control of how SoftLayer responds to what people are saying about us, though.

Your business needs to be active in social media.

You don't need a "social media team" or a budget or a strategy ... You need to be passionate about your employees, customers and products, and you need to make time to reach out to your community — wherever they are.

What roadblocks have you run into when it comes to your business's social media engagement? If you've been successful, what tips could you share with me (and the rest of the SoftLayer audience)?

-Rachel

*If you're toying with the idea of social media engagement or you're working for a company that hasn't embraced it yet, it's worth it for you to buy The Thank You Economy to read how @garyvee dismantles those excuses.

August 27, 2012

IPv4 v. IPv6 - What's the Difference?

About a year ago, Phil Jackson and I recorded a podcast-esque click-through of a presentation that explained the difference between IPv4 and IPv6 address space, and as a testament to the long-tail nature of blog posts, Internet Society's Deploy360 Blog shared the video. With a hint of nostalgia, I clicked "play" on the video.

I laughed. I cried. I found it informative. I noticed a few places where it could have been better.

We recorded the video in response to a tweet from one of our Twitter followers, and the off-the-cuff dialog wound up being somewhere in between "accessible, informative and funny" and "overly detailed, too long and obviously improvised." Because there aren't many people who want to listen to two guys give a 15-minute presentation on IP addresses when they could be watching a Songified review of Five Guys Burgers and Fries or an epic data center tour, I thought I'd dilute the information from the video into a quick blog post that spells out some of the major distinctions between IPv4 and IPv6 so you can scan it, interject your own "witty" banter and have your favorite YouTube viral video playing in the background.

IP Address Overview

An IP address is like a telephone number or a street address. When you connect to the Internet, your device (computer, smartphone, tablet) is assigned an IP address, and any site you visit has an IP address. The IP addressing system we've been using since the birth of the Internet is called IPv4, and the new addressing system is called IPv6. The reason we have to supplement the IPv4 address system (and ultimately eclipse it) with IPv6 is because the Internet is running out of available IPv4 address space, and IPv6 provides is an exponentially larger pool of IP addresses ... Let's look at the numbers:

  • Total IPv4 Space: 4,294,967,296 addresses
  • Total IPv6 Space: 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses

Even saying the IPv6 space is "exponentially larger" doesn't really paint the picture of the difference in size.

IPv4 Addresses

To understand why the IPv4 address space is limited to four billion addresses, we can break down an IPv4 address. An IPv4 address is a 32-bit number made up of four octets (8-bit numbers) in decimal notation, separated by periods. A bit can either be a 1 or a 0 (2 possibilities), so the decimal notation of an octet would have 28 distinct possibilities — 256 of them, to be exact. Because we start numbering at 0, the possible values of one an octet in an IPv4 address go from 0 to 255.

Examples of IPv4 Addresses: 192.168.0.1, 66.228.118.51, 173.194.33.16

If an IPv4 address is made up of four sections with 256 possibilities in each section, to find the total number of possibilities in the entire IPv4 pool, you'd just multiply 256*256*256*256 to get to the 4,294,967,296 number. To look at it another way, you've got 32 bits, so 232 will get you to the same total.

IPv6 Addresses

IPv6 addresses are based on 128 bits. Using the same math as above, we can take 2128 and find the total IPv6 address pool (which I won't copy again here because it takes up too much space). Because the IPv6 pool is so much larger than the IPv4 pool, it'd be much more difficult to define the space in the same decimal notation ... you'd have 232 possibilities in each section.

To allow for that massive IPv6 pool to be used a little more easily, IPv6 addresses are broken down into eight 16-bit sections, separated by colons. Because each section is 16 bits, it can have 216 variations (65,536 distinct possibilities). Using decimal numbers between 0 and 65,535 would still be pretty long-winded, so IPv6 addresses are expressed with hexadecimal notation (16 different characters: 0-9 and a-f).

Example of an IPv6 Addresses: 2607:f0d0:4545:3:200:f8ff:fe21:67cf

That's still a mouthful, but it's a little more manageable than the decimal alternatives.

CIDR Slash (/) Notation

When people talk about blocks of IP addresses, they generally use CIDR Slash (/) Notation where the block might look like this: 192.0.2.0/24 ... When you glance at that number, you might assume, "Okay, so you have 192.0.2.0 through 192.0.2.24," but CIDR notation is not showing you the range of addresses, it's telling you the size of the "network" part of the allocation.

IP addresses are made up two parts — the network and the host. The "network" part of the address tells us the number of bits that stay the same at the beginning of the block of IPs, while the "host" part of the address are the bits that define the different possibilities of IP addresses in the block. In CIDR notation, a /24 is telling us that the first 24 bits of the address are defined by the network, so we have 8 bits (32 total bits minus 24 network bits) in the host — 28 is 256 distinct addresses. The 192.0.2.0/24 IPv4 address block includes 192.0.2.0 to 192.0.2.255.

IPv4 address blocks can be as large as a /8 (given to regional registries like ARIN and APNIC), and they can be as small as a /32 (which is a single IP address).

Why Provision So Many IPv6 Addresses?

When SoftLayer provisions an IPv6 address block on a server, we give a /64 block of IPv6 addresses ... Or 18,446,744,073,709,551,616 IPv6 addresses to each server. That number seems excessive, but the /64 block size is the "smallest" IPv6 allocation block.

Providers like SoftLayer are allocated /32 blocks of IPv6 addresses. The difference between a /32 and a /64 is 32 bits (232) ... Bonus points if you can remember where you've seen that number before. What that means is that SoftLayer is given a block of IP addresses so large that we could provision 4,294,967,296 /64 blocks of IPv6 addresses ... Or put more remarkably: In one /32 block of IPv6 space, there are the same number of /64 blocks of IPv6 addresses as there are TOTAL IPv4 addresses.

So while it's pretty impossible to use a full /64 of IPv6 addresses on a server, it's equally difficult for SoftLayer to burn through its /32 block.

So Now What?

IPv4 space is running out quickly. If your site isn't running a dual-stack IPv6 configuration yet, it's possible that you're going to start missing traffic from users who are only able to access the Internet over IPv6 (which is not backwards compatible with IPv4). If your Internet Service Provider (ISP) doesn't support IPv6 yet, you won't be able to access websites that are broadcast only with IPv6 addresses.

The percentage of instances of each of those cases is relatively small, but it's only going to get larger ... And it only takes one missed customer to make you regret not taking the steps to incorporate IPv6 into your infrastructure.

-@khazard

August 21, 2012

High Performance Computing - GPU v. CPU

Sometimes, technical conversations can sound like people are just making up tech-sounding words and acronyms: "If you want HPC to handle Gigaflops of computational operations, you probably need to supplement your server's CPU and RAM with a GPU or two." It's like hearing a shady auto mechanic talk about replacing gaskets on double overhead flange valves or hearing Chris Farley (in Tommy Boy) explain that he was "just checking the specs on the endline for the rotary girder" ... You don't know exactly what they're talking about, but you're pretty sure they're lying.

When we talk about high performance computing (HPC), a natural tendency is to go straight into technical specifications and acronyms, but that makes the learning curve steeper for people who are trying to understand why a solution is better suited for certain types of workloads than technology they are already familiar with. With that in mind, I thought I'd share a quick explanation of graphics processing units (GPUs) in the context of central processing units (CPUs).

The first thing that usually confuses people about GPUs is the name: "Why do I need a graphics processing unit on a server? I don't need to render the visual textures from Crysis on my database server ... A GPU is not going to benefit me." It's true that you don't need cutting-edge graphics on your server, but a GPU's power isn't limited to "graphics" operations. The "graphics" part of the name reflects the original intention for kind of processing GPUs perform, but in the last ten years or so, developers and engineers have come to adapt the processing power for more general-purpose computing power.

GPUs were designed in a highly parallel structure that allows large blocks of data to be processed at one time — similar computations are being made on data at the same time (rather than in order). If you assigned the task of rendering a 3D environment to a CPU, it would slow to a crawl — it handles requests more linearly. Because GPUs are better at performing repetitive tasks on large blocks of data than CPUs, you start see the benefit of enlisting a GPU in a server environment.

The Folding@home project and bitcoin mining are two of the most visible distributed computing projects that GPUs are accelerating, and they're perfect examples of workloads made exponentially faster with the parallel processing power of graphics processing units. You don't need to be folding protein or completing a blockchain to get the performance benefits, though; if you are taxing your CPUs with repetitive compute tasks, a GPU could make your life a lot easier.

If that still doesn't make sense, I'll turn the floor over to the Mythbusters in a presentation for our friends at NVIDIA:

SoftLayer uses NVIDIA Tesla GPUs in our high performance computing servers, so developers can use "Compute Unified Device Architecture" (CUDA) to easily take advantage of their GPU's capabilities.

Hopefully, this quick rundown is helpful in demystifying the "technobabble" about GPUs and HPC ... As a quick test, see if this sentence makes more sense now than it did when you started this blog: "If you want HPC to handle Gigaflops of computational operations, you probably need to supplement your server's CPU and RAM with a GPU or two."

-Phil

August 17, 2012

SoftLayer Private Clouds - Provisioning Speed

SoftLayer Private Clouds are officially live, and that means you can now order and provision your very own private cloud infrastructure on Citrix CloudPlatform quickly and easily. Chief Scientist Nathan Day introduced private clouds on the blog when it was announced at Cloud Expo East, and CTO Duke Skarda followed up with an explanation of the architecture powering SoftLayer Private Clouds. The most amazing claim: You can order a private cloud infrastructure and spin up its first virtual machines in a matter of hours rather than days, weeks or months.

If you've ever looked at building your own private cloud in the past, the "days, weeks or months" timeline isn't very surprising — you have to get the hardware provisioned, the software installed and the network configured ... and it all has to work together. Hearing that SoftLayer Private Clouds can be provisioned in "hours" probably seems too good to be true to administrators who have tried building a private cloud in the past, so I thought I'd put it to the test by ordering a private cloud and documenting the experience.

At 9:30am, I walked over to Phil Jackson's desk and asked him if he would be interested in helping me out with the project. By 9:35am, I had him convinced (proof), and the clock was started.

When we started the order process, part of our work is already done for us:

SoftLayer Private Clouds

To guarantee peak performance of the CloudPlatform management server, SoftLayer selected the hardware for us: A single processor quad core Xeon 5620 server with 6GB RAM, GigE, and two 2.0TB SATA II HDDs in RAID1. With the management server selected, our only task was choosing our host server and where we wanted the first zone (host server and management server) to be installed:

SoftLayer Private Clouds

For our host server, we opted for a dual processor quad core Xeon 5504 with the default specs, and we decided to spin it up in DAL05. We added (and justified) a block of 16 secondary IP addresses for our first zone, and we submitted the order. The time: 9:38am.

At this point, it would be easy for us to game the system to shave off a few minutes from the provisioning process by manually approving the order we just placed (since we have access to the order queue), but we stayed true to the experiment and let it be approved as it normally would be. We didn't have to wait long:

SoftLayer Private Clouds

At 9:42am, our order was approved, and the pressure was on. How long would it take before we were able to log into the CloudStack portal to create a virtual machine? I'd walked over to Phil's desk 12 minutes ago, and we still had to get two physical servers online and configured to work with each other on CloudPlatform. Luckily, the automated provisioning process took on a the brunt of that pressure.

Both server orders were sent to the data center, and the provisioning system selected two pieces of hardware that best matched what we needed. Our exact configurations weren't available, so a SBT in the data center was dispatched to make the appropriate hardware changes to meet our needs, and the automated system kicked into high gear. IP addresses were assigned to the management and host servers, and we were able to monitor each server's progress in the customer portal. The hardware was tested and prepared for OS install, and when it was ready, the base operating systems were loaded — CentOS 6 on the management server and Citrix XenServer 6 on the host server. After CentOS 6 finished provisioning on the management server, CloudStack was installed. Then we got an email:

SoftLayer Private Clouds

At 11:24am, less than two hours from when I walked over to Phil's desk, we had two servers online and configured with CloudStack, and we were ready to provision our first virtual machines in our private cloud environment.

We log into CloudStack and added our first instance:

SoftLayer Private Clouds

We configured our new instance in a few clicks, and we clicked "Launch VM" at 11:38am. It came online in just over 3 minutes (11:42am):

SoftLayer Private Clouds

I got from "walking to Phil's desk" to having a multi-server private cloud infrastructure running a VM in exactly two hours and twelve minutes. For fun, I created a second VM on the host server, and it was provisioned in 31.7 seconds. It's safe to say that the claim that SoftLayer takes "hours" to provision a private cloud has officially been confirmed, but we thought it would be fun to add one more wrinkle to the system: What if we wanted to add another host server in a different data center?

From the "Hardware" tab in the SoftLayer portal, we selected "Add Zone" to from the "Actions" in the "Private Clouds" section, and we chose a host server with four portable IP addresses in WDC01. The zone was created, and the host server went through the same hardware provisioning process that our initial deployment went through, and our new host server was online in < 2 hours. We jumped into CloudStack, and the new zone was created with our host server ready to provision VMs in Washington, D.C.

Given how quick the instances were spinning up in the first zone, we timed a few in the second zone ... The first instance was online in about 4 minutes, and the second was running in 26.8 seconds.

SoftLayer Private Clouds

By the time I went out for a late lunch at 1:30pm, we'd spun up a new private cloud infrastructure with geographically dispersed zones that launched new cloud instances in under 30 seconds. Not bad.

Don't take my word for it, though ... Order a SoftLayer Private Cloud and see for yourself.

-@khazard

August 15, 2012

Managing Support Tickets: Email Subscriptions

This week, the development team rolled out some behind-the-scenes support functionality that I think a lot of our customers will want to take advantage of, so I put together this quick blog post to spread the word about it. With the new release, the support department is able to create "Ticket Email Subscriptions" for different ticket groups on every customer account. As a customer, you might not be jumping up and down with joy after reading that one-sentence description, but after you hear a little more about the functionality, if you're not clapping, I hope you'll at least give us a thumbs-up.

To understand the utility of the new ticket email subscription functionality, let's look at how normal tickets work in the SoftLayer portal without email subscriptions:

User Creates Ticket

  1. User A creates a ticket.
  2. User A becomes the owner of that ticket.
  3. When SoftLayer responds to the ticket, an email notification is sent to User A to let him/her know that the ticket has been updated.

SoftLayer Creates Ticket

  1. SoftLayer team creates a ticket on a customer's account.
  2. The primary customer contact on the account is notified of the new ticket.
  3. Customer logs into the portal and responds to ticket.
  4. Customer gets notifications of updates (as described above).

There's nothing wrong with the existing support notification process, but that doesn't mean there aren't ways to make the process better. What if User A creates an urgent ticket on his/her way out the door to go on vacation? User B and User C aren't notified when an update is posted on User A's ticket, so the other users aren't able to get to the ticket and respond as quickly as they would have if they received the notification. What if the primary customer contact on the account isn't the best person to receive a monitoring alert? The administrator who will investigate the monitoring alert has to see the new ticket on the account or hear about it from the primary contact (who got the notification).

Ticket email subscriptions allow for customers to set contact addresses to be notified when a ticket is created, edited or moved in a particular ticket group. Here are the ticket groups differentiated in our initial release:

  • Billing - Any ticket in our Billing department
  • Maintenance - Scheduled maintenance notifications for specific servers
  • Network Protection - DDoS mitigation and Null Routes
  • Monitoring - Host Down Alerts
  • CST, SysAdmin and Hardware - Any ticket in our support and data center departments
  • Managed Services - Tickets that relate to any managed services
  • Network Maintenance - Scheduled network maintenance

You'll notice that Abuse isn't included in this list, and the only reason it's omitted is because you've always been able to designate a contact on your account for abuse-related tickets ... Ticket subscriptions extend that functionality to other ticket groups.

Because only one email address can be "subscribed" to notifications in each ticket group, we recommend that customers use their own distribution lists as the email contacts. With a DL as the contact, you can enable multiple users in your organization to receive notifications, and you can add and remove users from each distribution list on your end quickly and easily.

When User A creates a ticket with the data center and goes on vacation, as soon as SoftLayer responds to the ticket, User A will be notified (as usual), and the supportsubscription@yourdomain.com distribution will get notified as well. When a network maintenance is ticket is created by SoftLayer, the netmaintsubscription@yourdomain.com distribution will be notified.

Ticket email subscriptions are additive to the current update notification structure, and they are optional. If you want to set up ticket email subscriptions on your account, create a ticket for the support department and provide us with the email addresses you'd like to subscribe to each of the ticket groups.

We hope this tool helps provide an even better customer experience for you ... If you don't mind, I'm going to head back to the lab to work with the dev team to cook up more ways to add flexibility and improvements into the customer experience.

-Chris

August 9, 2012

Startup Series: Dudepins

The Catalyst startup incubator has been running at full-throttle for a while now, and I've been blown away by the killer startups that have joined the program. The best part of my job is meeting entrepreneurs who see a need in the marketplace and have a vision for how to meet that need in a targeted way, and the story behind Dudepins — one of the startups in Catalyst — is a perfect example of that kind of thinking. Their goal: Macho visual bookmarking.

Dudepins: Dudes like sharing stuff. Man up. Sign up. Pin up.

Pinterest has been getting a lot of attention since 2011, but it still hasn't really been able to penetrate the male demographic; maybe because it's been so effective at cultivating content around fashion, recipes, DIY home ideas and cute puppies (Watch College Humor's "The Fall of Pinterest," and you'll see what I mean). The Dudepins team noticed an unmet demand for a male-oriented visual bookmarking site, and they seized the opportunity to build that platform.

Their Formula: 2 dudes + 2 computers + 1 idea + infinite scotch – non-infinite income = Dudepins!

Dudepins: Dudes like sharing stuff. Man up. Sign up. Pin up.

I fired off a few questions to the Dudes at Dudepins to get a little insight into how they built their business and what they'd recommend to other entrepreneurs in the same position ... They did not disappoint:

Q: How do you describe what Dudepins does?

Dudepins is a collection of montages — or personal boards — of pictures and videos, sorted into various categories. Dudepins is a place where you can easily save, share and collect everything that you find on the Internet, and you're able to organize that content into different montages (i.e. cars, style, watches, cigars, planes, food, travel, etc.). When you want to see the stuff thousands of other Dudes just like you have uploaded, we make that easy as well.

More simply: Dudes, Gentlemen, Guys, Sirs and whatever else a Man might call himself can use Dudepins to collect, save, view and browse everything associated with being a Dude.

Q: How did you find out about SoftLayer?

A: We were initially contacted by two seriously awesome Dudes: Josh Krammes and Kelley Hilborn. Both Josh and Kelley were in Vancouver on business, and fortunately, we were able to get together with them for some dinner. Sparks flew, and Dudepins was invited to join Catalyst.

Q: What has your experience been since you signed up?

A: We knew we'd get solid hosting when we signed on with SoftLayer, but we were most surprised by how far the support and benefits of Catalyst go beyond the infrastructure actually running Dudepins. The SoftLayer team has been a great resource for technical questions, and they've helped us meet several industry experts who, in turn, have provided a lot of amazing feedback about what can help us take Dudepins to the next level.

You guys (Josh, Kelley, Paul and John) are rockstars, and we highly recommend Catalyst to any startup looking for a bulletproof hosting infrastructure and network of brilliant advisers.

Q: What advice would you give to other startups?

A: It's extremely important to stay focused, motivated, goal-oriented and (most importantly) driven. Don't get married to your ideas, and don't let passions overrule logic ... especially when the sky gets cloudy.

Check out Dudepins at dudepins.com, and make sure you visit their "about us" page ... Trust me, it's awesome.

I hate to cut the Q&A short, but TechStars Boulder Demo Day is starting, and I have to go meet the next class of future SoftLayer customers!

If you've got a brilliant, creative, innovative or otherwise awesome startup, and you think Catalyst could be a good fit for you, make sure you hit us up from the "Apply" page on the SoftLayer Catalyst site.

-@PaulFord

August 8, 2012

No iFrames! Dynamically Resize Divs with jQuery.

It's no secret that iframes are one of the most hated methods of web page layouts in the web development world — they are horrible for SEO, user experience and (usually) design. I was recently charged with creating a page that needed functionality similar to what iframes would normally provide, and I thought I'd share the non-iframe way I went about completing that project.

Before I get into the nitty-gritty of the project, I should probably unpack a few of the reasons why iframes are shunned. When a search engine indexes a page with iframes, each iframe is accurately recorded as a separate page — iframes embed the content of one we page inside of another, so it makes sense. Because each of those "pages" is represented in a single layout, if a user wanted to bookmark your site, they'd probably have a frustrating experience when they try to return to your site, only to find that they are sent directly to the content in one of the frames instead of seeing the entire layout. Most often, I see when when someone has a navigation bar in one frame and the main content in the other ... The user will bookmark the content frame, and when they return to the site, they have no way to navigate the pages. So what's a developer to do?

The project I was tasked with required the ability to resize only certain sections of a page, while asynchronously shrinking another section so that the entire page would always stay the same size, with only the two sections inside changing size.

Let's look at an example with two divs, side by side on a web page:

iFrame Tutorial

One div will contain a navigation menu to jump to different pages of the website (#sidebar), and the second div will contain all the content for that page (#content). If some of the elements in #sidebar are too long to read with the default width of the div, we want to let the user freely resize the two divs without changing the width of the page.

Our task is straightforward: When #sidebar expands in width, also expand the navigation and shrink #content along with the main content inside #content. If #sidebar shrinks, the navigation, #content and main content would respond accordingly as well:

iFrame Tutorial

It's a relatively easy concept to do with iFrames ... But then you remember that iframes are no longer cool (yes, there was a time long ago when iframes were cool). I decided to turn to my favorite alternative — jQuery — and the fix was actually a lot easier than I expected, and it worked beautifully. Let's run through a step-by-step tutorial.

1. HTML

Lay out your two divs:

<div id="sidebar"> 
<div class="sidebar-menu">
<!-- all your sidebar/navigational items go here -->
</div>
</div>
<div id="content">
<!-- all your main content goes here -->
</div>

2. CSS

Style your divs:

#sidebar {
       width: 49%;
}
#content {
width: 49%;
        float: left;
}

3. jQuery

Now that we have our two divs side by side, let's apply some jQuery magic. To do that, Let's include our jQuery files in the <HEAD> of our document:

<link href="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8/themes/base/jquery-ui.css" rel="stylesheet" type="text/css"/>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.5/jquery.min.js"></script>
<script src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8/jquery-ui.min.js"></script>

Now that we have the necessary scripts, we can write our function:

<script type="text/javascript">
  $(document).ready(function() {
    $( "#sidebar" ).resizable({      
    });
    $("#sidebar ").bind("resize", function (event, ui) {
            var setWidth = $("#sidebar").width();
            $('#content).width(1224-setWidth);
            $('.menu).width(setWidth-6);
        });
  });
</script>

I know that might seem like an intimidating amount of information, so let's break it down:

   $( "#sidebar" ).resizable({      
   });

This portion simply makes the div with the ID of "sidebar" resizable (which accomplishes 33% of what we want it to do).

   $("#sidebar ").bind("resize", function (event, ui) {

By using the .bind, we are able to trigger other events when #sidebar is called.

            var setWidth = $("#sidebar").width();
            $('#content).width(1224-setWidth);

This is where the magic happens. We're grabbing the current width of #sidebar and subtracting it from the width you want your site to be. This code is what keeps your page stays the same width with only the divs changing sizes.

            $('.menu).width(setWidth-6);

This part of the code that expands the contents in the navigation along with #sidebar.

You can see a working example of iframe-like functionality with jQuery here: http://jqueryui.com/demos/resizable/

The only part you won't find there is the trick to adjust a corresponding div's size to make it grow/shrink with the first ... I had a heck of a time searching that on the web, so hopefully this quick tutorial will help other developers who might be searching for this kind of functionality!

- Cassandra

August 6, 2012

SoftLayer in the Community - Tour de Pink 2012

Every year, SoftLayer commits to raising money and giving support to a number of charities, and SLayers are all encouraged to submit the organizations and causes that are important to them. Not long after coming to work here, I found myself in a position to pitch one of my favorite charities — Tour de Pink — to Lance and the charity team.

Tour de Pink is one of the major fundraising efforts for The Pink Ribbons Project, a Houston based organization that raises money to fight breast cancer through awareness and educational outreach initiatives. The Pink Ribbons Project supports proper screening for the medically under-served and under-insured population in the Greater Houston Area, and Tour de Pink is the first bike ride in Texas solely benefiting breast cancer awareness and education.

I have been involved with the ride since its inception in 2005, and I manage the logistical support for all of the Pink Pit Stops. The first year of the ride, "support" consisted of me and a guy named Bear, my 1995 Ford Ranger pickup truck, a 25' moving truck with a lift, and 400 pounds of ice. By 2011, we had grown the logistics team to nine dedicated people, four route vans, a roamer and 4000 pounds of ice to support the 2000+ riders traveling seven routes.

Last year was Tour de Pink's seventh, and an opportunity opened up for a company to step in as the presenting sponsor for the ride ... After about six months of official employment with SoftLayer, I knew one thing for sure: If you have an idea, a plan or a cause that matters to you, it's your responsibility to take that idea / plan / cause wherever it needs to go to get addressed — whether it's an opportunity to improve a compliance process or a community cause. I stepped up and brought the idea to SoftLayer's CEO.

In true SLayer fashion, he saw how important the cause was to me, and he quickly commitment SoftLayer's support to the 2011 Tour de Pink.

In addition to the a financial commitment, we provided space in our downtown Houston offices for packet stuffing:

Tour de Pink

And the (infamous?) 3-Bars BBQ team towed the smoker down to Houston to cook up some fine "Q" for the annual Tour de Pink Kickoff Party:

Tour de Pink

SoftLayer VP of Business Applications Development DJ Harris even kicked off the opening ceremonies when the ride rolled around!

After an extremely successful 2011, SoftLayer has extended support for Tour de Pink to 2012! This year's ride is scheduled for September 16, and it will starting from and coming back to the Prairie View A&M University campus. While SoftLayer is the major underwriter of this ride, it's still a fundraiser, and that's where the rest of us come in. The monies that go out into the community are raised through registration of individual riders and teams and from their collective fundraising efforts.

If you want to roll with the cool kids (and believe me, SoftLayer IS cool) and you plan on being in the Houston area mid-September, surf on over to www.tourdepink.org and sign up to join us!

I hope to see some of you out on the ride, but until then, may the wind be always at your back ... and 3-Bars for Life!

-Val

Categories: 
August 3, 2012

Work Hard, Prank Hard.

Hard work is nothing new to the SoftLayer staff — we strive for perfection in everything we do. We give ourselves strict deadlines, we always push ourselves to give the best support possible, and we make every effort to go above and beyond. Every now and then, we make sure to go above and beyond when it comes to having fun in the office, too.

I'm sure everyone has seen the 10,000 bouncy ball shower we gave SoftLayer COO Sam Fleitman for his birthday, and if you've been an avid blog reader for a while now, you'll remember the prank retaliation when John Eaves went to Hawaii and posted a picture of himself relaxing on Facebook with the caption 'Happy Truck Day.' After the rest of his team finished unloading and installing the servers that were delivered, they turned their attention to his desk. As you'd probably guess, those two pranks are only the tip of the iceberg.

If you walk through the office on any given day, chances are good that you'll see evidence of little pranks and inside jokes that we all play on each other. Sometimes it's subtle, like when a picture of a famous Canadian pop singer (No ... Not The Mitch) is posted by a coworkers desk:

SoftLayer Office

Sometime it's a little more ... obvious:

SoftLayer Office

Pretty recently, I returned to my desk to find my UFC fighters and Jersey Shore bobblehead action figures rearranged:

SoftLayer Office

Those innocent little pranks tend to get the wheels turning in the heads of the office pranksters, though: "What could be the next big office prank?" An anonymous group of SoftLayer employees heard that DAL05 Site Manager Joshua Daley (who led this DC tour) was going out of town for a couple of weeks, so he became the next target. Out of nowhere, someone came up with the genius idea of remodeling his office in Hello Kitty style, and that got the ball rolling. Soon enough, Post-it notes were worked into the plan, and somehow, it was decided that 1,000 inflated balloons would be involved.

The prank involved a significant amount of work, and it wouldn't have come together without an impressive group effort. Many technicians stayed after their shift and came in on their day off to help plan, decorate and blow up balloons, and the result was pretty impressive:

SoftLayer Office

SoftLayer Office

When Josh got back, he got a kick out the prank, and I think he had a little too much fun destroying all of our hard work:

The aftermath:

SoftLayer Office

If you walk through the office and notice a few technicians with shifty eyes, they're probably either keeping an eye out for pranksters that might be targeting them or scheming on their next prank victim. Speaking of which, I have some scheming to do ...

-Timothy

August 2, 2012

Meet Memcached: A Developer's Best Friend

Whether you're new to software development or you've been a coder since the punchcard days, at some point, you've probably come across horrendous performance problems with your website or scripts. From the most advanced users — creating scripts so complex that their databases flooded with complex JOINs — to the novice users — putting SQL calls in loops — database queries can be your worst nightmare as a developer. I hate to admit it, but I've experienced some these nightmares first-hand as a result of some less-than-optimal coding practices when writing some of my own scripts. Luckily, I've learned how to use memcached to make life a little easier.

What is Memcached?

Memcached is a free and open source distributed memory object caching system that allows the developer to store any sort of data in a temporary cache for later use, so they don't have to re-query it. By using memcached, a tremendous performance load can be decreased to almost nil. One of the most noteworthy features of the system is that it doesn't cache EVERYTHING on your site/script; it only caches data that is sure to be queried often. Originally developed in 2003 by Brad Fitzpatrick to improve the site performance of LiveJournal.com, memcached has grown tremendously in popularity, with some of the worlds biggest sites — Wikipedia, Flickr, Twitter, YouTube and Craigslist — taking advantage of the functionality.

How Do I Use Memcache?

After installing the memcached library on your server (available at http://memcached.org/), it's relatively simple to get started:

<?php
  // Set up connection to Memcached
  $memcache = new Memcached();
  $memcache->connect('host', 11211) or die("Could not connect");
 
  // Connect to database here
 
  // Check the cache for your query
  $key = md5("SELECT * FROM memcached_test WHERE id=1");
  $results = $memcache->get($key);
 
  // if the data exists in the cache, get it!
  if ($results) {
      echo $results['id'];
      echo 'Got it from the cache!';
  } else {
    // data didn't exist in the cache
    $query = "SELECT * FROM memcached_test WHERE id=1");
  $results = mysql_query($query);
  $row = mysql_fetch_array($results);
  print_r($row);
 
  // though we didn't find the data this time, cache it for next time!
  $memcache->set($key, $row, TRUE, 30); 
  // Stores the result of the query for 30 seconds
  echo 'In the cache now!';
 
  }
 
?>

Querying the cache is very similar to querying any table in your database, and if that data isn't cached, you'll run a database query to get the information you're looking for, and you can add that information to the cache for the next query. If another query for the data doesn't come within 30 seconds (or whatever window you specify), memcached will clear it from the cache, and the data will be pulled from the database.

So come on developers! Support memcached and faster load times! What other tools and tricks do you use to make your applications run more efficiently?

-Cassandra

Pages

Subscribe to executive-blog