Posts Tagged 'Development'

May 11, 2016

Adventures in Bluemix: Migrating to MQ Light

One of my pet projects at SoftLayer is looking at a small collection of fancy scripts that scan through all registered Internet domain names to see how many of them are hosted on SoftLayer’s infrastructure. There are a lot of fun little challenges involved, but one of the biggest challenges is managing the distribution of work so that this scan doesn’t take all year. Queuing services are great for task distribution, and for my initial implementation I decided to give running a RabbitMQ instance a try, since at the time it was the only queuing service I was familiar with. Overall, it took me about a week and one beefy server to go from “I need a queue,” to “I have a queue that is actually doing what I need it to.”

While what I had set up worked, looking back, there is a lot about RabbitMQ that I didn’t really have the time to figure out properly. Around the time I finished the first run of this project, Bluemix announced that its MQLight service would allow connections from non-Bluemix resources. So when I got some free time, I decided to move the project to a Bluemix-hosted MQ Light queue, and take some notes on how the migration went.

Project overview

To better understand how much work was involved, let me quickly explain how the whole “scanning through every registered domain for SoftLayer hosted domains” thing works.

There are three main moving parts in the project:

  1. The Parser, which is responsible for reading through zone files (which are obtained from the various registrars), filtering out duplicates, and putting nicely formatted domains into a queue.
  2. The Resolver, which is responsible from taking the nicely formatted domains from queue #1, looking up the domain’s IP address, and putting the result into queue #2.
  3. The Checker, which takes the domains from queue #2, checks to see if the domains’ IPs belong to SoftLayer or not, and saves the result in a database.

Each queue entry is a package of about 500 domains, which is roughly 200Kb of text data consisting of the domain and some meta-data that I used to see how well everything was performing. There are around 160 million domains I need to review, and resolving a single domain can take anywhere from .001 seconds to four seconds, so being able to push domains quickly through queues is very important.

Things to be aware of

Going into this migration, I made a lot of assumptions about how things worked that caused me grief. So if you are in a similar situation, here is what I wish someone had told me.

AMQP 1.0: MQLight implements the AMQP 1.0 protocol, which is great, because it is the newest and greatest. As everyone knows, newer is usually better. The problem is that my application was using the python-pika library to connect to RabbitMQ, both of which implement AMQP 0.9, which isn’t fully compatible with AMQP 1.0. The Python library I was using gave me a version error when trying to connect to MQ Light. This required a bit of refactoring of my code in order to get everything working properly. The core ideas are the same, but some of the specific API calls are slightly different.

Persistence: Messages sent to a MQ Light queue without active subscribers will be lost, which took me a while to figure out. The UI indicates when this happens, so this is likely just a problem of me not reading the documentation properly and assuming MQ Light worked like RabbitMQ.

Messages sent to a MQLight queue without active subscribers will be lost.

Threads: The python-mqlight library uses threads fairly heavily, which is great for performance, but it makes programming a little more thought intensive. Make sure you wait for the connection to initialize before sending any messages, and make sure all your messages have been sent in before exiting.

Apache Proton: MQ Light is built on the Apache Qpid Proton project, and the Python library python-mqlight also uses this.

Setting up MQ Light

Aside from those small issues I mentioned, MQ Light was really easy to set up and start using, especially when compared to running my own RabbitMQ instance.

MQLight was really easy to set up and start using, especially when compared to running my own RabbitMQ instance.

  1. Set up the MQ Light Service in Bluemix.
  2. Install the python-mqlight library (or whatever library supports your language of choice). There are a variety of MQ Light Libraries.
  3. Try the send/receive examples.
  4. Write some code.
  5. Watch the messages come in, and profit.

That’s all there is to it. As a developer, the ease with which I can set up services to try is one of the best things about Bluemix, with MQ Light making a great addition to its portfolio of services.

Some real numbers

After I re-factored my code to be able to use either the pika or python-mqlight libraries interchangeably, I ran a sample set of data through each library to see what impact they had on overall performance, and I was pleasantly surprised to see the results.

Doing a full run-through of all domains would take about seven hours, so I ran this test with only 10,364 domains. Below are the running times for each section, in seconds.

Local RabbitMQ

This server was running on a 4 core, 49G Ram VSI.

Parser: 0.054s

Resolver: 90.485s

Checker: 0.0027s

Bluemix MQLight

Parser: 1.593s

Resolver: 86.756s

