<![CDATA[Chris Monnat | ]]> http://christophermonnat.com/ Chris Monnat Copyright 2017 2017-02-19T13:24:43-05:00 <![CDATA[Learning at the Speed of the Web]]> http://christophermonnat.com/blog/learning-at-the-speed-of-the-web http://christophermonnat.com/blog/learning-at-the-speed-of-the-web Few things in this world change as quickly as technology. New languages, standards and techniques are coming out constantly and if you’re not staying current then you’re falling behind. It has never been more important to keep up with what’s going on in tech as the demand for top quality developers is on the upswing.

But with so much changing so rapidly, how do we stay current? Within the last two or three years we have seen an explosion in online technology training options. It’s no longer necessary to go back to school or scour the web to learn the latest and greatest technologies. With with many structure and unstructured learning options available it has never been easier for us to keep current with our craft.

Structured Options

For those among us who benefit from formalized approaches to learning there are several options available. Treehouse is a great online option that gives users access to their content for a monthly subscription fee. You can bounce around self guided if you wish or take advantage of different tracks all while earning badges as you go for extra motivation.

Virtual learning options abound but for those of you who want to get out of the house and learn with other people there are opportunities for that as well. General Assembly has locations in a number of major cities around the world and offer an array of full-time and part-time in person courses focusing on tech and business topics. They also have online options as well, but learning while physically interacting with other people is more fun!

Another great way to learn is by teaching other people. You don’t have to be an expert on a specific topic to share your knowledge with others and it has the added benefit of helping you brush up on your presentation skills too. If your company does lunch & learns then step up and get on the schedule to present a topic that interests you. And if your company doesn’t have lunch & learns currently then you should start them. They are a great way for departments/specialities within a company to share what they know with one another.

Unstructured Options

I have never been much for the formal learning approach. I’m much more of a window shopper, bouncing around from topic to topic picking up nuggets of information here and there. Luckily there are great resources for people like me too. tuts+ is my personal favorite for keeping up with the latest and greatest the web has to offer. A monthly subscription fee gives you access to regularly updated videos and an ever growing ebook library. Free tutorials are also posted on a regular basis for those not interested in a monthly commitment.

Any post about online learning options would be incomplete without mentioning blogs. There are plenty of high quality blogs pumping out content about the latest technologies and techniques on a regular basis. I have fallen way behind keeping up on blogs since Google Reader was discontinued, but two sites I make an effort to check weekly are Smashing Magaine and CSS Tricks. There are many more where those came from, feel free to add your favorites in the comments.


I used to be a big tech book reader. I wouldn’t think twice about dropping $50+ at Barnes & Noble for the latest book on PHP. Lately however I find myself spending more time on blogs or some of the other resources already mentioned. But with that said there are still good tech books published all the time and with digital access/library options available from companies like O’Reily and Packt books are still a great way to stay current.

How do you stay current with the latest and greatest web technologies?

<![CDATA[Portfolios: Not Just for Designers]]> http://christophermonnat.com/blog/portfolios-not-just-for-designers http://christophermonnat.com/blog/portfolios-not-just-for-designers Designers have all the luck. Their work is always front and center. It’s the thing that all website visitors see and comment on. “Wow, what a nice looking website!” But what about the programmers or developers that made that website work? You don’t hear any visitors saying “hey John, come look at what happens when I click this great looking link.”

I was a designer for a very brief period of my career and quickly figured out it’s not as glamerious as it looks. But in most insdustries it’s all about looks. When a designer walks away from a job they have a portfolio full of colorful and well designed work (web, print or otherwise) to wow potential employers. But what do developers and programmers have?

It’s important that you not get discouraged by the lack of glitz and glam that development work has. Without the code, a website is just a picture that doesn’t do much. But it does lack a certain wow factor when compared to the design of a site. However, remember that you’re not applying for designer jobs. Your contribution to a project will matter to the respective hiring manager when applying for a development positon, you just need to show it off.

So how can you as programmer or developer show off your work?


One great way is to contribute code to an open source project. It doesn’t have to be a huge or well known contribution, it just has to work and follow the standards of the project. Beef it up with some documentation and a narrative about what you did and you’re well on your way to showing the world what you can do.

Another great way to contribute is by creating plug-ins or add-ons for popular applications. I’ve done a lot of work with the ExpressionEngine CMS and have created some plug-ins that I released open source on Github. Again, these are the most popular or well known add-ons in the community. But their code is available on my GitHub profile and anybody can check it out for quality and thought process.

Be sure that you have a GitHub, or equivalent service account, and that you have uploaded some quality sample work.

Use Pictures

Just because you didn’t design the site doesn’t mean you can’t use a picture of it. When creating an online portfolio of your work feel free to include pictures of projects you’ve worked on. A picture is worth a thousand words and it will make your site look better. Just be prepared for the question “so what specific contributions did you make to this site?”

Also, if you’re not a designer then don’t feel the need to design your own portfolio. Some people have the gift for making nice looking websites and others, like me, don’t. That is why we are blessed to have resources like ThemeForest and other sites that will sell you great looking templates for under $50.


Every developer should have a blog. Creating a blog of your own helps you grow as a developer by posting about things you’ve learned, become a better writer by writing more frequently and a better job candidate by giving potential employers a peek at how you think and approach certain things. Just write about what interestes you when you can and you’d be surprised at the opportunities that present themselves.

What other methods have you used to promote yourself and the work you’ve done? Leave your ideas in the comments.

<![CDATA[3 Steps to Quality Code]]> http://christophermonnat.com/blog/3-steps-to-quality-code http://christophermonnat.com/blog/3-steps-to-quality-code We each have our own style and preferred way of coding. These preferences come from our experience and what feels right over time. As long as we’re the only developers working on a specific project this isn’t a problem. But what happens when you get five or ten developers all with their own preferred way of doing things working on the same project? Anarchy!

The only way to keep your sanity, and the sanity of those developers working with you, when working on projects is to take some basic steps to ensure that you are producing quality code that can be maintained and extended in the future.

1. Define Standards

Writing documentation is no fun! Nobody likes it, everybody hates it and we wish we could do without it. However, the only way that we can ensure everyone on our team is doing things the same way is to document a commonly agreed upon format/standard so everyone can follow along.

Before you spend a lot of time trying to come up with standards on your own, do some Google searches and take advantage of existing resources that are already available like the following:

Playbook standards by Thoughtbot

The playbook, written by thoughtbot, is a great resource for more than strictly code standards. With sections covering laptop setup, sales, production and more this is a great place to start your research.

Playbook standards by Thoughtbot

This open source collection of best practices and code standards for front-end development was put together by Isobar. With the source code avialable on GitHub this is a good template to start with.

Playbook standards by Thoughtbot

An oldie but a goodie, the coding standards released by WordPress are another source to reference when defining your own rules.

Playbook standards by Thoughtbot

Never one to be left out, Drupal has their own set of coding standards on their website you can reference also.

No need to reinvent the wheel here. You don’t have to use WordPress, Drupal or a specific framework to borrow from their standards. Popular open source tools help bring standardization and introduce best practices to the masses, which is ultimately what we’re trying to do.

2. Review Code

I think Smokey the Bear said it best “only you can prevent bad code.” Okay, that might not have been Smokey but it’s a true statement. Just because code has been written and “works” doesn’t mean it should be merged right in to production and deployed live with no additional oversight.

Code quality is every developers responsibility and code reviews give developers the opportunity to learn from each other and to ensure code is standards compliant before it’s pushed to production. By defining a review process and outlining how new code will be merged in to production you will create a good reliable pipline for continuous integration.

3. Leverage Existing Tools

Automation is your friend. Any opportunity you have to automate complex or annoying tasks should be explored fully. Lucky for us some tools have hit the market that help to automate parts of the quality assurance process:

Playbook standards by Thoughtbot

An automated code review service that supports Scala, JavaScript, Python, PHP and CSS.

Playbook standards by Thoughtbot

SensioLabs Insight
From the maintainers of the Symphone PHP framework comes a PHP specific tool that analyzes your code for security issues, bugs and performance.

Playbook standards by Thoughtbot

Code Climate
An automated code review service that supports Ruby, JavaScript, PHP (beta) and Python (beta).

Playbook standards by Thoughtbot

An automated code review service supporting the largest number of langauges including Python, Ruby, JavaScript, PHP, Go, Scala, Java, Haskell, etc.

It’s important to note that there is no silver bullet solution. While some of the tools above gloat about automating code review I still think it’s valuable to have humans involved in the code review process, even if it’s minimally. Human code reviews provide teachable moments where developers can learn from one another and make themselves, and not just the code, better.

It’s easy to overlook standards and code quality when you are just starting to develop a new application, especially if you are a solo developer. However, as the code base and team grows you will quickly see the issues and downsides that come with not laying down some ground rules early on. So decide on some standards, schedule some code reviews and investigate ways to automate parts of your QA process. Your application will thank you for it.

What tools or techniques do you use to ensure quality code on your development projects? Let me know by leaving a comment below.

