Online lectures: Coursera

The fourth and final part in the mini-series about online education.

As tens of thousands of others, my first class on Coursera was Machine learning, led by Coursera co-founder Andrew Ng. It was clear from the beginning that it is a hit.

Professor Ng knows very well how to teach. The lectures were well structured, interesting and the principles of a given topic were communicated effectively. Coursera doesn’t make the same mistake as Udacity; lecutres are usually 10–14 mintues long with an occasional in-lecture quiz. Assignments for the ML course were stimulating and rewarding. Not that taking the ML course will make you a full-fledged data analysit (although some might argue otherwise), but you’ll learn the basics and get pointers to what to learn next.

It’s the same story with the rest of Coursera courses. They are fun and engaging, you’ll learn a great deal and know where to look next if you want to dive deeper in that particular subject.

From the technical standpoint, Coursera is not as advanced as Udacity (e.g. rewinding lecture video is a pain), but they’ve created a great paltform for online education. Plus, they are tailoring it to each course needs.

This, together with perfect content, partnership with top world universities, broad choice of topics make Coursera my online education platform of choise.

For some interesting behind the scenes info, watch this TED talk by Daphne Koller, Coursera co-founder.

Online lectures: Udacity

This is the third part of a short series about my experience with online education.

I took two Udacity courses – Design of computer programs and Intro into statistics.

There are things I like about Udacity and things I don’t. Unfortunatelly, those that I don’t like are the important ones for a online education platform.

The good things are that there are wise people building the platform. Technically, it is very good. I like that they use the Youtube player or the smooth transition between video playback and in-lecuture quizes. In some programming courses, you have a Python interpreter directly embedded in the browser window. They also built relationships with potential employers of Udacity “graduates”. All of this is smart and helpful, yet it doesn’t help with the main problem.

Udacity is not a good place to learn.

In my opinion it is mainly because of the format of the “lectures” – 2 minute videos are just too short and, as crazy as it might sound, I had trouble keeping my attention focused exactly because of this. Two minutes is not enough to pass on any principle. You try to keep it them in your head but the constant video switching suck. It interupts your train of thought.

Also, it doesn’t help that you can’t easily see the code or examples written previously and so you get stuck thinking “Why is it this way? What did the lecturer mean? How is it supposed to work?”. If you are not thinking exactly the same way as the lecturer, you’re going to have trouble following him.

The 2 mintue videos are at the heart of Udacity as you can hear from Peter Norvig in this TED talk, yet I hope they change it, and also improve on the other problems I’ve encountered. Until they do, I’ll prefer sites like Coursera.

Python pre-commit hook

This is a pre-commit hook I use in my Python projects.

https://gist.github.com/3849310

Nevermind my feak bash-fu, in the end the script does what I want it to – the three following things:

  • First, it checks if I haven’t forgotten to add a new module to the requirements.txt file. Most of the time this works like a charm with virtualenv and pip. The only drawback is installing modules in local experimental branches – these modules are not necessary in upstream branches and so they don’t belong to requirements.txt yet. When you switch back and want to commit in an upstream branch, the pre-commit hook fails. However, this is easily avoidable by using the --no-verify option of git commit.
  • Second, it runs pyflakes on all the .py files in the repository. If there’s something pyflakes doesn’t like, the pre-commit hook fails and shows the output of pyflakes. There’s one case which is ignored and that is using the _ (underscore) function from the gettext module as install makes it available everywhere. Pyflakes documentation is non-existent and I guess there’s no way to create a configuration profile for it, so I had to resort to this hack.
  • Finally, since I deployed code with forgotten set_trace() calls a couple of times, the third thing the script does is it checks for these and prints out the file and line number if it encounters any.

