Is it really a question? Not for us, its simple, we just do not do it. Have we done it? Sure, we have. We have experienced the trials and tribulations around outsourcing. There were too many issues around outsourcing and product development so we sat down and really analyzed what we were getting for what we were paying, and what we could do better. I am really talking about outsourcing your web development overseas. We have all heard of India, or China, or Romania, even Russia. So here is what we found out.

So what is outsourcing and what do I mean when I say outsourcing. To us, outsourcing simply means hiring a contractor to do work for you in order to get a job done. Whether you outsource a portion of a project or the entire thing, there can be some real pains around it. The other thing is outsourcing is even done locally vs. overseas. A common misconception with outsourcing is that many people think of India or China immediately when you say outsourcing. Yes, there are a ton of companies that use these countries and their developing economies. However, there are web design and development companies that outsource their work locally as well and are really just a middle man. While that can work for some, many of us want to have the comfort level to know that whoever we are doing business with, produces a product or service in house, not farm it out.

In this business, price is a factor for many people and companies. Sometimes I begin to wonder if people are willing to sacrifice quality for price. I talk to people every day that are so concerned with price and don’t really care about the quality. Imagine building a product and because of price, you had to take short cuts. Or because of price you hired a much less experienced firm overseas which saved you a lot of money. You are happy right? Are you really happy? Here is what I have seen and experienced.

At first everything is going along well, the design is ok and you are satisfied with it, but it doesn’t knock your socks off, because you couldn’t talk directly to the designer because the designer doesn’t speak English or is not capable of speaking to customers, or whatever the case may be. That should not happy. Every time you tell a story, if its retold, it looses some element of how it was told. If you can’t talk directly to the designer of your project, can you be sure whoever you are telling will convey the design concepts properly? Check out Robert our world class designer. Not only can you see him, you can call him directly and talk to him. Cool huh?

So, now you get to the application or development piece of your project. You have to stay up late to get updates and communicate with your developers. If that’s your style, great, that will work out good for you. If you are like most of us, you need your beauty sleep. It’s tough to stay up night after night trying to communicate with someone over email or IM to view your project. A lot of times, scope and what you want to happen in your application are not translated properly, so you wind up spending much more time trying to get things right. This has to be one of the most frustrating pieces with outsourcing there is. So now your project is behind schedule and milestones are getting missed. You are starting to wonder if you made the right choice to go with a less expensive, less experienced company. The design is just ok, and things seem to work, just not quite right.

Now lets take this and multiply your testing efforts by millions of users. Do you think these design firms that outsource their developers understand what the balance is between code and server requirements. Do you think they take into consideration when they are writing code, at what point it’s going to break when you get a ton of traffic to your application because everyone loves the application? If you do not take the time to plan properly for mass market testing, chances are you are going to see a big problem once your application becomes mainstream.

The last major problem that I see is the cleanliness of code and the ability to make changes. Outsourcing is usually cheaper because the people that are working on the projects are inexperienced. When it comes time to make changes, that should take only minutes wind up taking hours because the code is not properly documented, another developer is working on it, or it’s built incorrectly and you wind up having to update 100 files instead of just one. And guess who pays for that? You do.

At the end of the day, you get what you pay for. That’s the bottom line. Sometimes it makes sense to outsource, in web design and development, in our opinion it doesn’t. You can see all of our staff and and/or even talk to them as well. We have over 100 clients. Why do you think they came to us versus going to an outsourcing company or using someone that does this “on the side”. If you want a professional website or a professional web application then hire a professional company. Call us anytime to discuss your business. We would be glad to help. 919-341-2382

Ok so now you have the default cakePHP page up and working, now for the fun part, moving the actual code over and seeing what works.  Most applications use just the controllers,models, views, and webroot directories under the app directory, and there could be some things in the vendors directory as well.  It will vary from application to application.  Start by bringing the inocuous stuff forward first I would start with the webroot and vendors directories.  Once you have proven that doesn’t cause any major problems, other than maybe losing your css formatting, then move onto the models,views,and controllers directories.   At this point you have probably migrated all of your code over and have noticed what is working and more to the point what is not.  At this point it is probably a good idea to turn the debugging level up to at least 1, but I would probably set it to 2 so you can get all the SQL data that the application is passing back and forth.  This way you can see if the model find and save functions are working properly.

For the most part you will probably not have to change anything in the model definitions themselves.  the bulk of the changes will come in the controllers that use the models to find/save data.  Here are the major changes that I have found in the model methods that will require recoding.

1. findAll and findAll(By <Camel case table column id>) - these functions have been deprecated (removed), in version 1.2.  This means that you need to replace all instances of these function calls within your code.  In this case you need to use the new find function that is more specific in its use but is more flexible.

(i.e.) $this->Model->findAll($conditions,$fields,$order,$limit,$page,$recursive);

would become

$this->Model->find(’all’,array(’conditions’=>array(), ‘fields’=>array(), ‘order’=>array(), ‘limit’=>array(), ‘page’=>number, ‘recursive’=>number));

As you can see it is considerably longer to type, but is more specific in how you use it.

2. findCount  and findCountBy(Camel case by table column) - this has also been deprecated (removed), the good news here is that the changes almost identical to the findAll with just one minor exception.

So $this->Model->findCount($conditions,$fields,$order,$limit,$page,$recursive);

would become

$this->Model->find(’count’,array(’conditions’=>array(), ‘fields’=>array(), ‘order’=>array(), ‘limit’=>array(), ‘page’=>number, ‘recursive’=>number));

Notice the only real change to the find command is the first word in the find function from ‘all’ to ‘count’.  The nice thing about the newer version of findCount is that it just returns the numeric count instead of an array that you must index to get to the count.

Note the original find function has not really changed but under the hood in the cake libraries are basically doing this.

$this->Model->find(’first’,array(’conditions’=>array(), ‘fields’=>array(), ‘order’=>array(), ‘limit’=>array(), ‘page’=>number, ‘recursive’=>number));

So in essence the the find function has been re-written in cake 1.2 to be more specific in it’s use, the good news is that for the most part the new find functions appear to be more optimized and the generated SQL is considerably more compact than previous versions and seems to run quicker.  There are four basic keywords for the new find function (all,count,first,list), where the keyword versions of ‘all’ and ‘count’ must be used for their deprecated counterparts.  The ‘first’ keyword version can be used interchangeably with the standard find function.  The last keyword ‘list’ is used to replace the generateList function which has also been deprecated, This was used primarily in forms to generate quick list of information for drop downs, however it could also be used for quick id and field lists.  The function call looks just like the new declarations above, but first keyword changes as before. (i.e.)

$this->Model->find(’list’,array(’conditions’=>array(), ‘fields’=>array(), ‘order’=>array(), ‘limit’=>array(), ‘page’=>number, ‘recursive’=>number));

That about covers the major changes to the model class in cakePHP 1.2, this will keep anyone busy for some time changing out their controllers, and possibly helpers if there is model code in them.  For the most part the model declarations in cakePHP 1.2 are basically the same as in 1.1, however if you are doing any special validation rules in your models, it would be a good idea to test those out once you get the controllers functioning properly.  In the next chapter I will discuss the changes to the helper functions, and some of the rules enforcement changes on helpers as well.

Of course it is an oversimplification that would  lead you to believe that form and function are mutually exclusive.  I in no way think that these two are incompatible.  However, in my limited but valuable experience I have come to learn that a designer with developer’s abilities and vice versa exists the same way a unicorn or a purple elephant might exist, as a figment of our untamed imagination.  What follows are lessons, from a designers perspective, on this very subject.  I realize that I open myself up for ridicule and mockery for not recognizing those who have not only accomplished this task but have done it well.  To these I simply reply, thank you for reading my blog.

THE OBSERVATION

