Vincent's Blog

Debian contributions in November 2024

2024-12-15T21:32:00-08:00

Over the Thanksgiving holiday weekend I finally had some spare time to catch up and ensure the Debian packages I maintain are in good shape. I figured I'd blog about it too, in an effort to get back into blogging and sharing my thoughts a bit more frequently.

Package uploads

0ad

Updated from 0.0.26-7 → 0.0.26-8.

This upload was mostly prepared by another Debian Games team member, Antoine Le Gonidec, to fix a RC bug; I took the opportunity to also fix a FTBFS-when-building-twice bug (#1087990) as well as some general housekeeping — stdver bump, adding missing DEP-3 patch headers, and fixing some lintian issues.

conky

Updated from 1.21.6-1 → 1.21.8-1 → 1.21.9-1.

Straightforward package updates to pull in new upstream releases, along with some minor build-dep updates.

excellent-bifurcation

Updated from 0.0.20071015-10 → 0.0.20071015-11.

This was mostly just refreshing the package. I took the opportunity to drop a broken watch file and fix the packaging so that build hardening flags were properly passed.

mypaint / mypaint-brushes / libmypaint

mypaint: 2.0.1-10 → 2.0.1-11.

mypaint-brushes: 2.0.2+ds1-1 → 2.0.2+ds1-2.

libmypaint: 1.6.0-2 → 1.6.0-3.

I cherry-picked an upstream patch to fix a segfault in mypaint (#1079663), updated all three packages with a valid watch file provided by another Debian contributor via the BTS (#1051225), fixed FTBFS-when-building-twice bugs (#1047680 and #1045412), and some general housekeeping.

pdfarranger

Updated from 1.11.0-1 → 1.11.1-1.

Straightforward package updates to pull in a new upstream release, along with some minor build-dep updates (dropping python3-pkg-resources, #1083534).

pelican

Updated from 4.9.1+dfsg-4 → 4.10.2+dfsg-1.

This was primarily to pull in a new upstream release as well. Also dropped python3-pkg-resources (#1083538) as well as pulling in a patch from the reproducible builds team (#1056571) and forwarding it upstream. I also spent time adding in a proper autopkgtest that runs pelican to generate a simple blog.

I also took the time to update this blog to use Pelican 4.10 as well. Upgrading from 4.9 was relatively painless; fortunately none of the plugins I use broke or are otherwise incompatible.

pikepdf

Updated from 9.1.1+dfsg-1 → 9.4.2+dfsg-1.

Straightforward package updates to pull in a new upstream release, along with some minor build-dep updates (#1083543).

pygame

Updated from 2.6.0-2 → 2.6.1-1.

Another straightforward package updates to pull in a new upstream release. In a previous binNMU attempt, another flaky test specific to the s390x arch was identified (#1087608), so I ignored it by adding to the existing s390x-specific patch in the package. AFAIK upstream actually runs their tests in their CI pipeline against s390x so this is somehow solely flaky on Debian buildds. Oh well.

slashem

Updated from 0.0.7E7F3-11 → 0.0.7E7F3-12.

This package was removed from Debian testing several months back because of a RC bug, an unfixed build failure with gcc 14 (#1075515). I cherrypicked a set of patches from Fedora to fix this, and did some general housekeeping as well.

supertux

Updated from 0.6.3-2 → 0.6.3-3.

This was mostly just general housekeeping — stdver bump, missing DEP-3 patch headers, dropping obsolete build-deps, and updating the package's watch file (#1038393) with a patch supplied by Patrice Duroux.

wesnoth-1.18

Updated from 1:1.18.2-1 → 1:1.18.3-1.

This was a straightforward update to pull in the latest upstream release of The Battle for Wesnoth. Along the way I also closed #924437 since upstream removed support for OpenMP several releases ago.

As usual, when I do package updates for Wesnoth, I also backport it to Debian stable via backports, and Ubuntu via my wesnoth PPA. For some unknown reason, dak seems to insist that backports for Wesnoth need to go through backports-NEW, which makes no sense as this upload has the same set of binary packages as before. I've reached out to ftpmasters and the backports list for advice (multiple ... times ... actually), but currently I'm still unable to backport Wesnoth for Debian bookworm. Sorry if you happen to be using this backport and are wondering why it's taking so long. ☹

Miscellaneous stuff

Most of my contributions this month involved package uploads. Aside from that though, I noticed that a handful of my own packages and team-maintained packages were out of date in salsa (mostly due to NMUs) so I went ahead and updated them to match their current state in the Debian archive. All of them used git-buildpackage so I just grabbed what I needed from snapshot.debian.org and imported them with gbp import-dsc --pristine-tar ... as usual.

Setting Up Secure Boot on Ubuntu Linux

2023-01-22T19:44:00-08:00

I recently had to replace my motherboard on one of my PCs with a Nvidia GPU, which meant I had to figure out how to get Secure Boot working again with out-of-tree Nvidia kernel modules. Maintaining self-signed kernel modules is automated and zero-effort with dkms, but the initial setup takes a bit of legwork, so I figured I may as well document it for future reference.

This blog post specifically covers the use case of using a signed, standard distribution kernel provided by Debian/Ubuntu and using shim-signed to provision self-signed out of tree kernel modules that are registered with dkms. I'm explicitly not covering non-distribution kernels or kernel modules managed without dkms. Also, to state the obvious, this is only useful if you choose to have Secure Boot enabled. This guide should work for any non-ancient releases of Debian/Ubuntu that come with signed kernels; I know this definitely works from Ubuntu 18.04 LTS and above, but if in doubt check to make sure the shim-signed and mokutil packages came pre-installed.

On Ubuntu, shim-signed's postinst script generates a self-signed certificate, located in /var/lib/shim-signed/mok/MOK.{der,priv}. If these files are missing or you want to generate a new MOK key for whatever reason, run:

$ sudo update-secureboot-policy --new-key

AFAIK this is currently not the case in Debian, where you need to handle MOK generation yourself; refer to bug #989463. Also note that everytime you regenerate a MOK key you will need to re-enroll your keys, so you may want to include /var/lib/shim-signed/mok/MOK.{der,priv} in your scheduled backups (you do have backups, right?) and restore your MOK key if you ever need to reinstall your OS, whichever option is more convenient for you.

The next step is to enroll your MOK key. This is as simple as running:

$ sudo mokutil --import /var/lib/shim-signed/mok/MOK.der

This will prompt you for a one-time password. When you next reboot, instead of seeing the normal Grub menu, you'll instead see a UEFI key management shim screen, where you will need to enter that password to enroll your MOK key. If for whatever reason this fails, copy /var/lib/shim-signed/mok/MOK.der onto a FAT32 formatted USB drive, reboot into your motherboard's UEFI/BIOS setup menu (this will often be done by spamming F2 or Delete during boot, but check your motherboard's manual to be sure), and then dig through various menus until you find Secure Boot and key enrollment menu options, and add your key.

Sanity check that your key was successfully added with:

$ sudo mokutil --list-enrolled # your key should appear in the output, or
$ sudo mokutil --test-key /var/lib/shim-signed/mok/MOK.der
/var/lib/shim-signed/mok/MOK.der is already enrolled

You'll also need to check whether Secure Boot is enabled and enforced on your PC. This can be verified by running:

$ sudo mokutil --sb-state
SecureBoot enabled

If you do not see SecureBoot enabled, enable it by running:

$ sudo mokutil --enable-validation

When you next reboot, you'll again see a UEFI key management shim screen where you will be prompted to enable Secure Boot. Unfortunately this threw a rather non-descriptive error message with my Asus Z370-I motherboard and I had to go into UEFI setup (spam F2 during boot), go into the Secure Boot settings, and turn on "Windows UEFI mode" instead of "Other OS" to enable Secure Boot enforcement/validation. Once this is done, check sudo mokutil --sb-state to make sure it says enabled.

You can also check that Secure Boot enforcement is on and that your MOK key was successfully enrolled and in-use with dmesg, e.g.:

$ dmesg | grep "Secure Boot"
[    0.000000] Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7
[    1.010698] Loaded X.509 cert 'Canonical Ltd. Secure Boot Signing: 61482aa2830d0ab2ad5af10b7250da9033ddcef0'
[    1.018091] integrity: Loaded X.509 cert 'local_hostname Secure Boot Module Signature key: a0f5a8de9ffbef64e52df5c9b34b83e105287643'

From this point onwards, any and all kernel modules that are built by dkms should be signed with your MOK key. If you already have nvidia kernel modules (or any other out-of-tree modules) built before you generated a MOK key, and you want to rebuild them with dkms, you can do so by e.g.:

$ sudo dkms uninstall -k 5.4.0-90-generic -m nvidia -v 460.91.03 # replace kernel and module name/version as needed
$ sudo dkms install -k 5.4.0-90-generic -m nvidia -v 460.91.03 # replace kernel and module name/version as needed

To recap, to get Secure Boot working with a distribution kernel and out-of-tree modules:

Enable Secure Boot validation.
Enroll your MOK key in your motherboard's UEFI firmware.
Sign your out-of-tree kernel modules with your MOK key.

Step 3 has to be done every time you update your kernel or your kernel module packages, but fortunately this is all handled by dkms for you, without any user intervention (and if you depend on out-of-tree modules but aren't using dkms, this is a strong incentive for you to start using dkms). Steps 1 and 2 are effectively one-time operations; they only need to be done if you replace your motherboard, wipe your enrolled keys in your motherboard's UEFI key management screen, or reinstall Debian/Ubuntu without backing up your enrolled keys.

If for some reason you wanted to manually sign a kernel module, you can do that by running:

$ sudo kmodsign sha512 /var/lib/shim-signed/mok/MOK.priv /var/lib/shim-signed/mok/MOK.der /path/to/kernel/module.ko

Further reading on Secure Boot integration in Debian/Ubuntu if you're curious:

Reviving My Blog and Embracing Serverless

2023-01-18T22:38:00-08:00

Hello again, world! For the last several months, this blog was offline simply because I neglected to renew the VPS that I was hosting it on, and I didn't bother to rectify the situation since this blog was always a hobby project to begin with. I finally scrounged up some spare time over the winter holidays to do just that.

Several years back I migrated from Wordpress to Pelican for a variety of reasons, one of them being the reduced maintenance burden at a much lower cost. At the time I thought hosting a static blog on my own self-maintained VPS/cloud server would be sufficiently low maintenance, but that was back when I was still in university with ample time in my hands, and back when simple sysadmin tasks were a learning opportunity for me. I no longer enjoy self-inflicted hobbyist sysadmin work and my dayjob as a software engineer has me carefully rationing my spare time.

"Serverless" and "JAMStack" at this point may have become overly marketed buzzwords (or so goes the sentiment on Hacker News), but the core idea of taking the maintenance burden of self-hosting / paying for hosting, and offloading that to a CDN of my choice, definitely appeals to me now.

With all that said, I've migrated my Pelican-based static site to Cloudflare Pages, mostly because I already use Cloudflare DNS and Pages was easy to setup and use, with no need to involve yet another vendor. Github Pages was something I also briefly considered, but Github Pages doesn't support non-Jekyll static site generators, and using Pages to build my site for me gives me a free CI pipeline and one less thing to maintain (I can get straight to updating my blog without having to rebuild my dev environment if I'm not in front of my PC). Netlify is also another contender of course, as are other CDNs and vendors, but then I have to deal with the friction of a platform/product that I don't already use.

If you end up deploying your Pelican-based blog to Cloudflare Pages, Cloudflare has pretty good documentation to get you up and running. One thing I would point out here is that pelican-quickstart by default will generate two different configuration files, pelicanconf.py for dev-specific and general settings, and publishconf.py for production-specific settings. If you enter pelican content as the suggested build command in Cloudflare Pages, pelican is only going to read your pelicanconf.py and ignore your prod-specific settings - so if you're wondering why e.g. your Disqus comments aren't appearing, or worse, everything on your deployed site links to localhost:8000, that would be why. Make sure you call pelican content -s publishconf.py to have pelican build your site with the desired settings. Also be aware of what platform limits are in place for Cloudflare Pages.

My end goal is to make this blog as easy to maintain as possible, while doing my best to avoid vendor lock-in. With that in mind, I've tried to avoid depending on too many Cloudflare-specific features and functionality, but some of it was inevitable:

SSL (to be fair this comes out of the box with no further configuration)
www -> apex redirects with Cloudflare bulk redirects (instead of e.g. apache mod_rewrite), along with apex CNAME flattening
404 error handling

All in all, I'm happy to have embraced serverless for my personal blog. I can make changes simply by pushing to Github and have them live in less than a minute. Hosting my blog on a CDN guarantees it'll have better uptime and reliability than I could ever hope to achieve (I'm pretty sure I lose out here just by having to restart apache to apply patches, on my server). And, of course, there is practically zero maintenance overhead for me to deal with now. The only way for my site to go offline now is if I forget to renew my domain (which will not happen because that would take my email with it as well, and that is something I would definitely notice).

Review: Being a CPSC 210 TA

2015-06-25T02:32:00-07:00

Last term (2014W2, or Jan-Apr 2015), I had the opportunity to be a teaching assistant (henceforth abbreviated as TA) for CPSC 210: "Software Construction", which is part of UBC's CPSC software engineering stream. I've already reviewed 210 as a student in an earlier blog post; instead, this blog post will be somewhat different than my regular course reviews, being written from the perspective of a TA rather than a student in CPSC 210. There are a number of blogs out there that offer reviews of various UBC courses, but none that talk about what it's like to be a TA, so I hope other UBC students (and maybe even prospective TAs) might find this interesting.

It's worth pointing out that I was a 4th year undergraduate student when I TA'ed for 210, not a graduate student. My understanding is that for many (most?) faculties, e.g. Arts, TAs are for the most part all grad students, and TA-ship serves as one of their sources of funding for their graduate studies. However, in UBC's Computer Science department, all of the lower level CPSC courses (and a few of the upper level ones as well) are open to undergrad TAs. I've gotten the impression that the CS department seems to be perpetually searching for student candidates to serve as TAs for CPSC courses, and that there aren't always enough candidates, which may be why TA positions are open to undergrads rather than restricted to graduate students. If I remember correctly, all of my fellow 210 TAs were all undergrad students like me, except for a single grad student who took on administrative duties.

Let's start off by talking about how to apply for TA-ship. The process may be completely different for other faculties/departments, but for CPSC, it involves filling an online form that's fairly brief and straightforward. It'll ask you to fill out some basic information about your identity, then select courses that you're interested in TA-ing, and then explain your qualifications. Once you've submitted your application, all you have to do is wait to hear back from the department; you'll get an email regardless of whether you were accepted or rejected about a month or so before the term starts. If you're offered a TA position, you're given one week to either accept or reject it, and from then on you'll interact directly with the instructors of that course and/or the TA that's involved in coordinating everything for that course (the instructors for CPSC 210 in 2014W2 were Gail Murphy and Elisa Baniassad, just for the record). I don't know if that TA actually has a formal position or anything, but I'll refer to him/her as the "lead TA" for the purposes of this blog post.

During the first week you'll hear back from the department (via email from undergrad-info@cs.ubc.ca) regarding payroll stuff. To summarize, as an undergrad TA and a member of CUPE 2278, you'll be paid biweekly a non-negotiable wage of $14.75/hr (at time of writing) for a maximum of 12 hours/week. The amount of time you work per week has to be a "reasonable" amount and balance, i.e. you may be asked to work more than 12 hours in any given week (e.g. exam periods), but it has to balance out by less hours in other weeks. You also have to regularly submit paper timesheets to receive pay, and you'll have to submit your banking info to UBC Payroll before you get paid, so there'll be a bit of paperwork for you to clear during the first week.

In the first few weeks of the term, you'll also be assigned a TA buddy if you requested one and are a new TA. Your TA buddy will simply be someone that you can ask general TA-related questions (and who will likely get back to you with an answer faster than the CS department ever will).

To wrap up the administrative stuff, shortly before the start of the term, the instructor or TA in charge of administrative tasks will email you to ask about your schedule, and then assign duties like labs, "lecture labs" (210-specific?), and office hours to each TA. For CPSC 210, we were all assigned hours from 2 of the above 3 categories; I was assigned two 2-hour lab slots and 3 hours worth of office hours in the DLC (Demco Learning Centre) per week. This is in addition to a mandatory 1-hour weekly meeting that we had on Thursdays, which makes up for a minimum of 8 hours/week during the term that I spent on TA-related work. I consider this to be roughly equal to the workload of an average UBC course; as a TA, you should be mindful of the fact that the time investment you dedicate to TA-ing is not insignificant. I initially thought that office hours would be a quiet relaxing time for me to do my own homework, since I rarely went to office hours myself and expected it to be fairly quiet. I was quickly disabused of this notion, since I was very often kept busy during the entire duration of both my office hours and my lab sections. That was especially true near the end of the term; as you may well know, CPSC 210 has a fairly lengthy and work-heavy term project that many students struggle with.

Weekly meetings were a chance for us TAs to discuss anything relevant to the course that occurred the week prior, or about to come up the following week. These meetings were often a discussion about common issues in labs and assignments, or issues raised by students on Piazza, or about upcoming lecture labs, or later on about the term project, etc, and provided all of us a chance to ask questions if we were unsure about anything. We were often given a quick rundown as to what to expect in the upcoming week's lab sections, and informed of any additional duties like exam grading during this time.

For CPSC 210 labs, amongst the group of 3 TAs that taught each lab section, we would have one TA do a brief introductory lecture/presentation about the lab, and one other TA take care of marking for the previous lab; we would rotate between these responsibilities every week. We would usually have some sort of pre-made material for us to present, e.g. a set of PowerPoint slides, or a small Eclipse project that would demonstrate the key concepts taught in that week's lab, or even just a list of topics to briefly discuss, although TAs were free to make their own presentations. The marker TA would go through, err...*cough*...a "randomly" selected group of students, a "random" number of times, to mark their labs and ask questions to ensure that students understood what they were doing. (While the process may or may not actually be random, the intended goal is to encourage students to do all the labs even though TAs couldn't possibly mark every person for every lab.)

Office hours for 210 actually felt a lot like labs, in the sense that your job was to help students that came to you with questions about the course. There would typically be anywhere in between 3-12 students coming to me during my office hours, and most of the time questions were asked about either that week's assignment or lab, and later on in the term, the term project. Rarely would questions be asked about lecture material, which surprised me somewhat, but I reckon students often struggled more with labs and assignments than they did with lectures. The questions would often fall into one of two categories: either questions to clarify ambiguity in the lab/assignment or to give an explanation about the material covered in the lab/assignment, or a request to look at the student's code and fix it. The latter is rather undesirable because a "look at my code and fix it" attitude doesn't typically inspire the desire to learn (but I can understand where it's coming from, having been a 210 student myself a few years ago). What I usually do then is just give a few pointers/hints as to where to proceed if they get stuck, and/or go over debugger usage in Eclipse/Intellij IDEA/Android Studio if they still do not understand how to debug their code to fix it. TAs are obviously not supposed to actually fix students' code on their behalf, of course.

For CPSC 210 specifically, I actually think debugging is a concept that should be stressed more, because a lot of students seem to still have no idea how to use a debugger to debug their code even by the time they've started to work on their term project halfway through the term. I've also gotten the impression that students expect me to look at their code and just know what's wrong with it. Protip: sorry to disappoint, but TAs are not omniscient. However, TAs tend to be quite good at debugging code; when it comes to helping students especially with the project, asking them to start up their debugger and stepping through their code with them if needed (with them, not for them) is usually enough to figure out the problem and have an idea as to how to fix it. More often than not, the first thing I say when students come to me for help with the project is, "Have you tried debugging your code yet?"

It's worthwhile to note that for CPSC 210, TAs get solutions for the labs, but NOT for the assignments or the project. And because the term project changes from term to term, yes, as a 210 TA you'll end up doing the term project yourself just so you can anticipate what kind of questions students will ask you, and also so you have an idea of how the application should behave when students demo their term projects at the end of the term.

Another timesink is exam invigilation and marking. Exam invigilation as a TA is incredibly boring; I wasn't allowed to answer any questions from students, hence my job was to simply walk around a lecture hall for 2 hours or so. 210 makes invigilation slightly less boring because students are required to have a computer with them so they can refer to code checked out from a SVN repository, and a little bit of effort is required to make sure that nobody tries to cheat. Oh, I've never TA-ed for Steve Wolfman before, but from what I've heard from other TAs, apparently Steve invented "invigilation tag", in which TAs who are invigilating try to sneak up on fellow TAs to quietly tag them without students noticing. ;)

Exam marking is much more of a timesink than invigilation, however. CPSC 210 that term had 1 very lengthy midterm, and it took roughly 8 hours (on a Saturday!) to mark everything. TAs also took part in marking the final exam, which was done over 2 days and took roughly 11-12 hours in total IIRC. Both exams were marked in a similar fashion. TAs would gather around a few tables with giant stacks of exams, armed with red pens and whiteout. We'd all mark the same question at the same time, with the instructors first presenting the answer key and marking scheme; TAs were free to ask questions if there was any ambiguity, either with the answer key or with an individual student's exam. It wasn't entirely rare for the marking scheme to be modified slightly after some discussion once we got around to marking enough exams and seeing certain patterns, in which case we would have to dig through already-marked exams to apply the new marking scheme (I recall using a non-trivial amount of whiteout). Once a question was completely marked, we'd then move on to the next question and repeat the same process. It goes without saying that the open-ended questions on the exams were the toughest to mark; in some ways they were also...entertaining to mark, given the wide variety of answers (and hard-to-follow code) that students can come up with. Or just downright frustrating.

Note to students: please don't think writing as much as possible is always a good strategy. Digging through spaghetti code to find a few metaphorical gold nuggets that are worth actual marks can be really frustrating for your marker!

As a TA, you are also expected to answer questions on Piazza, the external discussion board used in CPSC 210 and many other CPSC courses at UBC. The system we used during that term was that you needed to answer any questions coming from a student in your lab section to spread the work around fairly. In reality, Gail (one of the instructors) answered a disproportionately large number of questions (IIRC according to the Piazza stats, she had more than a thousand posts by the end of the term), while few TAs had more than a hundred (heh, shame on us!). Piazza is a heavily used resource in 210, even more so during the lead-up to project deadlines; for the most part though, I got the impression that questions asked on Piazza were usually replied to in a prompt manner.

If you're looking for reasons to be a TA, well, I think the most rewarding aspect of the entire TA experience is engaging with students and helping them out with course material, during both labs and office hours. Being able to explain something is one of the more effective ways of demonstrating comprehension/understanding, so in many ways it's a learning process for you as the TA as well. There's also that feeling of accomplishment when you're able to pinpoint the source of a student's struggles or misunderstanding and help fix whatever the issue is. (Conversely, there's that sense of embarrassment when you don't quite know what's going on either and end up suggesting that the student asks on Piazza or the instructors.) For me, as an introvert, it was also the opportunity for me to step out of my comfort zone a bit and engage with others...although I'm still very much an introvert. I suppose being a TA also looks nice on your resume or LinkedIn profile. Other than that, there's also the fact that you get paid for being a TA, but frankly the pay you get as an undergrad TA sucks, given that you'll typically earn a lot more on CS co-op terms or as a private tutor. Heck, quite a few on-campus Work Learn positions pay better than being a TA, so if your primary motivation is money, you may end up disappointed; getting paid to be a TA is just a nice perk on top of everything else.

Review: CPSC 320, 404

2015-06-23T01:12:00-07:00

I took CPSC 320 and 404 this year (in 2014W2) along with a few electives, right after my second 8-month co-op stint. I actually took a lighter workload than I would usually take during regular winter sessions, in part because I was also doing a TA-ship for the first time (in fact, I've gone ahead and wrote a review about my TA experience). Keep on reading for my thoughts about these two upper-level CPSC courses.

CPSC 320:

In a nutshell:

Language: none in particular

Toolset: again, none in particular

Prereqs: CPSC 221, and either (a) 6 credits of 2nd year MATH or STAT or (b) 3 credits of 2nd year MATH or STAT with a grade of 72% or better. The MATH/STAT credits that you'll use to satisfy these prereqs are likely to come from a combination of MATH 200, MATH 221, and STAT 200+302 / STAT 241.

Website/resources: CPSC 320, Piazza

Textbook: Algorithm Design by Kleinberg and Tardos

Presenting CPSC 320, known as "Algorithms and Dating Advice"...according to our assignment hand-in box, at least:

CPSC 320, more formally known as "Intermediate Algorithm Design and Analysis", is a sequel/successor of sorts to CPSC 221; it covers a bunch of different algorithms and paradigms not covered in CPSC 221, with little overlap (you'll be given a review of asymptotic analysis and notation, e.g. big O, omega, theta, etc., and as you might expect, proofs and proof techniques are still very much relevant). In my opinion, CPSC 320 isn't nearly as broad as its predecessor, but it is still just as dense and material-heavy. The broad categories that you'll cover during the course include graphs, greedy algorithms, divide-and-conquer algorithms, recurrences, memoization, dynamic programming, and NP-completeness. I believe the course is also supposed to cover randomization and amortized analysis (judging by the syllabus provided for previous terms), but we didn't really have time to get to that this term.

I think it's helpful to point out the learning goals for the overall course (quoting from the syllabus):

Recognize which algorithm design technique(s), such as divide and conquer, prune and search, greedy strategies, or dynamic programming was used in a given algorithm.
Select and judge several promising paradigms and/or data structures (possibly slightly modified) for a given problem by analyzing the problem’s properties.
Implement a solution to a problem using a specified algorithm design paradigm, given sufficient information about the form of that problem’s solution.
Select, judge and apply promising mathematical techniques (such as asymptotic notations, recurrence relations, amortized analysis and decision trees) to establish reasonably tight upper and lower bounds on the running time of algorithms.
Recognize similarities between a new problem and some of the problems they have encountered, and judge whether or not these similarities can be leveraged towards designing an algorithm for the new problem.

In essence, I feel like CPSC 221 was all about giving you the basic toolkit you needed to understand algorithms, learning about the core data structures that you'll see appear over and over again (e.g. lists, trees, graphs, etc.) and common algorithms that are applicable everywhere (e.g. sorting, hashing, etc.); CPSC 320 is about building on that knowledge and applying it to a wider variety of problems, as well as a more directed focus on finding more efficient ways of solving a given problem (or whether that's even possible to begin with). It's definitely a course worth taking if you found CPSC 221 even remotely interesting. Fair warning though, I consider this course to be the most difficult 3rd year CPSC course I've taken to date (compared to CPSC 304, 310, 313, and 317), both in terms of workload and also the difficulty of the material that's assigned and taught.

Dr. Steve Wolfman taught this course when I took it. For those who've taken previous courses with him, you should already know what to expect: highly interactive lectures, and a very hands-on approach to problem solving in-class. In fact, lectures involve very little lecturing; instead, the bulk of class time was spent working on problems with your immediate neighbours, with Steve periodically giving out hints and then solutions near the end of class. As a result, you're supposed to do all the readings outside of class and in advance to the lectures so you were able to actually work on the problems. I'm generally quite a fan of his interactive style of teaching, although I admit that I'm not very diligent when it comes to pre-reading.

Another peculiarity with courses taught by Steve is evening group midterm exams and group finals. How this works is that when you take an exam, you first take it individually, and then you take the same (or very similar) exam again as a group of 3-5 of your fellow classmates; your resulting exam mark is derived from 85% of your individual mark and 15% of the group mark (with the individual mark being worth 100% if higher than the group mark, so you'll never get penalized for doing the group exam). As a result, you get immediate feedback on how you did; for me, that often translates from a mental thought process of "I think I did well on the exam" after taking the individual portion, to "oh crap, I answered this and that and everything else wrong so I must have totally bombed that exam" after the group exam. :P

It's also worth noting that the exams were all open-book, i.e. you were allowed to bring the textbook and 3 binders worth of notes if you desired to do so. In reality, that provides little more than just a boost to your confidence; it's unlikely you'll have enough time during the exam to fully utilize your notes, and Steve's exams will test you on how capable you are at applying the theorems and algorithms you've learned, not on how well you can regurgitate material.

Assignments are quite heavily biased towards theory and applying the concepts you've learned from class and the textbook, with very little coding involved; I recall only 1 of the 7 assignments actually involved any coding. They're also considerably time-consuming, so I highly recommend finding a partner (you're allowed to work in groups of 2 max) and working on them in advance of the due date.

Grading consisted of 7 assignments worth 20%, 2 midterms worth 30% total, lecture pre-reading quizzes (of which there were about ~20) worth 1% total, a final exam worth 45%; the remaining 4% goes towards whichever component above you did best in. Unlike most other Science courses, you do not need to achieve >50% on the final to pass; instead, you had to achieve >50% on the weighted average of the midterms and the final exam (as well as the overall course itself, of course), which was a relief to me as I thought the final was considerably harder than the midterms and I was somewhat worried that I might not have passed it. It's worth noting that I'm unsure whether this applies to just Steve's CPSC 320 sections, or all sections of the course taught by other professors as well.

CPSC 404:

In a nutshell:

Language: relational algebra, SQL

Toolset: exposure to a number of RDBMSs, including IBM's DB2 and Microsoft SQL Server

Prereqs: CPSC 213 and CPSC 304

Website/resources: CPSC 404; most of the course material is on Connect, with Q&A on Piazza

Textbook: Database Management Systems, 3rd ed., by Ramakrishnan and Gehrke (same as CPSC 304!)

CPSC 404, a.k.a. "Advanced Relational Database Systems", is as you might expect the sequel of CPSC 304. 304 serves the purpose of introducing you to relational databases (which I'll abbreviate to RDBMS from now on), including some of the necessary theory you need to understand like E-R models and relational algebra, and then actually using a RDBMS (e.g. by learning SQL syntax and being able to write out SQL queries). CPSC 404, on the other hand, dives into the nitty gritty internals of a RDBMS, focusing on how RDBMSs are implemented as well as the underlying data structures used by many RDBMSs. Therefore, if you're thinking of taking CPSC 404 with the intent of becoming a better DBA or to brush up on SQL, you'll probably be disappointed. On the other hand, if you're interested in learning more about what goes on behind the scenes in a typical RDBMS, the course material should be relevant to your interests.

You'll start off by learning about learning about topics like storage/memory hierarchy, buffer pool management, and I/O costs; calculating and comparing page I/O costs will be a prevalent theme throughout the entire course, and most of the calculations you'll be doing involve calculating I/O cost one way or another. That's followed by more than a month of lectures on both tree-structured and hash-structured indexes, data structures used to represent and maintain indexes, time/space complexity of common operations (insert, update, delete) performed on these data structures, and hashing; this includes hashing methods that were previously covered in CPSC 221 like static hashing, and methods that weren't, like extendible hashing and linear hashing. You'll see B+ trees again during this unit, which is another source of overlap with CPSC 221. This is followed by external sorting, including external mergesort and 2PMMS (the motivation for this is that regular in-memory mergesort like the one you learned in CPSC 221 doesn't account for the I/O overhead in RDMBSs). Next up is coverage of query evaluation and optimization, followed by a few weeks of cramming in data warehousing. Overall, I found the material to be quite straight-forward but dry at times, with the exception of the last unit on data warehousing which I found to be very confusing (I don't think cramming in this bulky unit in the last few weeks of class helped much).

CPSC 404 has a fairly standard marking scheme, with a combination of 2 assignments (4% each), 4 in-class midterms (10% each), pre-class and in-class exercises (10% total), clickers (5%), a final exam worth 37%, and 1% bonus for filling out surveys. The two assignments involved using Microsoft SQL Server and SQL Server Management Studio and running through a very detailed set of instructions with a partner (the assignment PDFs were 40-50 pages long, most of which was along the lines of "click this button" or "open this dialog box" or "type in this query" etc.), with questions and a brief Q&A follow-up with a TA. To be honest, I didn't find the assignments all that helpful; they were quite tedious, and the data warehousing assignment in particular was just confusing. I think the pre-class and in-class exercises, which were brief and to the point, were much more enjoyable and instructional.

Dr. Ed Knorr was my instructor for this session of CPSC 404, and this was the first time I took a class taught by him. I found him to be an approachable and overall effective professor, and he's clearly very passionate in the subjects he teaches, although I feel like he has a tendency to go off on unrelated tangents during lectures sometimes. He also has a mild-mannered voice which was a contributing factor to me falling asleep in class more than once (although lack of sleep was the predominant factor, of course, and that's purely my own fault).

Review: CPSC 313, 317

2015-06-22T23:21:00-07:00

Again, a set of long overdue reviews for a bunch of 3rd year CPSC courses that I took in 2013W2, hopefully in time for fellow students who are considering registering for these courses. Enjoy, and as always let me know if you have any feedback; comments, questions, or suggestions are all greatly appreciated!

CPSC 313:

In a nutshell:

Language: Java, Y86 (a subset of x86 assembly used in this course)

Toolset: Eclipse, your preferred text editor

Prereqs: CPSC 213 and CPSC 221

Website/resources: CPSC 313, Piazza

Textbook: Computer Systems: A Programmer's Perspective, 2nd ed., by Bryant and O'Hallaron

CPSC 313 is more formally known as "Computer Hardware and Operating Systems", and is the spiritual successor of CPSC 213. If you've already taken (and enjoyed) 213, you should feel right at home here, since the focus is on many of the same topics taught in 213, only in far more depth. Instead of using the imaginary SM213 assembly language again, however, you'll be using a subset of x86 as taught by the textbook, i.e. Y86. You'll start off by learning the basic set of instructions provided to you by Y86, followed by designing and implementing a sequential CPU, then doing the same thing for a pipelined CPU. These topics will cover about a half, or slightly more, of the course; the remaining time will be spent on exploring caching, memory hierarchy, file systems, and virtual memory. While there might be small bits of overlap here with CPSC 213, most of the material covered in 313 is either new or dealt with in much greater depth.

Your total grade will be based on occasional in-class group exercises (5% total), 5 assignments (25% total), 2 midterms (25% total), and a final worth 45%.

It's worth pointing out that the pace of this course is very quick, more so than any of the other courses I've taken so far in 3rd year CPSC, and a lot of material builds on top of previously covered material. As such, you definitely want to stay on top of things, and ask questions early and often if you find yourself not understanding a concept taught in class (luckily there's Piazza for that, as well as tutorials). Also, tutorials are generally worthwhile in this course, so either go to them or do the tutorial exercises yourself. There is no term project, but there are 5 non-trivial assignments that may take up a considerable amount of time depending on your familiarity with the material taught in class. Assignments may consist of tasks as simple as adding an Y86 instruction to your simulator, to debugging problems in an implementation of a Y86 simulator, to eventually implementing things like data forwarding and branch prediction in your simulator; these tasks will involve writing code in either Y86 or Java (the simulator itself is written in Java). You can work in groups of 2 max, so definitely take advantage of that.

Dr. George Tsiknis is an amazing prof; he's very passionate and enthusiastic about the material he teaches, and he's quite fun and lively in class. It's also worth pointing out that his lecture slides are pretty awesome as well, and help to illustrate concepts that would otherwise be difficult to understand. However, he does have a strong accent that may take a while to get used to.

CPSC 317:

In a nutshell:

Language: C, Java

Toolset: Eclipse, your preferred text editor, GCC on the department Linux servers

Prereqs: CPSC 213 and 221

Website/resources: CPSC 317, Learning Catalytics, Piazza

Textbook: Computer Networking: A Top-Down Approach, 6th ed., by Kurose and Ross

CPSC 317, a.k.a. "Internet Computing", serves as UBC's introductory computer networking course. That's a very broad subject in of itself, and the topics covered by the course are also quite broad; you'll cover a bunch of communication protocols, and learn about key pieces of networking infrastructure, the protocol stack and the responsibilities of each layer, and some key paradigms and strategies such as isolation, data loss (and mitigation), performance, layers and abstractions, etc. You'll also touch upon bandwidth and latency, multimedia, reliability, peer-to-peer, and security/privacy (there was even a lecture that covered PGP fundamentals, which was a bit of a surprise to me). However, due to the breadth of topics covered, you actually won't go into much depth for many of the above topics in 317.

The marking scheme is as follows: 4 assignments (21% total), 4 quizzes (26% total), and a final exam worth 53%. Yes, those numbers are quite weird, but they do add up to 100.

The one thing in particular I wanted to point out about my CPSC 317 experience was the level of difficulty of the assignments, and the disconnect between the assignments and the material covered in lecture. The course itself and the material taught in class are quite straightforward, but I felt the assignments were much harder in comparison. I distinctly remember (even 2 years after the fact!) that one assignment in particular, which IIRC involved writing a FTP client, was sufficiently difficult that the instructor claimed 3/4 of all students in the class would've gotten a big fat zero on the assignment with what was handed in by the class on the due date; he did however end up giving the entire class an extra week to ask questions and finish the assignment. The other assignments were all quite challenging in one way or another: socket programming in C and Java, writing a client to stream video with RTSP and RTP in Java, and also implementing the server side portion of that video streaming assignment in C. I think a lot of the difficulty originiated from the fact that the assignments had very little to do with the material covered in lecture, or were barely touched upon during lecture. That's in contrast with CPSC 313, where the material was difficult (even more so than 317) but the assignments were directly related to the topics covered in lecture, and were in effect practical applications of the knowledge that students acquired during lectures; such assignments have IMHO more educational value and are less intimidating.

Dr. Donald Acton was the instructor for the section of CPSC 317 that I took in 2013W2. It's clear that he is passionate and very knowledgable about the topics covered in the course and he's also quite approachable as a professor. However, he does seem to go off on unhelpful tangents at times during lecture, and his various in-class examples during lecture were not always clear or sufficient. CPSC 317 was one of the few CPSC courses where I ended up cracking open my textbook out of necessity and studying from that rather than learning primarily through lectures, the latter being my preferred method as I'm largely a visual learner.

Review: CPSC 304, 310

2015-06-22T21:38:00-07:00

This is a long overdue review for a bunch of 3rd year CPSC courses that I took in 2013W1. Better late than never, right? As it's been a lengthy 2 years since I've taken these courses, I'll probably keep these reviews a little bit shorter than some of my other reviews.

CPSC 304:

In a nutshell:

Language: relational algebra, SQL, Datalog

Toolset: exposure to Oracle, SQL*Plus

Prereqs: CPSC 221

Website/resources: CPSC 304 and lecture recordings (which are only accessible via VPN or ubcsecure; you'll get a 403 Forbidden error otherwise); Piazza

Textbook: Database Management Systems, 3rd ed., by Ramakrishnan and Gehrke

CPSC 304 is UBC's introductory course to relational databases (which I'll henceforth abbreviate to RDBMS); you're not expected to have had anyexposure to RDBMSs prior to taking this course. You'll learn about a fairly wide breadth of material; this includes database design (Entity-Relationship models), the relational model, formal relational query languages (relational algebra), writing actual queries (using SQL and datalog), normalization and normal forms (3NF, BCNF), and a few miscellaneous topics near the end of the course like XML. In 2013W1, CPSC 304 also covered topics that have apparently since been moved to CPSC 404 now (as of 2015), including logging, crash recovery, and concurrency control. I'm not entirely sure I understand the rationale; yes, the topics that were moved are more pertinent to CPSC 404 because they cover database internals, which isn't the focus of 304, but I felt that the pacing of 304 was pretty good already to begin with. Anyways, I digress...

In essence, you'll spend about half, maybe a bit more than half, of the course learning about how stuff in databases are modelled, and how to express queries using relational algebra, SQL, and datalog. The other half was more about the nitty gritty details about how databases are implemented (but again, this part of the course is supposed to be covered in 404 now).

Grades were assigned from 2 midterms (20% each), clickers (2%), the term project (18%), and a final worth 40%. The exams were quite straightforward, nothing much to write about there. The term project is probably the thing that'll eat up the biggest chunk of the time you spend on CPSC 304; as with all other typical CPSC term projects you'll encounter, the key is to pace yourself and not leave everything to the last minute. The project itself is just to create an application that uses a database (the department Oracle database was recommended); you start from scratch and have a lot of leeway in terms of what you want to do, and what technologies you want to use (there just has to be some SQL involved somewhere). You'll work in a group of 4 and will have multiple deadlines during the term, although the first few deadlines are for planning and design purposes.

I definitely enjoyed taking CPSC 304; Dr. Rachel Pottinger is an awesome professor who is energetic and enthusiastic about the material she teaches, and her enthusiasm is quite infectious (which makes it hard to fall asleep in her class; sleeping in class is a chronic problem I seem to have). Her lecture slides are also quite good, and for me they were more than sufficient for the purpose of studying for exams (the textbook was more or less a dead weight for me for both 304 and 404, actually).

CPSC 310:

In a nutshell:

Language: Java

Toolset: Eclipse, GWT (desired toolkit is up to you for the project)

Prereqs: CPSC 210

Website/resources: CPSC 310, Piazza

Textbook: none

CPSC 310, also known as "Introduction to Software Engineering", is the sequel/successor of CPSC 210 and is another course in the software engineering stream. You'll start off by covering software processes and methodologies (this is where you'll start learning about terms like "waterfall", "agile", "extreme programming", "user stories", etc.). The next 2 months, give or take, will be about design patterns, design patterns, and some more design patterns; there won't be any overlap with CPSC 210 here. You'll then wrap up the course with some topics on testing and a brief lecture or two on security.

To be brutally honest here, I thought this was the least useful and least interesting course amongst the CPSC courses I took in 3rd year. Most of the lectures were devoted to covering different design patterns, all of which you can learn about merely by spending half a hour or so reading up on Wikipedia. The remaining topics are things you'll pick up quickly while you're out on a co-op/internship term, or are barely touched upon. The only noteworthy thing left to mention is the term group project, which is where the vast majority of the workload for this course will come from, so basically CPSC 310 boils down to a project course (that is required if you want to graduate as a CPSC major, unlike CPSC 319). And I'm saying all of this as someone who enjoyed CPSC 210 and found it useful.

You'll be given a lot of leeway on the group project (done in groups of 3-5), with a few constraints. The goal is to build some kind of web application by adopting the agile methodology; you'll also have to use an approved source of data to feed into your web application; the only ones you could use without manual instructor approval were Data BC or Data Vancouver. The technical requirements are quite straightforward; quoting directly from the 310 project page:

Import and clean data - access data on a remote server, parse it, and translate it into a format useful for manipulation.
Storage - the data should persist once uploaded. I assume that you will load your data once, or every so often on a specified interval. Once it's loaded, it should be persisted as part of your own application.
Data display - display the imported data in a tabular and a geographic format.
Social network integration - integrate with at least one social network (e.g. Facebook, Twitter, LinkedIn, etc.).
Access - Users need to login with a password and have some user-specific account data (profile, preferences, media, etc...)

During the term I took CPSC 310, Google Web Toolkit was highly recommended to us by the instructor to use for the project. You could use other web frameworks, but without any help from the instructor or TAs if you found yourself having trouble with your chosen toolkit.

The marking scheme used in CPSC 310 boils down to: participating in in-lecture group activities (5%), 1 midterm (20%), the term project (35%), and a final (40%). The course was taught by Dr. Eric Wohlstadter in my term, and I found him to be a fairly clear instructor who is decent at conveying information. It's probably worthwhile to note that I don't think I would've enjoyed this class regardless of who was teaching it, however.

Browse This Blog Over HTTPS!

2015-01-08T22:15:00-08:00

Just a heads up to any security-conscious visitors: this blog is now browsable via HTTPS! Well, I did actually have a SSL certificate installed on my VPS for a while, but I didn't bother fixing up all the HTTP-only links scattered around my blog until now (which I've "fixed" by turning most of the links on this blog into relative URLs instead of absolute ones). The end result that this site is browsable via either normal, unencrypted HTTP, or via encrypted HTTPS.

https://www.vcheng.org

Please let me know if there are any glaring issues that I've not yet noticed.

And yes, I'm using a StartSSL certificate. I'm not a fan of them ever since Heartbleed and their subsequent refusal to waive fees for revoking potentially compromised SSL certs, but there's no other widely accepted CA who offers free SSL certificates (and by "accepted", I mean CAs with their root certificate installed on most systems by default). I'm hoping that the Mozilla-backed Let's Encrypt initiative works out, but in the meantime I'm fine with using StartSSL.

Inbox Zero, and Organizing My Digital Life

2015-01-07T23:48:00-08:00

For a large chunk of time over the last year, I haven't been nearly as diligent keeping up with emails, not to mention neglecting my blog for quite a while. Part of it was due to being preoccupied with my latest co-op position at a local startup, Tasktop Technologies, but most of it was due to, well, general laziness I suppose. Well, there's no better time to fix that than right after New Year's, and the start of a new school semester. It's been years since I've last made a New Year's resolution that I took seriously, but this year, it's something quite simple: retain control over my email inbox again by embracing the concept of Inbox Zero, and find a way to keep notes and reminders in a sane manner - "sane" being something other than a mish-mash of strategies that I'm currently using, including a multi-thousand-line text file of "notes", post-it notes scattered around my room, and a paper agenda that I infrequently use.

It's a New Year's resolution that's long overdue, for sure!

Clearing my inbox was fairly easy to accomplish once I decided to dive straight into the mess that was my inbox. Most of the time that I spent here was mostly related to Debian, given that Debian mailing list subscriptions account for the majority of emails I receive. I ended up replying to a bunch of old bug reports that I forgot existed, and also cleared my sponsorship backlog.

As for the other chunk of my resolution, I ended up being inspired by some suggestions in a particular Hacker News thread around this time, specifically by applying "Getting Things Done" concepts (using The Secret Weapon as a practical example). I ended up discovering TagSpaces through the same HN thread, which met all the requirements I was looking for from a note-taking tool (it's cross-platform, it has markdown support, it doesn't rely on an external service, and it's FOSS (AGPL 3)), and more that I hadn't considered, i.e. tags persist in the name of each file, which on second thought is actually a definite plus for me. I like the idea of having metadata stored in the files themselves rather than somewhere in the application; among other things, there's no vendor lock-in and I can interact with my markdown notes almost as effectively with vim and grep if I wanted to. TagSpaces doesn't currently support searching through file contents, which is a letdown, but the fact that I can just grep through my directory of notes is sufficient for me.

Anyways, now I'm mostly caught up and have adapted to my new workflow; time will tell whether I end up sticking with it or not, I suppose, but having small todo notes prioritized and ordered by tags definitely beats a large, unorganized free form text file. Now I just gotta find some time to type out some old blog post ideas I've had; I still intend on writing a review for CPSC 304, 310, 313, and 317 (along with CPSC 314, 320, and 404 after this term), and perhaps other blog-worthy thoughts that come to mind.

Hello, Planet Debian! (also, RFH: sponsorship-requests)

2014-02-22T22:41:00-08:00

Hi Debian! Just to briefly introduce myself, I'm Vincent (vcheng@d.o, vincent_c on OFTC/Freenode) and I'm a recent graduate of the NM process, having attained DD-ship (is that even a word?) about a month ago in January. Before that, I was a DM since mid-2012, and just another contributor for a few years prior to that. Most of my contributions to the Project are related to packaging, especially packages maintained within the Debian Games Team. Outside of Debian, well, I'm just another 20-year-old, 3rd-year undergrad student studying at the University of British Columbia, working towards a major in computer science. I anticipate that I'll be able to ditch academia for good in 2016; just 2 more years to go...

More about my life story in my AM's report. It's fairly boring, if I say so myself.

This blog post isn't just about me; I'd like to touch upon another topic that I consider important, i.e. attracting new contributors, and in many cases that involves package sponsorship. That's one of the many things I'd like to work on as a DD, and to that effect I've dedicated a large chunk of the time I currently spend on Debian sponsoring various packages, including packages that I'm not familiar with. I would love to see the sponsorship-requests queue empty one day, but I admit that I find that increasingly unlikely to happen, now that I've gotten a taste of the time commitment involved with sponsoring.

Team maintenance and sponsorship seems to work relatively well in Debian; why does that success not translate over to sponsorship-requests / debian-mentors@l.d.o, where a considerable amount of RFS requests don't see any response at all, and merely get closed once those packages get removed from mentors.debian.net (AFAIK they automatically get removed after 20 weeks)? Well, I'm not here to offer an answer for that, but I will point out that there was a relevant thread that originated on debian-devel a month ago: <87ha8lzl7n.fsf@inf-8660.int-evry.fr> (and no, I'm not talking about the giant init-related threads that pop up on debian-devel every other week or so and drown out everything else on the list...).

Are DDs in general reluctant to engage in "fly-by sponsoring"?

Most packages coming through the sponsorship-requests queue are not team-maintained, and are sent from sponsorees who are not already in contact with a sponsor, and who have no other way of getting in touch with a potential sponsor (assuming that there isn't an existing team or a DD who happens to be interested in that package). Regardless of the merits of fly-by sponsoring (many arguments in favour of, and against, this type of sponsorship have already been discussed in that thread; no need to re-iterate them here), it's discouraging for potential contributors new to Debian, who may just give up and move on to something else.

I've now had the opportunity to be a sponsor (rather than just a sponsoree), and I acknowledge that being a sponsor is more work than I imagined it to be a month ago, and it can be quite tedious and not-fun at times. I suppose I can draw a parallel between sponsoring packages and RC bug fixing; neither is what I'd consider to be a highly enjoyable way of spending my leisure time, and both can eat up a large chunk of time and effort; both often involve working on something that you aren't familiar with. But both are beneficial to Debian. No, beneficial isn't a strong enough word; how about "essential" instead? Yeah, that makes more sense. Without dedicated RC bug squashers, Debian would never be able to make a release; without dedicated sponsors, the size of Debian's archive would be smaller and of lesser quality, and its community also a lot smaller.

With all that said...I hope this blog post inspires at least a few DDs, possibly more, to dedicate a little bit more of their time towards sponsoring packages. :)

Pelican Sitemap and Pagination

2014-02-22T22:41:00-08:00

Pelican (the static site generator that I'm using to generate this blog) doesn't seem to generate a sitemap on its own, so I spent a bit of time today searching for a way to do so that's easily integrated with Pelican; surely someone must have already solved this problem, right? Well, it turns out that indeed, there's already a plugin for it in the pelican-plugins repository, and it's really easy to use!

pelicanconf.py:

PLUGIN_PATHS = ['/path/to/cloned/pelican-plugins/repo']
PLUGINS = ['sitemap']

SITEMAP = {
    'format': 'xml',
    'priorities': {
        'articles': 0.5,
        'indexes': 0.5,
        'pages': 0.5
    },
    'changefreqs': {
        'articles': 'monthly',
        'indexes': 'daily',
        'pages': 'monthly'
    }
}

However, if you take a look at the sitemap that it generates, e.g. my site's own sitemap, you'll notice that it only seems to recognize the top-level index.html page, and not any of the other pages that are generated by Pelican with pagination turned on (DEFAULT_PAGINATION = # in pelicanconf.py), e.g. index2.html, index3.html, index4.html, and so on.

Luckily, the sitemap plugin is quite simple to grok and I hacked together a workaround for this in just a few minutes. If you stumbled upon this blog post and you have the same problem, it basically comes down to changing:

for standard_page_url in ['index.html', 'archives.html',
                          'tags.html', 'categories.html']:

to this:

standard_pages = ['index.html', 'archives.html',
                  'tags.html', 'categories.html']

for i in range(100):
    standard_pages.append('index'+str(i)+'.html')

for standard_page_url in standard_pages:

in sitemap/sitemap.py.

(Yes, I know that's rather ugly, but it works...you can find my pull request if you've like to suggest a different solution.)

Migrating from Wordpress to Pelican

2014-02-22T01:02:00-08:00

I've finally taken the plunge and migrated from my old Wordpress.com site to my new and (hopefully) improved Pelican-built site! If you're reading this, you probably have two questions: "why?" and "how?"...so let's tackle them in that order.

Why? A lot of it comes down to the advantages that static site generators like Pelican have over the dynamic CMS that is Wordpress. Wordpress is without doubt a very powerful CMS, and it has a thriving, large community around it that adds on even more value to Wordpress through its huge collection of plugins. It's also really easy to setup and easy to use. So why switch to a static site generator like Pelican? Well, in return for giving up the convenience and usability that Wordpress offers, by adopting Pelican I got

speed: a static blog is going to be faster than a dynamically generated site, no matter how much you try to optimize your Wordpress site / cache / database. This site now serves up nothing more than HTML, CSS, and JS files.
simplicity (note: not convenience): as mentioned above, there's no need to set up, configure, and optimize your Wordpress installation. Simplicity in this sense also refers to the fact that this site is now powered by a smaller, simple to understand stack, rather than a giant and much more complex PHP stack that regularly attracts attackers...
improved workflow: you can use your preferred editor and your preferred VCS to create and keep track of your blog posts. Markdown is a nice bonus as well (it's the sweet spot between a WYSIWYG editor and raw HTML).
mobility/deployment: static site = easier to move around (just copy the files; there's no database to worry about) and deploy (and often cheaper to deploy; you can do so for free with Github Pages, for example).

Also, switching to Pelican means that I get to move off of Wordpress.com infrastracture, hence no more ads (and no need to pay $30/yr to get rid of them), no restrictions on the amount and type of content I upload, and being able to use my own domain name (without having to pay for it), and of course not having to rely on a third-party to host my blog.

As for "why Pelican and not any of the hundreds of other static site generators out there?"...because it's one of the most popular static site generators by far, and I know Python a lot better than I know Ruby (for me it came down to Pelican vs. Jekyll/Octopress). I know, these probably aren't very compelling reasons to pick Pelican over another static site generator, so feel free to experiment if you're planning on making the switch from Wordpress as well. An advantage of Pelican (and close competition like Jekyll) over the hundreds of obscure generators out there is that there's a sizeable community with an ample amount of themes, plugins, and support available, although if this was your main concern, you'd likely stick with Wordpress.

Switching over to Pelican had one major disadvantage for me, however:

Comments (or rather, the lack thereof).

Most static website generators "solve" this issue by making it easy to integrate your blog with Disqus. The only other alternatives come down to re-inventing Wordpress/Disqus' commenting systems (which kinda defeats the purpose of having a static site if you end up needing some sort of database and some PHP glue code to make everything work), or using a rudimentary email-powered solution whereby you get your readers to send you comments via email. I just ended up using Disqus, for lack of a better solution. commenting system.

Moving on to "How?" now...

Start by installing Pelican; there's a handy guide to getting started with Pelican available upstream, although if you're on Debian or a derivative, I suggest installing it via apt-get install python-pelican instead of using pip and virtualenvs as suggested by that guide. pelican-quickstart will ask you some questions to generate a set of config files populated with your answers. If you're migrating from Wordpress, make sure to export your data and convert it into a set of input files for Pelican with:

$ pelican-import --wpfile --dir-page -o content -m markdown wordpress.xml

Omit -m markdown if you prefer editing your blog posts in reStructuredText rather than Markdown. You can see the resulting Markdown/reST files in a content subdirectory.

At this point, you're ready to have Pelican generate a website for you (using the default theme and settings); pelican-quickstart will have generated a Makefile (as well as fabfile.py if you prefer Fabric instead) populated with a number of useful targets, e.g. make devserver to generate your site and host it on http://localhost:8000. You'll likely notice that the import script isn't perfect and you'll have to run through and fix a few things, but at this point you now have a working website which you can deploy via make publish and make {ssh,rsync,dropbox,ftp,s3,cf}_upload.

Pretty straightforward, no? (Almost) simple and quick enough to rival Wordpress' "famous 5-minute installation". ;)

At this point, you may want to browse through some of Pelican's plugins and themes. My site's current theme is a Svbtle-inspired theme closely based off of pelican-svbhack, with some minor modifications.

There are a number of settings that you'll want to tweak in pelicanconf.py, as well as publishconf.py (the latter is used only during make publish and inherits all the settings from the former, so you'll want to put most of your settings into pelicanconf.py). There is extensive documentation about each of the settings, so I won't go into too many details here.

As an example, by default Pelican generates all its output in a flat hierarchy, but you can easily force it to generate your site with a structure similar to Wordpress (like I've done with my site), with the following settings in pelicanconf.py:

ARTICLE_URL = '{date:%Y}/{date:%m}/{date:%d}/{slug}/'
ARTICLE_SAVE_AS = '{date:%Y}/{date:%m}/{date:%d}/{slug}/index.html'
PAGE_URL = 'pages/{slug}/'
PAGE_SAVE_AS = 'pages/{slug}/index.html'

If there are static files that you don't want Pelican to process, and just want to see copied over and placed alongside your generated HTML files, that's easy to accomplish as well. Just place them in a subdirectory of content, e.g. content/extra, and add the following settings:

STATIC_PATHS = ['extra']

...and those files will be copied to a subdir extra on your host. If you want to move them, e.g. to the top-level directory:

EXTRA_PATH_METADATA = {
    'extra/robots.txt': {'path': 'robots.txt'},
    'extra/favicon.ico': {'path': 'favicon.ico'},
}

(FILES_TO_COPY was deprecated in an earlier release, so avoid using that.)

Your theme and active plugins may also come with additional settings you can tweak inside your pelicanconf.py. Have fun!

My First SSD (Intel 330, 180GB)

2013-01-14T01:34:00-08:00

I actually bought my very first SSD last year during Black Friday, but I never got around to swapping out my hard drive until after exams, and to blog about it until now, heh. It's a 180GB Intel 330, snagged from Newegg for roughly $0.58/GB, which in late 2012 was considered a pretty good deal (although I expect SSD prices to dip even further this year). I've heard from friends previously that I should consider purchasing a SSD, but I never really gave it serious thought until after another hard drive failure.

So long story short, I got this in the mail a while ago:

I'm actually very impressed with the boot speeds my laptop has now; previous it took ~30 seconds to boot from POST to gdm, and another minute to get an usable GNOME Shell environment. Now it takes about 10 seconds to get to gdm, and 2 seconds to have an usable shell, which is quite the improvement! And this is with Debian's sysvinit, not systemd; I suppose systemd may be able to shave off another second or two, but boot speed is no longer a compelling reason for me to consider switching from sysvinit to systemd.

Setting up and using the SSD itself has been pretty quick and painless; just remember to add "discard" to /etc/fstab to enable TRIM support. That's the only thing that really should be done; everything else (noatime, tmpfs, I/O scheduler changed to deadline/no-op, etc.) is optional, although I went ahead and did that anyways.

Brief explanation of my current setup now (more for my own reference than anything else, although I hope this helps someone):

Tmpfs & TRIM:

$ cat /etc/default/tmpfs
RUN_SIZE=3%
LOCK_SIZE=5242880 # 5MiB
SHM_SIZE=12%
$ cat /etc/fstab
UUID=xxxx  /             ext4        noatime,discard,errors=remount-ro 0       1
/dev/sr0   /media/cdrom0 udf,iso9660 user,noauto                       0       0
tmpfs      /tmp          tmpfs       noatime,size=85%,mode=1777        0       0

Note that I manually mount /tmp as tmpfs in /etc/fstab to override the defaults that /etc/default/tmpfs sets. To be specific, I don't want nosuid or nodev since that seems to cause troubles when setting up a pbuilder chroot (I have /var/cache/pbuilder/build symlinked to /tmp to avoid excessive disk writes when building Debian packages with pbuilder).

I also have /var/cache/apt/ symlinked to /tmp to avoid excessive disk writes when using APT. I regularly run apt-get clean to clear out my cache, so this isn't a problem for me; with 8 GB ram, and a tmpfs setup on /tmp to take up to 85% of my RAM, that leaves me with more than enough space in /tmp for day to day usage.

I also want Deadline to be the default scheduler for SSDs/flash media, and CFQ to be default for rotating disks, so I added an udev rule for that:

$ cat /etc/udev/rules.d/90-io-schedulers.rules
# set deadline scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"
# set cfq scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"

That's pretty much it.

I've had to make minor adjustments to my workflow to accomodate the fact that my SSD is a lot smaller than my old hard drive, but it's still large enough for a dual-boot setup, along with all the programs that I use and most of my data (my videos/movies have to be stored on a separate drive though). I've already adopted the habit of compiling stuff in /tmp and building my Debian packages in a tmpfs /tmp before getting a SSD, so this hasn't disrupted my Debian packaging workflow very much either.

Review: CPSC 213, 221

2013-01-10T01:57:00-08:00

Now that I've finished with all my 2nd year CPSC courses, I guess it's a good idea to write down my review before I forget about it, especially since I'm now on a co-op work position. So, without further ado, I present to you my overall thoughts and comments on both CPSC 213 and CPSC 221 (taken in 2012W1).

CPSC 213:

In a nutshell:

Language: C, Java, Assembly (SM213)

Toolset: Text editor of your choice + gcc (GNU C compiler) + debugging tools (gdb for C, Simple Machine for SM213 assembly)

Prereqs: CPSC 121, 210

Website/resources: CPSC 213 website, SM213 ISA, CPSC 213 Lecture Notes Companion

Textbook: Computer Systems 2nd ed by Bryant and O'Hallaron

CPSC 213 is your introduction to some lower-level, operating system and software architecture basics. Essentially, you'll be spending roughly 2 months learning to program in assembly language, specifically referred to as SM213 in this course; since I can't find any references to it outside of the course, I'm going to assume that this is specific to CPSC 213 (but it's conceptually similar to programming in assembly language on another architecture, e.g. Intel x86). Then you'll spend the remaining month learning about topics like threading, schedulers, concurrency, and virtual memory.

The purpose of learning assembly is for you to learn how higher-level languages like C and Java get translated into simple, concise instructions that computers can understand and execute, e.g. adding 2 variables and assigning the resulting value to a 3rd variable (c = a + b) would involve loading the values of a and b into different registers, using the add operation provided by SM213's ISA, and then storing the value obtained from the register into the address of c. Each assembly instruction has an one-to-one correspondence with machine language, hence even the most simple programs with just a few lines in C/Java can be very lengthy in assembly. In fact, in many of the labs, you will end up translating short snippets of code from C into assembly and vice versa (Java will be thrown into the mix later). You'll come to appreciate just how much work your C/C++ compiler actually does for you...

The latter half of the course is all about lower-level operating systems related material, i.e. I/O, interrupts, threads & scheduling, concurrency, synchronization, and virtual memory. You'll learn about all the considerations you must make when designing programs that run in parallel (which is an increasingly relevant issue now that CPUs are becoming multi-core behemoths), e.g. how to make it safe to run code asynchronously, how to protect shared variables using locks/monitors/semaphores, common pitfalls like race conditions and deadlock, as well as a fairly brief introduction to how virtual memory is implemented, e.g. how your OS maps physical memory into virtual memory addresses and vice versa.

The course itself goes at a pretty brisk pace and builds upon stuff that you've previously learned (within each half of the course), so keeping up is pretty important. Debugging also plays a very important role, probably more so than in previous CPSC courses. It's easy to make errors while programming in assembly, and not so easy to find them, so do yourself a favour and learn early on to use that Simple Machine program you're provided with. In my opinion, the course tends to get progressively more and more difficult (for the first half of the course, up to the point where you'll be handling polymorphism with assembly), and the labs in the second half of the course can be extremely frustrating at times.

The course has a fairly generic marking scheme: 50% final, 30% spread across 2 midterms (15% each), and the remaining 20% spread across 9 labs (~2.2% each; 6 labs for the first half, 3 labs for the second half of the course). You do not have to go to your scheduled lab sessions (and to be honest I never went to my labs after the first one); labs are all handed in online via the 'handin' command-line program. Speaking of handin, you'll also gain a bit of practical Linux experience in this course, i.e. how to SSH into one of the Linux servers owned by the department, how to compile your C code using gcc remotely instead of on your own computer, how to navigate with a bash shell, etc. For many, this is probably one of their first encounters with Linux; a friend of mine ended up complaining that handing in his first lab seemed harder than actually doing the lab itself. :P

My prof (Dr. Tamara Munzner) generally explained concepts well and was an effective prof overall for 213 (and she even brought cookies in-class occasionally, yum!). I didn't really interact with the TAs in the course (labs aren't mandatory -> more time for me to sleep) in person, hence Piazza was an extremely helpful resource at times (especially right before labs are due). Workload is manageable, but again, do make sure you keep up. As for textbooks, to be honest I never once opened up the required textbook for the course; lectures + lecture notes + the 213 Companion PDF were sufficient (and there's no substitute for actually doing the labs that involve assembly...that's much more effective than just reading stuff).

CPSC 221:

In a nutshell:

Language: C++

Toolset: Text editor of your choice + g++ (GNU C++ compiler) + debugger (gdb, or one of its graphical frontends like ddd)

Prereqs: CPSC 121, 210 | Coreqs: MATH 101/103/105

Website/resources: CPSC 221 website, recorded lectures

Textbooks: Discrete Mathematics with Applications 4th ed. by Epp (same book required for CPSC 121), Objects, Abstraction, Data Structures, and Design Using C++ by Koffman and Wolfgang

The other CPSC course I took concurrently in the same term as 213 was CPSC 221, "Algorithms and Data Structures". The course name pretty much says it all: this is going to be a course where you'll learn tons about various data structures, and some of the algorithms that you can build given those data structures. It sounds simple enough, but this content covered in this course is extremely useful (if somewhat brief), and IMHO this is one of the most important CPSC courses you'll end up taking at UBC. If you think back to the material you covered in CPSC 110, you'll remember that there was a strong emphasis on designing data structures that meet your needs (HtDDD); if not done properly, writing functions that operate on that data (HtDF) would often be futile and frustrating. In CPSC 221, this important lesson is further hammered home, and you'll also deal with an additional factor to worry about: efficiency (run-time complexity), not just correctness of the implementation of your data structures/algorithms.

You'll begin the course with review of material that partially overlaps with CPSC 121, including sets and functions, proofs, induction, iteration vs recursion, loop invariants (if you hoped that proofs and induction were a thing of the past after you finished 121, sorry :P ). You'll also cover Big-O/Omega/Theta notation (time complexity), which along with proofs are concepts that you should master early on in the course, within the first few weeks or so. The rest of the course is going to explore lots of different data structures and the algorithms that build upon them: linked lists, priority queues and heaps, various sorting algorithms (mergesort, insertion sort, quicksort, heapsort, including implementation examples and analysis of complexity), hashing (and implementation details, e.g. open addressing vs. chaining, collisions, etc., and proofs using the pigeonhole principle), trees (properties and traversal, and different types: binary trees, binary search trees, B+ trees), graph theory (properties, breadth/depth first search, Dijkstra's algorithm, Kruskal's algorithm, etc.), concurrency/parallelism (some degree of overlap with CPSC 213), counting (lots of overlap with permutations and combinatorics in high school - Math 12).

The above is not a conclusive list...that was just a brain dump of everything I could remember from a few minutes of thinking.

As for coursework, you'll have both written assignments (3 in my term), and C++ programming assignments (again, 3 in my term). The written assignments are roughly as challenging as the assignments from CPSC 121; on the other hand, the programming assignments are likely harder than programming assignments done in past courses (I'd say somewhat harder than the Android end-of-term project for CPSC 210). I think I averaged 10-12 hours per assignment in total. If you're curious, here are links to Project #1, Project #2, and Project #3 (you'll likely get different assignments, so treat these as examples of what to expect). I don't really have any specific advice for the projects, besides the generic "don't leave it till the last minute", but I think most of you have figured that out by now. Oh, and as with CPSC 213, test compile your code on the department Linux machines before handing in your code (not just on your own machine), unless you want to risk hitting a compile error and getting a big fat zero. You'll also have ~9 labs that follow the course material as it is taught, but labs are usually pretty short (I've finished quite a few in under a hour, with the help of the lecture slides). Unlike 213, you do have to go to lab sections since they're marked in-lab by your TAs, but technically you could just go every other week since labs are due the week after they're assigned.

Grading scheme is as follows: 45% final, 25% distributed between 2 midterms, 15% for the programming assignments, 10% for the written assignments, and 5% for the labs. Written assignments handed in-class, projects handed in via the command-line "handin" program (like the 213 labs), and labs handed in by showing your TAs your work and answering questions to make sure you understand the concepts.

My prof (Dr. Will Evans) is a decent prof. It's pretty clear that he knows the material he's teaching well, but unfortunately he can be quite soft spoken at times...it made it hard to stay awake in class sometimes (as with MATH 200, but there it's because the material is just so dry). As I noted in the "nutshell" section above, there's luckily a web page of recorded lectures for CPSC 221, so if you've slept through a lecture, you can just rewatch a video of the lecture in your own spare time.

Toshiba Satellite P850: RTS5229 SD card reader not working

2012-10-08T20:40:00-07:00

It turns out that after thoroughly testing the new laptop I got a few months back for hardware compatibility issues with Linux, there was one thing I forgot to check: the built-in SD card reader slot. And of course, it happens to be the one thing that doesn't work out of the box (aside from Nvidia's Optimus, but I'll save my rant on that topic for another day). However, it turns out that Realtek does distribute source code for their out-of-tree rts5229 kernel module, which is used by my laptop's SD card reader, so luckily enough it didn't take me long before I got my card reader working and could get back to work. Details and a dkms package for Debian/Ubuntu users below...

If you're here, you probably want to know how to get your card reader working as it should be. First, check to make sure that we're talking about the same (or similar enough) hardware:

$ lspci -vnn | grep -A5 RTS5229
04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5229 PCI Express Card Reader [10ec:5229] (rev 01)
Subsystem: Toshiba America Info Systems Device [1179:fb30]
Flags: bus master, fast devsel, latency 0, IRQ 19
Memory at f6800000 (32-bit, non-prefetchable) [size=4K]
Capabilities:
Kernel driver in use: rts5229

(The "kernel driver in use" line won't show up until you've actually installed the driver, of course.)

You can fetch source code for the rts5229 module directly from Realtek (look for "PCIE RTS5229 card reader driver for Linux"; it's at version 1.07 at time of writing). Installation is simple; unzip it, untar it (don't ask me why Realtek put a tarball inside of a zip file...), cd into the source directory, and then:

$ make
# make install
# depmod -a

After which you can either reboot, or manually load the rts5229 module. It'll be automatically loaded on each subsequent reboot, regardless.

# modprobe rts5229

Of course, once you install a new kernel, you'll have to repeat the above steps, which is where dkms comes in: it'll automatically rebuild any out-of-tree modules registered with dkms each time you install/upgrade your kernel, so you don't have to do it manually yourself (if you're using dkms, you can skip all the steps I've outlined above). I've prepared a dkms .deb package for Debian/Ubuntu users, which you can grab here. (source package can be found in one of my Github repos)

Update: It looks like Realtek has submitted their driver into the mainline kernel; patches have been floating in the LKML for a while, at least. When it does get into mainline (3.8?), it'll be called "rtsx_pci" instead of "rts5229".

Update #2: Confirmed working perfectly out of the box in Linux 3.8. I recommend anyone with a RTS5229 card reader upgrade to 3.8, although it should be possible to backport upstream's patches for 3.6/3.7.

Linux kernel 3.6 audio distortion/noise

2012-10-07T22:15:00-07:00

Since I've spent a few hours of my time tracking the source and potential workarounds for this annoying bug, I figured that I may as well document my findings here. The latest Linux kernel (i.e. 3.6.0 at the time of writing) has a bug whereby if you play any audio file in VLC and try to change the volume, you'll hear a very annoying amount of audio distortion/noise. However, neither mplayer nor gstreamer-based players (Rhythmbox, Totem, etc.) seem to be affected (at least, not for me). More details available on the LKML. I don't seem to be the only one affected at least (e.g. LKML#1, LKML#2, alsa-devel#1, alsa-devel#2, bugzilla).

Workarounds: (obsolete, see update below)

1) Revert this commit and re-compile your kernel.

# echo "options snd-hda-intel position_fix=2" >> /etc/modprobe.d/alsa-base.conf
# alsa force-reload
$ pulseaudio -k

(Or just reboot instead of reloading ALSA modules + restarting PulseAudio.)

I'll update this post if I find other workarounds, or if my diagnosis of this bug is completely off. In the meantime, I'm off to enjoy some distortion-free music with VLC.

Update: Fixed in 3.6.2 (and 3.7): patch can be found on the LKML.

Toshiba Satellite P850 on Linux

2012-08-20T03:30:00-07:00

It's back to school season again, and I've decided to splurge some money on a new laptop a week or two ago. And of course, a new laptop means that I have to make sure that all the hardware components inside work with Linux, which is never a sure thing...

First things first, exactly what type of laptop was I looking for? Here's what I had after a quick brainstorming session:

Something within a $500-$1000 CAD/USD price range. Optimally somewhere in the middle.
Screen size 15"-16". (15.6" widescreen is preferred, minimum resolution I want is 1366x768)
Keyboard has numpad.
Intel CPU (i5/i7; ivy bridge should be affordable with budget < $1k) + dedicated Nvidia GPU combo. Entry-level Nvidia GPU is fine, just something with more oomph than an integrated Intel GPU. Of course, this means that I'm very likely going to end up with an Optimus-capable laptop, which had me somewhat worried at first due to Nvidia's non-existent support of Optimus on Linux. More on this later.
A wireless NIC that works out of the box on Linux. Most likely Intel/Atheros, but I'm fine with other brands as well. Preferably a card that doesn't require proprietary firmware, although I'm fine if it does just so long as it works.
Hard drive: I don't really care about capacity. Faster hard drive (e.g. 7200 rpm) ranks higher to me than capacity. Although SSDs are too expensive...
DVD+RW drive.
Everything else - ethernet, bluetooth, mobile broadband, webcam, mic, audio, USB ports and other peripherals, bulkiness/weight of laptop, battery life/power supply, warranty, pre-installed Windows OS + crapware, etc. - don't care. (Ok, battery life should be semi-decent though.)

I'm definitely not a hardware enthusiast, but I did intend to stretch my money as much as possible and try to get hardware that's recent and still affordable. I also wanted to avoid having to deal with too many Linux hardware compatibility issues...my old laptop (LG R580) was a pain to work with at first, given that e.g. suspend & resume regularly caused kernel panics (fixed by a BIOS update), very flaky wireless with my Ralink card (which was no longer an issue once rt2800pci matured enough, Linux >= 2.6.38), and display brightness couldn't be altered (leading to very poor battery life, but fixed with an out-of-tree kernel module, nvidiabl), and some other less important issues. This time around, I wanted everything to "just work" as much as possible.

The first laptop that I ended up buying was an Acer Aspire V5-571G, w/ Intel i5-3317U (ivy bridge), Nvidia GT 620M, 8 GB of DDR3 RAM, a 5400 rpm 500 GB HDD, and a 15.6" LED-LCD display (with a resolution of 1366 x 768), for a grand total of $699.99 CAD before tax, and which I returned a few days after. There were two "show-stoppers" with that laptop on Linux:

The laptop would always reboot when I told it to shut down from Linux, regardless of whether I powered off my laptop within a GNOME Shell session or with shutdown -h now in a console.
The Atheros wireless NIC that came with the laptop would frequently disconnect from my home wireless network, and unfortunately my google-fu turned up nothing fruitful in my search to make it just work. For future reference:

$ lspci -knn
04:00.0 Network controller [0280]: Atheros Communications Inc. AR9462 Wireless Network Adapter [168c:0034] (rev 01)
Subsystem: Lite-On Communications Inc Device [11ad:6621]
Kernel driver in use: ath9k

I couldn't find a fix for either of these issues before I ran out of patience and decided to try my luck with another laptop.

The second laptop I bought was a Toshiba Satellite P850, which I've had a much more pleasant experience with. Brief specs: Intel i7-3610QM (again, ivy bridge), Nvidia GT 630M, 8 GB of DDR3 RAM, a 5400 rpm 640 GB HDD, and a 15.6" LED-LCD display (with a resolution of 1366 x 768), which set me back $799.99 CAD.

First off, a quick Linux compatibility overview (with Debian 7.0 Wheezy, which is at the time of writing, testing and not yet released).

Ethernet:

$ lspci -knn
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 09)
Subsystem: Toshiba America Info Systems Device [1179:fb30]
Kernel driver in use: r8169

Works perfectly out of the box. No additional non-free (proprietary) firmware needed.

Wireless:

$ lspci -knn
03:00.0 Network controller [0280]: Intel Corporation Centrino Wireless-N 2230 [8086:0887] (rev c4)
Subsystem: Intel Corporation Centrino Wireless-N 2230 BGN [8086:4062]
Kernel driver in use: iwlwifi

Works perfectly once the required firmware is installed (for Debian, that's the firmware-iwlwifi package available in the non-free repository). Without the firmware, no wireless connections are detected (and you'll see "missing firmware" messages with dmesg), so if you're installing Debian, do so while hooked up with ethernet. It works out of the box on distros (e.g. Ubuntu) where the required firmware is available from the get-go.

Bluetooth: works perfectly fine. However, I don't use it regularly and unfortunately there's no BIOS switch to turn it off, so in order to stop it from wasting battery power, unload and blacklist the btusb and bluetooth kernel modules.

Webcam: works perfectly fine.

Internal mic: works perfectly fine.

Audio (through speakers): does NOT work out of the box with Ubuntu 12.04 LTS. When I installed Debian testing, it didn't work either. (However, it now works in both Debian and Ubuntu with updated kernels available from the repositories as of mid-August 2012). In order for audio to work out of the box, you must be running Linux >= 3.2.22 or >= 3.4. Launchpad bug report #1017017 addresses this issue; patch can be found on the LKML as well if you want to backport it to an older kernel.

Audio (through headphones): works perfectly fine.

CPU: it's a quad-core, 2.3 GHz i7 monster. 8 threads with Hyper Threading enabled, and hardware virtualization works, unlike my old laptop...that means I can finally use kvm (qemu is ridiculously slow without it).

Touchpad (actually a clickpad): works perfectly fine for me. I believe it's multi-touch capable, but I've never investigated it since I don't use multi-touch gestures.

USB slots: work perfectly fine. The Satellite P850 comes with 4 USB 3.0 slots, 2 on each side, which is convenient.

Suspend & resume: works perfectly fine.

Hibernate: works perfectly fine.

Graphics: Intel HD 4000 (again, ivy bridge) + Nvidia GT 630M in a mux-less Optimus setup. This, of course, means that you'll have to make do with Bumblebee and bbswitch which work perfectly fine if you follow the steps provided on the Debian Wiki, or make do without, which means you'll only be able to use the integrated Intel card (which I must say is already quite capable, and is able to compete with lower-end discrete ATI/Nvidia cards). Even if you don't intend on using the Nvidia card, install bbswitch so that it doesn't just sit there, eating up your battery life; the BIOS doesn't even give you the option of switching between Integrated and Optimus setups; you're stuck with both cards powered on by default.

Display brightness: works perfectly fine, either using GNOME's control center, or by manually inserting a value into /sys/class/backlight/intel_backlight/brightness.

Function keys: first thing you need to do is to go into the BIOS, and switch "Special" Fn keys to "Standard" Fn keys. This reverts the Fn keys to what most people would be more comfortable with. By default, since "Special" is activated, that means that pressing a F# key = implicitly pressing the Fn button as well, so the first time you try pressing F5 to refresh your page, what really ends up happening is that your laptop interprets it as Fn+F5 and disables your touchpad instead. This frustrated me to no end until I figured out I could switch this in the BIOS. I mean, honestly, when I press Alt + F4, I expect my current window to close, not for a projector screen to be activated, and I sure as hell don't want to press Alt + Fn + F4 to close windows. That's just stupid. And when I press F11, I want my browser to go fullscreen, not for my audio to get muted (with the implicit Fn key activated)...

Anyways, aside from the mess that is known as Nvidia Optimus, and audio with older kernels, this Toshiba Satellite P850 works great with Linux. :)

One last note: for Debian users like me who want to use the latest (beta1) installer to install Debian wheezy/testing on a Toshiba Satellite P850, you'll encounter lockups during the network detection step and while partman is launched; #683889 and #684309 respectively. This will prevent you from using the installer to install Debian (you'll be stuck with the pre-installed Windows, heh), and until those bugs are fixed, there's a working workaround available in #681656 (i.e. switch to another console and insert "exit 0" into /bin/check-missing-firmware before the network detection step, which automagically fixes the partman lockups as well...don't ask me how, I have no clue).

And to wrap things up, here's a photo of my shiny new laptop:

...And it turns out that 2 months after this post, I just realized that my laptop's SD card reader slot doesn't work, or at least not out of the box. I knew I was missing something...more on this in a follow-up post.

Review: CPSC 189

2012-07-17T13:57:00-07:00

CPSC 189 is a relatively new course and is only worth 1 credit, but it sounded interesting enough that I decided to take it during summer session. I've always wanted a formal grounding in Python, and while I was somewhat disappointed to realize that the purpose of CPSC 189 wasn't to teach students Python per se, it was still an interesting and engaging course in my opinion.

CPSC 189:

In a nutshell: [ Language: Python ] – [ IDE: Wing IDE 101 ] – [ Prereqs: CPSC 110 ] – [ CPSC 189 Website ]

Basically, this is CPSC 110, except you'll be designing programs with the Python programming language (which is a fairly popular interpreted language), instead of Racket. The same design principles are followed; you'll be re-using the HtDF, HtDDD, and HtDW recipes you learned in CPSC 110. So, you may ask, why should I take CPSC 189 then?

The answer lies in the differences between 110 and 189. While 189 is a very short course (1 month during the regular winter session, 3 weeks during summer), you cover additional material that you haven't explored (at least, not in-depth) in 110. I think the most notable difference would be the fact that 189 puts a lot more emphasis on iteration over recursion. In 110, you learned about recursion very early on and integrated it in your design recipes, while iteration was only briefly covered in the last unit (along with mutation and scope); in Python (and in most other languages), the preferred method of dealing with lists is not recursion as you've seen it in 110, but rather iteration. And once you've seen the simplicity of e.g. list comprehensions, you'll never want to go back (does anything remotely similar to list comprehensions even exist in other languages)?

You also learn about three useful third-party libraries: pygame (which you'll use for applying the HtDW recipe), matplotlib (a powerful plotting library), and numpy (for manipulating large amounts of data; in 189 you'll only work with numpy's arrays).

Overall, I enjoyed the course. I liked my prof (Dr. Paul Carter); he's very knowledgeable in the material that you'll learn in CPSC 189 and he's effective at teaching and communicating with students (he's also quite fast at replying to questions via Piazza). I do think that the course was a bit too short; the material was easy enough to absorb within the rushed schedule of a summer course, but I sort of wish we covered more material.

Workload in this course is manageable, but you do have to keep up. Mark breakdown is 65% final, 15% labs (spread between 5 labs during summer session), and 20% for in-lab quizzes at the start of each lab.

Review: CPSC 110+121+210

2012-06-23T04:30:00-07:00

Here's my review for CPSC 110, 121, and 210, which I took in my 1st year as a UBC Science student, doing a major in computer science.

CPSC 110:

In a nutshell: [ Language: Racket ] - [ IDE: DrRacket ] - [ Prereqs: none ] - [ CPSC 110 Website ]

"Bad programming is easy. Idiots can learn it in 21 days, even if they are Dummies." - How to Design Programs, 2nd Edition

This is an introductory computer science course (I know, I'm stating the obvious here), designed to teach students to design. In fact, the textbook you'll be using is entitled "How to Design Programs", a.k.a. HtDP. Incidentally, don't go and buy that book from the bookstore unless you want a hard copy, because it's available online: 1st ed. and 2nd ed., both of which you'll be using (but only the 1st ed. is in print; the 2nd ed. is still a work in progress). Save yourself ~$75, and spend it on the required CPSC 121 textbook instead.

Anyways, for those who do have prior experience with programming, you may (or may not) be surprised that you're not going to be taught Java in this course. In fact, there was an introductory CPSC course which featured Java (CPSC 111) and was equivalent to 110, but UBC axed it a few years back, so CPSC 110 is your one-and-only choice now. That's not a bad thing per se; I have no doubts that beginner programmers will find Racket (which you'll be using in 110) a LOT easier to work with than Java.

Racket itself originates from Scheme (it used to be called PLT Scheme); as with Scheme, it's most prominently used within academia. In real life, and in real world settings, you'll probably never come across Racket/Scheme. Rather, the point of CPSC 110 is not for you to learn Racket or its syntax (oh god, all those brackets!!! somebody save me...), but to learn the basic concepts of what "design" is, and how to go about programming, i.e. "designing" programs.

You'll start off by evaluating simple arithmetic instructions in DrRacket's interpreter (1+1), then learn about data and non-primitives, HtDF/HtDDD/HtDW recipes, lists, recursion (yes, you do learn recursion much earlier than you would in any other programming language), complex data, scope...up to the point where you'll be able to complete the design of a Pacman game near the end of term. Yes, I know Pacman doesn't sound like much, but it's a lot more complex than you would think it is. ;)

Labs are once a week; you get a short quiz, and then time to work on the lab (with TAs around to help you, and check you off at the end). There are practice exercises for you to work on during your own spare time, but they're not mandatory; marks are given for the quizzes, lab completion, and of course, your exams (2 midterms + 1 final). Exams involve written code (yes, it sucks having to write code with pen and paper...good thing only 110 does this), but as long as you understand the concepts you learn in lecture, the exams are quite straight-forward. I liked my prof (Dr. Joanna McGrenere); she explained concepts pretty clearly in class and was always approachable; my TAs were also pretty friendly and supportive (although I felt as if it was occasionally difficult to ask for help during labs...sometimes there would be line-ups for questions, given that TAs often have to work one-on-one to help a student work through a problem with his/her code). CPSC 110 also uses Piazza (sort of like a class discussion/forum) instead of Vista/UBC Connect (personally, I feel that Piazza > Vista/Connect, so I'm fine with that).

Overall, it was a fun and worthwhile course (even though I'm probably never going to use Racket ever again), and I'd recommend it to everyone, not just CPSC majors, who would like to have a taste in what programming is all about. :)

Note: As Elle mentioned in the comments section below, UBC also offers a not-for-credit version of CPSC 110 online via Coursera. Prospective CPSC 110 students may be interested in taking a look at it to get a taste of what's to come. ;)

CPSC 121:

In a nutshell: [ Language: none ] - [ IDE: none; Logisim in certain labs ] - [ Prereqs: CPSC 110 ] - [ CPSC 121 Website ]

CPSC 121: Models of computation is quite different from the rest of the first year CPSC courses that you can take. Instead of focusing on software and program design, 121 shifts the focus to hardware and logic. This is sort of a 2-in-1 course; lectures cover logic and proofs (truth tables, propositional logic, predicate logic, various proofs, mathematical induction, sets & functions), while labs cover the hardware aspect of the course (you'll work with the Magic Box or with Logisim to play around with very simplified circuits). This brings me to my foremost complaint about CPSC 121; lecture and labs seem to be completely unrelated to each other (this is akin to e.g. CHEM 121, where lecture and labs also seem to be completely independent of one another).

Early on, probably in the first lecture, you're going to be introduced to the "4 big questions" (my prof, Dr. Patrice Belleville, regularly referred back to them, so I think it's worth a mention):

1. How can we convince ourselves that an algorithm does what it's supposed to do?
2. How do we determine whether or not one algorithm is better than another one?
3. How does the computer (e.g. DrRacket) decide if the characters of your program represent a name, a number, or something else? How does it figure it out if you have mismatched " " or ( )?
4. How can we build a computer that is able to execute a user-defined program?

What you'll come to realize in this course is that your computer is nothing but a very, very complex grouping of parts that are capable of nothing else but simple logical operations. ;)

There's no programming done in this course at all (although sometimes your prof may use snippets of Racket to explain concepts in lecture). Marks are awarded for online quizzes (pre-reading for each chapter) done on Vista, ~5 assignments (roughly one every 2 weeks; do NOT leave them until the last minute, as most of them usually require several hours to complete, and it's likely that you'll struggle with a number of the questions...I definitely found the last 2 assignments difficult, given that writing proofs isn't really my forte), labs, and 2 midterms + 1 final.

CPSC 210:

In a nutshell: [ Language: Java ] - [ IDE: Eclipse ] - [ Prereqs: CPSC 110 ] - [ CPSC 210 Website ]

CPSC 210 is really an extension of what you learned in 110, but now, instead of learning how to "design" programs, you're going to learn how to "construct" them. Eh, who cares about terminology...anyways, you're going to be using a language called Java instead of good ol' Racket, which is both good and bad. On the one hand, Java's syntax can be harder to grasp once you're used to Racket's simplicity; however, unlike Racket, Java is actually used in real-life, and is currently the #1 (or #2, depending on your source) most popular programming language used in industry, so it's definitely very well worth your time to learn Java, especially if you intend to pursue a career in software development.

The initial hurdle dealing with Java's syntax can be frustrating at first, since the focus on lectures is to learn about various programming principles, not to learn about Java's nuances. It's definitely a different approach from 110. 110 is all about your prof holding your hand and teaching you basic syntactical knowledge, and guiding you as you write simple pieces of code. 210 is about having your prof (I had Dr. Mike Feeley) throw an entire codebase at you during your first lecture and telling you how to make heads and tails of it. The intent is for you to learn how to self-teach yourself a programming language, because Java is not the last language you'll learn over the course of your future career; programming languages increase and decrease in popularity over the years, and it's important for you to be able to learn new languages when you need to, in order to adapt to a rapidly changing tech sector.

...Whether CPSC 210 is successful at this, you decide. There is no assigned textbook in this course (AFAIK, Big Java used to be used in previous iterations of 210, but not any more, but it's still a good reference if lectures notes aren't sufficient for your needs), which can make 210 seem all the more frustrating at first. I came into CPSC 210 with rudimentary Java knowledge, and what little bit of programming experience I already had helped me to become fluent in Java fairly quickly. However, one of my friends struggled a fair bit with Java in the beginning; I've also met a few other 210 students who chose to spend a fair bit of additional time looking up references and doing some extra reading on Java. As the saying goes, your mileage may vary.

You'll start off by covering control flow models, call graphs, UML class/sequence diagrams in the beginning, then move on to abstraction and how to implement it. You'll also learn about data types, hierarchies, inheritance, type substitution, exceptions...by the end of this course, you should have a firm grasp of what object-oriented programming is, at least in Java. You'll also cover various design patterns, e.g. composite, singleton, observers, etc. Marks are based on 2 labs randomly picked amongst the ~5 labs that you'll do, a project (more on this later), and 2 midterms + 1 final. Note: You absolutely MUST pass the project in order to pass the course!

The project will take more than a month to complete, and is spread into 2 distinct sections, both weighted equally. You can work with one other person (pick your partner wisely, as this is definitely a lengthy project, and is going to be a lot of work, more than probably anything else in your other first year courses), and you'll be implementing an Android app that guides the end-user around campus, highlighting various sustainability-related attractions and nearby food outlets...a mobile tour guide, more or less. The first half of the project is the non-Android portion, i.e. coding the data model that the app will use. The second half involves working on the interface of your app, and implementing Android-specific features (e.g. GPS tracking so the app knows where the user is and can suggest suitable tourist attractions on campus).

Do NOT leave the project until the last minute. That is possibly the worst thing you could ever do to yourself in CPSC 210. There is a reason why you get a full month to finish it, and it's not because your instructors and TAs are feeling generous. :P

What irks people about the project (you'll inevitably see people complaining on Piazza, or even in class, about this) is that you're given very little guidance on the project, i.e. it's up to you to teach yourself how to, e.g. parse XML/JSON files, integrate your app with Yelp, implement GPS tracking, etc. You are not going to be spoon-fed the knowledge you require in lecture, so expect to do a lot of Googling/research on your own. But then again, you were thrown head-in into Java code on your very first day of lecture even if you had no idea what Java was, so you should really have gotten used to it by now. ;)

I just want to step back a bit here and clarify a few things. First, if you're concerned about the rather negative light I've put CPSC 210 in, don't be. It's a challenging and time-consuming course, yes, but it's also a rewarding course: it highlights the challenges you have to overcome as a software developer, and helps you develop your own toolkit to approach those challenges and tackle them efficiently. If you do well in this course, you should be prepared to deal with future CPSC courses; if you ended up hating CPSC 210 with all your guts, it may be worthwhile to consider another career option aside from software development. Personally, I liked CPSC 210 as a whole, even though it caused me quite a headache at times.

And that's all there is for now, folks! I'll be doing a review of CPSC 189 (which I'm taking this summer), and of CPSC 213 + 221 (which I'm taking this upcoming September) later.

Advice for new UBC students (CPSC)

2012-06-23T03:30:00-07:00

So, here's the 3rd entry in my "Advice for new UBC students" series (I know, I'm not all that creative :P ) - today, I'll talk about everything an incoming UBC computer science student should know. This is written primarily for students in the Faculty of Science; students who are studying comp sci, but are pursuing a BA / BCOM instead of a BSc, will have to deal with different requirements as determined by their faculty.

One of the unique things about CPSC at UBC is that it is the only specialization you can declare immediately upon entering Science as a 1st year student; all other specializations in the Faculty of Science cannot be declared until 2nd year (a few specializations, as well as a number of Honours options, are even deferred to 3rd year). When you first apply to UBC Science, you're given the option to immediately declare CPSC as your major, and this led to one of the first questions I had about UBC's CPSC program: what difference does it make if you apply now, or you wait until the summer before year 2, and go through the specialization declaration process along with everyone else in Science? Well, it turns out that there's really no difference; as a CPSC student, you do get an additional weekly e-mail on upcoming CPSC events (conferences, talks, volunteering opportunities, etc.), but other than that, it doesn't matter if you wait until 2nd year before declaring CPSC as your major. You're also free to switch majors later on, so don't hesitate about choosing CPSC from the get-go; if you know you want to study and do a degree in computer science, then go ahead and pick CPSC! :)

As an aside, everything mentioned in the weekly CPSC newsletter is posted online as well, via the UBC CS website. Definitely bookmark it and pay attention to those e-mails! Personally, I've found them to be much more useful and relevant to my interests than those Distillation e-mails. I've had the opportunity to attend a number of interesting talks hosted at UBC, where I've gotten to meet folks representing some well-known tech companies (e.g. Google, Microsoft, Facebook, Electronic Arts, Pixar, NVidia, etc., as well as a host of not-so-well-known companies), and I wouldn't have heard about these talks otherwise!

Anyways, as a 1st year Science student interested in pursuing a CPSC degree, there are a number of things you need to keep in mind when planning your 1st year course schedule; I'll list them briefly below, before moving on to a review of the CPSC courses I took last year. Again, please keep in mind that a lot of the following points below are irrelevant to those who are not in Science, unfortunately.

1) CPSC students are eligible to apply for Science Co-op (for a CPSC-related position, of course) as early as term 2 in your 1st year. Applications for CPSC co-op usually close in early March, but check the above website for details as it may change from year to year. To be eligible to apply for co-op, you must have already completed CPSC 110 and be currently taking CPSC 121 + 210 (and successfully complete them before being accepted into co-op). It is also recommended, but not required, to complete CPSC 213 + 221 before going out on your first work term (there's going to be a delay between being accepted into co-op, i.e. sometime in April/May if you applied in March, and going out on your very first work term, i.e. the following January, since there are a number of workshops you have to attend, and of course you actually have to go looking for a job yourself...no, you're not going to be served a job on a silver platter).

You can, of course, apply later for admittance into co-op. Do note that Science co-op requires you to complete at least 4 work terms (\~16 months of work), although that requirement is waived for BCS students (those who are studying CPSC as a second degree), and your last term at UBC can't be a work term, so don't apply too late or else you won't get accepted. Co-op schedules for CPSC are available online, although you can customize them according to your needs as long as you consult your co-op coordinator beforehand.

2) All standard lower level Science requirements still need to be completed. This includes the Communications requirement (6 credits of first-year English), the Physical Sciences requirement (6-8 credits of first-year CHEM/PHYS, excluding CHEM 111 / PHYS 100), Biology requirement (BIOL 111 for those who don't have credit for high school bio, and any 3 credits of BIOL/EOSC/ASTR/GEOB for those who do), and Laboratory sciences requirement (should be fulfilled alongside your Physical Sciences requirement). The one thing you don't have to worry about is the Computational Sciences requirement, as you'll have way more than enough MATH/CPSC/STAT credits to fulfull it. ;)

My recommendation to all first-year Science students intending to major in CPSC is to complete CPSC 110+121+210 in 1st year, and then spread your remaining slots amongst courses to fulfill your lower level Science requirements. Yes, that means you'll have very limited room for electives (in fact, I had no electives at all in my first year), but consider the following:

Communications has to be completed within your first 60 credits, and can't be deferred.
Only 3 credits max of your lower-level Science requirements can be deferred to 3rd year.
Course progression in CPSC is extremely linear in 1st + 2nd year (you're effectively bottlenecked by the prerequisite course chain), and CPSC courses only start to branch out in 3rd year (when you really have the freedom to pick and choose which CPSC courses interest you the most). Get started on your 1st and 2nd year CPSC courses ASAP.
You need CPSC 110+121+210 to get into co-op, and the more CPSC knowledge you have under your belt before entering your first work term, the better. That's assuming you intend on doing co-op, which I (and pretty much everyone I've met so far) highly recommend.

To help you understand, this is what my first year course schedule looked like (you can find more about what I think of first-year general sciences requirements in an earlier blog post):

Term 1: ENGL 112, MATH 104, BIOL 111, CHEM 121, CPSC 110

Term 2: ENGL 110, MATH 105, PHYS 101, CPSC 121, CPSC 210

Incidentally, since I passed all my courses (yay! :D ), that means I've fulfilled every single one of my lower level requirements, and I no longer have to do any BIOL/CHEM/PHYS courses anymore. In fact, from 2nd year onwards, the only courses that matter to me are CPSC, MATH, and STAT courses; everything else is effectively an "elective".

The UBC Academic Calendar also provides suggested course progression routes, which are definitely worth a read if you intend to do a degree in CPSC.

If you want more wiggle room (e.g. take only 4 courses in term 1 to have more leisure time to settle in), or really want to take an elective, you can consider deferring one of your ENGL courses (for Communications) to 2nd year, and one (or both) of your Physical/Lab sciences requirements (CHEM/PHYS) to 2nd year as well. You need MATH (including a number of 2nd year MATH/STAT courses, which are going to be prereqs for some of your CPSC courses later on), so you should definitely take a full year of 1st year calculus in 1st year (don't defer it), and I wouldn't defer the Biology requirement because you can just take an easy elective (EOSC 114/116/118, often considered to be GPA boosters) and just get it over with.

Now, onwards to CPSC course reviews for 110, 121, and 210...

Advice for new UBC students (general)

2012-06-18T02:14:00-07:00

As promised in my first blog post in my "Advice for new UBC students" series (previous post here), I'm going to stop focusing on Science so much and talk about stuff that's more applicable to all incoming UBC students. I'm not quite sure where to start though, so here's an unorganized list of everything that I can think of right now that's worth mentioning. Maybe I'll clean this up in the future.

There's actually a number of great blogs run by other UBC students out there on the web with lots of helpful info; my favourites include Carly's blog and idm04's blog, (among others). I guess it's inevitable that there's going to be some overlap, but I'll try to stick to stuff that's not already covered on other blogs.

1) UBC Grades Distribution webpage. A very powerful tool; use it to your advantage. e.g. you can use it to find subject/course/section averages, standard deviation, pass/failure rates, etc. Those who are obsessed with their GPA are going to be very well acquainted with this tool. ;)

2) 1 hr classes = 50 mins in length; 1 hr 30 min classes = 1 hr 20 mins. You get 10 mins to get to your next class (assuming you have classes back-to-back), which is enough to get from say, Buchanan to Chem at a steady pace, but not from Buchanan to Forestry. Location is something you should definitely consider when creating a schedule with back-to-back classes. If you can't walk to class on time, you can rollerblade, skateboard, or bike instead; I ended up biking a lot in my 2nd term, since I made the mistake of having several back-to-back classes at Buchanan and ICICS.

3) If you're going to bike, you should definitely know about UBC's bike shelters. There are 7 on campus at the moment, and it's a great secure place to lock up your bike if you're going to leave it on campus overnight. Access codes can be obtained for free at the AMS Bike Kitchen (at the SUB).

4) And while we're talking about bikes and getting around, I might as well briefly touch upon public transit here in Vancouver. There's another blog out there which I think does a pretty good job: UBC 101 - Beginner Commuting

5) Here's a handy MLA reference for your 1st year english courses, courtesy of the UBC Library. Your prof may or may not prefer a different style though, so do ask them first.

6) In mid-to-late August, once your booklist comes out, you're going to have to start worrying about textbooks. Whether you choose to buy your textbooks a week before class, or during the first/second week of class, is your choice, and soon enough you'll develop some intuition on when to go out and purchase your textbooks (or whether you actually need the textbooks your prof says you need). I've had profs who have assigned readings from the textbook the very first day of class, leading me to go out on a wild chase for textbooks in a frenzy; I've also had classes where the required textbooks weren't used until halfway through the course, or only a small section of it was used that I could've easily just borrowed it from a friend and photocopied what I needed.

