In an earlier blog post, I had presented the view that one of the best ways to learn Docker in my opinion is to move to the cloud and not do this stuff on your local machine. Chief reasons among them being bandwidth issues that could completely spoil your experience around Docker.
Docker is all the rage and there are valid reasons for it. Every software developer needs to understand this fundamental shift that is happening when it comes to packaging, delivering and running applications as containers. It would definitely pay to start learning this technology. There are enough resources on the Net to do that today and hopefully I will come around with some tutorials that can help demonstrate how useful Docker can be to individual developers like you and me.
The focus of this blog post is different though. It is about which platform/OS should I start learning Docker on. And then I would like to make some points from the perspective of countries/individuals where it is not easy to get high speed internet access all the time for several reasons. My focus is going to be for students who want to get started and have limited resources.
Over the last couple of weeks I have covered the news around several features that have been released on Google Cloud Platform (GCP). I write these articles on ProgrammableWeb. Here are the list of articles:
- Google Tool Scans App Engine Apps For Security Vulnerabilities
- Google Releases GRPC To Speed Up HTTP/2 Support In Applications
- Google Releases Cloud Status Dashboard To Monitor Service Disruptions
- Google Cloud Platform Unveils Pub/Sub Messaging Service
- Google Cloud Debugger Extends Support To Java Applications On Compute Engine
- Google Cloud Nearline Adds Low-Cost, Quick Access Storage
The articles demonstrate the recent spate of feature releases on GCP. They are targeted squarely towards the developers/organizations and helping them get more productive, write secure apps and finally get a shot at a messaging service in GCP. Not to speak of Google Cloud Storage Nearline that changes the game when it comes to cold data storage.
Android Studio has solid support for working with Google Cloud Endpoints. I have written a series of tutorials on working with Gradle, Android Studio, Cloud Modules over here. One of the episodes in that chapter was around generating the Persistence Layer in your Endpoints using Objectify.
At the time of that writing, the skeleton wrapper code that was generated for Endpoint when you provide it your Entity class was minimal. It was of not much use and you had to pretty much write the Objectify code for list, get, add, update and remove methods.
Since then the support has been upped by several notches and I should have written about this earlier but got around to it only now. The bottom line is that if you have an Objectify annotated Entity code, Android Studio is currently doing a great job of generating the Endpoints class with all the persistence goodness of Objectify generated for you. This can greatly help to reduce the time to generate working persistence code for your Mobile backend.
I recently wrote a blog post on writing a temperature logger using Arduino + Python + Orchestrate.io database service. Several readers wrote back to use an alternative database if possible. I have decided to rewire that tutorial but this time with Firebase database. This would also act as a introductory tutorial on Firebase.
Tomorrow is Valentines Day and I decide to do a little something about it. And what better way than to combine all the buzzwords that are strangulating us today : Cloud, IoT, APIs, HTTP, DIY Electronics and more.
December has been a busy month for talks. Among the various talks that I did, a few of them stood out for the audience, topic and size of the event. The talks were on Android Wear, Google Cloud Platform and understanding Gradle in Android Studio. Also enclosed are the presentations for each of those talks.