Checker: 6.766s

Since I am using the free, shared tier of MQ Light, I was honestly expecting much worse results. Having only a few seconds increase in runtime was a really big win for MQ Light.

Overall, I was very pleased working with MQ Light, and I highly suggest it as a starting place for anyone wanting to check out queuing services. It was easy to set up, free to try out, and pretty simple once I started to understand the basics.


March 24, 2016

future.ready(): 7 Things to Check Off Your Big Data Development List

Frank Ketelaars, Big Data Technical Leader for Europe at IBM, offers a checklist that every developer should have pinned to their board when starting a big data project. Editor’s Note: Does your brain switch off when you hear industryspeak words like “innovation,” “transformation,” “leading edge,” “disruptive,” and “paradigm shift”? Go on, go ahead and admit it. Ours do, too. That’s why we’re launching the future.ready() series—consisting of blogs, podcasts, webinars, and Twitter chats— with content created by developers, for developers. Nothing fluffy, nothing buzzy. With the future.ready() series, we aim to equip you with tools and knowledge that you can use—not just talk and tweet about.

For the first edition, I’ve invited Frank Ketelaars, an expert in high volume data space, to walk us through seven things to check off when starting a big data development project.

-Michalina Kiera, SoftLayer EMEA senior marketing manager


This year, big data moves from a water cooler discussion to the to-do list. Gartner estimates that more than 75 percent of companies are investing or planning to invest in big data in the next two years.

I have worked on multiple high volume projects in industries that include banking, telecommunications, manufacturing, life sciences, and government, and in roles including architect, big data developer, and streaming analytics specialist. Based on my experience, here’s a checklist I put together that should give developers a good start. Did I miss anything? Join me on the Twitter chat or webinar to share your experience, ask questions, and discuss further. (See details below.)     

1. Team up with a person who has a budget and a problem you can solve.

For a successful big data project, you need to solve a business problem that’s keeping somebody awake at night. If there isn’t a business problem and a business owner—ideally one with a budget— your project won’t get implemented. Experimentation is important when learning any new technology. But before you invest a lot of time in your big data platform, find your sponsor. To do so, you’ll need to talk to everyone, including IT, business users, and management. Remember that the technical advantages of analytics at scale might not immediately translate into business value.

2. Get your systems ready to collect the data.

With additional data sources, such as devices, vehicles, and sensors connected to networks and generating data, the variety of information and transportation mechanisms has grown dramatically, posing new challenges for the collection and interpretation of data.

Big data often comes from sources outside the business. External data comes at you in a variety of formats (including XML, JSON, and binary), and using a variety of different APIs. In 2016, you might think that everyone is on REST and JSON, but think again: SOAP still exists! The variety of the data is the primary technical driver behind big data investments, according to a survey of 402 business and IT professionals by management consultancy NewVantage Partners[SM1] . From one day to the next, the API might change or a source might become unavailable.

Maybe one day we’ll see more standardization, but it won’t happen any time soon. For now, developers must plan to spend time checking for changes in APIs and data formats, and be ready to respond quickly to avoid service interruptions. And to expect the unexpected.

3. Make sure you have the right to use that data.

Governance is a business challenge, but it’s going to touch developers more than ever before—from the very start of the project. Much of the data they will be handling is unstructured, such as text records from a call center. That makes it hard to work out what’s confidential, what needs to be masked, and what can be shared freely with external developers. Data will need to be structured before it can be analyzed, but part of that process includes working out where the sensitive data is, and putting measures in place to ensure it is adequately protected throughout its lifecycle.

Developers need to work closely with the business to ensure that they can keep data safe, and provide end users with a guarantee that the right data is being analyzed and that its provenance can be trusted. Part of that process will be about finding somebody who will take ownership of the data and attest to its quality.

4. Pick the right tools and languages.

With no real standards in place yet, there are many different languages and tools used to collect, store, transport, and analyze big data. Languages include R, Python, Julia, Scala, and Go (plus the Java and C++ you might need to work with your existing systems). Technologies include Apache Pig, Hadoop, and Spark, which provide massive parallel processing on top of a file system without Hadoop. There’s a list of 10 popular big data tools here, another 12 here, and a round-up of 45 big data tools here. 451 Research has created a map that classifies data platforms according to the database type, implementation model, and technology. It’s a great resource, but its 18-color key shows how complex the landscape has become.

