Python should be the first language you learn!

For the better part of the past 15 years, I’ve been a PHP developer. Really, I’ve developed everything in PHP, ranging from server side services, web services, backends – you name it, I’ve probably done it with PHP. Don’t get me wrong, I love PHP and it will always remain my language of choice for doing things really fast.

However, for the past year I’ve been increasingly developing with Python. I’ve always dabbled with Python, but never really had the chance to truly get down and dirty with it. Due to a couple of projects during the past year, specifically ones that involve Google AppEngine, I’ve had to sharpen my Python skills and get to a point where I can develop with the same agility that I have with PHP. Honestly, it wasn’t simple – sometimes I truly wanted to strangle someone with various errors a framework can spit at you. However, once you get around to reading the various cryptic messages Python may spit at you, getting around it and working with it is truly a delight.

So, why do I think Python should be the first language one learns? so here are my thoughts:

I started my coding days with BASIC, to be more accurate GW-BASIC (yes, I am that old). From that I moved to Pascal (Turbo Pascal to be more accurate), then C, then C++, C++ Builder, Visual C++ (yes, I did MFC at some point in my life as well). I then decided that my life is in the open source world – and thus, the track then went to PERL, JAVA and of course PHP. Honestly, somewhere around 2005, the mixture of C, JAVA and PHP truly gave me all the power I needed to do my job – so, I didn’t really find the time to learn a new language.

Then, about a year ago, I decided it’s high time to learn something new – specifically, I became increasingly interested in the Google AppEngine platform. Yes, I’ve been using Google Compute and other cloud platfroms for a few years now, I’ve used most of Amazon’s services, ranging from EC2 up to RedShift and their hosted Hadoop clusters. But when Google AppEngine came out, it only had Python, Java and GO to work with. Java is the least favorite language in my tool box – honestly, I hate it. I’ve never coded in GO, and didn’t really feel like starting out with it. And Python, well, I dabbled with it – but can’t say I’ve done something too serious with it. In 2014, Google added PHP support to Google AppEngine. Damn, that sounds cool – let’s play around with that. So, I built a few applications atop of AppEngine and the PHP SDK. I rapidly realized that while the PHP SDK gives you some power, Python is the more natural choice for AppEngine. So, I more or less sat my ass down for 3 days and decided to teach myself proper Python.

Took me about 3-4 days to get around the quirks of AppEngine and how to get it up and running using PyCharm (if you use Python, by far the best IDE I’ve seen). Then building up my first application, then migrating an existing application (a fairly big one), from PHP to Python on AppEngine. I then rapidly moved along to using easy_install, pip and the other Python tools that make life so easy for developers – honestly, right now, I can’t figure out why use anything else other than Python for shell environment tools. But, regardless of that, I honestly think Python is the first language you should teach students, not C/C++, not JAVA, not Ruby and surely not PHP (and I’m a huge PHP advocate).

Why do I say this? here are my main reasons:

  1. Python is objected oriented from the ground up, which means, that teaching object oriented programming using Python is easy and straight forward for new comers.
  2. Python is strong typed, which means that syntactical issues are dealt harshly – promoting proper usage of syntax, indentation, capitalization, variable handling – all the nice things that make good code – readable code.
  3. Python’s physical typing construct, where blocks of code must be tabulated in specific manner in order to make the code work in specific manner – is GENIUS. I’m very much a “Source Code Nazi” (Imagine that coming from a Jew, right?). For me, indentation, proper loop blocks, proper case blocks, making sure things are wrapped really tight without too many white spaces – this is what makes code look nice.
  4. Python is interpreted, not compiled – but yet, it is strong enough to hold the most complex multi-threaded of tasks.

In other words, if you take the above and teach to a new developer, someone who writes code for the first time in his life – your result will be a developer, that may not dish the best code at first (after all, a beginner), but it will be readable, manageable and maintainable. Python automatically promotes these by its structure, by its rigidness and by its agility at the same time.

