Now an important aspect of how mod_wsgi daemon process groups work, is that the step of setting up a daemon process groups is separate to the step of saying what WSGI application should actually run in that daemon process group. What this means is that it is possible to tell mod_wsgi to create a daemon process group, but then never actually run a WSGI application in it.
Combining that with the ability of mod_wsgi to load and run a specific Python script in the context of the processes making up a daemon process group when those processes are started, it is actually possible to use a daemon process group to run other Python based services instead and have Apache manage that service. This could for example be used to implement a mini background task execution service in Python allowing you to offload work from the WSGI application processes, with it all managed as part of the Apache instance.
As far as mod_wsgi is concerned it doesn’t really care what the process does though, it will simply create the process and trigger the loading of the initial Python script. It doesn’t even really care if that Python script performs an ‘exec()’ to run a completely different program, thus replacing the Python process with something else. It is this latter trick of being able to run a separate program that we can use to have Apache manage the life of the Docker instance created from our container image.
Quelle: Graham Dumpleton: Using Apache to start and manage Docker containers.
This handcrafted guide exists to provide both novice and expert Python developers a best practice handbook to the installation, configuration, and usage of Python on a daily basis.This guide is opinionated in a way that is almost, but not quite, entirely unlike Python’s official documentation. You won’t find a list of every Python web framework available here. Rather, you’ll find a nice concise list of highly recommended options.
Quelle: The Hitchhiker’s Guide to Python! — The Hitchhiker’s Guide to Python
A lot of information on AWS is already written. Most people learn AWS by reading a blog or a “getting started guide” and referring to the standard AWS references. Nonetheless, trustworthy and practical information and recommendations aren’t easy to come by. AWS’s own documentation is a great but sprawling resource few have time to read fully, and it doesn’t include anything but official facts, so omits experiences of engineers. The information in blogs or Stack Overflow is also not consistently up to date.
This guide is by and for engineers who use AWS. It aims to be a useful, living reference that consolidates links, tips, gotchas, and best practices. It arose from discussion and editing over beers by several engineers who have used AWS extensively.
Source: The Open Guide to Amazon Web Services
Hey, have you heard of the new AWS services: ContainerCache, ElastiCast and QR72? Of course not, I just made those up.But with 50 plus opaquely named services, we decided that enough was enough and that some plain english descriptions were needed.
Source: AWS in Plain English
We recently introduced Instant Messaging on LinkedIn, complete with typing indicators and read receipts. To make this happen, we needed a way to push data from the server to mobile and web clients over persistent connections instead of the traditional request-response paradigm that most modern applications are built on. In this post, we’ll describe the mechanisms we use to instantly send messages, typing indicators, and read receipts to clients as soon as they arrive. We’ll describe how we used the Play Framework and the Akka Actor Model to manage Server-sent events-based persistent connections. We’ll also provide insights into how we did load testing on our server to manage hundreds of thousands of concurrent persistent connections in production. Finally, we’ll share optimization techniques that we picked up along the way.
Source: Instant Messaging at LinkedIn: Scaling to Hundreds of Thousands of Persistent Connections on One Machine | LinkedIn Engineering
Sometimes it is necessary to have a detailed view on the HTTP requests sent by your Android app and also inspect the responses from the server. With a few steps, it is quite easily possible to do this:
Inspect HTTP requests from Android devices weiterlesen
With Robolectric you can not only mock HTTP responses for your code, but you can also test which HTTP requests your code sends. To do this, you can easily use either one of the static methods provided in the Robolectric class or you can use methods of the FakeHTTPLayer.
Testing HTTP requests on Android using Robolectric weiterlesen
One of the nice features of Robolectric, is its ability to intercept HTTP requests and provide a way to return the HTTP responses you want. It is very useful, if you want to test code that reacts on certain HTTP requests. To accomplish this, Robolectric provides a fake HTTP layer, which you can configure with different complexity levels depending on your needs.
Mocking HTTP responses in Android using Robolectric weiterlesen
The last weeks I had the chance to dive deeper into unit testing of an Android application. The solution we are using is Robolectric. It is an interesting and promising framework since it does not need an emulator but just runs as standard junit test. The tests we have been able to write and run with it are great. You can even create an instance of an activity, inflate the UI from layout files and check the state of single views. Or you can send a broadcast intent and check if it has been received.
Of course, Robolectric does not create a real UI for the tests. The way Robolectric allows testing of Android applications, works by intercepting the creation of instances of Android classes and provides some kind of proxy objects for them (so called Shadows). This way, the Robolectric developers have been able to rewrite parts of the platform’s behaviour, emulate the logic of a lot of classes and internally keep track of the state of the objects.
While this allows for efficient unit and integration testing without starting an emulator, it is clear that Robolectric tests do not replace testing on real Android devices or emulators with different OS versions. There are a few reasons for this:
- The code just emulates the logic the Robolectric developers have implemented. For the most common use cases, this works well, but you find missing/limited functionality quite quickly. This will improve over time. Nevertheless, one has to be aware of the fact, that not the real Android classes are used and the behaviour can be different from the Robolectric classes.
- The Robolectric framework does not emulate the real lifetime of an whole application. E.g. it will not start an activity or a service on its own. Also, it does not emulate the lifecycle of activities. This is by purpose, since it anyway is meant only for testing single units of the app. Of course, you can check which intent is being sent from an activity, which allows for testing the correct behaviour.
- There are also general limits to this concept. E.g. when your app is not based on the standard View classes, but uses OpenGL, this can not be tested with Robolectric. I would say, all cases where real hardware is involved, can not be tested.
In summary, Robolectric allows efficient testing of a lot of use cases of an Android application. It is certainly not enough to make sure it will run on all devices. But it already provides a way to cover a lot of use cases of standard Android applications and make sure that the single components of your app behave correctly.
One thing that is heavily missing is better documentation, though. Without having the source code of Robolectric available and checking how it is implemented or looking at the unit tests of Robolectric itself, I would have not been able to figure out how some things are expected to work.
Therefore, I will try to collect here some howtos and hints for Robolectric in the coming weeks.
My other articles about Robolectric might also be interesting for you.
After arriving back in Germany from the O’Reilly Android Open Conference in San Francisco, I want to summarize my conclusions and general impressions.
Being in San Francisco and attending the conference was very inspiring. The keynotes have given a great overview what is possibly coming in the future and having Tim O’Reilly speaking about leveraging the openness of the Android platform was very motivating. As well as seeing what people are doing with standard hardware, like the NASA with Nexus S based mini satellites is crazy.
What was also great, was to „feel“ what makes the bay area so special in terms of innovations: ways are short, it is easy to connect with people from great companies ( be it startups or established ones), you get first class information from first hand, and people are very open to try out new things.
My summary of the Android Open Conference 2011 weiterlesen