Tuesday 31 March 2009
Facebook StumbleUpon Twitter Google+ Pin It

Google Narratives Series: BuddyPoke

Continuing with the Google Narratives Series, we'd like to profile Google App Engine and OpenSocial developers, Dave Westwood and Randall Ho of BuddyPoke!

Dave and Randall both have backgrounds in 3D and avatars for the last 11+ years, with work in various web 3D games, facial tracking, facial animation, and mobile avatars. They've worked at five companies together - "Dave does all the technical stuff and I'm the technical artist." Simply put, they complement each other perfectly.

Q: Tell us the story of how BuddyPoke was envisioned.

A: We'd always worked for other companies, and disliked the company politics, etc, and always dreamed of just going and doing our own thing. When we saw the huge success of Slide's slide shows on MySpace, we quit our jobs and started work on a 3D pets widget. Facebook apps and OpenSocial weren't live yet and our first project failed miserably because we completely lacked a distribution model with viral channels. Fast forward a bit, and Nintendo Wii is huge with everyone making miis and talking about avatars. There was Playstation Home and Second Life. Also, the Simpsons Movie was just about to released and allowed for you to "Simsponize" yourself. We thought about the 30+ minutes people were putting into customizing their avatars, without any way of doing any cool interaction with friends. We also thought about the interesting fact that most people who installed these types of console games did it mostly for character personalization or "dress up," rather than to actually play the game. Bottom line, we knew we had to do something about it.

Facebook apps then started to take off, and OpenSocial came out. We closely watched what worked and what didn't on Facebook by looking at usage charts of the top 200 apps. After a lot of trial and error, we applied our 3D backgrounds to some of the ideas and came up with a way of doing the 3D rendering in Flash. That's when we came up with BuddyPoke.

Q: Describe your implementation and why you decided on Google App Engine.

A: During the time that we were focused on researching app usage, we noticed that most apps were struggling with scalability. Their difficulties sounded vaguely familiar with our current implementation and we knew we needed to find a platform that would help us avoid the same issue, especially since we were working on the version for MySpace. The main thing here was timing with the release of Google App Engine and the announcement of OpenSocial. All of a sudden we found ourselves able to quickly roll out our app to the various OpenSocial sites without having to worry about scaling.

Q: Tell us about your overall development experience and any obstacles you have encountered along the way.

A: When Google App Engine first came out, the big learning curve was BigTable. Our data models were horrible. Then, after watching Ryan and Brett's talks at I/O, we redid everything and it's running well now. Our only concern is the organization of our code on AppSpot - everything runs on one AppSpot site. If we knew ahead of time of our success, we would have broken the code up in groups to make updating easier. Also, our main ask is XMPP support so that we can implement chat on App Engine.

One last thing...we're thrilled about the success of BuddyPoke. The barrier to entry is so low from a developer's perspective. We never imagined having 3D characters seen by so many people, without having to even think about the technology behind them or without even having to buy a Wii.

We really enjoy hearing from developers in the community about inspiring stories, so if you have something you'd like to share, visit our online submission form. Better yet, come tell us your story at Google I/O. You can also check out Dave & Randall's cool story on the Ning blog!

Thanks Dave & Randall!

Monday 30 March 2009
Facebook StumbleUpon Twitter Google+ Pin It

Code Conversations Ep. 3 - Leslie Hawthorn on Google Summer of Code 2009

Google Summer of Code™ is a global program that offers student developers stipends to write code for various open source software projects. We have worked with several open source, free software, and technology-related groups to identify and fund several projects over a three month period. Since its inception in 2005, the program has brought together nearly 2500 successful student participants and 2500 mentors from 98 countries worldwide, all for the love of code. Stephanie Liu of the Developer Programs team sat down with Leslie to understand the history of the program, hear some of the many success stories and find out what's new for SoC 2009.




Leslie Hawthorn is a Program Manager for Google's Open Source Programs Office, where she's the Community Manager for Google Summer of Code. She serves on the Advisory Board of the GNOME Foundation and the Open Source Business Resource, as well as the Steering Committee for the Humanitarian FOSS Project. Her personal website is http://www.hawthornlandings.org.