Not all of these tools and technologies will be right for you, but they hint at one way the developer’s core competency must change. Big data will require developers to be polyglots, conversant in perhaps five languages, who specialize in learning new tools and languages fast—not deep experts in one or two languages.

Nota bene: MapReduce and Pig are among the top highest paid technology skills in the US, and other big data skills are likely to be highly sought-after as the demand for them also grows. Scala is a relatively new functional programming language for data preparation and analysis, and I predict it will be in high demand in the near future.

5. Forget “off-the-shelf.” Experiment and set up a big data solution that fits your needs. 

You can think of big data analytics tools like Hadoop as a car. You want to go to the showroom, pay, get in, and drive away. Instead, you’re given the wheels, doors, windows, chassis, engine, steering wheel, and a big bag of nuts and bolts. It’s your job to assemble it.

As InfoWorld notes, DevOps tools can help to create manageable Hadoop solutions. But you’re still faced with a lot of pieces to combine, diverse workloads, and scheduling challenges.

When experimenting with concepts and technologies to solve a certain business problem, also think about successful deployment in the organization. The project does not stop after the proof.

6. Secure resources for changes and updates.

Apache Hadoop and Apache Spark are still evolving rapidly and it is inevitable that the behavior of components will change over time and some may get deprecated shortly after initial release. Implementing new releases will be painful, and developers will need to have an overview of the big data infrastructure to ensure that as components change, their big data projects continue to perform as expected.

The developer team must plan time for updates and deprecated features, and a coordinated approach will be essential for keeping on top of the change.

7. Use infrastructure that’s ready for CPU and I/O intensive workloads.

My preferred definition of big data (and there are many – Forbes found 12) is this: "Big data is when you can no longer afford to bring the data to the processing, and you have to do the processing where the data is."

In traditional database and analytics applications, you get the data, load it onto your reporting server, process it, and post the results to the database.

With big data, you have terabytes of data, which might reside in different places—and which might not even be yours to move. Getting it to the processor is impractical. Big data technologies like Hadoop are based on the concept of data locality—doing the processing where the data resides.

You can run Hadoop in a virtualized environment. Virtual servers don’t have local data, though, so the time taken to transport data between the SAN or other storage device and the server hurts the application’s performance. Noisy neighbors, unpredictable server speeds and contested network connections can have a significant impact on performance in a virtualized environment. As a result, it’s difficult to offer service level agreements (SLAs) to end users, which makes it hard for them to depend on your big data implementations.

The answer is to use bare metal servers on demand, which enable you to predict and guarantee the level of performance your application can achieve, so you can offer an SLA with confidence. Clusters can be set up quickly, so you can accelerate your project really fast. Because performance is predictable and consistent, it’s possible to offer SLAs to business owners that will encourage them to invest in the big data project and rely on it for making business decisions.

How can I learn more?

Join me in the Twitter chat and webinar (details below) to discuss how you’re addressing big data or have your questions answered by me and my guests.  

Add our Twitter chat to your calendar. It happens Thursday, March 31 at 1 p.m. CET. Use the hashtag #SLdevchat to share your views or post your questions to me.

Register for the webinar on Wednesday, Apr 20, at 5 p.m. to 6 p.m. CET.


About the author

Frank Ketelaars has been Big Data Technical Leader in Europe for IBM since August 2013. As an architect, big data developer, and streaming analytics specialist, he has worked on multiple high volume projects in banking, telecommunications, manufacturing, life sciences and government. He is a specialist in Hadoop and real-time analytical processing.


March 4, 2016

Adventures with Bluemix

Keeping up with the rapid evolution of web programming is frighteningly difficult—especially when you have a day job. To ensure I don’t get left behind, I like to build a small project every year or so with a collection of the most buzzworthy technologies I can find. Nothing particularly impressive, of course, but just a collection of buttons that do things. This year I am trying to get a good grasp on “as a Service,” which seems to be everywhere these days. Hopefully this adventure will prove educational.

Why use services when I can do it myself?

The main idea behind “as a Service” is that somewhere out there in the cloud, someone has figured out how to do a particular task really well. This someone is willing to provide you access to that for a small service fee—thereby letting you, the developer, focus as much time as possible on your code and not so much time worrying about optimal configurations of things that you need to work efficiently.

SoftLayer is an Infrastructure as a Service (IaaS) provider, which is what will be the home for my little application—due in large part because I already have a ton of experience running servers myself.