More importantly, where do you buy textbooks? The UBC Bookstore should be your last resort, because while it has everything you need (and brand new as well), it is always going to be the most expensive place for you to purchase your books. Again, I shall refer you to another blog for some suggestions on where to look for your books.

My advice? 1) Ask your friends/older siblings if they have the textbooks (even if it's an older edition) that you need. 2) Saveonbook.com (I've had several friends personally recommend Saveonbook to me, and I've bought/sold several books there as well). 3) Facebook groups for buying/selling textbooks, e.g. here, or here. 4) UBC Discount Bookstore in the Village. 5) If all else fails...then yes, grudgingly head to the UBC Bookstore.

7) Bought an old I-clicker from somebody, and they neglected to mention that the ID code on the back has worn off (yeah, that's annoying)? No worries, you don't have to throw it out and buy a new one, just bring it to Chapman Learning Commons (3rd floor of Irving) and whoever is sitting at the Help Desk can retrieve it for you.

8) No idea where "Irving" or any of your classes are held? Refer to UBC Maps (while you're at it, grab a paper copy too...I recall getting a copy while I went to Brock Hall to pay my fees, although I'm sure those maps are distributed elsewhere on campus as well). And if you don't know the building where one of your exams is being held at (when your first midterms/finals come along), do go there early so you don't panic too much if you happen to get lost. :P

