Free Workshops at EuMW

Don't miss the workshops and tutorials at EuMW as a chance to learn about a new area or brush up on an existing expertise. This year there is quite a wide range of exhibitor workshops that are free and open to anyone. Agilent has a series of test and measurement workshops ranging from nonlinear measurement to MIMO design. Rohde & Schwarz also has nonlinear plus other types of measurement workshopds. And Keithley has one covering LTE testing so there is quite a selection on the test/measurement front. Ansoft has a series of 3 workshops on simulation and modeling and CST is giving in-booth tutorials. So don't miss the chance to learn something new - free workshops are always a plus.
No comments:

Agilent Unveiling of PXA


Agilent unveiled the PXA signal analyzer today which replaces the high end PSA unit and completes the X series with a full line ranging from the low cost CXA to the high performance PXA. The unit features 75 dB spurious free dynamic range at 140 MHz bandwidth which is the best in the industry.

Agilent now has the low cost CXA which starts as low as $12.5k. Then the economy class unit is the EXA, the mid class is the MXA and of course, the high performance unit is now the PXA. Guy Sene and Ron Nersesian were on hand to pull the blanket off the surprise unveiling in their booth complemented with champagne. Not a bad way to announce it!
They have some 20 demos in their booth covering ADS, NVNA/X-parameters, wideband receivers, scanning MW microscopy, etc. which we will cover in our wrap up article.
No comments:
We arrived in Rome on Sunday and the weather is beautiful (sunny and 80s during the day, high 60s are night). After some quick sightseeing in the afternoon we made our way over to the conference Monday morning. The venue is nice but quite spread out and not much surrounding the area. The sessions are in large, nicely arranged rooms all in the same area with a cafe so the setup is very well done for the conference. The exhibition is in a separate building next door so hopefully everyone will make there way over when it opens tomorrow.

In quickly looking through the sessions, there seems to be much more about higher class amplifiers (Class E and F including inverse versions) as the demand for more power/efficiency increases and the characterization techniques improve. It will be interesting to hear the details about power amplifiers that are over 75% efficient! There also seems to be more CMOS based devices as Si is ever improving its upper frequency limits and of course, more about GaN amplifiers. The passive devices are always getting smaller and doing more functions than their previous generations.

The exhibition starts tomorrow and the setup is nearing completion. The exhibition hall is well laid out and just the right size for this type of show. The large test and measurement companies dominate the entrance with Agilent, Rohde & Schwarz and Anritsu present with large booths. Of course, the component and software companies are well represented along with the large Italian defense companies Electtronica/Selex and Finmeccanica providing a large sponsorship which we don't typically see at the other European locations. It is nice to see such good local support - maybe they can continue in the other locations.

Let me know your impressions of the conference and exhibition.
No comments:

EuMW 2009 News Coverage

As I head over to Rome this weekend, I see the EuMW news starting to pour into our e-mail box. We have the EuMW Online Show Daily posted on our home page that will be updated continuously during the week but with so much news to cover, we decided to make a news summary page so you can quickly browse the headlines.

Please use this blog to talk about or comment on any news items, new products, interesting papers, hot events, etc. during the week. Also, as noted below we have quite a number of companies and individuals using Twitter to post the happenings at the conference and exhibition as they occur. Remember to include the text #EuMW in your Tweat as our feed and others searching for show information can easily find them.
No comments:

App Engine talks at a conference near you

It's September and the fall conference calendar is starting to fill up. Members of the App Engine team will present at these conferences: join us if you are in the area, and feel free to tweet @app_engine if you want us to participate in local developer community events around these dates!

We look forward to meeting you during these trips, if you can make it.



Posted by Patrick Chanezon, App Engine Team

No comments:

The Iterative Web App: 'Move' and 'Enhanced Refresh'

On April 7th, we announced a new version of Gmail for mobile for iPhone and Android-powered devices. Among the improvements was a complete redesign of the web application's underlying code which allows us to more rapidly develop and release new features that users have been asking for, as explained in our first post. We'd like to introduce The Iterative Webapp, a series where we will continue to release features for Gmail for mobile. Today: 'Move' and 'Enhanced Refresh.'

Last week we released two new features which can save you clicks when using web-based Gmail on an iPhone or Android-powered device.