If I were to say that I have never felt like Jane Goodall or Dian Fossey, as they patiently and carefully crouched behind rocks and trees in foreign jungles to study Chimpanzees and Gorillas, I would be a liar.  In fact this feeling is only intensified by the fact that at Mach 9, instead of cubicles, we work underneath actual tiki huts.  I have noticed some of the habits of the developer and wish to share them now.

The developer is normally very thoughtful and focused on the work that is given them.  They are very involved in that work to the point that it can become dangerous to interrupt with questions or comments related to the way their work will be displayed.  The developer is also very concise and clear in their instruction.  The same way a military commander would hand a subordinate detailed instructions on how to proceed with the invasion the developer will at times pass along instructions, however very rarely will it be for an invasion.  On very many occasions I found the developers to be…how should i put this…careful, cautious, exacting, neat, systematic, diplomatic, accurate and tactful but sometimes self-willed, stubborn, opinionated and flat out rude.  However,  in just the same way that Dian Fossey stretched out her hand to give her beloved and wild gorilla ‘Peanuts’ a love pat, so too must designers and developers come together for the good of the Internet.

THE ANALYSIS

The designer tends to have very many opposite traits to that of his/her counterpart the developer.  Designers tend to be more idealistic and flighty but concerned with beauty and, more practically, usability.  It is not only my intent to prove that both designer and developer alike can co-exist but to show that they can work together in a beautiful harmony to produce some amazing and cutting edge products.  This is what I have really been discovering in my time as the Creative Director at Mach 9.  The developers are good people with good intentions.  Beyond that nothing is accomplished without them.  In this way the relationship is as far from mutually exclusive as you can get.  Instead I have learned that the success of a web development company is fully dependent on the success of the designer and developer relationship.

THE APPLICATION

Modern web design is such that it attempts to create the ‘easiest to use’ yet still ‘most powerful’ websites.  This is partly what is meant by the term Web 2.0. (you like that don’t you Google)  It goes beyond the designers ability to create nice drop shadows or shiny floor reflections.   It means creating and designing in a way that not only appeases our inner artist but speaks volumes to our silent utilitarian.  It is here that I have found the answer to the debate between form and function.  In much the same way Apple has put its most powerful computers into the sleekest looking boxes, designers and developers must work together in harmony to accomplish amazing feats.

-Robert

So you have decided to migrate your cakePHP site from version 1.1 stable to the latest and greatest version 1.2. There have been several changes to the frame work since 1.1 and some for the better. From what I can tell in the RC2 candidate that we have used on several projects here is that the frame work has been sped up, and a fair amount of the overhead with database queries has been optimized.

I have spent about a weeks worth of time getting a version 1.1 site to come forward to the RC2 candidate, and for the most part it was a fairly painless process. However, it can be tedious, and sometimes finding every thing in all the views, and controllers can feel at times daunting. However, with some perseverance and attention to error messages that are produced with debug turned on you can work through this.

I would recommend that you make backups of the /app and /cake directories before starting this task, and then unpack the cakePHP distribution in the same base directory as the /app and /cake directories, then do the configuration changes listed below, then slowly start bringing your controllers, models, views, etc and working through the errors.

Chapter 1 - Base configuration changes

These changes are fairly straight forward and easy to make, the only two files that need to change are core.php and routes.php in the /app/config directory where ever your base cakePHP installation lives.

Changes to core.php, I would recommend just using the default one that comes with the cakePHP distrubution and incorporate your specific changes to the file. The biggest change to the core.php file is that the php function define is used much less in favor of the Configure object. Now you can just leave your configuration file the way it is, but doing so can result in strange behaviour on down the line, so it would be recommended that you upgrade this file, and if you have some application specific things that need to be defined put them here.

Changes to routes.php, this change is MUCH simplier than the changes required for core.php, in version 1.1 the connect function was not static and therefore the frame work needed to instantiate a single Router class in order to provide the connect function. In version 1.2 the function has been made static and the only real change that needs to happen in your routes.php file is to change all instances $Route->connect to Router::connect in the file and save off.

