Remove ‘Move to Dropbox’ from the right click context menu on Mac

I feel violated, one o f my favourite apps just changed the way I interact with my operating system without my permission.

Here is what I am talking about: dropboxcontext

Here is how to remove it, start terminal and:

sudo rm -rf /Library/DropboxHelperTools

Continuos Integration (CI) for JavaScript – Jasmine and Teamcity

Web applications are using more JavaScript than ever before.  The following image (thanks to Gineer) shows the shift in the architecture types of web applications from simple thin clients to thicker clients driven by rich presentations and client logic.

Since most of the newer web applications include business logic embedded into the client using JavaScript, we must put assurances to make sure the quality of the application is not compromised over time.

In most cases, the JavaScript side of the applications goes untested or is not automated which is a bad idea.

I have selected the following tools to be able to provide Continuous Integration to Rich Internet Applications:

Jasmine is a testing framework for JavaScript. It is usually used as a red-green tool for developing applications with either TDD or BDD. Jasmin runs on the browser for convenience to check the TDD red-green method but this makes it a bit harder to automate.

Team City is a Continuos Integration server that is extremely popular due to its flexibility to work with a wide variety of projects, it is easy to configure and it works in most environments.

Jasmine Team City Reporter is a reporter type for Jasmine. Jasmine uses a plugin based architecture where it allows different types of reporters to consume and prepare the data. The Jasmine Team City Reporter module allows Jasmine to output the data to the web page console window of the browser that runs Jasmine.

PhantomJS is a headless web-kit browser that allows execution and rendering of web content. We will use it to simulate as if we would be running Jasmine with the Team City Reporter on a website, this way we can automate the whole process.

I built a simple PhatomJS script that consumes the Jasmine Team City Reporter example, it worked great!

JavaScript file to control PhantomJS


console.log('Loading a web page');
var page = new WebPage();
//This was tricky, this is the way to open LOCAL files
var url = "file://localhost/Users/danmerino/test/teamcity_reporter.html";
phantom.viewportSize = {width: 800, height: 600};
//This is required because PhantomJS sandboxes the website and it does not show up the console messages form that page by default
page.onConsoleMessage = function (msg) { console.log(msg); };
//Open the website
page.open(url, function (status) {
    //Page is loaded!
		if (status !== 'success') {
	            console.log('Unable to load the address!');
	        } else {
                 //Using a delay to make sure the JavaScript is executed in the browser
			   window.setTimeout(function () {
					page.render("output.png");
        			phantom.exit();
 		       }, 200);
				}
});

JavaScript tests

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8" />
    <title>Console Reporter Spec</title>

    <link rel="stylesheet" href="../ext/jasmine.css" type="text/css" />

    <script type="text/javascript" src="../ext/jasmine.js"></script>
    <script type="text/javascript" src="../ext/jasmine-html.js"></script>
    <script type="text/javascript" src="../src/jasmine.teamcity_reporter.js"></script>
</head>
<body>
    <script type="text/javascript">
        describe("Basic Suite", function() {
            it("Should pass a basic truthiness test.", function() {
                expect(true).toEqual(true);
            });

            it("Should fail when it hits an inequal statement.", function() {
                expect(1+1).toEqual(3);
            });
        });

        describe("Another Suite", function() {
            it("Should pass this test as well.", function() {
                expect(0).toEqual(0);
            });
        });

        jasmine.getEnv().addReporter(new jasmine.TeamcityReporter());
        jasmine.getEnv().addReporter(new jasmine.TrivialReporter());
        jasmine.getEnv().execute();
    </script>
</body>
</html>

Team City Configuration

Team City Test Results

Common Performance Testing Mistakes

Common Performance Testing Mistakes

At my lab recently we have all been benchmarking our applications. Most of our work has to deal with throughput in distributed applications. A lot of the time I see people making common mistakes when performing tests so I decided to blog about it.

  1. Never test from the same machine, your testing program is taking away significant resources from your application!
  2. Is concurrency being tested (depends on your goals, most likely, YES)
  3. If testing for real world applications, network latency is a HUGE factor in performance and affects applications in many different scenarios, some quick tips are:
    1. Never test using a wireless network unless that is part of your tests!
    2. Make sure you are not hitting your network cap or your packets are being changed by your internet provider
    3. If testing a cloud service, do not test from the same service since there could be no network/connection delay. This can be due to several factors but it could be simply because the test tool might be under the same virtual machine as the application!
    4. If you are using a reverse proxy for spoon feeding, make sure you test with and without it!
  4. Most importantly, calculate performance based on real values instead of approximations. Most of the times approximations are NOT true as they are extrapolated to higher values.

In the web, performance is very important, if you don’t think so, ask Google: http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20.html

Marissa started with a story about a user test they did. They asked a group of Google searchers how many search results they wanted to see. Users asked for more, more than the ten results Google normally shows. More is more, they said.

So, Marissa ran an experiment where Google increased the number of search results to thirty. Traffic and revenue from Google searchers in the experimental group dropped by 20%.

Ouch. Why? Why, when users had asked for this, did they seem to hate it?

After a bit of looking, Marissa explained that they found an uncontrolled variable. The page with 10 results took .4 seconds to generate. The page with 30 results took .9 seconds.

Half a second delay caused a 20% drop in traffic. Half a second delay killed user satisfaction.

