Posts Tagged AppEngine
change of service agreements
Posted by Morten in Uncategorized on July 4, 2011
I read two articles yesterday (which is a while back when this post hits the blog). The first was the closing of iFlow reader, which is sad and out-right wrong as seen from a market perspective. There should be some marketing laws that prevent the elimination of competition in this way. Obviously Apple is scared of the competition. This post isn’t about Apple how ever. I also read the year a head for Google AppEngine, where Google announced that they were changing their subscription plan for AppEngine.
This is of course perfectly fine for Google to do, in fact it’s not that big of a deal. Their pricing still makes sense. But as a developer who was some services on AppEngine I have to consider. What happens if Google suddenly changes their pricing model to a model which doesn’t work with the plans for my services?
Suddenly I have to move my services else where, but with AppEngine I’ve developed most of the backend solution for Google AppEngine. Sure you can host Django on AppEngine and then move to a Django based hosted solution in the cloud, but there’s still the API:s that are used.
I guess what we can learn from iFlow is to keep check of what your dependencies are on service agreements for your services, and have backup plans in case things get out of hand.
Talk on Python Testing on Google AppEngine
Posted by Morten in Uncategorized on December 10, 2010
Last night I held a talk at GTUG Stockholm about testing on Google AppEngine. Here are the slides that I used during the presentation.
YubNub command to go to Python documentation for Google AppEngine
Posted by Morten in Uncategorized on December 6, 2010
New AppEngine SDK 1.4.0
Posted by Morten in Uncategorized on December 3, 2010
Apparently there is a new SDK out tonight! It’s version 1.4.0.
I had to mention it because apart from the really interesting Channel API there is a new “Always on feature” which, even though it costs money is a possible solution to the loading issues with using Grails on Google AppEngine.
There is also a possibility of activating Warm-up requests to try to predict in advance when there is a need for more instances. Which should help out even more with running Grails on AppEngine once you reach the limit of the preloaded three instances of the “Always on”-feature.
Also there are some severe changes to the limits for running background tasks and Cron jobs, which should allows more computation intense applications on AppEngine.
Seems really interesting!
Rolling back failed AppEngine deploys in Hudson
Posted by Morten in Uncategorized on October 30, 2010
In a previous post I mentioned how to set up a build that deployed to AppEngine using Hudson. I’ve been using such a build for a while for JS-Analytics but its frustrating when the deploy operation fails midway.
When this happens you need to issue a Rollback command at the same place you started to deploy form, else AppEngine will say that there is an update in progress. Meaning all builds will fail until it is corrected.
Until recently I’ve been logging into my build server to correct this problem every time it happens. However now I’ve set up another Hudson build to handle the rollback, a clean-up build if you wish.
I set the build to execute in the same workspace as the build that deploys to AppEngine and all the build does currently is to issue the rollback command.
I blurred out the part that contains the password, but as you can see it’s still pretty straight forward.
Now every time my deploy build starts acting up, I simply run my rollback build which takes a few seconds. Then I’m good to go again.
Setting up CI on Hudson for Python based AppEngine apps
Posted by Morten in Uncategorized on September 13, 2010
This post describes how I for JS-Analytics use a Hudson build server for Continues Integration, publishing to Google AppEngine on successful builds.
The build currently does just two things:
- It runs all my unit-tests and calculate code coverage on them. This step is to ensure that the application isn’t broken before the second step is executed.
- It publishes the latest changes to Google AppEngine
Running the unit tests
This is a straight forward execution of my unit tests. With some assisting tools. I use XML-runner to generate xml reports that Hudson can read to produce some nice output, and I use Coverage to calculate the metrics.
To get coverage to run I had to install it manually for python2.5. To run the coverage tool I run the following build step.
#!/bin/bash -ex cd jsAnalytics coverage run manage.py test coverage xml --omit=/usr/
It calculates the code covered during the test-run and omits the result as XML.
I then have the following setting set in the build to publish the results:
and
Publishing to AppEngine
#!/bin/bash -ex rm ~/.appcfg_cookies cd jsAnalytics echo <password> | python2.5 .google_appengine/appcfg.py -e <user email> --passin update .
The above snippet first removes the appcfg_cookies from the user directory. This is to allow builds the publish to different AppEngine projects to run on the same Hudson installation, and can be omitted if you wish.
The snippet then executes the appcfg.py update command with a user and passes a password. The user for me is a special Google Apps account created for publishing to AppEngine.
What the build gives me
Basically I’m just looking at two trends, I want the amount of tests to increase and I monitor the coverage to ensure I’ve not added something without tests. The only problem right now is that the code coverage report is somewhat tainted with the app_engine helper files. Something I’m not too fond of.
That and the added value that my check-ins are continually evaluated, and the next version is always available on AppEngine.
Testing on Google AppEngine (Python SDK)
Posted by Morten in Uncategorized on June 28, 2010
Testing in Python and Django is pretty straight forward. However I wanted to write tests that assert email sending, URL fetching and other external sources. Making sure the intended code is executed and allowing me to write fuller tests.
These external actions are accessed through Google’s API, and there are some posts about how to test on Google AppEngine.
Here is an example by AppEngine Fan where he uses Mocker to mock out the external API calls. An approach that shows the power of the mocking library, but to my taste it results in too much code, and too much details about the mocking framework in the test making it harder to read. This ties back to a previous post I wrote about testing without Mocks.
What I wanted was some way to keep my original code intact and still have a pretty self explanatory test.
After some more research I found out that all API calls in the Python SDK are done through a proxy map. Allowing you to replace the behavior of AppEngine with your own, stubbed behavior. This method is used in this example (that still uses the mocking framework), and also this post on the user group was that location where I first noticed it.
This made me dig through the source code available in the SDK about how exactly this stub map worked. What I noticed was that if you started using the stub map, you needed to setup all the stubs.
As far as I could tell there was not means to replace just a single stub and let the map remain otherwise intact. Which was a bit of a trouble for me. One of the reasons I researched it was because I didn’t want to have tons of setup code in my tests.
Since my test code is important I thought I’d show how I want my tests to look like.
Requirements for good test-code:
- Easy to read (Arrange-Act-Assert,Minimal setup code in the test)
- Fast execution
- non-fragile (black box testing the most external interface accessible for testing)
I want specific events in JS-Analytics to send an email to the administrators of JS-Analytics. The use case is covered with testing, but I wanted to add a test for this new requirement.
Here is what the test looks like:
def test_given_a_new_project_an_email_is_sent_informing_the_admins(self):
request = HttpRequest()
request.user = User(username="…", user=users.User("…"))
request.method = "POST"
request.POST = {"title":"test"}
index(request)
self.assertEqual("project created", self.getMessages()[0].subject())
As you can see I wish to use the Log pattern for test sent messages. This allows me to check the sent messages in order. There is a method that allows me to access a copy of all sent emails, with their complete structure. Allowing me to assert different aspects of the emails.
To support this I created a base-class that adds the behavior I want as setup code. This setup code is generic and only specific for AppEngine aspects of the code. Here is the structure:
The base-class called ServiceTest sets up the stub map. I added two stubs that change the behavior from the normal stubs. These add support for setting content that will be accessed through the URLFetch service, and the logging of email messages.
Since no call ever cross the service boundary to actually do anything, the execution time isn’t compromised.
Here is an example of the setContent usage:
def test_fetching_arrangement_example(self):
self.setResponse("http://url-to-be-fetched", "fake-content")
request = HttpRequest()
result = view_that_does_fetching(request)
self.assertEqual(result.content, "fake-content")
As you can see its pretty straight forward to Arrange the which content should be returned where.
This structure should be so generic that anyone could use it, so I added a copy of my base-class free to use by others.
Grails vs. Python on Google AppEngine
Posted by Morten in Uncategorized on April 7, 2010
A few weeks ago I got fed up with the bad performance I was getting on Google AppEngine for my Grails project. I was also having trouble figuring out how to combine references for Entities to build more complex structures.
As a result I finally lost it and started experimenting with Python on Google AppEngine. So here are some of my conclusions.
Framework
I still wanted to have a framework to build on for developing my application. Since Grails has a lot of dependencies that are sent to GAE I wanted something that was already supported by GAE. Partially because I heard that sending all these dependencies around in Google’s datacenter was one of the reasons for the bad performance I was experiencing.
So I chose Django. The Django framework is already installed on the web servers hosting the applications on Google AppEngine, which would reduce the load cost for dependencies.
There is also a Django helper that will help you use GAE features through the normal Django API.
Static files
Something I was missing from the Grails solution was the use of static files, most of the client side java script I server were static, so I just wanted a high expiration date and static serving of the files. This is inherent in Python GAE app.yaml file.
To be honest I am quite impressed by what I can do with the app.yaml file. I can set expiration dates on content, declare parts of the urls I define as secure. I can even reserve some parts of my site for me personally. Allowing me to build Administration interfaces for the application.
I will however miss the UI-performance plugin, as it handles my java script files the way I want, potentially even better. Now I have to manually set up something that during deployment compress and bundle my java script files.
Working with the API
Working with the python API for GAE gave me a better sense of control over what I was doing. The concepts of the Datastore and other features made much more sense. All of a sudden making applications with more complex data structure wasn’t an issue. How things connect to each other was inherent and the documentation was there to assist me when I missed something.
I also had to write less code to achieve the same features, however part of this could be because I had already solved the problem once and could produce a better solution with this.
What I really liked was testing, where I earlier had had problems with getting tests to run for Grails with the AppEngine plugin. The tests not only worked out of the box, but they took roughly 0.1 second to run 10 tests.
Performance
So finally, the performance part. Remember this was one of the reasons I made the switch.
Before I get to the actual numbers, I have to mention that there are some changes that affect the results. When hosting on Python I could serve most of my pages as static HTML files, where using Grails I was depending on the virtual machine to boot up before content was delivered. Performance for the static files could probably be achieved if the Java app is configured to serve the files as static files through GAE.
And now the numbers
| Avg. Response time | |
| Grails | 4985 ms |
| Python | 252 ms |
| Uptime | |
| Grails | 53.48% |
| Python | 100% |
These numbers are captured using Pingdom, with checks running every 5 minutes on the website from all over the world.
Conclusion
Since I don’t require any plugins for Grails for this project and Python serving so well I’ll go with Python for this project.
This being said as I know Grails will get performance improvements for Google AppEngine in coming versions.
Interesting issue on GAE issue list
Posted by Morten in Uncategorized on March 30, 2010
I was browsing around the issue lists on Google AppEngine, just some midnight light reading before going to bed…
I stumbled on the following issue, marked as critical:
http://code.google.com/p/googleappengine/issues/detail?id=1970
What’s interesting about it is that this is also what is causing all the problems with running Grails development on Windows machines. If this is fixed, then building Grails for GAE on Windows machines might work without any workarounds. Lets hope the Critical focus remains on this issue, and that it is resolved.
Hudson build server + Grails + AppEngine
Posted by Morten in Uncategorized on February 22, 2010
I just set up a build server for my Grails project. I chose Hudson since it was the one mentioned to work well, and it did. I’m quite happy with Hudson thus far. It hasn’t crashed (actually it crashed my browser once, more on that later), and been very easy to work with.
First of I installed it on my Ubuntu machine in the closet. It was straight forward installed using apt-get as per instruction. This was a clean install and the first use of that Ubuntu installation for any kind of development work.
With Hudson installed I started going through its configuration. I knew there was a Grails plug-in so I figured I had to install a lot more software to get things going.
Imagine my surprise when I found out I didn’t even have to install the JDK. All I had to do was to choose which JDK I wanted, accept the terms for usage, and Hudson installed it for me.I found the plug-in page, marked the Grails plug-in and installed it.
I created a job, configured it to fetch the code from my subversion repository. Already I could run the job, and watch the output from my normal development machine.
I love the console out page, compared to watching the build-logs and build progress in MSBuild this page gives good feedback, doesn’t crash that much, and works as both progress and log all wrapped up in one.
With the job running I pinpointed the missing parts in the job. Running the grails targets. So it was time to configure the Grails Hudson plug-in. It required the Grails installation path, so time to set up the libraries. Download and install Grails, update the plug-in with the path.
When running a Grails job the first time you need to run the “grails compile –non-interactive” command. This will install all other plug-ins as it is the Grails way. This will make plug-in specific commands available.
I ran it first without the –non-interactive flag, which caused the app-engine plug-in installation to ask questions. Hudson didn’t mind, but my browser in which I was looking at the console out didn’t like it. It kept updating the page with “do you want to use JPA or JDO” questions, until it finally crashed.
In my case I wanted my build to upload the compiled application to Google AppEngine. I added the APPENGINE_HOME environment variable to Hudson’s main configuration. With the APPENGINE_HOME variable set to my newly downloaded SDK.
This is what my grails build target looks like:
To get the deploy command to work I needed to add the login details for app-engine. After some research I found that the details are configurable. All you have to do is add the following to you Config.groovy file in the grails project.
google.appengine.email = "email" google.appengine.password ="password"
But with the correct email and password of course. In my case I used the user I’ve created for sending emails as the user that will deploy using the build.
I now have a working build that deploys to AppEngine. What I’m currently missing are running tests, as I’m still searching for a functional testing framework that will run as a Grails plugin with the AppEngine plugin. None of the two (easyb, functional-testing) Grails plugins I’ve tried so far have worked.