Skip navigation
Help

web programming

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.

  

Many of us care deeply about developing our craft. But staying up to date can be a true challenge, because the quantity of fresh information we’re regularly exposed to can be a lot to take in. 2012 has been no exception, with a wealth of evolution and refinement going on in the front end.

Great strides have been made in how we approach workflow, use abstractions, appreciate code quality and tackle the measurement and betterment of performance. If you’ve been busy and haven’t had time to catch up on the latest developments in these areas, don’t worry.

With the holiday season upon us and a little more time on our hands, I thought it would be useful to share a carefully curated list of the most relevant front-end talks I’ve found helpful this year. You certainly don’t have to read through them all, but the advice shared in them will equip you with the knowledge needed to go into the new year as a better front-end engineer.

Screenshot
Image credit: Jacob Bøtter

Baseline

Have a Strategy for Staying Up to Date

How to Stay Up to Date on Web Stuff, Chris Coyier

Part of continually developing your craft is staying up to date. Doing this is important for all professionals, and in this talk you’ll learn strategies for staying updated even when the ideas that surround the technologies we use are constantly evolving.

Screenshot

Make Sure Your Baseline for Development Is Current

A New Baseline for Front-End Developers, Rebecca Murphey

There was a time when editing files, testing them locally and simply FTP’ing them was the common workflow for a front-end developer. We would measure our abilities based on how well we could harass IE 6 into rendering pages correctly, and we generally lacked strong skills in HTML, CSS and JavaScript.

This has greatly changed over the past few years, with improvements in workflow and tooling. Front-end development is now taken more seriously, and this talk sheds light on the new baseline process for developing on the front end.

Screenshot

Understand How Browsers Work Behind the Scenes

So, You Want to Be a Front-End Engineer, David Mosher (Video)

Some would say that the browser is the most volatile development platform the world has ever known. If you’re a client-side developer, understanding how browser internals work can help you both make better decisions and appreciate the justifications behind many development best practices. In one of the best talks this year, David Mosher takes you through how browsers parse and render your pages.

Screenshot

Know What the Web Platform Now Has to Offer

The Web Can Do That!?, Eric Bidelman (Video)

The Web is constantly evolving, and keeping up with what’s new on the platform can be hard. HTML5’s new capabilities enable us to build an entirely new suite of applications with features that were simply impossible to achieve before (at least, not without the use of plugins) but are now a reality.

In this talk, my teammate Eric guides you through the bleeding edge of HTML5, focusing on solving many real-world problems. You’ll learn about media streaming, device input, modern CSS design, media capture, file I/O and more.

Screenshot

Workflow

For Web App Developers

Tooling for the Modern Web App Developer, Addy Osmani

Whether you’re using JavaScript or CoffeeScript, LESS or Sass, building an awesome Web application these days usually requires a plethora of boilerplates, frameworks and tools and a lot of glue to get them to work together. In short, you need a kick-ass utility belt.

In this talk, you’ll get an overview of the current tooling eco-system for the front-end and learn about a new tool that tries to bring together all of the pieces of this eco-system for you, called Yeoman.

Screenshot

An extended version of this talk is also available.

For Web Designers

A Modern Web Designer’s Workflow, Chris Coyier (Video)

A lot is expected from today’s Web designers. If this role defines what you do, then it’s now not just about visual design, but increasingly about building interactions. Designs need to work across different devices of varying shapes, sizes and connections, and they also need to be accessible.

As a designer, you often need to communicate and share code across teams and be familiar with many different technologies. In this talk, Chris Coyier discusses many of the amazing tools that can help things along, discussing what does what and giving a high-level view of a modern workflow.

Screenshot

For Mobile Web Developers

Mobile Web Developers Toolbelt, Pete Le Page (Video)

Building for the mobile Web requires a different mindset to the one we use when developing for desktop, and a different set of tools. Thankfully, a number of great options are available. From remote debugging to emulation, mobile browsers are offering more and more tools to make our lives easier.

In this talk, Pete Le Page takes you through a couple of tools that you can use today to make cross-platform mobile Web development easier, and then he peers into the crystal ball to see what tools the future may bring.

Screenshot

For Debugging

Secrets of the Chrome DevTools, Patrick Dubroy (Video)

Google Chrome Developer Tools provide powerful ways to understand, debug and profile Web applications. Most developers are familiar with Chrome’s basic inspection and debugging tools, but some of its most valuable features, like the Timeline and memory analysis tools, are less known.

In his demo-based walkthrough, Patrick Dubroy provides an overview of Chrome Developer Tools and an in-depth demonstration of some lesser-known features.

Screenshot

The Future

CSS

The CSS of Tomorrow, Peter Gasston

In this talk, Peter looks briefly at the state of CSS3: what you can do right now, and what you’ll be able to do in the very near future. He then looks into the long-term future, to a time when CSS3 will make possible page layouts far richer and more dynamic than we’d thought possible, and when CSS3 has taken on aspects of programming languages. This is effectively what CSS developers will be learning years from now.

Screenshot

JavaScript

The Future of JavaScript, Dave Herman

The Web platform is growing, and JavaScript is growing along with it. EcmaScript 6, the next edition of the JavaScript standard, is gearing up to be a huge step forward for Web programming. In this talk, Dave Herman discusses the exciting new features being worked on for EcmaScript 6 and how they can be used.

Screenshot

Web Applications

Web Components and the Future of Web App Development, Eric Bidelman

Web components are going to fundamentally change the way we think, build and consume Web apps. ShadowDOM, Mutation Observers, custom elements, MDV, Object.observe(), CSS — how do they all fit together?

This talk prepares you for the future of the Web platform by discussing the fundamentals of Web components and how we can use them today with frameworks such as AngularJS.

