Search Logger
Archives for January, 2010.

Archive for January, 2010

Books are Full of Visual Gems: 19th Century home exercise edition!

2:41 pm - January 12, 2010 in Google Book Search Blog


It may come as no surprise to the book nerds out there (you know who you are) that the annals of written history are full of visual gems.

When you come across something interesting in a public domain title that has been scanned via our Library Project, you can easily add it to your own website or blog. Simply snag the chunk of text or image using our Share this Clip feature in Google Books () and copy and paste the Embed HTML code onto your site.

It's hard to believe, but we're already a few weeks into 2010. For many folks, a new year means the creation of New Year's resolutions. Though I usually don't bother coming up with my own, I used January 1, 2010 as my excuse to get back to the gym. I was never much of an athlete, but so far I've stuck to my resolution to run a few miles a few times a week.

For a historical perspective on my little project, I went on Google Books and started digging up home exercise and workout manuals from the end of the 19th century. Turns out the fundamentals of weight training haven't changed much in 100 years, although I usually don't go running in a three-piece suit and handlebar mustache. I used the Clip feature in Google Books to collect these images and diagrams. Simply click any image to read the original book source!

[Please note, some content may not be available in full view to users outside of the United States.]


"A manual of the theory and practice of the lifting exercise" - 1871



"A system of physiologic therapeutics" by Solomon Solis-Cohen - 1904



"Health Habits" by M. V. O'Shea and J. H. Kellogg - 1921



"Physical Culture: A Manual of Home Exercise" - 1892



Home gymnastics for the sick and the well" by Eduard Ferdinand Angerstein - 1889


"Calisthenics and light gymnastics for home and school" by Alfred M. A. Beale & Samuel M. Spedon - 1888
 

In the Wild for January 10, 2010

12:18 pm - January 8, 2010 in Yahoo! User Interface Blog

News and notes from the YUI community over the past month…let us know in the comments or at @yuilibrary if we missed something important:

 

Google Cluster Data

11:11 am - January 7, 2010 in Google Research Blog


Google faces a large number of technical challenges in the evolution of its applications and infrastructure. In particular, as we increase the size of our compute clusters and scale the work that they process, many issues arise in how to schedule the diversity of work that runs on Google systems.

We have distilled these challenges into the following research topics that we feel are interesting to the academic community and important to Google:
  • Workload characterizations: How can we characterize Google workloads in a way that readily generates synthetic work that is representative of production workloads so that we can run stand alone benchmarks?
  • Predictive models of workload characteristics: What is normal and what is abnormal workload? Are there "signals" that can indicate problems in a time-frame that is possible for automated and/or manual responses?
  • New algorithms for machine assignment: How can we assign tasks to machines so that we make best use of machine resources, avoid excess resource contention on machines, and manage power efficiently?
  • Scalable management of cell work: How should we design the future cell management system to efficiently visualize work in cells, to aid in problem determination, and to provide automation of management tasks?
To aid researchers in addressing these questions in a realistic manner, we will provide data from Google production systems. The initial focus of these data will be workload characterization. Details of the data can be found here. The data are structured as follows:
  • Time (int) - time in seconds since the start of data collection
  • JobID (int) - Unique identifier of the job to which this task belongs
  • TaskID (int) - Unique identifier of the executing task
  • Job Type (0, 1, 2, 3) - class of job (a categorization of work)
  • Normalized Task Cores (float) - normalized value of the average number of cores used by the task
  • Normalized Task Memory (float) - normalized value of the average memory consumed by the task
We solicit your feedback in terms of: (a) the quality and content of the data we are providing; (b) technical approaches and/or results related to the topics above; and (c) other research topics that you feel Google should be addressing in the area of Cloud Computing (along with details of the data required to address these topics).
 

More code reuse patterns in YUI3

9:41 am - January 7, 2010 in Yahoo! User Interface Blog

Stoyan Stefanov.About the Author: Stoyan Stefanov (@stoyanstefanov) is a front-end engineer at Yahoo! Search. He is also the architect of YSlow 2.0, co-creator of the smush.it image optimizer, speaker and technical writer. His latest book is called Object-Oriented JavaScript.

