Google Webfonts Not Rendering in Chrome for Windows in Headers with Bootstrap Styling

Wow, it’s been awhile since I last posted about…ANYTHING. Anyways, had to resolve an issue last night with Google webfonts not rendering in the Chrome browser on Windows (ironic…). There’s tons of complaints about ugly rendering in Chrome but for me the font was rendering at all even though on Google’s Webfonts page it was fine.

After some finicking and comparing around, I discovered it was actually an issue related to how Twitter Bootstrap styles headers (h1, h2, etc, not the element). They specify the following CSS rule:

text-rendering: optimizelegibility;

For whatever reason, this causes the webfont not to render at all (again, only in Chrome on Windows). Change the value to auto or optimizespeed to get them to show up.

text-rendering: optimizespeed; /* or auto */

Didn’t find anyone else having this issue from my searching, so I thought I’d post it here and hopefully it helps other people who come across it!

Day 4, Another Productive Morning

This morning, I hacked together another bare-bones django app that does the same thing as the evernote one I wrote on Monday, except it integrates with google docs, where most of our existing word studies are. And yes, I created yet another github repo to share the oauth process involved.

Another nice thing about free mornings is I can take my time in praying and reading the Bible. It doesn’t mean I get epiphanies, but at least I can read a chapter slowly and multiple times.

On another note, one of the courses I’m taking is called Design Thinking Bootcamp (yay! I got into it!). We were assigned an interesting design challenge today that is due next week. I won’t say what it is since it’s possible I may interview you about it (“secretly” or explicitly), but I think it’s good that I’m being pushed out of my comfort zone to try to talk to people and find insight in uncovering a particular need.

Beginnings of LDT

This week was my orientation at Stanford’s School of Education. On Monday and Tuesday there was a workshop for my program (LDT) that introduced us to the “design thinking” process. Essentially it is a wildly collaborative and creative approach to problem-solving. I thought our facilitator gave a really nice graphical sketch of what design thinking is like compared to the “conventional approach.”

In a conventional approach, generally speaking, you identify a question or problem. From the question/problem, you try to find an immediate answer or solution that will work. Graphically, it might look something as simple as this:

The conventional approach to problem solving.

There’s nothing wrong with this approach, and it works fine. Design thinking is in a sense a less direct approach to problem solving, with the hope that the solution is highly innovative and well-informed. Graphically it might look something like this:

The design thinking approach.

Instead of going from the problem directly to an answer, design thinking explores a variety of possibilities. Possibilities don’t have to be feasible or practical – they are like “what-if” or “I wonder if this would work” kind of solutions. This allows for copious amounts of creativity to come into the process, even if most of the ideas are lucrative. But the idea behind exploring potentially lucrative solutions is that an extraordinary solution can be found by “backing off” a little bit. With this approach, the solution is most likely pushing the boundary of what’s possible and is a product that most wouldn’t have expected, yet works really well. Neat concept, huh?

Broadly, there are 4 phases:

  1. Research
  2. Design
  3. Prototype
  4. Scale and Spread

The first two days of orientation was an exercise in the design thinking process, sprinkled with icebreakers and short improv games. We broke up into groups of maybe about 15-20 people, and each group practiced applying design thinking to solve the following question: How can we increase low-performing middle school students’ engagement in learning?

For the research phase, each group interviewed 2 people in the education/teaching industry, asking questions we thought would be helpful in designing a solution. We took notes on post-it notes and later posted all of our findings on a wall and clustered them into categories.

From there, we started the design phase by throwing out ideas on what the solution might look like or might involve. Because of the collaborative nature, there were a ton of ideas ranging from curriculum development, use of media/technology, classroom space, techniques, policy changes, community outreach/involvement, etc. These were also written on post-it notes and clustered into categories. At this point we tried to refine our findings by focusing on one or two clusters for prototyping. One of the funnier ideas was “Get Justin Bieber to teach math.” There were a number of interesting ideas, but I can’t recall them right now.

Prototyping was an interesting phase because it was still very much like a design/conceptual stage, at least for the purposes of our exercise. We were given pipe-cleaners and styrofoam and other random crafts materials to help us form our ideas in some abstract way, but a lot of us ended up just playing with them while talking/fleshing out details of a potential solution. My mini-group decided to tackle the issue of curriculum material not being relevant to students’ interests or not having a connection to what the student perceives as the real world.

Scale and spread then looks at how our solution can “get legs” to become real. We investigate what needs to happen to make the solution realized, e.g. from who do we need buy-in, where could funding come from, how the solution will be deployed, what the business model might look like, etc.

