View Ryan Knight's profile on LinkedIn


Recent Posts



Tutorial: Deploying a Play Framework 2.0 Beta Web Application to Heroku with PostgreSQL

For a background on deploying a Play 1.2 application to Heroku see the last half of James Ward blog post on building a Play Web Application.  Deploying a Play 2.0 application to Heroku application which connects to a PostgreSQL Database requires a number of extra steps.

In the previous tutorial we walked through creating a basic Play 2.0 Beta web application with Ebean, JSON & JQuery.  Now we will deploy this web application to Heroku.  First we will deploy using the default in-memory h2 database. Note that all of these commands need to be run in the root directory of playbars2.

Step 1) login to Heroku from the command line:

heroku login

Step 2)  Test building and running the application locally.  First we need to add a plugin to the build process.  In project/plugins.sbt file add:

addSbtPlugin("com.typesafe.startscript" % "xsbt-start-script-plugin" % "0.5.0")

When an application is deployed to Heroku, it is compiled using sbt, the scala build tool, and then run using a script specified in a Procfile.  We can first test this process locally by running the sbt compiler locally:

sbt clean compile stage

If you look in the target directory you will see a start script has been generated.  This is the same script Heroku will use to run the application.  We can test this locally by running:


Now you can test the application by going to: http://localhost:9000/

Step 3)   Add the configuration files to tell Heroku how to deploy the application.  By default Heroku will try and deploy the application as a Play 1.2 application.  To deploy a Play 2.0 application first we need to add a Procfile to the root directory with one line:

web: target/start

This is simply telling Heroku to run this web application using the script in target/start.

Step 4)  Git is used to upload applications to Heroku, so we first need to setup git.  When an application is with the play new command it adds a .gitignore file, so we can safely add the entire directory to git and none of the generated directories will be included.

git init
git add .
git commit -m 'init'

Step 5) Create a new application on Heroku and deploy the application in the cloud.

heroku create -s cedar
git push heroku master

The great thing about git is you can push to multiple targets, unlike svn that has a single repository.  When you run the heroku create command it has added an additional target named heroku that we push to.  The heroku target is a named alias for the location of the stack that was created for us.  So after setting up Heroku, I can still push to my original github repository, using the target named origin.

git push origin master

Check that your applicaiton is up using:

heroku ps

You can monitor the Heroku logs to see if there are any errors in the deployment using:

heroku logs

or to tail the logs:

heroku logs -t

Step 6) You can now test the application by going to the url specified in heroku create or running:

heroku open

Step 7)  Now we need to modify the application to work with the PostgreSQL Database, the database used with Heroku.  First we need to add support for the PostgreSQL libraries.  In the project/Build.scala add/update the following:

val postgresql = "postgresql" % "postgresql" % "9.0-801.jdbc3"
val appDependencies = Seq(
// Add your project dependencies here,
jacksonCoreAsl, jacksonMapperAsl, postgresql

Next we need to modify the application configuration to point to PostgreSQL.  In the current Play 2.0 Beta the config files are not updated with environment variables.  Instead we have to manually configure the database for the specific environment (definitely not a good practice).  First find the database URL from heroku by running:

heroku config

You will get something like:

DATABASE_URL => postgres://username:password@ec2-107-22-193-180.compute-1.amazonaws.com/username

This needs to be translated into a proper jdbc URL.  In the conf/aplication.conf comment out the in-memory database and add the url for the PostgreSQL database:



Step 8) update git and Heroku with the changed files

git add project/Build.scala conf/application.conf
git push heroku master

Check that your application is up using:

heroku ps

Now when you access the application, it will be using PostgreSQL database. Test it out by accessing: http://localhost:9000 If you need to shutdown your applications or need a clean start you can get a list of your applications with:

heroku apps

And then destroy the application with:

heroku apps:destroy --app sharp-ocean-4302

You now have a Play 2.0 Beta Web Application running on Heroku using a PostgreSQL database.


Tutorial: Play Framework 2.0 Beta with Ebean, JSON & jQuery  