<![CDATA[Say Hello to dashEE 2.0]]> http://christophermonnat.com/blog/say-hello-to-dashee-2 http://christophermonnat.com/blog/say-hello-to-dashee-2 It’s been way too long coming but I am finally happy to announce the release of dashEE 2.0 - the control panel dashboard framework for EE CMS.

If you’re not the video watching type, dashEE 2.0 is packed full of new and exciting things like:

  • New Interface: the dashboard has a new look sporting fewer buttons and more icons.
  • Multiple Dashboards: users can now create multiple dashboards and seamlessly tab between them for better organization and greater flexibility.
  • Widget Folders: widgets can now be packaged in their own folder within the widgets directory of a module. This is especially helpful for the development of interactive widgets.
  • Widget Models & Views: widgets can now support their own model and view files giving you the same power and flexibility that you have when building other EE add-ons like modules.
  • Install/Uninstall Methods: you can now include install and uninstall methods in your widget to facilitate actions that need to happen when a widget is first used and when it is removed.
  • Add/Remove Methods: similar to install/uninstall methods, add/remove methods fire every time a user adds or removed a widget from a dashboard. Perfect for cleaning data out of a DB table, etc.
  • Widget Specific JS: you can now include custom widget specific JavaScript with your widget and leverage the new dashEE jQuery plugin to facilitate GET/POST requests with custom widget methods in your widget file.

All documentation and other code related stuff has been migrated over to the Github repo. Check it out and let me know what you think.

<![CDATA[Creating Custom Widgets for dashEE]]> http://christophermonnat.com/blog/creating-custom-widgets-for-dashee http://christophermonnat.com/blog/creating-custom-widgets-for-dashee There’s a new ExpressionEngine (EE) add-on type in town and it’s name is Widget! We’re all familiar with the standard EE add-ons: modules, fieldtypes, accessories, extensions and plug-ins. But did you know there was an additional type that allowed you to customize the control panel homepage with your own content and functionality? It’s called a widget and in this post I’ll review how you can create your own widgets that work with the dashEE module to assemble your own custom EE control panel dashboard.

Before we get started it’s important to note that widgets are not a standard EE add-on type. To use them you first need to install the open source dashEE module which is a complete alternate dashboard with drag-and-drop functionality as well as saved layouts and a handful of other useful features. The module comes standard with about 10 included widgets but the true power lies in the ability to create your own custom widgets. Once created you can then distribute them either as stand alone widgets or package them with your modules to add extra functionality to your existing code.

Getting Started

Just like other EE add-ons, Widget file names are always preceded with wgt. and then the name of your file and followed by .php. In our example we’re going to build a widget that displays the most recent tweets from a selected Twitter feed. So if the name of our widget is Tweets then our file name will be wgt.tweets.php.

Widgets also require a language file. If the widget is being packaged with a module then you can use the modules language file. But if the widget is being distributed on it’s own you will either have to instruct the user to use dashEEs or include a language file with your widget. Each widget requires two language variables that follow your chosen naming convention: wgt_tweets_name and wgt_tweets_description. These variables are important to remember because they are used when displaying your widget in the widget listing of the module.

The code above shows the beginning of our widget file. Following the standard EE add-on naming conventions, our class name will always begin with Wgt_ and be followed by our file name which in this case is tweets. Each widget file should have at least two public class variables defined: title and wclass. The title variable is used to display the name of your widget in the widget title bar (across the top of your widget) and wclass is a placeholder for any additional CSS class names you wish to assign to your widgets container div. You can also add a settings variable if your widget has settings but we’ll discuss that later in the post. Beyond those three you will likely want a variable for the EE object and then any additional variables that you choose.

Index Method

The only real required method within your widget file is index(). This is the method that gets called by dashEE when a user has installed your widget. After loading the widget file dashEE calls the index method and packages it’s return value within the CSS wrappings of a widget and puts it together with the other widgets to assemble the dashboard. So this method is required and it’s expected to return an HTML string. Back to our example, we’ll be using the Twitter API to get the most recent tweets from a chosen Twitter user for display and then returning them as formatted HTML.

That’s it, we’re done. For the sake of testing our example go ahead and add the two language variables to the dashEE language file and upload the widget file to the widgets directory of the dashEE module. Click the Widgets button and you should see Tweets listed. Click Install and you should see the widget added to your dashboard.


One topic that has caused some confusion is permissions. Obviously if a members group doesn’t have permission to access a given module then they shouldn’t be able to access that modules widgets either. To solve this problem there is an additional method you can add to your widget file called permissions(). For our example we only want Super Admins to have access to this widget so we’ll check the users group and return FALSE if they are not a Super Admin.

A widgets permissions method is called every time the widget is loaded which ensures as a members or modules settings/permissions change the dashboard will be adjusted appropriately. You can do whatever permission checking in this method you wish, all dashEE expects in return is a boolean true if the user should be able to access the widget or false if they shoudln’t. While it is recommended that you include a permissions method with your widget it’s not required.

Widget Settings

Back to our example, the widget we have created is functional but not necessarily usable if the user has to modify the code every time they want to change the Twitter account they want to watch. To assist with this we can add a settings_form() method to our widget file to allow the user to modify the widgets settings from within the dashboard.

If your widget file has a settings_form method then an additional icon will be displayed when users mouse over it’s title on the dashboard. When clicked dashEE calls the settings_form method for the widget in question and displays it’s return value within the widget. It’s expected that this method return a form containing the settings that you want to allow the user to change.

For our example that’s going to be the Twitter username and the number of tweets the widget should display. It’s worth noting that it’s not necessary to specify the form action because the module will handle it’s submission via ajax and as for field names those are up to you. Just remember what you named your form fields because you will use those same names when referencing those settings back in the index method.

When adding settings to your widget it’s also important to declare default values for the settings in the widget constructor so your code has something to go off of when initially installed.

Now that we have our settings_form method squared away we can update the index method to reference our newly saved settings. dashEE saves all widget settings as a JSON encoded value along with the widget in the DB and that value is then decoded and passed to the index method through the $settings variable as an object. To learn more about settings you can reference the wgt.feed_reader.php and wgt.blank.php widget files in the Widgets directory as both have settings of their own or refer to the documentation.

That’s it, you’ve created your first dashEE widget. Feel free to download the completed code to refer to for help. Hopefully this has peaked your imagination and gotten you thinking about other cool things you can develop for dashEE. Visit the Widget Directory to see what other developers have created or submit your own widgets for others to download. As always post a comment with any questions or problems.

<![CDATA[Wufee - The Power of Wufoo in ExpressionEngine]]> http://christophermonnat.com/blog/wufee-the-power-of-wufoo-in-ee http://christophermonnat.com/blog/wufee-the-power-of-wufoo-in-ee I’m proud to announce the launch of my first commercial add-on for ExpressionEngine: Wufee. Wufee is an EE module for connecting your website with your Wufoo account.

Wufoo users will be able to access their forms, fields, entries and reports all from within the EE control panel. The module ships with a full featured control panel interface (see video above), an accessory so you can access your form data anywhere from within the control panel, a custom fieldtype for relating your Wufoo forms with channel entries, template tags for displaying forms and entries on your website and dashEE compatible widgets so you can access your forms and reports right from your EE dashboard.

Visit devot-ee.com for purchase information or check out the documentation to learn more.

<![CDATA[Introducing dashEE]]> http://christophermonnat.com/blog/introducing-dashee-the-missing-expressionengine-dashboard http://christophermonnat.com/blog/introducing-dashee-the-missing-expressionengine-dashboard Today I’m excited to announce the release of a new EE module called dashEE. dashEE is a completely customizable control panel dashboard alternative that gives developers the ability to create custom widgets either as stand alone add-ons or as part of their existing custom modules. Check out the Github repo for more details.

<![CDATA[Make Phone Calls with Code Using Twilio]]> http://christophermonnat.com/blog/make-phone-calls-with-code-using-twilio http://christophermonnat.com/blog/make-phone-calls-with-code-using-twilio Web applications are better than old school applications that get installed on your hard drive because you can access them from anywhere using the web. They do however suffer from the same limited communication channel as typical software because they can only interact with users via the computer. Users provide input via the keyboard and the app provides output via the screen. Wouldn’t it be cool if we could take advantage of other communication channels like phone and text messages to communicate with our users? Well now we can with the help of Twilio. In this post I’ll walk you through building an application that can make phone calls and send text messages using the Twilio API.


For those of you who don’t know, Twilio is a web service API that empowers programmers with the ability to make phone calls and send SMS text messages programmatically. I first came across the service a while back and have been keeping an eye on it ever since because I think it has a lot of potential uses in modern web applications. In the past, having your application make a phone call used to entail a lot of programming and hardware overhead ($$$). Twilio makes it as simple as one single API call (that doesn’t break the bank) and you’re done.

In this post I’m going to be building a sample application to illustrate some of what Twilio is capable of. Have you ever used a website or other service that required you to confirm your phone number by receiving a call and then entering a code given to you over the phone? Well that’s what we’re going to build. The concept is that a user fills out a generic registration form on your site and includes their phone number. Upon submission we will leverage Twilio to call the user and recite a 4 digit confirmation code that they will then have to enter in step 2 of the registration process. Upon validating the entered code from step 2 we will either send the user a SMS text message confirming a successful activation or display an error.

For the purposes of this example I am leveraging the CodeIgniter framework simply for the sake of development speed. The code that actually interacts with the API can easily be transplanted into any application and still work. When it comes to interacting with the API, Twilio has a number of client libraries to choose from. Our weapon of choice is PHP, so I will be using the PHP client library.

To make things a little easier I’m providing two downloads, one is the complete source code with all the code included. The other is just the framework preconfigured with the necessary libraries and helpers. This way, if you want to follow along, we won’t have to waste a lot of time setting up and configuring CodeIgniter.

Step 1 - Get a Twilio Account

Before you can access the Twilio API you first need to create an account to get access information. You typically have to pay to use Twilios service, but they do provide a free trial that comes with $30.00 worth of credit which you can use for the purposes of this example.

Visit https://www.twilio.com/try-twilio and fill out the provided form.

After creating your account, and logging in for the first time, you will be presented with your account dashboard.

Your account dashboard is a collection of all of your account information in one easy to understand and access place. This is where you will find your Account SID and Auth Token. These are the two values you will need in order to make API requests. The dashboard also shows your account balance along with a rough calculation as to how that dollar amount translates into API requests. Your developer sandbox information is also displayed here, however we won’t be doing anything with the sandbox in this example.

The other thing you will need to do before continuing is to setup an outgoing called ID number within Twilio. For obvious reasons you can’t just go placing calls and sending text messages from any old number. You first need to enter and confirm a caller ID number within your account and then you can use that number when making API requests.

Within your Twilio account click Phone Numbers from the sub nav. At the bottom of this screen if where you can manage your called ID numbers. Click the Add Caller ID button and enter your phone number. Twilio will call you and request you enter a confirmation code (similar to the app we are about to build). After entering the code you should be all set.

OK, so now that you have your API access information and have setup your caller ID your ready to jump in and get coding.

Step 2 - Setup

If you have not done so already, download a copy of the source code (blank or complete) and unzip the archive onto your desktop. For our registration example you will need to create a database and update CodeIgniters database settings (/application/config/database.php) with the appropriate access information. Once you have created your database, use the following SQL statement to create the one table we will be using.

Now that you have created your database and updated the code you can upload everything to your development environment. You will notice that if you bring up the application in a browser you will most likely get an error. That’s because we haven’t created our default controller yet, but that’s the next step.

Step 3 - Create the Controller

Now that we’re up and running with our code and database we can get to coding. First thing to do is create a new controller called register.php in /application/controllers. When a user first visits our application we want to display our registration form so let’s setup our controller to do that by default.

The above code leverages CodeIgniters default controller function index() to automatically display our registration form when a user first visits our application. Now we need to create our registration form view file. Create a new folder in /application/views called register and a new file in that folder called index.php.

This view file contains just a simple four field registration form the user will complete to begin the registration process. Save and upload your changes and when you visit the application in a browser you should see the following form displayed. But before we go much further be sure to update the class variables at the top of the controller with your Account SID, Auth Token and caller ID number. Please note, the caller ID number should start with a plus sign (+), include the country code and have no hyphens.

Step 4 - Access the API

We now have our controller and registration form. You may notice however that when you submit the registration form nothing happens. The form is looking for a controller function called confirm(). This function will begin our user registration process by validating the form input, generating the users confirmation code and contacting the Twilio API to call our user and recite the code. Let’s go ahead and create this function now in our controller.

The majority of this code should be pretty self explanatory (for those familiar with CI) but let’s review just to be safe. The first 13 lines are all about validation. We are using CodeIgniters form_validation library to validate our form input and ensure we have valid data. If there are any errors we display the form again with error messages. On line 19 we create a random 4 digit number that we will use as our confirmation code. This is the code we will pass to Twilio to recite to our users and then test for in step 2 of our process. This will be stored in our database along with our other user data. Lines 21-31 handle the database insertion for our user record using CIs active record library. 33-38 are where we contact the Twilio API and make our request to call the user (I’ll review these lines in a moment). The remainder of the function displays step 2 of our registration form which is just a single field asking the user to enter their confirmation code. Before we forget let’s create this new view file called confirm.php in /application/views/registration.

As I mentioned above, lines 33-38 are where we actually make our API request to Twilio.

The first thing we do here is determine if we need to make the call or not by checking the $call variable passed to the function. I put this in here to avoid making additional API calls if the user enters a wrong confirmation code (this will make sense later on). Next we create a new instance of TwilioRestClient which is the PHP client library and pass it our Account SID and Auth Token for authentication. Using our new TwilioRestClient object, we make a request to the API using the request() function. This function takes 3 arguments: the path to the API method your calling, the type of request your making (POST, GET, etc.) and any data you are passing along to the API (as an array).

Something to make note of here is the path to the API method we are passing. In a rather odd turn of events, each API call must include your Account SID. I find this rather odd and verbose but alas it is required. There are ways to make this easier to use within your code by making a minor modification to their library, but I chose to keep things just the way they provide for the purposes of our example.

So we are calling the /Accounts/Calls API method and passing it a “From” phone number, “To” phone number and “Url” to handle the call. The “From” number is the phone number the call will be made from (your Twilio called ID number). The “To” number is the number Twilio will be calling. It’s worth noting that this number must inclue the country code and contain no hyphens. The code should probably include some sanitization to ensure this, but I kept it out for simplicity. Finally the URL to handle the call is where Twilio will look for instructions on what to do for this call. This is where we have to provide it with instructions using TwiML or Twilio Markup Language.

Step 5 - TwiML

There is an entire section of documentation dedicated to TwiML, so I don’t intend on spending a tremendous amount of time on it. Suffice it to say it is the XML format that Twilio expects when looking for instructions on what to do when placing a phone call. You have several options to choose from but all we care to do is place a call and read a script. Let’s go ahead and create a new function in our controller called handle_call() to generate the necessary TwiML.

The above code basically creates the following XML document.

The first thing we do here is find our user based on ID in the DB. Next we take their confirmation code and put spaces between the numbers. Without doing this Twilio will pronounce the number as a complete number instead of digit by digit which would be a bummer for our users. Finally we put it all together in a script and call the addSay() function adding a loop attribute of 2 to make sure Twilio repeats the message twice. If you were to visit this function in your browser (/registration/handle_call) you would hopefully see the XML I provided above as an example.

Step 6 - Confirmation

We now have the majority of our application in place. The only thing we’re missing is the processing code to handle step 2 of our registration process. Let’s create a new function in our controller called confirm_code() to handle the final bit of validation.

The above code processes the confirmation code submission and checks to see if our user entered the correct code or not. If correct, we send the user a SMS text message using Twilio and display a view called account_activated.php. If incorrect, we simply display a view called account_error.php. Let’s create those two views now in /application/views/register.

The code for sending the text message is very similar to the block we used to make the phone call above.

This time we are requesting the /SMS/Messages API method to send a text message and passing along “From”, “To” and “Body” as parameters. Just like above “From” is the phone number we are sending from (our Twilio caller ID number), “To” is the number we are sending to and “Body” is the actual content of the text message. It’s worth mentioning that text messages don’t require any TwiML instructions, only phone calls.

And there you have it. If you save and upload your changes you should now have a functioning example. Enter your phone number in the phone number field of the registration form (being sure to include the country code and no hyphens) and hit submit. You should shortly receive a phone call reciting your confirmation code. Enter that code in the confirmation code form and submit. You should then see the success message and receive a congratulatory text message.


When I was first building this app I was not having much luck with placing phone calls. Twilio would call me but say there was a system error and then hang up (very frustrating). Come to find out that I had my site password protected and it couldn’t get to the handle_call() function for the TwiML instructions. The point of this story is I wouldn’t have been able to figure out what the problem was without the Twilio Debugger available through your Twilio account.

The debugger, available when you log-in and click Debugger from the sub nav, is your first stop when trying to deal with Twilio issues. It should give you the information you need to determine what the problem is. There is also some documentation available to help you deal with common issues. And if all else fails you can contact support for additional assistance.


This is obviously not a complete and well polished application but it does illustrate some of what Twilio is capable of. Some possible enhancements to this code could include adding a country code drop down menu to the registration form so the user doesn’t have to enter it as part of their phone number, better phone number validation to ensure processing and maybe e-mail integration since we are collecting the users e-mail address. Feel free to experiment on your own and let me know how you make out by leaving a comment.

I know this was a long post but thanks for sticking with me. To learn more about what Twilios capable of, be sure to visit their documentation and implementation gallery.

<![CDATA[Building Applications using CodeIgniter (Part 4) - Code Templates]]> http://christophermonnat.com/blog/building-applications-using-codeigniter-part-4-code-templates http://christophermonnat.com/blog/building-applications-using-codeigniter-part-4-code-templates Last July I wrote a post entitled “What does your code say about you?” In that post I discuss the importance of writing clean well formatted code. It’s vitally important, even if you are the only programmer working on a project, that you document and format your code because you may be the only programmer now but who knows about 6 months or a year from now. Plus, as a programmer, the code you write is a direct reflection on you as a professional.