I keep this file as a part of the repository, making a symbolic link to it in .git/hooks/pre-commit. Make sure the file is executable.

    Do you have similar stuff in your VCS hooks? Is there anything I could improve in mine? I’ll be glad to see your tips in the comments.

    Getting the cellular network information on your iPhone

    I got this neat little trick from my colleague Petr. Dialing *3001#12345#* on your iPhone launches a hidden app called Field test. In it, you’ll find a lot of detailed information about your network. You can disable wifi to see even more data.

    Photo_1Photo_2_1

    To be honest, I don’t even know what half of those values mean, but you can easily Google for them. The EF-ICCID value in SIM Info can be useful even for non-developers. It’s the ID of your SIM card, the one your operator often times asks for. This way, you don’t have to take out the card from the device.

    Server-side verification of Google Play subscriptions

    TL;DR To programatically verify Google Play subscriptions, you have to use the OAuth 2.0 for web server applications auth flow, not service accounts. This is a massive FUBAR on Google’s side and makes life of developers very painful.

    Lately, I’ve been working on the backend part of a upcoming app we’re developing for one of our clients. This app offers monthly and yearly subscriptions, so I had to implement a check if the recurring payment happened, the credit card got billed and the app provider got the money. Of course, for multiple reasons, this has to be done server-side, completely automatically and without any intervention from the app user or provider.

    Google provides an API called android-publisher for this. To use any API from Google, first you have to enable it from the Console and then authenticate with it. The authentication is done via OAuth 2.0. As Google offers API access to many of their services which are used in different occasions, they also offer different OAuth 2.0 authentication flows.

    The flow/mechanism for server to server communication is called Service accounts in Google terminology. This is precisely what I needed. However, for reasons beyond my understanding, this is not the one used for android-publisher API. Instead, they chose Web server applications flow, which for this use case is absurd.

    (Sidenote: When we started to build the aforementioned app, recurring transaction were not even available for Android. We planned to use Paypal as we did for the Blackberry version. However, during development, Google introduced subscriptions for Android which made us happy.

    I started reading the docs and implementing the whole auth and check code, but it didn’t work; I was getting “This developer account does not own the application.” HTTP 401 error. Googling for this didn’t help – at that time, the only search results were two couple of hours old questions on Stack Overflow. I would swear the docs at that time mentioned to use Service accounts for authentication and later Google changed it. I had to re-read the docs from the beginning to debug this infuriating error.)

    Using Web server applications flow is ridiculous because human interaction is involved. At least once, you (in this case our client!) need to press an “Allow” button in you web browser. Palm, meet face.

    Here are the instructions you need to follow to achieve automated subscription verification. The code is in Python but it’s easy to adapt.

    First of all, in the Console, you need to create a Client ID for Web applications. You can use http://localhost as the redirect hostname. As you’ll see in a minute, it doesn’t matter much. You mostly need the Client ID and Client secret.

    Next, fire up the Python REPL and enter this:

    https://gist.github.com/3450666

    Use the Client ID and Client secret you obtained from Console. This piece of code will give you an authentication URL; by default, it will contain access_type=offline parameter. This is very important, make sure it’s there. Open the URL in your browser and log in with the Google account that you will be using for publishing the Android application. After a successfull login and authorization, you’ll be redirected to localhost in your browser. Unless you’re running a webserver locally, this will probably fail, but it doesn’t matter. The address you are redirected to will contain a code parameter. Copy its value and go back to the REPL again:

    https://gist.github.com/3450785

    Finally you’ve got an instance of the oauth2client.client.OAuth2Credentials class. It contains couple of properties but the only one that’s really interesting is the refresh_token. Store the refresh token to your server configuration, you can use it forever meaning until someone does not revoke the access to the API. Then you would have to got through this whole process again.

    Basically, thanks to this refresh token you will able to obtain a new access token on each call to the API. To do that, you create an instance of OAuth2Credentials and use that to authorize an httplib2.Http object:

    https://gist.github.com/3451039

    You can now build a service and call the get purchases API call.

    The following gist summarizes the whole blogpost:

    https://gist.github.com/3451509

    As long as the API access will not be revoked, you should be fine using this method.

    In praise of the future

    We’re living in the most exciting era of mankind. The scientific progress of the last hunderd years is just astonishing. This makes me happy.

    The Internet is just a little over 20 years old but now all of man’s knowledge is available to anyone with a connection to it. Thank you Sir Tim Berners-Lee. We have autonomous cars and planes; 100 years ago, man wasn’t able to fly at all. We have built a large underground tunnel to ram particles against each other really fast and discovered the Higgs boson. We have put a nuclear powered rover on Mars.

    With this amount of recent progress, can you imagine what’s waiting for us in the future? I hope for a squad of on-demand robots that will print a house according to my personal design. If I won’t be able to have a holiday in space in 30 years, I will be disappointed. Oh, and please, someone, bring back public supersonic flights.

    Online lectures: Technology entrepreneurship (a.k.a venture-lab.org)

    This is the second part in a series about my experience with online education. Some months earlier I wrote about taking a couple of online classes. This second post is about Technology entrepreneurship class.

    Spoiler alert – this class was a big disappointment. A waste of time, really.

    The promise of venture-lab.org was to form a team and build a company. This fact alone should have been a warning sign, but I was optimistic and eager to try it out.

    For the first two assignments, the system automatically diveds students into teams of 10 based on geographical location and language preferences. This worked well. When my teammates were chosen, I sent a first email saying hi to all of them. Just one replied.

    The first assignement was that everyone of us should come up with either a best or worst business idea ever. We were supposed to fit it into the business model generation canvas. This was an easy and fun task and was supposed to bind the team together. Unfortunatelly, only one other member (Hi Carlos!) from my “team” participated.

    Next, we were given an idea created by some other team in the first assignment and were supposed to create a business pitch. Either a slide deck, a video or a text selling the business to potential investors. Again, as with the first task, only two of us participated. I was starting to get annoyed.

    These two tasks, however, were supposed to be just warm-up duties. The “real” would be the next one. We were instructed to create a 3 or 4 person teams (could be from the current teammates or any other enrollees). I sent another mail to my current team, again with no reply but one. Since they have been inactive for the whole course, I decided to post to the forums, looking for a team, advertising my skills. As I should have known, people who responded we’re “business types” looking for a iPhone developer to build their awesome SoLoMo app idea that’s better than Foursquare. I’m not kidding here, this really happened.

    Irritated by the whole experience, I decided to spend my time more productively and quit venture-lab.org. This experiment was a failure.

    There were also other mishaps resulting from the rest of the teammates not communicating, but I won’t go into details as they are not that important.

    Another defect of the class was the organization of study materials and video lectures itself. It was just chaotic. I understand that it is the first year and so I hope they’ll improve it.

    Yet I believe the whole premise of this course is flawed. You just cannot pick people at random, put them together and think they’ll build a company even if it’s the aim of every single one of them. If this course taught me anything, it was that building a company is all about people. Surround yourself with the right ones.