header('Content-type: application/json; charset=utf-8');

Then I noticed what it was actually giving in response was charset=utf8 (note the missing dash).

I wouldn’t have noticed it until my application failed in Internet Explorer — while working perfectly in all other browsers.

SCRIPT58734: Could not complete the operation due to error c00ce56e. angular.min.js, line 98 character 124

It turns out Internet Explorer is very picky on the charset and givent the fact that PHP was not actually sending the charset I’m telling it to, I had to resort to modify php.ini

default_charset = "UTF-8"

Above charset enforces the proper charset.

I haven’t thoroughly examined what lead PHP to ignore my explicit headers but this sure fixed it.

Study how to get a good job and love what you do.

Written by Cal Newport.

One Sentence Summary

Good jobs are rare and to get something that is rare and you have to provide something that is valuable (rare) which is your expertise in that particular field gained through years of rigorous hard working.

Summary

Author is trying to answer the questions; how to get a good job and love what you do.

He starts by refusing the widely accepted career advice “following your passion”. According to author, there’s no one magical single true job waiting for you somewhere in the wild, instead, you grow to like your job as you get good at it. He presents scientific evidence that shows the likelihood of loving what you do correlates with how much time you spent on it. That’s, the longer time you spent on a job, the more you like it as you become competent on it. This is rule #1. Author claims that there are MANY jobs that you can be passionate about once you are competent on it.

To answer the question “how to get a good job”, however, we obviously first need to define what a good job is.

Author defines the traits of a good job as
- Creativity : Being able to be creative at the job.
- Impact : Make positive difference in the world.
- Control : The amount of control you have in your daily life like when you wake up, when you can take a time off.

Then, author tells how all these traits are hard to find in jobs, which, in practice makes good jobs a rare commodity. In economics, supply and demand model dictates that if supply is low (good jobs are rare) and demand is high (everybody wants them) then the price will be high. Which, in practice, means that you have to offer a very good value to get these good jobs.

Offering good value to get a good job is attributed to “career capital”. Career capital is your accumulated expertise in your field that you can offer to get that good job. This is rule #2.

After acquiring career capital, author says you can trade them with traits which makes a job great. For instance, if you prove to be an indispensable employee, you can demand less working hours — control.

Author goes on to describe what is the most efficient way to acquire career capital, and that is deliberate practice. Deliberate practice is defined as always getting a bit out of your comfort zone and pushing your skills forward.

Even though there are three traits for making a job great, author emphasizes control trait the most and rule #3 is that you should spend the career capital you gained for control on your daily life.

In the final rule, rule #4, the author starts mentioning a new concept: mission. Author claims that mission is one of the most important traits you can trade with your career capital for a compelling career. To acquire a mission however, you must be cutting edge in your field, so that you can see the next big thing and make that your mission. According to author, missions are tricky, so you must make little bets for reaching your missions. Such as monthly projects which attempts to solve one little piece at a time. If it fails move on, if it yields good results keep on.

Criticism

I found the book thought provoking.

Even though the traits of a good job are merely opinions and not a result of scientific study, I agree with them. Like many of the texts you’d find in this field of writing — that is self improvement, maybe ? — you often find very obvious answers to questions and this book is no exception. It says that you have to work real hard for real long time to get a good job. Obvious right ? Right. But it goes in detail to give you the grounds to realize what you are doing wrong.

For instance, I really could relate myself to many things written in the book. Like hitting the a performance plateau. I really started to avoid deliberate practice as I progressed in my professional career and that made me hit the performance plateau. Before reading this book, I have already started to realize this, so I was putting myself outside of my comfort zone to try to improve the quality of code I’m producing but this book made it very clear for how common and important a problem is this . These problems have been studied by performance scientists mentioned in the book.

So, generally, I came to agree with most of the conclusions drawn by the author.

Though, I think the book lacks scientific evidence on some of the theories it is suggesting, rendering them merely opinions. Also, in some occasions very little sample pool is used to draw conclusions (page 37).

Author makes some assumptions from his personal opinions of the concepts which is the very core of the book and builds the book on top of them but soon becomes a prisoner of these assumptions he made himself and religiously defends them. This reminded me of the term “intelligence trap” as defined by Edward de Bono.

He goes on to rule “follow your passion” advice out completely and defend this thought whatsoever. I think this is not a black and white area and we should be more open. For instance check this bit.

In the book, there’s a story of a musician named Jordan Tice. Author explains how hard Tice worked to get to the point where he is now.

It asks you to leave behind self-centered concerns about whether your job is “just right”, and instead put your head down and plug away at getting really damn good.

The author suggests Tice didn’t question if being a musician is the right job for him or not, he put his head down and worked his ass of regardless and once he got competent on it he became passionate.

Author, immediately quotes one of the many similar arguments he heard from his readers against this theory.

Tice is willing to grind out long hours with little recognition, but that’s because it’s in service to something he’s obviously passionate about and has been for a long time. He’s found that one job that’s right for him.

He defends his stands with:

I don’t buy it.
First, let’s dispense with the notion that performers like Jordan Tice or Steve Martin are perfectly secure in their knowledge that they’ve found their true calling.

I think the fact that they were insecure does not mean that they were not passionate. I believe, they kept bettering themselves against all the odds because they were passionate about what they do. The thing we should study here is what is it that ignites the passion in the first place.

Author is also a amateur musician and compares himself to Tice:

To the high school version of myself, the idea of learning complicated lead parts by ear would have been way past my threshold of mental strain and patience. But Jordan came to enjoy this labor.

But skips to study the reason why Jordan enjoyed that labor. I call it passion.

Conclusion

I took what I could to the best of my ability from the book and enlightened in some ways but, to be honest, I do think the thoughts presented in the book are not of book quality yet as they are often opinions rather than scientific facts. They might be accurate or not but I expect a more scientific approach in books.  But that might be just me.

I had to start from somewhere, so, I start writing a mini book about how world wide web works.

Please feel free to contribute.

https://github.com/engina/the-internet-book

Traditional web applications consist of several “pages”. Each page requires external resources such as CSS, Javascript and image files to be fetched. Every time we load a web page those resources are also loaded with it. So whenever you navigate from one page to another, all these resources are loaded again and most of these resources are static. They are always the same, yet, they are reloaded every time you navigate in the web site.

Implementations and specifications are evolved to remedy these design problems. Each resource was retrieved by a separate connection in HTTP 1.0, it was only since HTTP 1.1, we started to re-use existing connections to retrieve additional resources. Even then, to be a good network citizen, browsers only open limited number of connections to an origin, so additional resources are queued and fetched in serial fashion anyway.

Additionally, we started to use HTTP caching directive headers aggressively to avoid re-fetching of the resources.

Furthermore, we enabled gzip compression to compress textual data in the server before sending it to the browsers which support it.

But no matter what you do, even if you avoid re-fetching resources completely, the browsers reloads them from its cache. This means they are processed again and cause visual imperfection, as you can notice the page is being re-rendered.

Furthermore when we reload the page, it is a challenge to keep the state of all the visual components. This is basically due to HTTP is being an inherently stateless design.

This is, obviously, a severely broken way. Web’s needs have changed and this design is clearly far from ideal for today’s scenarios.

A more modern approach

For the past few years, I’ve adopted another design approach which today’s web giants such as Facebook, Twitter and finally Google too have adopted to some degree.

Even though it has existed before that, a new technique called Ajax emerged around 2005 which is basically just a feature that you can use to send web requests in the background without reloading the web page and get the result back. So, with this technique, you could retrieve new information, such as live stock data, in the background and update some part of the page without reloading it completely.

This was actually a ground braking approach. It remedies most of the flaws of the traditional way of web application development. Yet, it took quite some time for people adopt and really use it. For instance, Google Ajaxified Youtube’s comment system just a few years ago. Even though, Facebook used Ajax for many of its tasks for a very long time, Facebook recently Ajaxified most of its interface, such as when you click on a photo, it just pops up a dialog right now instead of sending you to another page — which was the case about a year ago.

I do believe that ideal web application is just a single static web page which can be served with very high speed, redundant technologies such as CDN servers which have no dynamic page creation ability. After the web application is loaded, it’ll communicate with the back-end server via Ajax requests in the background. I’ve used this technique successfully and the result was amazing, it was the fastest user experience I’ve ever seen in a web page. I’ve engineered whole thing to be as fast as possible.

Try it for yourselves, I was playing with a toy project which is now in hiatus status, which is hosted at http://beta.gettingback.at/. Go ahead and test the speed for yourselves. Once, it is cached, It takes 600 ms for the whole page to be loaded and rendered completely, from a server which is 2600 km away. Clicking on any link on the page just pops up another dialog to show you the information you are requesting. If you design your application smarter, you can fetch-ahead some of the data user is most likely to click so the experience can get even more faster. The responsiveness and perceived speed is outstanding.