I’m a big fan of Python, so I’m going to start programing with the Pyramids framework as the base for my new application. Like the “as a Service” offerings, programming frameworks and libraries exist to help the developer focus on their code and leverage the expertise of others for the auxiliary components.

To make everything pretty, I am going to use Bootstrap.js, which is apparently the de facto front-end library these days.

For everything else I want to use, there will be an attached Bluemix service. For the uninitiated, Bluemix is a pretty awesome collection of tools for developing and deploying code. At its core, Bluemix uses Cloud Foundry to provision cloud resources and deploy code. For now, I’m going to deploy my own code, but what I’m really interested in are the add-on services that I can just drop into my application and get going. The first service I want to try out is going to be Cloudant nosql, which is a managed couchDB instance with a few added features like a pretty neat dashboard.

Welcome to Bluemix

Combining Bluemix services with SoftLayer servers

One of the great things about services in Bluemix is that they can be provisioned in a standalone deployment—meaning Bluemix services can be used by any computer with an Internet connection and therefore, so can my SoftLayer servers. Since Bluemix services are deployed on SoftLayer hardware (in general, but there are some exceptions), the latency between SoftLayer servers and Bluemix services should be minimal, which is nice.

Creating a Cloudant service in Bluemix is as easy as hitting the Create button in the console. Creating a simple web application in Pyramid took a bit longer, but the quick tutorial helped me learn about all the cool things the Pyramid project can do. I also got to skip all the mess with SQLAlchemy, since I’m storing all the data in Cloudant. All that’s required is a sane ID system (I am using uuid) and some json. No need to get bogged down with a rigid table structure since Cloudant is a document store. If I want to change the data format, I just need to upload a new copy of the data, and a new revision of that document will be automatically created.

After cobbling together a basic application that can publish and edit content, all I had to do to make everything look like it was designed intentionally was to add a few bootstrap classes to my templates. And then I had a ready to use website!


Although making a web application is still as intensive as it’s always been, at least using technology in an “as a Service” fashion helps cut down on all the tertiary technologies you need to become an expert on to get anything to work. Even though the application I created here was pretty simple, I hope to expand it to include some of the more interesting Bluemix services to see what kind of Frankenstein application I can manage to produce. There are currently 100 Bluemix services, so I think the hardest part is going to be figuring out which one to use next.


October 20, 2015

What’s in a hypervisor? More than you think

Virtualization has always been a key tenet of enabling cloud-computing services. From the get-go, SoftLayer has offered a variety of options, including Citrix XenServer, Microsoft Hyper-V, and Parallels Cloud Server, just to name a few. It’s all about enabling choice.

But what about VMware—the company that practically pioneered virtualization, making it commonplace?

Well, we have some news to share. SoftLayer has always supported VMware ESX and ESXi—your basic, run-of-the mill hypervisor—but now we’re enabling enterprise customers to run VMware vSphere on our bare metal servers.

This collaboration is significant for SoftLayer and IBM because it gives our customers tremendous flexibility and transparency when moving workloads into the public cloud. Enterprises already familiar with VMware can easily extend their existing on-premises VMware infrastructure into the IBM Cloud with simplified, monthly pricing. This makes transitioning into a hybrid model easier because it results in greater workload mobility and application continuity.

But the real magic happens when you couple our bare metal performance with VMware vSphere. Users can complete live workload migrations between data centers across continents. Users can easily move and implement enterprise applications and disaster recovery solutions across our global network of cloud data centers—with just a few clicks of a mouse. Take a look at this demo and judge for yourself.

What’s in a hypervisor? For some, it’s an on-ramp to the cloud and a way to make hybrid computing a reality. When you pair the flexibility of VMware with our bare metal servers, users get a combination that’s hard to beat.

We’re innovating to help companies make the transition to hybrid cloud, one hypervisor at a time. For more details, visit

-Jack Beech, VP of Business Development

April 27, 2015

Good Documentation: A How-to Guide

As part of my job in Development Support, I write internal technical documentation for employee use only. My department is also the last line of support before a developer is called in for customer support issues, so we manage a lot of the troubleshooting documentation. Some of the documentation I write and use is designed for internal use for my position, but some of it is troubleshooting documents for other job positions within the company. I have a few guidelines that I use to improve the quality of my documentation. These are by no means definitive, but they’re some helpful tips that I’ve picked up over the years.


