The Changelog: Software Development, Open Source - Adhearsion, Telephony, XMPP (Interview)

Episode Date: April 13, 2012

Wynn caught up with Ben Klang and Ben Langfeld of the Adhearsion project to talk about Adhearsion 2.0, the future of telephony apps, XMPP, and more.

The Change Log is brought to you by Pusher, and they're looking for a system engineer who specializes in evented systems. If that's you, send your GitHub profile, a cover letter, and your CV to jobs at pusher.com. And also use the coupon code THECHANGELOG to save 15% off your first month billing. Join the real-time web today at pusher.com. Welcome to the ChangeLog episode 0.7.9. I'm Adam Stachowiak. And I'm Winn Netherland. This is The Change Log. We cover what's fresh and new in open source.

If you found us on iTunes, we're also up on the web at thechangelog.com. We're also up on GitHub. Head to github.com slash explore your fun. Some trending repos, some feature repos from our blog, as well as the audio podcast. And if you're on Twitter, follow The Change Log and me, Adam Stack. And I'm Penguin, P-E-N-G-W-Y-N-N. Fun episode this week. Talked to the guys over at Adhesion, Ben and Ben,

who on the episode you'll hear me call Ben0 and Ben1. Nice. Just to talk through what's going on with Adhesion version 2.0 and what they're doing with the plug-in architecture over there. And just a nice telephony conversation, kind of a follow-up to what we did with Chris Matthew back in the day. Yeah, back in the day. That was a good show, too. I know Chris. He's awesome. Yes. I guess telephony is one of those things that's such a cool tool. I wish I had a problem to solve with it.

Other than some uber prank call system, I'm not sure what I would build with it, but it is super cool. Yeah, definitely. I can see small businesses tying into some of this stuff and building their own, I guess, call systems. It's pretty neat. You know, if you're a 12-year-old, I think it would be the coolest thing ever to be able to build a very sophisticated, you know, your cows in my garden type of app. Yeah. Fun episode this week. Should we get to it?

Let's do it. We're chatting today with Ben and Ben, Ben Langfeld and Ben Klang from Adhesion. So, Ben Klang, why don't you introduce yourself and then we'll jump over to Ben number two. Sure thing. So, my name is Ben Klang, why don't you introduce yourself, and then we'll jump over to Ben number two. Sure thing. So my name is Ben Klang. I'm the founder of a company called Mojo Lingo, based out of Atlanta and parts throughout the world. I'm actually here today in my capacity also as the Adhesion Project Leader, and I've been in that role for about two years now.

And Ben? I'm Ben Langfeld. I'm based in the UK, and I'm an application architect for MojoLingo. As Ben said, we're distributed all over the world. I'm also on the core team for the Adhesion Project and I have a background in the sciences. Awesome. We did a lot of that on the previous episode. It's quite well received. So Ben, one, I guess I should say, for those that don least in concept with things like Ruby on Rails or Django or other web-based development frameworks. And those, those frameworks make it possible for you to relatively quickly and painlessly develop a web

application. And Adhesion is much the same thing, except applied to the telephony domain. As any good framework does it, it gets rid of a lot of the minutiae, the painful parts of dealing with the telephony world. So the framework provides things like a plugin management system, configuration management, the ability to, sorry, provides a nice clean API for developing voice applications in a way that's familiar for Ruby developers, and particularly those coming from Rails, and provides a whole host of integration points with various other bits and pieces of software, such as Rails, for example,

integrating your voice prompts with a database or some web API. Things that are very trivial to do in Ruby can be applied to a voice application very easily. So you've got a bit of Ruby here on the homepage. So let's talk about the architecture for a moment. Is it just a Ruby API wrapper around some other tools? What's the stack look like? So I think that's an important distinction. It's not just an API. It is a fully featured framework. It provides much more than a simple library into dealing with Asterisk or Rao or Prism or anything else.

