About
The Berlin Google Technology User Group is a English speaking group meeting in Berlin to discuss Google Technologies.
This page is meant to be an aggregator for all GTUG-related information.
This page is meant to be an aggregator for all GTUG-related information.
Accounts
Friends
-
Loading…sixtus42 2 days ago
Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.
Click here to check if anything new just came in.
January 30 2012
January 29 2012
g|saudi arabia 2.0 is back
By Rania Hadi, MENA Outreach Manager
View this post in Arabic
Building on a year packed with g|days throughout the Middle East and North Africa, today we are announcing Google MENA’s first 2012 event to kick off the new year. On March 24-25, Google, in collaboration with Badir Technology Incubator, will be hosting our second event in the Kingdom: g|saudi arabia 2.0.
We’re coming to Jeddah with a host of fresh sessions on all things technology and business. Google engineers, product managers, and business leaders will be there to not only deliver trainings but will be available for any questions, ideas, or discussions you may want to have. We’re also planning some new formats: hands-on workshops, dedicated sessions for women in technology, and chances to showcase Saudi’s finest developer talent.
So if you are a developer, programmer, IT professional, entrepreneur, or small business/start-up, you won’t want to miss this event! If you need more convincing, have a look at the fun, enthusiasm and energy from last year.
Rania Hadi has been with Google since 2004 and now works on Outreach in MENA. She focuses on building relationships and promoting Google technologies with the developer and tech communities.
Posted by Scott Knaster, Editor
By Rania Hadi, MENA Outreach Manager
View this post in Arabic
Building on a year packed with g|days throughout the Middle East and North Africa, today we are announcing Google MENA’s first 2012 event to kick off the new year. On March 24-25, Google, in collaboration with Badir Technology Incubator, will be hosting our second event in the Kingdom: g|saudi arabia 2.0.
We’re coming to Jeddah with a host of fresh sessions on all things technology and business. Google engineers, product managers, and business leaders will be there to not only deliver trainings but will be available for any questions, ideas, or discussions you may want to have. We’re also planning some new formats: hands-on workshops, dedicated sessions for women in technology, and chances to showcase Saudi’s finest developer talent.
So if you are a developer, programmer, IT professional, entrepreneur, or small business/start-up, you won’t want to miss this event! If you need more convincing, have a look at the fun, enthusiasm and energy from last year.
Rania Hadi has been with Google since 2004 and now works on Outreach in MENA. She focuses on building relationships and promoting Google technologies with the developer and tech communities.
Posted by Scott Knaster, Editor
January 28 2012
January 27 2012
Fridaygram: faster web, stronger machines, prettier planet
By Scott Knaster, Google Code Blog Editor
Everybody likes a faster web, and that theme has been evident this week here on Google Code Blog. On Monday, Yuchung Cheng wrote about Google’s research into making TCP faster through various proposals and experiments. Yesterday, Roberto Peon and Will Chan blogged about SPDY (pronounced speedy), Google’s protocol for speeding up the web’s application layer historically handled by HTTP. In related news this week, the chairman of the HTTPbis Working Group announced support for SPDY in a public post.
At Google, these projects are part of our Make the Web Faster initiative, although TCP improvements and SPDY are efforts of the whole community. Even if you’re not working on TCP or SPDY, you can find lots of useful resources at our Make the Web Faster site. For example, there are articles on compression, caching, metrics, and more, a set of tools for measuring and optimizing pages, and several discussion forums for communicating with other interested folks.
Sometimes stronger is more important than faster. Scientists looking to improve the durability of machinery have been studying the yellow fattail scorpion, which uses bumps on its back to resist damage from sandstorms. Researchers hope to use the scorpion’s design to create erosion-resistant surfaces for blades, pipes, and similar parts. Or maybe they’ll make machines that look like giant yellow scorpions.
Finally, take a step back from everything on Earth and have a look at NASA’s latest "Blue Marble" images of our planet. We have a beautiful home.
Let’s say this fast: Fridaygram posts are just for fun. Fridaygrams are designed for your Friday afternoon and weekend enjoyment. Each Fridaygram item must pass only one test: it has to be interesting to us nerds. That definitely includes speed, space, and scorpions.
January 26 2012
My summer with the Google App Engine Team
Today’s post is contributed by our Summer 2011 team intern, Chris Bunch. Chris did some great work on our Logs and MapReduce APIs and is also the first “App Engine Triple Crown” winner for developing the Experimental Logs Reader API in Python, Java and Go simultaneously.
Four years ago, I was a brand-new Ph.D. student at the University of California, Santa Barbara and when our research group (the RACELab) heard about Google App Engine, we were intrigued. We thought it presented a new model that enabled apps to scale the right way without severely constricting the types of programs users would write.
After creating our own system to run Google App Engine apps, I wanted to see how Google does it. Therefore, I decided to become an intern on the App Engine team and see if I could give them (and by extension, the App Engine community) something amazing over the summer. I started off with some work on the MapReduce API, making the sample app much easier to use and prettier all around. I also made a YouTube video showing how it all works and how easy it is to run MapReduce jobs over App Engine.
I then looked at a recurring question that App Engine users encounter: “How can I get my logging information for my application to answer data analytic questions?” It was an excellent problem to tackle, as we have users who want to be able to determine application-specific queries that Google Analytics or the Admin Console don’t answer. Currently users have to use appcfg to grab all their application’s data to a remote machine and run some analysis script over it.
To solve this problem, I created the Logs API, which gives applications programmatic access to their logs from within App Engine itself. Applications can use it to query small numbers of logs within a single request, and they can utilize the Pipeline, MapReduce, or Backends APIs if they have lots of logs they want to analyze. Logs contain both request-level information (e.g., the URL accessed, the HTTP response code returned) as well as logging info generated by the application (the logging module in Python, the Logger class in Java, and the logging methods that Go’s appengine package provides). The Logs API is available for use as of App Engine 1.6.1 by programmers using the Python, Java, or Go runtimes, in both the production environment and the local SDK.
I had a great time putting the Logs API together, and had a unique experience interning with the App Engine team. Programming in Python, Java, and Go on a daily basis was an exciting new challenge, and I loved it!
Four years ago, I was a brand-new Ph.D. student at the University of California, Santa Barbara and when our research group (the RACELab) heard about Google App Engine, we were intrigued. We thought it presented a new model that enabled apps to scale the right way without severely constricting the types of programs users would write.
But we wanted to experiment with the core functionality of App Engine: the APIs, the scheduler, etc., and so we built AppScale, an open-source implementation of the Google App Engine APIs that allows users to deploy applications written in Python, Java, and Go to the infrastructure of their choice.
Wherever possible, we implement support for the App Engine APIs with alternative open-source technologies. We’ve added support for nine different databases, database-agnostic transactions, a REST interface that users of any programming language can communicate with (via an App Engine app), and the ability to run high performance computing programs over the whole thing and talk to it from your App Engine app. And here’s my favorite part - it all deploys automatically! You don’t need to tell it what block size you want for the distributed file system, or the size of the read buffers: we configure the necessary services automatically. Since AppScale is completely open source, if you don’t like the defaults, change them!After creating our own system to run Google App Engine apps, I wanted to see how Google does it. Therefore, I decided to become an intern on the App Engine team and see if I could give them (and by extension, the App Engine community) something amazing over the summer. I started off with some work on the MapReduce API, making the sample app much easier to use and prettier all around. I also made a YouTube video showing how it all works and how easy it is to run MapReduce jobs over App Engine.
I then looked at a recurring question that App Engine users encounter: “How can I get my logging information for my application to answer data analytic questions?” It was an excellent problem to tackle, as we have users who want to be able to determine application-specific queries that Google Analytics or the Admin Console don’t answer. Currently users have to use appcfg to grab all their application’s data to a remote machine and run some analysis script over it.
To solve this problem, I created the Logs API, which gives applications programmatic access to their logs from within App Engine itself. Applications can use it to query small numbers of logs within a single request, and they can utilize the Pipeline, MapReduce, or Backends APIs if they have lots of logs they want to analyze. Logs contain both request-level information (e.g., the URL accessed, the HTTP response code returned) as well as logging info generated by the application (the logging module in Python, the Logger class in Java, and the logging methods that Go’s appengine package provides). The Logs API is available for use as of App Engine 1.6.1 by programmers using the Python, Java, or Go runtimes, in both the production environment and the local SDK.
I had a great time putting the Logs API together, and had a unique experience interning with the App Engine team. Programming in Python, Java, and Go on a daily basis was an exciting new challenge, and I loved it!
Interested in interning with the App Engine team? Check out google.com/students for more information on internships.
Making the web speedier and safer with SPDY
Will
Roberto
By Roberto Peon and Will Chan, Software Engineers
Cross-posted with the Chromium Blog
In the two years since we announced SPDY, we’ve been working with the web community on evolving the spec and getting SPDY deployed on the Web.
Chrome, Android Honeycomb devices, and Google's servers have been speaking SPDY for some time, bringing important benefits to users. For example, thanks to SPDY, a significant percentage of Chrome users saw a decrease in search latency when we launched SSL-search. Given that Google search results are some of the most highly optimized pages on the internet, this was a surprising and welcome result.
We’ve also seen widespread community uptake and participation. Recently, Firefox has added SPDY support, which means that soon half of the browsers in use will support SPDY. On the server front, nginx has announced plans to implement SPDY, and we're actively working on a full featured mod-spdy for Apache. In addition, Strangeloop, Amazon, and Cotendo have all announced that they’ve been using SPDY.
Given SPDY's rapid adoption rate, we’re working hard on acceptance tests to help validate new implementations. Our best practices document can also help website operators make their sites as speedy as possible.
With the help of Mozilla and other contributors, we’re pushing hard to finalize and implement SPDY draft-3 in early 2012, as standardization discussions for SPDY will start at the next meeting of the IETF.
We look forward to working even more closely with the community to improve SPDY and make the Web faster!
To learn more about SPDY, see the link to a Tech Talk here, with slides here.
Roberto Peon and Will Chan co-lead the SPDY effort at Google. Roberto leads SPDY server efforts and continues to tell people to be unafraid of trying to change the world for the better. Will works on the Chrome network stack and leads the Chrome SPDY efforts. Outside of work, Will enjoys traveling the world in search of cheap beer and absurd situations.
Posted by Scott Knaster, Editor
January 25 2012
Older posts are this way
If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
