Notes, How Tos, Things To Remember, Things I'll soon forget

As part of my ongoing exploration with dotcloud , I've had to do a bit of learning about nginx . I've never worked with nginx before but i needed to add some rewrite rules into my dotcloud deployment. I wanted to make sure that static content like images and css files where being served by the nginx instead of my app ( Dancer is pretty nice about making sure public content gets served during requests ). I found that after changing a nginx include that the server needs to be restarted or reloaded after a change to the include. I spent a few hours trying to figure out if a restart was required since I wasn't sure if I had screwed up the rules due to a bug (now fixed) with dotcloud deployment not restarting it after a push as expected for Perl deployments. dotcloud provides server restart as: udo /etc/init.d/nginx restart __END__

I'm in the process of rewriting my site www.leecarmichael.com . I really wanted a reason to build a small but real app with (Perl) Dancer . I really like most of Dancer 's approach to routing and layout. It fits well with my way of thinking of web apps. At the same time I stumbled onto Dot Cloud , a very well thought out and incredible nice deployment provider. They are part of the current cloud shift in which individual application stack layers are hosted instead of a full OS stack. Here are the few gotchas that I found: They deploy using PSGI and Plack, very cool. But its deployed with an environment of 'deployment'. This means you must have a deployment configuration file. Example: application_root /environments/deployment.yml . I found this confusing since i expected it to follow the Dancer approach of production (my own bad assumption) Unfortunately, runtime errors are not logged to the standard web server error log (or anywhere else). Therefore you need t...

As I was working on a small application that allowed editing of pages, I really wanted to grab the referring page to redirect after the page was updated or the edit session was cancelled by the user. It wasn't very clear to me how to grab the referer from Dancer 's POD documentation on Dancer::Request . Basically I could grab it either of 2 ways. request->referer - nice. This applies to other env options as well forwarded_for_address which pulls in X_FORWARDED_FOR request->env->{HTTP_REFERER} - feels more lower level. I read the documentation as request->env->{referer} which is not correct at all. In the end it is much easier and I think prettier than the several options I tried :) __END__

Quick note to self (and anyone that might be listening): When setting config options different than start and end tag for TT such as PRE_PROCESS in Dancer , you must make them all caps. e.g. config.yaml: # template engine template: "template_toolkit" engines: template_toolkit: encoding: 'utf8' start_tag: '[%' end_tag: '%]' PRE_PROCESS: 'config.tt'

I often work on new projects outside subversion tree then move them in at some reasonable point. This usually avoids conflicts inside the group, sometimes it involves an evolving idea or a new template may need converting before updating reducing some noise. It is important to remember with svn import is that you need to specify the end location of the directory in the tree. Well I often forget this and its a pain since I haven't found a good way to undo it without just removing or moving all the crap by hand :( a few examples: svn import new-theme http://myrepos.svn.beanstalkapp.com/trunk/projectx/webapp Then recheck it out: svn checkout http://myrepos.svn.beanstalkapp.com/trunk/projectx/webapp ~/proj/projectx/webapp Or you can import new stuff into an existing location: svn import a-few-new-files http://myrepos.svn.beanstalkapp.com/trunk/projectx/webapp

This should be easy but "Beginning CakePHP" didn't include an index reference for application logs. But the online manual did (w00t!). (  CakePHP Manual Log Reference  ) For my future reference log location: webroot /app/tmp/logs Log File names: error.log debug.log

For some reason my hosting provider doesn't like Perl's Net::SMTP SMTP authentication of PLAIN. Everytime, it gives an error. Unfortunately, there is not way to tell Net::SMTP::auth method to only use a predefined mechanism from Authen::SASL. It will tries the first one every time.... This happens to be the ever failing PLAIN not the working LOGIN flavor. I tried to pass in a Authen::SASL to the auth method but it will just be smart and override the mechanism list :( Well, here is my evil to turn the mechanism method into a read only method, put in the top of my script: package Authen::SASL; no warnings 'redefine'; # suppress sub refine warning sub mechanism { return 'LOGIN'; } package main; Awful hack but right now I can't find a better way around this problem without completely overriding the the auth method, which seems much worse. now to figure out how to open a good bug for Net::SMTP.