This post is a follow-up to the article “Inheritance patterns in YUI3″ and dives deeper into the YUI3 APIs showing more patterns for code reuse. The Gang of Four book advocates that we should “prefer object composition to class inheritance”. And in fact, inheritance is sometimes used as a workaround in strongly typed languages where the signature of an object or a class needs to be fixed at compile time. JavaScript is loosely typed and objects can be composed, mixed and augmented at any time.

Augmenting objects

In real-life JavaScript, it’s rare that you would have to setup deep inheritance chains. Often you may only want to augment an existing object (or a constructor) with the members of another, without necessarily forming a parent-child relationship. YUI offers the method Y.augment(...) to do just that.

The following example illustrates the difference between the proper inheritance with Y.extend(...) and the simple object augmentation with Y.augment(...).

// parent, a.k.a. supplier of functionality
function Programmer(){}
Programmer.prototype.writeCode = function(){};

// a constructor that gets augmented with supplier's members
function CodeMonkey(){}
Y.augment(CodeMonkey, Programmer);
var monkey = new CodeMonkey();

// a constructor that inherits from the parent-supplier
function Guru(){}
Y.extend(Guru, Programmer);
var guru = new Guru();

Now that we’ve reused Programmer’s functionality in two ways, let’s test the outcome. Both objects monkey and guru now get a writeCode() method, but only the guru is part of the inheritance chain.

alert(typeof monkey.writeCode); // "function"
alert(typeof guru.writeCode); // "function"

// monkey is not a Programmer, while guru is
alert(monkey instanceof Programmer); // false
alert(guru instanceof Programmer); // true

Y.augment(...) can also take an object (as opposed to a constructor) to be augmented.

var n00b = {};
Y.augment(n00b, Programmer);

// now n00b can writeCode
alert(typeof n00b.writeCode); // "function"

Y.augment(...) allows the recipient to be more picky when reusing code from the supplier. An optional third parameter to Y.augment(...) defines whether existing properties should be overwritten (false by default, meaning preserve the original properties of the recipient). The fourth parameter can optionally provide a whitelist – an array containing the names of the properties that should be carried over.

Cloning

Cloning objects is yet another pattern for code reuse, which allows you to create brand new objects which are just like existing ones. In a way, the idea is similar to the prototypal inheritance (see Y.Object(...) in the previous article), where objects inherit from objects. The main difference is that when cloning, the parent’s properties get copied to the child directly, not through the prototype chain.

Y.clone(...) creates a deep copy, meaning it recurses through array and object properties. It also creates copies by value, so that the cloned object doesn’t modify the parent by mistake (in JavaScript arrays, objects and functions are copied by reference).

To illustrate the difference, consider an object pro that gets cloned into a new object clone and also inherited as wiz using Y.Object(...).

// original object
var pro = {groks: ['html']};

// inherit
var wiz = Y.Object(pro);

// clone
var clone = Y.clone(pro);

Now let’s add a new array element to the original object

pro.groks.push('css');

The child object sees the updated value, while the clone doesn’t, because the clone is a snapshot of what the object was at the time of cloning.

wiz.groks.join(); // "html,css"
clone.groks.join(); //"html"

This works the other way around as well – when the child modifies the array.

wiz.groks.push('js');
pro.groks.join(); // "html,css,js"
clone.groks.join(); // "html"

Clone discussion

As you can see Y.clone(...) creates new objects by deep-copying all their properties and methods. Although this is probably not what you’d normally call inheritance, it’s still a pretty simple and straightforward pattern for code reuse. After all code reuse is about avoiding the need to duplicate code and reusing existing functionality.

Something you may be wondering – what about performance? Isn’t it inefficient to copy values like that. The answer is – yes, it could be inefficient. But for most applications this would rarely be the bottleneck. In fact Firebug (Firefox extensions are written in JavaScript), which is a pretty complex piece of software has an extend() method which works by simply copying properties from the parent object to the child object, using a shallow copy (not recursing into objects and arrays).

So, since cloning is just deep-copying properties from one object to another, wouldn’t it be nice if you can inherit functionality from multiple objects, not only from one? This is where Y.merge(...) comes to help you with this sort of mix-in objects.

Mixin objects with Y.merge(...)

The mixin pattern allows you to grab properties and methods from multiple objects and carry them over into a new object. YUI3 provides the method Y.merge(...) which can take any number of objects and return a single one which is a mix of all source objects.