It's a whole environment and a way of thinking about approaching telephony problems. We did select Ruby as the language of choice, I think both because we like it as a language and also because it's very expressive and makes it relatively painless to solve these problems. The ability to provide a DSL that closely maps to the needs of a telephone application just enhances that experience. What's new in Adhesion 2.0? to the needs of a telephone application just enhances that experience. What's new in Adhesion 2.0? Just about everything. I'll go high level kind of what the bullet points for Adhesion 2.0, and I'll let Ben go into some of the details.

I think the biggest, most exciting thing in Adhesion 2.0 is the fact that we've added support for not only a new telephony backend, but we've also made it modular so that in the future we can continue to add support for telephony backends. So just very briefly, the history of Adhesion was, it was a framework for building Asterisk applications, Asterisk being the open source to PBX. And that was very powerful and went a long way. But obviously, there are more than one way to skin a cat and Asterisk had a lot of strengths, it also had a few weaknesses. So we wanted the ability to support other backends, such as cloud based backends like Tropo, and also very large scale enterprise backends with something like Prism. So the big thing that prompted a lot of the rework in Adhesion 2 was the ability to abstract the telephony APIs,

the lower-level interfaces from the DSL. And so with Adhesion 2.0, out of the box, we support Asterisk, as we always have, and we also support Prism, which is an enterprise-grade commercial telephony engine provided by Voxeo using a new open standard RAO protocol, I'm sure we'll be talking about later in this podcast. How portable is the DSL across those backends? Are you investing in a backend if you choose a particular solution? We really do aim to be completely portable. And the idea is that if

you stay within sort of the sandbox, maybe not the best word, but if you stay within the confines of our DSL, you're guaranteed to be portable across the subordinated backends. There always will be things that each backend can do that others cannot. And we expose those to you, but you have to do those things consciously. And where there are differences in platforms, we expose those to you, but you have to do those things consciously. And where there are differences in platforms, we document those. So really the goal is to make applications portable. We don't want to have you invest all that time and energy

just to be locked to one backend. There are too many ways to do that already. Really the promise of Adhesion should be that you can write your application and then have it portable across any of our supported backends. So you mentioned cloud providers. Has that been a long time in the works, or how did that come about?

Well, our project is sponsored by Tropo, which is a leading provider of cloud-based telephony services. And we've worked closely with them. They have, in addition to Tropo, the cloud product and service, they actually sell premise versions of Tropo. So you can actually install this into your own data center if it's something that you wish to do. So we worked closely with them to ensure that we are very compatible with the services they provide. One of the things that Tropo does out of the box that Asterisk can't do, for example,

is very high quality text-to-speech and speech recognition. And our adhesion was designed to support those things if they're available. And certainly you can make those things available on Asterisk. It's just they don't come out of the box. So Tropa support is something, or cloud, I should say, cloud support is something that we've really looked at closely with Adhesion 2, both the ability to run Adhesion applications in the

cloud on the likes of Heroku, but also to be able to use cloud providers such as Tropo, which although I have to admit there are technical limitations today that make it not possible to run a Tropo app, those things will be resolved in the near future and a fully cloud deployed Adhesion telephony application will be a reality. Let's talk about some of the solutions, I guess, practical applications people are building with the platform. So I think Call Center is the one that comes to mind. What other solutions are you seeing people building with Adhesion? Well, the go-to answer would be things like IVR and Call Center.

Those are kind of the classic telephony applications. And certainly there's plenty of room in that space to innovate, to improve the processes that those kind of users have. With call centers, for example, what we're seeing is a lot of call centers are becoming more and more distributed, whether they're classic call centers or just sort of applying call center techniques to the modern cloud world. For example, we have a client that has a dictation service and the dictation service is, it employs transcribers around the country to take recordings and then turn them into written documents. And so the application we've helped them build is one that collects those recordings and routes them to the, to the queue to be processed. So theoretically you could have a, let's say podcast, upload an audio file, have that transcribed and have an ASCII version of that. Yes. And that is exactly what their service does. Might need to check into that. Yeah. Yeah. It's, uh, it, it, it opens a lot of possibilities when

