I created a simple app that renders a Blender 3D scene in the cloud: users can customize the displayed message by changing an URL parameter, and the app will return the 3D rendered image. Give it a try here.
The code is a very simple Python function that invokes the Blender open source software. It uses the Blender API in order to dynamically change the value of a Text object. The function is then simply wrapped in a basic Flask application in order to respond to HTTP requests. Because Blender needs to be installed, I am using a Dockerfile that runs “apt-get install blender”.
This app was created to showcase the upcoming “serverless containers” product of the Google Cloud Platform. It allows to run any container “in a serverless way”: developers are able to deploy and run any language or library they want, and only pay for actual resources used when it receives requests. I demoed the feature during the Cloud Next 2018 keynote and othersessions. sign up for early access at g.co/serverlesscontainers
My goal was to capture any Java exception in my production application and report it to Stackdriver Error Reporting for automatic exception monitoring and alerting.
I use the very simple Stackdriver Error Reporting report API: just send error stack traces using an HTTP POST request and an API key.
After creating a project and getting an API key in the Google Cloud Console, I instrumented my Play Framework application to catch all exceptions, format them in the expected structure and POST them to Stackdriver. (make sure you are using at least JDK v1.7)
Here is the code I added to my main application controller:
A short amount of time after deploying this code, I started receiving alerts that new errors were occurring in my production application:
I was not aware of these application errors, now I have better visibility into their impact and will be able to prioritize what to fix.
My website (Cadeaux entre nous, to organize Secret Santas), has been running on Heroku for years and has huge usage spikes around christmas. This will help me make it more stable.
Disclaimer: I am a Product Manager at Google, working on Stackdriver
The website (that we host at www.beansight.com) and associated mobile apps allow users to create predictions and vote on other’s predictions. Computation is done to extract from all votes a percentage of probability for a given event.
The website features all mechanisms of a social website : registration, login, user profiles, followers / following, content creation, comments, moderation tools, administration dashboard, API, i18n.
We built Beansight using the great Play! Framework. It turned out that Play! was a really great choice for our architecture and project. At that time, Play! was a Java web framework that got rid of the traditional Java web stack to focus on a simple MVC architecture, inspired by rails and other modern web frameworks, that prevails convention over configuration.
It was a real pleasure working with this language in a framework so well designed for websites like our.
Mobile application are native for iOS and Android and we used jQuery mobile for the mobile web version.
We decided to keep a very simple UI as part of our native mobile apps. We were one of the first apps to use ViewPager on Android for example.
We realised quite soon that we needed to build an API, mostly for these mobile apps. Our MVC architecture allowed us to easily create one. Ideally I think the main website should have use it (either client or server side). Anyway, our API code and website code were sharing a lot, thanks to our rich object oriented Models. You can find the API documentation in a GitHub wiki.
We used different hosts. We first started with PlayApps.net, the Platform As A Service offer from the builders of the Play! Framework. We never encountered any issue with it and were very satisfied to not bother about system administration. However, we had to move due to the service closing. Beansight was then running on Gandi Hosting. Here we had to take care about administring our server, which added some pain to the maintenance of Beansight.
Finally, in order to reduce the costs and make it easier to setup as part of the open source process, we made sure it is compatible with the Heroku PaaS hosting.
Today, Beansight can be easily run on any Linux server or pushed to Heroku with any MySQL database (beansight.com is now using clearDB for example).
I hope this code will be useful to somebody. I would be pleased to see you starting a new community from it, building something on top of it, or using it as part of another project.
While a few technical improvements could be done, I think it is still quite reliable, with a pretty well documented source code and good architecture.