Finally if you have the rewrite engine enabled for the web server that this is running on, ensure that the .htaccess files are set up properly in the base web directory for the application, all the way down to the webroot directory for the cakePHP application. In the web server web root directory and the /app directory make sure the following lines are in your .htaccess file:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule ^$ webroot/ [L]
RewriteRule (.*) webroot/$1 [L]
</IfModule>

finally make sure that you use .htaccess file that comes with the distrubution in the webroot directory or make sure that it has these lines in it.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]
</IfModule>

There shouldn’t be any other configuration changes that you need to make, just make sure that you have all the configuration files copied over from your old application (mainly database.php, and with the exception of the core.php and routes.php that were changed previously). If you have done everything properly, you should have the default cakePHP home page that states all is well, or you need to fix something (usually permissions changes to the /app/tmp directory). That should be it for the configuration changes, next Chapter we will discuss the changes to the model that have been made and how this will affect your controllers and views.

What this means, essentially, is that it is a nice way of structuring the code so that different activities are separated logically. Database interaction and data validation should always be done in the Model. Displaying of data should always be done in the View. And any special logic that needs to be done to link the data to a display should be done in the Controller.

These are essentially extensions of Object-Oriented Programming. In fact, the representations of each Model and Controller are actually Objects, which can be extended or inherited.

CakePHP has it’s little quirks with these implementations that are meant to make development faster, but can trip up a developer new to Cake if they are unaware of them. CakePHP has very specific expected naming conventions.

A Model, for example, might be called Event. The file representing this model will need to be placed in the app/models directory and named event.php. The Class name (a Class being a logical block of code, and an Object being an instance of that Class) would then need to be Event. The related database table would also need to be named events. Notice the difference in capitalization. If the file name is not lower case and/or the class name does not begin with an uppercase letter, the Model may not work properly, or might require extra coding to make it work, which can get unnecessarily tedious.

Typically, each Model should have a matching Controller that performs any necessary activities between the Model and the Views. This Controller should be placed in a file in the app/controllers directory and named events_controller.php. The Controller Class should be named EventsController. Notice the difference in pluralization. If these naming conventions are set properly, no extra coding is required to link the Model to the Controller. Also notice how multiple words are handled: all lowercase and separated by an underscore for file names, and differentiated with capital letters in the class name. This would work if you wanted a Silly Photos MVC set: app/models/silly_photo.php for the SillyPhoto Model and silly_photos database table, and app/controllers/silly_photos_controller.php for the SillyPhotosController class.

Views are a little different in that they are related directly to the Controller. Generally, the names of View files will match exactly with the method names in the Controller. Usual methods for a Controller are add, delete, edit, and index. The related View files for the EventsController would be located in app/views/events/ and would be named add.ctp, delete.ctp, edit.ctp, and index.ctp, respectively. The subdirectory of the views files must match the Controller’s file name, minus the _controller text (ie: views for SillyPhotosController would be located in app/views/silly_photos/). The case and pluralization of the Controller method names and View file names should be the same, so a method called list_items should have a View file called list_items.ctp.

There are exceptions to these rules that can be made, but it’s generally easier to stick with these conventions. The only time you might need to explore the exceptions is when trying to integrate code that is maintained by a third party, where their conventions do not quite match those in CakePHP.

In my next post I will describe some of the performance and configuration gotchas I have experienced while learning and developing with CakePHP.

Change

if (Calendar.is_ie) {
br.y += document.body.scrollTop;
br.x += document.body.scrollLeft;
} else {
br.y += window.scrollY;
br.x += window.scrollX;
}

to

if (Calendar.is_ie) {
br.y += document.documentElement.scrollTop;
br.x += document.documentElement.scrollLeft;
} else {
br.y += window.scrollY;
br.x += window.scrollX;
}

After that all should be well, also if you look at the code just below the fix you can see what NOT to name a function. Evidentally the khtml browser is hard to code around for this particular widget. I will let you see what the actual function name is for yourself, as it really shouldn’t be repeated here.