This is the third episode in the "Code Conversations" video series on YouTube and Google Code. You can view the entire series at this link: http://www.youtube.com/view_play_list?p=633DD2FE10E46955

Thursday 26 March 2009
Facebook StumbleUpon Twitter Google+ Pin It

Custom Logos for Open Source Projects

Open source projects now have customizable logos! You can use this to maintain consistency with your other websites or just for fun. Here's an example of a project with its own logo. To update the logo on your project, click on the Administer tab (as long as you're a project owner) and upload an image. It will automatically be resized. You can switch back the default logo or upload a new logo at any point.

Google projects such as Chromium will retain the large Google logo.

For other notable changes, see our groups post.

Tuesday 24 March 2009
Facebook StumbleUpon Twitter Google+ Pin It

Toward an open web standard for 3D graphics

For years, developers have tried to create rich 3D experiences on the web. However, the lack of a common way to render 3D graphics in the browser has forced them to use workarounds like special purpose plugins or software rendering frameworks. As a result, web users have generally experienced lower quality graphics compared to what can be found in today's desktop apps.

This is why Google is excited about the "Accelerated 3D graphics for the web" initiative by the Khronos Group and the Mozilla Foundation. As Javascript is becoming faster every day, we believe that it is time to create a general purpose API for 3D graphics on the web to allow developers to create compelling 3D applications in the browser. Khronos's initiative to develop a new, open web standard for high performance 3D graphics is a promising step in that direction. Google plans to contribute technology and web development expertise to the discussion within Khronos and the broader development community. As an active contributor to Khronos, Google would also like to encourage other technology companies to join Khronos in this effort and embrace a project that promises to move the web forward.

Friday 20 March 2009
Facebook StumbleUpon Twitter Google+ Pin It

Improvements to Google Checkout Module for osCommerce

At Google Checkout, we're constantly striving to improve our usability. That's why we've recently simplified and improved the installation and configuration process for the osCommerce Google Checkout module. osCommerce is a popular open-source e-commerce solution and the module is an open-source project hosted on code.google.com.

We've completely reworked the installation process by no longer requiring users to manually copy and paste large swaths of PHP code into their files. Instead, we've created an automated deployment app (shown below) that does this for you. This should ease concerns about lines of PHP getting copied into the wrong place. If you want to learn more about the installation process, you can take a look at our documentation, which contains a step-by-step walkthrough with screenshots showing exactly how it works.


For more details, check out our post on the Checkout blog. We're excited about the improvements to the osCommerce Checkout module. If you're using osCommerce, we invite you to give Checkout a try and share your feedback with us.

Wednesday 18 March 2009
Facebook StumbleUpon Twitter Google+ Pin It

Monster Mesh - A Google Chrome Experiment

Over the past year or so, my contributions to Google Chrome have mostly been behind the scenes: improving our base libraries, security, stability, and performance. But recently, I made an addition to Chrome Experiments, a site we just launched today. With the Monster experiment I had a chance to step back from working deep within Google Chrome's C++ code, and give my right brain a little exercise.

Since web browsers don't currently support native 3D graphics, the basis for my experiment is a custom 3D rendering engine written in JavaScript. It uses some pretty intense numerical computations to project the 3D shapes into a 2D image, like your eye would. These are then drawn to the screen using the HTML5 canvas element. This process is a similar concept to early 3D game engines, before accelerating graphics cards handled the work.

JavaScript wasn't originally designed with intensive mathematical computation in mind; the real trick is not in writing the engine, but making it perform well in the high-level language running in your browser.

Compared to creating the 3D model beforehand and embedding the data in the application, Monster creates the mesh using software algorithms in real time while the demo runs. This has some nice advantages like decreasing download time, but it requires even more processing power to draw every frame.

Here's what it looks like in action:



The demo starts with a simple cube, but as it progresses, the cube is smoothed and pulled apart to become exponentially more complex. The values used in these operations are varied over time, creating an animation that brings the monster to life. Anytime during the demo you can hit 'p' to pause, and explore the scene with your mouse. With a bit of careful programming (ok, a lot) and the performance of V8, it's possible to do all this work and still generate smooth and consistent graphics.

