Kivy Idle Week

Bionoid has graciously agreed to ship an iOS development device to my place (Our Kivy community is awesome!). And while I was waiting for it, I had taken a break this week to attend a couple of interesting lectures happening in the city. Although I have been closely sticking with the plan otherwise, I will put in extra effort when that reaches me to cover up for this.

Also, I have decided to work on facades interfacing with accessibility systems on the various platforms. I didn’t have that as a part of my original summer plan but it seems like an interesting idea as suggested by tshirtman. I will investigate the common features and work on a plan to implement this.

Quoc Le’s Lectures on Deep Learning

Update:  Dr. Le has posted tutorials on this topic: Part 1 and Part 2.

Dr. Quoc Le from the Google Brain project team (yes, the one that made headlines for creating a cat recognizer) presented a series of lectures at the Machine Learning Summer School (MLSS ’14) in Pittsburgh this week. This is my favorite lecture series from the event till now and I was glad to be able to attend them.

The good news is that the organizers have made available the entire set of video lectures in 4K for you to watch. But since Dr. Le did most of them on a blackboard and did not provide any accompanying slides, I decided to put the brief content descriptions of the lectures along with the videos here. Hope this will help you navigate the videos better.

Lecture 1: Neural Networks Review

[JavaScript needed to view this video.]

Dr. Le begins his lecture starting from the fundamentals on Neural Networks if you’d like to brush up your knowledge about them. Otherwise feel free to quickly skim through the initial sections, but I promise there are interesting things later on. You may use the links below to skip to the relevant parts. The links are using an experimental script, let me know in the comments if they don’t work.

Contents


Lecture 2: NNs in Practice

[JavaScript needed to view this video.]

If you have already covered NN in the past then the first lecture may have been a bit dry for you but the real fun begins in this lecture when Dr. Le starts talking about his experiences of using deep learning in practice.

Contents


Lecture 3: Deep NN Architectures

[JavaScript needed to view this video.]

In this lecture, Dr. Le finishes his description on NN architectures. He also talks a bit about how they are being used at Google – for applications in image and speech recognition, and language modelling.

Contents

Maintenance work in progress

Continuing my work from last week I included a PEP8 style checker in the Plyer repository. I was able to borrow most of the code from the main Kivy project. This also included a git hook which runs a script to check for style errors after every commit. I also included a make hook rule to make it easier for the contributors to set that up.

But I had to do a lot more work after checking in the code. Our script threw a whole bunch of errors for the previously checked-in code that was submitted without any checks in place. Unfortunately, I had to fix most of them by hand. The silver lining on the cloud was that I managed to memorize all the conventions and unlearn my bad habits while styling code in the process.

While I was setting up the Makefile, I also set up the rules for building the Plyer docs using Sphinx. I also took this opportunity to revise some of the docstrings to make them explain things better. Hopefully the documentation will now make more sense to the readers.

This is how my final pull request looks like with all of the above changes. I think I touched nearly every source file in the project and ended up changing 37 files with 2,417 additions and 125 deletions. I hope I haven’t introduced any silly errors while doing that though.

In other updates, I have started parallel efforts for iOS facades. I am trying to get my hands on a real device and also working on running Kivy on a simulator in the background. There has been some prior work in this direction but we don’t have a final solution for this as yet. Hopefully, I will be able to find something here in the coming weeks.

I can haz commit access and other updates

I can haz commit accessIn this week’s update on Kivy and Plyer, I have been granted commit access to the repository. Yay! And thanks everyone in the community for considering me responsible enough 😛

As a result I did some obligatory maintenance work and clean up the repo post my code merges. Doing that I also realized that we need a git hook to do all code style checking before any push. I think the standard Python PEP8 checker should suffice. I will work towards adding it in the coming week.

Also, I worked on a new battery status facade on Plyer. I have implemented the lowest common denominator set of features for now and we can query whether the device is connected to a power supply and its battery’s charge percentage. I also have access to some platform information which can be added as well if need. May be under extras or a specially marked category.

If you have been following my updates, you’d have noticed that I haven’t made much progress on iOS as yet. This is because we haven’t had any success running Kivy on a simulator and I don’t have access to a real device. Brousch and I have decided to get community help for any tips on this issue.

