 A little bit about me and my company before we go ahead. This is a Josh software, and I'm sorry it's not Josh. I'm sorry for all the Josh that Josh is around. Josh in my mother tongue in Hindi means enthusiasm. And that's what we're all about. We believe that programming is an art, and you're based in India. And this is what we do. We work enthusiastically and build masterpieces. We've been working exclusively in Ruby on Rails for the past three years. And typically, this is how our journey begins. Or with protective gear, or ready to write enough waters. And when time finally comes, usually be successful, but always drenched. Well, the call goes to show either you always fall in love with Splat or Splat on my face. A little more about us is our website and our blog. Well, my presentation is all about mobile value added services. So I thought I should at least get into little basics of what value added services for mobile points are. Anything that is beyond that of voice offering by telcos is termed as mobile OS. SMS. SMS borders on mobile OS, or part of a whole deal. Today with any cell phone reception that you get, any voice facility always have texting. Well, so you have any sort of GPS, or any sort of movie schedules, corner tunes, score alerts, IPTV, email, all these are value added services on mobile. What we are going to deal with is the SMS aspect of mobile value added services. Smartphones are pretty cool. I know almost everyone here has an iPhone. But these are the few problems I see when using SMS or smartphones for mobile value added services. You're restricted by infrastructure. You require at least 3G spectrum for getting really cool applications out, for getting stuff in. But guys, are we targeting only our select audience here? Or are we targeting the world? The aim here is to target the world, get a global presence. Sometimes mobile value added services are restricted by geographies or by laws. In India, for example, the 3G spectrum is opening up. It's being purchased by the government for whopping 55 crore. 55 crore. So it's like a crazy amount of money. And that's where the market is going. In spite of all this, smart phones are for the tech side. Well, that's why I'm two-year-old. When my dad comes home, he asks for the iPhone. I have no idea whether he meant Apple or iPhone 3. Well, that's where the world is going in. SMS, on the contrary, on the other hand, has a global reach. It's a photo of people in Africa and uncanny is the temporary phone that I have purchased here. It has SMS. Wherever there is cell phone connectivity, you will always find SMS connectivity, even in the really deep jungles. And a good part about the emotional aspect, as well as a case study of SMS as a value added services, comes from a country in Malawi. I mean, one of Malawi. Malawi is a very small country in Africa which was struck by famine in 2002. The UNICEF and the USAI went down there and they tried to get in the statistical data for malnutrition and kids there. So, they initially did an exercise sheets on paper. They had it. So how do you detect if a kid is suffering from malnutrition? Malnutrition is by measuring the high rate and the upper-on circumference. Well, this data had to be sent to a processing unit in the US somewhere where they would finally detect if the person had SMS malnutrition. By the time the reports came back, either it was error-prone, kid is missing, kid is probably dead. Well, they managed to do this for one whole year. After UNICEF and the USAI moved out of Malawi in the whole process went for a toss because of all sorts of overheads, bureaucracy, blood tape, paper lot, lots of paperwork involved, human errors, and they finally came up with a new system called rapid SMS. The rapid SMS today is local source framework which is useful for managing SMS information. So, it's not an SMS port, it's for managing the data but they could set an SMS with the growth monitoring center, child stats, get a census, send the upper-on circumference, get immediate response from the system there whether the kid is malnutrition or not, and proceed. With the success of rapid SMS, a lot of web authors realize that there is a lot of benefit by going just beyond your online presence. You want to be great. Almost everyone on your iPhone uses Twitter account, uses your Twitter to send tweets. Use your phone because it's easy. If you had the facility of using SMS, it would make your life easier. Twitter has made huge amount of progress by simply, sorry for that. Twitter has made huge amount of progress by simply providing an SMS facility in various countries. And this is where most of the value actually is coming for any online portal, for any application that wants to go beyond the offering of just their online audience. So, how does one start, it's very simple. Just choose a vendor, maybe video, click-a-tail, TROPO, VIMOBO, Bulk SMS, and there are only a few of them, there are like about a hundred of them. There are a hundred of them with their offerings in different countries, presents in different countries, and we should never forget the different protocols. There is the rest, so HTTP, and these are just a few of them again. So, what are the choices you make? Do you want the cheapest alternative? You go with the costliest alternative. Maybe you have good support. Maybe just take any one vendor, set it up, and we tackle these when it comes to resolve them as they come in. But, you know, you're always going to have your doubts. Did I make, did I choose the right vendor? Can I change my vendor now? Suppose they just change their, they change their plan and become really expensive. How about you short myself in the form? You've chosen three questions that you're actually asked yourself, ever when you're doing this, let's wait, what's the solution, though? One of the simple solutions is hire one of the ungrateful developers, flesh out this graduate school, tell him that I'm going to give you some sort of amazing work to work in the new protocols. You learn restful APIs, and you can work with third party integration, and get into development. Maybe not a lot of it, not so convenient. I could help but get that one in there, so. I have to take it, take it, take it. Well, let's just, let's just solve the problem, that's it. Every vendor has different APIs. Every vendor does things differently because there are no standards. To give you an example, we chose ClickTap. Just to send bulk messages, customize bulk messages to people you have to actually go through this vomit of code. And I have tried to strip out as much as I can from it. You have to set up your authorization, get your session ID, then start a batch, get some fields integrated. Notice that you have fields here. ClickTap says, put a hash field one, hash field two. You set, formulate, somehow get your dynamic data in, formulate the SMS information, send the SMS, close the batch. This is one way of doing it. The other, some other company probably do it is a simple XML file. The pretty neat startup in India though, they're using embedded Ruby syntax in the XML data information and we place dynamic data on it. But if I had to change vendors, that would really kill me. I have ClickTap having HTTP APIs, XML APIs. These guys have XML, somewhere Twilio has rest. You can do it this flat way. Set your vendor, keep on format, send the SMS. You probably do a demo later on. I'm gonna ask some of y'all, I'm gonna bribe some of y'all with some coffee or some beer if you could register numbers here so that they'll get this even a SMS. So for a few cents for a beer. And this API mess that I talk about continues. Nothing is ever complete without a mix. All those blue things coming down, but I thought you could see the arrows in the process of different vendors we evaluated and their different offerings. And you'll notice that not all of them have everything that you really want. ClickTap is pretty cool because it has very huge global presence. But they have different types of support, HTTP authentication support, they have different types of sending bulk messages. They're supporting different types of protocols. Suppose we take, for example, let's do with ClickTap because it's got most of the offerings here. I wanted to have a portal which is launched with mobile language services in the US, in Africa, and in India. ClickTap is a good player. It has support everywhere. But it can get expensive if you're sending international APIs. Wouldn't it be cool if I could take a vendor in the US, get the best option in Africa and get the best option in India, and auto detect which SMS goes to which country, which value I had a customer, and send it via that particular gateway. So Splat came about because it was a necessity for us. It was not something that we thought about doing something cool. We actually had a few clients, one in Europe, one in India, and one in the US who said we want the SMS integration and our developers coming back and kicking us, saying, you know what, we don't want to do the same thing again and again. So we said, let's build a library. It says that it's generic enough to ensure that you can change your vendors. You can do a lot of other stuff. You can manipulate information. You can work with different vendors at the same time. And that's why I really love Splat. Splat is not our SMS vendor. So we have just a library. It's an open source library package as a gem. It's available as Josh Splat. Not that we want to put on him, but somebody's already taken the Splat gem. But we automatically integrate different vendors. Currently, we're supporting four of them. We're supporting Click-A-Tell, Twilio, Punk SMS, and one more Indian vendor, Vivovo. Splat, as I said, is not a service. You still have to purchase a subscription. But those nagging questions earlier, well, this makes your life easier. You can afford to make mistakes. You can afford to choose. And you can afford to change your choices later on without any fear. You can, there are, like, Click-A-Tell gives you only 10 credits. Twilio gives you $30 for development and marketing. We're planning on building, we're not building one yet, but we're planning on building a test Go-Bus SMS gateway where you can test out all different, turn on different type of SMS and send it to the different customers. I still have to ask Jim how we've hosted the raffle. I think it's on Twilio. Don't drop out. Drop out? Cool. Oh, yes, of course. It should be, it has to be one of the sponsors there. Cool. So these are some of the things that are good features that you need to add. Imagine if you had to send a Punk SMS list, you had to maintain a list, and you want to change it. You want to see how many of these people actually responded to your SMS, how many of them came back with incoming data information, and you want to trend on this information. Not just in your local sector, but globally. We have to do that. So we can schedule SMSs, we can standardize reports, Click-A-Tell has different reporting format. Twilio has a different, Twilio does not have a reporting format, it's just a status. All these vendors, all these vendors have their own formats of status and Splat helps you standardize that. So we can actually go about setting some sort of standards or sending SMS, some sort of API standards, some sort of standardization in the reports. We can do some trend analysis. And all was not so smooth. We kept having this hanging down. Why isn't it already there? Why hasn't somebody already done it? And among some of the challenges that we face was the big number, mobile number format. All these are valid number format. And every vendor says, we will do it only our way. Click-A-Tell says, I want the country code, followed by the number, but without the plus sign. Another vendor says, I work only in India, so I don't want the country code. The third vendor says, I'll accept any format. Somebody wants the dash. So the way around this would be, we set our own default number. And that's it, that's better. Is it worse? Is it worse? Is it worse? Okay, so we set our own format. A default format, which is highlighted there in the comments there. We set the plus country code with a space and give you a mobile number. Well, it's mobile number. The entire number itself can vary between eight and eight, in different countries. So we have to keep some standard. But now the question arises that if I already have a legacy database of, say, 10,000 customers in my own number format, how will you splat? We provided the facility for all that, just before you're sending the SMS, you can manipulate the number to splat format, so that you're following the standards. Maybe, if you really want to risk it, change the reg X that we have before. Change this to suit your need, but you'll probably be able to work in one vendor. But of course, it's Ruby, we have to provide a short circuit route. It's, we're providing a good default option, but that is not mandated. Installing and configuring splat is as simple as gen install. We've also provided generators for a Rails application, so you can use it easily through Rails. And there are two configuration files which are necessary. One is for default splat configuration, and one is for your vendors. The vendors is, you have to set your subscription to either key or password or username, and you should be able to send some SMSes. Demo time. Okay, so I have my phone here. What we can do is, four lines of code to send an SMS. I'm currently using Twilio, and it might be worth to show, and this is the vendor's file. Just remove the transparency. Somehow it's not working. Is this clear enough? Okay, cool. So this is the vendors.yml file, and that's simple as providing your credentials for Twilio, for any credentials that keep for Twilio. And you can send your SMS. Sending the SMS is, you have to create a new instance of whichever vendor you want to work with, and send your SMS. So I'm sending it to Twilio right now, and hopefully something's gonna happen after some time. I'm sure they'll get the SMS to all of it. There it comes. So, and, hey, somebody else got the SMS. No, that's me. But it's as simple as this. Now, suppose I want to change my vendor at a later stage. All I have to do is go and change one word, ensure my vendor's file is updated, changes to click attack, not the same one again. Sends to click attack. What I'll achieve here is ensuring that I'm completely SMS vendor agnostic. I don't have to bother about how vendors work with it. How vendors, I should have kept my tone a little higher. It's pretty interesting, right? So, sound volume. So, this is how we change vendors when you're working with flag. How about we go through another demo where we want to work in multiple gateways together? In the sense, if I have, I'm working multiple numbers, and I'm working with a US phone number, and an India phone number, and when I have to send the same sort of SMS, I can choose my different vendors. The code I'm instantiating splat twice. I'm using one of the bulk SMS from India, and I'm using a simple regular expression to check the country code, and I'm setting my default tone to something pretty fancy. Yeah. But you guys should help, right? So, if I'm sending to one of the numbers in the US, and one of the numbers in India, I can use a simple regular expression to choose which gateway I want to send. Now, the beauty of this is that if we use things like DLJ, we can actually send bulk SMSes with a second using the right gateway, using multiple gateways being country-sensitive or country-code-context-sensitive, and that's exactly how this works. So, of course, you will not be able to see the demo of the one going to India, but something should come here. Imagine life without a plan to work with integrations of different click-a-tell or Twilio APIs. When you work with such cases, it's very easy for us to realize that Eureka, okay, I thought it was a temporary phone, I don't know how to switch that tune off so much. But, so, this is another one now. I have one more demo lined up, but I have a Twilio account. Do I have any volunteers where I can actually send bulk SMS, customized bulk SMS through Twilio? Now, Twilio does not support customized SMSes, Twilio does not support bulk SMS, but we do it with Splat. The only problem is I have a developer account. So, before we activate, yeah, I have to actually activate your account on Twilio. So, do I have any volunteers? That's cool, I kept the scope for that. So, I'll add you in my column. Go ahead and just send it to him. Well, I think it's... Go ahead and just send it to him. Sorry? Go ahead and just send it to him. I got to take care of it. I'm sorry. He did it for you. I upgraded your account for you. Oh, you did? I can send it to everyone? Yep, one second. I'll have to write. No, okay. Hey, you know what the worst part was? I thought all I have to do is upgrade my account. So, instead of using development, I actually quit particular hours quit. And still didn't let me send as much to any number. We have to add a number you can send from that phone. We can work it out after. You should be fine to send to him. Should I send? Go to phone numbers. Okay. I am on phone number right now. So, if you click buy a number on the top right there. You want me to buy one right now? Yeah, it takes two seconds. Okay. And then just pick a state. Any area for it? Anyone that's not great. If you use that, click purchase number, and if you use that one as the problem number, you can send it to anybody. Okay, so. So, red purchase, there first, yep. Okay. So, now I have to use this number to. You have to send it as the problem number. This rocks. So, I'll let you all in on another secret. We integrate with 3DO last night. So, what you're doing right now, is. I got a better way to put that. Just for coming here, somebody's telling me about how to give cool presentations. Cooling presentations there. Okay, pretty cool side. I like one thing there. You go standing in front of the audience. That's what I'm doing right now. 429. Thanks for the call. Okay. So, volunteers. You have 512. 512. 777. 777. 4144. 4147. 1144. 1144. And, what's your, who did I leave on your name? You put Charles. Anyone else? 512. 512. 632. 632. 6617. 617. And your good name will be? Keith. K-I-P-T-H. K-E-I-T-H. Any other ones here? 2-8-1-8-2-7. 2-8-1-2-8-2-7. 827. Sorry, 2-8-1. 2-8-1. 827. 827. 6574. 6574. Rob. Wrong bracket on the left. Syntax here. Bracket on the left. Sorry, what? Left bracket. You have a right bracket. Left bracket. Left bracket. There you go. Last one. 415. 415. 704. 704. 451. 704. 451. 704. 3-8-1. 401. 202. 306. 415. 417. 418. 422. 418. 418. Over here. 419. 518. 419. 419. 318. 419. 419. 419. 419. 419. 419. 419. 419. 419. 419. 419. 419. 419. So we get the number plus, we get the message that we can say. We can even set defaults. So in case I have, say, $2 somewhere, and I say for my surname, and I don't have a surname, I can set the default, say, empty string or user or something like that. So we are doing our best effort here. Okay. It's time. I didn't send anything. But thanks a lot. Okay. Let the games begin. And currently everything is synchronous. So plan is to get it to be their job. That's somebody. Anyone else? I got it, yeah. Hey, who? I haven't got it yet, so. But it's only the case of the bit. Hey, yeah, I have a live account. Thanks. So that's what splat is all about. We are not done yet. A simple example here for customized messages. What's a splat roadmap? Splat is about three months old. We had RubyConf India where my colleague and me got an idea about doing this. He spoke to some people, searched the net and said, you know what, let's just do it. And in the past three months, what we've tried to do is try to send a whole list of bulk SMS support for splat. We've done four vendors, video being the last. We wanted to do TROPO, but we ran into trouble because TROPO said you need to have numbers in I think four cities right now. Four or five cities only, so we didn't have numbers. So we couldn't do TROPO. But we plan to integrate as many vendors as we can. We want to do the stuff that, you know, we want to look at things like Sprinkly or Authentic.net. We're looking at a common layer for getting textbook services out. And there could be some business potential that we do later, but it's too early for that. So our aim is to get in all the features that we want to ease sending bulk SMS, getting incoming SMS. We already have a course for registering incoming SMS, but I can't demo it because it's extremely expensive. But we plan also to do trending. Trending opens up a whole new avenue of business potential. And I don't know where we're going to go from here, but we see a lot of potential. We're trying to see where we can get this library out to speed. That will be. Thank you so much. Any questions? You've done much testing clinics. We've, well, our development has been on over two. Because I just tried the first one. It doesn't mean it doesn't recognize my specialty. Yes. So this has absolutely been a proof of concern for us. The last two, three weeks have been a roller coaster ride. But we've done our development, so wherever Ruby is supported, it should ideally work. So we've got, we've kind of put in some specs. And we've got all the experts' advice. We said, let's get a proof of concern card before we do any other work. And things like these are actually helping us to get a little more traction with lots of lines. Unfortunately, in the US, there's been a lot. There is always SMS too, which helps you send an email to SMS, but there's formatting issues. You have to get sent the email in its own format. Setting up an SMS gateway, getting a subscription is sometimes expensive. So, well, God help us. Any other questions? You need a gateway in order for this to work, right? No. Ours is a library, but you need a gateway subscription. Okay. So you need to pay money in order for half a percent of SMS. Yes. That's why I said, SPLAT is not an SMS vendor. It's just a library. It helps you assist. So it's a development tool right now, where the developers don't have to bother about getting into the activities of either vendor or their protocol. That's right. Receiving text from the SMS device, if I were to reply to you, what would happen technically on the Twillow account when you receive my reply in dialogue? So, SPLAT, as a library claim, will register call back. And we'll be registering that with the URL. So there are different types. Sometimes you can register a call back function, or you can register a call back URL, which SPLAT will register with Twillow. So when you get an SMS on your Twillow phone number, it will come back to the SPLAT library, which will call your function for processing the incoming message. We've already done that with one of our Indian vendors. So that's unfortunately what I can demo here. But we've already done that. Any other questions? Thanks so much.