OpenGL is widely adopted as the graphics API of choice for real-time interactive 3D graphics applications. OpenGL is easy to understand, but its simplicity and orthogonality enable many interesting possibilities. One such possibility is image processing.

Using “OpenGL” for Image Processing enables us to completely utilize the power of Graphics Processing Unit (GPU) hence the image processing will be faster also it reduces the load on CPU. This can be crucial for Image processing applications, especially in mobile environment where the resources available are relatively lesser.

In this post we will be discussing how to use OpenGL Shader Language to manipulate pixels and create Image filter effects.

As with any OpenGL app, we will start with setting up the view.

The next step is to load an image into the texture, This texture can be mapped on to the surface of a square, which will then be drawn on to the screen.For Image processing, we will require only 2 dimensions so we will set up the view in orthographic projection and will also discard z axis by keeping it to 0.0 most of the times.

But before drawing to the screen, there are many intermediate operations that are done by the graphics hardware, which are now directly programmable in OpenGL ES 2.0 using Shader Language (GLSL).
We will be concentrating on Vertex and Fragment processing phases in OpenGL pipeline. We will go through a simple fragment shader program and will explain how it works. Both of these programs are written in GLSL. GLSL is a ‘C’ like language which gives direct control over the  graphics pipeline without having to use assembly language or hardware-specific languages.

Vertex shader

uniform mat4 uMVPMatrix;
attribute vec4 aPosition;
attribute vec2 aTextureCoord;
varying vec2 vTextureCoord;
void main() {
  gl_Position = uMVPMatrix * aPosition
  vTextureCoord = aTextureCoord
}

The Vertex shader is executed for each vertex that is to be drawn. Here, we are drawing a square and mapping the texture on to that.

This calculates the transformed coordinates of the square by multiplying the given coordinates with MVPMatrix [ MVP -  Model * View * Projection ]. Other than this we are also storing corresponding texture co-ordinates in variable ’vTextureCoords’ so that it is available in the fragment shader.

Fragment Shader

precision mediump float;
varying vec2 vTextureCoord;
uniform sampler2D sTexture;
void main() {
   vec2 cen = vec2(0.5,0.5) - vTextureCoord.xy;
   vec2 mcen = -0.07*log(length(cen))*normalize(cen);
   gl_FragColor = texture2D(sTexture, vTextureCoord.xy-mcen);
}

Fragment shaders are executed to calculate the color of individual pixels. This is where the actual image transformation happens. Instead of mapping the corresponding texture coordinates to corresponding pixels, we can map different coordinates of the texture to different pixels which will distort the image in some way. In the above example the texture co-ordinate to fill each pixel is chosen based on the calculation in line no 6. The actual movement depends on the distance of the texture coordinate from the center. This creates an effect which is similar to what is shown in the below picture.

Although this is a very simple effect, the intention here is to just show potential applications of OpenGL in Android apps.

We’ve set up our CI server for building android apps. We use Jenkins as our CI server, but the same steps can be applied to any CI server.

Setup Android Environment on CI server

You need to first install the android SDK and platform tools on the CI server. The steps are well defined here. You can run the command android update sdk --no-ui if the CI server is in an headless environment.

Generate Build script

Using android SDK tool , you can generate build script for the android project which contains the standard steps for building the app such as clean, compile, release, install etc. The following command will generate the build script, replace <appname>, <target> and <project path> accordingly.

android update project -n <appname> -t <target> -p <project directory>

This will create build.xml file under the project directory. You need to create build.properties file with the following contents:

key.store=path-to-keystore
key.alias=[alias]
key.store.password=[pw]
key.alias.password=[pw2]

You can generate the key file using keytoool or you can generate the key file from eclipse. Run the command  ant clean release, which will compile the files, and generate the apk files (it generates signed, unsigned and unaligned files). The signed version can be used for uploading to Android Market or for installing directly on any device. Couple of stuff to be noted here are:

• Ant version has to be 1.8.0 or higher.
• Put the external libraries in the libs directory. Build script automatically picks up the libraries put under libs directory, otherwise the script need to be changed to look at a different classpath.

Checkin the build.xml, build.properties and the key file into the repository.

Setup the CI server

The CI server has to run the ant script for building the app. One more setting what we’ve done in our Jenkins server was to archive the apks as artifacts (available in the post build action). In upcoming posts, I will cover how to do the following:

1. Running android tests
2. Running code/test coverage tools
3. Actual deployment

References: http://skaug.no/ingvald/2011/09/android-app-with-jenkins/

• Reindex the solr/lucene indexes if any new field has been added to the index
• Some custom rake tasks , say for eg: task to update values in the DB, which you don’t want to add to migrations

We do have Cap tasks for running the required rake tasks, but again it was done manually. So we’ve to remember to run them after deploying to production.  And also there is no way to track what steps were followed for a certain deployment.

I used the build parameter again for fixing the above issue i.e. after accepting the extra tasks as parameter for the build for the first job, they will be passed on to the downstream jobs. In this way the same deployment steps will be automatically followed for rest of the jobs in the pipeline.

The only difference in this case is that – sometimes the parameter can be empty. This check has to be done in the scripts i.e. if the value exists for the parameter, execute the extra tasks along with the normal deployment else just do a normal deployment.

Continued..

• Continuous Delivery – Part 1: Our Jenkins Build Pipeline setup
• Continuous Delivery – Part 2: Code metrics with metrical
• Continuous Delivery – Part 4: Rolling back database migrations with Capistrano rollback

The steps I followed for setting it up in our Jenkins server are:

• Install the gem. I installed it under our ruby 1.9.2 in RVM.
• Create a .metrics file under your projects directory with the settings. This is not mandatory, but I had to use this because some configurations do not seem to be working with ruby 1.9.2. I’ve mentioned those below along with the contents of the .metrics file
• Create a job in Jenkins server, mention the repository details and for build step give the shell command as rvm 1.9.2 -S metrical
• Configure the HTML Publisher plugin for showing the nice Graphs generated by metric_fu as part of the build report. The default report location is tmp/metric_fu/output under the project directory. You can change the same in .metrics file.

As I mentioned above, tools such as flay and flog, which comes as part of metric_fu, have issues working with ruby 1.9.2. And the same case with stats graph and syntax highlighting. The same case with rcov also. So I had to create a .metrics file with the following contents and put in the project dir:

MetricFu::Configuration.run do |config|
        config.code_dirs = ['app', 'lib']
        config.syntax_highlighting = false
        config.metrics  = [:churn,:reek,:roodi,:hotspots,:rails_best_practices]
        config.graphs   = [:reek, :roodi, :rails_best_practices]
        config.rcov[:test_files] = ['spec/**/*_spec.rb']
        config.rcov[:rcov_opts] << "-Ispec" # Needed to find spec_helper
end

For test coverage I’ve used Simplecov which is easy to setup. It will generate the coverage report whenever you run the tests. This also generated html report which can be integrated easily into Jenkins. As mentioned here in the issue list, it does not generate the report when you are running with spork.

Continued..

• Continuous Delivery – Part 1: Our Jenkins Build Pipeline setup
• Continuous Delivery – Part 3: Running custom rake tasks during deployment
• Continuous Delivery – Part 4: Rolling back database migrations with Capistrano rollback

A super simple SMTP server which catches any messages sent to it to display in a web interface. Configure the app to deliver to smtp://127.0.0.1:1025, then check out http://127.0.0.1:1080 to see all the mails being sent out of your application.

This really makes it easy to check emails generated by the application in development environment. Additionally configuring this tool in your development environment makes sure that emails are not being sent to actual users unintentionally – very useful when you are trying to reproduce some issue with production environment data.

Rating: Extremely useful

Vogue

Vogue creates a real-time link between your web browser and your file system. When you save a CSS file, used by the HTML page in your browser, Vogue will make the browser reload the stylesheet. Only the stylesheet is reloaded, not the entire page, making it work even for very dynamic/ajax pages.

A very useful tool, and it does save a lot of time when you are trying to check CSS changes across different browsers.

To make it work, you just have to install node.js and its package management tool – npm.

Node installation instructions
npm installation instructions

Vogue installation [Note: This a forked repo]