9) (Science specific) Co-op applications open up in term 2 of 1st year for CPSC (comp sci) and PHAS (physics/astronomy) students; everyone else has to wait for 2nd/3rd year before applying. Also note that it adds an extra year to your degree, and that your summer break will no longer be free (you'll likely be on a co-op work term). Still, most people who I've talked to heartily recommend doing co-op; I've just been accepted into CPSC co-op and my first work term starts in Jan 2013, so I'll reserve judgment 'til then. See Science co-op for more info.

10) There are plenty of ways to earn money on campus, but one of the lesser known ways is to take quick paid surveys offered by Psych. I thought I'd bring this up, since I myself have only recently heard about this, and I'd thought it'd be worth a mention: Paid Psychology Studies at UBC

11) Find a place where you can study while on campus; if you need suggestions, take a look at this. Lots of people think of Irving/Koerner whenever they need a place to study, but I prefer smaller, less populated locations. AFAIK, there's something like ~20 libraries ("library" is a generous term here; this includes various reading rooms spread around campus), so wander around a bit at the beginning of the term and find your own favourite places to study.

Note: Each of the SPAC coaches mention their favourity study locations on their profile; it might be worth checking out if you need some more suggestions.

That's it for now, I guess. I'm planning to do a write-up that's specific for incoming CPSC students (I have yet to find a blog that specifically addresses UBC CS students), so stay tuned! :) Update: that CPSC-related write-up has now been posted!

