Legitimate cross site scripting (CSX) with AJAX

How do you do legitimate cross site scripting?

If you control the servers involved, this is how you can do cross site scripting with AJAX.

I recently came across a situation where I wanted to do an AJAX load from one server to another server. Internally to our campus, our students use a wiki and a ruby on rails web application. I wanted information contained in our rails application to show up on the wiki. My first impulse was to use jquery's load method, however, I received the following error:

Access to restricted URI denied" code: "1012

My first work around is just to avoid the AJAX load and use an iframe. However, inspiration hit me a few weeks ago and I tried a different solution. Since the AJAX load can retrieve information from the same website, maybe I should request a special url on the same machine and use apache to hide the fact that the content is coming from a different domain name. This can be accomplished with the apache ProxyPass command.

Let me give a concrete example. Say you have two websites: a static site that serves html pages through apache from the filesystem (http://static.sv.cmu.edu) and a dynamic site using an application server with a database (http://dynamic.sv.cmu.edu). You want some of the information from the dynamic site to show up on the static site. You want to allow users to add comments to a static webpage where the comments are rendered by the dynamic site.

Your first attempt might be:

$('#comments').load('http://dynamic.sv.cmu.edu/comments');

Which results in the error.

In static.sv.cmu.edu's httpd.conf file add the following line:

ProxyPass /comments http://dynamic.sv.cmu.edu/comments

Now from your browser window, test to see if you can access the dynamic data from the static machine: http://static.sv.cmu.edu/comments should give you the same information as would http://dynamic.sv.cmu.edu/comments

Now your AJAX code will work.

<script type="text/javascript" src="http://code.jquery.com/jquery-latest.js"></script>
<script type="text/javascript">
//<![CDATA[
$(document).ready(function(){
$('#comments').load('http://dynamic.sv.cmu.edu/comments');
});
//]]>
</script>

Guidelines for evaluating an Agile Maturity Model

When it comes to any Agile Maturity Model (AMM), it is paramount to start with the business value with respect to the framework. The framework should clearly identify the business and software engineering issues it is trying to solve.

The framework should be simple to understand. It's essence should be straightforward. Practitioners should be able to start applying the concepts and see progress. Days of training should not be a pre-requisite for adoption.

I am very reluctant to place any named method into different defined levels, unless the analysis is multi-dimentional. Let me be concrete. When an IBM employee identifies RUP as a Level 2 method and Scrum and XP as Level 1 methods, it is an open invitation for skeptics to find immediate cause to reject the maturity model as biased toward company loyalism. This is not to say that we should not compare and contrast different methods. Larman compares methods by ceremony and cycle while Cockburn scale's uses team size and criticality to determine a version of Crystal to use.

Extreme Programming: After 10 Years, Why Are We Sill Talking About It?

At the first keynote for SD West 2009 conference held in Santa Clara, CA, USA, Robert Martin (aka Uncle Bob) reflected on the history of the Agile movement, both what Extreme Programming and Scrum have done for the industry, and the need for Software Craftsmanship

Ten years ago, Extreme Programming had just arrived on the scene. People's reactions were either excitement or revulsion. Programmers who suffered under heavy weight processes rejoiced that they could get work done. The method has a high geek factor as it gave specific guidelines on programming and testing. This made it appealing to programmers but made it difficult for project managers or businessmen to get excited about it. Those who revulsed complained that without architecture and a thorough design, the software would become a mess. Because of these two reactions, Extreme Programming received a lot of attention.

After the birth of the agile manifesto at the Snowbird, Utah meeting, there were some unintended consequences. One was finding a better term to describe the new "lightweight" methods, and the term "agile" stuck. The success of adoption was beyond what they were expecting. Another interesting consequences was the new attention given to scrum.

Scrum is a near perfect subset of the Extreme Programming practices. It has the many of the same project management practices (Small Releases, Release Planning, Acceptance Tests, Whole Team, Product Owner) without the technical practices (Refactoring, Simple Design, Test Driven Development, Continuous Build, Paired Programming). In short, it doesn't "smell" of geeks. Scrum made agile palatable to business people. The scrum certification process allowed agile to cross the chasm as scrum became mainstream.

What got left behind were the engineering disciplines or "software craftsmanship." With scrum, you can turn the iteration crank very quickly, yet over time, the crank can get harder to turn as a mess begins to emerge. The nay-sayers of XP were correct in this regard, without replacing architecture and design with technical practices, you do get a mess. Now there is emerging talk of craftsmanship. People are using Katas to study how to write software. They write the same piece of software over and over again to learn technical mastery of software. Last Friday, the Manifesto for Software Craftsmanship was released. Robert ended his keynote with a plug for his Clean Code book and a green Clean Code bracelet that helps remind you to leave the world of code a better place by improving each module you come across.