you, when you can, when you have the, the ability to apply a, a programming language that's modern and has libraries for everything, you know, already available. You're not having to reinvent the wheel. And in fact, part of their story was they were locked into an old proprietary platform and it was, it was prohibitively expensive to make changes. And basically if, if they didn't replace it, they were looking at, you know, not being able to continue to run the service. I think in the way they had, it just was not, it was not a workable solution. So certainly there's a lot, there, there's a huge opportunity to continue to replace legacy telephone systems that are not programmable, not maintainable, just not modern by every definition. And those are great stories to tell. But I have to admit, I have a sort of an affinity for some of the really cool

innovative stuff that this also enables. I think that one message we would like to get out to the world is that for a long time, telephony was kind of forgotten. It was sort of a painful technology to use. The audio quality wasn't great, and you had to memorize telephone numbers. There was a very limited interface between you and whoever you were calling. But a lot of that is changing, and it's changing very quickly. The likes of Skype, the likes of the WebRTC initiative to put audio into the web browsers. Suddenly, the voice channel is just one more channel with which to communicate,

and you can embed this into an existing web application or into an existing desktop application or whatever it may be and really bring an additional rich communications channel to whatever it is you're doing. That's a powerful idea. And I do believe that we are still on the leading edge of seeing some of the really cool ideas come to market, that adhesion among many other technologies will enable a new generation of really cool applications. Hey, Adam here. Just wanted to take a moment and thank our sponsor, Hover.com, for supporting the show.

We certainly appreciate their support. Hover is by far the best place to register your domains. We recently took advantage of their domain concierge service, which is completely free, by the way. We had over 30 domains that needed to move over from GoDaddy because, you know, for obvious reasons why, we didn't want to use them anymore. And Hover took care of everything. They took care of all the heavy lifting. It's this special service they have.

It's called their domain concierge service, which basically means you don't worry. They do all the work. They move over all your domains. They take care of recreating your CNAME, your A records, your MX records for your email, everything. All you do is sit back and relax, and it's completely free. You actually talk to a human being to set it all up.

It takes about five or ten minutes. You call this 800 number, 866-731-6556. Like I said, you talk to a human, they take care of you, they make sure that you're good to go. And just tell them what the changelog sent you. Use the coupon code THECHANGELOG to save 10% on all the services that apply us to. We certainly appreciate their support, and thank you for trying them out. Hover.com.

Let's talk plug-ins for a moment with Adhesion 2.0. What's the anatomy of an Adhesion plug-in? So in the last release before 2.0, we had a concept called components. They allowed you to do a limited set of things with regards to code reuse. The new plugin system is much more similar to RailTies. A lot of people will be familiar with that. It allows you to extend the functionality of the application from within a gem dependency by doing such things as providing extra

call controller DSR methods. We'll talk more about what a call controller is a little bit later. It allows you to do things like add rate tasks to the application, add extra configuration options to the central configuration system in your Adhesion application and allows you to extend Adhesion to connect to various different services. For example, one of the plugins that we have that started off as a core feature of previous versions of Adhesion and is now extracted out into a plugin because we can do that now is XMPP functionality.

So if you want to integrate your voice application with either instant messaging or some other more technical use case for XMPP or Java, you can do that very easily by including Adhesion XMPP in your application's gem file and make use of the excellent Blather XMPP gem, which allows you to send and receive XMPP messages and do all kinds of interesting things.

So let's take, I guess, a step back and talk about the architecture of an application then. So the example on the home homepage is a class of my controller and people with a Rails background might think MVC when they see that. What are some of the similarities or differences between how you would construct maybe a Ruby-based web app and a Ruby-based voice app?

So with Adhesion 2, we've introduced this concept of call controllers, which brings an MVC-like approach to a voice application. It seems strange that you would consider a telephone call to fit into MVC. But if you break it down in a particular way, it really does. If you can consider the actual phone call itself to be the view, you can render audible input and output to that view. You can capture audio from it. You can manipulate it in several different ways. You can transform that view by applying combinations of other views. You can, for example, join calls together. Those actions are generally instigated by a controller,