As part of my academic studies, I’ve studied education and how to teach computer science to high school students. I’ve learned that you should start with Pascal or C, then move to Object Oriented, then move to more advanced stuff. I have one thing to say: BULLSHIT! Honestly, the first thing you need to teach is Python, after Python, the rest are just syntax. Nothing more, nothing less – pure, simple, straight forward syntax.

Would love to hear your opinion on this one…

Astricon 2015 Personal Wrap Up

Astricon 2015 is now over, honestly, it flew passed us really fast – at least for me it did. I will refrain from talking about the location of it – as it is more of less a geek’s paradise when it comes to movies and amusement parks. But putting that aside, let’s talk about Astricon itself.

As I see it, Astricon 2015 had distinctively two shining stars – from what I managed to collect. The first one is WebRTC, as it was definitely the talk of the corridors and within the DevCon. Be it a WebRTC controller Lego Puppy, or a connected Tooth Brush – WebRTC is definitely an exciting thing. With the growing popularity of Respoke.io among developers and its inherent connection to Asterisk – I’m confident we’re going to hear more about Respoke in the coming year.

The second one, that is naturally closer to me, is ARI. I’ve seen several people do some really innovative stuff with ARI – and more specifically, PHPARI. I was surprised to learn of a content provider in the Philippines who is using PHPARI to drive over 1500 concurrent calls, topping a total of 5 Million minutes a month – using Asterisk 13 and PHPARI. Man, what a rush! – I started PHPARI about two years ago, I personally know of thousands of installations, but till today, no one really told me what kind of mileage they were getting from it. But learning that someone is packing a 1500 concurrent calls punch with PHPARI, I was ecstatic.

Then, slightly after learning that, I participated a panel with Matt Jordan and Gaston Draque – where we discussed the status of ARI and people had the chance to ask questions. Gaston came to me after the panel saying: “You know, we had a serious fight in the company if to use PHPARI or use GO programming language”. According to Gaston, currently, PHPARI is the most complete toolkit for ARI development – man what a rush. Gaston really knows what he’s doing, I’ve seen some of his work in the past – getting this from Gaston is a serious compliment.

When my wife learned that Astricon this year will be in Orlando, she said: “Take a day off and go have some fun”. So, initially, I was supposed to fly with Eric Klein only. However, we ended up 4 of us in Orlando – which was way more fun. So, for the last day and under the excellent orchestration of Eric, a trip to the Kennedy Space Center was arranged. A group of 21 Telephony geeks got on the bus and took a trip to the Kennedy Space center. Honestly, a highly motivating and inspiring place. Think about it, NASA sent people to the moon, with computer power that is far inferior to your everyday smart phone – simply amazing.

12141558_10153564121736265_7014870291634838053_n[1]

The trip lasted the entire day – we left the hotel at around 8:30, only to come back to the hotel at around 20:30 – a full day! Honestly, if you are going to Orlando, schedule a day trip to KSC – just to see the Apollo rocket in real life – your jaw will drop!

We finished the day back at the hotel, where the first lady of Asterisk joined us for dinner at Jake’s – which was an evening filled with laughter and jokes all around.

12144766_10206916717649129_5376531960455866432_n[1]

So, what’s next? I guess I need to start putting my ass to the chair and cranking up the speed on adding new features to PHPARI .Btw, if you want to help, I will would highly appreciate it – it a work of love, but sharing it around is even better.

Astricon, Vegas and Geekness

So, Astricon 2014 is over and behind us, so now I’m now sitting at the Holiday Inn in Chicago. I have to admit that moving from the RedRock resort and Casino to the Holiday Inn in Chicago – talk about a mind blowing change. Just to give a general idea, the bath room in Vegas was roughly the size of the entire room here (mental note to self – next time order something better via BA miles).

So, this years’ Astricon was, at least for me personally, one of the best I’ve been to. Various topics that I’ve started talking about years ago, had finally made their way to the public’s ear, and the community and adopters are finally picking up on these. Security, privacy, cloud computing, proper usage of Linux and virtualization – these are now become the predominant subject people are confronted with.

