!!--FuTuRe Of CoDiNg--!!

a new compression algorithm called Courgette to make Google Chrome updates small.

2009-07-16T13:23:00.000-05:00

We have built Google Chrome to address multiple factors that affect browser security. One of the pillars of our approach is to keep the software up to date, so we push out updates to Google Chrome fairly regularly. On the stable channel these are mainly security bug fixes, but the updates are more adventurous and numerous on developer channel.

It is an anathema to us to push out a whole new 10MB update to give you a ten line security fix. We want smaller updates because it narrows the window of vulnerability. If the update is a tenth of the size, we can push ten times as many per unit of bandwidth. We have enough users that this means more users will be protected earlier. A secondary benefit is that a smaller update will work better for users who don't have great connectivity.

Rather then push put a whole new 10MB update, we send out a diff that takes the previous version of Google Chrome and generates the new version. We tried several binary diff algorithms and have been using bsdiff up until now. We are big fans of bsdiff - it is small and worked better than anything else we tried.

But bsdiff was still producing diffs that were bigger than we felt were necessary. So we wrote a new diff algorithm that knows more about the kind of data we are pushing - large files containing compiled executables. Here are the sizes for the recent 190.1->190.4 update on the developer channel:

* Full update: 10,385,920 bytes
* bsdiff update: 704,512 bytes
* Courgette update: 78,848 bytes

The small size in combination with Google Chrome's silent update means we can update as often as necessary to keep users safe.

Get Your Database Under Version Control

2008-08-11T01:42:00.000-05:00

When it comes to version control, the database is often a second or even third-class citizen. From what I've seen, teams that would never think of writing code without version control in a million years-- and rightly so-- can somehow be completely oblivious to the need for version control around the critical databases their applications rely on. I don't know how you can call yourself a software engineer and maintain a straight face when your database isn't under exactly the same rigorous level of source control as the rest of your code. Don't let this happen to you. Get your database under version control.

I was thinking about this again because my friend and co-author K. Scott Allen just wrote a brilliant five part series on the philosophy and practice of database version control:

Silverlight - Basics - XAML

2008-05-29T23:09:00.000-05:00

Silverlight 2.0 is on its way to an official release, and with beta 1, we are now seeing a fuller implementation, including a number of standard controls and richer support to accomplish common tasks. If you're new to Silverlight / Windows Presentation Foundation, the place to start is understanding XAML (pronounced zammel) - the Extensible Application Markup Language. XAML is an XML dialect, and thus, follows the traditional tree hierarchy of elements you're used to seeing in XML. The main features of XAML are:

* Element names correspond to objects. A "" in XAML corresponds to the System.Windows.Controls.UserControl class, for example.
* Type converters understand string property values. Type converters are used to convert a property value, such as Background="White" or Background="#FF0000" to the class behind the property. A type converter parses and understands what you're asking for (as long as you specify something it can convert)
* Markup extensions. A markup extension is a special way of saying "interpret this property value, don't take it literally or type convert it." Markup extensions are using for referencing resources, creating control templates and data binding.
* Dependency properties and attached properties. A dependency property is a property that depends on potentially many things - including animation, data binding and the value you explicitly set. An attached property is a special type of dependency property that an object doesn't define. It is "attached" in that the object with the attached property has the property, but it is meaningless to the object itself. The attached property IS meaningful, however, to elements enclosing the object. A great example is a container such as Canvas (it provides absolute positioning) and the attached property Canvas.Left and Canvas.Top - specify these on a child object, such as an Image, and the Canvas knows where to place the Image.
* Direct connection to code-behind. When built, the XAML file causes generation of a piece of the class specified by the x:Class attribute, and it is here that object identifiers are created to connect to the objects specified by elements in the XAML (as long as the element in XAML has an x:Name attribute defined) This connection also includes connecting to event handlers in the code-behind.

This is a rather quick overview of XAML - over time we will delve deeper into these features and all the aspects of Silverlight.

Silverlight Tips, Tricks, and Best Practices

2008-05-17T01:52:00.000-05:00