which is the call controller that you'll see an example of on the website. That provides you with several methods by which you can manipulate the call view and then the vast majority of interesting adhesion applications that we build and other people build don't stop at providing output and recording input they they integrate with some kind of data source or some kind of model that provides for for example, a dynamic menu or, for example, captures a response from a user and stores it in a database and so on. So the classic MVC pattern does approximately apply to a voice application scenario.

It's not identical to the Rails-style MVC, which is not true MVC anyway. Sure. But it's that kind of approach, and it's a very useful way of thinking about it when you're building your application. There's also a concept of a router that routes. There is indeed. We have a routing DSL, which allows you to match an incoming call's variables. Any call coming into the system will have a certain set of variables provided with it when it comes in that tell you things about, for example, the caller ID of the person who initialized the call,

the method by which it got to your system, various metadata that the call is tagged with along the way across the telephone network to your system. And you can use that information combined with any information from the environment of the application at the time of the call, for example, the current time, to match against incoming calls and route them to different controllers. So, for example, it's very easy to have a route in the DSL which says any calls coming from such and such call or ID can be routed in one direction. Any calls, for example, coming in outside of office hours can be routed to a voicemail system. It's very flexible. What sort of challenges are involved, I guess, in creating global applications with something like this?

Any differences in telephone networks across international boundaries? As far as the details of actually connecting between networks goes, adhesion doesn't really worry about that a great deal. The issues faced in adhesion doesn't really worry about that a great deal. The issues faced in adhesion applications are normally ones of addressing. It's quite often you need to store

or manipulate phone numbers in a particular way, and there are inconsistencies across the world in the way phone numbers are structured. That's a minor problem that you often come across in these kinds of applications. So if you were to localize one of these applications, I guess, to offer different language prompts based on where the call is coming from, does it offer any hooks for any of that? Currently, there is no internationalization support built into Adhesion. It's a fairly simple thing to do custom in your application. That is something we have on the roadmap going forward with the two series of Adhesion.

The other interesting issue when you're talking about real-time interaction with a user, more so when you're making outbound calls, is time zones. We all know time zones suck in a very big way, but they suck even more when you're talking about calling people at 3 o'clock in the morning. So that is another challenge that is present in this kind of software development, but it's one that can be, um, you can, you can get around it if you think about it. So you guys had adhesion conf back in October, any plans for a follow-up? Definitely. In fact, that was the second adhesion conf. Uh, we had the first one in 2010 and 2011 was even better. It was, uh, I would say half again, larger than the original. And we had

more speakers coming from the community. I would, I was very, half again larger than the original, and we had more speakers coming from the community. I was very, very excited by the growth we had last year, and I'm hopeful that we'll get that again this year. We haven't actually really started planning. It usually happens late in the summer or possibly early in the fall, so we've been thinking about when and how that will be. But yes, definitely we'll have it again this year and I'm looking forward to it. It actually might be interesting to, in that the Adhesion 2 framework, or I shouldn't say that,

the Adhesion 2 roadmap was actually first revealed publicly at AdhesionConf. There's video of Ben and myself talking about, you know, kind of the goals we wanted to achieve. And I'm pretty happy that we've, I feel like we've hit most of the goals we wanted to achieve. And I'm pretty happy that we've, I feel like we've hit most of the goals we put into that presentation. And of course, just have that many more exciting things

coming up for some of the next releases. How many people are hacking on the framework? On core itself, if you're talking about the core of the framework itself, it's not many. It's, we have approximately 35 past contributors. As far as people using Adhesion to write applications, it's quite a lot, and it's people you wouldn't necessarily expect to be using it.

For example, at the last AdhesionConf, we had a presentation from a gentleman who works for the security services in the United States. So the Department of Defense are using adhesion. If it's good enough for them, then I'm sure there's a great many things that the rest of us can do with it. I'm sure they're war dialing. Actually, that was exactly his presentation was war dialing. It's funny you mentioned that. But actually, we also have reports that the army was using adhesion in the green zone in Iraq as part of a voice biometric system. So there are some pretty cool applications out there.