Unlike previous years, I decided to talk about Cloud computing and some tips from the Cloud front line. Cloud computing, specifically cloud based servers are and infrastructure that many want to use – but very few truly understand what it means. What kind of impact does SWAP have over your instances, what is the swapiness value? and why the hell would I choose one cloud over another – aren’t they all the same at the end?

This year, we had the first ever Astrion Hackathon. I’ve participated in several Hackathons in the past, but this was very special to me. While in most Hackathons I’ve participated the participants never knew each other (well, at least 95% of them), here, most participants knew each other – some on a very personal basis. As you know, my latest Open Source passion is my own pet project – phpari. My hack for the contest was a phpari sandbox, imagine it to be a cross between jsfiddle, Asterisk and PHP. A simple use playground, where you can try various parts of ARI in general and the toolkit in particular. Much to my surprise (as there were other strong candidates), the phpari sandbox won the “Asterisk Developer’s Team” Award, for best use of Asterisk during the Hackathon. To me personally, it means a whole lot. I’ve been dealing and working with Asterisk for over 12 years now, in fact, I was joking around with Corey Mc’fadden that we are currently, probably the oldest Asterisk community members around – well, probably oej, joshc and a few others are as old as us. We never had a chance to actually see how we work together, how we think about various problems and challenges. This was the first ever time we’ve got to see each other work, how we work, how we look at things – it was exciting. Looking at Tim Panton as he battles the various concepts of Respoke and he’s application – trying to figure out exactly why “Respoke” didn’t work as he expected (amusing to say the least).

So, after Astricon, we spent the last evening going out to the Vegas Strip. I have one thing to say right now: “I don’t think I like Vegas all that much”. It’s just too much of everything. Too much “Putti’n on the Ritz” facade, too much commercialism of everything and anything, just too much for me. Don’t get me wrong, it’s an interesting place to visit, but I don’t believe that being there more than 2-3 days is required in order to appreciate the place. Be it the lights that are always bright, making you believe it is day light, the hotel that literally had no windows to the outside – so you won’t know if it’s day or night, the entire system gets screwed up totally.

So, during the night of the “geeks take over Vegas”, the following group of people decided to head to the strip:

  • Allison Smith
  • Peter – Aka: Mr Allison (hey, what do you want, you’re married to the voice of Asterisk)
  • Ben Klang (Adhearsion/Mojo-Lingo)
  • Evan (sorry, can’t recall the rest)
  • Steve (Mojo-Lingo)
  • Dan Jenkins (Respoke)
  • Eric Klein (My partner in crime)
  • Correy McFadden (Venoto)
  • Beth – Correy’s Wife
  • Steve (From South Africa)

So, here we are sitting at the cosmopolitan waiting for our table to the STK. Once we got it (at 10:45PM), we sat down at the stools waiting for our table. At the table next to us, a man and two young ladies were definitely getting it on. To be more descriptive, apart from actually going at it in front of us all, they were all over the place. As they say, what happens in Vegas – stays in Vegas. But what happens at a public restaurant, don’t be surprised to find it on Twitter. Coming to think about, we should have videoed the entire thing. Now, don’t get me wrong, I’m as much a man as the other guy, and I admit that the display was interesting (so say the least) – but comm’on, we’re a public place – get a bloody room. The funny bit was that Peter came back from the rest rooms, saying that he was delayed due it being occupied. When the door opened, two girls walked out of the same compartment – and I’ll let your imagination continue from here. So, as Eric commented on Trip Avisor – the music was loud, the service was slow – but the Steak WAS PERFECT. In deed, one of the finest steaks I’ve had in a long time.

One more thing I need to mention in our dinner (Eric and Myself) with John Draper – aka: Capation Crunch, but that’s a whole different story all together.

The Asterisk scaleability Unicorn

Ok, the picture shows a donkey not a Unicorn – as you know, Unicorns are very hard to find. Asterisk Scaleability is somewhat of a unicorn – not because it doesn’t exist, it is a little tricky to do and get it right first time.