A single static web application

Benefits

- Lower requirements. You can serve the UI file with the dummiest web servers available even with the lowest technology CDN servers.
- Minimal bandwidth usage. As all the communication is done over Ajax and all transferred information is strictly data and no repetitive, redundant information (such as the presentation logic — i.e. html).  This cuts cuts bandwidth costs.
- Minimal server load, distributed computing. As presentation logic is completely on the client, server does not need to fiddle with templates and all sort of stuff which has a computational expense. Hence, in a sense, you are distributing computing expenses to the clients.
- Optimizable. Single static web page proved to be easier to optimize — more on that later.

Problems

- Lack of frameworks. Since this approach is not widely adopted there are lack of frameworks that dictate best practices.
- Back and forward buttons. As this approach keeps the user in one single page back and forward buttons’ job is rendered useless. Luckily enough, this was the first problem noticed with Ajax and had been worked on for a long time and solutions exist.

What’s the best way to communicate with the API ?

So, how should we design our API ? We most probably want our API to be accessible by the world as 3rd party developers will use it. This means cross-domain communication. If our API is at http://api.foo.com and another page such as http://static.foo.com tries to access it, it will be a cross domain communication.

What are our options for cross domain communication ?

I’ve studied the subject in my post Cross-domain data-push methods compared two years ago. Back then, using a transparent Flash as cross-domain communication proxy seem like the way to go to me. Mainly because:

- Flash can maintain a single connection and many request-response on it
- Flash has raw TCP connection so you can freely implement a bandwidth efficient protocol.
- Flash was a very ubiquitous technology which was available in %99 of the browsers — making it the most cross-browser method.

Though it proved to have some performance challenges.

Other dominant competing methods was JSONP and XHR.

JSONP is inherently cross-domain compatibly while XHR had cross-domain communication support with the introduction of CORS and IE introduced CORS support in IE8. Back at the time I wrote above comparison article IE6 and IE7 market share was %19,6 according to statistics hence rendering the XHR CORS method not available in at least %19,6 of the market. Now, things has changed and IE6 and IE7 market share dropped to %1.5 as of October 2012.

This makes XHR with CORS compatible with the vast majority of the market, most likely above %95. So, XHR is a serious choice again.

JSONP virtually has 100% browser compatibility.

Furthermore, JSONP and XHR are mobile device friendly unlike Flash. This leaves us two serious competitors for modern times, JSONP and XHR.

I believe it is justified to chose XHR technology for cross domain communication today.

YouTube API already has XHR support with this new access control specification. Though, Facebook still uses JSONP internally for most of its communication, probably because it is working just fine.

Caveats of XHR CORS

From now on, I’ll refer to XHR assuming it has CORS implementation.

Now, there are at least two types of XHR requests defined as I’ve already wrote about here.

- Simple requests: These are the requests with HTTP methods GET, POST or HEAD and have no custom HTTP headers in it.
- Not so simple requests:  Any request who does not fit into above criteria is not a simple request and requires a preflight request (explained below). So, this renders strictly RESTful APIs which rely on PUT and DELETE methods less robust.

What is a preflight request ?

If browser decides it requires a preflight request, it first sends an HTTP request with method OPTIONS to ask if the server allows you to do cross domain requests to her then the actual request is executed. So a preflight request means doubling your number of requests for a resource. If you keep asking for the same resource (URL part before that #) preflight cache will be used and you’ll spare subsequent OPTIONS requests. But if you ask for different resources (foo.php?q=a and foo.php?q=b) then each of these requests will require preflight requests.

So what can be do about preflight requests ?

- We can use a simple requests which does not require preflight requests at all — that is only GET, POST, HEAD methods with no custom headers.

If that is not an option and we inevitably need preflight requests — for instance because we need to add custom HTTP headers to our request:

- We can use a single entry point to our api (api.php) and pass all the parameters via POST to keep the URL fixed hence there will only be one preflight request. Basically, we’ll just have http://api.foo.com/api.php and send all the parameters to that very same resource with POST parameters hence require only one single preflight request.

Sometimes, the JS libraries we use send custom headers by default. For instance ExtJS, Dojo and Prototype JS libraries were sending custom HTTP headers without consulting the developer, rendering a simple request complex one and hence requiring a preflight request. Maybe some of those libraries have some ways to stop this behavior, I haven’t check.

For instance, with ExtJS you can stop it using custom headers with the following  property.

Ext.Ajax.useDefaultXhrHeader = false;
Ext.Ajax.request({url: ............... });

Note that, this API is not documented for normal ExtJS as it is marked as a private API but it is documented in ExtJS Touch API.

Conclusion for server-side designs

You have two options

1) Single entry point API handler