I’m sure everyone has met the frustration of reading a long-winded sentence that should have been three separate sentences. Keeping your sentences as short as possible helps ensure that your advice won’t go in one ear and out the other. If you can write things in a simpler way, you should do so. The goal of your documentation is to make your readers smarter.

Avoid phrasing things in a confusing way. A good example of this is how you employ parentheses. Sometimes it is necessary to use them to convey important beneficial tidbits to your readers. If you write something with parentheses in it, and you can’t read it out loud without it sounding confusing, try to re-word it, or run it by someone else.

Good: It should have "limited connectivity" (the computer icon with the exclamation point) or "active" status (the green checkmark) and NOT "retired" (the red X).
Bad: It should have the icon “limited connectivity” (basically the computer icon with the exclamation point that appears in the list) (you can see the “limited connectivity” text if you hover over it) or “active” (the green checkmark) status and NOT the red “retired” X icon.

Ideally, you should use the same formatting for all of your documentation. At the very least, you should make your formatting consistent within your document. All of our transaction troubleshooting documentation at SoftLayer uses a standardized error formatting that is consistent and easy to read. Sometimes it might be necessary to break the convention if readability is improved. For example: Collapsible menus make it hard to search the entire page using ctrl+F, but very often, it makes things more difficult.

And finally, if people continually have a slew of questions, it’s probably time to revise your documentation and make it clearer. If it’s too complex, break it down into simpler terms. Add more examples to help clarify things so that it makes sense to your end reader.


Use bullet points or numbered lists when listing things instead of a paragraph block. I mention this because good formatting saves man-hours. There’s a difference between one person having to search a document for five minutes, versus 100 people having to search a document for five minutes each. That’s over eight man-hours lost. Bullet points are much faster to skim through when you are looking for something specific in the middle of a page somewhere. Avoid the “TL;DR” effect and don’t send your readers a wall of text.

Avoid superfluous information. If you have extra information beyond what is necessary, it can have an adverse effect on your readers. Your document may be the first your readers have read on your topic, so don’t overload them with too much information.

Don’t create duplicate information. If your documentation source is electronic, keep your documentation from repeating information, and just link to it in a central location. If you have the same information in five different places, you’ll have to update it in five different places if something changes.

Break up longer documents into smaller, logical sections. Organize your information first. Figure out headings and main points. If your page seems too long, try to break it down into smaller sections. For example, you might want to separate a troubleshooting section from the product information section. If your troubleshooting section grows too large, consider moving it to its own page.


Don’t make assumptions about what the users already know. If it wasn’t covered in your basic training when you were hired, consider adding it to the documentation. This is especially important when you are documenting things for your own job position. Don’t leave out important details just because you can remember them offhand. You’re doing yourself a favor as well. Six months from now, you may need to use your documentation and you may not remember those details.

Bad:SSH to the image server and delete the offending RGX folder.
Good:SSH to the image server (imageserver.mycompany.local), and run ls -al /dev/rgx_files/ | grep blah to find the offending RGX folder and then use rm -rf /dev/rgx_files/<folder> to delete it.

Make sure your documentation covers as much ground as possible. Cover every error and every possible scenario that you can think of. Collaborate with other people to identify any areas you may have missed.

Account for errors. Error messages often give very helpful information. The error might be as straightforward as “Error: You have entered an unsupported character: ‘$.’” Make sure to document the cause and fix for it in detail. If there are unsupported characters, it might be a good idea to provide a list of unsupported characters.

If something is confusing, provide a good example. It’s usually pretty easy to identify the pain points—the things you struggle with are probably going to be difficult for your readers as well. Sometimes things can be explained better in an example than they can in a lengthy paragraph. If you were documenting a command, it might be worthwhile to provide a good example first and then break it down and explain it in detail. Images can also be very helpful in getting your point across. In documenting user interfaces, an image can be a much better choice than words. Draw red boxes or arrows to guide the reader on the procedure.


January 27, 2015

Hello, IBM Bluemix!

Developers, if you'd prefer to focus on building new applications instead of customizing your own unique cloud infrastructure, IBM Bluemix provides building blocks to rapidly develop and deploy applications on the Platform as a Service (PaaS) level to make life easier for you. It’s an ecosystem of services based on Cloud Foundry, an open source project designed to make deploying and scaling an application as simple as possible. Leveraging an existing project like this is a large part of what makes Bluemix so easy to use.