So give it a try and take a look through the other Chrome Experiments on the Google Chrome Blog. If you've made something interesting with JavaScript please submit it, too. We'll be highlighting more experiments and holding sessions Google Chrome at Google I/O on May 27 - 28 in San Francisco.

Updated GoogleBar features new UI and targeted sponsored results



The GoogleBar, a control in the Maps API to allow users to search the map for local businesses, landmarks and points of interest, has just launched a new version. In addition to a greatly improved UI, the new GoogleBar includes advertising targeted to the user's searches. This new feature will improve the user experience by providing targeted and relevant sponsored results, and you can benefit by sharing in the revenue of including these results on your site. You can see the new GoogleBar, together with ads, below:


As shown above, the new version of the GoogleBar contains advertising. Profiting from the advertising personally is as easy as signing up for an AdSense account and including your AdSense publisher ID when you create the GoogleBar. See the recent Maps API Blog post for details. Whether you already have a map on your webpage or not, it only takes a few lines of code to embed a fully searchable map into your site - the GoogleBar documentation will tell you everything you need to know.

The GoogleBar is built upon our low-level Local Search Control. For those interested in peeking under the covers, check out the Local Search Control documentation and Code Playground examples.

Questions or comments? Please visit the AJAX API and Maps API discussion groups.

Tuesday 17 March 2009
Facebook StumbleUpon Twitter Google+ Pin It

Google Narratives Series

By Christine Songco, Google Developer Programs

Google Code has highlighted many developers who've created applications using AppEngine, OpenSocial, AdSense, and Google Maps, however, we often forget to reflect on the stories of the people behind the code. In a series of upcoming blog posts we're calling Google Narratives, we'll be telling these stories to allow our developer community to interact and inspire each other to create or even improve existing projects. At last year's Google I/O, we met Dan Shahin of Hijinx Comics, whose creativity in using open source projects to build his business really makes him stand out. Dan agreed to chat with us and share his story. Thanks, Dan!

The story of Dan and how he came to own a comic book store.

At 28 years running, Hijinx Comics, is the oldest comic book store in San Jose, California. From both a personal and business perspective, Hijinx Comics holds a special place in Dan Shahin's life. At the early age of 11, Dan was hired at Hijinx, which was at the same location at the time but went by a different name. Dan continued to work there throughout high school, building his lifelong passion for comics. He left the comic store behind to attend college and later worked at a number of high tech jobs, gaining experience in UNIX systems administration, release management, and software engineering. But by the year 2000, still Dan couldn't shake the feeling that something was missing in his life. Hours of soul-searching revealed that the missing piece was the excitement and passion that he had once experienced when working with comics.

Dan decided to get in touch with the owner of the comic book store. It turned out to be perfect timing because the owner of the store was ready to sell. Dan picked up everything he owned and moved back to his old neighborhood to run the comic book store. He reopened the store as Hijinx Comics and expanded on the traditional business of collectible comics and novelty items with a new focus on graphic novels and books focused on entertainment reading.

Because of the amount of time Dan had worked with comics as a teenager, he had keen awareness of the pain points related to subscriptions and inventory. Drawing on these experiences, he developed a software suite to manage the subscriptions and inventory of his shop and of a brand new online bookstore. Best of all, he opensourced the whole offering to help other comic book stores alleviate the same issues. From there, a side business grew that involved him consulting and implementing a management system and hosting solution to other comic book stores across the nation.

Today, Dan's working on Ver.2 of his project while Ver.1 runs his current business needs. Below are some excerpts from our meeting with Dan.

Q: Tell me about your Google implementation and if there were any obstacles.

A:
I use a lot of Google Code products to build my own open source comic shop management system. I use Google Checkout for my online bookstore ( http://www.comicbookshelf.com ) and did the level 2 integration myself in my custom LAMP application. I also make heavy use of Google Analytics [used to compare data from his own raw server logs], Charts API, Apps for Domains and thanks to last year's I/O, I'm getting into App Engine development as well as Gears, which is what really brought me to Google I/O. My web-based point of sale system uses all of the Gears APIs to bring down UI latency and to allow offline use, which are the two greatest sticking points to current adoption of similar systems. The documentation is well-written with one exception. It would be nice to have a cookbook section - that type is more helpful. More real-life examples in more detail, casual, reader friendly and a commonly used code section. They tend to have lots of detail and the high level can sometimes be fuzzy


Q: What effect have you seen with your customers as a result of the Google implementation?

A: Customers usually come to visit the store but can also log in and update their subscriptions on their own. There's a quicker checkout process since they do the rest of their browsing online. We have a book club where we collect email addresses for customers that buy certain novels online. Customers are also able to offer reviews or books we sell. These reviews are available both online and in the store. We keep track of this type of data in a CRM and based on it, can help recommend favorites and offer Netflix type suggestions.
We're excited to kick off the Google Narratives Series and plan to highlight more developers in our community so if you have a story like Dan's that you'd like to share with us, we're accepting submissions via our online submission form. Better yet, come tell us your story at Google I/O!

Thursday 12 March 2009
Facebook StumbleUpon Twitter Google+ Pin It

Google Friend Connect API Available in Labs



Today we are excited to make the Google Friend Connect API available to developers. Google Friend Connect lets a site owner instantly awaken and strengthen the community that visits their web site.

Friend Connect has enabled tens of thousands of sites like naturalnews.com, and millions of blogs like paulocoelhoblog.com, to build their communities. Now, we are pleased to open up the service to the broader development community. With Google Friend Connect, two of our primary goals are to:
  • Make it easy for every site owner to add Friend Connect to their site, regardless of their technical capabilities. We do this by letting site owners simply paste snippets of code into their websites' HTML to instantly provide social capabilities on their sites.

  • Be open by letting visitors control their own data and freely share it with sites and services as they see fit. Services that are currently integrated with Friend Connect include OpenID providers like Yahoo!, social network providers like Twitter, and update aggregators like Plaxo Pulse.

The combination of ease and openness puts visitors and site owners in full control of their social information, activities, and relationships throughout the web. As a developer, the Labs release of our API lets you:
  • Use JavaScript APIs to integrate social flows and data directly within your page's markup, via the OpenSocial standard specification.

  • Use REST APIs to integrate your existing login systems, registered users, and your existing data with new social data and activities. These APIs are also part of the OpenSocial standard.

In addition, we have used the APIs to build open source plugin samples that integrate into popular commenting and content systems including WordPress, Drupal, and phpBB.

This release is documented in code.google.com. To take advantage of the the API on your site, go to www.google.com/friendconnect and visit the "for developers" section to grab the snippet that enables the new API on your site.



We're looking forward to hearing your feedback, and to seeing how the development community will combine their creativity, Google Friend Connect, and these APIs to enrich the open social web. Make sure to check out Google I/O on May 27 - 28 where you can meet the engineering team and learn more about the Google Friend Connect API.

Wednesday 11 March 2009
Facebook StumbleUpon Twitter Google+ Pin It

Code Conversations Episode 2 - Kevin Marks with Brad Neuberg



A few weeks ago, Brad Neuberg sat down with Kevin Marks for an informal chat about technology, live video, the changes in software development over the last decade and OpenSocial. The video below is an edited version of their conversation, but if that only serves to whet your appetite, you can view the full version here (Part 1, Part 2). Be sure to look for the part in the video where Kevin talks about what it was like to work with Douglas Adams.



Intros:

Kevin Marks is the author of the popular blog Epeus Epigone. In his 20-year long career, he played a major role in the development of live streaming video as a member of the Quicktime team at Apple, founded the Multimedia Corporation and as Principal Engineer at Technorati, built the spiders that make sense of the web and track millions of blogs daily. Today, in addition to being a developer advocate for OpenSocial, he is also one of the co-founders and a driving force for Microformats.

Brad Neuberg is a developer advocate at Google for the Open Web. He has created a number of libraries and frameworks for expanding the capabilities of web applications and is a core member of the Dojo project. He blogs at codinginparadise.org.

This video is the second in our video series "Code Conversations". You can view the first episode, a conversation with Chris DiBona on open source software here.

Tuesday 10 March 2009
Facebook StumbleUpon Twitter Google+ Pin It

Steve Souders: Life's Too Short, Write Fast Code (part 2)

By Steve Souders, Member of Technical Staff

I've been working on a follow-up book to High Performance Web Sites called Even Faster Web Sites. As I finish chapters, I talk about the findings at conferences and tech talks. The first three chapters are Split the Initial Payload, Load Scripts Without Blocking, and Don't Scatter Inline Scripts. You can hear about those best practices in my video from Google I/O.

This talk presents the next three chapters: Couple Asynchronous Scripts, Use Iframes Sparingly, and Flush the Document Early.

The adoption of JavaScript is growing, but the blocking behavior of external scripts is well known. That's why it's important to use one of the techniques to load scripts without blocking (see the Google I/O talk). But loading scripts asynchronously means that inlined code that uses symbols from the script must be coupled in some way. Without this coupling, undefined symbol errors occur when the inlined code is executed before the external script arrives.

There are five techniques for coupling asynchronous scripts: hardcoded callback, window onload, timer, script onload, and degrading script tags. All of the techniques work. Degrading scripts tags is the most elegant, but isn't well known. Script onload is the most versatile technique and is the one I recommend people use. In the talk, I then go into detail, including many code examples, on how to load scripts asynchronously and use these coupling techniques to speed up your web page.

Iframes have a negative impact on web pages. They are the most expensive DOM element to create. They block the parent's onload event (although there's a workaround to this problem in Safari and Chrome). Also, the main page can block resources in the iframe. It's important to understand these interactions if you use iframes in your page.

