Posts

Showing posts with the label google

Google delivery : Drones versus balloons?

Image
In this issue, Google seems to have adopted its preferred side. After several years of exhaustive tests, Google appears to have abandoned the idea of using drones to deliver Internet services. Google's Alphabet division has been studying the possibility of using drones powered by solar panels. In 2014, Google purchased the company Titan Aerospace to start looking for solutions to their challenge. They've finally decided to replace drones by hot-air balloons, known in French as montgolfières . The revised project is named Loon . Balloons will travel at an altitude of some 20 km, and each one will cover a territory of about 40 km. For the moment, Google doesn't appear to have answered satisfactorily the question of avoiding collisions with other aircraft. A commercial airliner would look so silly if it reached its destination covered in Google packages. The situation would be far worse than silly if if the jet's engines were clogged up with torn strips of a hot-air ball...

Monstre du Loch Internet

Image
Depuis la naissance du web il réapparait régulièrement, chaque fois qu’un créateur de nouveau site souhaite faire quelque chose de magique dans l'espoir que Google indique son adresse aux Internautes de France et de Navarre. Ce monstre des profondeurs s’appelle SEO : Search Engine Optimization . Le principe : Pour une somme d’argent modique, des spécialistes peuvent « optimizer » votre beau site pour que n’importe quel visiteur potentiel le découvre automatiquement grâce à Google. C’est une belle idée. Le seul problème, c’est que ça ne peut pas marcher. L’idée qu’un bonhomme puisse insérer des termes magiques dans votre site web pour le rendre attirant est aussi stupide que de donner de l’argent à un charlatan pour qu’il vous transforme en quelqu’un de beau et intelligent. Curieusement, c’est Google lui-même qui fait sortir ce mythe. Voici une démo magique. Je vais taper les termes “ daily exami ”. Admirez ce que Google me donne : Cliquez pour agrandir Après 0,36 secondes, Googl...

Google software improves its own translation process

Image
                                                                           [photo Manuel Burgos/Getty] Click here to read a New Scientist article about an improved approach to automatic translation... invented spontaneously by the AI system itself [ artificial intelligence ] that had been handling this activity. That’s a fascinating idea. An AI designs its own approach enabling it to do a better job.

Mobile-friendly web pages

Google has announced that they are marking web pages as “mobile-friendly” in their search results . I was initially worried about this, because many websites have mobile-specific versions that are worse than their desktop versions on mobile devices. I also don’t like being auto-forwarded to mobile locations (e.g. from www.example.com to m.example.com ), because it prevents URLs from being universal. However, Google’s criteria for mobile-friendliness are reasonable: Pages must… Avoid software that is not common on mobile devices, like Flash Use text that is readable without zooming Size content to the screen so users don't have to scroll horizontally or zoom Place links far enough apart so that the correct one can be easily tapped Google’s blog post gives tips for ensuring that your page is recognized as mobile-friendly. It seems like a similar approach could be used for checking whether pages are accessible.

Hello Polymer: Q&A with Google’s Polymer team

Image
Today, there was an online event called “Hello Polymer”, in which Polymer team members Eric Bidelman, Alex Komoroske and Matthew McNulty talked about the framework. This blog post summarizes what happened. The actual video of the event starts at 2:40 . Goals and nature of the project Web components are a set of APIs (shadow DOM, templates, custom elements, etc.) that will enable cross-framework widgets and user interface elements for the web. The main goal of the Polymer project [1] is to help with designing those APIs. To that end, it polyfills them on modern browsers so that experience with them can be gained – with real projects. The Polymer team closely collaborates with web standards bodies, contributors to various frameworks and the Blink team. The following diagram describes the architecture of Polymer: platform.js : The red parts are shims [2] for upcoming APIs. These shims will be used by most frameworks in the future and eventually be replaced by native APIs. p...

Google’s Polymer and the future of web UI frameworks

Updates: [2013-07-16] Hello Polymer: Q&A with Google’s Polymer team [more information on Polymer] [2013-05-23] Plans for supporting Web Components in AngularJS and Ember.js At Google I/O 2013, Google presented a new web user interface (UI) framework called Polymer . The way it works is indicative of the future of all web UI frameworks. Polymer Polymer is composed of the following layers: Foundation (platform.js): Foundational building blocks. Most, if not all, of these APIs will eventually become native browser APIs. Core (polymer.js): Helpers complementing Foundation. Elements: UI and non-UI components built on Core. The Foundation layer (platform.js) The Foundation layer comprises the following technologies: DOM Mutation Oberservers and Object.observe() (probably ECMAScript 7): for observing changes to DOM elements and plain JavaScript objects. Pointer Events : handle mouse and touch in the same manner, on all platforms. ...

Google’s Blink: a few interesting facts

With Blink , Google has created a permanent fork of the WebKit HTML engine. This blog post mentions a few interesting facts that provide context for that decision. How much did each company contribute to WebKit? There are several interesting diagrams and numbers in the article “ Reviewers and companies in the WebKit project ” (by Daniel Izquierdo Cortázar for Bitergia). It’s remarkable how much Google has recently contributed to WebKit. Obviously, not all contributions are created equal: some benefit everyone, others only the contributor. We don’t know what the ratio between the two kinds is for Apple, Google, etc. Why didn’t WebKit2 adopt Chrome’s multiprocess architecture? Here is an Apple employee’s explanation of why WebKit2 has a multiprocess architecture that is different from Chrome’s: Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could bu...