So far in this series I’ve discussed my typical application structure, configuration and helper files when developing apps using CodeIgniter (CI). In this final post I’ll review creating code templates for quick consistent development.

There is nothing really functional/technical about code templates. Templates are a set of simple files that have the basic document structure for the specified file (controller, model, library, etc.) that you use as a common starting point when creating any new file for your app. Your template should contain common elements to all files like the header comment block, class declaration, constructor, etc. There is no need to come up with your own standard when creating your templates because CI has a very nice style guide you should follow.

CI Style Guide

A few versions ago, CI added a page to their users guide entitled PHP Style Guide. In this section they do a great job at outlining the proper format when declaring variables, writing comments, naming files, etc. This is a great place to start when creating your templates. If you don’t already, you should think about getting in the habit of following these standards (even if you aren’t programming with CI) because they will help keep your code clean and consistent.

Template Files

Before I start coding my app I typically create a template file and place it in the controller and model folders. The templates are different of course, but they both create a nice starting point whenever I need to create a new file. It’s important to note that you don’t necessarily have to create physical template files to accomplish clean and well formatted code. Some tools like Coda and TextMate give you the ability to save bits of text and reuse them in your files. So you could create your header comment block and save it in your editor and just call upon that whenever you create a new file. Doesn’t really matter how you do it, it just matters that you do.

That’s a Wrap

OK… lecture over. That does it for the building applications using CodeIgniter post series. If interested, you can download a copy of the final CI install that we’ve created over the last 4 posts with helpers, code templates and all.

I hope by sheding some light on my process and explaining how I do things you came up with some ideas on how you can improve your own CI apps. As always, feel free to leave any questions or feedback as a comment below.

<![CDATA[Building Applications using CodeIgniter (Part 3) - Helpers]]> http://christophermonnat.com/blog/building-applications-using-codeigniter-part-3-helpers http://christophermonnat.com/blog/building-applications-using-codeigniter-part-3-helpers So far in this series we’ve discussed framework/application structure and configuration information. The next thing I always add to new applications is some common helper files I’ve developed and that come in handy in most projects. CodeIgniter (CI) helpers are very flexible tools to assist with common tasks throughout the app. If it doesn’t belong in a controller and is too small for a custom library then a helper might be just what the programmer ordered.

What belongs in a helper?

Something I’ve struggled with in the past is determining when a certain function or process belongs in a helper file and when it would be better off elsewhere. There is no cold hard rule for determining when something belongs in a helper and when it doesn’t but you do need to be aware of the following:

“Unlike most other systems in CodeIgniter, Helpers are not written in an Object Oriented format. They are simple, procedural functions. Each helper function performs one specific task, with no dependence on other functions.” - CI Users Guide

This means that in order to access libraries and models within your helper functions you will need to get a CI instance:

$CI =& get_instance();

With the technicalities out of the way let’s take a look at the 2 helper files I’ve developed: display_helper.php and  flash_helper.php.


A lot can be accomplished with CI’s built in templating but there are still some things that require logic and therefore fit nicely within a helper function. The display_helper.php file holds a number of common HTML display functions that I use throughout my program view files. To see what this file looks like, download an example. The functions in this file are pretty self-explanatory but I will briefly describe what each does below:


The display_error() function displays a properly formatted HTML error message. I have this function setup so it can display 2 types of message: standard and form. When using the form_validation library I use the set_error_delimiter() method to wrap my error messages in list item tags and then display form error messages as unordered lists. So, I can easily accomplish displaying both types of messages using this function just by passing some variables.


This function just displays a properly formatted HTML message. This doesn’t necessarily need to be in a helper function because it’s so simple. But, the nice thing about having it here is if I ever decide to change the format of my messages I just need to come here in one place and make the update. So it consolidates my code nicely… but the same could probably be accomplished by using more generic CSS ID names.


You should always identify required fields on your forms so users know what they need to fill in and what can be left blank. I’ve put the display of this flag in a helper function again to consolidate my code. As with the display_msg() function, if I ever decide to change my required field flag I just need to come to this one place and change it instead of going into all my view files and going a find and replace.


JavaScript confirmation messages come in handy when you want to check with a user to make sure they are sure of something before you do it. You can accomplish the same confirmation by writing more PHP but that takes more work. The js_confirm() function, when used with the default CI URL helper anchor() function, displays a browser pop-up message with whatever text I pass to the function. If I’m in a hurry and don’t provide a message the function just returns a generic “Are you sure?” message.

Your display_helper file might look much different than mine, this is just an example of how I use it. But you want to be on the look out while your coding for repetition and little details here and there that might be changing down the road. If you can consolidate those things in a helper file you will end up saving a lot of time updating down the road.


CI added flashdata to it’s session library a few versions back and I for one was happy to see it. Flashdata allows you to pass messages for display between pages.  Simple status messages like “record added” or “record not found” can be placed in a flashdata variable and then displayed after the user is redirected to another page. A very handy tool for letting your users know the results of their actions.

While I do like this functionality, writing $this->session->set_flashdata(‘item’, ‘value’) and $this->session->flashdata(‘item’) every time I need to set or get something is a lot of typing. So the flash_helper is a pair of wrapper functions that handle the job of setting and displaying flash messages for me. To see what this file looks like, download an example.


The display_flash() function displays a selected flash message in a view file. Simply provide the name of the flash variable and it will display it in a properly formatted HTML div.


This function sets a flash variable with a value I specify. Since I use flash variables for a lot of different messages, which I may need to format differently, I also use this function to store some formatting data along with the message. That way when I display the message it is automatically displayed using the CSS style I intended.

The flash_helper file is based on the same concept that Michael Wales posted about a while back. I would link to the post but I can’t seem to find it anymore.

Last up: Code Templates

That wraps up the 3rd installment of this series. In the next, and final post, I’ll discuss creating code templates to help you maintain consistency between your files.

<![CDATA[Building Applications using CodeIgniter (Part 2) - Configuration]]> http://christophermonnat.com/blog/building-applications-using-codeigniter-part-2-configuration http://christophermonnat.com/blog/building-applications-using-codeigniter-part-2-configuration The framework that you use to build your application will end up being the foundation of your program. Everything that your program does will revolve around how that framework works. Things like naming conventions, file paths and settings are dictated by the framework. But if you have chosen a good framework, like CodeIgniter (CI), you will be able to manipulate how that framework works and the tools it makes available to you by modifying it’s configuration information. In the first post I talked about application file structure. Now that the structure is solid I’m going to look at how I configure the framework so that it works the way I expect.


All of CI’s configuration files are stored in application/config.

  • config
    • autoload.php
    • config.php
    • constants.php
    • database.php
    • doctypes.php
    • hooks.php
    • mimes.php
    • routes.php
    • smileys.php
    • user_agents.php

The purpose of each file coincides with it’s name. To get us up and running we are only going to worry about autoload.php, config.php, database.php and routes.php.


The config.php file is the main configuration file for the framework. In this file you can control things like logging, character sets, extension prefixs, etc. The folks over at EllisLab have done a great job at commenting this file so I’m not going to go through the whole thing. The only thing I’m going to change here are lines 14 and 26.

Line 14 holds the full web path to your CI installation. In the past I used to type this in by hand until I had the need to write portable apps that could be distributed and installed without much configuration on the users end. Since then I have resorted to using this code I found on the CI wiki. By replacing line 14 with that code you can set this variable and forget about it. Wherever your program ends up this config variable will be set automatically so you don’t have to worry about it.

Line 26 of the config file holds the name of the index file. Since I use search engine friendly URLs where ever possible I just delete the value and leave it blank (just like the comment tells you to do).


Now that the config.php file is taken care of we turn our attention to the tools we need to build out app. What libraries, models, helpers, etc. are we going to need on a regular basis throughout the entire app? The answer to this question will probably differ based on what app your building, but I have found there are a number of common files I always load throughout any application:

Libraries - database, session

Helper - form, url, display, flash

Config - program

The libraries above, database and session, are the default CI libraries to handle database abstraction and user sessions (note, if your app doesn’t use a database consistently throughout the whole app you might not want to autoload this library). The form and url helpers are both default CI helpers but display and flash are two custom helper files I’ve developed to assist with some common tasks. I will discuss helpers in the next post. Finally, program is a custom config file that I create for all my applications which I will discuss shortly.


If you are app is interacting with a database then you need to update the database.php config file. This file stores the access information for the database or databases that your app will be interacting with. This file is pretty self-explanitory so I’m wont go to delve into it.


The routes.php file allows you to define custom URLs and map them to specfic controllers and methods. This is a very powerful tool that comes built into the CI framework. The only thing we want to update in this file to get started is line 43. Right now it’s set for the default welcome message we saw before. I usually set this variable to home just because it’s pretty generic and tends to work well in URLs but you can set it to whatever makes sense to you and your app.


Now that I’ve discussed all the default CI files, I’m going to create a custom config file called program.php (the same one we auto-loaded above) and place it in the config folder. This file will store all the application wide configuration settings and information that I will be referring to both programmtically and manually. To see what this file looks like you can dowload an example for reference.

