Posts Tagged ‘developer’

We invite each of our featured SoftLayer Tech Marketplace Partners to contribute a guest post to the SoftLayer Blog, and this week, we’re happy to welcome Mike Lauricella from Plivo. Plivo is an open communications and messaging platform with advanced features, simple APIs, easy management and volume pricing.

Bridging the Gap Between the Web and Telephony

Businesses face a fundamental challenge in the worlds of telephony and messaging: Those worlds move too slowly, require too much telecom knowledge and take too long to adopt. As a result, developers often forgo phone and SMS functionality in their applications because the learning curves are so steep, and the dated architecture seems like a foreign language. Over the last twenty years, the web has evolved a lot faster than telephony, and that momentum only widens the gap between the “old” telecom world and the “new” Internet world. Plivo was created to bridge that gap and make telephony easy for developers to understand and incorporate into their applications with simple tools and APIs.

I could bore you to tears by describing the ins and outs of what we’ve learned about telephony and telecom since Plivo was founded, but I’d rather show off some of the noteworthy ways our customers have incorporated Plivo in their own businesses. After all, seeing those real-world applications is much more revealing about what Plivo does than any description of the nuts and bolts of our platform, right?

Conferencing Solution
The purest use-cases for Plivo are when our customers can simply leverage powerful telephony functionality. A perfect example is a conferencing solution one of our customers created to host large-scale conferences with up to 200 participants. The company integrated the solution into their product and CRM so that sales reps and customers could jump on conference calls quickly. With that integration, the executive management team can keep track of all kinds of information about the calls … whether they’re looking to find which calls resulted in closed sales or they just want to see the average duration of a conference call for a given time frame.

Call Tracking
Beyond facilitate conference calls quickly and seamlessly, many businesses have started using Plivo’s integration to incorporate call tracking statistics in their environments. Call tracking is big business because information about who called what number, when they called, how long they talked and the result of the call (sale, no sale, follow up) can determine whether the appropriate interaction has taken place with prospects or customers.

Two Factor Authentication
With ever-increasing concerns about security online, we’ve seen a huge uptick in developers that come to Plivo for help with two factor authentication for web services. To ensure that a new site registrant is a real person who has provided a valid phone number (to help cut down on potential fraud), they use Plivo to send text messages with verification codes to those new registrant.

Mass Alert Messaging
Because emergencies can happen at any time, our customers have enlisted Plivo’s functionality to send out mass alerts via phone calls and SMS messages when their customers are affected by an issue and need to be contacted. These voice and text messages can be sent quickly and easily with our automated tools, and while no one ever wants to deal with an emergency, having a solid communication lifeline provides some peace of mind.

WebRTC
An emerging new standard for communications is WebRTC — open project that enables web browsers with Real-Time Communications (RTC) capabilities. WebRTC make communications a feature of the Web without plugins or complex SIP clients. Plivo already supports WebRTC, and even though the project is relatively young, it’s already being used in some amazing applications.

These use-cases are only the tip of the iceberg when it comes to how our customers are innovating on our platform, but I hope it helps paint a picture of the kinds of functionality Plivo enables simply and quickly. If you’ve been itching to incorporate telephony into your application, before you spending hours of your life poring over complex telecom architecture requirements, head over to plivo.com to see how easy we can make your life. We offer free developer accounts where you can start to make calls to other Plivo users and other SIP endpoints immediately, and we’d love to chat with you about how you can leverage Plivo to make your applications communicate.

If you have any questions, feel free to drop us a note at hello@plivo.com, and we’ll get back to you with answers.

-Mike Lauricella, Plivo

By now, if you’ve seen my other blog posts, you know that I’m fascinated with how much JavaScript has evolved and how much you can do with jQuery these days. I’m an advocate of working smarter, not harder, and that maxim knows no coding language limits. In this post, I want to share a pure CSS solution that allows for “sticky” footers on a web page. In comparing several different techniques to present this functionality, I found that all of the other routes were overkill when it came to processing time and resource usage.

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.

This, by far, is one of my *favorite* things to do. It makes the web layout so much more appealing and creates a very professional feel. I ended up kicking myself the very first time I tried to add this functionality to a project early in my career (ten years ago … already!?) when I found out just how easy it was. I take solace in knowing that I’m not alone, though … A quick search for “footer stick bottom” still yields quite a few results from fellow developers who are wrestling with the same frustrating experience I did. If you’re in that boat, fear no more! We’re going to your footers in shape in a snap.

Here’s a diagram of the problem:

Unfortunately, a lot of people try to handle it with setting a fixed height to the content which would push the footer down. This may work when YOU view it, but there are several different browser window heights, resolutions and variables that make this an *extremely* unreliable solution (notice the emphasis on the word “extremely” … this basically means “don’t do it”).

We need a dynamic solution that is able to adapt on the fly to the height of a user’s browser window regardless if the resize it, have Firebug open, use a unique resolution or just have a really, really weird browser!

Let’s take a look at what the end results should look like:

To make this happen, let’s get our HTML structure in place first:

<div id="page">
 
      <div id="header"> </div>
 
      <div id="main"> </div>
 
      <div id="footer"> </div>
 
</div>

It’s pretty simple so far … Just a skeleton of a web page. The page div contains ALL elements and is immediately below the tags in the page code hierarchy. The header div is going to be our top content, the main div will include all of our content, and the footer div is all of our copyrights and footer links.

Let’s start by coding the CSS for the full page:

Html, body {
      Padding: 0;
      Margin: 0;
      Height: 100%;
}

Adding a 100% height allows us to set the height of the main div later. The height of a div can only be as tall as the parent element encasing it. Now let’s see how the rest of our ids are styled:

#page {
      Min-height: 100%;
      position:relative;
}
 
#main {
      Padding-bottom: 75px;   /* This value is the height of your footer */
}
 
#footer {
      Position: absolute;
      Width: 100%;
      Bottom: 0;
      Height: 75px;  /* This value is the height of your footer */
}

These rules position the footer “absolutely” at the bottom of the page, and because we set #page to min-height: 100%, it ensures that #main is exactly the height of the browser’s viewing space. One of the best things about this little trick is that it’s compliant with all major current browsers — including Firefox, Chrome, Safari *AND* Internet Explorer (after a little tweak). 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 */
      position:relative;
}

If the user does not have a modern, popular browser, it’s still okay! Though their old browser won’t detect the magic we’ve done here, it’ll fail gracefully, and the footer will be positioned directly under the content, as it would have been without our little CSS trick.

I can’t finish this blog without mentioning my FAVORITE perk of this trick: Should you not have a specially designed mobile version of your site, this trick even works on smart phones!

-Cassandra

In the late 90′s, web pages presented their information in a relatively structured fashion, with little concern on how “pretty” the content looked. To a certain extent, that was a result of available technology and resources being a little more limited, but much of the reason was probably because we had no idea what was possible. We’ve come a long way, my friend. These days, it’s tough to spend an hour online without coming across a gorgeous web site with huge animations, a pallet of every color possible, full-width backgrounds and high definition detail.

Those sites may be aesthetically pleasing, but they can be a big pain from a developer’s perspective.

How much load does all of that stuff put on the server every time that web page is visited? As developers, it’s our job to think about both what the visitor sees AND the visitor’s experience in seeing it. Even the most beautiful sites will be ignored if a page takes too long to load. We spend hours optimizing every detail so users can fluidly browse without having to wait. It was in one of these optimization sessions that I discovered “lazy load.”

To be honest, I wasn’t too fond of the word “lazy” in the name, and I especially wasn’t fond of having to explain to my boss that *I* wasn’t being lazy … The jQuery plugin is *named* “Lazy Load.” Lazy Load effectively allows large pieces of content to stay in the backlog until they’re needed. To give you an example of what that looks like, let’s say you have a website with three humungous images, but they’re all in different locations. Instead of pushing the entire load onto the user when they first land on your page, we can break them up and have them load only when the user goes to view them. We’re not reducing the size of the web page; we’re merely helping it work smarter.

Without Lazy Load, a normal web page loads each item when its page is visited. If a website has videos, music, images and some neat user interactivity applications, each of those items will load at the same time:

If you take into consideration how large each of those items are, you can sense the problem. The user only has so much bandwidth to load these items, and something’s gotta give. Usually, it means long loading times. We can’t control how fast each user’s ISP is, but we can reorder our items and let Lazy Load help us prioritize items and load the page more efficiently.

After we snag Lazy Load on Github (jquery.lazyload.js), we put our jQuery scripts in the <head> of our page:

<script src="jquery.js" type="text/javascript"></script> 
<script src="jquery.lazyload.js" type="text/javascript"></script>

Now that the plugin is available to us, we need to determine what we want to load lazily. Images are probably one of the most bothersome page elements, so let’s apply Lazy Load to the images we load in the belazy class. In the <head> of your page (or in the footer if you prefer your JavaScript entries there), you’ll add:

<script type="text/javascript">$("img.belazy").lazyload();</script>

As a result of that function, all image tags with a class of belazy will have Lazy Load run on them. This helps us ensure that we’re not loading ALL of our images lazily. Now we need to choose which images we want to apply Lazy Load to.

