Joe@Nitobi

October 14th, 2007

I was talking to someone about a new rails project, and we asked about which server would be the best one to work on. Of course, me being a person who loves apt-get and hates RPM, I said one word.

Debian

But then I had to point him to a place to go to make things easier. The problem is that deploying a Rails app is rarely easy, especially one that actually is meant to not die. Not only that, but I don’t always agree with all the tutorials. So I’m going to write a series of blog posts about how I’m going to do it. I’d recommend reading this post when it comes to installing ruby, rails and gems on Debian/Ubuntu but forget any of that Capistrano/Apache stuff that they talk about. I recommend vlad an nginx for setting up and deploying rails apps. We’re going to talk about nginx in thsi post.

So, the first thing that is done when setting up a production server is to choose the webserver. Now, conventional wisdom says that when you’re running Linux, you will most likely use Apache. Conventional Wisdom is very wrong, since Apache is a giant 800lb Gorilla of a webserver that has more features than you’ll ever possibly need. It’s great if you want to load things like mod_php or mod_python (which you would do with django, but that’s the topic for another post), but it sucks if you want to use it for Ruby, since we’re going to be forwarding everything to the mongrels anyway.

So, what do we use? We’re going to use the Big Red Webserver from Russia, nginx. nginx is a nice http/reverse proxy server, with small, human readable files. The first thing that we’re going to do is install it on Debian. Sudo as root and do this:

See, isn’t apt-get the coolest thing ever! Beats the crap out of yum! Anyway, what this just did was installed nginx, so in /etc/nginx, you are now going to have to delete your stock nginx file and create a new one. The first thing that you do is specify the user. It’s best to create a user for this such as www-data.

Note, we also set the log files. Now, we have to set some basic settings, such as the mime-type includes, the connections that we will accept, and gzipping your data. Simple, commonsense stuff. This begins the http configuration block:

OK, so far so good. Now, let’s specify some mongrel clusters. Depending on your app, you may want more or less clusters to balance the load. I’d ideally say at least 2 per processor, but sometimes you may want to run less of these for some weird reason. So, here’s what I have setup for a dual-processor machine.

We’re going to show how to setup this in mongrel later. This is what we have currently. Now, we have to specify the server.

Not much to see here. We’re using nginx as a proxy to the mongrel servers. We point to public just like how we would in any rails application that’s going to production, and we specify what we do in the case of a filename request. In the case that we request index, and index exists, we show the index.html page. Otherwise, we pass it all to mongrel. Then we use a closing brace to finish the scope.

Now, that was MUCH simpler than the beasts of Apache logs that you’d have to wade through to do the same thing. It’s interesting to note that nginx is a lightweight proxying server, and is actually designed to do this, as opposed to Apache which is more general purpose, and is meant to load web apps using shared libraries which is always much faster than doing something like using mongrel.

I’m not saying that nginx is the right tool for every job, in fact, I would use think seriously about using Apache for a Python/Django project, but that’s the topic of another post entirely. Stay tuned for my next post about Vlad the Deployer!

Posted in General, Linux, Rails, Ruby | 2 Comments »

September 11th, 2007

I managed to get my girlfriend’s Digital Camera to work, and now I finally have some photos in on my Flickr account (many years after I registered the account)

Check them out here

Posted in General, Linux, mesh, FtN | 1 Comment »

September 10th, 2007

I have a hobby of hacking the firmware on the Linksys WRT54G. I originally started doing it because I wanted to learn about how Embedded Linux worked, and I thought it was cool that it could run Linux. That’s how I got introduced to the Community Wireless movement.

Basically, the problem with the DIY Community Wireless hacking is that you’d have to either take off the shelf routers, flash them (and void your warantee) and then hope that you got something working. Then you can write applications for it like WifiDog, or various Mesh Networking Applications such as Optimised Link State Routing. This was great, but it ran into two big problems:

1. It’s hard to convince someone to run a hacked Linksys router in their home, because it looks sketchy
2. You’re at the whim of the manufacturer, who may not like that you can extend your hardware, or may change the hardware randomly or End of Life(EOL) it because they can make something that is cheaper.

In fact, the original Linksys WRT54G was changed after Version 4.0 to run vxworks because it took less processing power, voltage and memory to do what they wanted than they needed from their prior cookie-cutter design. Also, Netgear also discontinued the WGT634U because of similar logic. The reason I mention the WGT634U router is because that is what MIT Roofnet originally used to build the prototypes for what is now Meraki Mesh.

After BarCamp and talking to Boris at Bryght, I decided to buy some Meraki hardware. Now, I was expecting some unmarked boxes, and the devices to be large, but I was very suprised to find a branded box, like what you would find in FutureShop, and a very small device. Not only that, but it is extremely user friendly. I was also impressed with the range of the device. I put one in my Window at my apartment, and it seems to have a 100m (about 300 ft) range. Now, this is important, since the way mesh works is that you put a bunch of mesh nodes out into the world, and they route between each other to the nearest gateway node, the node with the least latency.

When I compare the Meraki out-of-the-box solution to the alternative, which is the Freifunk OLSR, there’s really no comparison for how easy it is to use. I think that Meraki has a very interesting project and it’s worth testing out. The main advantage of us testing out mesh is obvious, since we can facilitate a test bed for Ajax components in mobile devices right outside our window. With the release of the iPhone and the iPod touch (more importantly the iPod Touch, since we’re in Canada), content that is dynamic, and takes advantage of both geography, as well as the various user agents, is critical to providing a user experience like nothing else.

With more and more mobile devices equipped with Wifi for mass adoption, it just makes sense to at least play with the stuff. I’ll have pictures up here soon of us playing with the hardware!

Posted in General, Linux, UI, mesh, FtN | 1 Comment »

April 25th, 2007

Juan Carlos Pontaza at Fidelity has created something that a lot of people have been asking about on the forums recently, and that is the Dynamic Listbox. There are a lot of people who wish to have something similar to the Master/Detail Combo example for two listboxes on the same row. This was finally achieved by the Dynamic Listbox, which was included in a modified version of Grid 3.41.

Basically, a standard listbox consists of keys and values. Below is the sample for a Listbox defined with an XML island:

<!- then, outside the <ntb:columns> tag… ->

<ntb:datasources>
<ntb:datasource id=”lookupCategoryDataSource”>
<ntb:datasourcestructure
id=”lookupCategoryDataSource”
Keys=”ProductCategoryID”
FieldNames=”ProductCategoryID|ProductCategoryName”>
</ntb:datasourcestructure>
<ntb:data id=”lookupCategoryDataSource”>
<ntb:e a=”1″ b=”Cleaners” xi=”0″></ntb:e>
<ntb:e a=”2″ b=”Solvents” xi=”1″></ntb:e>
<ntb:e a=”3″ b=”Adhesives” xi=”2″></ntb:e>
<ntb:e a=”4″ b=”Fuels” xi=”3″></ntb:e>
<ntb:e a=”5″ b=”Waxes” xi=”4″></ntb:e>
<ntb:e a=”6″ b=”Dyes” xi=”5″></ntb:e>
<ntb:e a=”7″ b=”Paints” xi=”6″></ntb:e>
<ntb:e a=”8″ b=”Sealants” xi=”7″></ntb:e>
</ntb:data>
</ntb:datasource>
</ntb:datasources>

In this example, The column is being bound to a ProductCategoryID field and you are getting the ProductCategoryName from the datasource value that matches the ProductCategoryID to be able to render the correct text.

In his case with the dynamic loader, we do not need to display the value, because the datasource will be different per row, so at renderer time we need the description value to write it on the cell. To solve this, the developer has to provide that other column too. For example: