MatrixAdapt | Logiciel de gestion d'Entreprise, Création et référencement des sites web

Seo Master present to you:
By Eduard Sánchez of Code Factory

This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.


For the last 8 years we at Code Factory have been making software that helps the blind and the visually impaired access their mobile phones. We’ve created this software for several different platforms. Last year we decided it was time to start doing something for the Android platform, due to its growing popularity and variety of devices.

From our past experience, developing a screen reader for a new platform required a lot of work, hacks, and investigation. Almost none of the previous platforms we supported implemented any sort of Accessibility API that we could use. Android, we thought, would be no exception to this rule. We were very wrong.

Starting at version 1.6, the Android operating system comes with a built-in Accessibility API that makes our application a lot easier to develop. All you do is create a service, which implements the AccessibilityService interface, declare it in your manifest and voilà! The system will start sending events, such as button presses, list navigation, focus changes, etc. to your service. You then convert this information to voice using a Text-to-Speech engine, and you have a screen reader.

The Accessibility API is not yet as complete as what you can find on a desktop PC, but it's good enough to provide the users with basic user interface navigation, and we have no doubt that, as the Android platform evolves, so will the built-in Accessibility API.

We also wanted our application to go beyond a screen reader and provide an intuitive, easy-to-use UI that allowed the blind and visually impaired access to most of the phone's functionality, such as messaging, web browsing, contact management, and so on.


We were pleased to see that we could do this Android. The existing set of UI controls, such as buttons and lists, can be overridden in order to provide custom functionality, such as speaking the text of the control. This made it possible for us to keep the user interface of our application consistent with Android, while at the same time providing the speech feedback that our users require.

By intercepting touch events within our application and using the gesture detectors that Android provides to developers, we were also able to make the touch screen accessible to our users, so they can use gestures like swipes to move through items of lists, or double-taps to activate items.

We really like how much we can accomplish with Android with so little code. Want to let a blind person create an SMS or email using voice? Simply use the SpeechRecognizer class. Want blind users who are walking on the street to know their exact location? Just use the LocationManager and Geocoder classes to give their exact street name and number.

Android lets us do a lot in a very efficient way. It wraps a whole bunch of cool technology into well-defined classes and interfaces. And if at any given time you need to know how something works behind the scenes, you just take a look at the source code, which is freely available to everyone.

We just can't wait to do more on this platform.


Come see Code Factory in the Developer Sandbox at Google I/O on May 10-11.

A pioneer in assistive technology for mobile phones, Eduard Sánchez is the brain behind all Code Factory software applications. His greatest satisfaction is to use his passion for programming to make a positive difference in the lives of people with disabilities.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:
By Eddie Chan, Software Engineer at Elastic Path Software

This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.


Elastic Path develops a very flexible enterprise ecommerce platform. Many global brands rely on the Elastic Path platform to power their ecommerce solutions.

Many ecommerce sites are actually complex web applications. Catalog management, shopping cart functionality, promotion engine, order fulfillment, and backend integrations are just some of the challenges involved in running a full-fledged online store.

Since 2008, our Java-based platform has been the ecommerce backbone of a couple of online stores that are being migrated to run on App Engine. Like many complex web applications, these stores used to run in a multi-server environment (Apache Tomcat with a MySQL database) hosted in a colocation center.


As the diagram above shows, our goal is to have Elastic Path running entirely on the App Engine cloud. The storefronts have already been migrated, and the database and remaining parts of the Elastic Path platform will be fully on the cloud soon.

Why are we doing this? There are many benefits to being on App Engine:

• Increased security
• Easier deployments and operations
• Scalability
• Cost-effectiveness
• Built-in monitoring

We can only undergo this migration because App Engine supports enterprise-grade Java applications, and because Elastic Path is very flexible.

Our migration’s high-level approach was to move everything except the persistence layer onto App Engine, and then resolve issues with the technical limitations such as the class whitelist and request length. We also had to modify some third-party libraries to work around App Engine’s restrictions on operations such as class loading, threads, and sockets.

We didn’t migrate the persistence layer because Elastic Path uses a relational database; converting our entire object graph to the Datastore is not feasible now. We are working closely with Google on alternatives. In the interim, we are still using a MySQL database and have kept our persistence layer running within a Tomcat application in the colo. We implemented a creative solution: the non-persistence layers of Elastic Path run on App Engine and communicate with the Tomcat-hosted persistence services via Spring Remoting. The back-and-forth remoting was expensive and impacted the performance of our application so we implemented some data caching. For this, we turned to App Engine’s Memcache, which improved performance by an order of magnitude (less than 2 seconds average response times vs. 2 minutes or more without Memcache).

Other App Engine technologies we use heavily include AppStats for performance tuning, URL Fetch for the Spring Remoting described above, and the fantastic Maven GAE plugin that we use for packaging and automated deployments. As we continue to push our platform up to the cloud, we hope to utilize more of App Engine’s cool features. If you’d like to learn more about Elastic Path, how we are migrating our Java platform to run on the cloud, and how you might be able to migrate your application to App Engine, drop by our booth in the App Engine section of the Developer Sandbox. See you there!


Come see Elastic Path Software in the Developer Sandbox at Google I/O on May 10-11.

Eddie Chan is an ecommerce developer at Elastic Path Software in beautiful Vancouver, Canada. He and his brilliant team work closely with Google and are currently focused on migrating existing online stores to App Engine.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:
By Amy Unruh, Developer, Author, Consultant

This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.


Mojo Helpdesk from Metadot is an RDBMS-based Rails application for ticket tracking and management that can handle millions of tickets. We are migrating this application to run on Google App Engine (GAE), Java, and Google Web Toolkit (GWT). We were motivated to make this move because of the application’s need for scalability in data management and request handling, the benefits from access to GAE’s services and administrative tools, and GWT’s support for easy development of a rich application front-end.

In this post, we focus on GAE and share some techniques that have been useful in the migration process.

Task failure management

Our application makes heavy use of the Task Queue service, and must detect and manage tasks that are being retried multiple times but aren’t succeeding. To do this, we extended Deferred, which allows easy task definition and deployment. We defined a new Task abstraction, which implements an extended Deferrable and requires that every Task implement an onFailure method. Our extension of Deferred then terminates a Task permanently if it exceeds a threshold on retries, and calls its onFailure method.

This allows permanent task failure to be reliably exposed as an application-level event, and handled appropriately. (Similar techniques could be used to extend the new official Deferred API).


Appengine-mapreduce

Mojo Helpdesk needs to run many types of batch jobs, and appengine-mapreduce is of great utility. However, we often want to map over a filtered subset of Datastore entities, and our map implementations are JDO-based (to enforce consistent application semantics), so we don’t need low-level Entities prefetched.
 So, we made two extensions to the mapper libraries. First, we support the specification of filters on the mapper’s Datastore sharding and fetch queries, so that a job need not iterate over all the entities of a Kind. Second, our mapper fetch does a keys-only Datastore query; only the keys are provided to the map method, then the full data objects are obtained via JDO. These changes let us run large JDO-based mapreduce jobs with much greater efficiency.

Supporting transaction semantics

The Datastore supports transactions only on entities in the same entity group. Often, operations on multiple entities must be performed atomically, but grouping is infeasible due to the contention that would result. We make heavy use of transactional tasks to circumvent this restriction. (If a task is launched within a transaction, it will be run if and only if the transaction commits). A group of activities performed in this manner – the initiating method and its transactional tasks – can be viewed as a “transactional unit” with shared semantics.

We have made this concept explicit by creating a framework to support definition, invocation, and automatic logging of transactional units. (The Task abstraction above is used to identify cases where a transactional task does not succeed). All Datastore-related application actions – both in RPC methods and "offline" activities like mapreduce – use this framework. This approach has helped to make our application robust, by enforcing application-wide consistency in transaction semantics, and in the process, standardizing the events and logging which feed the app’s workflow systems.


Entity Design

To support join-like functionality, we can exploit multi-valued Entity properties (list properties) and the query support they provide. For example, a Ticket includes a list of associated Tag IDs, and Tag objects include a list of Ticket IDs they’re used with. This lets us very efficiently fetch, for example, all Tickets tagged with a conjunction of keywords, or any Tags that a set of tickets has in common. (We have found the use of "index entities" to be effective in this context). We also store derived counts and categorizations in order to sidestep Datastore restrictions on query formulation.

These patterns have helped us build an app whose components run efficiently and robustly, interacting in a loosely coupled manner.


Come see Mojo Helpdesk in the Developer Sandbox at Google I/O on May 10-11.

Amy (@amygdala) has recently co-authored (with Daniel Guermeur) a book on Google App Engine and GWT application development. She has worked at several startups, in academia, and in industrial R&D labs; consults and does technical training and course development in web technologies; and is a contributor to the @thinkupapp open source project.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:
By Aurelio Tinio of The Bay Citizen

This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.

The Bay Citizen is a nonprofit, nonpartisan news organization dedicated to fact-based, independent reporting of issues in the San Francisco Bay Area. We are interested in visualizing public data that is useful to the local community. One such effort is our Bike Accident Tracker. In this post, I’ll present a simple example of how we used Google Maps and Google Fusion Tables to accomplish this.

This is what our accident map looks like:


Want to add our accident map to your site? Here is the code:

<html style='height: 100%'>
  <head>
    <script type='text/javascript' src='http://maps.google.com/maps/api/js?sensor=false'></script>
    <script type='text/javascript'>
      function initialize() {
        var bc_office = new google.maps.LatLng(37.788901, -122.403806);
        var map = new google.maps.Map(document.getElementById('accident-map'), {
          center: bc_office,
          zoom: 13,
          mapTypeId: google.maps.MapTypeId.ROADMAP
        });
        var accidents_layer = new google.maps.FusionTablesLayer(433634);
        accidents_layer.setMap(map);
      }
    </script>
  </head>
  <body onload='initialize()' style='height: 100%; margin: 0px; padding: 0px'>
    <div id="accident-map" style='height: 100%'></div>
  </body>
</html>

That’s it. To test this yourself, just save the raw file, open the file with a browser and you will have a copy of the accidents map running locally on your computer. The code mainly deals with setting up Google Maps, with one critical line that sets up Fusion Table integration:

var accidents_layer = new google.maps.FusionTablesLayer(433634);

You can expand this integration by filtering the results through the use of Fusion Tables’ sql-like query syntax. As an example, to display accidents from May 2009, change the line above to look like this:

var accidents_layer = new google.maps.FusionTablesLayer(433634, {
  query: 'SELECT FullAddress FROM 433634 WHERE Year=2009 AND Month=5'
});

A quick gotcha to point out here is that Google Maps v3 only supports a SELECT operation on the location value column. So the location query above works just fine, but the COUNT query needed to get the number of accidents does not work:

'SELECT COUNT() FROM 433634 WHERE Year=2009 AND Month=5'

Instead, to get the number of accidents in this case, you can use the Fusion Tables API endpoint directly:

https://www.google.com/fusiontables/api/query?sql=SELECT COUNT() FROM 433634 WHERE Year=2009 AND Month=5

You can see the actual response from the count query here. Because The Bay Citizen is built on the Django framework, we can leverage the Python libraries Google provides for query generation and API calls. Also, since the location query is so similar to the count query, I consolidated the filter logic so it happens on the server side using a jQuery AJAX call. As a result, when users apply a filter, they see an updated map and results bar all thanks to the following few JavaScript lines:

$('#filter-form').ajaxForm({
  success: function(responseText, statusText)  {
    var data = $.parseJSON(responseText);
    accidents_layer.setMap(null);
    accidents_layer = new google.maps.FusionTablesLayer(433634, {
      query: data.map_query});
    accidents_layer.setMap(map);
    $('#filter-results').html(data.results);
  }
});

I was really happy with this approach. The performance hit is negligible, the code is much cleaner, and the filter logic is rewritten in the programming language I currently know best (Python).

I hope this post gives you a taste of what it's like to work with Google Maps and Fusion Tables. Also, please note that our data is public and can be referenced at Table #433634. This means you’re free to use the same data we do to develop and design your own map interface. When we update the data, your project will be updated as well.

From our end, we don't have to worry about our servers being overloaded with data API and map generation calls that come from your project. So by all means, hack away, improve the design, and create a better version. All we ask is that if you do come up with something cool, please link back to us, let us know, and then maybe we can even work together.

For additional details, take a look at the extended post Bike Accident Tracker: A Fusion Powered Map.


Come see The Bay Citizen in the Developer Sandbox at Google I/O on May 10-11.

Aurelio Tinio is a software engineer specifically interested in data journalism and visualization. He enjoys coding, basketball, travelling (not while playing basketball), and meeting new people.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you:

Mike

Fred

By Mike Johnston and Fred Cheng, co-founders, Simperium

This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.


We originally created Simplenote both as a learning exercise and to address what we thought were shortcomings in the original Notes app for the iPhone (Marker Felt font, no ability to search, etc.) The very first version of Simplenote didn't even have syncing!

We've certainly come a long way since then. The Simplenote backend now synchronizes data across devices, the web, and third-party apps while also handling in-app purchases, sharing, and basic metrics. About a year ago, we were accepted to the Y Combinator startup accelerator with something like 20,000 users. Today, with hundreds of thousands of users, we're currently serving 15 million requests daily and providing access to over 500 gigabytes (!) worth of text notes.


Google App Engine is at the heart of it. We made a decision early on to use App Engine so we wouldn't have to worry about scaling, or deploying more servers, or systems administration of any kind. Being able to instantly deploy new versions of code has allowed us to iterate quickly based on feedback we get from our users, and easily test new features in our web app, like the newly added Markdown support.