Screenshot

CSS

State of the Art

All the New CSS Hawtness, Darcy Clarke

This talk dives into some of the latest CSS implementations and specifications floating around. You’ll learn what’s here and what’s around the corner, and you’ll gain insight into why these new features will change our development workflow.

Darcy Clarke touches on modules such as paged-media, multi-columns, flex-box, filters, regions, box-sizing, masking and 3D.

Screenshot

Modularity

Your CSS Is a Mess, Jonathan Snook

We all think that CSS is easy. Take some selectors, add some properties, maybe a dash of media queries, and — presto! — you have a beautiful website. And yet, as the project changes and the team grows, we see the frustration build, with increasingly complex selectors and overuse of !important.

In this talk, Jonathan looks at common problems and solutions that will make your CSS (and your projects) easier to manage and easier to scale.

Screenshot

Pre-Processors

CSS Pre-Processors, Bermon Painter

If you haven’t jumped on the pre-processor train this year, you’re missing out. In this helpful overview of (current) popular pre-processors, Bermon Painter takes you through Stylus, LESS and Sass, with features subdivided into easy-to-learn sections of beginner, intermediate and advanced. I’ve been using mixins quite heavily this year, and I simply wouldn’t have been able to if it weren’t for projects like Sass.

Screenshot

Documentation

A Better Future With KSS, Kyle Neath

Writing maintainable CSS within a team is one of those problems that a lot of people think can be solved by writing CSS in a particular style. But in Kyle’s experience, that never works out.

In this talk, he introduces you to his latest creation, KSS. It’s a documentation and style guide format. He’ll show you why he built KSS and how it’s been helping him at GitHub to refactor its four-and-a-half year old CSS, and he’ll give you a glimpse into the future of KSS.

Screenshot

JavaScript

The Importance of Code Style

Maintainable JavaScript, Nicholas Zakas

Some say that good code is its own documentation, and the fact is that the more readable our code is, the easier it is to maintain.

Writing JavaScript for fun and writing it professionally are two different things, and in this talk by Zakas, you’ll learn practices to make JavaScript maintainable over the long run, to reduce errors and to make your code easily adaptable to future changes. It’s highly recommended reading.

Screenshot

A Modern Large-Scale App Stack

SoundCloud’s Stack, Nick Fisher

I’ve talked a lot about large-scale development in the past. It’s a non-trivial problem that’s difficult to get right, and so it’s exciting when someone working on such challenges shares their experience.

In this talk, Nick Fisher of SoundCloud discusses the company’s story of developing large-scale applications with JavaScript, not only at runtime, but also its steps to make development and deployment easier. In particular, he looks at RequireJS and Backbone, talking about how SoundCloud has used and abused each to suit its needs, sometimes in uncommon ways.

Screenshot

Rethinking Application Structure

Re-Imagining the Browser With AngularJS, Igor Minar

What if you could a write modern Web app with dramatically fewer lines of code and improve its readability and expressiveness at the same time? In case you’re wondering: no, there’s no new language to learn, just familiar old HTML and JavaScript. As a matter of fact, there are concepts for you to unlearn.

AngularJS is a client-side JavaScript Web development framework whose authors believe they’ve done something special. Instead of asking what kind of functions they could provide to make writing apps smoother, they asked, “What if the browser worked differently in a way that eliminates code and gives structure to apps?”

In this talk, you’ll get a tour of how to get the power of tomorrow’s Web platform in today’s Web applications.

Screenshot

Internationalization and i18n

Entschuldigen you, parlez vouz JavaScript, Sebastian Golasch (Video)

While JavaScript applications grow in size and complexity, there are still some white spots on the big map of Web applications: internationalization and globalization! If you´re still thinking that switching strings in and out is the way to go, you are definitely headed in the wrong direction.

In this talk, Sebastian takes you through how to spot real-world internationalization problems and how to solve them in the most elegant way.

Screenshot

I couldn’t cover internationalization without mentioning Alex Sexton, who has also spoken a great deal on this topic. His JSConf talk on client-side internationalization is available in video form if you’re interested in checking it out.

Patterns and Principles

The Plight of Pinocchio, Brandon Keepers

JavaScript is no longer a toy language, and many of our Web applications can’t function without it. Brandon states that if we are going to use JavaScript to do real things, then we need to treat it like a real language, adopting the same practices that we use with real languages. I completely agree with him.

This framework-agnostic talk takes a serious look at how we develop JavaScript applications in the real world. Despite their prototypical nature, good object-oriented programming principles are still relevant. The design patterns that we’ve grown to know and love work just as well in JavaScript as they do in any other language.

Screenshot

When to Lazy Load Scripts

How Late Is Later?, Massimiliano Marcon

Reducing the loading time of a Web application is a well-known challenge. Developers need to make sure that the browser downloads only the code that is strictly necessary to bootstrap the application, and leave the rest for later. This is what we commonly call “lazy loading.”

But when is “later”? When is the right time to lazy load? This talk shows how JavaScript code — functions and objects — can be delivered to the browser on demand, thus reducing the perceived loading time of a Web application.

Screenshot

Mobile

Building Touch-Based Interfaces

Creating Responsive HTML5 Touch Interfaces, Stephen Woods (Video | Audio)

Flickr front-end engineer Stephen Woods shares some hard-learned lessons about building responsive touch-based interfaces using HTML5 and CSS. Because our users are demanding better instant feedback from touch-based UIs, understanding how to approach this problem and avoid the pitfalls will be critical for many application developers in the future.

Screenshot

The Challenge With Scrolling

Embracing Touch: Cross-Platform Scrolling, Mark Dalgleish (Video)

