Skip navigation

Tag Archives: python philippines

The end of February was remarkable for a couple of things. First was PyCon Philippines 2014. I’ve already mentioned here a bit of my involvement with Python Philippines. I’ve noted my presence in Python Philippines’ monthly meet-ups. It is no secret that we’ve been working towards another PyCon Philippines.

PyCon Philippines 2014

I must say, organizing a conference is really a taxing job. Kudos to the volunteer team who worked really hard behind the scenes. And while yours truly was listed everywhere as a volunteer, it would be terribly unfair to compare the effort I spent compared to the effort of some others.

For day two, I was a speaker in behalf of Chikka. Chikka sent in a delegation of 26 corporate attendees. However, I was not able to finish day two because I had a flight to America scheduled. You see, I was in for an interview with the Google.

Yes! It has always been my dream to work on the type of problems which Google is tackling. I never thought that, as early as now, I’d be able to score an interview with them, at the Mountain View campus, no less. I did not get in but I’m no less grateful that I’ve had this opportunity.

While this whole adventure deserves a whole post on its own, let me end with the update I had at my Facebook profile after the closing phone call came.

When Google came calling

TL;DR: Nope, not yet. Still, thanks to everyone who wished me luck. This experience was definitely fun. Maraming salamat! (–,)

It started one Saturday morning in October last year. I received an email from an “@google.com” email address. He claimed to be a recruiter from Google who got impressed with my GitHub resume.

Now, prior to this I’ve already received a number of recruiting calls due to my GitHub and my PythonPH involvement. But, hey, Google? The Google? Just. Wow.

So…okay, I just sent in a copy of my proper resume as the recruiter wanted. Weeks passed without hearing anything from the recruiter. Until December.

He had me scheduled for a 15-minute phone interview. I thought that Google will finally have developer operations in the Philippines. During this 15 minute interview, it became clear to me that I’m interviewing for a position at their Mountain View campus. The interview went fine which led to a 45-minute technical phone interview in January. Apparently, they got impressed with it as well because they eventually had me for an onsite interview.

After some bureaucratic fiascos with travel documents, I finally managed an onsite interview during the last week of February. Google had me for an all-expenses paid US trip. I was in California for around four days.

I’ve been to a number of interviews already and I must say, Google is really different. They call it a panel interview but I think a better term is “circuit interview”. And it was more like a mentorship session than anything. No pressure, just geek-to-geek chat.

I managed to answer all of the problems they gave me which is to say I performed better than I expected (haha!). I just got a call saying I did not make it but getting from that October email to that closing phone call is still quite a ride.

I’m 21, college-age in America’s educational system. I’ve less than two years industry experience, while most of Google’s job openings require at least three. I did not approach Google; Google approached me. I think I’ve earned the right to be very proud of this experience.

Yay! \(^_^)/

The longer Story, sometime soon!

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.