I believe the most robust way is to have a single entry point and encourage using POST method only. All interaction will be done on your entry point so even if preflight is required, it will be done only once.

HTTP POST your parameters, such as {controller: user, method: search, query: foo} to http://foo.com/api.php. Note, that you are always interacting with the same URL. POST method is chosen over GET because it can reliably send more data than GET method.

This pattern contradicts with most of the server-side you’ll find today as they adopt MVC pattern with pretty URLs as their design choice.

2) Pretty URLs with strictly simple requests

The frameworks out there which adopted MVC pattern and preferred pretty URLs create many resources. This might have an impact on the performance as they might require separate preflight request for each resource such as http://api.foo.com/post/5 and http://api.foo.com/post/8 are both different resources and require separate preflight requests — unless they are strictly simple requests.

So, if we want to use multiple resource APIs, we should make sure our clients are sending simple requests. Otherwise we’ll perform poorly as a preflight will be required for each resource.

Final thoughts for server-side design

In many scenarios the only difference between the implementation of two options listed above is an HTTP rewriting module in the web server. As you can rewrite http://api.foo.com/user/add into http://api.foo.com/?c=user&m=add anyway. Their implementations are pretty much the same but the way they perform in different scenarios are different — as one of them would require preflight and the other won’t.

As for the CORS specification. I couldn’t figure out, why the CORS specifications require separate preflight requests per resource. I believe a domain/path wide access-control policy would be more robust.

If particular resources need special restrictions they could still do it, as each HTTP request has an origin header in it, per resource restrictions might be applied too.

I don’t know why it hasn’t been designed this way.

Client-side design

Everything is fine, we pretty much decided how should our API ideally be designed. Now, what ?

With the new web application design, server-side is just for data retrieval, so we need a powerful ways of designing our user experience in the client side.

There are many Javascript libraries out there, such as venerable jQuery but rarely they provide high quality UI components. Windows provides many controls, similarly, other frameworks such as Qt also provides tons of widgets that we can assemble together to build an application but Javascript ecosystem is just catching up.

If you don’t need many UI components such as Grids, Panels and layout managers you should definetely go with jQuery, it is a very innovative and intuitive library that would dramatically make your work simpler.

But if you need a more corporate-like professional applications, you want a consisten look among all your UI components and a big collection of components to chose from. In that respect, ExtJS comes into play. They provide a very high quality JS library. Yet, they naturally, have a much more steep learning curve.

How to glue client-side and server side

Most of the time you have to glue them together manually. This is one department we have to work on. I’m speculating ideas about to generate a JS API on the fly by server via Refletion APIs of the server-side languages. In fact, I’m playing with a server side framework idea does generate an API specification automatically, as you add more services to it. Here’s a sample output.

{
  "Project":{
    "test":{
      "parameters":{
        "name":{
          "optional":false,
          "type":{
            "name":"String"
          }
        },
        "surname":{
          "optional":false,
          "type":{
            "name":"String"
          }
        }
      }
    }
  },
  "Session":{
    "status":{
      "parameters":[

      ]
    },
    "create":{
      "parameters":[

      ]
    }
  },
  "User":{
    "getStatus":{
      "parameters":[

      ]
    }
  }
}

In the mean time, ExtJS acted quicker and they propose a solution to this problem with Ext.Direct. I’ll study its design and probably write about it soon.

When I was looking for ways to design my models, I was quite surprised that it is such a pain in the ass. There’s a huge demand for this and a tremendous amount of work has been done but they all seem unintuitive and overly complicated.

For instance take a look at propel’s modeling language