Scrolling effects are a popular way to add personality to the simple act of moving down the page. Unfortunately, these effects don’t work natively on mobile devices, where the touch interaction would make these techniques more effective. In this talk, Mark looks at some ways to implement these effects within the limitations of mobile browsers.

Screenshot

Native, HTML5 and Hybrid Apps

Native, HTML5 and Hybrid Mobile Development, Eran Zinman

One of the toughest decisions every mobile developer faces is choosing a development strategy: “Should I develop a native, HTML5 or hybrid mobile app?” Over the past two years, Eran has led Conduit’s mobile client development efforts, experimenting with cross-platform development in various flavors: from complete HTML5 solutions (using PhoneGap and other technologies) to hybrid solutions to semi-hybrid solutions to fully native solutions.

In this talk, Eran shares some real-life experiences in cross-platform development, describing changes that Conduit has implemented along the way, and sharing what some of the “big players” (such as Facebook, LinkedIn and Twitter) are doing in their mobile app development.

Screenshot

Performance, Distribution and Facebook on HTML5

On the Future of Mobile Web Apps, Simon Cross

Simon looks at Facebook’s experience with and investment in the mobile Web, the issues affecting mobile Web developers and what Facebook and the industry are doing to push the mobile Web forward. Mark Zuckerberg’s comments on HTML5 were undoubtedly one of the most discussed topics in mobile this year, and I personally found these slides a good summary of Facebook’s current take on what works and what still requires improvement.

Screenshot

Tools for Mobile Debugging

Mobile Debugging, Remy Sharp

Debugging Web apps on mobile devices can be a genuine pain. Luckily, a number of tools are available today to ease the process. From remote debuggers to cross-device consoles, this talk summarizes the current state of debugging for mobile, going into more depth on debugging than Pete’s talk from earlier in the post.

Screenshot

Responsive Design Techniques

Responsive Web Design: Clever Tips and Techniques, Vitaly Friedman

Responsive Web design challenges designers to apply a new mindset to their design processes and to the techniques they use in design and coding. This talk (by Smashing Magazine’s own Vitaly Friedman) provides an overview of various practical techniques, tips and tricks that you might want to be aware of when working on a new responsive design project.

Screenshot

Web Apps

Offline Web Apps

Offline Rules, Andrew Betts (Video)

In the last couple of years, a deluge of new offline storage technologies have appeared. In this talk, Andrew looks at why they are all excellent and rubbish at the same time and why you need to use all of them, and he walks through techniques to consider when building a Web application that can load and function with no network connectivity.

But making use of client-side storage is necessary not only in order to make an app that works offline, but it can also hugely improve the experience of your website when the user actually does have connectivity.

Screenshot

State of the Art

Building Web Apps of the Future: Tomorrow, Today and Yesterday, Paul Kinlan (Audio)

The browser is an amazing runtime that can already deliver amazing apps. Paul dives into the technologies that will help you deliver Web apps that will blow your users’ socks off now and in the future.

Screenshot

Client-Side Storage

Storage in the Browser, Andrew Betts

Installed native applications can use all the space they want, but in the browser we’re much more limited. This talk explores how to make the best use of the storage technologies available to Web apps, comparing the virtues of different packaging and encoding techniques, and covering simple forms of in-browser compression that can yield surprising results.

As more apps are developed to surf over network turbulence, and to work even when completely disconnected from the network, local storage becomes ever more important.

Screenshot

Application Cache

Application Cache: Douchebag, Jake Archibald (Video)

The Application Cache is one of the cool bits of HTML5. It allows websites to work without a network connection, and it brings us much closer to native app-like behavior. However, from roundup articles and talks about HTML5, you might be left with the impression that it’s a magic bullet. Unfortunately, it isn’t; the Application Cache is, as Jake famously puts it, a douchebag.

In this talk, he looks at how to use the features of Application Cache without the horrible side effects, comparing techniques that you’d use for both a simple client-side app and a large content-driven website. He explores the many gotchas left out of most articles about Application Cache and discusses how to build your website to survive them.

Screenshot

Performance

CSS

High-Performance CSS, Paul Irish

Paul dives into the tools available in and outside of the browser to assess the performance of your CSS. Find out what’s slow (is box-shadow causing paints to be 70 milliseconds longer?) and how to fix it. Learn about about:tracing, CSS profiling and speed tracer, and get a better understanding of the browser’s internals in the process.

Screenshot

There’s also Jon Rohan’s talk about some problems related to CSS performance that were solved at GitHub. Recommended reading.

GitHub’s CSS Performance, Jon Rohan

Screenshot

Avoiding Jank

Jank-Free: In Pursuit of Smooth Web Apps, Tom Wiltzius

Building beautiful experiences on the mobile Web takes more than a good designer and fancy CSS: performance is critical for a Web app to feel fluid. Smooth animation that never drops a frame can give your app a native feel. But when animations stutter, effects lag or pages scroll slowly, we call that “jank.” This talk is about identifying jank and getting rid of it.

Screenshot

Web

Building Faster Websites, Ilya Grigorik

In this comprehensive crash course, Ilya Grigorik shares some really juicy tips on how to make the Web faster, including Google’s findings on what slows down people’s Web experience and how Chrome and other services have improved it. If you’re an engineer looking to improve the performance of your websites or apps, this talk comes highly recommended.

Screenshot

JavaScript

Breaking the JavaScript Speed Limit With V8, Daniel Clifford

Are you interested in making JavaScript run blazingly fast? If so, this talk looks at V8 under the hood to help you identify how to optimize your JavaScript. Daniel shows you how to leverage V8’s sampling profiler to eliminate performance bottlenecks and optimize JavaScript programs. He also exposes how V8 uses hidden classes and runtime-type feedback to generate efficient JIT code. A very interesting talk for performance junkies.