At the very least this file will always have 2 variables: ci_version and program_version. Both are pretty straight forward in purpose, ci_version stores the current version of CI that I’ve used to build the app and program_version is the current version of my app. I’ll typically call upon the program_version and display it in the footer of the app and knowing the version of CI running comes in handy when updating or making any framework modifications.

When building an app of any size you always want to build in a quick and easy way of taking the app offline. I accomplish this with the status variable. If the status is true then the program is online and everything is operational but if it’s false then things are offline. By creating a config variable for this I can easily refer to this flag throughout the program to determine whether or not input should be accepted and processed.

Another thing I commonly store in the program config file is e-mail settings that will be used whenever an e-mail is sent from the app. This commonly consists of the from and reply-to address and names. Again, by storing this information here it’s easily accessed whenever sending an e-mail.

Your program config file can store any type of system wide configuration information that your app will need to reference from many places. You could theoretically store this configuration information in a database but then you wouldn’t be able to take advantage of the native CI config tools available. In the end it’s up to you.

Next up: Helpers

That wraps up configuration. In the next post I will review some custom helper files I’ve developed and autoload in most of my applications.

<![CDATA[How to Ensure a Secure Connection Using PHP]]> http://christophermonnat.com/blog/how-to-ensure-secure-connection-using-php http://christophermonnat.com/blog/how-to-ensure-secure-connection-using-php When submitting sensitive information over the web it’s important to ensure that the requested page is being accessed via an HTTPS encrypted connection. I’ve come across some forms that don’t check whether a secure connection has been made or not. In other words, you can delete the S from HTTP and instead of redirecting the user back to the HTTPS connection the form is just displayed unsecured. This is a BIG NO NO… as a programmer you cannot rely on the visitor, or even other developers who would be linking to the form, to request a form securely. In this post I will review how you can ensure that your users are accessing certain pages using a secure connection.

The Server Superglobal

How can you tell if your user is requesting a certain page using a secure connection (HTTPS)? Enter the PHP server surperglobal.