We consider our syncing capabilities to be core features of Simplenote. They are, in and of themselves, largely responsible for attracting and retaining many of our users. Our goal is to give other developers access to great syncing, too. The next version of our backend is named after our company, Simperium. As a general-purpose, realtime syncing platform intended for third-party use, Simperium's architecture is much more expansive than the Simplenote backend. Yet App Engine still plays a key role. It powers the Simplenote API that is used by dozens of great third-party apps like Notational Velocity. And it continues to power auxiliary systems, like processing payments with Stripe, while bridging effectively with externally hosted systems, like our solution for storing notes as files in the wonderful Dropbox.

We suspected we might outgrow App Engine, but we haven't. Instead, our use of it has evolved along with our needs. Code we wrote for App Engine a year ago continues to hum along today, providing important functionality even as new systems spring up around it.

In fact, we still come up with entirely new ways to use App Engine as well. Just last week we launched an internal system that uses APIs from Twitter, Amazon Web Services, Assistly, and HipChat to pump important business data into our private chat rooms. This was a breeze to write and deploy using App Engine. Such is the mark of a versatile and trustworthy tool: it's the first thing you reach for in your tool belt.


Come see Simperium in the Developer Sandbox at Google I/O on May 10-11.

Mike Johnston was a senior designer and programmer at Irrational Games where he worked on numerous games and prototypes for PC and Xbox 360. Before that he built security software at Entrust.

Fred Cheng hails from Cantaloupe Systems, a venture-backed startup, where he built their infrastructure for wirelessly tracking tens of thousands of vending machines.

Posted by Scott Knaster, Editor

2013, By: Seo Master

Seo Master present to you: By Jereme Monteau, Lead Developer at ShortForm

This post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.


ShortForm is a new entertainment medium where you find continuous channels of the best videos, curated by a growing community of VJs. At ShortForm you can be a viewer, a VJ, or both. Viewers subscribe to channels of interest, lean back, and enjoy a continuous stream of videos.


The developers at ShortForm worked with various YouTube Data APIs in order to deliver both the Viewer and VJ experience.

Standard feeds and user playlists. ShortForm makes it easy and fun for anyone to VJ a channel. We also auto-curate a select set of channels to surface mainstream content that would appeal to most audiences. For example, our YouTube Hits channel includes content from the standard YouTube video feeds such as Top Rated, Most Viewed and Most Popular. ShortForm developed a system for retrieving video entries and their associated metadata, and then ordering them in playlists based on a ranking algorithm.

Favorites and uploads. ShortForm allows VJs to import their YouTube favorites and uploads into their channels quickly and easily by authenticating via YouTube’s OAuth provider. Once a user has connected their ShortForm account to their YouTube account, we are able to allow them to import their favorites and uploads through an authenticated call to the YouTube Data API. In the future we will streamline the process of uploading videos to YouTube by allowing VJs to upload videos to YouTube directly from ShortForm while adding those videos to their ShortForm channel in the same flow.


Player API. Providing a seamless channel viewing experience on ShortForm requires that we integrate tightly with YouTube’s JavaScript API to the ActionScript 3 player. This allows us to properly handle video events to ensure continuous playback. Users have full control over their viewing experience using the next and previous video buttons, which load videos into the YouTube player. We have also begun integrating with the new iframe embed style that is currently in beta and have seen promising results in our initial tests across desktop and mobile platforms.

Android tablet. Tablet computing represents an exciting opportunity for ShortForm to provide a first-class viewing experience in a new package. We have begun testing and looking for places to optimize the viewing experience on tablet devices.

ShortForm widget. Our embeddable widget syntax was inspired by YouTube’s new iframe embed syntax. We believe this is the simplest, most flexible and most powerful way to allow our users to embed their channels anywhere on the web.

We are thrilled to be a part of Google I/O and in order to demonstrate the power of ShortForm, we are putting together a Google I/O Sandbox channel, a continuous channel of product pitches and demos from companies represented in the I/O Developer Sandbox. We invite all Sandbox companies to submit a video of their product pitch or demo. Details can be found at the ShortForm at Google I/O page. We'll use the channel to preview cool companies in the Sandbox before the conference. The channel will also provide media members with a summary of all the technology from all Sandbox companies.

Lastly, we are going to have a little fun and invite all attendees to vote on their favorite pitches and demos. Submit your video on the ShortForm at Google I/O page. We’ll surface a leaderboard showing videos with the top votes, and the winning entry will be highlighted in a press release and will get prime placement on ShortForm’s homepage for one week, reaching hundreds of thousands of people.


Come see ShortForm in the Developer Sandbox at Google I/O on May 10-11.

As a founding member of ShortForm, Jereme has been hacking around with the YouTube APIs for over a year now and has been building software for 15 years. When he’s not coding he’s probably trail running or roasting his own coffee while eagerly anticipating the arrival of his first child in June.

Posted by Scott Knaster, Editor

2013, By: Seo Master