Here’s an example:

var mad_skillz = {bake: function(){}, mix: function(){}, eat: function(){}};
var ingredients = {sugar: "lots", flour: 1, eggs: 2};
var dairy = {milk: 1};

// mixin
var cake = Y.merge(mad_skillz, ingredients, dairy);

Now you can test which properties got carried over to the cake object using the convenient method Y.Object.keys(...) which gives you an array of all property names.

Y.Object.keys(cake).join(); // "bake,mix,eat,sugar,flour,eggs,milk"

Y.merge(...) resembles cloning, but instead of deep-copying one object, it creates a shallow copy and can take multiple objects to mix with the same method call. The overwriting logic of Y.merge(...) in cases of property naming collisions is different than most other methods – if you have two members with the same name, the last one wins and overwrites the previous.

Just like with Y.clone(...), Y.merge(...) is not necessarily limited to the purposes of code reuse. You can use them also for manipulating arrays or any sort of hash-like objects, such as configuration objects.

Y.mix(...)

Y.mix(...) is the lower-level method behind most of the functionality discussed above. It offers you a fine-grained control over which properties get copied and where exactly. It also allows you to combine two properties with the same names, ignore certain properties and so on.

Here’s a somewhat complex example of using the Y.mix(...) API:

// an object
var pro = {
  groks: ['html', 'css', 'js'],
  speaks: ['Latin'],
  tweets: true
};

// a constructor
function WebGuru(){}

// augmenting the prototype of the constructor
// with some of pro's properties
Y.mix(WebGuru, pro, true, ['groks', 'tweets'], 4);

// test
var guru = new WebGuru();
guru.groks.join(); // "html,css,js"
guru.tweets; // true
guru.speeks; // undefined

If you look at the call to Y.mix(...), we have 5 arguments, meaning:

  1. WebGuru gets more members…
  2. from pro
  3. overwriting any existing ones…
  4. only if they are in this whitelist array ['groks', 'tweets']. This means that the speaks property will not be mixed
  5. 4 is the mode. There are five mixing modes – 0 to 4, where 4 means that the prototype of WebGuru will receive members from pro.

You can check the docs for more information on the parameters accepted by Y.mix(...).

That’s all folks!

Thank you for reading! For more information and examples on the OOP functionality in YUI3, you can consult these links:

 

Inheritance Patterns in YUI 3

9:30 am - January 6, 2010 in Yahoo! User Interface Blog

Stoyan Stefanov.About the Author: Stoyan Stefanov (@stoyanstefanov) is a front-end engineer at Yahoo! Search. He is also the architect of YSlow 2.0, co-creator of the smush.it image optimizer, speaker and technical writer. His latest book is called Object-Oriented JavaScript.

This article discusses two JavaScript code reuse patters implemented in YUI 3 – the classical inheritance pattern and the prototypal inheritance pattern.

Satisfying dependencies

The prototypal pattern is available from the core YUI 3 API in the yui-min.js seed file. The classical pattern requires the oop module, but since the oop module is a requirement for most of the other modules, you usually won’t have to do anything special to get access to this functionality. But if you want to create a simple test page to play with the patterns yourself, you can satisfy the dependencies by including YUI like so:

<script type="text/javascript" src="http://yui.yahooapis.com/3.0.0/build/yui/yui-min.js"></script>
<script>
YUI().use('oop', function(Y){
  // your code goes here
  // Y is the YUI instance
});
</script>

(pseudo)Classical inheritance

You can call this pattern “classical” not because it comes from Plato’s ancient Greece, but because it helps you think in terms of classes. JavaScript doesn’t have classes (hence the “pseudo” part), but it has constructor functions instead.

In Java or other languages you can have a Programmer class inherit from a Person class. In JavaScript, you’ll actually have a Programmer constructor function and a Person constructor function. The goal is to have objects created with the Programmer constructor inherit properties and methods as if they were created with the Person constructor.

Consider these two constructors:

// parent
function Person() {
  // "own" members
  this.name = "Adam";
}

// properties of the parent's prototype
Person.prototype.getName = function() {
  return this.name;
};

// child constructor
function Programmer(){}

