Thursday, July 23, 2009

lighttpd unixsocket is too long in error

I recently found this error occurring in my lighttpd error log.

2009-07-23 08:23:54: (mod_fastcgi.c.1290) unixsocket is too long in: fastcgi.server = ( .fcgi => ( ( ...

Google did not prove useful, but its was pretty easy to figure out. The string being assigned to socket in the FCGI config is too large. The string needs to be shortened.

Thursday, June 4, 2009

switching from programming to responding to emails

I have the hardest time swithcing from programming to responding to 'quick' emails. My mind moves faster than my hands. I wish there was a syntax check for English, where are they on that? I saw Spelly on Google Wave, that's what I need.

Monday, February 9, 2009

experience with learning Google App Engine and Python

In my endless aim to learn about the web technologies of the web, I finally came across to using Google App Engine. My motivation to start using it was its promise of development environment where I didn't have to worry about the details of deploying my application.

App Engine provides a integrated environment that allows you to build an application on your local dev box as it would work exactly on the live site. Some would find this constricting, but I just looked at as new platform where I didn't have to worry about the database setup, massive configurations files, and finding hosting for final project.

I've been working on a side project for awhile, which has gone through many iterations of development (in short I was over thinking it). One of the iterations started with me developing on Google App Engine where I got to chance to build using Python. Google uses Python internally for many things (apparently), but they also choose it because it allowed to easily create a sandbox environment.

Learning Python from a Perl and Ruby background has shown me the true meaning of there is more than one way to do it. In dynamic languages, you usually have control of how the program flows, Python follows this same convention, but doesn't provide so many avenues to do so. For example, in Ruby there are about 5 different types of eval, as far as I can find Python has one. These conventions (not restrictions) of Python make you think of your program in a different order of logical steps. Its been kind of PITA because somethings that come intuitive in Ruby just didn't come to me while working in Python.

The sandbox environment of Google App Engine is built the same on the desktop and the deployment environments. It follows the brand of WYSIWYG from a programming stance. The limitations to the sandbox is pretty much that the Python cannot run C-based libraries and access the OS for more advance I/O features.

Because only pure Python applications can run in the sandbox I had to choose a web framework that would work within it. Google App Engine comes with its own lite web framework, but it was just bits and pieces of Django patched together. Web frameworks are plentiful in the Python realm, and webpy seems to be the simplest and easiest to pick up, which instantly attracted me to it.

After working 2-3 weeks learning Python and building my application, I came to the conclusion that ran into too many limitations of my knowledge of Python. I would always wanted to do something that would always bring back to "I can do that in Rails easily".

Mid-entry UPDATE: It appears that Google is planning on supporting Java on Google App Engine. There are even early reports coming in of early Rails development using JRuby on Rails. This is some exciting stuff, which means I will certainly be revisiting App Engine in the near future.

Sunday, November 16, 2008

Sinatra speaks a different language, Perl

So, if it has become obvious to some, I have a thing for web frameworks. I like to understand how and why they work, and for me that usually involves more than just reading the source code. My first attempt was different variations of Puddy -- Rails/Merb like framework in Perl. The second iteration has led me down the path of the Ruby Sinatra framework.

Sinatra is a minimalist framework for creating web applications. Its scope really only extends into realm of controllers. It does support views, but it is still far from the enormous support that Rails would provide in options. The controller aspect allows you to define the route in method call of the action -- often causing your entire application to be just one file. I have used it to experiment with building APIs for some of my projects.

In short, its a light, quick, and not at all a memory hog, so of course I wanted to dissect it. This lead me to just reading the source code, but I wanted to do more to understand how it worked. I should inform you that I do indeed know Ruby. I've used it on a daily basis for the past 2 years for my job(s) and have used well beyond just the Rails environment. Now, I have also been a big supporter of Perl, mainly because it was my first language beyond good old Q-BASIC.

With that in mind, I would like introduce a project that I have been working on Sinatra for Perl. Yes, it is a work in progress, but I have put a lot of effort into making sure that this code base was some what solid before I released it to the world. In the repository, a working example can be found and run on your local machine of the feature set.

I like the ease of of extending Sinatra in either Ruby and now Perl. I have added simple extensions to support page caching, running tasks from command line, and a simple background job server. Many of these are lacking optimizations, but I just wanted to show the ease of extending the framework.

The simplest example of a Sinatra app:

#!/usr/bin/env perl
require 'lib/';

use strict;

get('', {}, sub{
return 'Hello World';

get(':name', {}, sub{
my $r = shift;
return 'Hello, ' . $r->params->{name};
A simple DSL that defines what action to perform on a route. LOVE IT!

This has been an educational experience (albeit a nerdy one) and I hope to continue on this project. I think I will probably have to go through a name change in the near feature as not to confuse people on the Ruby version.

Monday, November 10, 2008

rails plugin to white label CDNs

This is a continuation of my previous post talking about using S3 as a CDN. This post covers some of the issues that were faced with making Rails work nice with a CDN.

Rails is made to do great things, but as many before have me said, handling concurrent connections is not one of them. Once a request comes into Rails, that process (Mongrel, FastCGI, etc.) is blocked till the request is done. Actions like sending emails, transferring files, large calculations need to be pushed away from the user request into another process. There are many solutions such as BackgrounDRb, Starling, etc, which allow you to load long running tasks from blocking Rails.

The task of handling files on a remote server is always a tricky one. Each CDN has there own interface on how to interact with the files -- delete, update, move, etc. This proved to be a problem when trying to test which one would work cleanly with our setup -- widgets stored in the database, which are updated immediately to all users on the Chumby network.

I took a top down approach to the problem. Designing how I wanted the widgets to move from our servers to a another server by building the API of methods. These methods were just a skeleton and did nothing. It just allowed to me to write the code I expected instead of working around another CDN or modules API. The methods could then be filled with the appropriate code to make it work with the CDN.

Originally, the CDN of choice was S3 -- not a true CDN, but suited our purposed of unloading our servers of loading dynamic content from our servers. The necessary API calls were filled to support the functionality of S3. Its then I realized that with the top down approach that the work I had could be easily modified to work with any CDN method. I've written extensions for rsync, ssh, and just S3, but it has supported our needs to be able to test multiple environments and services quickly.

This plugin data_fu is currently a work in progress, but I hope to modify for wide spread use and finalize it.

NOTE: At the time of writing this software that there are many solutions of CDNs that handle transparent proxy and caching of content. The reason these solutions were not used because the content of widgets need to be updated instantly. Since the solution was to use vanilla CDN mechanism so we could change CDN solutions if one went down and switch over was needed immediately.

Monday, September 15, 2008

project euler repo

I have recently gotten back into the Project Euler problems. The website provides a bunch of math and logic problems that can be solved any way -- paper and pen or programming. I like the challenge every once and awhile, so I thought I might share some of my results of the code I have written to help solve the problems. There are comments in most of these. They are just quick dirty hacks to help me get the answer. Sometimes the output will not be the answer and you might need to go look for it, but the logic is there.

Saturday, September 13, 2008

new job and location

I have neglected my duties as the maintainer of this blog for a few months. Its has been for the better though. About a month ago, I left my position at Chumby and moved to San Francisco to start working at [context]. I had a great time and experience working at Chumby, but I felt that San Francisco is where I needed to be for both work, but also experience. I grew up in one of the largest (and best) cities in the world, and I missed the lifestyle that came with it. San Diego has great weather, but I hated driving everywhere.

Now I am in San Francisco. Trying to sell my car. And enjoying my new job, people, and experience.

If you are in the area, please contact me, nice to meet some readers. :)