Mid-summer Progress on Kivy and Plyer

This week I worked on retrieving a Unique ID depending the the hardware your program is running on. This involves querying some platform specific unique IDs that are suitable for this purpose. For example, you could use the IMEI number on an Android device or the serial number of the machine when running on a desktop. While none of these methods are foolproof and can be spoofed, they can still be useful in primitive fingerprinting and probably even seeding a random number generator. You can check out my pull request here.

The week also marks the end of five weeks since I have started working on the Kivy project. I have been making steady progress towards improving Plyer, a cross-platform library to handle all the common platform dependent things you need while writing python applications that can run on Android / iOS / Linux / Mac or Windows.

Here are the links to my previous blog posts describing my progress each week:

  1. Kivy for all your GUI (or NUI) needs!
  2. Kivy Updates from the First Week
  3. Mid-Midterm Activities on Kivy, and
  4. PyJnius to rule them all!

I started my work with a critical bug that was blocking further progress in the first week. Although it is only recently that Inclement has been able to propose a fix for it, we were able to find a quick work-around that did not stop the development on Android platforms.

I also did some review of existing pull requests in Plyer that were pending to be merged. I also implemented the accelerometer facade on MacOS by writing a small library using ctypes to make the API calls. I then re-wrote some of the existing sensor facades on Android using the support provided by the PyJnius project. This made access to the platform specific APIs more simple and very clean. We decided against using the sl4a compatibility layer and stick with using Pyjnius for accessing Java classes on Android.

You can find a list of all the pull requests in Plyer here. In summary, these are the facades that were either added, modified or reviewed since the beginning of the project:

Platform Android iOS Windows OSX Linux
Accelerometer X  X  X
Camera (taking picture) X X  X  X
GPS X X
Email (open mail client) X X X X
Vibrator X
SMS X
Play Sound X X X X
Compass X X
Gyroscope X X
Unique ID X X X X

I also added some example applications using Kivy to demonstrate the use of these facades. And also made a point to include one with most of the new facades that I wrote.

I believe that I have made some significant progress till now but there are still some tricky facades that are left to be implemented before the end of summer. I hope to carry this momentum forward and add many more facades in the coming weeks.

Kivy Plyer Updates

This week I looked into a pending facade’s implementation on Mac and worked on some new ones as well. In other news, we have a functional #plyer channel on Freenode. It is not very active at the moment but is fully equipped with all the basic amenities (:D), ie. logging and a google-group to contact the folks offline. The idea behind making a separate channel was to reduce the noise on the main channel and also allow the relevant people to focus on project specific updates here.

We have had a camera facade in the queue for quite some time now. We wanted to model something on the lines of what is available on Android OS. It should provide a simple API to  capture a picture from the default camera on the platform. We had tried two different unsatisfactory approaches previously and were on the lookout for a lighter (without many dependencies) method to get it working. I am of the view that we could do with tools in the public-domain like ImageSnap, for each platform. This is in line with the Plyer’s philosophy of trying not to re-invent the wheel and use external libraries wherever possible. I have created a pull request to get feedback on this approach and I am waiting to hear back on this from the community.

The other new facade that worked on is called “Play Sound”. As its name, it would be used to play a short clip of an audio file on command. It also relies on existing standard libraries and tools. I have made use of the Sound Pool API on android, NSSound on MacOS, WinSound on Windows and on Linux, I launch a command line player (play or aplay) for now. I may update that in future if I can find a better method to achieve that. Here’s a link to the PR.

I think slowly and steadily I have been reaching my mid-term goals and have been checking off items in my easy list. I think now would be a good time to gather some feedback on the PRs I have proposed till now. Some suggestions on them would help fix any issues with them and continue with new facades.

Packaging web applications

A couple of weeks ago I did a post on packaging research code. While talking about web-based research projects, I concluded with the following paragraph:

There are a lot of newer (relatively speaking) projects out there that let you easily package code involving web applications and make them ready for deployment on other machines.

I felt that I didn’t do quite the justice in explaining this part and skipped over a lot of good stuff.

I am sure that you too, like me, would have been a bit hesitant in allowing others to deploy your web-projects on their own. Mainly because of the amount of work that goes into do so.