$_SERVER is an array containing information such as headers, paths, and script locations. The entries in this array are created by the web server.” - PHP Manual (http://www.php.net)

There are 2 elements within this array that you can check that will tell you whether the user has made a secure request or not: https and server_port.

Programmer Beware

Something to keep in mind is that each web server will provide or not provide certain information in the $_SERVER array depending on their configuration. The PHP manual also points this out:

“There is no guarantee that every web server will provide any of these; servers may omit some, or provide others not listed here.” - PHP Manual (http://www.php.net)

So I guess that brings us back to the original question: how can you tell if your user is requesting a certain page using a secure connection (HTTPS)? Of the 2 elements mentioned above, server_port is part of the CGI 1.1 specification so the chances are good that element will be available in most servers. You can check for the availability of the https element if you wish but you should also include a check of the server_port as a fallback.

The Code

There is a good code example in the comments of the PHP manual of a function that checks whether or not the user has made a secure request:

This example function makes use of both the https and server_port elements of the superglobal array and also takes into account the different values that might be provided based on the web server. The only thing I will mention about using the server_port element is to make sure you know what port your server is using for HTTPS connections. I believe 443 is the standard, but ports can be changed so you just want to make sure you are checking the correct port for your server.

What about CodeIgniter (CI)?

If your programming using CI, you could certainly put the function above in a helper and call it whenever necessary. Or, a technique I’ve used successfully in the past, is to put the check in a custom library and auto load it. When you do it this way the connection is tested every time a page is loaded automatically without you having to make any additional function calls. And instead of returning TRUE or FALSE you can simply redirect the user to the requested page using HTTPS instead of HTTP which truly automates the process.

One thing that can trip you up when making secure connections using CI is the address you’ve entered on line 14 of application/config/config.php. If you enter just a static address starting with HTTP then HTTP will be used when calling any URL helper function like site_url() or anchor(). To avoid this issue,  you can replace line 14 with the following code from the CI wiki:

This code will automatically set the base_url config element so you don’t have to. This also comes in real handy when writing portable code that you want to distribute to other users or clients for installation on their own servers.

That’s a wrap

That does it for making sure your files are being accessed securely. If you have any questions or use a different technique for checking secure connections please share them by posting a comment.

<![CDATA[Building Applications using CodeIgniter (Part 1) - File Structure]]> http://christophermonnat.com/blog/building-applications-using-codeigniter-part-1-file-structure http://christophermonnat.com/blog/building-applications-using-codeigniter-part-1-file-structure Creating web applications with CodeIgniter (CI) is quick and easy because CI handles a lot of the typical application requirements right out of the box (like session management, database abstraction and file uploading). I’ve developed a number of applications with CI now, including BadgeTracker and Sign-Up-Sheet.com, and while CI does handle the repetitive stuff it’s still up to you to create a scalable and easy to update application. Over the last couple of years I’ve come up with a pretty solid structure and set of files that I use whenever I’m building a new app and in this series I’m going to show you what I do so you can get ideas for your own apps.

In this first part of the series I’m going to talk about file structure. The first step to building your app is to get your folder and file structure setup so you have an idea where everything is going to go. If you wait to figure this out as you go along you run the risk of inconsistencies in your code so it’s good practice to just settle on a structure first thing.

CodeIgniter Default

By default, CI (version 1.7.1) presents you with the following structure:

  • system
    • application
      • application folders…
    • cache
    • codeigniter
    • database
    • fonts
    • helpers
    • language
    • libraries
    • logs
    • plugins
    • scaffolding

Everything lives inside the system folder. This isn’t necessarily a bad thing, but every time you want to get to your application to add or update files it’s just a hassle to go into system to get to your application. So, it’s pretty common practice to move your application folder outside of the system folder so it’s front and center in the document root (or whatever folder your developing in).

To accomplish this you will need to update the main index.php file outside of the system folder. Line 43 needs to change to “../application” instead of “application”. Once that update is done then CI shouldn’t be able to tell the difference.

Application Assets

It might be because I’m a neat freak or maybe it’s because of the brief exposure I had with Ruby on Rails (RoR) but I don’t like having my application root littered with folders for images and JavaScript files and such. I like a nice clean document root. So I create a folder at the root of my application called assets. Inside the assets folder I create 3 other directories for images, JavaScript and CSS files so it looks something like this:

  • assets
    • images
    • js
    • css

Now all of my non-php files are nicely organized in a single directory at the top of my application. From time to time I’ll also add a directory for videos but you get the idea.

Template Files

Another one of those common application tasks that CI handles, like I mentioned earlier, is templating. The views folder (inside application) makes up the V in MVC and that’s where all your design/display files should go. It’s taken me some time but I’ve settled on a pretty standard way I handle my application templating and it all revolves around a folder I create within views called _templates.

Instead of loading a bunch of view files one after another to make up my page, I prefer to create layout files which are complete web pages just with some variables acting as place folders for content to be inserted later. When it’s time to display a page I load a couple of partial views into variables (by returning the views as strings instead of displaying them) and then passing those variables to my master view file for display. The main benefit of this type of templating structure is that your whole application can use a just a hand full of layout files to handle page structure.

Within the _templates folder I create another folder called layouts. This is where the actual layout files live. Other include/template files are placed inside the _templates folder that are included in more than one layout file like navigation elements and such. I will also typically create other folders within _templates for things like system e-mails and the like.

Final Structure

That just about does it for our structure. I’ve listed the new structure below with just the new directories we should be left with and where they live.

  • application
    • views
      • _templates
        • layouts
    • assets
    • css
    • images
    • js
  • system

At this point I typically move the files to the development environment and make sure the default CI welcome message is displayed. If your following along at home and don’t see the welcome screen you more than likely didn’t make the change to the index.php file I mentioned above when we moved the application folder outside system. Double check that and if all was done correctly you should be all set. If you continue to have problems, leave a comment and I’ll see what I can do to help.

Next up: Configuration

In part two of this series I’ll talk about configuring CI to load the common libraries we’ll need and creating a custom config file to keep information specific to our application.

<![CDATA[Zend PHP Certification: Necessary or Not?]]> http://christophermonnat.com/blog/zend-php-certification-necessary-or-not http://christophermonnat.com/blog/zend-php-certification-necessary-or-not I have to start this post out with a quick apology for the lack of recent posts. There is a lot going on right now: working on ScoutPath (which launches in June), putting out fires in BadgeTracker and working full time at my day job. All of this leaves little time for blogging (or anything else for that matter). Another thing I’m working on is getting my Zend PHP 5 certification and that brings me to this post. A couple of years ago when Zend first announced the certification I was determined to get certified but just haven’t put my mind to it until recently. However, after studying for the last couple of weeks and taking the practice tests I am left wondering what this certification proves and whether it’s truly worth it.

The Test

For those of you not familiar with the test let me break it down for you:

  • 70 questions
  • a combination of multiple choice (with multiple answers) and short answer
  • you get 90 minutes to complete

The test is taken on a computer in true Who Want’s to be a Millionaire fashion, just without Regis. When done you are told whether you have passed or failed. Now the whole computer test thing is bugging me a little because I had an incident back in college where my laptop shit the bed during a programming final and I was only able to complete part of the test. But I’m sure the test producers have thought of all that ;).

What does it prove?

If I displayed a big long code block here with 2 or 3 lines blanked out with question marks and then asked you to tell me what code should replace the question marks to achieve some final result, could you do it? That’s just one example of the questions asked on this test and I’m racking my brain trying to figure out what knowing the answer to that question proves. Does it show that I know PHP or that I just know the subject matter of that particular script? Or that I can understand confusing questions?

I think the question of what a particular certification really proves pops up now and then within the professional community when people try to put a weight to a specific accomplishment. Is it the difference maker between getting the job or being shown the door? I don’t necessarily think so but that’s a determination each person or company needs to make for themselves.

Is it worth it?

The test costs $125 and your free to spend anything above that on various preparation methods but all considered it’s a pretty cheap proposition. When you pass you are added to the Zend Yellow Pages and you get access to the Zend Certified Engineers LinkedIn group. You can also download a nifty badge to put on your blog and resume but overall these are nice perks. These are in addition to putting it on your resume and such as well which helps you get noticed by employers and bosses and such too.

So, is it worth it? I think so, but that’s a determination you will have to make for yourself.

Wrap up

Becoming PHP certified is a nice feather to put in your cap to differentiate you from the thousands of other PHP programmers out and about. What the questions actually prove is still up for debate but overall I think it will be a good thing. I’m taking the test on Friday so I’ll be sure to post a follow-up on the whole certification process next week.

Stay tuned!

<![CDATA[10 Reasons Why MediaTemple Rocks]]> http://christophermonnat.com/blog/10-reasons-why-media-temple-rocks http://christophermonnat.com/blog/10-reasons-why-media-temple-rocks I understand that I might be coming a little late to this party, but I thought it deserved a post anyway. A little background first, up until about a week ago I had a virtual private server (VPS) with HostMySite.com (HMS). I had been a customer of theirs for about 2 years and was pleased with the service and offerings. But recently I wanted to try some new things that required an updated version of PHP. HMS said I couldn’t get the newer version of PHP without upgrading my account and changing control panels over to CPanel. Needless to say I was saddened by this news so I started shopping around.

Below are my 10 reasons why I switched my hosting over to (mt) Media Temple:

1. More Bang for the Buck

Let’s face it, web hosting has become a commodity. There are so many providers today that you can always find one that does it cheaper or gives you more for less. The only true litmus test that I have been able to find is the companies reputation among other developers and who their customers are. I’ve heard a lot of good things about (mt) for a while, they almost have a cult following among certain bloggers. I even  gave them a serious look two years ago when I was shopping but their lack of “hold my hand” support scared me away.

This time however I took a look at their (dv) Dedicated-Virtual numbers and was very pleased. I need at least 512 MB of ram because of what I run on my server so their Rage offering caught my eye, 40GB of disc space and 1.5TB of bandwidth for $100.00/month. It was $40 more a year than HostMySite would have been but (mt) had the version of PHP I wanted along with Plesk. I called their sales team and was sold the next day.

2. The Right Version of PHP

Those of you that don’t use the Plesk server control panel won’t have much of a reference, but for those of you that do will probably understand. Plesk ownes your server. You have to be very careful when making changes via SSH to make them in such a way that it won’t break Plesk or be overwritten the next time Plesk reboots Apache. So when HMS told me I couldn’t install the new version of PHP I sort of understood but was bummed all the same. Then I found (mt) and they claimed to have the new version of PHP, MySQL and running Plesk. This was a major selling point for me.

3. The Right Kind of Support

Ask anybody and they will tell you that Chris Monnat is a software person… not hardware. So when it comes to server administration I am very leary. In the past I have always looked for hosting companies that offer what I refer to as “hold my hand” support. Whether they are supposed to help me or not I can call them up with a question or request and they are able to assist me or at least point me in the right direction. I guess in the industry this is referred to as completely managed hosting. But over the years I’ve learned some things about server administration and have become more comfortable with doing things on my own.

(mt) comes right out and says they are not a managed hosting provider. They will make sure your server is running, the hardware is working and that it is connected to the web… the other things are pretty much up to you. That concerned me in the brginning, but then I saw their Knowledgebase and user forum. The Knowledgebase is full of step by step how-to’s on topics I would used to call support to help me with. Now I just bring up the instructions and do it myself. In the end (mt) offers less support than I’m used to but I feel better about it because I’m learning more and getting more experience myself. It’s totally cool!

4. Backups and a Firewall

When you talk to most people they have their own system setup for making backups of their sites. Whether it’s automatic or manual they each have a way. With the version of Plesk I have through (mt) the backup utility is enabled so now I can have Plesk take care of all of my backing up on a scheduled or manual basis. I can even have Plesk FTP to backup to another account or server for off-site storage and it doesn’t cost me anything extra. For those who need a little more, (mt) also offers Snapshot Backups for an extra $20/month.

Firewalls are another one of those things that most hosting companies try to charge you extra for. The Plesk install on my (dv) came with a software firewall module available and (mt) provides isntructions in their knowledgebase to help me configure it. So right off the bat I can have a more secure server with a software firewall I can configure myself without spending any extra money.

5. Update Option Program

This was the #1 thing that made me sign-up with (mt). Those of you who use Plesk can probably share my pain when I talk about updating the Plesk control panel software. Parallels, the makers of Plesk, provide an automatic updater within Plesk to help with updating the software but my fellow Plesk users and I know it doesn’t work and potentially leaves your server in a diminished state. (mt) knows this and that’s why they offer the update option program (UOP) which will automatically upgrade Plesk for the servers that are enrolled. (mt) goes to great lengths testing and configuring new Plesk versions to make sure it doesn’t break anything before pushing updates out. So you get the benefit of running updated Plesk software without the hassel of doing it yourself and enrollment in the UOP is free of charge.

6. Simple Account Center

You don’t really know how important an easy to use account management tool is until it’s gone. (mt)’s AccountCenter (where you go to manage your billing, contacts, etc.) is very nicely designed and super easy to use. You can use the AccountCenter to manage your domains host records on their name servers, add new domains, manage your server, manage billing, manage account contacts and request support from (mt)’s support team. It’s very well done.

7. DNS Done Right

Using (mt)’s AccountCenter you can purchase new domains and add existing domains to your hosting account. Once they have been added you have the ability to modify host records for each domain hosted with (mt) so it’s simple to add txt records and setup Google Apps. The nicest thing I noticed with (mt)’s DNS tools is the ability to manage reverse DNS for each domain. No need to call or e-mail support to make a modification to the reverse DNS, you can now do it yourself all through their AccountCenter.

8. Recovery & Issue Management

“Server administrator heal thyself!” (mt) makes it easy to help yourself when disaster strikes. Using the AccountCenter you can revert your (dv) back it it’s original state when you first purchased it with the link of a link. You can also reset the firewall rules on your server in the event that you accidentally lock yourself out. And one of the most useful things is the ability to add additional disk space temporarily. If your server fills up you can temporarily add 1GB of disk space to the server so you can get in and fix whatever went wrong free of charge.

9. Containers

Another cool thing (mt) has is different isolated hosting containers for different technologies like Django, Ruby on Rails and MySQL. These containers are hosted on their (gs) Grid-Service which is a cloud hosting environment to help handle high traffic and storage needs. So if you wanted an isolated little database server you could setup a MySQL container for $20/month on a cloud hosted environment quickly using (mt).

10. (mt) Labs

Something that I noticed that (mt) does that other hosting companies don’t is they tell you what they are working on. (mt) Labs is where they talk about what new and exciting things they are working on and open the floor to beta testers and users for discussion. They have really taken the web 2.0 company approach to hosting and I think that is totally cool.

Media Temple is not your regular stuffy old hosting company. They seem to have an intimate understanding of their audience and as a result have developed some very nice hosting packages. The next time you are in the market for hosting be sure to check out Media Temple!

<![CDATA[Implementing Facebook Connect (Part 3) - Accessing Data from Facebook]]> http://christophermonnat.com/blog/implementing-facebook-connect-part-3-accessing-data-from-facebook http://christophermonnat.com/blog/implementing-facebook-connect-part-3-accessing-data-from-facebook About a month ago I posted a continuation of my Implementing Facebook Connect series on how to establish a connection to Facebook. In this post I am going to look at using that connection we established to access user data and render it on a page.


Once you’ve established your connection to Facebook you now have access to a wide array of information, but to display this information you need to get familiar with Facebook Markup Language (FBML), an extension to HTML. The cool thing with FBML is that you can access a lot of information without a lot of code. All you need is the FBML tag in your HTML document and that’s that.

Rendering XFBML

In order to render XFBML tags on your page you first need to add the appropriate doctype and HTML attribute to your document.

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”> <html xmlns=”http://www.w3.org/1999/xhtml” xmlns:fb=”http://www.facebook.com/2008/fbml”>

The above mark-up is a standard doctype declaration. The only thing to note here is the XML namespace attributes added to the HTML tag. These are necessary in order to IE to render things appropriately so you don’t want to leave them out.

After you have the appropriate doctype declared you need to initialize the JavaScript Client Library from the Facebook site. This script basically contacts Facebook servers and tells them that you want to display FBML on the page in question and it’s up to Facebook to provide all the necessary tools to do so.

Finllay you need to send them your API key using the following script (which should be placed right after the above JavaScript include).

The Tags

OK, so now that we have the environment setup to recognize and render FBML we can review some of the tags and what they do.


The login-button tag should be familar from my last post. This tag renders a Facebook Connect log-in button on your site. When a user clicks the button they are presented with the Facebook log-in form in a pop-up window. When they log-in your application is added to their list of approved applications.

<fb:name uid=”user_id”>

The name tag does just what it’s mark-up would suggest, it displays the users name. This tag has one required attribute called uid where you need to provide a user id. You can also use this tag with Facebook Pages as well by passing the page id instead of the user id in the uid attribute. For more information about the name tag, visit the Developers Wiki.

<fb:pronoun uid=”user_id”>

The pronoun tag displays a pronoun for a specified user. Again, this tag has one required attribute uid for the user id. For more information about the pronoun tag, visit the Developers Wiki.

<fb:profile-pic uid=”user_id”>

The profile-pic tag can display a users Facebook profile picture in a number of different ways. After providing a user id for the uid attribute you can also specify a size (like thumb, small, pic_square, etc.). For more information about the profile-pic tag, visit the Developers Wiki.

<fb:grouplink gid=”group_id”>

The grouplink tag gives you the ability to display group page links using FBML.  Simply provide the group id for the gid attribute and your all set. For more information about the grouplink tag, visit the Developers Wiki.

<fb:eventlink eid=”event_id”>

The eventlink tag is similar to the grouplink tag except for events. Fed an event id for the eid attribute it will render a link to the specified events page within Facebook. For more information about the grouplink tag, visit the Developers Wiki.


The serverfbml tag is a very powerful tag that allows you to render FBML on Facebooks servers within an iFrame on your page. Using this tag you can interact with Facebook data through forms and such and it all takes place on Facebooks servers for security reasons. For more information about the grouplink tag, visit the Developers Wiki.

Try it yourself!

For additional information about the tags mentioned here and others I would recommend checking out the Facebook Developers Wiki. You can try things out on your own, or Facebook provides a number of demo files available for download which use the tags mentioned above and others to help you get a better idea of what’s possible.

There is one post left in this series and I promise it won’t take me a month to post it. In this post we looked at accessing information from Facebook; in the final post we will look at sending information back to Facebook so stay tuned!

<![CDATA[Selling Campaign Monitor to Your Customers]]> http://christophermonnat.com/blog/selling-campaign-monitor-to-your-customers http://christophermonnat.com/blog/selling-campaign-monitor-to-your-customers Introducing ScoutMailer

At Left of Center Communications (LOCC) my primary target market is the boy and girl scouting communities. My flagship product, BadgeTracker, is designed specifically for scout camps and Sign-Up-Sheet.com was first developed to help my local scout troop. So when it came time for me to figure out how I was going to sell CM it didn’t take me long to decide I would target it to the scouting community and thus ScoutMailer was born.

I choose to resell CM because the deal is just too good to pass up. There are no monthly fees, annual licensing fees or recurring fees of any kind. The only real long term cost is management time which isn’t that much thanks to CMs intuitive interface. Also, this isn’t just some referral or affiliate program that pays 20% - 30%. You can charge your clients whatever you want for the product. CM will take care of all the financial stuff and send you your cut at the end of every month via Paypal.

At the beginning of every new project I typically sit down and come up with a task list of things that need to be done in order to bring a new product to market. When I thought about ScoutMailer there really was only 4 things to do:

  • Design logo and promotional site for scoutmailer.com domain.
  • Write website content.
  • Customize CM interface with colors and logos.
  • Promote through existing add channels using BadgeTracker and Sign-Up-Sheet.com.

I outsourced the design of the logo and website so the only thing I needed to invest in that task was money. Writing the promotional website content was reasonably simple after seeing what other companies had done. Customizing CMs interface with my colors and logo was a simple 10 minute thing. Finally, promotion and marketing has really just begun. But that was it… less than 4 tasks to bring a new product to market.

The Promo Site

The biggest part to reselling CM is developing your own promotional materials. This process is really the same with any product, whether your the developer or just the reseller. The good news with CM is that they have a lot of resources available in the form of screenshots and how-to’s to help you along. I would also encourage you to take a look at the customers section of their website to see what other companies have done.

After about 2 weeks and some back and forth between myself and the designer we came up with the ScoutMailer promotional site:


Most all CM promotional sites are pretty much the same. They have the same site structure and content, but I wanted to make mine stand out a bit. So, I added a resources section to my site controlled by WordPress. My intention is to eventually develop some tutorials and how-to articles specifically for my group of users. The thing to remember about the promo site is you need to speak to your specific users. Put the product in terms that they will understand.

Customizing the Interface

The folks over at CM have written a helpful article to walk you through the process of rebranding their product to fit your needs. This was really the only “gotcha” moment in this whole process for me. They provide a set number of color schemes to choose from and that’s it. You can’t define your own colors. As a heads up, you might want to review those options before settling on a color scheme for your promo site/brand for CM so that your logo and site design goes with the interface. I had a bit of an issue with their shade of red but I think everything turned out OK.

Overcoming the Language Barrier

One of the issues I knew I would have to address in the promo site, and will probably have to work through in support requests, is the e-mail marketing terminology. My particular target market isn’t interested in an e-mail marketing tool… they are more looking for a mailing list management solution and the two don’t necessarily mean the same thing to them. They want something that let’s them send plain text reminders from time to time and maybe the odd HTML newsletter every so often… but that’s it!

Another issue that I foresee moving forward is that my user base probably won’t understand that campaign = e-mail message. There is going to be a bit of a language barrier that I’m going to have to deal with so that they understand the process. It would be totally cool if CM allowed us to customize the terminology used in the app someday. But for now I’m relying on my promo site to steer users in the right direction. I’m also thinking about potentially developing a glossary and posting that in the resources section to help. But it’s something for you to keep in mind depending on what audience you plan on marketing CM to.

What’s next?

ScoutMailer officially launched just this past Monday. Marketing and promotion is still getting underway but it will be interesting to see if I get any takers. Another opportunity for selling CM to existing customers is integrating your existing products with the CM API. I’m going to look into this later this year to see if theres any value there. Keep watch for a how-to post on that in the near future.

That’s my story… do you have one? If you have been reselling CM for a while or just started, let me know what your experience has been in the comments.

Reblog this post [with Zemanta]
<![CDATA[Implementing Facebook Connect (Part 2) - Establishing a Connection]]> http://christophermonnat.com/blog/implementing-facebook-connect-part-2-establishing-connection http://christophermonnat.com/blog/implementing-facebook-connect-part-2-establishing-connection Two weeks ago I took a look at Facebook Connect (FC) summarizing what it is and why developers would want to integrate it with their own applications in part 1 of this series. Originally I had thought this would be a two post topic but as I have learned more about FC I think it’s going to take a few posts to get up and running successfully. So, in this post we’re going to get all the pre-requisites out of the way and establish a connection with Facebook from our own application. We will then look at how we can do things with that connection in subsequent posts. Ready or not… let’s get started!

Getting Started

In order to use FC with your own application you first need to set your application up within Facebook so you can get your hands on an API key. As is the case when working with any API your API key will be used throughout your FC integration code for authentication purposes.

Step 1 - Add Facebook Developers to Your Applications

The first thing you need to do in order to set your application up within Facebook is add the Facebook Developers Application to your approved applications list. To do this, visit http://www.facebook.com/developers/. Once you have added the developers application to your authorized applications list you will have access to all the developer resources that Facebook has to offer as well as a discussion board for questions and issues.

Step 2 - Setup Your Application

Now that you have added the developers application to your authorized applications list you can now proceed with setting your application up.


Navigate back to the Facebook Developers application by visiting http://www.facebook.com/developers/ and click the Set Up New Application button at the top right of the window.

Now comes the fun part… setting up an application in Facebook involves a mega-form full of options and other required pieces of information. The form is fairly self-explanitory so I won’t take the time to go through it all with you. The only thing I will point out is the Connect tab. This section of the form concerns all the FC settings as they relate to your application. The only thing you need to concern yourself with at this point is the Base Domain field. “Specifying a base domain allows you to make calls using the PHP and JavaScript client libraries as well as get and store session information for any subdomain of the base domain.” Enter all the necessary information about your application and click Save Changes.



h2 style=”text-align: left;”>Establishing a Connection Now that we have our API keys we can put the files in place that will help us establish a connection between our application and Facebook. I am having problems displaying code in my blog posts so for this post I’m just going to refer you to the FC getting started guide for the actual code to use. If any of you have any recommendations for tools to use to display code in Wordpress blog posts I would love to hear them.

Step 1 - First the CCC File

The first thing we want to do is create something called the cross-domain channel communication (CCC) file. That’s an awfully big name for such a little file. Basically this file provides the Facebook JavaScript Client Library with what it needs in order to function properly.

Copy the code from the FC getting started guide located under #2 and paste it into a new file named xd_receiver.htm. This file needs to be placed in a directory that’s relative to the callback URL that you entered when setting up your application in the mega-form above. For those of you following along using CodeIgniter, you should be able to get away with placing this file in the root of your CI application. That’s where everything is really referenced from anyway regardless of the search engine friendly URLs.

Step 2 - Now the Test File

Now that we have the CCC file we can begin writing the file we are going to use to establish our connection. Since we are only testing things in this post we will just make a simple file that displays the Facebook log-in button and adds the application to the users approved applications list. Go ahead and create a new file named test.htm and then follow along with the getting started guide starting with #3 for the necessary markup. Again, for those CI users you can place this markup in a view file and load it using whatever template your program is using.

Before running the script you want to be sure to replace YOUR_API_KEY_HERE with your API key and <path from web root> with the appropriate path to the CCC file. Once you have done that you can upload the two files we’ve created and test.

That’s it!

When viewing your test file in a browser all you should see is a Connect button displayed. When you click the button you should see a pop-up window prompting you to either login to your Facebook account or give your application permission to access your profile like in the screen shot below:


Once you either login or give your application permission you can now go back to your Facebook account and look at the list of your authorized applications and you should now see your own application in the list.


h2 style=”text-align: left;”>What’s next?

We didn’t get into much of the real nitty gritty in this post but we did lay the ground work for what is to come. In the next post I will begin looking at how we can access information about our users from Facebook and how we can send data back. Stay tuned!

Reblog this post [with Zemanta]
<![CDATA[Implementing Facebook Connect (Part 1) - What is Facebook Connect?]]> http://christophermonnat.com/blog/implementing-facebook-connect-part-1-what-is-facebook-connect http://christophermonnat.com/blog/implementing-facebook-connect-part-1-what-is-facebook-connect I have been spending some time recently developing an online community which will hopefully be launched next quarter. One of the things I wanted to integrate is OpenID to try and lessen the burden of signing-up and logging-in. However, after doing some research I’m thinking that Facebook Connect might be the better way to go. This is the first of at least 2 posts about implementing Facebook Connect with your own PHP application. To begin we will first look at what Facebook Connect is and does and the next post will get technical and look at how to integrate it with your next CodeIgniter or PHP application.

What is Facebook Connect and how does it differ from OpenID?

Facebook Connect (FC) allows users with Facebook accounts to log into your website/service using their Facebook log-in credentials. OpenID provides the same functionality except instead of using your Facebook credentials you use your OpenID credentials. The difference between the two is that FC brings a lot more, in terms of features and functionality, to the table for developers to work with than OpenID does. FC allows users to take their web based social identity with them from site to site.

The Facebook Developers site has a lot of useful information on FC and what you can do with it. Using FC, you can enable “…your users to seamlessly “connect” their Facebook account and information with your site, connect and find their friends who also use your site and share information and actions on your site with their friends on Facebook.” In a nutshell, when you integrate FC with your website or web based application you are allowing your users to interact with their Facebook account from within your app thereby adding value to your site right off the bat.

As I stated above, FC offers more than just authentication. If a user logs into your application using FC you have the ability to interact with that users Facebook profile, friends, Facebook Feed, requests and notifications (if they give your app permission). A nice example of FC functionality and features is a sample app Facebook staff developed as an example called The Run Around. This example shows how FC would be integrated with a typical web app. You can either create your account using The Run Around registration form and connect your Facebook account later on the settings screen. Or, you can just use your Facebook account to log-in and forgo the static registration all together.

When a user logs into The Run Around, and they have connected their account to their Facebook account, the app can now post updates to the users Facebook Feed and show them any friends of theirs that are also using the app. So now you can not only leverage a users Facebook log-in information but you can create an app that interacts with that users Facebook account which I think is totally cool. This opens the door for developers to create nice sites that compliment Facebook and vice verse.

Now that we have covered what Facebook Connect is the next post in this series will begin to look at how we go about using it in our own apps. Check out part 2 to estalibsh your applications connection to Facebook.

<![CDATA[10 Reasons Why Campaign Monitor Rocks]]> http://christophermonnat.com/blog/10-reasons-why-campaign-monitor-rocks http://christophermonnat.com/blog/10-reasons-why-campaign-monitor-rocks E-mail marketing apps are a dime a dozen now a days. Each one claims it has better delivery rates than the other, more pre-designed HTML templates than the other and better support. However, I found an e-mail marketing app a while back that has just differentiated itself from the rest of the pack completely. The program is called Campaign Monitor (CM) and it’s not just your typical e-mail marketing app. CM has been built with designers and developers in mind. You can completely rebrand this hosted application to make it look and act like your own application and then resell it to your customers for additional revenue… totally cool!

Below are my 10 reasons why Campaign Monitor rocks:

1. Very easy to use.

E-mail marketing can be a complex activity if you aren’t real tech savvy. Especially in today’s market with so many different e-mail clients and spam filters around. Campaign Monitor has an extremely simple user interface. They don’t clutter the screen with unnecessary icons or graphics. Most operations are in a step by step wizard format with plenty of helpful notes and explanations along the way.

2. It speaks our language.

When you really get into e-mail marketing and start looking into why messages are bouncing, etc. you start to come across terms like Sender Policy Framework (SPF) and DNS records. Your general user, who just wanted to send a message to their list, doesn’t know what all that is about… and they don’t care. Campaign Monitors reports get the information across in plain terms that anyone can understand. Their bounce report lists all recipients whose messages bounced back along with the specific reason why it bounced.

3. You only pay when you send.

E-mail marketing is one of those things that I refuse to pay a monthly fee for. I don’t send enough e-mails to warrant such a fee. That’s why Campaign Monitor is so great; you only pay when you send a message. So all the list and subscriber management tools are available for free. When it’s time to send a message it’s just $5.00 for the e-mail and $0.01 per recipient. So, if you’re sending a message to 100 people the cost will be $6.00 for the message. And the price doesn’t go up for more recipients. Of course you will pay more for sending to more people, because of the penny per recipient, but it’s still just $5.00.

4. Helps you get your messages to your recipients.

Getting e-mail’s to their intended destination is not a simple process. Spammers have clogged the pipes with so much junk that poor e-mail systems are having a hard time determining what’s legit and what’s not. To help ensure your mail get’s delivered you are encouraged to look into the Sender Policy Framework and adding TXT records to your DNS so e-mail services like Hotmail, AOL and Yahoo don’t file your message as SPAM. Campaign Monitor does all the hard stuff for you by allowing you to add authenticated sending domains to your client accounts. Then CM provides you with the necessary DomainKey and Sender ID TXT records to just copy and paste into your domains DNS.

5. Not your typical affiliate or referral program.

Programs like this usually work off an affiliate or referral program. You link to or recommend the program to your clients who end up sign-ing up and you receive 15-20% of what they spend. Not a very attractive offier. Campaign Monitor, however,  actually allows you name your own price and still use their system. The deal is that you name your own price and then the client gets charged your price. At the end of every month CM does the math and sends you a Paypal transfer with your profit (minus their cut of course). CM only takes $5.00 for every message sent plus $0.01 per recipient.

6. Over 30 pre-designed HTML templates.

Campaign Monitor is a full featured e-mail marketing app in a box. All you have to do is gussy it up to look like you want and your off. They even offer 30 pre-designed HTML templates for you and your clients to use.

7. 100% Rebrandable

You know as well as I that rebrandable can mean anything from being able to change colors to being able to change the URL. With Campaign Monitor you can change pretty much anything you want. You can upload a logo for the main log-in screen, a logo for the main application interface, you can choose from a number of different color schemes, you can even set your own pricing scheme. To top it off you have the ability to change the URL of your app to anything you want. So users don’t visit http://something.campaignmontior.com. You can make the program look completely like your own.

8. A wealth of design resources.

On top of a great program, the makers of Campaign Monitor have a Resources section on their website chocked full of useful tips and tools. They have ideas on how you can offer e-mail marketing services to your clients and information on how CSS is supported in HTML e-mail design. They also have detailed explanations and resources to help your users understand permissions and what is and is not acceptable use of someones e-mail address.

9. Segmentation and custom fields.

You can have 5 different mailing lists for a single site if you want. But with Campaign Monitor you have the ability to create segments within a given list. Using custom fields you can group members of a given list into segments and then send messages to certain segments without affecting the other members of your list. This allows you to keep track of all your subscribers using just one list instead of many.

10. API Access

As if the items I have already mentioned aren’t enough, Campaign Monitor also provides it’s users with API access to their program. This allows developers like myself to integrate the program with their own apps to help streamline mailing list management and cut down on all the exporting and importing that typically needs to take place. If you offer other web based applications this is a great opportunity to upsell Campaign Monitor because you can integreate it with your apps thereby making the process seamless for your clients and that’s what it’s all about.

Those are just some of the reasons why I think Campaign Monitor rocks. Try it out for yourself and let me know what you think.