Unless you've been stuck on a desert island for the past several months, you've undoubtedly heard about Silverlight™, the new cross-browser, cross-platform solution from Microsoft that helps you build rich Internet applications and rich, immersive media experiences in the browser. Version 1.0, which combines a XAML rendering engine with a JavaScript API, shipped in September 2007. Version 2.0, which will enter beta soon, will pair an enhanced XAML engine with a version of the CLR that runs in the browser, a Silverlight version of the Microsoft® .NET Framework Base Class Library (BCL), and a managed API. (That's right: C# in the browser!)
Silverlight 1.0 applications are proliferating on the Web, thanks in part to some of the high-profile companies that adopted it early and helped spread the love. The programming model is simple enough for an experienced developer to begin building Silverlight applications in a matter of hours. What's missing for this still very young platform, however, is that wealth of knowledge and resources that accompanies more mature platforms.
I've been developing Silverlight apps for more than a year now and have put together a list of best practices that I and other developers on my team use to build better applications. This column contains some of the most helpful ones.

Take Performance Tips to Heart
Not long before Silverlight 1.0 shipped, Microsoft published a document titled "Performance Tips for Silverlight-Based Applications" (msdn2.microsoft.com/bb693295). This guide is a compilation of tips for optimizing performance by avoiding some common mistakes. The best practices you'll find include:

* Use the Visibility property rather than Opacity to hide objects.
* Don't use the Width and Height properties of MediaElement and Path objects.
* Detach programmatically registered event handlers after use.
* Use transparent control backgrounds sparingly.

Most of these make sense when you read them. It's not hard to imagine why it's better to encode videos using the width and height at which you intend to display them (rather than encode them at one scale and display them at another). It's because the Silverlight rendering engine can avoid resizing each frame on the fly. Still, it's good to see them written down and to know that Silverlight doesn't do something fancy to resize video without incurring a performance penalty.
One best practice that I would add to that document is to avoid redundant calls to FindName. I often see event handlers structured this way:
Copy Code

function onClick(sender, args)
{
var rect = sender.findName('Rect');
rect.fill = 'red';
}

The problem is that FindName has to walk the tree of XAML objects to find its target. If you're going to be referencing the XAML object named "Rect" many times over the lifetime of the app, you should initialize it once—for instance, in an event handler for the root canvas's Loaded event—and store the reference in a global variable. Then, instead of calling FindName every time onClick is called, you can do this:
Copy Code

function onClick(sender, args)
{
_rect.fill = 'red';
}

The resulting code will be faster than the original. But if a developer does this, he should be sure to release that reference when finished with the plugin. In normal pages this is never an issue, but in an AJAX app where whole pieces may be coming and going, its crucial to release those references to avoid a memory leak. For that reason, the Sys.UI.Silverlight.Control ajax type that is used when using the ASP.NET Silverlight Control (currently available in the Extensions 3.5 Preview Community Technology Preview) provides a pluginDispose method you can override to release references and event handlers.

Offer a Compelling Installation Experience
Too often the Silverlight-based application installation experience is not friendly enough to users who don't have Silverlight installed, as exemplified by the barren landscape displayed in Figure 1. Silverlight.createObjectEx—the function that's typically called to instantiate a Silverlight control—displays a "Get Microsoft Silverlight" button when Silverlight isn't present. Clicking the button transports the user to the Silverlight Web site to download and install it. You can improve the experience somewhat by setting Silverlight.createObjectEx's inplaceInstallPrompt parameter to true, enabling the user to download and install Silverlight without leaving the Web page. But even that leaves something to be desired, especially when Silverlight comprises most or all of the content on the page.
Figure 1 Default Silverlight Installation Experience (Click the image for a larger view)
Microsoft recently published a document that should be required reading for all developers using Silverlight—"Silverlight Installation Experience Guide." It's available for downloading along with sample code at go.microsoft.com/fwlink/?LinkId=106023. The document outlines a general technique for displaying HTML content (including a "Get Microsoft Silverlight" button and browser-specific instructions) in a Silverlight DIV when Silverlight isn't installed, and XAML content when it is. The idea is to paint a picture of what the user would see if Silverlight were installed and hopefully to entice him to click the button.
This column is accompanied by a sample application named RevolvingAuto that demonstrates some of the best practices presented here, including how to build a better installation experience. I'll show you key portions of its source code shortly.
RevolvingAuto is notable for its installation experience. Figure 2 shows what the home page looks like to a visitor who doesn't have Silverlight installed. Behind the "Get Microsoft Silverlight" button is a shaded version of the same user experience the user would see if Silverlight were installed. Because the call to Silverlight.createObjectEx includes an inplaceInstallPrompt="true" parameter, the user can install Silverlight without leaving the Web page. And to top it off, the home page includes logic to create the Silverlight control after installation is complete, eliminating the need for a manual refresh. (This feature works great in Internet Explorer® because it doesn't have to be restarted after Silverlight is installed. It's powerless in browsers that require a restart, unfortunately.)
Figure 2 RevolvingAuto before Silverlight Is Installed (Click the image for a larger view)
The JavaScript that drives the install experience lives within Default.html (see Figure 3). To create a Silverlight control, most Silverlight applications structure the code and markup like this:
Figure 3 RevolvingAuto Application—Default.html
Copy Code

Revolving Auto

Copy Code

RevolvingAuto structures it this way instead:
Copy Code

The code inside the

The script engine.js contains the core of DWR. Generally, you just include it as is, and then ignore it. There are a few methods in it that are sometimes useful, but you can see the full documentation for them at the DWR website. The script util.js contains some utility functions that are totally optional, but will help you greatly in getting anything done with DWR. Chat.js is dynamically generated by DWR as the remote version of Chat.java. If you look at it, you'll see something like this:

Chat.addMessage = function(callback, p0) { ... }
Chat.getMessages = function(callback) { ... }

DWR does everything it can to make the JavaScript version of your Java code as simple as possible, but there are some things you need to be aware of. The most obvious is that the "A" in AJAX stands for asynchronous; so by definition, the remote method is not executed the instant your JavaScript code is executed. This would not be an issue, except for the complexity of knowing what to do with the values returned by Java to the browser. DWR solves the problem by asking for a callback method, to which it will pass the returned data. The first parameter to any DWR-generated method is always the callback function.

Above, we created a web page with a JavaScript function that we've not implemented, until now: the sendMessage() event is fired off by the browser whenever the "send" button is pressed. As you might guess, this is going to call Chat.addMessage():

function sendMessage()
{
var text = DWRUtil.getValue("text");
DWRUtil.setValue("text", "");
Chat.addMessage(gotMessages, text);
}

The first line gets the value from the input field. DWRUtil.getValue() works with most HTML elements, so long as they have an id attribute (in this case, the input element has an id="text").

Next, we use the setValue() method to blank out the input element; again, the setValue() is very smart at working out what to do with your data and how it should update your web page with the new data.

Then we call Chat.addMessage() and ask DWR to return the list of messages typed by other web users to the gotMessages() function. It looks like this:

function gotMessages(messages)
{
var chatlog = "";
for (var data in messages)
{
chatlog = "

" + messages[data].text +
"

" + chatlog;
}
DWRUtil.setValue("chatlog", chatlog);
}

This is where DWR excels. The Java method Chat.addMessage() returned a List of Message objects. DWR has automatically converted this into an array of JavaScript objects. All we need to do in gotMessages() is to iterate over the messages array, getting the text member from each object in the array, and build some HTML from it. Finally, we push the string we have created into the div using the ever-versatile setValue() method.

And that's it! We have a basic multi-user, web-based chat system in about 100 lines of code, for both the client and server code.

There are a number of things missing for this to be useful: a polling method that uses setTimeout() to call Chat.getMessages() would keep things flowing a bit more. The downloaded code contains an extra six lines of JavaScript to make this happen. We could also add code to only alter the display if new messages have arrived; this would make for a flicker-free display. Finally, having a back-off mechanism where the browsers poll the server less often if nothing much is happening would be a good idea to prevent swamping the server.

You can see the final version here. It adds the features listed above, plus highlighting of new messages--all of which takes an extra 50 or so lines of JavaScript.

It is also worth checking out http://localhost:8080/[YOUR-WEB-APP]/dwr, which is a test debug page that automatically shows you the classes you have remoted, and allows you to test their functionality.

Conclusion
Using DWR can make creating cross-browser AJAX websites very easy, and introduces a very neat way to interact between JavaScript in the web browser and Java on the server. It is simple to get started with and integrates well with your current website

Coding an XML Configuration File

2008-02-27T03:55:00.000-05:00

This is a problem that we see a lot in .NET as well as programming in general these days. There are a lot of good ideas built into .NET and more ideas that are just carried forward for compatibility's sake. In particular, there are a lot of methods to choose from if you need to save a little configuration data for your program.

This article will describe the various ways that this can be done, but we'll finish up with a very simple example - complete with the downloadable source - showing what I think is the easiest way to save a few data items between program executions: native XML.

From a historical perspective, configuration information used to be saved in simple text files. You may still see a file named "settings.txt" or "config.txt" even today. In their latest book (Visual Basic 2005 for Programmers, 2nd Edition, Paul J. Deitel, Harvey M. Deitel, ISBN: 0-13-225140-X), the Deitel Developer Series has a major section showing how to create and read what is actually a "comma separated value" (CSV) file - an idea that is decades old. (Their goal is to demonstrate stream oriented sequential file processing, but the end result is the same.)

The next step up the ladder was to require some structure for configuration files. The best example is proably the .INI files. Here's what a typical .INI file looks like (from Wikipedia):

[section1]

; some comment on section1
var1 = foo
var2 = doodle

[section2]

; another comment
var1 = baz
var2 = shoodle

These types of files were very typical when Windows 3.1 was the hot OS, even though Windows itself used config.sys and autoexec.bat for most startup configuration.

Then the thinking shifted to another idea: Put all your eggs in one basket and then watch that basket !! The "basket" is the Windows registry and it's still used for most of the Windows OS information. The next version of Windows, Vista, will continue to use the registry in just about the same way. In the era of Windows 2000 and Windows NT, creating lots of little .INI files was discouraged and programmers were encouraged to put their own program configuration information in the registry too, but we have discovered now that stuffing everything into one basket has it's own set of problems. So while COM, the technology used in VB 6, required that DLL's be "registered" .NET does not. VB.NET does provide excellent support for saving configuration information in the registry using the My.Computer.Registry object that is new in Framework 2.0 if that's the way you want to go.

The idea of using individual configuration files - information that is only used by your program in a few small files in the program folder - gets a lot more respect these days, thanks in no small measure to .NET. After all, Visual Studio will create a couple of dozen different files for even the simplest Windows application filled with exactly this kind of information.

But there are still more options to be considered.

The new buzzword for writing a file these days is "persist" -- as in "Persisting an Object" or "Persist an ADO.NET DataSet" (titles taken directly from Microsoft's web site). I used to call it, "saving an object" or "writing a dataset" but I guess I'll have to catch up with the times and start saying "persist" now. The idea is that some result of the program lasts after the program stops running and is restored when the program starts up again. The dictionary definition of "persist" is "to exist in spite of adversity." Being removed from computer memory is an example of adversity, I suppose.

You can persist information in several formats, however. We started the article by considering CSV and INI files, but there are more formats available now. VB.NET has excellent objects that help you serialize data to binary files, SOAP files, or XML files. Serialization is just the process of converting an object into a linear sequence of bytes. You can read more about serialization in lesson 3 from an About Visual Basic email tutorial. Microsoft's own Visual Studio will save configuration data in binary, XML, and proprietary formats. You can find examples in Microsoft's MSDN web site about how to persist data in all of these formats.

The code . . .
In my opinion, however, if you want your program to be as easy to understand as possible, and you want the data itself to be easy-to-read text too, then creating a configuration file using XML methods is probably the way to go. Most modern programming technologies now completely support XML and you can open an XML file in either Notepad or most browsers to see what's in it. Writing the file directly with XML methods in VB.NET makes what is happening as clear as possible in the program code. The alternative of "serializing" to an XML file does a lot of the work for you but also makes the creation of the XML a "black box". The example you will see here puts it all out there in the open.

As an example of an alternative, here's a program designed to be used as a desktop utility for simple calculations of stock market prices and amounts.

The starting values are set using an XML configuration file. The starting values that will be used the next time the program is loaded can be set using an update routine that overwrites the XML file with new values. The illustration below shows the XML file displayed in IE. (IE is one of the best XML utilities!) The first task for the program is to write the XML file. The code that writes the XML file is shown below.

Dim Doc As New XmlDocument
'Create a 'vanilla' XML Declaration (processing instruction)
Dim myXmlDeclaration As XmlDeclaration
myXmlDeclaration = _
Doc.CreateXmlDeclaration("1.0", "UTF-8", "yes")
Doc.AppendChild(myXmlDeclaration)
' <-Root Created
Dim Root As XmlElement
Root = Doc.CreateElement("StockCalcDefaults")
'Create a company name child node
Dim Child As XmlElement
Child = Doc.CreateElement("companyName")
Child.InnerText = companyName.Text
Root.AppendChild(Child)
'Create a Buy Price child node
Child = Doc.CreateElement("buyPrice")
Child.InnerText = _
CStr(Decimal.Round(buyPrice.Value, 2))
Root.AppendChild(Child)
'Create a Sell Price child node
Child = Doc.CreateElement("sellPrice")
Child.InnerText = _
CStr(Decimal.Round(sellPrice.Value, 2))
Root.AppendChild(Child)
'Create a Number of Shares child node
Child = Doc.CreateElement("numShares")
Child.InnerText = CStr(numShares.Value)
Root.AppendChild(Child)
'Add an attribute to the child node
Dim Attr As XmlAttribute
Attr = Doc.CreateAttribute("incByThousand")
Attr.Value = CStr(incByThousand.Checked)
Child.Attributes.Append(Attr)
'Create a Profit Amount child node
Child = Doc.CreateElement("profitAmount")
Child.InnerText = _
CStr(Decimal.Round(profitAmount.Value, 2))
Root.AppendChild(Child)
' <-Root Added to Doc
Doc.AppendChild(Root)
'Write XML to a file
Dim Output As New XmlTextWriter( _
"StockDefaults.xml", _
System.Text.Encoding.UTF8)
' <-Document Written
Doc.WriteTo(Output)
Output.Close()

How the code works
There are a lot of lines of code here, but they fit into some neat categories that will help you understand what they do.

When programming XML, you have to learn to "think" XML first. The most fundamental organization of XML is a hierarchy. So, rather than writing the XML line-by-line as you might expect in a sequential file, the most direct way to write an XML file is to create it node-by-node and then write it. There are other techniques and you might want to experiment. You might find one that fits your way of thinking about it better.

In this program, the first statements create the XML declaration. This identifies the file as an XML file and is strictly required. Then a root node is created and populated with all of the content: child nodes and any XML attributes.

(This program includes just one XML attribute, incByThousand, to the numShares element.) Finally the root node is appended to the XML document and the whole thing is written to a file. No path information is provided so this file is written to the same folder that the executable is in. I used the same names for the XML elements and attributes as I used for VB program variables just to make things easier to code. This isn't required.
In this program, reading the XML document back again requires you to change your thinking back to a sequential mode. Although Microsoft's System.Xml namespace gives you the tools to zero in on exactly what you need, in this case it's easiest to simply read through the XML in sequence and assign the data back into variables. I do this in the Load event for the form. A Do While loop moves through the XML document from front to back and a Select Case block simply extracts the values that the program needs.

One interesting sidenote that contributes to confusion is that the Value property of an XML node can be used some of the time and some of the time it can't. The Tool-Tip unhelpfully tells us that Value "Gets the text value of the current node."

Not exactly right.

For example, this statement compiles, but creates an exception when the program runs:

Child.Value = companyName.Text

This statement works fine when the node type is an attribute but always assigns a null reference when the node type is an element.

varName = Input.Value

This MSDN page tells you when it works and when it doesn't. Although their documentation could be a lot more clear about why things work this way, you can't really blame Microsoft for the problem. The cause is the very exact way that XML works. For example, a node in XML might look like this:

FirstDataSecondData

What's the "value" of the element node? Is it "FirstData"? Or "FirstDataSecondData"? Microsoft's very complete System.Xml namespace has methods to deal with every possibility, but some of them don't make sense until you have more experience with XML.