Finally, at the end each group of 15-20 had to pick one idea and prepare a presentation for it. Our group ended up picking the idea that my mini-group thought of (woot!) and our presentation revolved around a skit of our solution in action. Our solution turned out to be a really ambitious digital content platform that connects topics at school (“What did you learn today?” prompt) with an individual students’ interests, which could also serve as data collection for teachers and schools to further inform their lessons and policies. Our skit demonstrated a disengaged student in class where the teacher was talking about Mayan culture, but the student doesn’t really care about anything except basketball, jazz, video games, and erm…women. When the student opens the mobile app and enters “Mayan culture”, the app would fetch rich content that relates Mayan culture to his particular interests. For example, it might tell him about Mayan sports and how the losers of said sport competitions were subsequently sacrificed. The app also feeds into a type of social network that suggests local experts that students can communicate with on said topic. All of this data (student’s interests, what topics the students looked up, and what content they viewed) can be fed into a “teacher dashboard view” which would compile and distill all of it to gauge the interests and activity of say, one’s class. This information would be valuable in making lessons more relevant to students’, and for inviting guest speakers to come to the school, based on what a large number of students might be commonly interested in.

Anyways, I am really excited about this program and working with the people in my “cohort.” There are 27 people in our program and they are all so intelligent, fun, passionate, and purpose-driven. I’ve never felt this eager about school before, so hopefully that means I made the right choice.

Thank God for this wonderful opportunity, and I hope I can take advantage of it to its fullest so that ultimately, the things I learn can also be applied to church work, especially RE.

Django Documentation on Writing a Custom Backend


Today is a special day, because I forked my first github repo! +1 geek points.


Another nerdy post which may be of some use to a random novice django developer like myself. Feel free to ignore unless you get a kick out of my programming frustrations.

One of the reasons why I love developing with django is because the documentation is excellent. I’ve almost never had trouble using it both as a reference and as a “how to do ____”. Almost, because of what happened today.

I was determined to implement sign-in using the Janrain Engage service for my django apps and after reading the documentation on it from both the Janrain side and the django side, it seemed pretty straightforward. Sample code is also a big help.

After a few hours of coding/testing/debugging (committing other stupid typos and errors), I had everything pretty much working in terms of interfacing with the Janrain API service, mapping django users to external accounts, and authenticating/logging in through django. The only problem was even after I was allegedly authenticated, every time I tried to access a page limited to “logged in users” it would still redirect me to the login page. WHY? I was using the development version of Django so I thought maybe it was a bug and I even tried downloading the latest stable release and testing again; still not working.

Turns out, this is what killed me. When writing an authentication backend, you only need to implement two methods: an authenticate(self, **kwargs credentials) method and a get_user(self, user_id) method. This is the line in the django documentation that killed me:

The get_user method takes a user_id — which could be a username, database ID or whatever — and returns a User object.

“Oh, okay. In that case I’ll just make the user_id parameter be the unique identifier that’s provided by the external service.” So I implemented that method treating user_id as such, and then moved on to the authenticate() method, which required more logic. In practice, I only ever saw the authenticate() method being invoked from the custom code I was writing so I thoughtlessly assumed that my get_user method was only needed for compatibility purposes or for implementing more advanced backend features. And of course, my thoughtless assumption was wrong.

The fix for my problem turned out to be that the get_user method was being invoked somewhere in the framework and it was supplying a user_id corresponding to the primary key of a django User object. After spending hours trying to pick out problems with my authenticate method and view logic, it turned out to be a problem with the 4 lines of code I wrote and never looked back on. Boohoo. Partially my fault for treating the user_id arbitrarily, and partially the documentation’s fault for not describing how the get_user method is used and how to know what the user_id corresponds to (since the documentation stated that it could be “whatever”!).

Evaluating Lightroom 3 vs. Aperture 3

Today I spent pretty much the whole day trying to figure out whether I should use Adobe Lightroom 3 or Apple’s Aperture 3.

Here’s what I want to ultimately accomplish:

  • store my photos on an external drive
  • be able to edit/retouch non-destructively select photos without being tethered to my external drive
  • localized adjustments
I downloaded the trials of both applications and discovered that both can achieve the above. Both allow maintaining multiple libraries (or catalogs in Lightroom terms), have adjustment brushes, stacking, keyword and metadata tagging, and so forth. So in no particular order, here are my observations. (I should note that none of these were really deal-makers or breakers because as I said before, both can accomplish my main goals)
What Aperture Has that Lightroom Doesn’t
  • adjustment brushes for every type of adjustment, including curves (lightroom adjustment brushes “only” let you adjust exposure, brightness, contrast, saturation, clarity, sharpness, and color overlay; not that these options are limiting in any way)
  • Faces detection and tagging
  • Native GPS and location tagging (lightroom can achieve this with a 3rd party plug-in)
  • More advanced slideshow options (e.g. multiple audio tracks which can be interspersed with arbitrary durations)
What Lightroom Has that Aperture Doesn’t
  • Some superior editing features like noise reduction (very impressive) and lens distortion correction
  • Physical folder management with the ability to synchronize to the contents of the physical folder (plays nice with manual copy/move operations you do in the file system)
  • side-by-side comparisons with synchronized panning and zooming
  • cross platform compatibility (but legally, you need 2 separate licenses to install on both mac and windows)