YUI 3’s oop module offers the Y.extend(...) method to help you with the inheritance part. It’s as simple as:

Y.extend(Programmer, Person);

Then you can test that the getName() method was properly inherited:

var guru = new Programmer();
alert(typeof guru.getName); // "function"

Note that the Y.extend(...) method will only inherit members of the prototype, not “own” members. It is considered a good practice to add all the reusable functionality to the prototype and leave all instance-specific properties as own properties (added to this). In the example above, only getName() gets inherited, while name does not. (In the prototypal inheritance pattern – discussed further in the article – you inherit both prototype and own members.)

Extend and augment

Y.extend(...) allows you to inherit from a parent constructor and at the same time augment the child with new members. This is actually the de facto pattern used by YUI to build “class” extensions.

You can add properties to the prototype of the child constructor using the third parameter to Y.extend(...) and you can add properties to the constructor itself (class static properties) using the fourth parameter.

Here’s an example of extending and augmenting at the same time:

Y.extend(Programmer, Person, {groksHTML: true}, {LIMIT: "sky"});

// groksHTML is now a property of the child's prototype
alert(typeof Programmer.prototype.groksHTML); // "boolean"

// the property works for all new objects
var bob = new Programmer();
alert(bob.groksHTML); // true

// adding to the constructor is more for
// "static" properties meant to act as constants
alert(Programmer.LIMIT); // "sky"
var limit = bob.LIMIT; // undefined

Superclass

The pseudoclassical pattern described above gives you access to the prototype of the parent’s constructor via the static property called superclass.

superclass points to the prototype of the parent and so superclass.constructor points to the parent constructor function. Consider an example:

// inherit
Y.extend(Programmer, Person);

// child's access to the parent constructor
var parent = Programmer.superclass.constructor;
// test
alert(parent === Person); // true

// access to the parent from an instance of the child
var guru = new Programmer();
guru.constructor.superclass.constructor === Person; // true

As noted earlier, with the classical pattern you only inherit prototype members. But using the superclass you can also initialize the parent constructor from the child and get the parent’s own properties as the child’s own properties.

You can modify the Programmer constructor to call the parent constructor, passing the child object (this) and any initialization arguments

// ... parent definition same as shown before...

// child
function Programmer() {
  // initialize the parent using the child as "this"
  Programmer.superclass.constructor.apply(this, arguments);
}

// inheritance
Y.extend(Programmer, Person);

// test
var pro = new Programmer();
alert(pro.name); // "Adam"

As you can see, the programmer instances now have a name property and it’s an own property.

  alert(pro.hasOwnProperty('name')); // true
  alert(pro.hasOwnProperty('getName')); // false

Access to overridden methods

The fact that superclass points to the prototype of the parent lets the child gain access to overridden methods. Consider this classic example of Triangle that inherits Shape:

// parent
function Shape(){}
Shape.prototype.toString = function() {
  return "shape";
};

// child
function Triangle(){}

// inheritance
Y.extend(Triangle, Shape);

// child overrides the parent's toString() method
// but thanks to the superclass property
// it still has access to the original method
Triangle.prototype.toString = function(){
  return Triangle.superclass.toString() + ", triangle";
};

// test
var acute = new Triangle();
acute.toString(); "shape, triangle"

Prototypal inheritance

Douglas Crockford suggests this inheritance pattern, where you forget all about classes and have your objects inherit from other objects. For example:

// parent object, created with a simple object literal
var parent = {
  name: "John",
  family: "Wayne",
  say: function() {
    return "I am " + this.name + " " + this.family;
  }
};

// the inheritance magic
// a new object is born from an existing one
var batman = Y.Object(parent);

// customize or augment the new object
batman.name = "Bruce";

// use
batman.say(); // I am Bruce Wayne

Using this pattern there are two steps in setting up your objects:

  1. You create a new object inheriting all the properties and methods from an existing object.
  2. You customize the new object – you can overwrite some of the members or add brand new ones.

Note that Y.Object(...) is available in the YUI core. You don’t need to include the oop module.

Prototypal inheritance discussion

If you’re curious about the motivation behind the prototypal inheritance and how it works under the hood, you can study the pattern described in Douglas Crockford’s own words.