Flushing the document early allows the browser to start rendering the page and downloading resources in the page, even before the entire HTML document has arrived. But getting flushing to work can feel like trying to get the stars to align. You need to understand PHP's output_buffering, HTTP/1.1's chunked encoding, Apache's DeflateBufferSize, the impact of proxies, minimum HTML size requirements in Safari and Chrome, and the need for domain sharding to avoid having the HTML document block other downloads.

If your company wants a better user experience, increased revenues, and reduced operating costs, the key is to create even faster web sites. For more information on these best practices, watch the video below and read the slides.



Check out other talks in this tech speaker series:

Monday 9 March 2009
Facebook StumbleUpon Twitter Google+ Pin It

Now Accepting Applications for Google Summer of Code 2009



Google Summer of CodeTM, our flagship program to introduce college students to open source development, opens today. Over the past four years, we've seen nearly 2,500 successful students "graduate" from the program, and we're looking forward to welcoming another group of students for our fifth year. We're now accepting applications from open source projects who wish to act as mentoring organizations and will begin accepting applications from students on March 23rd. For more details, check out the Google Open Source Blog.

Thursday 5 March 2009
Facebook StumbleUpon Twitter Google+ Pin It

Code Conversations Episode 1 - Chris DiBona on Google's Open Source Programs



"Code Conversations" is a new series of videos intended to film casual conversations with notable Google developers and legends in the technology field. No agenda, no topic... just thoughts. This video is the first episode of this series, in which Chris DiBona, our intrepid open source programs manager talks to Stephanie Liu of the Developer Team about his "sweet goatee" in the Chrome Comic. He also explains why Google open sourced Chrome and Android and why we didn't do it sooner. He also touches on why much of Google's software isn't open sourced.

Intros:

Chris DiBona is the open source programs manager at Google, where his team oversees license compliance and supports the open source developer community through the release of open source software projects and programs such as the Google Summer of Code. Before joining Google, Chris was an editor at Slashdot, has edited the books Open Sources: Voices from the Open Source Revolution and Open Sources 2.0: The Continuing Evolution and formerly co-hosted the FLOSS weekly with Leo Laporte. His personal blog is called Ego Food.

Stephanie Liu is a Programs Manager on the Developer Team here at Google.



We'll be checking your comments on this post for feedback and ideas for future Code Conversations.

Wednesday 4 March 2009
Facebook StumbleUpon Twitter Google+ Pin It

Google Code University: New Materials and SIGCSE



With SIGCSE kicking off today, we are happy to announce that we pushed a small - but fresh - addition of course materials to Google Code University, a growing repository of open access Computer Science materials. With the credit belonging to Berkeley and UC San Diego, there are now more Distributed Systems materials available which complement some of the other CS resources. As usual, the materials are Creative Commons licensed allowing adaptations and modifications to fit new course designs.

