Skip navigation

Tag Archives: python

A full GitHub year

I technically hit the year mark on January 6 but I wanted a full perfect rectangle of green so I pushed for a week more and this is what I got.

I think it’s time to erm…cash out on the things I learned doing this thing. Or spend more time thinking and less of coding; but I think, the habit can be quite hard to break.

A few more words before I go, the year mostly revolved around two projects, interestingly both a throwback from when I was just fresh out of university.

alexandria is actually a Python “port” of my earliest project on GitHub. Scare quotes on the word “port” because, by now, it hardly is a port. I wonder if the old PHP code will still run if I try to set it up today. The Python port itself, however, was started in 2015.

PyGame-Objects is my earliest attempts at seriously Python-ing. I created Snake this year which is, yeah, not very impressive but it really made me happy to try to write it as cleanly as I could, modifying the framework (which I built too, which is what PyGame Objects is all about) when needed, and maintaining backwards-compatibility with the previous games. I think some time ago (in 2013? But that feels like a lifetime now) I tried to rename it to something cooler but I stuck with the humbler name for now, and for the foreseeable future.

I cannot contain my excitement when the debug mode for PyGame Objects finally worked. Oh what joy! It felt legit even if there is much work to be done.

Pardon my seeming lack of modesty but my great takeaway here is that I write code pretty clean. They say a good rule-of-the-thumb of code cleanliness and documentation is if you can understand code you last touched three months ago. Well I last touched most of PyGame-Objects four years ago!

But I think, I overshot my intended quota of words. Goodbye now. Gotta play The Witcher 3: Wild Hunt.

From my last post, I’m taking a little break from Chess as I turn my attention to a guitar I bought as a Christmas gift to myself. You see, I’m in the process of becoming a Guitar God, ala Jason Mraz, but that story is better reserved for my main blog no?

And well, since I can’t personally jam with Jason Mraz (or Chris Martin), I settle for MP3’s of his songs. The problem is, MP3s play abruptly without warning. There is no sufficient time between my hand pressing play and the song playing!

Jason Mraz Fanboy

And yes, I do have the CDs!

None of the MP3 players I know of is aspiring-musician-friendly as such. So, obviously, this makes it a nice candidate for a quick hack.

My requirements are simple:

  • Have a UI
  • Be able to play an MP3 file after a set countdown. And it has to be in MP3 format, hard requirement. If it is to be of any use with minimal hassles, it has to be MP3.

 

The first requirement makes it a good candidate for a web/JavaScript app. But then, as far as I know, JavaScript is not allowed access to the local filesystem for security purposes. So JavaScript (unfortunately) rules out the more-important requirement of the two I have.

The next obvious choice is Java since I’m quite used to utilizing Swing to develop desktop GUIs; in fact, I created the user interface of our thesis in Swing, from ground up. However, for a quick hack, I think Java might be overkill and there’s this Python library I’ve been wanting to play with for so long…

Kivy!

Kivy can handle my UI requirement, and rather beautifully so, if I may say. Now, searching around, there are multiple ways to play an MP3 file with Python. One of them is even a Kivy library! The other libraries I found are mp3play, musicplayer, and PyGame.

But one by one, problems emerged

  • PyGame’s mp3 support is limited.
  • The sample code in musicplayer’s PyPi page looks too complicated. (Yes, since this is just a quick project, I’m in lazy mode.)
  • mp3play only works for Windows XP.

 

And then the Kivy library. It would’ve been sweet to have a single library for all my project’s requirements. But alas…

Kivy has a SoundLoader class which automagically determines the best way to handle the given sound file’s format. I’m not good with design pattern terminology but, the way I see it, it looks like a combination of Factory and Strategy patterns. However, when I test code given in their documentation, I come across the following logs:

[INFO ] Kivy v1.8.0
[INFO ] [Logger ] Record log in /home/chad/.kivy/logs/kivy_15-01-04_6.txt
[DEBUG ] [Audio ] register SoundPygame
[INFO ] [Audio ] Providers: audio_pygame (audio_pygst, audio_sdl ignored)
[WARNING] [Audio ] Unable to find a loader for <test.mp3>

 

The only provider that loaded is PyGame’s. And, as I’ve noted above, PyGame’s mp3 support is shaky. In fact, Kivy’s code as of presstime only allows PyGame on MP3 files if it is running on Android. audio_pygst would’ve done the trick but then, as the logs indicate, it did not load.

So why did it not load? Looking at audio_pygst’s code, it imports the modules gi, pygst, and gst, in that order, respectively surrounded in try-catch statements should there be problems on the import.

