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.
This is a pre-commit hook I use in my Python projects.
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.
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.
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.