The rants and raves of a technogeek
php
I’m no web designer – I’m a developer
Aug 10th
Lets put it this way: I am no web developer, nor was I ever, nor will I ever be. While I do enjoy playing around with various web designs and web technologies, I’m no web developer. Think about it, this blog is based upon the WordPress system, which means, that while I could easily build my own blog system – I didn’t.As most developers are, I am a lazy person – when it comes to writing code, that is. This means that when I write an application, I really like spending my time working on the application logic, rather than wasting my time on GUI. I’ve always looked for better ways to improve my applications development track, especially, the ability to seperate the logic from the display in such a way that both become agnostic to one another. So, I started looking into various MVC (Model-View-Controller) frameworks – which had been springing up all over the past year.
While the most popular one seems to be Ruby-On-Rails, I don’t like Ruby and prefare PHP. Various options exist here, so I seeked one that was easy to integrate and that is backed by a company of some sort.
Zend Framework
Much like PHP, Zend Framework appears to be a mixture of functions, closely wrapped into a set of classes, to help you create an MVC environment. I’ve started learning it, and shortly came to a conclusion: much like PHP, Zend Framework enables you a feature rich environment, however, it isn’t always clear how to get to do something with it.
CakePHP
CakePHP appears to be a slightly more rigid PHP MVC environment, with a fairly vibrant and lively community backing it up. However, like any other young community backed project, it lacks one main element: proper documentation. The documents available on the CakePHP.org website are sketchy at best, which means, there is no ordered manner of getting started fast with CakePHP.
Code Igniter
Code Igniter is a PHP MVC environment, backed by Ellis Labs – the same people behing Expression Engine. So, from a technical point of view, this is a plus, as Ellis Labs had made it its business to make Code Igniter a valid product. The amount of information available on the Internet is satisfactory, and the documentation on the website is more than good – it’s down right GREAT! The addition of video tutorials with a very clear naration enables even a novice developer to go about and start working fast with Code Igniter. The one thing that Code Igniter lacks is a rigid framework, which means, that just like PHP – it’s easy to fuck about and mess things up.
My Choice
Currently, I use a mixture of Code Igniter + Prototype + XAJAX to build my web applications, which makes for a fairly rapid development environment – I’d love to hear what you have to say about these.
Working on a new book ….
Aug 5th
As most of you reading this blog, you must know that I’ve published an AsteriskNOW book early this year. I’m happy to say that I’ve received numerous emails since the publication of the book, all asking various questions about Asterisk in general and AsteriskNOW in particular.
Most of the questions that I received were related to the development of AGI and AMI scripts, and how to utilize Asterisk as an application layer platform. This inspired me to work on additonal title, to complete my previous book. I’m currently working on an Asterisk Developers guide, for AGI/CTI development with Asterisk. The book serves as a complete guide, summarizing the various aspects of developing AGI/CTI applications with Asterisk, while, enjoying various additions from my day-to-day experience with AGI/CTI development with Asterisk. The book is written as an eye-opener for experienced developers, wishing to make their transition to AGI/CTI development, and teaches them how to avoid the most common mistakes of early day AGI developers.
I’ll be be updating the blog with my progress. Currently, chapters 1 through 5 are complete, covering the basic aspects of dial-plan and AGI development. More information will be released soon.
We are to blame…
Jul 9th
Lately I’ve come to the realization, that we are to blame for our own inability to promote Open Source and the adaptation of Open Source proficiency. Being an Open Source evangelist and consultant, this is very weird to be said by one like myself, however, this is my realization – and I will explain.
In the early days of Open Source adaptations (late 90′s, early 2000), Open Source software was a somewhat magical solution that meant: pay nothing, get more. Software packages like Linux, Apache, mySQL, PostgreSQL and programming languages like PERL and PHP had lowered the bar on the adaptation of new technologies, and enabled a prolific number of solutions and services.
I still remember the early days, when a Windows based Mail Relay would cost anything between 800$ to 1200$, and I would come in with a Linux based solution that would do the same thing for FREE – amazing. As time progressed, so did the technology and the penetration of Open Source into new fields. CRM, ERP, Telecoms, management – all of these now enjoy a diverse number of Open Source solutions. However, the original concept of ‘Open Source = Magical FREE Solution’ had still remained in the minds of managers and business people.
Today we are confronted with ‘would-be’ Open Source solution experts, which adopt and develop upon Open Source products and project various applications. In example, let’s take a look at Asterisk. Asterisk has a multitude of Open Source solutions, ranging from PBX system, Prepaid calling cards, Wholesale routing platforms, Attendance system, Presence systems – and even a plant watering solution. The problem with this ever growing number of solutions is that Asterisk is immediately considered to be: “A magical solution” capable of solving any problem – when it’s not even remotely related to Asterisk. For example, a friend of mine had been asked to develop an Asterisk based solution, that would support a total of 250 concurrent call initiations and up-to 3000 concurrent calls on the system. Any Asterisk developer would take a look at this, and would immediately say: “Hmmm…. this requires several servers, but hey, what about the application itself? that would also have an impact”. Now, the customer of the project has a ‘would-be’ Asterisk tech in his company which said: “I was able to initiate 200 concurrent SIP invites to Asterisk via SIPP, no problem’ – HELLO! STUPID! where’s the application? where’s the database? where’s the user information flow? comm’on, are you listening to yourself speak? or simply are filled with the gasses coming out of your ass that are affecting your brain?
Now, once the customer learns that Asterisk is most probably not the right solution for the problem, he becomes angry. Why? because he now learns that he needs to spend about 10 times more money than he anticipated for the creation of this tool – well, that’s life when you have no idea what you are doing/saying, and you believe in magical solutions. However, we – “The Open Source Community – is the one to blame for this scenario, because we got the world accustomed to the idea that Open Source is like magic – flip the Linux magic wand, and the rest will solve itself.
I’d like to open the floor for discussion on this, as I believe most of you will have something to say about this.
Predictive dialers enhance contact center performance – truth or myth?
May 8th
Since I’ve released my dialer framework demo about 2 months ago, I’ve been swamped with many requests from various contact centers around the world – to utilize my dialer framework for the development of a custom made predictive dialer.
For those of you who are not in the know, a predictive dialer is a tool that is capable of analyzing the performance of each agent in a contact center, accurately predicting when his current call will be completed, and thus, start calling outbound to ensure that the agent is utilized as much as possible.
Most contact center managers believe that if an agent is utilized 100% of the day (or at least a close enough number), they will maximize their profits and work will be done faster. This is not always the case, and there are some cases where predictive dialers will be nothing more than a “White Elephant”, sitting in your call center, doing nothing.
Considering the following scenario: We have a contact center selling computer insurance plans by phone. Each agent is trained to make a sale, that is: “Don’t get off the bloody phone without a credit card!”. One of the issues with such a contact center is that there is no-way of predicting how long a sale will take. Lets imagine that one call a sale happens in 15 minutes, while in the next, we start with the kid in the house, move to the older brother, move to the mother, move to the father, ending up making a sale after 35 minutes. In other words, we have no way of profiling an agent, as there is no proper profile to the customers.
So you can argue that by utilizing statistical models and proper targeting of potential customers, we can go about and perform more accurate predictions. However, these predictions will all go up in flames, the minute a deviation from the norm of the statistic happens. We then immediately create a form of ripple effect, that is then carried across the entire contact center.
In the book “The Goal“, by Eliyahu M. Goldratt, the author tells us a story about a group of boys walking in the woods. The group of boys constantly are unable to walk the path at the designated speed, due to various timing and synchronization issues. In theory, a predictive dialer is used to better synchronize the contact center intake (numbers to be dialed), with the contact center’s ability to perform (the ability to make a sale). However, this model fails when the sale constraint is unknown, thus, making the entire model fail.
In most cases, contact centers are better off using “Preview Dialers” and not “Predictive Dialers”, unless, the contact center is highly targeted with its campaigns and sale strategy. A “sell or die” contact center strategy immediately negates the possibility of accurately measuring the contact center performance and bottle necks, thus, having an automatic pace creator in such a scenario will become redundant and will most probably just cost funds.
Picasa
Twitter
Facebook
LinkedIn
wikipedia
Youtube
RSS