Nginx, uWSGI, and web.py…and my new job
This past week I started a new job at Local Projects. I'm really excited about working with all the talented people there. One of the fun things about the job so far is that I'm doing a bunch of Python development with web.py. It's a great minimal web framework and working with Python has been great as well.
One of the things I wanted to do this weekend was to figure out how to run a web.py app with nginx and uWSGI. It took me ages to figure it out, but I finally got a working setup. This post is mostly to document the few things that made the difference.
First thing to note is that I did this all on a micro instance of Ubuntu 11.04 on EC2 (ami-1aad5273). Second, I installed the lastest versions of nginx and uWSGI from source. The following gist lists examples of the files I used to get this running. I should note that the config and .sh files are intended for running one server and one web.py application.
The wonderful eyeo festival
I think I'd be putting it lightly if I said that eyeo festival was inspiring. It was easily the best gathering of talented minds that I've been to over the years. I'd only be echoing the words of nearly every attendee if I was to go into any detail about what made the event so great, so I'll spare your time. The biggest thing in my mind is that eyeo must be an indicator of where our minds should be headed.
You can so easily forget about what artists, designers, and developers are doing outside the stereotypical agency world of microsites, Facebook apps, Twitter mashups, and the like. Much of this work isn't rooted in the web, and as a developer I am more inspired to look beyond the laptop and mobile screen. I know I have the skills and know-how, I just need to get my mind out the rut its been in and into the area that the speakers and attendees of eyeo have carved out.
Quick Update
Howdy, everyone. It's been ages since I've written on this thing so I wanted to give you an update on what I've been up to.
Over the past summer and fall I had been working on a large project for a client that I, unfortunately, can't mention. I may not ever be able to mention it. The project itself was pretty cool. It was a product configuration application. The front end was built with Flash using Robotlegs as the core architecture. On the backend there was two systems. The application model was tied in with Magento and all data was accessed using AMF. I didn't build or maintain that bit, but I had the pleasure of working with Adil Hashem on that piece.
The other backend system was a Java image compositor. The image compositor already existed but it needed a different implementation for the application to scale. With the image compositor being written in Java I took the opportunity to get into Java web development. I spent a good couple of weeks getting into Spring Framework and its Web MVC component. I also started exploring usage of MongoDB for basic statistical tracking but in the end went with Amazon's SimpleDB for ease of use and to minimize future IT needs. The whole image compositor is hosted and supported with various Amazon web services including EC2, S3, and CloudFront. I also set up a pretty snazzy automated deployment process with Ant.
The product configuration application was just one part of a bigger project. My app was pretty much in order but a combination of problems from all sorts of sources caused the project to stagger and eventually the project abruptly ended. I wont go into anything beyond that because it doesn't really matter. I was certainly bummed out when I found out the project would never see the light of day. However, the positive side is that I learned a whole bunch of new stuff. I'm really stoked on Spring and MongoDB lately. I can whip up backend prototypes so quickly with those two pieces of software and Morphia which is a document mapper for Java.
After work for me stopped on that project I started getting into Android game development a bit. It was fun for a while but I eventually decided that I had been at Rokkan for long enough. Nearly 5 and a half years after I came to New York City to work for them I finally felt the need to move on. I interviewed at a bunch of places and I ended up taking a job at Syrup. Syrup is essentially a full blown advertising agency but they're quite small considering how much they do. They do broadcast, print, and digital. They brought me on as their CTO to help boost their digital offering. I'm working with some really creative people and its been awesome so far.
That's all for now. I'm hoping to get back into blogging a bit. I'm still trying to prototype ideas and I hope to share some of the things I run into along the way. Perhaps I'll write a post on Spring and MongoDB next. Who knows...until then, happy coding.
Practicing Continuous Integration on Flash Projects : Using Hudson
In the previous part of my series "Practicing Continuous Integration on Flash Projects" I described how to setup a CI server using Amazon's EC2 service. In this final part of the series I'm going to quickly show you how to set up your project in Hudson so that it can build it.
Using Hudson
If you're practicing CI properly you should be integrating new code on a pretty regular basis. When new code is integrated the project should then run through its build process which should include running all the unit tests and building the project if all the unit tests pass. This is where Hudson comes in. Hudson can monitor your source repository and whenever new code is committed it will retrieve it and build the project. Now I'm going to show you how to set up the CIExample project in Hudson.
Practicing Continuous Integration on Flash Projects : Integration Server Setup
In the previous part of my series "Practicing Continuous Integration on Flash Projects" I explained how to use Apache Ant and the Flex SDK to automate the build process of a project. In this part of the series I'm going to show you how to set up Hudson, an integration server, on a bare bones Fedora 8 Linux box.
Introduction
Code integration happens whenever you commit code into the project's mainline. There are essentially two camps when it comes to building the project after new code has been committed. Some developers prefer to do it manually, meaning that the developer switches to the "integration machine", checks out the new code and runs the build process. If the build is successful then the developer's commit is also successful. If its not successful, then the developer should revert their commit, make adjustments to their code, and attempt to integrate again later.
The other camp enjoys using a CI server such as Hudson or CruiseControl. A CI server will monitor the project's mainline and attempt to build the project any time new code is committed. A developer can check out the CI server website to see the progress or the eventual status of the build. When the build is complete, successful or not, the CI server should notify the developer who committed the new code. Personally I think a CI server is an invaluable tool when it comes to practicing CI and thus I'd like to show you how to get Hudson up and running.