The first one is 'Move', which you can find under 'More' in the Floaty Bar. The 'Move' function lets you label and archive a message in a single step. So as soon as you 'move' a conversation to a certain label, that email will disappear from your Inbox and show up under that label. We introduced this feature to Gmail for your PC earlier this year, and now we're making it available for your mobile phone as well.

Another improvement we made is 'Enhanced Refresh.' With this feature, your Gmail inbox auto-refreshes when you switch back to Gmail from another tab or application. And if your phone goes to sleep while Gmail is open, it will refresh when you wake it up.

To try out Gmail for mobile, visit gmail.com in your mobile browser. This version of Gmail for mobile supports iPhone/iPod touch OS 2.2.1 or above, as well as all Android-powered devices, and is available in US English only. To make it easy to access your Gmail account, try creating a home screen link.


by Heaven Kim, Product Marketing Manager, Google Mobile
No comments:

Google Mobile App for Windows Mobile gets My Location and more

It's easier and faster than ever to search Google using your Windows Mobile phone. Just visit m.google.com to download the latest version of Google Mobile App, which includes these new features:
  • My Location. Get local results without typing your location. Once you see the blue My Location dot with your current location below the search box, simply search for a local query, for example "italian restaurant", and the search results will contain local business results along with web results.

    To protect your privacy, location is encrypted when sent to the server, and only your most recent location is stored so that successive searches can use the same location. You can disable My Location at any time in the "Advanced Options" screen.
  • Google Suggest. Reduce typing time by selecting suggestions to complete your queries. You will also see URL suggestions, which bring you directly to a web page, skipping the search results page entirely. Try typing "facebook" to see this kind of suggestion.
  • Search with Maps. If you have installed Google Maps, type a local query and wait for suggestions. Select the suggestion with the red pin next to it to launch your search inside Google Maps.


To download the new version of Google Mobile App, visit m.google.com from your phone.

Posted by Craig Wilkinson, Software Engineer
No comments:

Agile paddling with App Engine: lessons learned building the Canoe '09 website

