YOW! Melbourne 2011 and that Crankshaft Presentation

Greetings from Melbourne! This week, I attended YOW! 2011, a conference for Australian developers featuring talks on web development, infrastructure and coding practices.

Opening remarks at YOW! 2011 in Melbourne

According to the YOW! conference organizers, approximately 500 people registered for this event. This wasn’t a surprise to me; Melbourne has a fantastic developer community and has always supported events such as these. Mitch Denny and I were witness to this when we co-founded the Melbourne .NET User Group back-in-the-day.

On day 1, I attended a number of excellent presentations. However, there was one presentation in-particular that was simply awesome. It was a presentation by Kasper Lund from Google talking about Crankshaft, the compilation infrastructure of V8 (Chrome’s JavaScript engine). FWIW, Kasper’s also a member of the Dart team.

Kasper Lund (Google) at YOW! 2011 in Melbourne

In his presentation, Kasper went into great detail about how Crankshaft optimizes JavaScript. It’s amazing to hear some of the things that Crankshaft does to tease out every possible drop of performance possible from JavaScript. Much of it involves runtime inspection of the code as it’s running and optimizing when it’s appropriate to do so. The big take-away for me was realizing that JIT compilers have a tough job; they have to walk a fine line between making JavaScript run super-fast without bogging down the environment.

After Kasper’s presentation, it felt like my brain had been through the spin cycle of a washing machine. This is a good thing. Many presentations today are way too shallow. I always prefer to “go deep” on something, struggle along the way, and then reformulate afterward.

Anyway, I found a video up on Vimeo of a talk Kasper gave about the V8 engine:

It’s worth a look in order to gain a better understanding how Google Chrome optimizes JavaScript.

Kendo UI v1.0 Released!

Earlier today, we took the wraps off Kendo UI, a framework for creating interactive web applications with modern web standards. My colleague, Todd Anglin wrote about today’s release in a blog post where he highlights what’s new in Kendo UI, the breakdown of products (Kendo UI Web, Kendo UI DataViz, and Kendo UI Mobile – currently, a preview), and the official licensing that underpins it. The good news? Existing customers will have access to Kendo UI Web in both the Telerik Premium and Ultimate Collections.

There’s a lot to like in the v1.0 release. In addition to some of the new UI widgets, we’ve added an integrated ability to modify themes. We call this the ThemeBuilder.

The ThemeBuilder is a tool that lets you modify the Kendo themes with ease, so that they match the look and feel of your site or app. Through a series of mouse clicks, you can quickly customize the look and feel of the Kendo UI widgets. Once you’re done, the ThemeBuilder will generate LESS or CSS text, which you can then integrate into your web application.

It’s pretty freaking sweet.

We’ve also introduced two new aspects of the Kendo UI framework: globalization and validation.

Globalization is the process of designing and developing an application that works in multiple cultures. The culture defines specific information for the number formats, week and month names, date and time formats, etc. Kendo UI exposes the culture(cultureName) method, which allows you to select the culture script corresponding to the “culture name”. This method then uses the culture name to select culture from the culture scripts that you have included and then sets the current culture. You can check out a live demo of this in-action by visiting the Kendo UI demos.

The Validator in Kendo UI provides an easy mechanism of client-side validation to web developers. Built around the HTML5 form validation attributes, the Validator supports a variety of built-in validation rules, but also provides a convenient way for setting custom rules handling. A live demo of the Validator can be seen on the Kendo UI demos page.

There’s certainly a lot more to cover. Fortunately, we’ll be hosting a webinar that provides you with everything you need to know about Kendo UI to help you get started. Simply register, attend, and you’ll hear everything you need to know about building awesome web experiences with Kendo UI.

In the meantime, make sure to follow Kendo UI on Twitter, Facebook or Google+. Also, don’t forget to check out our forums. They’re a great way to provide feedback to the team.

JustCode for JavaScript Developers

Telerik’s JustCode is an agile development add-in for Visual Studio 2005, Visual Studio 2008 and Visual Studio 2010 that boosts development productivity. It provides blazing fast solution wide on-the-fly code analysis and error checking, smart code navigation and refactoring features. With its cross-language engine, JustCode provides features for C#, VB.NET, ASP.NET, XAML, JavaScript and HTML and supports multi-language solutions.

In this blog post, I’ll highlight how JustCode helps JavaScript developers write better code.

On-the-Fly Code Analysis for JavaScript

Along with the inspections done by Visual Studio, JustCode conducts code analysis, which provides a list of errors and warnings found in your JavaScript. It does so by applying a list of custom inspections of your solution on-the-fly, without interrupting your work.

In the Code Analysis settings, you’ll find options to control how JustCode inspects your JavaScript. By default, JustCode will mark all syntax errors along with non-optimal statements (i.e. empty statements). These errors/warnings are displayed to the developer in the editor and document well:

In the image (above), items marked in yellow are warnings. Items marked in red are errors. A more detailed list is provided in the JustCode Errors window:

This list can be filtered across all columns, allowing you to quickly find a particular class of error/warning:

JustCode is highly configurable. The errors/warnings discovered during the on-the-fly code analysis can be configured through the Code Analysis options of JustCode:

Once an error or warning has been discovered, the next step is to fix it. Once JustCode has inspected your JavaScript, it will provide you with Quick Fixes to fix any non-optimal statement:

In addition to Quick Fixes, JustCode also provides a feature called Quick Hints. These are code inspections that recommend ways for improving your code. While Quick Fixes warns you about code that won’t compile, Quick Hints will provide suggestions on how to improve it:

Quick Hints – along with many other aspects of JustCode – is highly configurable:

Code Navigation and Search

Go To Definition command navigates you to the definition of a selected identifier:

You can invoke this command by simply right-clicking a variable and selecting “Go To Definition” or press F12.

Go To Member is a useful feature of JustCode that’s provided in the editor window. It allows you to quickly jump to members by supporting statement completion:

The Find Usages command helps locate where a variable is used in the solution:

This view can be expanded to show all instances of the variable being searched for:

You can also modify this view by specifying a group criteria:

Code Templates

Code Templates are reusable code snippets that allow you to quickly insert commonly used code fragments or surround given code fragment with a meaningful code block (example: try-catch statement). With this feature you just type the abbreviation for the template, press “Shift+Space” and the template expands:

When JustCode expands a template, it will search for all variables in scope that can help complete the code template. In addition, it will suggest appropriate variable names where necessary:

The list of available code templates can be easily expanded to include ones that embody common patterns or conventions that you leverage within your JavaScript.

Rename

It’s useful to know what the impact of renaming a variable before committing it to your source. The Rename operation in JustCode allows you to see the changes you’ll make ahead-of-time beforehand:

You can see the code that’s impacted along with the locations where these changes will occur.

At this point, we’ve only scratched the surface of what JustCode can do. There are many useful features that will help JavaScript developers write better code. If you’d like to try JustCode for yourself, you can download a free, 60-day trial by visiting http://www.telerik.com/products/justcode.aspx and clicking the DOWNLOAD button on the page.

My Experience at SydJS

I have a new, favourite group and its name is SydJS (@sydjs).

Before arriving in Australia just over one month ago, I knew that it was critical to get myself involved in the local developer community. As a Developer Evangelist for Telerik, it’s important that I’m connecting to our customers (i.e. developers). This allows us to hear what they love (and maybe, not love quite as much) about our products. It also allows us to introduce ourselves to developers who maybe haven’t heard of us.

An effective way of connecting with developers, of course, showing up and getting involved in the local community. This can be done in a number of different ways. I find that being present and helping out are a good start. Ultimately, to become truly connected, you need to give back. (More on this in a blog post later.) It should be noted that I love developer communities regardless of my job role; there’s a good chance that I would have attended SydJS anyway. But, I digress.

Last night, I attended my first meeting of the Sydney JavaScript group (SydJS) at Atlassian. In short, what an awesome group; lots of passionate developers who care deeply about JavaScript. Oh, and beer. They definitely care about beer.

The night’s agenda provided four presentations:

• A Walk Through JavaScript’s Event-Driven Model by Jonathan Creenaune
• AltJS – Languages That Compile to JavaScript by Brian McKenna (@puffnfresh)
• Inside Large Scale Applications by Adam Ahmed (@hitsthings)
• Getting Loud About Amplify.js by Wesley Walser (@wewals)

The one presentation that impressed me the most was Brian McKenna’s lap around languages that compile to JavaScript. In this session, I learned about Roy (built by Brian) and about Source Maps, which – frankly – are kinda awesome. From a .net Magazine article that highlights Source Maps:

There is detailed information on the progress of the Mozilla work over on the wiki at wiki.mozilla.org/DevTools/Features/SourceMap, and you can read about the WebKit work atbugs.webkit.org/show_bug.cgi?id=63940. The Mozilla document states that this feature is targeted for release in Firefox 9.

The presentations that were delivered provided more of a high-level overview of JavaScript-related concepts. It’s wasn’t terribly low-level but that’s OK. There were a number of new members who haven’t written a great deal of JavaScript yet and I’m sure these presentations helped in their skills development.

The other thing that I impressed me was the core group of folks at Atlassian. They have passionate developers who understand why JavaScript rocks. The digs are too bad either. They also appear to pride themselves on grokking development; right down to the swag.

But, of course, the highlight for me was this:

You can almost hear these values recited by Morgan Freeman; “That’s goddamn right.”

So, all in all, I had a great time at SydJS and I’m already looking forward to the next meeting. Why not sign up? Registration is free and the folks are super-friendly.

Reducing FOUT with FOUT-B-Gone

While I’m a big-time fan of web fonts, I’m not a fan of a side effect I’ve observed in browsers like Firefox and IE. In particular, I’ve noticed that during the loading of a page, there’s a moment where web fonts aren’t applied. This is known as FOUT or “flash of unstyled type”. Coined by Paul Irish back in 2009, FOUT refers to an instance where web fonts appear briefly unstyled prior to apply the @font-face CSS rule. After the web page appears, the viewer sees unstyled fonts morph into styled web fonts. By way of example, here’s what you will see (briefly) on the initial load of pages that leverage web fonts:

You’ll notice here that the title of my blog isn’t applying a web font on the initial load. That’s because there’s a slight delay in particular browsers (i.e. Firefox and IE). It should also be noted that the delay is brief but noticeable. If you’d like to fix this, check out WebINK’s FOUT-B-Gone:

FOUT-B-Gone is a JavaScript library that inventories custom fonts used on a page and selectively hides only DOM elements that would cause FOUT. The end result of applying this to your page is a delayed rendering of text with applied web fonts. However, it is quite reliable and eliminates the artifact you’ll see otherwise. Now, I haven’t decided to apply FOUT-B-Gone to my page because I simply don’t care. However, if you are in the boat that does (or, have clients that do), this is a possible solution for you.