Screenshot

Note: Some of the optimizations mentioned in this talk are specific to V8 and may not apply to other JavaScript engines. I wrote about how to write memory-efficient JavaScript on Smashing Magazine recently, in case you’re interested in exploring the topic further.

Testing

Understanding Code Smells

Why Our Code Smells, Brandon Keepers (Video)

Odors exist for a reason, and they are usually trying to tell us something. If our code smells, it might be trying to tell us what is wrong.

Does a test case require an abundance of setting up? Maybe the code being tested is doing too much, or it is not isolated enough for the test? Does an object have an abundance of instance variables? Maybe it should be split into multiple objects? Is a view brittle? Maybe it is too tightly coupled to a model, or maybe the logic needs to be abstracted into an object that can be tested?

In this talk, Brandon walks through code from projects that he works on every day, looking for smells that indicate problems, understanding why the smells are there, what the smells are trying to tell us, and how to refactor them.

Screenshot

Current State of the Art

JavaScript Testing: The Holy Grail, Adam Hawkins (Video)

Adam talks about this Holy Grail for JavaScript developers: getting a test suite up and running fast and having multiple browsers execute the tests. Getting the Holy Grail is difficult, though, even though several tools have been created in the past in attempts to solve this problem.

Barriers to entries are everywhere. How easy is it to get going testing small parts of JavaScript functionality? What happens as your become bigger and more complex? What about headless testing? Does this process scale up to CI? Can you even do this stuff locally?

A myriad of testing tools and solutions are available, and Adam shows what’s out there and what we as a community need to do next to get the Holy Grail, to ensure a better Web experience for everyone.

Screenshot

Tip: One tool for testing that I’m loving at the moment is Testling-CI, which runs browser tests on every push.

Improving the Testability of Your Code

Writing Testable JavaScript, Rebecca Murphey (Audio)

It’s one thing to write the code that you need to write to get something working; quite another to write the code that you need to write to prove that it works — and to prove that it will continue to work as you refactor and add new features.

In her talk, Rebecca looks at what it means to write testable JavaScript code.

Screenshot

Conclusion

Time spent thinking about (and developing) your craft is time well spent. The more honed your skills are, the more opportunity you will have to become an efficient engineer.

While this list doesn’t cover every excellent talk presented this year, it hopefully offers some direction for you to accentuate your skills. Do consider reading through a few of them. Focused reading in this way will add to your value as a craftsperson and hopefully improve your daily development workflow.

With that, do enjoy the holiday season and have a fantastic new year.

(al)

© Addy Osmani for Smashing Magazine, 2012.

0
Your rating: None

  

You’ve presented the new website and everyone loves it. The design is crisp, the code is bug-free, and you’re ready to release. Then someone asks, “Does it work in Japanese?”

You break out in a cold sweat: you have no idea. The website works in English, and you figured other languages would come later. Now you have to rework the whole app to support other languages. Your release date slips, and you spend the next two months fixing bugs, only to find that you’ve missed half of them.

Localization makes your application ready to work in any language — and it’s much easier if you do it from the beginning. Just follow these 12 simple rules and you’ll be ready to run anywhere in the world.

1. “Resource” All Of Your Strings

The first step of localization is to get user-visible strings out of your code and into resource files. Those strings include titles, product names, error messages, strings in images and any other text the user might see.

Most resource files work by giving each string a name and allowing you to specify different translation values for that string. Many languages use properties files like this:

name = Username

Or they use .pot files like this:

msgid "Username"
msgstr "Nom d'utilisateur"

Or they use XLIFF files like this:

<trans-unit id="1">
 <source xml:lang="en">Username</source>
 <target xml:lang="fr">Nom d'utilisateur</target>
</trans-unit>

The resource files are then loaded by a library that uses a combination of the language and country, known as the locale, to identify the right string.

Once you’ve placed your strings in external resource files, you can send the files to translators and get back translated files for each locale that your application supports.

2. Never Concatenate Strings

Appending one string to another almost always results in a localization bug. It’s easy to see this with modifiers such as color.

Suppose your stationery store has items such as pencils, pens and sheets of paper. Shoppers will choose what they want and then select a color. In the shopping cart you would show them items such as a red pencil or a blue pen with a function like this:

function getDescription() {
    var color = getColor();
    var item = getItem();

    return color + " " + item;
}

This code works well in English, in which the color comes first, but it breaks in French, in which “red pencil” translates as “crayon rouge” and “blue pen” is “stylo – encre bleue.” French speakers (but not only them) put modifiers after the words they modify. The getDescription function would never be able to support languages like this with simple string concatenation.

The solution is to specify parametrized strings that change the order of the item and color for each language. Define a resourced string that looks like this:

itemDescription = {0} {1}

It might not look like much, but this string makes the translation possible. We can use it in a new getDescription function, like this:

function getDescription() {
    var color = getColor();
    var item = getItem();

    return getLocalizedString('itemDescription', color, item);
}

Now, your translators can easily switch the order, like this:

itemDescription = {1} {0}

The getLocalizedString function here takes the name of a resource string (itemDescription) and some additional parameters (color and item) to substitute for placeholders in the resource string. Most programming languages provide a function similar to getLocalizedString. (The one notable exception is JavaScript, but we’ll talk more about that later.)

This method also works for strings with text in them, like:

invalidUser = The username {0} is already taken. Please choose another one.

3. Put All Of Your Punctuation In The Resourced String

Tacking on punctuation later is often tempting, so that you can reuse the same string, say, in a label where it needs a colon and in a tooltip where it doesn’t. But this is another example of bad string concatenation.

Here, we’re adding a simple log-in form using PHP in a WordPress environment:

<form>
<p>Username: <input type="text" name="username"></p>
<p>Password: <input type="text" name="password"></p>
</form>

We want the form to work in other languages, so let’s add the strings for localization. WordPress makes this easy with the __ function (i.e. underscore underscore):

<form>
<p><?php echo(__('Username', 'my-plugin') ?>: <input type="text" name="username"></p>
<p><?php echo(__('Password', 'my-plugin') ?>: <input type="text" name="password"></p>
</form>

Spot the bug? This is another case of string concatenation. The colon after the labels isn’t localized. This will look wrong in languages such as French and Russian, which always put spaces around colons. Punctuation is part of the string and belongs in the resource file.

<form>
<p><?php echo(__('Username:', 'my-plugin') ?> <input type="text" name="username"></p>
<p><?php echo(__('Password:', 'my-plugin') ?> <input type="text" name="password"></p>
</form>

Now the form can use Username: in English and Nom d'utilisateur : in French.

4. “First” Names Sometimes Aren’t

My name is Zack Grossbart. Zack is my given (or first) name, and Grossbart is my last (or family) name. Everyone in my family is named Grossbart, but I’m the only Zack.

In English-speaking countries, the first name is the given name and the last name is the family name. Most Asian countries go the other way, and some cultures have only one name.

The cellist Yo-Yo Ma is a member of the Ma family. In Chinese, he writes his family name first: Ma Yo-Yo (馬友友).

This gets tricky because many people change their names when moving from Asian countries to English-speaking ones. They often switch the order to fit local customs, so you can’t make any assumptions.

You must provide a way to customize the presentation of names; you can’t assume that the first name always comes first or that the last name always comes last.

WordPress handles this pretty well by asking you how you want your name to show up:

Name formatting in WordPress

It would be even better if WordPress supported a middle name and a way to specify the format per locale so that you could make your name one way in English and another in Chinese, but nothing’s perfect.

5. Never Hard-Code Date, Time Or Currency Formats

The whole world is inconsistent about date and time formats. Some people put the month first (6/21/2012), others the day first (21/6/2012). Some use 24-hour (14:00) time, and some use 12 (2:00 PM). Taiwan uses specially translated strings instead of AM and PM, and those come first (上午 2:00).

Your best bet is to store all dates and times in a standard format such as ISO time or epoch time, and to use a library like Date.js or Moment.js to format them for the given locale. These libraries can also handle converting the time to the current zone, so you can store all dates and times in a common format on the server (such as UTC) and convert them to the right time zone in the browser.

Dates and times are also tricky when displaying calendars and date pickers. Estonia starts the week on Saturday, the US starts on Sunday, the UK on Monday and the Maldives on Friday. The jQuery UI date picker includes over 50 localized files to support different calendar formats around the world.

The same is true of currencies and other number formats. Some countries use commas to separate numbers, and others use periods. Always use a library with localized files for each of the locales that you need to support.

StackOverflow covers this topic well when discussing daylight savings time and time zone best practices.

6. Use UTF-8 Almost All Of The Time

The history of computer character encodings is a long one, but the most important thing to remember is that UTF-8 is the right choice 99% of the time. The only time not to use UTF-8 is when you’re working primarily with Asian languages and absolutely need the efficiency of UTF-16.

This comes up a lot with Web applications. If the browser and the server don’t use the same character encoding, then the characters will get corrupted and your application will fill up with little squares and question marks.

Many programming languages store files using the system’s default encoding, but it won’t matter that your server is English when all of your users are browsing in Chinese. UTF-8 fixes that by standardizing the encodings across the browser and the server.

Invoke UTF-8 at the top of all of your HTML pages:

<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

And specify UTF-8 in the HTTP Content-Type header, like this:

Content-Type: text/html; charset=utf-8

The JSON specification requires that all JSON documents use Unicode with a default of UTF-8, so make sure to use UTF-8 whenever you’re reading or writing data.

7. Give Strings Room To Grow And Shrink

Strings change size in translation.

Repeat password example

“Repeat password” is over 50% wider in German than in English; if there isn’t enough space, then your strings will overlap other controls. WordPress solves this problem by leaving extra space after each label for the string to grow.

Label spacing in the WordPress admin

This works well for languages whose strings are roughly of the same length, but for languages with long words, such as German and Finnish, the controls will overlap if you don’t leave enough space. You could add more space, but that would put the labels and controls pretty far apart from each other in compact languages such as Chinese, thus making them hard to use.

Label spacing in the WordPress admin in Chinese

Many designers of forms give their labels room to grow and shrink by aligning them to the right or by placing them above the controls.

Label above controls in the WordPress admin

Putting labels above the controls works well for a short form, but it makes a form with a lot of fields very tall.

There’s no perfect answer for how to make your application work in all languages; many form designers mix and match these approaches. Short labels like “User name” and “Role” won’t change much in translation and need just a little extra space. Longer paragraphs will change substantially and need room to grow wider, taller or sometimes both.

Label next to and above controls in the WordPress admin

Here, WordPress gives a little extra space for the “Biographical Info” label, but it puts the longer description below the field so that it can grow in translation.

8. Always Use A Full Locale

The full locale includes the language and country code, and it supports alternate spellings, date formats and other differences between two countries with a shared language.

Always use a full locale instead of just a language when translating, so that you know whether you’re doing someone a favor or a favour, and that they know whether to take the elevator or the lift, and that they know whether £100.00 is expensive.

9. Never Trust The Browser To Know The Right Locale

Localization is much more difficult with browsers and JavaScript because they give a different locale depending on who’s asking.

JavaScript has a property to tell you the current language, named navigator.userLanguage. All browsers support it, but it’s generally useless.

If I install Firefox in English, then my navigator.userLanguage value would say English. I can then go into my preferences and change my preferred languages. Firefox lets me select multiple languages, so I could specify my order of preference as English from the US, then any other English, then Japanese.

Language preferences in Firefox

Specifying a set of locales makes it possible for servers to find the best match between the languages that I know they support. Firefox takes these locales and sends them to the server in an HTTP header, like this:

Accept   en-us,en;q=0.7,ja;q=0.3

Firefox even uses the quality factor (that q= part) to indicate how much I prefer one locale over another.

This means that the server might return content in English or Japanese or another language if it doesn’t support either. However, even after I’ve set my preferred language in Firefox, the value of my navigator.userLanguage property will still be English and only English. The other browsers don’t do much better. This means that I might end up with the server thinking I want Japanese and with the JavaScript thinking I want English.

JavaScript has never solved this problem, and it has not one standard localization library, but dozens of different standards. The best solution is to embed a JavaScript property or some other field in your page that indicates the locale when the server processes each request. Then you can use that locale when formatting any strings, dates or numbers from JavaScript.

10. Plan For Languages That Read Left To Right And Right To Left

Most languages are written on screen from left to right, but Arabic, Hebrew and plenty of others go from right to left. HTML provides a property for the html element named dir that indicates whether the page is ltr (left to right) or rtl (right to left).

<html dir="rtl">

There’s also a direction property in CSS:

input {
    direction: rtl;
}

Setting the direction property will make the page work for the standard HTML tags, but it can’t switch a CSS element with float: left to float: right or change an absolutely positioned layout. To make more complex layouts work, you will need a new style sheet.

An easy way to determine the direction of the current language is to include a direction string in the resourced strings.

direction = rtl

Then you can use that string to load a different style sheet based on the current locale.

11. Never Sort In The Browser

JavaScript provides a sort function that arranges lists of strings alphabetically. It works by comparing each character in each string to determine whether a is greater than b or y is less than z. That’s why it makes 40 come before 5.

The browser knows that y comes before z by using a large mapping table for each character. However, the browser includes the mapping tables only in the current locale. This means that if you have a list of Japanese names, the browser wouldn’t be able to sort them properly in an English locale; it would just sort them by Unicode value, which isn’t correct.

This problem is easy to see in languages such as Polish and Vietnamese, which frequently use diacritical marks. The browser can tell that a comes before b, but it doesn’t know whether comes before ã.

The only place to sort strings properly is on the server. Make sure that the server has all of the code mappings for the languages you support, and that you send lists to the browser presorted, and that you call the server whenever you want to change the sorting. Also, make sure that the server takes locale into account for sorting, including right-to-left locales.

12. Test Early And Often

Most teams don’t worry about localization until it’s too late. A big customer in Asia will complain that the website doesn’t work, and everyone will scramble to fix 100 little localization bugs that they had never thought of. Following the rules in this article will avoid many of those problems, but you will still need to test; and translations usually aren’t ready until the end of the project.

I used to translate my projects into Pig Latin, but that didn’t test Asian characters, and most browsers don’t support it. Now I create test translations with Xhosa (xh_ZA). All browsers support Xhosa, and Nelson Mandela speaks it natively, but I’ve never been asked to support it in a product.

I don’t speak Xhosa, so I create a new translation file and add xh to the beginning and end of every string. The xh makes it easy to see whether I’ve missed a string in the code. Throw in a few Japanese Kanji characters to test character encoding, and I have a messy string that tests for all of my translation issues.

Making the test translation file is easy. Just save a new properties file with xh_ZA in the file name and turn…

name = Username

… into:

name = xh吳清源Username吳清源xh

The resulting jumble will test that I’ve resourced every string, that I’m using the right locale, that my forms work with longer strings and that I’m using the right character set. Then I’ll just quickly scan the application for anything without the xh and fix the bugs before they become urgent issues.

Do the right thing for localization ahead of time, and you’ll save yourself a lot of trouble in the long run.

(al) (km)

© Zack Grossbart for Smashing Magazine, 2012.

0
Your rating: None

Look at this incredible thing Ian Baker created. Look at it!

The PHP hammer

What you're seeing is not Photoshopped. This is an actual photo of a real world, honest to God double-clawed hammer. Such a thing exists. Isn't that amazing? And also, perhaps, a little disturbing?

That wondrous hammer is a delightful real-world acknowledgement of the epic blog entry PHP: A Fractal of Bad Design.

I can’t even say what’s wrong with PHP, because – okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.

You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.

You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.

You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.

And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.

Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.

That’s what’s wrong with PHP.

Remember the immediate visceral reaction you had to the double-clawed hammer? That's exactly the reaction most sane programmers have to their first encounter with the web programming language PHP.

This has been going on for years. I published my contribution to the genre in 2008 with PHP Sucks, But It Doesn't Matter.

I'm no language elitist, but language design is hard. There's a reason that some of the most famous computer scientists in the world are also language designers. And it's a crying shame none of them ever had the opportunity to work on PHP. From what I've seen of it, PHP isn't so much a language as a random collection of arbitrary stuff, a virtual explosion at the keyword and function factory. Bear in mind this is coming from a guy who was weaned on BASIC, a language that gets about as much respect as Rodney Dangerfield. So I am not unfamiliar with the genre.

Except now it's 2012, and fellow programmers are still writing long screeds bemoaning the awfulness of PHP!

What's depressing is not that PHP is horribly designed. Does anyone even dispute that PHP is the worst designed mainstream "language" to blight our craft in decades? What's truly depressing is that so little has changed. Just one year ago, legendary hacker Jamie Zawinski had this to say about PHP:

I used to think that PHP was the biggest, stinkiest dump that the computer industry had taken on my life in a decade. Then I started needing to do things that could only be accomplished in AppleScript.

Is PHP so broken as to be unworkable? No. Clearly not. The great crime of PHP is its utter banality. Its continued propularity is living proof that quality is irrelevant; cheap and popular and everywhere always wins. PHP is the Nickelback of programming languages. And, yes, out of frustration with the status quo I may have recently referred to Rasmus Lerdorf, the father of PHP, as history's greatest monster. I've told myself a million times to stop exaggerating.

The hammer metaphor is apt, because at its core, this is about proper tooling. As presciently noted by Alex Papadimoulis:

A client has asked me to build and install a custom shelving system. I'm at the point where I need to nail it, but I'm not sure what to use to pound the nails in. Should I use an old shoe or a glass bottle?

How would you answer the question?

  1. It depends. If you are looking to pound a small (20lb) nail in something like drywall, you'll find it much easier to use the bottle, especially if the shoe is dirty. However, if you are trying to drive a heavy nail into some wood, go with the shoe: the bottle will shatter in your hand.
  2. There is something fundamentally wrong with the way you are building; you need to use real tools. Yes, it may involve a trip to the toolbox (or even to the hardware store), but doing it the right way is going to save a lot of time, money, and aggravation through the lifecycle of your product. You need to stop building things for money until you understand the basics of construction.

What we ought to be talking about is not how terrible PHP is – although its continued terribleness is a particularly damning indictment – but how we programmers can culturally displace a deeply flawed tool with a better one. How do we encourage new programmers to avoid picking up the double clawed hammer in favor of, well, a regular hammer?

This is not an abstract, academic concern to me. I'm starting a new open source web project with the goal of making the code as freely and easily runnable to the world as possible. Despite the serious problems with PHP, I was forced to consider it. If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option. If that doesn't scare you, then check your pulse, because you might be dead.

Everything goes with PHP sauce! Including crushing depression.

Therefore, I'd like to submit a humble suggestion to my fellow programmers. The next time you feel the urge to write Yet Another Epic Critique of PHP, consider that:

  1. We get it already. PHP is horrible, but it's used everywhere. Guess what? It was just as horrible in 2008. And 2005. And 2002. There's a pattern here, but it's subtle. You have to look very closely to see it. On second thought, never mind. You're probably not smart enough to figure it out.
  2. The best way to combat something as pervasively and institutionally awful as PHP is not to point out all its (many, many, many) faults, but to build compelling alternatives and make sure these alternatives are equally pervasive, as easy to set up and use as possible.

We've got a long way to go. One of the explicit goals of my next project is to do whatever we can to buff up a … particular … open source language ecosystem such that it can truly compete with PHP in ease of installation and deployment.

From my perspective, the point of all these "PHP is broken" rants is not just to complain, but to help educate and potentially warn off new coders starting new codebases. Some fine, even historic work has been done in PHP despite the madness, unquestionably. But now we need to work together to fix what is broken. The best way to fix the PHP problem at this point is to make the alternatives so outstanding that the choice of the better hammer becomes obvious.

That's the PHP Singularity I'm hoping for. I'm trying like hell to do my part to make it happen. How about you?

[advertisement] How are you showing off your awesome? Create a Stack Overflow Careers profile and show off all of your hard work from Stack Overflow, Github, and virtually every other coding site. Who knows, you might even get recruited for a great new position!

0
Your rating: None

It’s not everyday that someone tries to add a new programming language to the web. There’s a good reason for that. The great trinity of web development — HTML, CSS and JavaScript — while not perfect has proved itself highly flexible and capable of adapting as it evolves, which, in the end, might be more important than perfection.

But, regardless of how well those three have served the web thus far, they are not enough for Google, which is hoping the web will now embrace Dart, Google’s brand new programming language for “structured web programming.”

The first hint of Dart surfaced about a month ago when an internal Google memo was leaked onto the web (the memo itself dates from 2010). In it Google claims that “JavaScript has fundamental flaws that cannot be fixed merely by evolving the language.” The answer, for Google, was to go off and create its own homebrewed solution.

That solution is Dart, a “class-based optionally typed programming language for building web applications.”

Lars Bak, a software engineer working on Dart, says the language is designed to work with every thing from “a one-person project without much structure to a large-scale project needing formal types in the code to state programmer intent.”

In other words, Dart is aiming to be a one-size-fits-all solution for writing apps on the web. Dart has been built from the ground up with this goal in mind. Indeed Dart offers some interesting tools, including optional types and the ability to declare private methods via an underscore. Unfortunately for Dart, a couple of novelties don’t seem to be winning over programmers. The Hacker News discussion thread on Dart is full of rather barbed critiques with hardly a supportive voice to be heard.

Dart on the web

Appealing to programmers is only half of what Dart needs to succeed, it also has to work well on the open web. For that Google has two solutions.

The first and ideal solution will be to execute Dart code in a browser-native virtual machine (very similar to how JavaScript is handled today). Of course that means the rest of the browser makers need to join Google in supporting Dart. Because that isn’t likely to happen any time soon, nor will it ever happen for legacy web browsers, Google has a fallback plan — a compiler that translates Dart code to JavaScript.

While the JavaScript compiler solution will mean slower web apps, it also means that Dart apps would always be able to run, regardless of the browser in question. That’s good for older browsers, but it also raises some questions about where Google plans to go with Dart.

Essentially Google has set up a two-tier system for running Dart in the browser, and that is where Dart might run afoul of the open web.

Prior Dart Art

The leaked Google memo that appeared on the web last month created a tempest in the web standards community teacup. The idea that Google had a secret project designed “to replace JavaScript as the lingua franca of web development” did not sit well with those who support open web standards.

The company appears to have backed off that stance somewhat for the official release. In fact Google hardly mentions JavaScript in its Dart announcement and Lars Bak tells CNet that Dart is “not going to replace JavaScript… JavaScript is a cornerstone of the Web today, and it will continue to be for a long, long time.”

That message may be too little, too late. Publicly Google may now be pushing the message that Dart is complimentary to JavaScript, but the blunter language and goals outlined in the leaked memo are already out there, fresh in developers’ minds. That, combined with Google’s less than stellar track record with its “open” projects may make it difficult for Dart to find supporters.

While Dart is open source and available for anyone to use, Google does not have a strong record of fostering open projects, that is, projects where the community can not just download and compile code (Andy Rubin’s “definition of open“) but can actually have a hand in creating features and guiding the direction of the project.

Until the latter component is well established don’t expect other browser makers to adopt Dart. So long as Google controls the strings it’s unlikely its arch rivals like Microsoft and Apple will support Dart.

Without that support Dart won’t be running in a virtual machine; instead it will fall back to running as JavaScript. That effectively means that, while Dart will run in any browser, it will likely have subpar performance in any browser lacking the virtual machine.

What standards proponents fear is a web where only Google’s Chrome browser ever fully supports Dart. That would mean that, while Dart apps would work everywhere, they’d be significantly faster in Chrome. That would send the web back to the bad old days of “works best in Internet Explorer” websites, only this time around it would be “works best in Google Chrome.”

Future Dart

It’s possible that Google will use Dart to finally create a true community-driven project. The company has already said it plans to eventually submit Dart for standardization, which would certainly help.

It’s too early to write off Dart, but it’s also too early to say it will be anything more than a novelty Google uses in its own apps (like WebP or even SPDY). Even if Dart can convince both developers and browser makers to jump on board, don’t look for Dart to become the “lingua franca of web development” any time soon.

See Also:

0
Your rating: None

Have you ever heard a software engineer refer to a problem as "NP-complete"? That's fancy computer science jargon shorthand for "incredibly hard":

The most notable characteristic of NP-complete problems is that no fast solution to them is known; that is, the time required to solve the problem using any currently known algorithm increases very quickly as the size of the problem grows. As a result, the time required to solve even moderately large versions of many of these problems easily reaches into the billions or trillions of years, using any amount of computing power available today. As a consequence, determining whether or not it is possible to solve these problems quickly is one of the principal unsolved problems in Computer Science today.

While a method for computing the solutions to NP-complete problems using a reasonable amount of time remains undiscovered, computer scientists and programmers still frequently encounter NP-complete problems. An expert programmer should be able to recognize an NP-complete problem so that he or she does not unknowingly waste time trying to solve a problem which so far has eluded generations of computer scientists.

You do want to be an expert programmer, don't you? Of course you do!

NP-complete problems are like hardcore pornography. Nobody can define what makes a problem NP-complete, exactly, but you'll know it when you see it. Just this once, I'll refrain from my usual practice of inserting images to illustrate my point.

(Update: I was shooting for a poetic allusion to the P=NP problem here but based on the comments this is confusing and arguably incorrect. So I'll redact this sentence. Instead, I point you to this P=NP poll (pdf); read the comments from CS professors (including Knuth) to get an idea of how realistic this might be.)

Instead, I'll recommend a book Anthony Scian recommended to me: Computers and Intractability: A Guide to the Theory of NP-Completeness.

 A Guide to the Theory of NP-Completeness

Like all the software engineering books I recommend, this book has a timeless quality. It was originally published in 1979, a shining testament to smart people attacking truly difficult problems in computer science: "I can't find an efficient algorithm, but neither can all these famous people."

So how many problems are NP-complete? Lots.

Even if you're a layman, you might have experienced NP-Completeness in the form of Minesweeper, as Ian Stewart explains. But for programmers, I'd argue the most well known NP-completeness problem is the travelling salesman problem.

Given a number of cities and the costs of travelling from any city to any other city, what is the least-cost round-trip route that visits each city exactly once and then returns to the starting city?

The brute-force solution -- trying every possible permutation between the cities -- might work for a very small network of cities, but this quickly becomes untenable. Even if we were to use theoretical CPUs our children might own, or our children's children. What's worse, every other algorithm we come up with to find an optimal path for the salesman has the same problem. That's the common characteristic of NP-complete problems: they are exercises in heuristics and approximation, as illustrated by this xkcd cartoon:

 Travelling Salesman Problem

What do expert programmers do when faced by an intractable problem? They cheat. And so should you! Indeed, some of the modern approximations for the Travelling Salesman Problem are remarkably effective.

Various approximation algorithms, which quickly yield good solutions with high probability, have been devised. Modern methods can find solutions for extremely large problems (millions of cities) within a reasonable time, with a high probability of being just 2-3% away from the optimal solution.

Unfortunately, not all NP-complete problems have good approximations. But for those that do, I have to wonder: if we can get so close to an optimal solution by cheating, does it really matter if there's no known algorithm to produce the optimal solution? If I've learned nothing else from NP-complete problems, I've learned this: sometimes coming up with clever cheats can be more interesting than searching in vain for the perfect solution.

Consider the First Fit Decreasing algorithm for the NP-complete Bin Packing problem . It's not perfect, but it's incredibly simple and fast. The algorithm is so simple, in fact, it is regularly demonstrated at time management seminars. Oh, and it guarantees that you will get within 22% of the perfect solution every time. Not bad for a lousy cheat.

So what's your favorite NP-complete cheat?

[advertisement] Peer code review without meetings, paperwork, or stopwatches? No wonder Code Collaborator won the Jolt Award.

0
Your rating: None