Bluemix integrates with Jazz, IBM’s DevOps service, to help manage code, plan versions and release, and actually push code to production. You can still use it with your github projects, so no worries there.

And as a SoftLayer customer (or potential customer), you can rest assured that Bluemix projects can run on SoftLayer’s hardware and network.

Core Ideas

The Application
This is your code. Bluemix comes with a number of predefined buildpacks to get your language of choice up and running quickly, but you will still need to actually develop your application. Bluemix hasn’t solved that problem yet.
A buildpack is a collection of scripts designed to set up your container and all of the application dependencies. If Bluemix doesn’t have a buildpack that suits your needs, you can always create your own. Extending a buildpack is pretty easy. Simply clone an existing one to use as a base, make your changes, commit it to your github repo, and then tell Bluemix about it so it can build your application properly.
Bluemix has a long list of services you can bind to your application. Instead of making a MySQL server yourself, you can just bind the MySQL service to your application and start coding. Along with many of the standard services expected from a CloudFoundry project, there are also some IBM specific ones, like Watson as a service. While I haven’t had the time to learn about Watson personally, everyone I talk to says it’s a rather neat thing to have on your application.

Getting Started

I recommend reading this tutorial which will get you to a nice “hello world” application. Overall I found that going from “I have no idea what Bluemix is” to “I’ve created my own Bluemix application!” to be a rather pleasant experience.

Creating your first Bluemix project is only a few clicks away. A Bluemix 30 day free trial should give you plenty of time to get an idea if Bluemix is the right fit for you.

Bluemix is absolutely worth checking out. So, what are you waiting for? Give it a go!

- Chris

November 6, 2014

#T4 -Tips and Tricks - Pure CSS Sticky Footers

Who doesn’t like a walk down memory lane? In our #T4 series, SoftLayer brings back popular tech tip blog posts. #ThrowbackThursday #T4 #ThrowbackThursdayTechTips

Sticky footers are still landing developers in, well, sticky situations. Don’t fret—we’ve all been there. We’re bumping our popular Tips and Tricks – Pure CSS Sticky Footers blog post that was originally posted two years ago today!

Our objective is simple: Make the footer of our web page stay at the bottom even if the page's content area is shorter than the user's browser window. We got a LOT of feedback the first time this blog was posted, a lot of you loved it, and some of you brought to my attention that some browser environments didn’t support this method.

For this throwback, I have modified the code (the HTML and the CSS), but as you can see, not by too much, only a few things have changed. This method uses the: after attribute, which in my opinion is a LOT cooler. This should help those of you who could not get the previous method to work as this utilizes more of a modern technique and has a lot more universal compatibility!

So enjoy!

Go from this:

CSS Footer

To this:

