Python, Web Applications

Deploying Python apps to Epio

I recently got my beta access to ep.io, the Python application deployment platform. I had the chance today to have a play around and try out some deployments so I thought I would try and give my view on the experience before. I’ve deployed Python apps to Heroku and Gondor before so those services form my reference points here.

So firstly, there’s a command-line client that you install via pip and you effectively deploy to the platform via a client-command, SSH keys and what looks like git on the server-side. This is more like Gondor than Heroku (which is intimately linked to git). It means you have your choice of source control and if you want to be a Python purist you never need to step outside of Python for everything you are doing.

Applications consist of essentially one configuration file that states where the WSGI application is and what the requirements file is. Compared to Gondor it is a very simple setup but it did feel that it could be even simpler if it made convention-based assumptions such as the requirements file being called requirements.txt, for example.

Leveraging WSGI and configuration this way gives a very flexible platform and I was able to get both Flask and Bottle to work (the former very quickly because it has documentation, the latter via trial and error that might require its own blog-post). I didn’t have time to try Django but I felt pretty confident that I could get whatever framework I wanted working once I understood the basic setup.

Unlike Heroku, Epio provides a fixed framework for executing the apps. It seems you will be running behind NGINX and Gunicorn. Both are good choices and I certainly like them but if you want to play around with different servers like Tornado or CherryPy you may prefer Heroku’s more open deployment model. I did like the way that you can use the configuration file to have NGINX serve static content directly.

Epio naturally has less of an ecosystem than Heroku but has Solr, Postgres and Redis out of the box. All solid choices and covering off the majority of what I would need. I was certainly grateful that I didn’t have to grapple with remote database administration and could prototype apps with just Redis.

Deployment and logging have kind of rough edges. Being able to access logs directly from the application page was a win for me, however when I was struggling to define the WSGI entrypoint correctly it seemed as if the application wasn’t being really compiled until the first request comes in. I would see an entry confirming a new deployment but then nothing until I hit the app. I think there should be some kind of sanity check of what you have uploaded to see whether it will even run.

Right now epio is providing a Python-based cloud deployment platform with a sensible set of supplementary services and low opinion about the source control system to you use. It feels like if this had been around at the start of the year it would have blown me away. However now there is more competition and therefore questions of price and ease of use will matter in terms of  how compelling it is to use the service.

If you do Python web development I would definitely recommend you sign up for beta and give it a go yourself as it seems a very solid prototyping platform. If you are not a Ruby and Git fan then you may well love what is on offer here because it is already very convenient, makes few demands on you and gets your web app public in minutes.

Standard
Python, Web Applications, Work

Declare for simplicity

I was struggling with an issue today on a template that was blowing up due to missing keys in a template data hash. At first I tried to write some conditional code in the template. That ended up being quite ugly so then I was trying to find a way to condition the template on whether the key was present.

Then it struck me that the issue was really the missing key. As the hash is prepared in Python code the original implementation frugally avoided creating the entry if the underlying data wasn’t present. While this is clever and minimal it actually just pushes the complexity out of the Presenter logic and into the template where it is much worse because you can only interact with the Presentation’s abstraction of the original data.

The problem here is that dynamic languages sometimes allow you to be too clever. In a declared structure system you have to declare all your data and provide sensible defaults. This makes writing the templating solution at lot easier as you never have a missing data problem to deal with (you still have headaches with duff defaults but that is a different post).

So I went back to the presenter and declared an empty list under the key that had been causing me grief. Bingo! My failure went away and the default behaviour of not generating any content for the empty list kicked off, reducing my template back to the unconditional single-line I had originally.

Standard
Java, Programming, Web Applications

Notes on NetBeans 6.1

I am working on an exciting web prototype project at the moment and I am using NetBeans 6.1 rather than my usual Eclipse environment. Overall I am very happy with the experience. The good points are:

  • NetBeans seamlessly integrated with my existing Tomcat instance, configured it correctly and makes it easy to build and deploy my application making my build-compile-deploy cycle as quick as it has ever been
  • The Javascript support is excellent and allowed to discover the JQuery API with no problems
  • It has been easy to define libraries and have them brought in to the project
  • The built-in XSLT validation and one-click transform of a test file is really powerful and very simple to use
  • Associating a web project with different deployment servers is easy
  • The GUIs for writing Java Web App configuration files is great
  • Managing NetBean Modules is easy and the interface is good
  • NetBeans 6.1 is fast, really noticably faster than 6.0.1

That is a whole lot of positive, so what hasn’t been so good?

  • Code templates complete on a different keystroke to code completion. The seperation doesn’t make sense to me. Both things are about completing what I have typed.
  • The window of opportunity for completing a code template is too narrow. If you don’t complete while typing the template stub then it doesn’t work.
  • When entering the parameters of a generated method you have to hit return too much. If the auto-generated code has aready correctly assigned variables to the parameter position then I’m done. At the moment though you have to hit return for each parameter otherwise the code generator gets in a tizzy and often opens brackets on the line below the current method.
  • Really gnarly HTML can take a long time to parse for the navigator windows and the slowdown is noticeable across the whole IDE. XML blazes by comparision.
  • There’s a lot of magic going on to make the project work automagically and there isn’t a good “raw” representation of the project that would make it easy to work from CI and the command-line.

Essentially most of these problems are to do with the interface being too fussy and in some cases too specialised. However I do thing I am getting the benefit of the integrated development environment and while it may not be as fast as Rails it is some of the fastest Java web development I have ever done.

Standard