Interesting. You know, it just occurs to me that we used to spend so many brain cycles trying to do prank calls back in the day, and this is like a perfect cloud-based prank calling system if you are so inclined. The average 13-year-old that knows Ruby could have a lot of fun. So do not try this at home. We don't condone that kind of behavior. But if you were interested in learning more about how to do that, there's a really good video actually by Nathaniel Barnes, who the gentleman Ben was referring to. His video from AdhesionConf is up on the web. They actually compared what they created to Metasploit, which if you're familiar with that, it's a Ruby framework for penetration testing and exploiting. And it's an interesting comparison.

But yeah, his presentation had all kinds of really, really interesting details from the field, hypothetically, theoretically, on how you might do that. If one was not constrained by law. I first came across it, here's an asterisk, I guess about three, maybe four years ago. I'm trying to remember. It's been a while at a local regional Ruby conference, and it seems like back then, to kick the tires on this thing, the first thing people did was had a home install, where they had their own menu-based phone answering program at the house.

Have you guys so deployed one at home? I have in the past. I don't still have one. It's a nice introduction. We do similar things with corporate voice networks these days. And for example, our entire internal phone system is powered by Adhesion. So it's something that we do. And I certainly am sure Ben has done something similar, have gone down the home voice system route.

But it's something that wears off a little bit quickly. Yeah, I definitely have, have had over the years, many different, um, deployments of, of asterisk or other telephone things in my house. And pretty much it got to the point where, uh, I needed to maintain the PBX for the business. And so that's where all my effort goes. And my home phone line is actually, um, it's, it's just a special phone hanging off the, uh, the business. And so that's where all my effort goes. And my home phone line is actually, um, it's, it's just a special phone hanging off the, uh, the business PBX, but, um, there's really with the quality of bandwidth today, there's really no need for me to run my own asterisk instance at home. It's, it's really easy just to, to hang it off the, the work PBX, or even if you weren't someone who had their own work PBX that was available, the rise in the hosted PBX market has really, I think, shown that the flexibility, the relative

inexpense, it's just not hard to manage phone systems that way. That's really, to me, it's the obvious choice. I mean, who wants to pay for the initial hardware and also the cost of maintaining a phone system anymore, unless, unless it's something you specialize in doing, it's just not something you want to take on yourself. And just a short time, we've seen it go from voice to XMPP and SMS, um, any plans for video or other adapters that you could see coming into this sort of architecture? Definitely. I mean, video is something that everybody's excited about, but it's also one of those things that's sort of easier said than done. Adhesion as a project,

theoretically today, could do much of, really, from Adhesion's perspective, a video call is not that different from a voice call. The limitation is the underlying platform. Today, Asterisk does have video support. It has relatively good video support when you're talking about placing a direct call from party to party. It has a very limited video bridge. And I say limited in the sense that you can have multiple people in a conference and you can either have it so the video is is fixed so that one person is always on video broadcasting to other participants you can think of that like a lecture mode it also has a mode where you can it'll follow the active speaker so based on who's talking that video stream will be fed to all the participants

what it doesn't do and mostly for reasons of of both complexity of code as well as complexity of CPU complexity and load on the server, it does not make any attempt to mix the video. So it doesn't try to transcode. It doesn't try to do what's called the Brady Bunch effect, where if you have nine people in a conference, you have nine faces tiled. Those things don't happen. So that is a limiting factor for video. Other platforms, in fact, such as Prism, have no video support at all. So definitely we would like

to approach it, but I think that the technology there needs to evolve a bit more before it's actually useful. As far as adhesion is concerned, a lot of these challenges, as Ben says, are pushed down to the layer of the platform that adhesion is driving. It's important to note that adhesion is concerned a lot of these challenges as ben says are pushed down to the layer of the platform that adhesion is driving um it's important to note that adhesion does not for example process any audio um adhesion is a third-party control layer on top of um the the voip platform of your of your choice um so we don't need to worry about any of the heavy lifting of transcoding video, etc. That is all done for us. And once the platform does those things appropriately, it will not be too difficult for us to drive it in a way very similar to how we do voice right now.