CSS Footer

  1. Start by getting the HTML structure in place first:
    <div id="page">
          <div id="header"> </div>
          <div id="main"> </div>
    </div> <!-- /page -->
    <div id="footer"> </div>
  2. Then code the CSS for the full page:
    * {
          margin: 0;
    html, body {
          height: 100%;
  3. Code the rest as:
    #page {
          min-height: 100%;
          margin-bottom: -100px; /* equal to the fixed height of your footer */
    #page:after {
          content: “”;
    #footer, #page:after {
          height: 100px;
  4. For Internet Explorer to not throw a fit, we need concede that IE doesn't recognize min-height as a valid property, so we have to add Height: 100%; to #page:
    #page {
          Min-height: 100%;  /* for all other browsers */
          height: 100%;  /* for IE */

To read my FAVORITE perk of this trick: check out the original post here.

For questions, comments, or just feel like chatting, contact us at


October 23, 2014

CSS3 Tips and Tricks – Mastering Multiple Backgrounds

I’ve written a lot of blog posts, some on our very own SoftLayer Development Network, but most of them have been posted right here on SoftLayer’s main blog. One of the most popular is a tutorial I wrote on being able to create a customized background depending on the user’s location. For example: A person visiting a website from the United States during the daytime may see a beautiful yellow background with an orange glow and a bright yellow sun just above the horizon, while a surfer from China may see the same website, but with a dark purple background with subtle white stars and a shimmering moon because it is night. The example I wrote customized the CSS to the time zone based on locale tailoring the site with a more personal touch.

The demand for sites to serve a more interactive experience has always been large in volume, but few websites actually deliver.

Luckily, our Web languages are evolving all of the time, and since I’ve written the “What time is it for you?” blog on our SLDN, more advancements have been made to the background functionality and browser compatibility. This means MORE browsers support these new features, and it’s compliant across the board!

Let’s start off with our usual HTML document (with an addition of an empty div for now, this is where we’re going to master our background techniques).

    <title>CSS3 Tips and Tricks – Mastering Multiple Backgrounds</title>
    <div class=”slBackgrounds”></div>

With CSS3, we can define multiple backgrounds in one declaration, like this:

background: url('earth.png') no-repeat top 30px center, url('star_bg.png') repeat-y center;

By separating each background with just a comma, we’re able to declare many backgrounds for one div. Let’s go ahead and add our multi-background CSS in the <head> of our document:

    .slBackgrounds {
        width: 300px;
        height: 300px;
        margin: 0 auto;
        background: url('earth.png') no-repeat top 30px center, url('star_bg.png') repeat-y center;
        transition:background-position 600s;
    .slBackgrounds:hover {
        background-position: top 30px center, 0px 60000px;

After adding the CSS styling, you should have something that looks similar to the following:

You’ll notice I added a transition property to the .slBackgrounds class, and I bet you’re wondering why? Everybody has their own learning technique that helps them absorb concepts better and faster than other methods. My learning method (and probably 75 percent of other developers) happens to be the challenge technique: When I learn something new, I think about something extremely fun and challenging that I would like to do with this newfound knowledge beyond just the base use. For instance, why learn how to use multiple backgrounds with CSS3 and just have a five-line blog when we can learn to use multiple backgrounds, AND create an awesome animation sequence that can jazz up the old and boring background system?

Not only does this jazz it up, but by using additions such as the transition and :hover properties, we’re able to open new doors to possibilities with interactivity.

If you haven’t guessed already, the .slBackgrounds:hover section covers what should happen to the .slBackgrounds div when the user hovers over it; in this case, there’s a background-position declaration. The ‘top 30px center’ applies to the first background image, and the ‘0px 60000px’ applies to the second (gotta love multiple backgrounds!).

Go ahead and hover over our images! You should see something like this:

Something pretty simple, but I bet you can already think of a hundred things you can do with the CSS3 multiple background ability, huh? The great news is that the cross-browser compatibility is awesome and supports all newer browsers and most reasonably older ones too! And to think . . . barely five or six years ago it took MUCH more innovative coding and workarounds to achieve results like this without just embedding a flash file or an animated gif!

We’d love to hear how YOU’RE using multiple backgrounds!

- Cassandra

October 16, 2014

#T4 – Tips and Tricks–jQuery Select2

Who doesn’t like a walk down memory lane? In our #T4 series, SoftLayer brings back popular tech tip blog posts. #ThrowbackThursday #T4 #ThrowbackThursdayTechTips

Creating a drop-down menu? Here’s an abridged version of our Tips and Tricks – jQuery Select2 Plugin post from two years ago tomorrow!

Turn your drop-down menu from this:
Option Select

To this:

Pretty Option Select

  1. Download Select2 and upload it to your server.
  2. Add the jQuery library and scripts to the <head> of the page document:
  3. <script src="jquery.js" type="text/javascript"></script> 
    <script src="select2.js" type="text/javascript"></script>
  4. Add Select2's included style sheet:
  5. <link href="/select2.css" rel="stylesheet"/>

  6. Before closing the <head> tag, invoke the Select2 function:
  7. <script>
    $(document).ready(function() { $("#selectPretty").select2(); });
  8. Then add the #selectPretty ID to the select element you want to improve:
    <select id="selectPretty">
    <option value="Option1">Option 1</option>
    <option value="Option2">Option 2</option>
    <option value="Option3">Option 3</option>
    <option value="Option4">Option 4</option>

For questions, comments, or just feel like chatting, contact us at


September 16, 2014

CSS3 Tips and Tricks – Generated Content Without jQuery

If you guys have read any of my past blogs, you know how much I LOVE jQuery, but every good developer knows that if there’s an easier or more efficient way of doing something: DO IT. With all the new developments with CSS3, HTML5, etc. etc., sometimes we have to get back to basics to relearn how to do things more efficiently, so here it goes!

Nearly every website has some form of 2.0/dynamic/generated content nowadays, and if your site doesn’t… well, it probably should catch up! I’ll show you how with some new CSS tricks and how it can reduce a lot of overhead of including the entire jQuery library (which would save you approximately 84kb per page load, assuming you have no other asynchronous/client side functionality you need).

I’ll start off with an easy example, since I know most of you take these examples and let your creativity run wild for your own projects. (Note to self: start a “Code Gone Wild” series.)

Usually this is the part where I say “First, let’s include the jQuery library as always.” Not this time, let’s break the rules!

FIRST, start off your document like any other (with the basic structure, set your DOCTYPE appropriately, i.e. strict vs transitional):

<!DOCTYPE html>

Wow, you can already tell this generated content’s going to be a TON easier than using jQuery (for those of you whom aren’t already jQuery fans).

Now let’s add in a div there; every time we hover over that div, we’re going to display our generated content with CSS. Inside of our div, we’re going to place a simple span, like so:

<!DOCTYPE html>
     <div class=”slisawesome”>
          <span data-title="Hello Cassandra!">What’s my name?</span>

As you can see, the span content contains a simple question and the data-title attribute contains the answer to that question.

Now let’s just make this div a little bit prettier before we get into the fancy stuff.

Add some style to the <head> section of our document:

     .slisawesome  {
          /* Will TOTALLY be making another blog about the cool CSS gradients soon */
          background:linear-gradient(to bottom, #8dd2d9 , #58c0c7);
          padding: 20px;  /* give the box some room to breathe */
          width: 125px;  /* give it a fixed width since we know how wide it should be  */
          margin: 100px auto;  /* move it away from the top of the screen AND center it */
          border: 1px solid black;  /* this is just a little border */
          position: relative;  /* this is to help with our generated content positioning */

Now you should have something that looks like this:

This is good; this is what you should have. Now let’s make the magic happen and add the rest of our CSS3:

     .slisawesome  {
          /* Will TOTALLY be making another blog about the cool CSS gradients soon */
          background:linear-gradient(to bottom, #8dd2d9 , #58c0c7);
          padding: 20px;  /* give the box some room to breathe */
          width: 125px;  /* give it a fixed width since we know how wide it should be  */
          margin: 100px auto;  /* move it away from the top of the screen AND center it */
          border: 1px solid black;  /* this is just a little border */
          position: relative;  /* this is to help with our generated content positioning */
     .slisawesome span::before {
          content:attr(data-title); /* assigning the data-title attribute value to the content */
          opacity: 0; /* hiding data-title until we hover over it */
          position: absolute; /* positioning our data-title content */
          margin-top: 50px; /* putting more space between our question and answer */
          /* Fancy transitions for our data-title when we hover over our question */
          /* which I’m TOTALLY going to write another blog for ;) If you guys want, of course */
          -webkit-transition:opacity 0.4s; /* determines the speed of the transition */
          transition:opacity 0.4s; /* determines the speed of the transition */

Now, right now, your page should still look like this:

That’s okay! We still have ONE more step to go:

     .slisawesome  {
          /* Will TOTALLY be making another blog about the cool CSS gradients soon */
          background:linear-gradient(to bottom, #8dd2d9 , #58c0c7);
          padding: 20px;  /* give the box some room to breathe */
          width: 125px;  /* give it a fixed width since we know how wide it should be  */
          margin: 100px auto;  /* move it away from the top of the screen AND center it */
          border: 1px solid black;  /* this is just a little border */
          position: relative;  /* this is to help with our generated content positioning */
     .slisawesome span::before {
          content:attr(data-title); /* assigning the data-title attribute value to the content */
          opacity: 0; /* hiding data-title until we hover over it */
          position: absolute; /* positioning our data-title content */
          margin-top: 50px; /* putting more space between our question and answer */
          /* Fancy transitions for our data-title when we hover over our question */
          /* which I’m TOTALLY going to write another blog for ;) If you guys want, of course */
          -webkit-transition:opacity 0.4s; /* determines the speed of the transition */
          transition:opacity 0.4s; /* determines the speed of the transition */
     /* Drum Roll --------- Here’s our hover magic */
     .slisawesome span:hover::before{
     /* Okay… that was a little anticlimactic… losing cool points */

Despite my anticlimactic adding of “the magic,” we just added a :hover that will show full opacity when we hover, so refresh your page and try it out! You should see something like this when you hover over THE QUESTION:

Of course you could REALLY start getting fancy with this by adding some php variables for the logged in user, or perhaps make it dynamic to location, time, etc. The possibilities are endless, so go… go and expand on this awesome generated content technique!


Subscribe to development