Over the years, there had been multiple approaches to building a scaleable Asterisk platform, most of them relied on the same principals: multiple Asterisk servers, singular point of entry with load balancing, single point of exit with LCR. Normally, when you talk Class-4 services (call routing, DID services, Calling Cards), this methodology would work just fine. When it comes to Class-5 (Centrex, Voicemail, Queues), things tend to get a bit more complex – but again, the basic methodology applies and remains. Over the years, we’ve seen contenders come and go, FreeSwitch, Kamailio, OpenSIPS, SER, OpenSEMS – they are all a means to an end, just get the number of concurrent calls and CPS ratio higher.

The question is this: “Is there a singular approach to Asterisk scaleability? is there a bullet proof recipe that we can use to achieve this Unicorn type configuration?” – the answer is: NO! – it is very much dependent on your application, your client side application, your general usage patterns and what kind of agility you are looking to expose to the end consumer.

Since the inception of Asterisk, and specifically since the inception of FreeSwitch, many people had been dissing Asterisk as being a monolithic environment. Many times, if you ask someone – “what does that mean?” – you would end up with a very googly eyed face, not really understanding what monolithic means. Yes, Asterisk is by definition a monolithic environment, which means, it was designed to work a self enclosed unit. If you think about it, how many PBX systems do you know that are not monolithic. The question in that case is: “If Asterisk is monolithic, how can we scale and expand it? how can we build something really big from something like Asterisk?”.

In martial arts you always learn to use your opponents strength as their weakness, as your weakness as your strength. If Asterisk’s monolithic nature is its weakness, let’s try and make it into its strength. How do we do that? we make sure that any decision (process, calculation, state handling, etc) that is cross platform is handled outside of Asterisk, while keeping call control and media handling at the monolithic layer. This yields two distinct advantages: we can develop our cross platform logic at ease, without impacting our Asterisk development process, we can develop our Asterisk logic as a singular unit and expand it as required, simply by adding more computation units horizontally. In network and platform design there is a simple rule of thumb – growing deep is complex, growing wide is simple. If the question of scaleability becomes a question of brute forcing additional computation resources, the issue is simple. If scaling out requires changes in the computational structure – you’ve done something wrong.

Over the years, we’ve developed several large scale Asterisk platforms. These had recently hit the combined user number of 15 Million, with over 850 Million minutes served on all platforms combined. Some of these are carrier oriented, some are social oriented – but in all of them the scaleabilty factor was important. In other words, the Unicorn is out there, we’ve actually managed to find it several times, each time somewhere else – but it was always grazing in similar locations. If you keep looking for the bulls, you will surely miss the Unicorn standing at the right of the road – right next to you.

Stanley is gone – Welcome PHPARI

In my previous post I’ve announced the bootstrapping of a new PHP project, called “Project Stanley”. Project Stanley was an attempt at creating a Asterisk ARI developer kit, based upon the PHP programming language (yes, I call it a programming language).

Shortly after initiating the development and reaching a point where our code was actually able to do something, we realized that we’ve gone the wrong way. The wire frame we’ve created relied heavily on the Ellislabs CodeIgniter MVC framework. Now, don’t get me wrong, I love CodeIgniter – but, it was the wrong choice. It was wrong, because we were locking our developers into an MVC structure, that truly isn’t needed for something like this.

So, we’ve stopped working on Project Stanley (you can still find it on github if you really want to) and we migrated the code into the PHPARI project. PHPARI is a cleaner approach to providing a simple, to the point, ARI developer kit using PHP. It relies on 2 PHP external libraries – PHPWS and PEST.

PHPWS is a WebSocket client implementation in PHP, while PEST is a REST client implemented in PHP. Both are actively maintained and had been tested by multiple projects as stable and battle tested. We’ve also enabled PHPARI in packagist, you can look it up for installation. Make sure you use the dev-master part of the package, not the dev-develop – it’s unstable and may actually contain broken code.