Advice for new UBC students (worklists)

2012-06-18T00:41:00-07:00

It's that time of year again, when schools all across the province are wrapping up, and students who are graduating from high school are starting to look more carefully at their post-secondary future, many of whom are attending UBC in the upcoming winter session. I still remember how I spent my last week in June last year, flipping through and trying to absorb as much information from the UBC Academic Calendar, as I tried to create that illusive, perfect worklist. Back then, I ended up looking through a number of student blogs for some more personalized advice and less dense material to sift through (the UBC Calendar isn't exactly an easy read); I found lots of nuggets of useful info which I'd like to share, as well as some of my own experiences during my 1st year at UBC.

So, first of all, you may be wondering who I am. Well, my name is Vincent Cheng and I'm a 2nd year (I'll be entering my 2nd year at UBC this coming September) Science student, doing a major in CPSC (computer science); in other words, I'm a BSc candidate, class of 2015, but I'll likely be graduating in 2016 instead due to co-op (which typically lengthens your degree by an extra year; more about my co-op experiences in a future post). As such, a lot of my blog posts are going to be specific to Science students and CPSC majors, but my hope is that you'll learn something new from my blog even if you're not a Science/CPSC student.

You're likely most worried about creating worklists and planning out a schedule for the upcoming year, so let's start off by talking about that. (Note: this section is going to be mostly Science specific.) The UBC Calendar has a huge amount of information about course options, degree options, prereqs, etc., but if you don't feel like reading every single page (nobody does), the following graph shows you a concise overview of what you really need to know:

UBC Science Flowchart

As of right now (June 2012), that flowchart is up-to-date as far as I'm aware, but do note that UBC can of course change any of the requirements for its programs.

Now that you have the "big picture" in mind, here's what I have to add:

1) MATH: You'll quickly notice that you have lots of options for math. First off, keep in mind that math falls under the computational credits requirement (= you need 9 credits from MATH/STAT/CPSC courses, by the time you enter 4th year; apparently, this is one of the more easier-to-forget requirements that trip up people later on). With that said, strictly speaking you are only required to take MATH 100/102/104 or equivalent (1st year calculus, derivatives); the remaining 6 credits can be formed with any combo of MATH/STAT/CPSC courses. However, MATH 101/103/105 or equivalent (1st year calculus, integration) is required for most, if not all, degree options in Science, so I strongly recommend that you take both MATH 100+101 (or 102+103 or 104+105), and that you do so in 1st year. Defer the remaining 3 computational credits for 2nd/3rd year; if the specialization you'd like to choose doesn't require 2nd year MATH courses, and you're sick of MATH and you just want a GPA booster, consider either STAT 200 or CPSC 101.

If you've never taken any Calculus courses back in high school, substitute MATH 180/184 for MATH 100/104 respectively (I have no idea why MATH 102 doesn't have an equivalent option). Basically, it's the same course, except those in 180/184 get an extra weekly tutorial. If you're really, really good at math and you've been invited, you have the option of taking honours 1st year math courses (MATH 120+121), but I'd actually advise against it unless you're interested in doing a major/honours degree in math, or you really, really like math. I know I don't. :P

