Category: Blog

I recently built a chrome extension. It maps craigslist housing searches onto a map. This is a two part blog post on a few things I’ll keep in mind when writing more Chrome extensions. This is the first post and will talk about parts of a chrome extension and where to put code. Of course the official documentation probably does a better job, but this summary is as much for me as it is for you.

Each Chrome extension has the following files:
– manifest.js: This file will contain basic but important information about the extension, such as it’s name, description, any files being included, websites when the extension will come alive, as well as be able to make cross-site requests, as well as security considerations.
– background.js: This file is your grand daddy. It orchestrates communication between the different parts of the system.
– Other JavaScript files: These files represent what will happen inside different content views – page actions, browser actions, tabs etc.

Code organization:
background.js – Anything that the browser does, such as opening new tabs, placing buttons, assigning action to a browser button and so on, is handled by background.js.
some_content_script.js – You guessed it! Things that happen inside the content of a window – basically whatever happens inside the html tags is handled by some content js.

Lately, I’ve been fortunate enough to contribute to Dot429. It is, among other things, a great place for the LGBT community and their supporters to connect, discuss business and mentor each other.

One of the mini-projects, a contest, required us to ask for a telephone number, but in three separate fields: (area-code), (first three digits), (last four digits). Once the fields were accepted and validated, they were to be concatenated and stored in the database.

Rails makes this very easy: just add the accessors for non-database fields and validate them as we normally would through the built in validators:

When the save() function is called in the controller, the model should validate just fine, even if the particular fields do not correspond to columns in the database.

Now, what if we want to make use of validators for a model that has no table in the database?
Rails throws its arms in the air if you do the above but for a model that has no corresponding database table. The solution is simple: create a dummy table. This, in my opinion, is the simplest solution to the problem because it makes Rails happy. We can even create one dummy talble and associate it to any model that does not have a corresponding database table. Like so:

What if none of the alarm clock apps for OSX work just the way we want them? My favorite app until a couple of hours ago was Robbie Hanson’s excellent Alarm Clock 2 app to wake me up. It is simple, intuitive and did exactly what I needed, which was to let me pick a song from my iTunes and set it as my repeating alarm. But then it couldn’t play Soma.fm streams, which iTunes gladly plays.

Luckily OSX comes with excellent built-in tools to make it play the awesome internet radio at 10am.
Here are the steps:

First, create a playlist using iTunes and add music to it.

Now, lets tell our Mac what we want it to do: Open AppleScript Editor. It should open a new script editor window. Paste the following code – be sure to replace MY_PLAYLIST with the name of our iTunes playlist.

set volume 10
tell application "iTunes"
set the sound volume to 0
play user playlist "MY_PLAYLIST"
repeat 10 times
if sound volume is less than 100 then
set sound volume to (sound volume + 10)
delay 3
end if
end repeat
end tell

The AppleScript is very easy to read. We first set the computer’s volume to full, then start iTunes and tell it to set the volume to 0. Then we tell it to play a playlist. Finally, we gradually increase the volume.
Go ahead and press the “Compile” button, and then the “Run” button to test out the script. iTunes should fire up and start playing the desired playlist. . Now save the script to an appropriate location – I put mine in my home directory (/Users/Cabanaman/) and called it alarm_clock. AppleScript will save it with a .scpt extension, so it might look like alarm_clock.scpt, depending on our display settings.

We now need to do two things: First, we must schedule a time for our alarm_clock script to run everyday at our chosen time, and then we need to make sure that our computer starts up on time for the script to actually run on time! Lets tackle the scheduling first.

We have two choices for this step: the easy way using iCal that Joachim suggested, or the crontab way, which involves some Unix magic!

The iCal way
Simply, open iCal and create an event. Set the event to start at our preferred wake-up time (10am), and set the alarm to Run Script and select our AppleScript (in my case, alarm_clock). Thats it! Lets skip the crontab, and move onto the final step.

Alternatively, the crontab way:
We are going to use crontab to schedule our alarm clock. Open up Terminal. What we are going to do now is open up the scheduler file in a text editor, and enter a line for our alarm clock to run at the appropriate time. Here is what the crontab line’s format is:

MM HH dd mm ww osascript /Path/to/alarm clock script.scpt

Here MM stands for Minte, HH, stands for hour, dd for day of month, mm for month and ww for day of week. osascript is a program that lets us run AppleScript files from the command line. And finally we will want to enter the path to our alarm clock script. Start crontab’s editor:

crontab -e

If we have never done this before, then we are most likely in the vi editor. By default, the vi editor does not let us enter text. Press i to enter insert-mode. Now lets start typing in our crontab entry. Here’s what mine looks like:

00 10 * * * osascript /Users/eyce/alarm_clock.scpt