As of this writing there is a compatibility issue with Vogue and the socket.io package it uses, so instead of installing from the official repo use this repo instead [https://github.com/DTrejo/vogue.git].

Rating: Extremely useful

SpriteCow

Helps you get the background-position, width and height of sprits within a sprite sheet.

This tools works really well with sprite-sheets which has a transparent background [which is usually the case].

RailsWizard

Rails Wizard is a tool from Intridea which makes it easy to create application templates just by specifying the gems that you want to use.  It is available as a webapp as well as as stand alone tool.

Because of an incompatibility with the latest mysql2 gem and rails (3.0.x) this did not work me as expected.

Rating: Moderately useful

The pipeline we have now is very simple. They are:

• Run all the RSpec tests
• Run the Javascript Unit tests
• Deploy to staging
• Deploy to production

The problems we had with our earlier approach, and how the current approach solved those problems:

What we had in the past was, simple scripts with the above items. We had a job for running the tests. If the build was successful, we would run capistrano scripts to deploy to staging and once the customer gave the thumbs up, we’d push it to production.  There are a series of steps that we had to do for each deployment. For eg:  for staging deployment:

• Merge the “staging” branch with master
• Run the cap script
• Tag the build

And almost similar steps needed to be followed for production deployment also. The usual problems that we used to face are:

• There is no way we knew what deployment was done on a certain day for what
• All staging updates would not get pushed to production, so it was a tough task to identify which tag to merge when we were finally ready for a production update

With the current approach, the advantages are:

• Its a one click deployment, so rare chance of making any kind of mistake
• We can clearly see when a feature has been moved to staging, and whether it has been pushed to production or not
• Anyone can do deployment as it is just a click of a button. We may even be able to teach the client how to do this.

One of the major problems I had faced in the earlier “manual” system – was the inability to pass parameters between builds. For example, once the app would be moved to staging, a tag is created and when its ready to be pushed to production, we’d have to merge that particular tag to production and then push it.

To achieve the above I used the “parameterized build” option. In Jenkins, the parameters get converted to Environment Variables and got passed to the downstream job. This is how you can set the parameterized build:

When you fire the build, it prompts for the value of the TAG parameter. Once entered this would be available as an Environment variable for this job and all its downstream jobs.

For eg: in the pipeline, the downstream project is “Stage deploy”, and it will know the value for TAG and uses that value to create a tag in Git after successful deployment.

When it is ready for production deployment it merges with the same tag and deploys to production. In the latest version of the plugin, moving to the next step is not triggered automatically and you can retry the failed ones. The following is a sample pipeline dashboard view:

Note: Capturing the parameter will happen only for the first job. So, if the parameterized job is not the first one in the pipeline, the capture of the parameter will not happen.

So we’ve reached the “one click deployment stage” with this. But we’ve still got the following pending tasks – based on what’s mention in the book  Continuous Delivery:

• Rolling back the bad builds
• Add non-functional tests to the pipeline i.e. performance and security tests
• Feature flags
• Zero downtime deployment
• Canary Releases (Something on the lines of A/B testing)

Continued..

• Continuous Delivery – Part 2: Code metrics with metrical
• Continuous Delivery – Part 3: Running custom rake tasks during deployment
• Continuous Delivery – Part 4: Rolling back database migrations with Capistrano rollback

References:

• http://weblogs.java.net/blog/johnsmart/archive/2011/03/10/build-pipelines-jenkinshudson
• http://continuousdelivery.com/patterns
• http://www.quora.com/How-does-Etsy-manage-development-and-operations

All the errors looked similar to this:

Although the tests were failing, the functionality seemed to work just fine. So this had to be some issue with Specs. When I checked the code again I found that one of our view specs included ApplicationHelper, but unlike most of the other specs this one had the ”include” statement outside the main ExampleGroup.

 require 'spec_helper'
 include SearchHelper
 include ApplicationHelper
 describe "/welcome/discover.html.haml"

require 'spec_helper'
describe "/welcome/discover.html.haml"
  include SearchHelper
  include ApplicationHelper

I tried TLB, but stopped on it because it required cluster setup for our CI server i.e. hudson. I was looking for something which was even simpler than TLB, and tried Hydra, but could not setup it successfully. Thankfully though, the Hydra committer  suggested that I try out  parallel_tests – as hydra is not currently being maintained.

I am yet to try running it parallelly on multiple machines, but I tried it on a dual core machine and can clearly see the difference. The following are the results:

Without parallel_tests:

Finished in 451.01 seconds
1089 examples, 20 failures, 1 pending

real	8m14.908s
user	3m4.236s
sys	3m20.061s

With parallel_tests:

Results:
544 examples, 10 failures, 1 pending
545 examples, 10 failures

Took 330.528104223 seconds
Specs Failed

real	5m35.586s
user	7m3.150s
sys	0m14.269s

The different is 2-3 minutes which I think is a huge deal.

I forked parallel_tests to make a change to its default behaviour of running tests only under spec folder. As our app was built using rails engines, we had tests even under our vendor/engines directory.

The feature, I feel, missing in parallel_tests compared to TLB is the logic it uses to split the tests. TLB is intelligent enough to split the tests into different processes depending upon the time each test takes, so that all the threads finish by the same time. I am not sure whether how exactly parallel_tests works, but looks like it splits the total no of tests among the number of processes because when it started I could see the message:

"2 processes for 162 specs, 81 specs per process"

But parallel_tests by default spawns multiple processes depending upon the “core” i.e. on a dual core it starts 2 processes unless you mention otherwise.

Update: We’ve fixed the 20 failures mentioned above. Those started coming all of a sudden, and how we have fixed the same can be found here.

Step 1: Add these to Gemfile

gem 'therubyracer', :require => false
gem 'barista'

‘barista’ gem takes care of installing coffee-script gem and its dependencies. ‘therubyracer’ is the javascript engine for ruby.

Step 2: Run Bundle Install to install coffee-script gem and other required gems

bundle install

Step 3: Generate Barista initializer file config/initializers/barista_config.rb

rails generate barista:install

Step 4(optional): Lets configure barista to compile all coffeescript code into public/javascripts/coffeescripts/ folder (this is optional, if not configured compiled code will be placed under public/javascripts folder)

config/initializers/barista_config.rb, line 7.

# Change the output root, causing Barista to compile into public/coffeescripts
c.output_root = Rails.root.join("public", "javascripts", "coffeescripts")

Step 5: Create a folder ‘coffeescripts’ under app/ to have all your coffeescripts. All file names should end with .coffee
Example: app/coffeescripts/user.coffee

jQuery ->
 $('form').validate()

Step 6: Above code will be complied to JS file under public/javascripts/coffeescripts/user.js. Example code:

 /* DO NOT MODIFY. This file was compiled Thu, 23 Jun 2011 07:13:34 GMT from
 * /home/manoj/my_rails_app/app/coffeescripts/user.coffee
 */
 (function() {
 jQuery(function() {
 return $('form').validate();
 });
 }).call(this);

Step 7: Include these coffeescript js files in your view/layouts using include tag.

<%= javascript_include_tag 'application', 'coffeescripts/user' %>

And you’re done with setup. As the complied code is neat JS code, your page should continue to work fine Going forward you can start using CoffeeScript for writing JS code.

For deployment we can use the barista:brew rake task in the Capistrano script using an “after” hook

Refrences used to create above steps:
http://jashkenas.github.com/coffee-script/
http://blog.nicolasblanco.fr/2010/12/13/you-should-already-use-coffeescript-in-your-rails-app/

Convert existing JS to coffeescript:
http://ricostacruz.com/js2coffee/

Setting up Emacs with coffee-mode:
http://ozmm.org/posts/coffee_mode.html

There were quite a few presentations this year which I felt were very useful for me. Those are:

• Ruby Plus Rails Plus Your Application Minus Rails by Brian Guthrie
• Test Load Balancer: Rocket Booster for your Build by Janmejay Singh and Pavan
• Continuous Delivery in Ruby by Srushti Ambekallu and Brian Guthrie

And its needless to say that the keynotes by Yehuda Katz, Chad Fowler, Nick Sieger and Ola Bini were awesome too. Especially Chad Fowler’s session gave a new perspective on “Service” and who should be considered as a “Customer”. And Nick Sieger’s closing note gave a different perspective on how to contribute back to the community by conducting workshops and with Kidsruby.

So whats next? Yes, implement the stuff we learned. So these are the immediate action items for us:

• More automation for the entire release mechanism. We do have a CI server and do have a Cap script for deployment. But we do not have a “one click deployment” process. A “Build pipeline” plugin for Hudson should help us achieve that.
• Tools like Chef/Puppet for server configuration management. We’ve tried rubber, but are yet to use it for any production setup.
• Use TLB to run tests in parallel.  Setup seem to be pretty straightforward. This will be a huge help when you are doing many deployment in a day.

Update: One talk I missed in the list was Designing High Throughput Web Service Clients by Sherin. He was able to convey the problems he faced and how he went ahead and solved those.