<?xml version="1.0" encoding="UTF-8"?>
<database name="bookstore" defaultIdMethod="native">
  <table name="book" phpName="Book">
    <column name="id" type="integer" required="true" primaryKey="true" autoIncrement="true"/>
    <column name="title" type="varchar" size="255" required="true" />
    <column name="isbn" type="varchar" size="24" required="true" phpName="ISBN"/>
    <column name="publisher_id" type="integer" required="true"/>
    <column name="author_id" type="integer" required="true"/>
    <foreign-key foreignTable="publisher" phpName="Publisher" refPhpName="Book">
      <reference local="publisher_id" foreign="id"/>
    </foreign-key>
    <foreign-key foreignTable="author">
      <reference local="author_id" foreign="id"/>
    </foreign-key>
  </table>
  <table name="author" phpName="Author">
    <column name="id" type="integer" required="true" primaryKey="true" autoIncrement="true"/>
    <column name="first_name" type="varchar" size="128" required="true"/>
    <column name="last_name" type="varchar" size="128" required="true"/>
  </table>
  <table name="publisher" phpName="Publisher">
   <column name="id" type="integer" required="true" primaryKey="true" autoIncrement="true" />
   <column name="name" type="varchar" size="128" required="true" />
  </table>
</database>

And I’m just ranting how it could be defined, just bare with me.

<book>
  <title max="255"/>
  <isbn:int len="13"/>
  <publisher:publisher/>
  <author:author/>
</book>

<author>
  <first_name max="128"/>
  <last_name max="128"/>
  <books:book[]/>
</author>

<publisher>
  <name max="128"/>
  <books:book[]/>
</publisher>

I think any programmer who is familiar with array accessor operator [] would immediately understand what about model means exactly.

Defaults

* Each table has a INT PK AI (Primary Key, Auto Increment)

* Each field is required=true and type=text. I put the max=”128″ just to represent as much information as the original XML does.

Defining cardinality (relationship association types)

one-to-one

Imagine each book can has only one author and each author can only have one book.

<book>
  ...
  <author:author/>
</book>

<author>
  ...
  <book:book/>
</author>

This should generate either author_id field in the book entity OR book_id in the author entity.

Note that this schema is also applies for one-to-many. If enforcing one is required, then a unique index can be created for author_id or book_id field.

one-to-many

Imagine each author can have many books (naturally).

<book>
  ...
  <author:author/>
</book>

<author>
  ...
  <book:book[]/>
</author>

This will generate author_id in the book entity and that’s it.

many-to-many

It is perfectly possible for one book to have many authors, so here’s what we do.

<book>
  ...
  <author:author[]/>
</book>

<author>
  ...
  <book:book[]/>
</author>

Then, we should generate a book_author entity with fields book_id, author_id. Then we can insert as many book-author links as we want.

There might be cases which this syntax fail to define which I can’t think of right now.

Syntax

We can use verbose element attributes such as

<title type="string" required="true" len="10" index="true"/>

Or we can extract common properties of each element and innovate a shorthand syntax for them.

field[*?][:type[(min,max)]] [|validator_function]

Data Types

Known data type with built-in validators

These principles and patterns makes the code easier to maintain and test. Furthermore, these separations gave us other opportunities. It showed us once you had your model ready, there are a lot of repeated work to be done.

1. Building a Data Access Layers (DAL) to persist and manipulate the objects programatically.
2. Building the graphical user interfaces (GUI) to let users manipulate the objects — and god… validate the input data.
3. Building an application programming interface (API) to let other programs manipulate the objects — and again… validate the input data.

These tasks have a base no-brainer code to be prepared all the time. Worse, you need to update all these codes when you update your model. If you do not automate this process, you will be reluctant to make any changes to your program because it is such a pain in the ass — not to mention all the errors you’d make.

So, it is inevitable that programmers all around the world will find ways to generate code for above tasks. The first one of the above tasks is called Object Relational Mapping (ORM) and there are countless projects available to do that. ORM is basically generating code that does Create Read Update Delete (CRUD) operations.

Even though most of the ORM projects achieves same goal, they do have different design choices

ORM Design Choices

1. Generation of type safe strong interfaces

Strong interfaces and type safety are inherently available in many platforms like C# and Java and you can’t go wrong with them but ORM is often used with dynamic languages which lacks many of these features, so ORM projects must take extra cautions. CakePHP is not just an ORM framework but a complete solution which can dramatically speed up development time for many scenarios. Though, I do not agree with some of their design choices. For instance CakePHP’s ORM generates Models with weak interfaces.

// Instead of doing this
class StrongInterfaceBook
{
    public function getTitle();
    public function setTitle($str);
    public function getAuthor();
    public function setAuthor(Author $author);
}