These are by no means a comprehensive list of things which one has that the other doesn’t, but those are just the ones I noticed.
Licensing/Pricing notes
  • Aperture is $79.99 from the Mac App Store vs. $99.00 for Lightroom (Education price; there is also a Student/Teacher edition which is $89.99)
  • Aperture can be installed on numerous mac computers linked to your iTunes account (possibly more than 2)
  • Lightroom can be installed on up to 2 computers with a single license (but again, must be the same platform)
  • both are for personal/non-commercial use at the prices and licensing options listed
So what did I end up choosing? Aperture 3.
But this decision was far from easy and definitive. The main deciding factor was that I have Mac Appstore credit from purchasing my macbook air. If it were not for that, I would’ve chosen Lightroom 3 and paid the extra 20 dollars. Money/cost aside, I actually like Lightroom a little better for the following reasons:
  • One click for applying a previous photo’s adjustments to the current photo
  • when performing undo, an overlay shows you what operation was undone – this is a very nice touch
  • writing metadata changes directly to the master files (this is possible in Aperture supposedly, but seems like there’s a bug and you get an error if you try to write metadata changes to master jpg files)
  • the keyword tagging interface
  • a significantly smaller memory footprint (no rigorous tests performed, but when I had both Aperture 3 and Lightroom 3 open, Aperture 3 consistently took up much more memory). This is a pretty major bummer for me in choosing Aperture 3 instead of Lightroom. In practice, both ran smoothly on the macbook air, so hopefully it says that way after time.
  • smaller catalog size vs. Aperture’s library size (this is mostly because Aperture generates more preview files, which can be turned off).
  • a friend pointed out a rather good point: adobe is more trustworthy and more mature in this area than Apple
In summary, I think they’re both good in terms of functionality and capability. From an interface perspective, both are pretty easy to navigate, but as noted above I like certain things in Lightroom more than Aperture. Memory-wise, it seems Lightroom is definitely more streamlined. Cost-wise, Aperture 3 is cheaper if you purchase through the Mac Appstore.

Setting Up the Macbook Air for Development

Reference for self:

  • installing PostgreSQL (thanks to this forum thread for resolving the issue I was getting)
  • install XCode (comes with SVN and Git integration)
  • installing django
    • first I tried to do this with svn, but the command failed…so I decided to install SVN from macports. It finally just finished
    • in the time it took macports to install svn (and a bunch of dependencies which I thought were already installed…like sqlite3), I cloned the django git respository instead
    • configure the django.pth file in site-packages
  • installing MAMP for apache, php, and mysql
  • install postgresql and mysql python drivers
  • clone my code from git
  • run the code! (*cross fingers)
  • resume development after almost 1 month of no activity….

Life with a CR-48

It’s been 1-2 months since I got the CR-48 (a prototype laptop/netbook that runs Google’s Chrome OS). How has it fit into my habits and workflow?

When It Has Come in Handy

  • Productivity on the BART; 100MB of free 3G data per month for 2 years is a pretty sweet deal. 100MB doesn’t seem like much, but most of the time I’m using wi-fi anyways and I haven’t yet used up the monthly quota. Incidentally, sending emails and editing google docs doesn’t use that much data.
  • Taking sermon notes at church; thanks to the SSD, there’s no more lap burns or noisy fans blowing. The battery life is also sufficient for use throughout a whole day (with wifi and 3G turned off), with more juice to spare.
  • Taking my computer downstairs while I “cook”/prepare my dinner
  • Lying down on my bed to read something without risk of setting my sheets on fire
  • Checking the weather after I’ve shut down my computer
  • I can type in Chinese using pinyin!

What’s Not So Great

  • As I mentioned in an earlier post, it’s weak in terms of processing power. Any video-related activity chokes and lags at least a little bit; video-chatting in particular.
  • Not optimal for local development. Switching on developer mode potentially makes it possible if you install a text editor and manage to get your programming language of choice compiled on it, but without developer mode, it’s not possible.
    • Alternatively, one can SSH into a development server, but again, not possible without developer mode
    • Cloud-based development is a new trend that’s starting to gain some traction. Recently I started using github with cloud9ide, which is very promising, but cloud9 currently can only run javascript, even though it supports creation of python and ruby files. Git integration still makes it useful for non-javascript development, but again, still not optimal yet.
  • The wi-fi antenna seems a bit weaker compared to my dell xps. My room does not have the strongest signal reception, but my xps can still maintain a consistent and stable connection. The CR-48 though, not so much.
  • Chrome’s native PDF reader is pretty inadequate; no bookmark support, no facility to jump to a certain page; workable, but not convenient. Other PDF reader plugins can’t be used either.
  • Chinese pinyin input is only supported for simplified :(

So this post is probably pretty boring to everyone except for those curious about the CR-48, but I said I would post more about it and so this is my attempt at following up on that claim.

In other news, I decided to go to Stanford for graduate school, and ordered an iPad 2 as well as a 13 inch Macbook Pro, marking the beginning of my transition to the apple ecosystem. I’ll try to “justify” these purchases in a later post.