Let’s say the image tag of the largest image on one of our page looks like this:

<img src="bighonkingimage.png"/>

To have the lazyload function apply to it, we just have to make a couple tweaks:

<img class="belazy" src="bighonkingimage.png" data-original="bighonkingimage.png"/>

We added class="belazy" to trigger the lazyload function, and we added data-original="bighonkingimage.png" to line up with the formatting required by the newest version of Lazy Load (it’s simply a repeat of the source).

When a user visits our page, bighonkingimage.png will load only when it’s needed!

Pretty neat, eh?

-Cassandra

Simple Object Access Protocol (SOAP) is built on server-to-server remote procedure calls over HTTP. The data is formatted as XML; this means secure, well formatted data will be sent and received from SoftLayer’s API. This may take a little more time to set up than the REST API but it can be more scalable as you programmatically interface with it. SOAP’s ability to tunnel through existing protocols such as HTTP and innate ability to work in an object-oriented structure make it an excellent choice for interaction with the SoftLayer API.

This post gets pretty technical and detailed, so it might not appeal to our entire audience. If you’ve always wondered how to get started with SOAP API development, this post might be a good jumping-off point.

Read the full SOAP API Application Development post! »

I recently bought a new computer for my wife. Being a developer, and a former hardware engineering student, I opted the buy the parts and assemble the machine ourselves. Actually assembling a computer these days doesn’t take too long, it’s the software that really gets you. Windows security updates, driver packs, incompatibilities, inconsistencies, broken websites, and just plain bad code plagued me for most of the night. The video card, in particular, has a “known issue” where it just “uh-oh” turns off the monitor when Windows starts. The issue was first reported in March of 2006, and has yet to be fixed.

This is why SoftLayer always tests and verifies the configurations we offer. We don’t make the end user discover on their own that Debian doesn’t work on Nehalems, we install it first to be sure. This is also why our order forms prevent customers from ordering pre-installed software that are incompatible with any of the rest of the order. We want to make sure that customers avoid the frustration of ordering things only to find out later that they don’t work together.

The problem with desktop computers, especially for people who are particular about their configurations, is that you cannot buy a pre-configured machine where all the parts are exactly what you want. We attempted to get a computer from Dell, and HP, but neither company would even display all the specifications we were interested in, nevermind actually having the parts we desired. Usually pre-built systems skimp on important things like the motherboard or the power supply, giving you very little room to upgrade.

At SoftLayer, we don’t cut corners on our systems, and we ensure that each customer can upgrade as high as they possibly can. Each machine type can support more RAM and hard drives than the default level, and we normally have spare machines handy at all levels so that once you outgrow the expansion capabilities of your current box, you can move to a new system type. If you’re thinking of getting a dedicated server, but you’re worried about the cost, visit the SoftLayer Outlet Store and start small. We have single-core Pentium Ds in the outlet store, and you can upgrade from there until you’re running a 24-core Xeon system.

With the recent releases of Google’s Chrome (Sept 2), Microsoft’s Internet Explorer 8 Beta 2 (Aug 28), Mozilla’s Firefox 3 (June 17), not to mention all the legacy browsers many of which are still in use. If you are not a web developer, you are probably thinking why should I care what web browser people are using? Believe me you should, the majority of SoftLayer’s customers run a business and with that have a website which must be displayed on, you guessed it, a web browser.

1. Layout/Rendering Engine
This could be one of the biggest differences between the browsers, a layout/rendering engine is what the browser uses to parse the html and display your web pages. Although there are numerous specifications for various types of content (HTML, XHTML, images, etc..) each of the engines seem to render it slightly different based on their interpretation of the specification documents.

But don’t take my word for it go check the ACID website or the screenshots of the ACID tests in different web browsers.

2. Your Privacy
Most of the front runners in the browser wars are sending your usage and machine specifications back to the mother ship. What they are doing with the information once they get it, who knows. But, with Google being the front runner in search and ads, with the addition of Google Chrome, they pretty much can monitor all web usage for anyone using their product. Please get out the tin foil hats now ☺

3. Usage / Front Runner
Based off most of the statistics I have seen IE 6, IE 7, Firefox 2, Firefox 3 are the front runners, with a few stragglers using Safari and Opera. But I bet things will be changing and Chrome will be coming up in usage ranks over the next few months as well as IE 8 once it is released from Beta.

At SoftLayer we test on all the major front runners in the browser wars for our web presence. I will be grabbing the popcorn and watching the show, things are about to get hectic in this area. Whether it is good or bad; users are getting more options in the browser market.

-Dorian