All your clients should go on a diet

During the last few months my graduate supervisor and I have been doing a lot of demos to the major canadian telecommunications companies. In the demos we show different devices interacting with each other (which is something people love at demos). One of the things we get asked fairly often is: “How long did it take to build each one of these applications?” and our usual answer is about less than a day. This usually shocks people.

How can this be done? Simple, we use thin clients and the cloud (or some robust and scalable servers).  By having outsourced the client logic to the cloud it is possible to build thin clients.  The thin clients just do a few data calls (or get their data pushed into them) to exchange information.

Of course, this requires extra effort at front when building the server logic but it saves A LOT of work later.

Just as a note, in all cases many client side optimizations should not be overlooked. As an example, client side caching is a good thing when possible.

Don’t copy-and-paste code. Don’t use debug driven development!

Don’t copy-and-paste code. Don’t use debug driven development!

I see a common copy-and-paste trend specially with junior developers. Many of them just copy-and-paste random internet code into their projects. After a while I ask them about their implementation… very few understand what they copy-and-paste and the implications of that implementation!

I inquired further and it was clear that many used debug driven development to get the copy-and-paste code to work. Debug driven development is basically 90% random changes and 10% thinking. This is a popular trend within .NET developers with visual studio because the IDE is amazing…very little planning is required to get things to work.

After a few weeks of seeing this trend I did the following:

If they asked me a question that I believe is due to copy-and-paste or debug driven development I reply with the following questions

  1. Did you google the problem? (some  of them didn’t google the problem!)
  2. Did you copy and paste code? Is that code giving you the error? If you did copy and paste, what does the code do?
  3. What are 2 different approaches to this implementation and why did you choose this implementation?

After answering the questions above, they were able to solve the problems themselves. That makes them happy and it makes me happy!

Value Objects (Immutable objects) in F#

Value Objects (Immutable objects) in F#

Value Objects are objects that can be shared across different parts of a program. This can have great benefits in performance. Because  the objects are shared it is very important for value objects to be immutable. If value objects are not immutable then any part of the program can change the values and all the other parts can do calculation with erroneous data.

One of my goals was to make immutable objects in F# to take advantage of parallelization and automatic compiler optimizations:


type City(Name:string, X: float, Y:float) =

member t.Name = Name

member t.X = X

member t.Y = Y

type NeighborCities(city1:string, city2:string) =

member x.fromCity = city1

member x.toCity = city2

Objects created in this manner in F# are immutable. Even when they are accessed in other projects outside their definition, their members are read-only. This was specially helpful on the distributed traveling salesman problem I built last year.

Quick Overview of F#

F# is very cool. By combining the regular iterative features of the other .NET languages with an Ocaml syntax variant, F# is extremely flexible and powerful.

Here is a simple loop:

 for i in 0..loopSize do

Here is another example for reading in contents from a file, making an object city and returning a list of cities:


let ReadFile (s:string) = match s with
    | null -> raise (ApplicationException "Please provide a non-empty string for the filename!!")
    | s ->
    let cityList = new ResizeArray<CityDef.City>() in
    let rec ReadFile (r:StreamReader) =
        if not r.EndOfStream then
            cityList.Add(ParseCityString(r.ReadLine()))
            ReadFile r
        r.Close()
    let r = new StreamReader(s) in
    ReadFile r
    cityList

F# has powerful features because it has a lot of high order functions on top of the usual map, filter and reduce. The extra high order functions (such as iter, fold, scan, skip, skipWhile, sum, take, takeWhile, truncate, unfold, windowed, zip, zip3, etc.) make it easy to compound complex tasks.

The next example is a little snippet that returns a dictionary distances between cities for a small distributed traveling salesman problem I did last year to test F# on a software engineering class.


let squared x = x*x

let CompareNeighbors = {
    new System.Collections.Generic.IEqualityComparer<CityDef.NeighborCities> with
    member x.Equals(a,b) =  (String.Compare(a.fromCity, b.fromCity) = 0 ) && ( String.Compare(a.toCity, b.toCity) = 0 )
    member x.GetHashCode(a) = a.toCity.GetHashCode() }

let Distance (distanceDic : Dictionary<CityDef.NeighborCities, double>, i: CityDef.City, j: CityDef.City ) =
    let x2 = squared (i.X - j.X)
    let y2 = squared ( i.Y - j.Y)
    let total = sqrt( x2  +  y2)
    let n = new CityDef.NeighborCities(city1 = i.Name, city2 = j.Name)
    distanceDic.Add(n, total)

type DistanceDictionary() =
    interface Infrastructure.IDistanceCalculator with
        member this.DistanceDictionary (genericListOfCities:ResizeArray<CityDef.City>)  =
            let dic = new Dictionary<CityDef.NeighborCities, double>(CompareNeighbors)
            Seq.iter(fun z -> Seq.iter(fun x->Distance(dic, z, x)) genericListOfCities) genericListOfCities
            dic

Also it is nice being able to use interfaces with F# in the simple format of “interface Infrastructure.IDistanceCalculator with”.

As a little tip, for applying something to a list that does not require a new collection, it is important to avoid using the higher order function map. Map should only be used if a new list with a different set of values is expected because it creates a new list. In this case, map was not necessary and iter was the choice.