// CakePHP generates code like this
class WeakInterfaceBook
{
    public function __call($name, $arguments)
    {
         // Figurative code
         $_fieldsToBeUpdate[$name] = $arguments[0];
    }
}

// So, when you call
$c = new WeakInterfaceBook();
// Not the intentional erros in the following line
$c->setTilte('Foo');
// Your code will execute just fine ignoring the Title field, as it does not exist.

// If you do that with strong interface
$c = new StrongInterfaceBook();
$c->setTilte('Foo'); // Raises a compile time error.

Furthermore, generating strong interfaces help your IDE to auto-complete your code, as the interface can actually be indexed.

I, also, believe that generated code should catch your errors as soon as possible and shouldn’t allow any silent errors as in the above example. Imagine you’ve changed your model and renamed a field. Weak interfaces won’t catch the errors and where a strong interface will raise an error as soon as it is compiled.

For PHP, Doctrine and propel generates strongly typed, strong interfaces.

For .NET environment, sqlmetal, which is the code generation utility of Microsoft, generates strongly typed interfaces with an ground braking API (LINQ) which has been inspired many frameworks such as propel. Once you know the caveats of LINQ, it is the ultimate DAL.

CakePHP is also not designed to regenerate your model code all the time — as it overwrite generated model code in each execution, so you have to merge your changes from your version controlling system back to regenerated code.

In other frameworks, you usually derive from the generated code

public class BookBase
{
    public string Title
    {
         get
         {
              return m_title;
         }
         set
         {
              validateTitle(value);
              m_title = value;
         }
}

public class Book : BookBase
{
    // Add additional functionality here, so code generated overwrites does not affect you
}

Microsoft’s and propel’s code generation tools use this design pattern when generating code.

2. Utilizing data types and model relationships

Models can define some basic things about its fields, such as minimum, maximum values and length which can be easily checked. If the field is of enum type then allowed values are strictly defined so invalid inputs are easy to catch.

3. Performance

This is least of my concerns, any widely used framework will be well optimized. IMHO, best approach is to generate as much strongly typed code as possible. Even if you rely on runtime introspection, caching will save the performance penalty anyway.

ORM approaches

In my humble opinion, models are the core of any design. Once you have defined  your model you can get save yourself the trouble of writing boilerplate code all over.

1. Code first

You code your classes, most probably with some extra meta data which is called annotations in Java and attributes in C#. And PHP has a fake annotations which is implemented by extracting meta data from documentation blocks via reflection API.

Some framework such as Doctrine and CakePHP does not allow you to export this model to a easy to read file but they provide extensive introspection API which you can extract all the information from the models.

I, personally, do not like this approach as it does not feel intuitive to me. It is a different way you have to define your model in each platform.

There are many solutions which use this approach such as Java’s Hibernate and PHP’s Doctrine. Each project claims to support Database First approach too but they do not favor it and it is not well documented.

2. Model first

You define your model here and then generate SQL code to generate the schema in your preferred data base, generate DAL code, or even a REST API complete with documentation and test cases.

I think this is a very good way to start to your project but making changes to your model after you get started (which is inevitable) would require you to sync your database schema with the new model. I’ve used tools which does this before but I’m not familiar with how Model First ORM frameworks hand database syncing yet.

2. Database first

You create your database schema and extract your model from there. I find this approach fine, as there are many tools to let you design your database easily and most likely with the aid of graphical tool. It is like designing your model in SQL and then converting the model from there. Also by changing your schema on the database eliminates syncing your database with the model problem.

Conclusion

I favor the code first approach the least but as long as they export the model information in a concise manner, I’m fine with with either of the approach.

Once you have extracted  or designed your Model. There are endless possibilities.

1. You can generate DAL

2. You can generate web services to expose your objects

3. You can generate ExtJS models so that ExtJS can communicate with your services

4. You can generate ExtJS UIs

And what’s better is, once you changed the model, your changes will be propagated in all your frameworks, given you have followed proper design patterns.

Eclipse PDT does not allow you to use external browser. You can work around this though.

Add these two lines to your php.ini

xdebug.remote_autostart = true
xdebug.idekey="ECLIPSE_DBGP"

Keep reading for details

Xdebug works like this: Debugger listens for incoming connections and whenever you send a HTTP request to server, the server itself tries to connect to the debugger client.

To achieve this, Eclipse PDT opens a page in the internal browser with some parameters appended to the URL. These parameters tell PHP interpreter that a debug session is desired.

http://localhost:81/eclipse/cake/caketest/?XDEBUG_SESSION_START=ECLIPSE_DBGP&KEY=13535270012515

When opening from an external browser you don’t have this, in an autmated manner. So, we use xdebug.remote_autostart parameter in php.ini. With the parameter every HTTP request you send to your server which invokes PHP interpreter makes the server try to connect to remote debugger automatically. So you are supposed to not to need the parameters in the URL above.

But it didn’t work. So I enabled xdebug.remote_log and saw the following:

Log opened at 2012-11-21 19:57:02
I: Connecting to configured address/port: 127.0.0.1:9000.
I: Connected to client. :-)
-> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" fileuri="file:///C:/Users/Engin/Code/PHP/eclipse/cake/caketest/webroot/index.php" language="PHP" protocol_version="1.0" appid="11472" idekey="ENGIN-VAIO$"><engine version="2.2.1"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[http://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2012 by Derick Rethans]]></copyright></init>