I work for Norex, a web development company in Halifax, Nova Scotia. As part of our sponsorship of the 2009 ICF Canoe Sprint World Championships in Halifax (Canoe '09), we developed an application to deliver real time race results to standard and mobile web browsers. Thanks to the ability to rapidly develop and deploy a scalable application on Google App Engine, and to do so live during the event, what began as a small experiment became a huge success for Norex.



Our goal was to import instant results (directly from the timing system FinishLynx), upcoming race information, athlete bios, teams, and past race results from a system used by the race organizers, and to reformat that data for distribution to web browsers. We chose to develop in Google App Engine (with Django and appengine patch) and iUI (iPhone User Interface) frameworks. In fact, this was our first time deploying an app using any of these technologies! While we had a few weeks to build the prototype, we also had to deal with the added challenges of a varying data format and special cases that could occur during live races. As with many software projects, these specifications were not provided on a regular or consistent basis from the race organizers, so we had to anticipate the unknowns and work to adjust to the conditions at the time.



The Canoe 09 Web Interface
The Canoe 09 Web Interface


To give you a taste for just how agile we were able to be on App Engine, here are some events during the race which we were able to cope with:



  • After the first day, the closed-circuit TV system which the race organizers planned to use for the event was down. Before it was back up and running, we were able to deploy a new view appropriate for display on the TVs.
  • By the end of the first day, the application had handled 840,000 requests at a peak of 60 requests/second. This was already several orders of magnitude higher than we had expected. At the start of the second day, we reached 10% of our CPU quota before 7:45am and were processing 100 request/second. While we had originally cached only the main pages, with a few lines of code, we extended our caching strategy to cache every possible page request, a different version for each web platform, and re-deployed during the day's races.
  • The rules of the events changed at 2pm on day 3 of the event to allow crew changes. By 4pm, I had reworked the models and views to support the change.
  • At 11am on the final day of races, someone in the control booth manually deleted inaccurate records, but this created inconsistencies in the model causing errors. By 11:05am, we had deployed a patch to stop the errors, and by 1pm had deployed a version which gracefully failed when referenced objects were inadvertently deleted.
  • Every night we deployed new views of the data as requested by race organizers, participants, and spectators.


We found that new deployments were possible (and quick) because we could stage versions of the application to the App Engine servers, and test these staged versions on live data. Switching from the live version to the staged version and back again takes seconds, thus we could paddle as confidently and rapidly as the racers.



The International Canoe Federation was so impressed by the dependability and versatility of the solution, that they elected to replace their usual channels with our application to serve up the official results for news organizations and to Sport Federation sites all over the world, and to be used internally for calculating medal counts.



All in all, we saw over 1,000,000 page views from 93 countries around the world, and experienced incredible stability and scalability from Google App Engine even when we were spiking 350 requests per second during the finals. It was a big win for Norex, and App Engine has proven itself to be a serious contender for developing scalable web applications. Thanks so much to the Google App Engine team for providing such an outstanding product!



Link to: ZAP Results Application



Guest Post by Adam Thurlow, Web Application Developer, Norex.ca

No comments:

Google Sync: Now with push Gmail support

Earlier this year, we launched Google Sync which allows you to synchronize your Gmail Contacts and Google Calendar with your iPhone, Windows Mobile, and S60 devices. Today, we're adding Gmail support to Google Sync for iPhone, iPod Touch and Windows Mobile devices.

Using Google Sync, you can now get your Gmail messages pushed directly to your phone. Having an over-the-air, always-on connection means that your inbox is up to date, no matter where you are or what you're doing. Sync works with your phone's native email application so there's no additional software needed. Only interested in syncing your Gmail, but not your Calendar? Google Sync allows you to sync just your Contacts, Calendar, or Gmail, or any combination of the three.


To try Google Sync, visit m.google.com/sync from your computer. If you're already using Google Sync, learn how to enable Gmail sync. Since push Gmail has been a popular request on our Product Ideas page and Help Forum, we look forward to hearing your feedback, so drop us a line and let us know how it's working or what you'd like to see next.

Douglas Gresham, Software Engineer, Google Mobile

Update at 8:20am: We jumped the gun on this post. The new feature should be rolling out in a few minutes.
No comments:

EuMW 2009 Coverage Has Started!


The Microwave Journal Online Show Daily for EuMW 2009 is live at http://www.mwjournal.com/#EuMWOSD (on our home page). Our September show issue contains several articles about the conference, exhibition, events and what to see and do in Rome. The site is updated frequently with news and featured products from the show plus a live Twitter Feed. Set the keyword to "EuMW" to follow the action and follow me on Twitter at http://twitter.com/pathindle.

We will have various entries on this blog over the next couple of weeks covering the show and what we find are hot topics and products in Rome. After attending IMS 2009 MTT-S, I think the two hotest topics might be new non-linear characterization techniques and high power GaN/LDMOS products. What do you think?
No comments:

Is that a cell phone in your pocket....

Fertility researcher, John Aitken, is advising men wishing to have children to avoid keeping their active mobile phones below the waist. His research group at the University of Newcastle in Australia has found that human sperm exposed to mobile phone radiation (1.8 GHz) for 16 hours had reduced vitality and motility, two key indices of fertility. Notably, he has also confirmed his own previous study, published in 2005, which showed that RF radiation could lead to DNA damage. In that earlier experiment, he had exposed mice to 900 MHz signals and then looked at the animals' sperm, in contrast to the new study in which he exposed semen collected from human volunteers.

The new data show striking dose responses for all three effects over a wide range of SARs �above 0.4 W/Kg and up to 27.5 W/Kg. The changes in motility and vitality became statistically significant at 1 W/Kg and the DNA damage at 2.8 W/Kg. In all cases, the statistical reliability of the effects became much more significant with higher SARs. These new results appear in a paper published on July 31 in PLoS ONE, a Web-based, peer-reviewed journal. All Public Library of Science journals offer free access to all.

"After 16 hours exposure, there was clear evidence of DNA damage," Aitken said at a fertility conference in Brisbane last fall when he first presented these findings. Aitken is the director of the Australian Research Council's Center of Excellence in Biotechnology and Development. "Several independent lines of evidence suggest that RF-EMR has the potential to influence semen quality and could be an important contributor to DNA damage in the male germ line."

Aitken also demonstrated a "potential causative mechanism" as to how RF radiation can lead to DNA damage. He acknowledges that cell phone signals do not have enough energy to directly break chemical bonds, but, he goes on, "[T]his form of radiation may have other effects on larger scale systems such as cells and organelles, which stem from the perturbation of charged molecules and the disruption of electron flow." Specifically he believes that the RF can cause leakage of electrons from the mitochondria and produce reactive oxygen species (ROS), which in turn can attack DNA. This process, he states, is unrelated to thermal stress.
No comments:

Is Obama Apeasing the Russians with a Change in Missile Strategy?

Appeasing the Russians or making a smart strategic move for the US? Obama announced yesterday that he has modified the previous Bush administration's missile defense strategy by changing it from a long range, fixed system based in Poland and the Czech Republic to a mobile short/medium range defense system. This could ease tensions with the Russian's who strongly objected to such a system in their back yard and possibly help the US convince them to put pressure on Iran to curb their nuclear efforts.

I think this change in strategy seemed to be presented poorly (or sensationalized by the press) as a scrapping of the Bush strategy rather than a modification of Bush's strategy as the threats have changed. Iran seems to have adapted to the initial Bush era system and bulked up its production of short and medium range missiles after we started working on a system to intercept long range missiles so the threat changed (assuming our intelligence is accurate which in the past has proven to be wrong). Therefore a more mobile, short/medium range intercept system could be the right strategy now and it should save money which is another benefit. Coupled with the improvement in Russian relations which could put pressure on Iran, this seems to be a very smart move providing our intelligence is accurate. It also protects our troops fighting in the area and our allies in the middle east such as Israel and Turkey. Having a mobile system (sea and land based) also makes it more flexible by being able to move the missiles around the globe to where the threats exist at the time.

How will this affect our industry? Do you think it is a better strategy or a mistake?? Below is video coverage from MSNBC.

No comments:

M2M Markets Seeing Life

ABI Research has new M2M report out showing how the market grew rapidly from 2003-2007 but collapsed in 2008. They began tracking the cellular machine-to-machine (M2M) module market in 2003, and for five years shipments increased on average more than 25% per year. In 2007 module shipment growth peaked at a phenomenal 45%. The economic collapse of 2008 put an end to such double-digit growth rates, but the M2M market was still up 4%.

Feedback from vendors indicates that most feel the market bottomed out in the fourth quarter of 2008 and the first quarter of 2009. Starting in 2Q 2009, they report that activity seems to be picking up again. ABI Research now forecasts that 2009 will show modest growth, with unit shipments projected to be about 16% higher than in 2008, and revenue up 10%. Below is a graph of projected growth for M2M module shipments by application:
No comments:

Cell Phone Radiation Report Out

Last year around this time there was some renewed concern that cell phone radiation could be dangerous, especially to kids. The Environmental Working Group has brought up the subject again with their release of the best and worst phones for radiation emissions and bringing up their concerns of the possible dangers. But there still does not seem to be any scientific evidence that they are dangerous and non-ionizing radiation is not known to be dangerous to the human body at the levels one would experience in everyday use of cell phones.

It is interesting that Samsung dominated the top 10 best phones list with 5 out of the 10 that have the lowest emission levels with the Samsung Impression taking the top spot. Motorola seems to dominate the top 10 list of the the worst rated phones with 5 out of 10 on that list (they do have one in the top ten best list also so it seems to be phone specific).

As I said in my entry last year, the FCC does limit the radiation levels of cell phones to a maximum specific absorption rate (SAR) of 1.6 W/kg (European limits are 2.0 W/kg). You can find the measured SAR values for many cell phones on CNET's website (one of my favorite sites for Tech Info.).
No comments:

Google Fast Flip for Android and iPhone

Browsing print and online articles on a phone can often be a slow task. There are many different sites to visit, and media-rich pages can take a long time to load. Of course, mobile devices make this more difficult with small screens, slower Internet connections, and less comfortable keyboards.

To help solve this problem, today we announced a new product from Google Labs: Google Fast Flip for computers, iPhone, and Android-powered devices. Google Fast Flip combines some of the best features of reading articles in print and on the web.

With this webapp you can literally flip through stories with the swipe of your finger. To get more information or view the entire article, simply tap on the screen. You can browse headlines and popular articles, and view trending topics. Searching for a specific topic lets you make your own "magazine." Fast Flip makes sharing articles easy as well. To send an article to someone, simply tap on the "Email" link in the upper right.




To try it out, point your mobile browser to fastflip.googlelabs.com. For easy access, we recommend creating a home screen link or bookmark. Fast Flip works on all iPhone, iPod Touch and Android-powered devices. For more information on Google Fast Flip, check out our post on the Official Google Blog.

Posted by Steve Kanefsky, Software Engineer, Google Mobile
No comments:

Migration to a Better Datastore

At Google, we've learned through experience to treat everything with healthy skepticism. We expect that servers, racks, shared GFS cells, and even entire datacenters will occasionally go down, sometimes with little or no warning. This has led us to try as hard as possible to design our products to run on multiple servers, multiple cells, and even multiple datacenters simultaneously, so that they keep running even if any one (or more) redundant underlying parts go down. We call this multihoming. It's a term that usually applies narrowly, to networking alone, but we use it much more broadly in our internal language.



Multihoming is straightforward for read-only products like web search, but it's more difficult for products that allow users to read and write data in real time, like GMail, Google Calendar, and App Engine. I've personally spent a while thinking about how multihoming applies to the App Engine datastore. I even gave a talk about it at this year's Google I/O.

While I've got you captive, I'll describe how multihoming currently works in App Engine, and how we're going to improve it with a release next week. I'll wrap things up with more detail about App Engine's maintenance schedule.



Bigtable replication and planned datacenter moves


When we launched App Engine, the datastore served each application's data out of one datacenter at a time. Data was replicated to other datacenters in the background, using Bigtable's built-in replication facility. For the most part, this was a big win. It gave us mature, robust, real time replication for all datastore data and metadata.



For example, if the datastore was serving data for some apps from datacenter A, and we needed to switch to serving their data from datacenter B, we simply flipped the datastore to read only mode, waited for Bigtable replication to flush any remaining writes from A to B, then flipped the switch back and started serving in read/write mode from B. This generally works well, but it depends on the Bigtable cells in both A and B to be healthy. Of course, we wouldn't want to move to B if it was unhealthy, but we definitely would if B was healthy but A wasn't.




Planning for trouble

Google continuously monitors the overall health of App Engine's underlying services, like GFS and Bigtable, in all of our datacenters. However, unexpected problems can crop up from time to time. When that happens, having backup options available is crucial.



You may remember the unplanned outage we had a few months ago. We published a detailed postmortem; in a nutshell, the shared GFS cell we use went down hard, which took us down as well, and it took a while to get the GFS cell back up. The GFS cell is just one example of the extent to which we use shared infrastructure at Google. It's one of our greatest strengths, in my opinion, but it has its drawbacks. One of the most noticeable drawback is loss of isolation. When a piece of shared infrastructure has problems or goes down, it affects everything that uses it.



In the example above, if the Bigtable cell in A is unhealthy, we're in trouble. Bigtable replication is fast, but it runs in the background, so it's usually at least a little behind, which is why we wait for that final flush before switching to B. If A is unhealthy, some of its data may be unavailable for extended periods of time. We can't get to it, so we can't flush it, we can't switch to B, and we're stuck in A until its Bigtable cell recovers enough to let us finish the flush. In extreme cases like this, we might not know how soon the data in A will become available. Rather than waiting indefinitely for A to recover, we'd like to have the option to cut our losses and serve out of B instead of A, even if it means a small, bounded amount of disruption to application data. Following our example, that extreme recovery scenario would go something like this:



We give up on flushing the most recent writes in A that haven't replicated to B, and switch to serving the data that is in B. Thankfully, there isn't much data in A that hasn't replicated to B, because replication is usually quite fast. It depends on the nature of the failure, but the window of unreplicated data usually only includes a small fraction of apps, and is often as small as a few thousand recent puts, deletes, and transaction commits, across all affected apps.



Naturally, when A comes back online, we can recover that unreplicated data, but if we've already started serving from B, we can't automatically copy it over from A, since there may have been conflicting writes in B to the same entities. If your app had unreplicated writes, we can at least provide you with a full dump of those writes from A, so that your data isn't lost forever. We can also provide you with tools to relatively easily apply those unreplicated writes to your current datastore serving out of B.



Unfortunately, Bigtable replication on its own isn't quite enough for us to implement the extreme recovery scenario above. We use Bigtable single-row transactions, which let us do read/modify/write operations on multiple columns in a row, to make our datastore writes transactional and consistent. Unfortunately, Bigtable replication operates at the column value level, not the row level. This means that after a Bigtable transaction in A that updates two columns, one of the new column values could be replicated to B but not the other.



If this happened, and we switched to B without flushing the other column value, the datastore would be internally inconsistent and difficult to recover to a consistent state without the data in A. In our July 2nd outage, it was partly this expectation of internal inconsistency that prevented us from switching to datacenter B when A became unhealthy.




Megastore replication saves the day!

Thankfully, there's a solution to our consistency problem: Megastore replication. Megastore is an internal library on top of Bigtable that supports declarative schemas, multi-row transactions, secondary indices, and recently, consistent replication across datacenters. The App Engine datastore uses Megastore liberally. We don't need all of its features - declarative schemas, for example - but we've been following the consistent replication feature closely during its development.



Megastore replication is similar to Bigtable replication in that it replicates data across multiple datacenters, but it replicates at the level of entire entity group transactions, not individual Bigtable column values. Furthermore, transactions on a given entity group are always replicated in order. This means that if Bigtable in datacenter A becomes unhealthy, and we must take the extreme option to switch to B before all of the data in A has flushed, B will be consistent and usable. Some writes may be stuck in A and unavailable in B, but B will always be a consistent recent snapshot of the data in A. Some scattered entity groups may be stale, ie they may not reflect the most recent updates, but we'd at least be able to start serving from B immediately, as opposed waiting for A to recover.



To Paxos or not to Paxos


Megastore replication was originally intended to replicate across multiple datacenters synchronously and atomically, using Paxos. Unfortunately, as I described in my Google I/O talk, the latency of Paxos across datacenters is simply too high for a low-level, developer facing storage system like the App Engine datastore.



Due to that, we've been working with the Megastore team on an alternative: asynchronous, background replication similar to Bigtable's. This system maintains the write latency our developers expect, since it doesn't replicate synchronously (with Paxos or otherwise), but it's still consistent and fast enough that we can switch datacenters at a moment's notice with a minimum of unreplicated data.




Onward and upward

We've had a fully functional version of asynchronous Megastore replication for a while. We've been testing it heavily, working out the kinks, and stressing it to make sure it's robust as possible. We've also been using it in our internal version of App Engine for a couple months. I'm excited to announce that we'll be migrating the public App Engine datastore to use it in a couple weeks, on September 22nd.



This migration does require some datastore downtime. First, we'll switch the datastore to read only mode for a short period, probably around 20-30 minutes, while we do our normal data replication flush, and roll forward any transactions that have been committed but not fully applied. Then, since Megastore replication uses a new transaction log format, we need to take the entire datastore down while we drop and recreate our transaction log columns in Bigtable. We expect this to only take a few minutes. After that, we'll be back up and running on Megastore replication!



As described, Megastore replication will make App Engine much more resilient to hiccoughs and outages in individual datacenters and significantly reduce the likelihood of extended outages. It also opens the door to two new options which will give developers more control over how their data is read and written. First, we're exploring allowing reads from the non-primary datastore if the primary datastore is taking too long to respond, which could decrease the likelihood of timeouts on read operations. Second, we're exploring full Paxos for write operations on an opt-in basis, guaranteeing data is always synchronously replicated across datacenters, which would increase availability at the cost of additional write latency.



Both of these features are speculative right now, but we're looking forward to allowing developers to make the decisions that fit their applications best!



Planning for scheduled maintenance


Finally, a word about our maintenance schedule. App Engine's scheduled maintenance periods usually correspond to shifts in primary application serving between datacenters. Our maintenance periods usually last for about an hour, during which application serving is continuous, but access to the Datastore and memcache may be read-only or completely unavailable.



We've recently developed better visibility into when we expect to shift datacenters. This information isn't perfect, but we've heard from many developers that they'd like more advance notice from App Engine about when these maintenance periods will occur. Therefore, we're happy to announce below the preliminary maintenance schedule for the rest of 2009.



  • Tuesday, September 22nd, 5:00 PM Pacific Time (migration to Megastore)
  • Tuesday, November 3rd, 5:00 PM Pacific Time
  • Tuesday, December 1st, 5:00 PM Pacific Time


We don't expect this information to change, but if it does, we'll notify you (via the App Engine Downtime Notify Google Group) as soon as possible. The App Engine team members are personally dedicated to keeping your applications serving without interruption, and we realize that weekday maintenance periods aren't ideal for many. However, we've selected the day of the week and time of day for maintenance to balance disruption to App Engine developers with availability of the full engineering teams of the services App Engine relies upon, like GFS and Bigtable. In the coming months, we expect features like Megastore replication to help reduce the length of our maintenance periods.



Posted by Ryan Barrett, App Engine Team

No comments:

WiFi is Pushing RF ICs to New Heights

Strategy Analytics states that vendors will ship $4 billion in Wi-Fi radio chips in 2013, most of these for cellphones, notebooks, netbooks, infrastructure, home entertainment systems and wireless gaming consoles. At the same time, adoption of 802.11n MIMO with multiple transmit streams will help boost the market for Wi-Fi power amplifier modules to twice its 2008 size, despite continued pricing pressure.

They have determined that Broadcom will probably remain on top, but the firm faces increasing competition from cellular chip vendors bundling connectivity with their platforms, and from chip specialists targeting emerging applications, such as Wi-Fi for home entertainment. In RF power amplifiers, SiGe Semiconductor has established a firm lead despite increasing competition from GaAs PA module specialists Skyworks, RFMD, TriQuint and Anadigics.

WiFi is becoming pervasive now and soon you won't be able to buy a phone, camera, printer, TV or PC that does not come with it. Remember when only the new and more expensive phones and PCs had cameras? Now you can hardly find them without one. That will be WiFi soon in consumer electronics.
No comments:

App Engine Launcher for Windows

As recently announced on the Google App Engine Blog, the 1.2.5 SDK for Python now includes a GUI for creating, running, and deploying App Engine applications when developing on Windows. We call this the Google App Engine Launcher.



About a year ago, a few of us recognized a need for a client tool to help with App Engine development. In our 20% time, a we wrote a launcher for the Mac. Of course, not all App Engine developers have Macs, so more work was needed. Thus, a new crew of 20%ers set off to write a launcher for our App Engine developers on Windows. Although Google is spread out across many offices around the world, it is surprisingly easy to connect with passionate engineers. For example, this new launcher for Windows has contributions from Dave Symonds in Australia, Mark Dalrymple on the east coast, and more engineers here in Mountain View.



The Windows launcher is written in Python and uses wxPython for its GUI. This means (with a little care) the launcher should work on Linux, and we'd like Linux developers to have the option of using it. Although we ship a binary of the Launcher for Windows (thanks to py2exe), shipping binaries for Linux is a bit more challenging. Fortunately, Google has a well-traveled path for solving this problem. For example, Google O3D provides binaries for Windows/Mac; it also provides source code and instructions for building on Linux. Thus inspired, we've open sourced the Windows launcher so that developers can use it on other platforms.



The goal of the launcher is to help make App Engine development quick and easy. There may be other tasks you'd like to integrate (e.g. run tests, re-encode images before deploying, etc) and with the launcher now open sourced, you can add them! We look forward to seeing contributions from the community.



We have also started the process of open sourcing the Mac version of the launcher. The source code is now available; however, it references some missing Google libraries, so it won't yet compile in its current state. Fortunately, those libraries have also been open sourced, so it will be possible to get things up and running using entirely open source code. I'll be using more of my 20% time to clean up the Mac launcher project in the coming weeks.



We hope the launcher will improve the workflow for App Engine developers. We also hope the source code will enable developers to adapt it to their needs, just as we do on Chrome, my main project. Finally, I am proud to continue a tradition of openness which began with my very first project at Google.



-- John Grabowski, Software Engineer



Let us know how the launcher works for you.



Open Source Code for the App Engine Launcher: for Windows and Linux, and for Mac OS X.



Screenshot of Google App Engine Launcher for Windows
No comments:

App Engine SDK 1.2.5 released for Python and Java, now with XMPP support


Today we are releasing version 1.2.5 of the App Engine SDK for both Python and Java, our first simultaneous release across both runtimes. We're excited about the great new functionality in this release ... including XMPP!



XMPP Support


XMPP (or Jabber as it is sometimes known) is an open standard for communicating in real-time (instant messaging). One of the most popular API requests in the App Engine issue tracker has been support for XMPP, so today we are excited to mark that issue closed with the release of our new XMPP API for both Python and Java SDKs!




Like the other APIs that App Engine provides for developers, XMPP is built on the same powerful infrastructure that serves other Google products. In this case, we take advantage of the servers that run Google Talk. This new API allows your app to exchange messages with users on any XMPP-based network, including (but not limited to!) Google Talk. If you're currently participating in the Google Wave developer preview, you can also use the XMPP API to build bots that interact with your waves.




We've tried to make the XMPP API as simple as possible to incorporate into your existing Python or Java applications. We use the same webhook pattern that Cron and Task Queue already use: you send outgoing messages with an API call; you receive incoming messages as an HTTP POST. You can read more about the features the XMPP API in our documentation (Python, Java).




We're very proud of our first XMPP release, but there's still more work to do. In the future we hope to provide even more functionality to apps, such as user status (presence) and info on new subscriptions. If you have particular requests or feedback, please let us know.



Task Queue API for Java


Python developers have been processing tasks offline using App Engine Task Queues since mid-June, but until now the feature was not available in the App Engine for Java SDK. The 1.2.5 SDK now includes support for creating Tasks and Queues in our Java runtime.




If you're familiar with the Python Task Queue API, the Java version will look very familiar. We use the same webhooks pattern as with Cron (and now XMPP). The API provides a simple pattern for creating tasks, assigning them a payload and a worker, and inserting them into queues for scheduling and processing. There's lots of potential with the Task Queue API, so make sure to check out the Java Task Queue Documentation for more details.



Raising Limits for the Task Queue API


With the 1.2.5 release, we are increasing the daily quota for Task Queue insertions to 100K for billing-enabled apps. Ultimately, we will raise the quota for both free and billing-enabled apps, but we hope this intermediate step opens up new scenarios for our developers using Task Queues.



New App Engine Launcher for Windows


Last but not least, we're very excited that 1.2.5 for Python now includes a Windows-based version of a useful tool that Mac OS X users have been enjoying for sometime: The Google App Engine Launcher!



Screenshot of Google App Engine Launcher for Windows


This tool simplifies the process of creating new Python projects, testing them locally, and uploading them to the App Engine servers. In addition, we're releasing the source code for both Mac and Windows App Engine Launchers as open source projects. Watch this space for more details on where you can find the source, and how Linux developers can use the Launcher as well.




1.2.5 also includes the usual set of bug fixes, tweaks, and API polish. For a more detailed look at all the things that have changed this release, take a look at our release notes and, as always, let us know what you think!

No comments:

461 GB of Data Per Day Sent Back to Earth!

Over the next year NASA�s Lunar Reconnaissance Orbiter (LRO) will scout and collect more information about the moon's surface and environment than any previous mission. It takes a powerful system to send all of this information more than 238,800 miles back to Earth so equipped with a new type of TWT amplifier, LRO can transmit 461 GB of data per day. It transmits this information at a rate of up to 100 MB per second. The 13-inch-long TWT is the first high data rate Ka-band transmitter to fly on a NASA spacecraft. L-3 Communications Electron Technologies built the amplifier under the supervision of NASA's Glenn Research Center in Cleveland.

As the orbiter collects information about the moon's geography, climate and environment, the communication system transmits this information to a receiver at a Ka-band antenna network at White Sands Test Facility in New Mexico. Scientists are using the data to compile high-resolution, 3D maps of the lunar surface.

TWT Amplifiers have been used for other planetary missions, such as Kepler and Cassini, but previous designs were less powerful and less efficient. The amplifier underwent vigorous spaceflight testing -- including vibration, thermal vacuum, radiation and electromagnetic interference tests -- to ensure that it could withstand the intense conditions of launch and lunar orbit.

I wish I could get a wireless connection that fast!
No comments:

Wireless Temperature Sensors in Football Helmets

There have been 40 deaths (30 high school players) to football players due to over heating since 1995. Now wireless transmitter systems are being tested that are embedded into football helmets with temperature sensors to monitor player's body temperature. The cost is about $100 per player - pretty cool stuff. See the video below from CBS:

No comments:
Subscribe to: Posts (Atom)