Localization in SproutCore 1.6

written by Peter Bergstrom

Why Should I Care About Localization and Internationalization?

When developing applications, localization and internationalization are things that are easily overlooked and forgotten until the very end. In the case of smaller applications, they are targeted to only one language, and not having to account for localization or internationalization might work out in the end.

However, especially for larger applications or applications that are targeted to several international markets, planning and implementing an application with localization and internationalization is extremely important. Without proper planning, you can get into a lot of trouble that could have been alleviated with very little upfront effort. The type of planning you’ll need to do is what we’ll go over in this in this post.

Factor in localization early in your development cycle!

As a developer, you should plan for localization and internationalization early in your development cycle, when it is easy to deal with. Once an application grows too large, it is very difficult to add localizable strings.

If you develop without taking into account localization, often text winds up hard coded and, as with any application, these strings are found in a million different places. Having to track down all the non-localized strings after the fact is time consuming and unnecessary if accounted for earlier in the project.

Localizing Your Apps with SproutCore

SproutCore makes it easy to localize your application. Using a strings table for each language, developers can enter key-value pairs. These keys are generic and are referenced throughout the application.

When the application runs, instead of using the actual string in the view, SproutCore looks up the correct localized value from the strings table. This makes it easy not only to localize the application, but also to manage all of the strings in your application because they are all located in one place. If you need to finalize the strings, you can send that off to be finalized without having the stakeholders know any JavaScript.
Continue reading

Optimizing App Performance with SC.Benchmark

written by Peter Bergstrom

SproutCore is a powerful JavaScript framework that allows developers to take full advantage of the code design paradigms used for native applications developed in languages like Cocoa. However, the tools that are available for web development are different and, in most ways, more basic than what is available when writing native applications.

One of the major challenges developing SproutCore applications is measuring the performance of your application. The major web browsers all have built-in profilers that allow developers to examine the overall performance of their application. These profilers allow you to easily track the execution of operations from start to finish, but they do not provide an easy way to optimize specific portions of code.

One of the less known features of SproutCore is SC.Benchmark, a built-in benchmarking tool that developers can, and should, use to optimize their application. There are several ways to report the data captured using SC.Benchmark, including aggregate reports and graphs.

It is very simple to use and can be used anywhere in a SproutCore application. Each benchmark needs a key value. This key value does not need to be unique if you want to get averages for benchmarks over many runs of a code segment. To start the benchmark, you add SC.Benchmark.start("my benchmark key"); to your function. To stop it, you add SC.Benchmark.end("my benchmark key");

Benchmarking Functions and Loops

In the example below, you can see it used inside of a function to capture the execution time for creating a number of SproutCore objects.

createObjects: function(klass, count) {
	SC.Benchmark.start("createObjects");
 
	var objects = [];
	for(var i=0; i<count ; i++) {
		objects.push(klass.create());
	}
 
	SC.Benchmark.end("createObjects");
}

Continue reading

Structuring Large-Scale SproutCore Project Teams

written by Peter Bergstrom

Writing large desktop-like applications in SproutCore comes with a unique set of challenges that you wouldn’t encounter writing a smaller application. A smaller project with one or two contributors is a lot more flexible and requires less planning; a large project with many contributors and moving parts is a completely different beast.

I’ve worked on many SproutCore applications, both large and small, since 2007 and I’ve seen where a project can get into trouble when it grows larger both in scope and in team size. The goal of this post is to share some of my personal experience developing a large SproutCore application.

The Bliss of Smaller Projects

The benefits of smaller projects with one or two developers are relatively obvious. A small team makes it easy to stay on task for the limited scope of the project. Everyone knows what is going on because communication is easy and each developer has the opportunity to wear every hat in the project. Also, the developers working on the project know the code well throughout, mainly because two developers can transfer knowledge and be most effective if they are pair programming.

The Challenge: a Large Application

If you are given the task of creating a larger SproutCore application, such as a calendaring client, one or two developers cannot possibly deliver the application in the required time frame. In some cases, more than 100,000 lines of code may be required, much more than a small group of developers can manage.

In this case, the team must grow to a size where you can meet your timelines while not adding so many people that the project slows down. Since there is so much to do, you need to split up responsibilities; instead of having developers wear all the hats in the project, developers wear one or two hats, and act as the person the rest of the team can trust to deliver their specialized part of the code or functionality.

This is true of working in any large team; the goal of this post is to highlight the particular roles that need to be filled when creating a SproutCore project in particular.
Continue reading