-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" status="stopping" reason="ok"></response>

Log closed at 2012-11-21 19:57:02

Then I watched the log for a successful debug session with the internal Eclipse browser.

Log opened at 2012-11-21 19:58:46
I: Connecting to configured address/port: 127.0.0.1:9000.
I: Connected to client. :-)
-> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" fileuri="file:///C:/Users/Engin/Code/PHP/eclipse/cake/caketest/webroot/index.php" language="PHP" protocol_version="1.0" appid="2324" idekey="ECLIPSE_DBGP"><engine version="2.2.1"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[http://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2012 by Derick Rethans]]></copyright></init>

<- feature_set -i 86 -n show_hidden -v 1
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="86" feature="show_hidden" success="1"></response>

<- feature_set -i 87 -n max_depth -v 3
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="87" feature="max_depth" success="1"></response>

...

As you can see idekey is different. Hence we also used xdebug.ide_key and it all works out. Finally…

For the sake of completeness, here’s my whole xdebug configuration from php.ini

zend_extension = "c:\Users\Engin\bin\LAMP\php-5.4.8\xdebug\php_xdebug-2.2.1-5.4-vc9.dll"
xdebug.default_enable=0
xdebug.remote_enable=1
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_autostart = true
xdebug.remote_log="c:\Users\Engin\bin\LAMP\php-5.4.8\xdebug\log"
xdebug.idekey="ECLIPSE_DBGP"
xdebug.dump_globals=1
xdebug.dump=COOKIE,FILES,GET,POST,REQUEST,SERVER,SESSION
xdebug.dump.SERVER=REMOTE_ADDR,REQUEST_METHOD,REQUEST_URI
xdebug.show_local_vars=1
xdebug.show_mem_delta=1
xdebug.collect_includes=1
xdebug.collect_vars=1
xdebug.collect_params=4
xdebug.collect_return=1
xdebug.auto_trace=0
xdebug.trace_options=0
xdebug.trace_format=0
xdebug.trace_output_dir="c:\Users\Engin\bin\LAMP\php-5.4.8\xdebug\trace"
xdebug.trace_output_name="trace.%t"
xdebug.profiler_enable=0
xdebug.profiler_append=1
xdebug.profiler_enable_trigger=1
xdebug.profiler_output_dir="c:\Users\Engin\bin\LAMP\php-5.4.8\xdebug\profiler"
xdebug.profiler_output_name="cachegrind.out.%s.%t"

To do the permanent redirect from my old domain to new one, Apache HTTPD has this awesome feature, check this out:

<VirtualHost *:80>
        ServerName www.bzzzt.biz
        ServerAlias bzzzt.biz *.bzzzt.biz
        Redirect permanent / http://ea.tl/
</VirtualHost>

Mind the trailing /, at the end of ea.tl, that matters.

Cheers… I’m just getting more awesome day by day.

Actual error:

[Wed Nov 07 19:35:27 2012] [error] [client 78.171.237.162] SoftException in Application.cpp:299: Script "/home/engin/www/api.php" resolving to "/home/engin/www/api.php" not within configured docroot

It’s easy to think that this is related to Apache vhost configuration’s DocumentRoot but it is not.

My application which is working was located in /home/usera/public_html and the failing one was in /home/userb/www. Now check the /etc/suphp/suphp.conf‘s docroot variable:

docroot=/var/www:${HOME}/public_html

As you see, ${HOME}/public_html is in the docroot, hence one of my application was working and the other one was not. I moved www to public_html and all is fixed.