In this post I am going to offer you a some more (hopefully) helpful advice on how to use the tools that package your webapps with minimal extra effort.

Make isn’t as helpful when you are looking to distribute webapps

While writing code for the web may be similar to writing other (generic) projects, there are a few of issues that are better tackled by a few other dedicated tools:

  1. Many more libraries to manage
    If you have written Javascript apps, you’d know that you tend to rely on a lot of external frameworks, libraries, plugins etc… when coding for web projects. And frankly that is the one of the convenient reasons of doing a webapp in the first place. It is a lot more fun to concentrate on your own stuff when you have a lot of existing re-usable code at your disposal. But all of this makes your app even more vulnerable to fail when you have package and distribute it to others. Pulling different versions of your libraries from the web, may prevent your application to run smoothly. They could interfere with each other and result in conflicts specially when you are dealing with not-so-well-tested research code.
  2. Dependence on other services
    If you are writing a webapp, it is quite likely that you’d have a back-end service to use as well. It is usually a good idea to develop them independent of each other but this leaves you with many more configuration variables to manage. Manually taking care of each of these settings adds to a lot work either during deployment or while writing code. There are far too many prefix and suffix variables that get thrown around.
  3. Deploying it on a webserver
    And ofcourse you need a web-server to be able to deploy and run your apps. You might be using different types of them depending on what you did your backend in (Java / PHP / .NET … etc.). This adds to a whole new set of problems on its own while packaging apps.

Because of these factors it is a challenging to package webapps that can be easily deployed on other machines. But then you could take a few extra steps for the sake of reproducibility (and science!).

Node.js to the rescue!

While your options are a many here, I am going to talk about my (current) favorite development stack – Node.js. But then of-course you could look for other alternatives depending on your specific uses.

One of the advantages of using Node.js is that it lets you do the back-end in JavaScript. This specially convenient when you also have a good portion of the UI code in js as well. In fact, I
would recommend using it even if you are doing your backend in some other language. That’s because I like node’s package manager – npm a lot (I would rate it right after apt-get in terms of usability). You’d want to use them for deploying apps on servers that don’t rely on node as well.

Two packages that I couldn’t highly recommend would be bower and grunt. Bower is a client side code manager that let’s you deal with all of the client side dependencies with ease. These include your frameworks (jquery / angular etc.), starter code (Bootstrap / HTML5 Boilerplate etc.), and even your framework plugins.

While grunt takes care of all the repetitive tasks such as minifying source files, building docs, and configuration management etc.

And then finally, you could also use npm to install a basic http-server for cases when you have a simple or no back-end. Saves you the trouble of using a separate web-server altogether.

Assuming that I have sold node to you, I will now illustrate their uses with small examples so that you could get some idea on how you can use node and npm with your own projects.

For using npm, you would include a simple a package.json file where you can specify individual packages (bower, http-server etc.) that you are using for your project. It let’s you specify specific versions for them to avoid any conflicts. I’ll use a sample package.json file as an example:

Once you do a npm install, it would not only install all the package dependencies but you have an option of doing a couple of post-install steps in the script section. Once you have all the packages you’d be using you’d probably want to download all the libraries that you are using using bower. You also have other options in the scripts section like starting the simple http-server and so on. And here’s how a sample bower.json file would look like:

See, that? Bower and npm install let you pull all your dependencies on the fly while taking care of managing their required versions! No longer you need to explicitly include these files with your project.

And finally I’ll come to this another neat package called grunt. I find it really useful for managing the configuration variables. With a gruntfile, true to its name, you could automate your repetitive tasks that need to be carried out during different steps like installing the app, start the server, running tests etc . In case you were wondering about about the config variable in my package.json, now’s the time when I will be make use of them:

In my code, I’d like replace all instances of the term @@backEndApp in my config/services.js file, replace it with the correct value as set in package.json and finally copy this file inside my app’s working directory. The two at (@) symbols is the default syntax for a full match but you could use regular expressions there as well.

As you would have noticed, this is a regular javascript file and you enjoy its full functionality as well. You might probably already have ideas to do a lot more with with grunt.

Once you start exploring other npm packages likes, the only steps required by somebody looking to deploy your webapp would be something like a npm install, possibly followed by a npm start. Neat isn’t it? Hope this would help you package your webapps better.