I try to load them manually on Python’s shell and get the following result:

chad@galadriel:kivy$ python
Python 2.7.3 (default, Feb 27 2014, 19:58:35) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gi
>>> import pygst
>>> import gst
/usr/lib/python2.7/dist-packages/gobject/constants.py:24: Warning: g_boxed_type_register_static: assertion `g_type_from_name (name) == 0' failed
  import gobject._gobject
>>>

 

Looking around, this seems to be an issue with gst 0.10.x. The obvious solution would be to upgrade. Unfortunately, gst updates for Ubuntu 12.04LTS seem to have stopped at 0.10.

So there. Much ado achieving nothing, for a quick hack. Maybe, I’ll look into using Java for this project, moving forward. Stay tuned!

Coldplay Fanboy

Okay. First off, I’m aware that I’ve lagged behind my New Year’s Resolution. But I’ve only lagged behind the blogging part: I’m still exploring new stuff monthly. Guess I’ll talk about them in brief for now and, maybe, expound some other time. ^_^

Just to clear some smoke, last time, I told you that I may be in for a volunteer project. Well, so I’ve been and yes, I did use Django pretty extensively with it. The project is for the up-and-coming Python Philippines. I’m the one behind the website and it’s running on Django CMS. Go visit it. We don’t have content yet but, well, you can look at the pretty theme. Hehe.

And just last Saturday, I talked about Django CMS at Python Philippines’ monthly meet-up, to encourage contributors. I feel that my talk went well and I hope to put up a transcript of it in here, to make up for my lack of blogging. Soon!

 

I’ve also been trying to learn some things from the ground up in Python. I’ve done sockets last time and this time around, I tried doing threads. Straight from the box, Python does not really support threads. You’d need libraries like gevent to actually get some concurrency done in peace. But still, unlike PHP, if you just want to switch among jobs, Python has something for you.

I’ve experimented with Python’s threading library. It’s a curious thing, coming from Java’s threads. I got so curious with it I’m even trying to learn statistics to validate my experiments. Because, you know, I did all my samples in powers/multiples of ten.

 

Lastly, as a form of humbrag1, I got myself an Xperia Z, for around a month now2. I must say, it’s damn gorgeous! I never got people who complain that Samsung uses cheap plastic to house impressive hardware but with the Xperia Z’s all-glass build, I get it now. It’s all about the user experience, people. User. Experience.

The hardware is damn powerful; Iron Man 3 plays very smoothly, save for occasional lags. The camera isn’t shabby either; for quick shots, it can do in place of my bulky SLR. Being water proof, dust proof, and shock proof sealed the deal for me.

At last, at last, I can play Temple Run 2 even when it’s raining.

  1. Okay, really bragging mostly []
  2. Those who know the camera I am using can now scream “Fanboy!” []

For February I tinkered with Django, arguably the most popular web framework for Python. Prior to this, the only web framework I’ve had experience with is CodeIgniter and one proprietary JSP-based framework.

In an earlier post I covered installing Django. Nothing much has changed between then and now except that the most recent version of Django, 1.5, now supports Python 3! The first for Django ever. But I’m sticking with Python 2 for the time being.

Note: I tried learning Django last August, in an afterthought project with goals loftier than what my resources could have achieved. Needless to say, I never got too far with it. It was this which prompted me to specify a mini-project I’d use to learn web frameworks (any web framework). I’m not sharing the specifics of it now but you can gather what you can in my sandbox repository.

The Admin Site

One nifty feature of Django is how it creates an admin site automatically for you. On my CodeIgniter projects, I’d pattern the users table something like this, borrowing from Linux file systems:

CREATE TABLE IF NOT EXISTS users(
    -- Some project-specific fields here
    create_time TIMESTAMP NOT NULL,
    last_updater INTEGER NOT NULL,
    last_update TIMESTAMP NOT NULL,
    can_read BOOLEAN NOT NULL DEFAULT TRUE,
    can_write BOOLEAN NOT NULL DEFAULT TRUE,
    can_exec BOOLEAN NOT NULL DEFAULT FALSE,
    PRIMARY KEY (userid),
    FOREIGN KEY (last_updater) REFERENCES users (userid)
    -- Yes, apparently, MySQL allows you to foreign key recursively
);

If I’m really feeling up to it, or if the project requires (never had it tho), I might even implement user groups. But even with this, I can already define 23=8 types of users, which is already way more than what one project usually requires. What I’d normally do here is to designate can_exec privileges to admins. Way neater than maintaining different tables for different user types and then giving admins backdoor log-in pages—one of the naive approaches I used when I first started designing databases for apps.

Django automatically covers this for you, user permissions, groups, and all. The structure becomes a bit different though, and I find permission management way more complicated than my binary-scheme. Take a look at all possible user permissions in Django:

django_permissions

Look at how many that is, and realize that there is still a scroll bar!

What Django basically did is to allow you to specify add/change/delete permissions for every table in your database. Note that due to how Django enforces code modularity (see below), the number of tables in your database could easily blow-up.

Code Modularity

Perhaps one of the most confusing things I encountered as I tried to learn Django was how it distinguishes the terms “project” and “app”. Normally, I’d talk about an “app” being a “project” for some party. But in Django a project is a collection of apps. I had a hard time designing my project around these terminologies even after reading discussions at StackOverflow until I realized that perhaps a better term for “app” would’ve been “plug-in” and there’s really nothing stopping you from making your project as one big plug-in.

With the side-effect, of course, of your app being non modular and probably not well-factored. So, yes, the way Django handles things enforces the nice practice of modularity. Nice to take advantage of it, though it may be too time-taking to wrap your design around Django’s rules.

Django also enforces a form of Object-Relational Mapping (ORM). In fact, you don’t need to write a single line of actual SQL code to get your database up and running—all DB creation is done through the ORM and manage.py . This even allows you to easily switch DB back-ends. Then again, as with above, not all projects would fit well for an ORM approach.

Overall?

I find Django pretty neat given that you only need minimal set-up for this whole bunch of admin stuff. But then I haven’t had much time to explore it although I’ve volunteered in a (non-work, non-paid) project that might use Django pretty extensively. Guess I’ll get more Django this month. Let’s see.

Okay. I know it’s already February and that it’s kinda late. But it’s in times like this that I say “better late than never!”. But as I’ll show, I’ve already started with my resolutions—I’m just writing about them now.

But since this is my coding blog, the resolution I will mention here will be my technical-life resolution (as opposed to the personal ones everybody makes). So, without further ado…

I resolve to learn a new technology every month. Or, at least, get deeper with one I’m already acquainted with.

Also, I’d go into programming competitions/contests again. Team requirements limit my choices but, hey, there are a lot I can do alone online, not to mention free! (Though if anyone wants to team-up with me, let’s talk.)

And, just so I’ll stick with it, I’ll write a blog post every month about what I’ve been up to. Consider this the one for January.

For my first resolution, I created this sandbox repository at GitHub. And since my GitHub account is, in itself, already my sandbox of sorts, I guess this is some sandbox-ception eh?

January, I did sockets in Python. I didn’t manage to dig as deep as I’d have wanted because the Facebook Hacker Cup kicked in earlier than I expected and that falls under my second resolution. So it had to give way. Besides, I’m already dealing with a few sockets too many at work.

Regarding my second resolution, I don’t really expect much from it. At least, I won’t get rusty from the lack of problem sets in the real world (read: industry). At most, I might score a free trip to some world finals. But that world-finals scenario is still very out of my league. I’ve been doing ACM-ICPC problems since I was in my sophomore year in College and even now I find most of them really tough and tricky. Also, after less than a year out of school, I’m bound to have some rust in my system (not that school is a sure fire way to keep you sharp though). I only decided to start practicing with my algorithms sometime in December so there isn’t really much to expect.

(Note: I started writing this post in the last hour before the first round of Hacker Cup started. It’s now over and everything fell within my expectations. There’s a lot to learn. Maybe, I’ll write about this soon.)


So, what do I think about sockets in Python? (This will be short since, as mentioned, I didn’t have much time to dig deep into this.)

As with all things Python, it looks super neat. I got a client and server up and running in just 41 lines of code combined. The biggest savings comes from the fact that socket I/O is direct in Python; you no longer have to create OutputStream and InputStream objects as the socket objects themselves have methods for sending and receiving. It’s also interesting to note that Python’s socketserver class has a serve_forever method which, as the name implies, handles requests as long as it can (the official phrase is: “until an explicit shutdown signal is received”).

Oddly, this design reminds me how I handled one of the things I did at work. Won’t go into the details but I thought that it’s neat to have one class responsible for managing one whole session: packet numbers, windowing, etc. One instance of a class maps to one client; when client goes away so does this instance (at least, I no longer care if the garbage collector marks it as garbage). Makes OO live more peacefully with concurrency.

Awesome that Python enforces this design by default. Really, the more I discover about Python, the lovelier programming gets.

‘Till I get my February experiments done! ~Chad