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

Edit:

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

https://github.com/leehsueh/django-janrain

——————————-

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
TODO:
  • 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….

NYST, BibleDB –> Bible Tidbits

It’s been awhile hasn’t it?

Thank God, two weekends ago the NYST was completed at Hillsborough church in NJ. This was the first time I’ve ever coordinated anything in church of this scale, so although it was a bit stressful, I learned a lot and feel blessed to have such reliable and diligent coworkers in NYM. I also gained a few powerful tidbits during the seminar which were really needed and they have renewed my sense of meaning and strength in serving God (lately I’ve been feeling a bit weary, including during the time I spent prepping for NYST). I guess I’ll just share a few that I remember off the top of my head.

  • Sometimes our zeal can cover up a hidden motive that we weren’t really aware of. In one of the classes we learned how Paul was truly zealous for God before his conversion, yet his zeal (and that of the Pharisees as well) actually stemmed from his desire to assert himself. The law of God is in essence good and holy and righteous; how can anyone who is so zealous for the law miss its very essence and become someone cruel who enjoyed punishing others? Zeal without true knowledge can become zeal with an ulterior motive. And even if it doesn’t, zeal without knowledge causes more harm than good.
  • A growing fellowship must know where its strength comes from. Likewise for the coordinator and for any worker of God. Paul says in 2 Corinthians 3:5 – “Not that we are sufficient of ourselves to think of anything as being from ourselves, but our sufficiency is from God” (emphasis added). I think more recently I’ve come to try to rely on my own strength without really entrusting to or having faith in God’s power. As a result I was always tired and reluctant to do work. But if we know where our strength comes from, we have the assurance that in whatever we have been entrusted to do, we can have sufficiency from God.
  • Be wary of becoming too task-driven or inflexible with deadlines, because it may lead to caring more about the smoothness of an event than the needs of the members who participate. Arguably it is necessary to be task or deadline driven because otherwise things just don’t get done. But we need to be careful not to become so efficient that we neglect the needs of the people and the purpose of holding such events (which are intended to meet those needs). I may have been guilty of this in preparing for the NYST so I need to think a little bit more on how to strike a good balance.
  • When dealing with weariness from holy work, it is important to pinpoint the cause of the weariness. Are we tired/burdened because our spirit is not being truly satisfied? I think this is commonly the case for me, and I believe this blog post on 5 loaves 2 fish summarizes the concept very well. If we’re not being satisfied in spirit, then it’s an indication that our service is more like busy-work and not something we do because it is fulfilling. Perhaps our servitude is not accompanied with the necessary cultivation. If we do not know the God whom we serve, how can that service be meaningful to us? Jesus set such a wonderful example for us. After every great work, like feeding the 5000, he retreated to pray. This teaches us that after we complete some holy work, whether it be an RE workshop or a seminar like NYTS or NYST, that is the time we need to pray the most. That prayer is needed for spiritual rest and renewal of strength. We often emphasize prayer in preparation for some event or special activity, but forget that prayer is just as important afterwards too.

During the fellowship on the last night, we had a few epic rounds of telephone charades (with like 20 people in each line). It was wildly funny to watch and I’m glad I was the designated photographer. Anyways, Pr. Hou had a really interesting observation from it which he shared during the closing ceremony.

He said that the game reminded him of how difficult it is to pass a message down sans variation and mutation. Indeed, in telephone charades the original message becomes beyond recognition by the 3rd or 4th person. When it comes to the truth, we are also tasked with passing down the gospel to those who come after us. It made me realize two things:

  • We need to really know what we believe in, and understand what we have been taught by those before us. In a game like telephone charades, it is extremely difficult to perpetuate the act if you don’t know what you are portraying, even if you mimic every movement mechanically.
  • Even when we think we know the message, we don’t realize our inadequacy until we’ve tried teaching it. “You don’t really know it unless you can teach it.” Sometimes in telephone charades people were able to recognize the answer, but their execution in communicating it to the next person left more to be desired. Thus, even if they knew what the answer was, it was still lost afterwards.

In the game it’s always funny to pick out who in the chain of people really messed it up, but when it comes to the truth of the gospel, we must certainly not be the generation that distorts it for those who follow us. Paul urged Timothy to guard the doctrine with the Holy Spirit, and to preserve the doctrine. As churches become increasingly liberal, the word “doctrine” takes on an increasingly negative connotation of narrow-mindedness and conservatism. But like it or not, doctrine is indisputably crucial to Christian faith – Paul’s exhortations to Timothy and the churches in general attests to that.

In light of all this, it is truly a marvel that the doctrines of True Jesus Church have been preserved since her establishment in 1917. Across borders, cultures, and generations, our basic beliefs have been kept intact. By the grace of God, may we continue in the pattern of sound words which we have heard.

Now onto a completely different topic, I’ve been thinking about what to do with BibleDB. The site’s been inactive and I would venture it’s because of these reasons:

  • people are simply too busy
  • it seems like you’re supposed to write some long and insightful reflection (in this respect it has become something quite different from the original intention of categorizing verses)
  • even if someone did want to get around contributing, the password is long forgotten

A redesign has been swimming around in my head for a little and I’ve gotten around to developing it. I call it “Bible Tidbits” because the purpose of it is to jot down “tidbits” or bite-size notes/annotations, rather than fully developed reflections or devotionals. These tidbits are generally the short little notes you might squeeze within the tiny margins of your Bible, but often record some interesting observation or thought associated with a passage, or with a set of cross references.

Thus, the semantics for the content in this redesign is different from the existing BibleDB. Instead of “Context notes” and “Reflection,” there is “Tidbit” and “More,” for cases where you do want to put down more elaborate thoughts. Typically, however, only the “Tidbit” will be populated and the “More” will be hidden by default unless the person wants to specifically write more stuff. The design is meant to feature the tidbit prominently, so no more need to click on a single record to view its content.

I also removed categories altogether, and just left the organization to tagging. This lets users organize their notes themselves rather than enforcing some categorical scheme.

And the most important enhancement, in my personal opinion, is cross references. Tidbits can be associated with multiple verses/passages instead of just one.

I will say, however, that I’m not developing this app and trying to push it so that many people will want to use it. Ultimately, I’m kind of developing it for myself and tailoring it to the way I work, and if it appeals to other people, great! But for now, I’m just hoping it can be a useful tool for me, a place to perhaps centralize all my Bible margin scribbles and inspirations that can be retrieved later for further development.

Some things I would like to put in place before “releasing it” for general use are authentication/login with existing services (most likely google or facebook) so people don’t have to maintain another special account, and a way to query a passage reference and bring up all the tidbits associated with that range (this is already possible in BibleDB, but because the underlying data model is different, doing it in the redesign is a little more involved).

<begin shameless plug>Anyhow, if you’re interested in checking out the preview, let me know! It’s a fun (although somewhat time-consuming) project for me as it is also an opportunity for me to work with HTML5, CSS3, and Javascript even more. It would be great to get some feedback though, especially in relation to how it should be different from BibleDB so that it can be more useful/more convenient to add content. So again, if you’re interested or just curious to see it, let me know and give me suggestions! </end shameless plug>

I’m not publishing the url since what I have now is basically a prototype and it could very well be so inefficiently fetching too much data in each request that if even a few people play with it my very limited memory quota will be exceeded, causing my webhost to terminate my process.