We'll also be participating and presenting at SIGCSE, so be sure to chat with us if you'd like to contribute course materials, or you're welcome to discuss in the forum.

Tuesday 3 March 2009
Facebook StumbleUpon Twitter Google+ Pin It

Introducing Labs for Google Code



As Google's developer program continues to grow -- already over 60 APIs and tools on Google Code today -- we credit much of this growth to a culture of exploration and rapid iteration, and to the invaluable feedback and insights we receive from you about each product as it evolves.

Reflecting this culture, we're pleased to introduce Google Code Labs today as a home for developer products still in their early stages of development. Our hope, of course, is that all of our developer products grow up to be huge successes, but we realize that not every single one will reach that goal. The Labs program offers engineering teams at Google and the developer community a chance to explore ideas and get involved early.

With that background, we're also announcing that several of our best-known and most-used APIs and tools are among the first set of Google Code Labs "graduates" -- including App Engine, Google Web Toolkit, AJAX Search API, Maps API, Earth API, Calendar Data API, YouTube APIs, and more. See the full list of graduates on the Google Code Labs page.

For these graduates, we're increasing our commitment with published deprecation policies and other critical support services. The Visualization API terms, Contacts Data API terms, and Picasa Web Albums Data API terms include good examples of transparent deprecation policies. They state that we'll support each version for at least 3 years from when it's deprecated or a newer version is introduced. We're working to get policies posted for the other graduates as well, though the time period may vary a bit from product to product. It will be 3 years for most, but it might be less for some. The AdWords API, for example, has a policy of supporting old versions for 4 months.

Of course, even established products need a way to experiment with new features. With that in mind, some products will have features labeled "experimental" that could change (or even be removed) at any time, while the rest of the API is covered by a deprecation policy with long-term support.

There are additional hurdles for an API to graduate from Labs. They include requirements like having a dedicated, ongoing engineering team and comprehensive test suite. We also want to do things like the App Engine System Status Dashboard for more products.

Finally, we'd like to bid a fond adieu to one of our first developer products, the venerable SOAP Search API. It has been deprecated since 2006, when we stopped accepting new developers for the API, and it's finally hanging up the gloves and retiring on August 31st. It has been steadily declining in usage over the last couple years and we believe that the majority of use cases are sufficiently handled by the more comprehensive AJAX Search API (which supports not only web search, but local, news, images, video, and more). For those interested in migrating, there are more details in the AJAX APIs blog.

Thank you for making the past five-plus years such a success. We look forward to doing great things together with Google Code Labs and we hope you'll join us in congratulating the new graduates.

Monday 2 March 2009
Facebook StumbleUpon Twitter Google+ Pin It

Doug Crockford: JavaScript: The Good Parts

By Steve Souders, Member of Technical Staff

Doug Crockford, from "The Yahoo!" (his words), gave a talk at "The Google" (again, his words) last week. The talk is based on his recent book of the same name, JavaScript: The Good Parts. Doug is a, perhaps the, JavaScript guru who has undertaken responsibility for helping the world's web developers embrace JavaScript and use it successfully to build clean, fast web applications. He is the creator of JSLint, JSMin, and JSON. (Notice a theme?)

Doug was hitting on all cylinders. I've heard him deliver this talk before, but this rendition was off the scale in terms of clarity, humor, and takeaways. He flowed effortlessly from broad observations to detail-oriented code samples.

He begins with the observation that JavaScript is one of today's most used languages, so it obviously has gotten something right. Despite this success, JavaScript has plenty of bad parts: global variables, semicolon insertion, with and eval, and more. There's confusion with false values. Consider this example:
'' == 0
0 == '0'
'' != '0'
In JavaScript, all three of these statements return true. Doug highlights other traps that are easy to fall into using for..in, ++, and typeof.

He delivers a clear, concise tutorial on object-oriented JavaScript and closures. The most satisfying piece to me was his clear explanation of why right-curlies ("block {" all on the same line) is the only acceptable style in JavaScript.

Tune in to the video below, and follow along with the presentation. It's enjoyable and enlightening. What a great combination. Thanks, Doug!