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

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

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

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.

Authentication
Before you start playing with the SoftLayer SOAP API, you will need to find your API authentication token. Go into your portal account, and click the “Manage API Access” link from the API page under the Support tab. At the bottom of the page you’ll see a drop down menu for you to “Generate a new API access key” for a user. After you select a user and click the “Generate API Key” button, you will see your username and your API key. Copy this API key, as you’ll need it to send commands to SoftLayer’s API.

PHP
In PHP 5.0+ there are built in classes to deal with SOAP calls. This allows us to quickly create an object oriented, server side application for handling SOAP requests to SoftLayer’s API. This tutorial is going to focus on PHP 5.1+ as the server side language for making SOAP function calls. If you haven’t already, you will need to install the soap client for php, here is a link with directions.

Model View Controller

Model-View-Controller or MVC is a software architecture commonly used in web development. This architecture simply provides separation between a data abstraction layer (model), the business logic (controller), and the resulting output and user interface (view). Below, I will describe each part of our MVC “hello world” web application and dissect the code so that you can understand each line.

To keep this entry a little smaller, the code snippits I reference will be posted on their own page: SOAP API Code Examples. Protip: Open the code snippit page in another window so you can seamlessly jump between this page and the code it’s referencing.

Model
The first entry on the API Code Examples page is “The Call Class,” a custom class for making basic SOAP calls to SoftLayer’s API. This class represents our model: The SOAP API Call. When building a model, you need to think about what properties that model has, for instance, a model of a person might have the properties: first name, height, weight, etc. Once you have properties, you need to create methods that use those properties.

Methods are verbs; they describe what a model can do. Our “person” model might have the methods: run, walk, stand, etc. Models need to be self-sustaining, that means we need to be able to set and get a property from multiple places without them getting jumbled up, so each model will have a “set” and “get” method for each of its properties. A model is a template for an object, and when you store a model in a variable you are instantiating an instance of that model, and the variable is the instantiated object.

• Properties and Permissions
  Our model has these properties: username, password (apiKey), service, method, initialization parameters, the service’s WSDL, SoftLayer’s type namespace, the SOAP API client object, options for instantiating that client, and a response value. The SOAP API client object is built into php 5.1+ (take a look at the “PHP” section above), as such, our model will instantiate a SOAP API object and use it to communicate to SoftLayer’s SOAP API.

  Each of our methods and properties are declared with certain permissions (protected, private, or public), these set whether or not outside functions or extended classes can have access to these properties or methods. I “set” things using the “$this” variable, $this represents the immediate class that the method belongs to. I also use the arrow operator (->), which accesses a property or method (to the right of the arrow) that belongs to $this (or anything to the left of the arrow). I gave as many of the properties default values as I could, this way when we instantiate our model we have a fully fleshed out object without much work, this comes in handy if you are instantiating many different objects at once.