This tutorial is a port of James Ward’s Tutorial on building a Web Application with Play 1.2.3 to Play 2.0 Beta.  The Play 2.0 Beta is a major re-write of the Play Framework and uses a whole new approach to writing Web Applications.  Deployment of the web application to Heroku will be discussed in the next blog post. This tutorial use the Play 2.0 Beta Release on November 16.  Documentation is sparse at this point, so I had to make some guesses on how to get some things to work.  To make it easier I stuck with the original release instead of updating to the latest source branch.

The source of this tutorial is on github.

Step 1)  Download and install Play 2.0 Beta - I unzipped it into a directory called play2beta.

Step 2) Create a new Play app from the command line, using a Java Template:

 play new playbars2

For the template choose “Create a simple Java application”

Step 3)  Change to the new application’s directory and start the server.  It is important to first run the server before trying to load the application in an IDE.  This is because it generates a number of dependencies need to compile the application.

cd playbars2
play run

The server is now running at the URL: http://localhost:9000 The beta release does not have URL’s for documentation and JavaDocs.

Optional Step 4) Setup the application in your favorite IDE.  Add the following jar files and directories from the framework to this list of dependencies:


And then add these directories from the application itself.  These are the directories that are generated by the Play Framework.


Step 5)  Create a basic Model class.  Instead of inheriting from the Play Framework Model class, the class extends from the Ebeans Model class.  This class provides the basic save, update and delete methods.  To get the basic read operations, such as find all, we need to create a Finder.   For the most part Ebeans is similar to JPA and uses the same annotations as JPA.

public class Bar extends Model {
public String name;
// -- Queries
public static Model.Finder find = new Model.Finder(String.class, Bar.class);

Step 6)  Define the routes to the different methods in the conf/routes file:

GET / controllers.Application.index()
GET /bars.json controllers.Application.listBars
POST / controllers.Application.addBar

The format of the file is still the same.  It specifies what URL’s map to what methods.  For example we define the URL get request for /bars.json maps to the action of listBars, which returns all the bars in JSON format.

Step 7) To create the web UI we will use reuse the HTML and JQuery from the previous sample.  The difference is the Play Framework now uses Scala for the template language. The first page to look at is app/views/main.scala.html   The first line declares two variables that will be used in the page:

 @(title: String)(content: Html) 

These variables are used later in the page to set the actual values of the title and content of the page:


The rest of the page is fairly standard HTML, the only difference is how references to assets and scripts are made.  They use a special syntax so that Play can properly resolve the references:


The index.scala.html page also declares two variables, which are referenced later:

@(message: String)(barForm: Form[Bar])

The syntax for declaring the form variable, barForm, is similar to Java Generics and declares the type of the form. Form[Bar] means the type of the Form will be the Bar model. It then includes the main.scala.html page and defines values for the first two variables of  main, title and content:

@main("Welcome to PlayBar 2") { ...... } 

The content between {   } is the content that is put into the main page. The content of the page declares the HTML form that is used to add a bar and tells what  action to use to process the form, the addBar method in Application.  It also defines an ID, barForm,  which is used to reference the form:

@form(action = routes.Application.addBar, args = 'id -> "barForm") {
   field = barForm("name"),
   args = 'label -> "Name of bar?", 'placeholder -> "Foo Bar"
<p class="buttons">
   <input type="submit">

When the submit button is clicked, the results will be routed to addBar.

Step 8) Add JSON support.  JSON support is now included in the latest source code of the Play Framework, but is not in the early beta.  As a work around I included the source to encode Objects to json in my sample (copied from the Play Source code). The Jackson JSON libraries also need to be added to the list of project dependencies.  By adding them to Build.scala, when we deploy to Heroku it will be able to also download the necessary jar files.  Modify the file to add the following lines:

val jacksonCoreAsl = "org.codehaus.jackson" % "jackson-core-asl" % "1.9.2" val jacksonMapperAsl = "org.codehaus.jackson" % "jackson-mapper-asl" % "1.9.2"  val appDependencies = Seq( // Add your project dependencies here, jacksonCoreAsl, jacksonMapperAsl ) 

Step 9) Next we need to define the methods that do all the server processing in  “app/controllers/Application.java”.    As opposed to the previous version of play, all of the methods return a Result class.  The Result ok method is used to return a 200 OK Result, along with the data to be returned. When the application is first load it will call the Application method index.  That method references the index.html.scala page and defines the two values to be used for message and barForm, defined at the first of the index page:

return ok(index.render("Enter the name of your new bar:", form(Bar.class))); 

Another big difference with Play 2.0 is how forms are processed.  Instead of passing the model class into the method, you create a new instance of a form based of your class.  In the addBar we create a form object and have it bind the data from the request for processing.  Once we have the bar we can use the inherited methods from Ebeans model to save the model.

Form form = form(Bar.class).bindFromRequest();
  if (form.hasErrors()) {             
      return badRequest(index.render("Error in Bar form.  Enter new Bar",form(Bar.class)));         
  } else { 
      Bar bar = form.get();            
      return ok( index.render("The bar  " + bar.name + " was saved.   Enter a new Bar:", form(Bar.class)));         

Then to list the bars we use the findAll we defined in the Bar model class and convert the results to JSON:

return ok(toJson(Bar.findAll())); 

Now you can test the application by going to: http://localhost:9000/

We now have a working Play 2.0 Beta web application.  Deployment of the web application to Heroku requires a number of extra steps and will be discuss in the next blog post.  This sample is also lacking several things, which will be covered in other tutorials (things such as tests and flexible configuration).


Using Annotations with Spring AOP

When I was first looking for information on how to use annotations with Spring AOP I skipped the section on @AspectJ support. Later I realized that this is the section on annotations. Spring AOP uses the same annotations as Aspect J. It is still a pure Spring implementation using dynamic proxies and does not use the AspectJ compiler and weaver.

As the documentation explains, “Spring 2.0 interprets the same annotations as AspectJ 5, using a library supplied by AspectJ for pointcut parsing and matching.” The reason for this is AspectJ already has a fairly extensive library for declaring pointcuts using annotations. For more information on @AspectJ see the website - http://www.eclipse.org/aspectj/

The example code for this tutorial is on github.

Spring Configuration

The first step is to configure spring to use the AspectJ library in the spring config file (i.e. spring-config.xml). You will also need to add the necessary schema definitions (see the example file here):


And then tell Spring to scan your classes for the annotations:

<context:component-scan base-package="tmo">
	<context:include-filter type="annotation" expression="org.aspectj.lang.annotation.Aspect"/>

Creating an Annotation

The annotation is created using standard Java syntax. An important part is to declare the annotation to have a retention policy of runtime. The default value is class, which means the annotation is not retained by the JVM at runtime.

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(value = RetentionPolicy.RUNTIME)
public @interface Timed {

Declaring the Aspect

In this example (shown in the SystemTiming.java file) we will be declaring basic around advice, wrapping the annotated method. This example will record how long it took to a method to execute. The annotations used come from the AspectJ library. First we declare a class to be an aspect using @Aspect:

public class SystemTiming

Then in the class we declare the advice along with a pointcut expression used by Spring to know where to inject the advice:

@Around("@annotation( timedAnnotation )")
public Object processSystemRequest(final ProceedingJoinPoint pjp, Timed timedAnnotation) throws Throwable {

This says this around advice should be applied any methods marked with the Timed annotation. The pointcut expression actually matches the parameter declaration in the method. The best way to understand this is to think of the method actually being declared first and then the pointcut following. This becomes important as the pointcut expressions get more complicated. You can actually simplify the expression if you don’t need to access the annotation by leaving the annotation out of the method declaration.

@Around("@annotation( Timed )")
public Object processSystemRequest(final ProceedingJoinPoint pjp) throws Throwable {

Inside the advice we then need to call proceed to execute the actual method. An interesting benefit of this is we could stop execution of the method all together, for example if the user did not have the right credentials.

try {
	Object retVal = pjp.proceed();
	return retVal;
} catch (Throwable t) {
	throw t;

The advice can also get information about the method being wrapped. As an example we will add some basic pre and post processing around the method. For this example we want to wrap the method call in timing and then log the name of the method along with the time it took to execute the method:

long start = System.currentTimeMillis();
Object retVal = pjp.proceed();
long end = System.currentTimeMillis();
long differenceMs = end - start;

MethodSignature methodSignature = (MethodSignature) pjp.getSignature();
Method targetMethod = methodSignature.getMethod();

System.out.println(targetMethod.getDeclaringClass().getName() + "." + targetMethod.getName() + " took " + differenceMs + " ms”);
return retVal;

Using the Annotation to Log Method Calls

Using the annotation is very simple. All that is needed is to add the annotation above a method (shown in the RateServiceImpl.java file):

public void doWork() { ..... }

By simply adding this annotation to the method now the around advice will be applied and the method timing will be logged.

Advanced Spring AOP with Annotations - Adding Values to an Annotation

Annotations can have variable declarations that allow you to pass extra information into the advice:

public @interface Timed {
	String timingNotes;

To access the annotation, the annotation needs to be passed as a parameter to the advice:

@Around("@annotation( timedAnnotation )")
public Object processSystemRequest(final ProceedingJoinPoint pjp, Timed timedAnnotation) throws Throwable {

Then inside the advice we can access the annotation information:

String timingNotes = timedAnnotation.timingNotes();
//log additional timing notes here ....

When the annotation is declared, then additional information can be added to the annotation.

@Timed(timingNotes = "this is a slow service")
public void doWork() { ..... }

This example would allow you to put additional notes or information that needs to be logged along with the method timing.

Accessing method arguments

As a final addition to the advice suppose all the methods we are logging have a common parameter that we want to access. For example suppose each method takes an authentication token as a parameter and we want to log that token (probably not a good idea because this would create a security hole in the system).

   @Around(value = "@annotation( timedAnnotation )  && args(param)")
    public Object processSystemRequest(final ProceedingJoinPoint pjp, Timed timedAnnotation, final ServiceRequest param) throws Throwable {

Inside the method we can now access the parameter to find out request information:

String requestInfo = param.getRequestInfo();

That is all it takes to use annotations with Spring AOP. Let me know if you have any questions!


Protection of Intellectual Property in Romania

Why off-shore development in Romania help protects your Intellectual Property

Romania is one of the best countries to work with for off-shore development for a variety of reasons.  They have a highly skilled, college educated work force who learn english from a young age.  And the country provides ideal protection of Intellectual Property for the following reasons:

  • As a member of the European Union, significant intellectual property protection exists in Romania for all four types of intellectual Property.
  • US and other international arbitration decisions are enforceable under Romanian law.
  • Relative to other common outsourcing destinations, Romania has a reputation for being a good place to do business.
  • Practical considerations (e.g., minimizing employee turnover) are important to protecting intellectual property when it is developed through outsourcing.


We will look in depth at Romania protects your IP.

1 - The Four Types of IP Protection.

There are four main types of legal protection for IP:

  • Patents
  • Copyrights
  • Trademarks
  • Trade Secrets   

We will discuss these in order.

A. Patents.       A patent for an invention is the grant of a property right to the inventor, issued by the Patent and Trademark Office in the United States or a similar body in other countries. The issuance of a patent allows the inventor to enforce its property rights against infringers. Patents are most commonly used to protect physical inventions, but may also be used to protect unique concepts contained in software or the application thereof, although obtaining a patent for software is often more difficult. The most far reaching international law regarding the protection of patented IP is the Patent Cooperation Treaty (the “PCT”) of 1970. The PCT allows an inventor to seek patent protection for an invention simultaneously in each of a large number of countries, including Romania. By filing for and receiving an international patent, an inventor may request protection in an individual member country through a streamlined domestic review and approval process for such country. While patent laws and enforcement mechanisms vary among signatories to the PCT, Romania has restructured and harmonized its national patent related laws to conform to applicable European Union regulations, including the European Patent Convention, which Romania ratified in 2002. Further, as a member of the World Trade Organization (“WTO”), Romania also agreed to comply with the WTO’s rules for trade related aspects of intellectual property, which is an international standard for the protection of IP. As a result of these actions and Romania’s involvement in the PCT, patented IP rights are protected in Romania and patent infringements can also be prosecuted and remedied in Romania.

B. Copyrights.     A Copyright is a form of protection provided to the authors of “original works of authorship,” including literary, dramatic, musical, artistic, technical and certain other intellectual works, both published and unpublished. Because software code is often not patentable, copyright protection of the written software code is the most common method of IP protection for software. The World Intellectual Property Organization (“WIPO”) is the preeminent international organization focused on the protection of copyrighted material and other IP. WIPO is a specialized agency of the United Nations that is dedicated to developing a balanced and accessible international IP system. Romania is a member of WIPO and is a signatory to the following WIPO treaties.

  • Berne Convention
  • Budapest Treaty
  • Hague Agreement
  • Lisbon Agreement
  • Locarno Agreement
  • Madrid Agreement (Marks)
  • Madrid Protocol
  • Nairobi Treaty
  • Nice Agreement
  • Paris Convention
  • Patent Cooperation Treaty
  • Patent Law Treaty
  • Phonograms Convention
  • Rome Convention
  • Singapore Treaty
  • Strasbourg Agreement
  • Trademark Law Treaty
  • UPOV Convention
  • Vienna Agreement
  • WIPO Convention
  • WIPO Copyright Treaty
  • WIPO Performances and Phonograms Treaty


     Each of these treaties has a different focus and objective, but two of the most significant relating to the protection of copyrights are the Berne Convention for the Protection of Literary and Artistic Works, and the WIPO Copyright Treaty. The Principles of copyright protection set forth in the Berne Convention have also been adopted by the World Trade Organization and WTO member states are required to comply with the substantive law provisions of the Berne Convention. This is significant because the WTO provides for enforcement mechanisms if any member country is not in compliance with WTO regulations and policies.

     Romania is also a signatory to the WIPO Copyright Treaty (the “WCT”) which specifically focuses on protection of IP related to computers and software. The WCT is a special agreement under the Berne Convention that requires signatories to comply with the substantive provisions of the 1971 Act of the Berne Convention which specifically sets forth IP protection for (i) computer programs, whatever may be the mode or form of their expression, and (ii) compilations of data (databases) or other material in any form, which by reason of the selection or arrangement of their contents constitute intellectual creations. The WCT requires each member country to provide legal remedies against the circumvention of technological measures (e.g. encryption) used by authors in connection with the exercise of their rights and against the removal or altering of information such as certain data that identify works or their authors. The WCT also requires each member country to adopt legal measures necessary to ensure the application of the WCT including ensuring that enforcement procedures are available under such member’s laws so as to permit effective action against any act of infringement of rights covered by the WCT. 2

C. Trademarks. Trademarks are used to protect words, names, symbols, sounds, or colors that distinguish goods and services from those manufactured or sold by others and to indicate the source of the goods.3    As indicated above, Romania is a signatory to the Trademark Law treaty, the Singapore Treaty on the Law of Trademarks and the Madrid Agreement Concerning the International Registration of marks, all of which aim to standardize and streamline the national trademark registration procedures of signatory countries and allow for the enforcement of registered trademark rights in member countries.

D. Trade Secrets. A trade secret is information, including a formula, pattern, compilation, program, device, method, technique, or process, that (i) derives independent economic value, actual or potential, from not being generally known to, and not being readily ascertainable by proper means by other persons who can obtain economic value from its disclosures or use, and (ii) is the subject of efforts that are reasonable under the circumstances to maintain its secrecy.4    Romania’s adoption of the WTO’s treaty on the Trade Related Aspects of Intellectual Property required Romania to implement certain legal standards for the protection of trade secrets, which it did by adopting the Romanian Unfair Competition Law in 1991. This law defines a trade secret as any information which is not generally known or is not easily accessible to the people usually dealing with this kind of information, which derives economic value from the fact of being secret and for which the legitimate holder took the reasonable steps to keep it secret. Early applications of this law indicate that anything may qualify as information of economic value: a process, the correction of a common error, an invention, an idea, a discovery, a prognosis, a list of clients or suppliers, a strategy, the source-code of software, a formula or a fact. These interpretations expand the scope of material offered protection under this law and provide for broad general protections for trade secrets in Romania. This law also establishes civil, administrative and penal liability for acts of unfair competition in trading or industrial activity, including the misappropriation or unauthorized use of trade secrets.

2 - General IP Protections and Enforceability in Romania.

Another significant development relating to the ability of businesses to protect their IP when doing business in Romania was the admittance of Romania as a member of the European Union in January of 2007. In order to be admitted to the European Union, countries have to demonstrate and maintain certain standards and legal protections, including with respect to the standardization and enforcement of IP related laws. In a European Union Directive on the Enforcement of Intellectual Property Rights issued in 2004, all member states were required to apply effective, dissuasive and proportionate remedies and penalties against those engaged in counterfeiting and piracy to create a level playing field for all copyright and patent holders doing business with European Union member states. The effect of this directive was to require that EU member states have similar laws, procedures and remedies in place to allow holders of IP rights to effectively protect and defend their rights. By becoming part of the European Union,


Romania is required to comply with this directive going forward and also had to meet certain compliance standards prior to being admitted to the European union.

The European Union has focused on protecting IP rights in software through promoting uniform and enforceable copyright and similar laws of members states. It first issued its Directive on the Legal Protection of Computer Programs in 1991, which set forth common minimum standards and model laws to be adopted by member states. A follow-up report issued in 2000 found that the member states had satisfactorily adopted the requirements set forth in the Directive. As a member of the European Union, Romania is also required to meet the standards contained in the Directive and is evaluated along with other EU members for satisfactory compliance.

3.    Enforceability of Arbitration Contract Clauses and Awards in Romania.

Romania’s legal system and laws currently in place allow companies to effectively enforce their contracts in Romania, including contractual arbitration clauses requiring arbitration outside of Romania. Romania’s legal provisions respecting arbitration largely follow the principles and structure of the United Nations Commission on International Trade Law’s Model Laws of 1985.5    Further, foreign arbitral awards are enforceable in Romania, pursuant to Article 3703 of the Romanian Commercial Code and Article 178 of Law No. 105/1992, which provide that foreign arbitral awards made by a competent tribunal have evidential force before the Romanian courts with regard to the facts which they establish without the requirement for formal recognition.

Further, Romania has a long history of enforcing both foreign and domestic arbitration clauses and awards. Romania ratified the New York Convention on Recognition and Enforcement of Foreign Arbitral Awards of 1958 and has participated and ratified other relevant international conventions and bilateral treaties on arbitration. Following the fall of communism in Romania, the first major new area where the enforceability of foreign arbitration clauses and awards was tested came with the introduction of franchise agreements for large western corporations seeking to set up franchised operations in Romania. Virtually all franchise agreements include arbitration clauses that designate a forum outside of the country in which the franchised business is located for the settlement of any and all disputes related to the franchise relationship. The success of franchisors in Eastern Europe is evidence of such countries’ willingness to enforce arbitration clauses and awards. One leading authority on contracting in Eastern Europe notes “occasionally problems and misunderstandings do occur but the case of commercial arbitration seems to be one of the success stories in [post-communist] Eastern Europe.”6

4.    Doing Business in Romania.

Doing business in Romania is likely simpler and safer than doing business in certain other countries typically used for outsourcing. We reviewed statistics from the Doing Business Project, which is an international data aggregation and quantification service of the World Bank that provides objective measures of business regulations and their enforcement across 183 economies. In 2010 Romania ranked 55th out of 183 countries on the ease of doing business index, whereas India ranked 133rd and China 89th. This index also includes relative rankings for various individual aspects of conducting business in a specific country, including the ease of starting a business, employing workers, paying taxes and enforcing contracts. The report uses data such as the number of days and procedures required to complete a business task such as forming a business or enforcing a contract through the court system and seeks to calculate the average cost of these activities. This information is then compared with similar information for all other countries included in the report. With respect to the ease and cost of enforcing contracts, Romania once again ranked 55th out of 183 countries, whereas India ranked 182nd.

5.    Other Considerations for the Protection of IP.

Several non-legal factors also contribute to how well a company will be able to protect its IP when engaging with outsourced developers. The first of these is employee or contractor turnover within the firm developing the IP. In certain countries where outsourcing is a major industry, such as India, employee turnover rates for development firms are high and it is difficult to control the dissemination of information from one development firm to another as employees move between firms. If outsourcing companies have dedicated teams of employees or contractors and the turnover of such employees and contractors is low, there is less risk that sensitive IP information will be disseminated in a manner that is difficult if not impossible to protect against. The ability to pay wages beyond the market minimum is another consideration for protecting IP developed through outsourcing. If an outsourcing firm is able to pay its developers wages that are above the average for the market area, there is less likelihood that the employees will be hired away by a better paying job or have an incentive to spoil their lucrative working relationship by being lax in the protection of the IP they are developing. Romania’s relatively low per capita income levels and highly educated populace make it an ideal place to recruit and retain talented and efficient developers at a relatively low cost. Finally, outsourcing companies that use employees as opposed to independent contractors will likely have better control and protection over the IP that they develop. This is because the laws of most countries will automatically vest ownership of any IP developed by employees of a company in that company, whereas independent contractors are often only contractually obligated to transfer ownership of any IP they develop to the company for which they are currently working. Because this is a contractual, and not a default legal obligation there can be more opportunities for interpretation and compromise than would exist if a developer was employed by the outsourcing firm.

7. Conclusion.

In conclusion, while outsourcing IP development work to countries outside of the United States requires careful consideration, outsourcing development work to Romania may be preferable to other commonly used outsourcing countries, and Romania’s legal protections for IP should offer sufficient protection and enforcement mechanisms for owners of IP developed by Romanian contractors or employees.




Joa Ebert posted a very interesting blog post about Compiling ActionScript in The Enterprise and I thought it would be interesting to explain what I did a while ago as part of the Anvil Flex Open Source Project to speed up compiling Flex 3 applications.   I should say we, because I had a lot of help from James Ward in building this.  Anvil Flex was desinged somewhat like a portal server and the application was then broken down into smaller sub-applications or "modules" (in the orginizational context and not the flex context).   Each module was designed so the it could be compiled and tested in a stand alone context.  There was also several common libraries that where shared with the entire application

About 6 months into this project compile times for the entire application where exceding 20 minutes and it was nearly impossible to do continuous integration.  One of the main problems with the flex compilers is each part of the compilation process (mxmlc, compc, opimizer, etc.) requires you to start a separate JVM, compile that small part of code and then shutdown the JVM.  Not only does starting and stoping the JVM take time, you also lose all the compilation information when you shut down. 

To solve this problem we build a custom Java compilation program called Taz that called directly into the Flex compiler classes, since the Flex compiler is written in Java.  It consited of the following steps:

1 - We designed a heirarchial build system in Ant that would allow you to build any part of the tree and it's descendets automatically.

2 - The common libraries and modules each had there own Ant build files that described their dependecies.

3 - On building the application we would first walk the tree and build a dependcy heirarchy in memory of what modules and libraries need to be built.

4 - Then as we compiled each library we would cache any pre-processing and loaded libraries that could be reused throughout the compilation process.

The result was compile times dropped from 20 plus minutes to around 4 minutes!    Then for continuous integration builds we set-up multiple builds that would first compile the individual modules and common libraries and then build the entire application.  This would prevent a single module from breaking the build of all the other modules.

A very interesting and logic next step would be to take this process and allow the compilation process on individual developers machines to use the latest libraries built remotely.  For example if a developer was working on module A that depended on module B they could specify to grab latest pre-built module B and any common libraries off a remote machine, like the last known good build from the continuous integration server.  You could also distribute the build across machines this way.

A final note,  a lot of people don't like Ant and say Maven is the build system of the future.  Acutally part of the reason I stop working on Anvil is the entire build process was in Ant and I also thought the trend was to using Maven for builds.  Then on my last project we used Maven extensively and I know believe that Ant actually might be better solution for compiling large and complicated Flex Applications.  One of the reasons I didn't like the Maven build system was a large part of our build process actually used Ant behind the scenes for everything that could not be easily done in Maven.  Yes, Flex Mojos and such can help compile a fairly standard Flex project, but when you project reaches a certain point of complexity that starts to fall apart.  Things such as bundling custom resource files, including special assets in the final build, linking common library files, etc.  it gets complicated really fast! 

I had previously said that the Anvil Flex project was dead, but the code lives on in sourceforge. If there is any interested this build process could be extracted out into a separate, stand alone project.