Using this pattern, the parent’s members are inherited via the prototype chain. That means that if you add a property with the same name to the child, the new property will not overwrite the one inherited from the parent, but it will take precedence. In other words, you can redefine the say method like so:

batman.say = function() {
  return "Can't tell you my real name";
};

// test
batman.say(); // "Can't tell you my real name"

Unlike in the classical inheritance model afforded by Y.extend, there is no way to reference the parent’s say method from the child object’s say (vis. superclass). However, if you delete the say method of the child object, the parent’s say will “shine through”.

delete batman.say;
batman.say(); // "I am Bruce Wayne"

In ECMAScript 5

The new edition of the ECMAScript standard includes the prototypal inheritance pattern through a native method called Object.create(...).

// YUI3
var batman = Y.Object(parent);

// ECMAScript 5 (future)
var batman = Object.create(parent);

More?

Thanks very much for reading! For more information and examples of the two patterns discussed in this article, you can consult these links:

Stay tuned for a follow-up article that discusses even more code reuse patterns in YUI3.

 

​A new year, new mobile features, and more!

5:58 pm - January 5, 2010 in Official Google Reader Blog
Posted by Arif Siddiquee, Software Engineer ​

We know that many of you like to take Reader with you wherever you go, so today we are updating our mobile interface by adding a few new features along with a new streamlined look.

New mobile features include support for "liking", tagging, and sorting feeds by oldest/newest. These are all features that were previously only available on the web interface, and we’ve worked to get them into the mobile version as quickly as possible.

As far as streamlining goes, we’ve made a few improvements to give you more features with less clutter. First, we redesigned the bottom action bar to include a “More” link, revealing additional options (with the most common actions selected by default).



We’ve also updated the main header to be consistent with other Google mobile applications, specifically Gmail, Calendar, and Latitude. And we’ve added an option drop-down in place of the old secondary tool bar, to give you a little more space for your feed items. We hope this also reduces those accidental “mark as read” accidents that happen on occasion.



On Reader's web interface, we've made it easier to find people who are sharing stuff similar to you. Take a peek at the new people recommendations (in the “Recomended sources” section on the web interface) to find folks with shared items we think you’ll enjoy. It's a nifty way to discover new feeds and people that you might not have discovered otherwise.



As always, we listen to your feedback and use it to improve Reader. If there are specific features you miss on the mobile version of Google Reader, head over to our Product Ideas page and leave us a note. We love all kinds of feedback through our official help forums and our Twitter account.

 

Microsoft Joins W3C SVG Working Group

5:10 pm - January 5, 2010 in IEBlog

As a part of Microsoft’s continued commitment to interoperability and standards support, yesterday we submitted our request to join the Scalable Vector Graphics (SVG) Working Group of the World Wide Web Consortium (W3C). We’re excited to take part in ensuring future versions of the SVG spec will meet the needs of developers and end users.

As stated on its Web site, “the mission of the SVG Working Group is to continue the evolution of Scalable Vector Graphics as a format and a platform, and enhance the adoption and usability of SVG in combination with other technologies.” We recognize that vector graphics are an important component of the next generation Web platform. As evidenced by our ongoing involvement in W3C working groups, we are committed to participating in the standards process to help ensure a healthy future for the Web. Our involvement with the SVG working group builds on that commitment.

To date, I have had several interactions with the SVG working group, and their clear dedication to creating a great technology for end users and developers alike stands out.  I personally look forward to future and more direct involvement with this great set of folks.

Patrick Dengler
Senior Program Manager
Internet Explorer Team

 

Crockford delivering “State and Future of JavaScript” talk at ACCU in Mountain View on January 13

1:46 pm - January 5, 2010 in Yahoo! User Interface Blog

Crockford at ACCU on January 13.

Douglas Crockford will be reprising his lecture on “The State and Future of JavaScript” at the next ACCU gathering in Mountain View on January 13. The event is free and open to the public; Symantec is hosting the event on its Mountain View campus.

Yahoo is also hosting a public lecture series, Crockford on JavaScript, beginning this month — also free to the public (RSVP required).

 
 
 
 
 
 
It's All About Search | © clsc.net |
2012.02.0715:54
Tech used here: Valid HTML - Valid CSS - Valid RSS - JavaScript - PHP - Smarty - MySQL - and a partridge in a pear tree.