• Methods
  I like to separate my methods into 4 different groups: Constructors, Actions, Sets, and Gets:
  • Sets and Gets
    Sets and Gets simply provide a place within the model to set and get properties of that model. This is a standard of object oriented programing and provides the model with a good bit of scalability. Rather than accessing the property itself, always refer to the function that gets or sets the property. This can prevent you from accidentally changing value of the property when you are trying to access it. Lines 99 to the end of our call are where the sets and gets are located.
    
    
  • Constructors
    Constructors are methods dedicated to setting options in the model, lines 23-62 of the call model are our constructors. The beauty of these three functions is that they can be copied into any model to perform the same function, just make sure you keep to the Zend coding standards.

    First, let’s take a look at the __construct method on line 24. This is a special magic php method that always runs immediately when the model is instantiated. We don’t want to actually process anything in this method because if we want to use the default object we will not be passing any options to it, and unnecessary processing will slow response times. We pass the options in an array called Setup, notice that I am using type hinting and default parameters when declaring the function, this way I don’t have to pass anything to model when instantiating. If values were passed in the $Setup variable (which must be an array), then we will run the “setOptions” method.

    Now take a look at the setOptions method on line 31. This method will search the model for a set method which matches the option passed in the $setup variable using the built in get_class_methods function. It then passes the value and name of that option to another magic method, the __set method.

    Finally, let’s take a look at the __set and __get methods on lines 45 and 54. These methods are used to create a kind of shorthand access to properties within the model, this is called overloading. Overloading allows the controller to access properties quicker and more efficiently.
    

  • Actions
    Actions are the traditional verbs that I mentioned earlier; they are the “run”, “walk”, “jump”, and “climb” of our person model. We have 2 actions in our model, the response action and the createHeaders action.

    The createHeaders action creates the SOAP headers that we will pass to the SoftLayer API; this is the most complicated method in the model. Understanding how SOAP is formed and how to get the correct output from php is the key to access SoftLayer’s API. On line 77, you will see an array called Headers, this will store the headers that we are about to make so that we can easily pass them along to the API Client.

    First we will need to create the initial headers to communicate with SoftLayer’s API. This is what they should look like:

    <authenticate xsi:type="slt:authenticate" xmlns:slt="http://api.service.softlayer.com/soap/v3/SLTypes/">
        <username xsi:type="xsd:string">MY_USERNAME</username>
        <apiKey xsi:type="xsd:string">MY_API_ACCESS_KEY</apiKey>
    </authenticate>
    <SoftLayer_API_METHODInitParameters xsi:type="v3:SoftLayer_API_METHODInitParameters" >
        <id xsi:type="xsd:int">INIT_PERAMETER</id>
    </SoftLayer_API_METHODInitParameters>

    In order to build this we will need a few saved properties from our instantiated object: our api username, api key, the service, initialization parameters, and the SoftLayer API type namespace. The api username and key will need to be set by the controller, or you can add in yours to the model to use as a default. I will store mine in a separate file and include it in the controller, but on a production server you might want to store this info in a database and create a “user” model.

    First, we instantiate SoapVar objects for each authentication node that we need. Then we store the SoapVar objects in an array and create a new SoapVar object for the “authenticate” node. The data for the “authenticate” node is the array, and the encoding is type SOAP_ENC_OBJECT. Understanding how to nest SoapVar objects is the key to creating well formed SOAP in PHP. Finally, we instantiate a new SoapHeader object and append that to the Headers array. The second header we create and add to the Headers array is for initialization parameters. These are needed to run certain methods within SoftLayer’s API; they essentially identify objects within your account. The final command in this method (__setSoapHeaders) is the magical PHP method that saves the headers into our SoapClient object. Now take a look at how I access the method; because I have stored the SoapClient object as a property of the current class I can use the arrow operator to access methods of that class through the $_client property of our class, or the getClient() method of our class which returns the client.

    The Response method is the action which actually contacts SoftLayer’s API and sends our SOAP request. Take a look at how I tell PHP that the string stored in our $_method property is actually a method of our $_client property by adding parenthesis to the end of the $Method variable on line 71.

View
The view is what the user interprets, this is where we present our information and create a basic layout for the web page. Take a look at “The View” section on SOAP API Code Examples. Here I create a basic webpage layout, display output information from the controller, and create a form for sending requests to the controller. Notice that the View is a mixture of HTML and PHP, so make sure to name it view.php that way the server knows to process the php before sending it to the client.

Controller
The controller separates user interaction from business logic. It accepts information from the user and formats it for the model. It also receives information from the model and sends it to the view. Take a look at “The Controller” section on SOAP API Code Examples. I accept variables posted from the view and store them in an array to send to the model on lines 6-11. I then instantiate the $Call object with the parameters specified in the $Setup array, and store the response from the Response method as $Result in line 17 for use by the view.

Have Fun!
Although this tutorial seems to cover many different things, this just opens up the basic utilities of SoftLayer’s API. You should now have a working View to enter information and see what kind of data you will receive. The first service and method you should try is the SoftLayer_Account service and the getObject method. This will return your account information. Then try the SoftLayer_Account service and the getHardware method; it will return all of the information for all of your servers. Take the IDs from those servers and try out the SoftLayer_Hardware_Server service and the getObject method with that id as the Init property.

More examples to try: SoftLayer Account, SoftLayer DNS Domain, SoftLayer Hardware Server. Once you get the hang of it, try adding Object Masks and Result Limits to your model.

Have Fun!

-Kevin

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.

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