Thats right. I plan to wake up at 10:00am every day! The *’s represent wild-card entries meaning every day / month / day of the week.
Now, when we’re happy with the line, press Escape to get out of insert-mode, and then type in :wq and press enter. This will save the crontab settings and quit the editor. Lets type in crontab -l and press Enter and crontab should show us our new settings.
We are done in Terminal and can type in exit and press Enter to end the Terminal session and finally quit the Terminal.

For the last step, we are ready to tell our system to wake up at the right time for our crontab or iCal event to run our AppleScript to run iTunes at the right time! Lets go into System Preferences, then Energy Saver. Lets press the Schedule button and set the wake-up time to about 5 minutes before our actual alarm is supposed to go off. In my case, since my alarm is set for 10am, I set the scheduler to turn my macbook on at 9:55am.

And that is all! =). The computer should start up, along with the cron/iCal event, and then the AppleScript, which will start iTunes with our favorite playlist at 10am! Or, whatever time you set yours for 😉

About a year ago, I realized that I had a developed a terrible habit. Whenever I was idle, even for a brief moment, I unconsciously visited my favorite news sites. A new browser tab would open, and my fingers would type away. After spending half an hour, an hour, sometimes even a couple of hours on the sites, I’d snap back to realize that I was wasting time. This happened several times every day – I often visited the same site only to discover that I had already read every article of interest.

My solution was to block off any website that I found was too distracting. I wrote the following script and stuck it in my home directory:

The idea was to replace the host file /etc/hosts with one with a list of blocked websites.
I created two copies of /etc/hosts. One was called /etc/free_hosts and the other was called /etc/blocked_hosts. I then changed /etc/blocked_hosts to look like this:

Any websites that I did not wish to visit when I was working would simply be redirected to 127.0.0.1. I replaced the default apache homepage on my laptop with a gentle reminder that I had a lot to get done before reading the news.

When I was ready to do work, I opened up a terminal window and typed in:

~/switch_hosts block

Two things happened as a result of this script: suffering from withdrawal, and increased productivity. Initially I tried to visit the blocked sites with even greater frequency than before, only to be presented with my own “get back to work” page. Despite this, I achieved hours more productivity everyday. And after a few days, my frequency attempted site-visits started to go down. I began to concentrate on work for longer stretches of time.

A few days ago, I signed up for a Linode instance with Ubuntu 10.04 installed on it. The plan is to gradually move all my websites, including this blog to the new instance. I gave NGiNX a shot as my web server after reading a few articles on how it is light and fast, compared to Apache. Here’s what happened.

1. Don’t lock yourself out of your own server:
The server needs to run NGiNX with Ruby on Rails, MySQL, and PHP. I found Chris Kemson’s guide to be the best and started following it.
The installation was fairly smooth, except for one hilarious mistake on my part: I followed the instructions too closely. During the step for installing UFW (Uncomplicated Firewall), Chris asks us to first enable the firewall, and then turn on support for ssh and http. So I went along and turned on the firewall, only to find myself logged out of the ssh session and no way to go back in. First, I laughed pretty hard at myself, and then logged into the Linode control panel to see if there was anything I could do. Thankfully, Linode provides a web-console, which let me log in and allow ssh access through the firewall.

2. Phusion Passenger only speaks in one Ruby at a time
Something I wanted to support was being able to run both Rails 2 and 3. A lot of people seem to recommend installing RVM for this. RVM lets us run multiple versions of ruby on the same system, and switch between them as needed. This means that it is possible to setup Rails 2 under Ruby 1.8.7 and Rails 3 under Ruby 1.9.2. So far so good. The problem is in deployment. You see, Phusion Passenger does not allow us to run multiple versions of Ruby. The lineexport PATH=/opt/myruby/bin:$PATH is an http level statement in nginx.conf, and specifying a different ruby for each server simply generates an error. I eventually settled with removing RVM, and running Rails 2 and 3, installed under the same Ruby version (1.9.2).

3. Errors with hard to find solutions
Here are a few NGiNX configuration related errors that haunted me:

Background:
We have just created one or two new WordPress pages using wp-admin – say an “About” page and a “Resume” page. You’ve done all the work to write up all the content, and format it properly and when you publish, the pages look fantastic!

Problem:
The About and Resume pages have web addresses that look like this: http://www.cabanalabs.com?page_id=99
This is all well and good, but no one is going to remember that our resume is sitting at page_id=99. It would be much more desirable if someone could just type in: http://www.cabanalabs.com/resume

A simple solution, if you are running a newer version of Apache as your web server:
Assuming that we have administrative access to our apache server, and know where our VirtualHost file is, possibly in the /etc/apache2/sites-available/ directory. If you don’t – then stop right here and get a hold of your system administrator! He may have a better solution to this than what you see here :-)..

Modify the VirtualHost for our blog’s domain so that it would include a RewriteRule that would allow someone to then go to the simpler address, http://www.seevishal.com/resume, and reroute them to the correct WordPress page, which in this case would be http://www.seevishal.com?page_id99.