So in some of the installations that you guys have been a part of in the PBX systems, what are some of the menu options? Are you doing purely audio and touchstone-based menu options, or are you pulling the information back into dedicated displays on phones and things of that sort, the visual voicemail style of app? You know, there are so many uses for telephone systems. We have done IVR. It's really not something that we do a lot of.

There are companies that specialize in IVR. I mean, it's that big of a field, I suppose. A lot of our work has been on kind of non-traditional applications. So, for example, we have a client, um, Palmling that's on the Tropo platform and their service is about connecting. Um, if, if you're traveling in a, in a foreign country and you need, uh, if you need help translating in that language, you can call into their, to their platform and it will find someone in their network who speaks the right language and connect you so that they can help you translate the call.

Oh, nice. Yeah. It's, it's a really cool idea and it's, it's a, it's a great service. Um, and, uh, and congrats to them. They, they launched not too long ago, but they're my, my point in telling that story, as far as your question goes, there is an IVR there, but it's, it's relatively basic. The, the main function of the IVR is to authenticate the caller to make sure that they're, you know, a registered a registered subscriber with an active account and to as quickly as possible get them out of the IVR and get them talking to a translator because that's really the problem they want solved. And it's sort of a Zen-like thing. The less IVR you need, the better. I think the broader question was looking at multiple interface modes with, you know, around a call. We have developed applications. Most of them are still in development and we can't talk in too

much detail about them. But we have applications which combine a web browser, a mobile app, a voice call, instant messaging, etc., where you have multiple modes of communication with the application simultaneously. So you may have a conference call and a text conference, similar to how you may do a Skype conference call, but in ways that are very flexible across devices. So imagine if one of those participants could be a cell phone and another one is a desktop application, and that you don't have to worry too much about the capabilities of each channel,

sort of like the idea of progressive enhancement with the web or graceful degradation. You present to each channel the best of its capabilities, and everybody participates at their own level. So when you guys aren't hacking on adhesion, what's in your open source radar? What is out there that you just can't wait to play with? So I'll go for that first. I'm very invested in XMPP. In fact, the RIO protocol that is fit for the web.

That's a major enhancement. I maintain, along with its original author, Jeff Smick, the Blather XMPP library, which allows you to build quite advanced software that makes use of XMPP. For example, a bot. Everybody when he's 17 builds an IRC bot. You can do the same thing with XMPP. You can integrate with Google Talk, for example,

which is XMPP-based. I do a lot of work in that arena. That interests me. XMPP seems to be everywhere. We at work use HipChat for our group chat, and I think that's one of the biggest selling points is that you can bring any XMPP client along and connect. Exactly. It's open, it's federated, it's very flexible,

and it can be used not only for user-facing things, but it can be used for internal infrastructure as well. XMPP PubSub is a fantastic queuing mechanism, for example. And it's a proven technology. Brent kind of mentioned the federated nature of it. I mean, it's an awesome way to not reinvent the wheel, is a good way to say it. But a lot of services that you might not even realize are being built on XMPP. To my understanding, Apple's iMessage, which is the new sort of SMS replacement they have that's XMPP based as is Facebook chat. Now, the degree to which

you can access it with external clients kind of varies, but just the fact that those things are running on XMPP is good for the entire community. A great deal of messaging systems are built on XMPP without you knowing it. As Ben said, iMessage and WhatsApp is another one that's an entirely XMPP-based network. A lot of people are using it who you might not necessarily know about are using it. But it's a fantastic protocol that, quite frankly, more people should know about. What's the most interesting project that you've built with Blather? I think the most interesting one is probably one that I can't really talk about. I guess the most interesting topical one would be the library that Adhesion now uses to communicate with the VoIP backend,

as Ben said, we've made everything modular. We now have a middleware library called Punchblock, which sits in between Adhesion and the voice platform and makes them all appear under a consistent API. That uses Blather and XMPP to drive a Rio server, for example, Voxair Prism. That's had some unique challenges and was very interesting to put together.