Some other tidbits: generally speaking, MATH 100+101 has the lowest averages amongst all first-year math courses (but hey, engineering courses always have the lowest averages :P ). MATH 102+103 have labs that you must attend, whereas MATH 100/104+101/105 involve only lectures. Also, you can mix and match between the various derivatives and integration courses, e.g. MATH 100+105, MATH 102+101, etc.

Personally, I ended up taking MATH 104+105. The averages for these courses were noticeably higher than say, MATH 100+101 (I mean, my 105 section had a 74% average, which is pretty high compared to most other 101/103/105 sections).

2) ENGL: You need 6 credits (2 courses) of eligible first-year english courses, i.e. any 2 of ENGL 110/111/112, ENGL 120/121 (honours equiv. of 110/111), SCIE 113, ASTU 150/300. This is the "communications requirement", and it must be done within your first 60 credits (~ within 2 years). I recommend just getting it over in 1st year so you don't have to worry about it, i.e. take 1 english course per term, but of course you can defer it for 2nd year if you wish.

Be wary of SCIE 113; it's a relatively new course and not all other faculties consider it to satisfy 1st year english requirements (e.g. med). You'll also likely have troubles with this if you choose to do a degree at another school.

My recommendation: ENGL 110+112, or ENGL 111+112 (I found 112 (focus on writing) to be easier than the literature-based 110/111, but that's just me I guess). I myself ended up taking 112 in term 1, and 110 in term 2. It doesn't matter in what order you choose to take these courses.

3) BIOL/CHEM/PHYS: BIOL 140 is infamous for being the course with the heaviest workload you'll encounter in 1st year (and it's only worth 2 credits). General consensus is that if you have AP/IB credit for it, don't bother with 140. Otherwise, I don't have much to say about these courses; I'm doing a CPSC major, and I only took the minimum amount of BIOL/CHEM/PHYS credits as required by 1st year science requirements, i.e. the biology, physical sciences, and laboratory sciences requirements (i.e. I took BIOL 111, CHEM 121, and PHYS 101, and I never have to take another BIOL/CHEM/PHYS course ever again...CPSC major, remember? :D ).

Most 1st years in Science, however, will end up taking BIOL 112+121+140, CHEM 121+123, and PHYS 101+102. First-year honours phys stream is PHYS 107+108+109, but again, my advice is to avoid honours courses unless you want to do a major/honours degree in that field, or you're really, really passionate about the subject, as with the MATH and ENGL honours stream courses as well.

Lots more detailed information about Science lower-level requirements can be found here.

I think I'm going to stop with course recommendations right here. Hopefully I've helped a few UBC Science 1st-years with their worklists, or at least given them stuff to chew on for a while. Anyways, I'm going to talk about some more general stuff in my next blog post, which I hope will help all those incoming students who aren't going into Science.

print "Hello world!"

2012-06-17T03:04:00-07:00

On a sudden whim, I've decided to create a blog about...myself. A fascinating subject, of course. :P

I figure that a blog is the most suitable place to spout out whatever comes to mind, rather than on social networking sites like FB and Twitter. I'll probably end up blogging about a variety of subjects, but the intended focus of this blog is to document my thoughts and feelings as I progress through university (let's hope I survive) and my future pursuits.