There's some things we've done there that we might not do again, some things we've done there that are quite fantastic. Altogether, a very interesting use case for XMPP that has absolutely nothing to do with instant messaging. that we might not do again. Some things we've done there that are quite fantastic. Altogether, a very interesting use case for XMPP that has absolutely nothing to do with instant messaging. So since you can't talk about your day job at MI6, let's talk about your background in the sciences. So let someone think that it's just a broad da Vinci stroke there.

What sort of sciences have you dabbled in? So I did a physics degree, um, as an undergrad. Um, that was actually only a few years ago. Um, I, uh, do some work, um, casually with, uh, a friend of mine who does a PhD in astro seismology. Um, and I use, or I've encouraged him to and helped him to use Ruby to infiltrate a world that is full of Fortran and IDL and other nonsense. So I've been playing my limited part

in expanding the horizons of the British scientific community to include such a fantastic language as Ruby. So did you come into computing as just a love for computing or just out of necessity to do something more valuable and this was a means to an end? I've always been interested in communications problems. And I came to the work that I'm doing now with with ruby and and more or less all of my software engineering um work that i've done um from that angle um i did a lot of work um while

i was doing my degree with the university radio station and there were some interesting problems to solve there with regards to communication when you don't have a multi-million pound budget to buy commercial systems. And so that's actually what brought me to Adhesion, building a flexible phone system for a very specialized use case, a radio studio. And actually Adhesion fit that very well. Ben Zero, what's your background? My background is systems. So I started actually in high school. I took sort of random jobs as a systems administrator,

and I spent the next 10 years doing all things system. I did a lot of work consulting on, believe it or not, PeopleSoft as an architect, figuring out how many networks and how many servers and how much storage you would need. So I still have a love for the operational side of things. And actually, I came to Telephony almost by accident. My father-in-law had a startup. He got royally upset at AT&T one day for canceling a service that he liked, which today is fairly commonplace, but then was really not. It's the classic follow me, where you have a phone number, you call in, Google Voice does this, you call into it and it calls your cell phone,

your home phone, and you can take the call wherever. This was back in 2002. Asterisk had not actually reached version 1.0. Everyone who's running Asterisk had to check it out from CVS and compile it and run it. And, uh, so yeah, he, so we, we kind of tried to start a business, uh, offering follow me services. That part didn't go so well, but that, but, uh, definitely got me hooked on telephony and the possibilities there. And, uh, and so as I, um, as I exited the, the systems admin world, I was looking for something to do, uh, you know, something to do because I wanted to start a company. And Telephony was really interesting, and it was kind of a case of right place, right time, especially as far as the Adhesion Project was concerned, as the former maintainer was sort of on his way out.

And so I stepped into that role, and it's just been a fantastic, fantastic ride since then. So I'll put you on the spot either one of you have a programming hero i think ben's my hero yeah uh i i have well thank you ben um i have several people whose work that has has has benefited me that i've some of those that I've taken over projects from Jeff Smick who was the original author of Blather has done some pretty cool stuff

there's a few people doing very interesting stuff around concurrency in Ruby which is not a pretty subject in some cases. I've been wanting to get the celluloid project on the audio. I can talk to you a little bit about celluloid. Adhesion uses it.

Oh, yeah. Yeah. We're seeing that now. Tony has put together a fantastic framework that looks and smells a lot like airline but without the yuckiness that's so going in the show notes mike perrin has done a lot of interesting stuff um yeah there's there's there's some pretty cool guys out there doing doing interesting things with concurrency on Ruby. I'd also like to point out Charles Nutter and the guys working on JRuby

for really doing some, I think, some important work to bring Ruby to an entirely different audience and to an entirely different scale. That's a really cool project. Absolutely. Well, thanks, guys, for joining us and talking to us a bit more about Adhesion 2.0. It's a fun project and I think I'll be dabbling in this myself. Fantastic. Glad to hear it. you