PhantomJS

The Problem:

When given a website and an image on that website, the task is to take a screen capture of that image on the page it appears on the site.

Solution 1:

Manually: enter the website, find the given image (scroll if needed), take the screenshot and save it to the disk.

But what can you do when you have thousands of screenshots to take per hour?

You can employ hundreds of people to handle this scale, but...

This is kind of expensive and what should you do if your scale increases or decreases?

Solution 2:

Automate it: if only we could write a piece of software that could do exactly what we need...

So what do we actually need? Something that can:

1) Imitate a browser

2) Find an image on a webpage

3) Take the screenshot

Let me introduce PhantomJS:

PhantomJS is commonly known as Headless Web Kit with JavaScript API.

Headless refers to the fact that the program can be run from the command line without a window system.

JavaScript API means that we can easily write scripts that interact with PhantomJS which is useful if one needs to find an image on a webpage for instance.

Web Kit is the open-source web browsing engine that powers popular browsers like Chrome.

How to use it?

There are many ways to use PhantomJS, here at PicScout we use Selenium Web Driver to run PhantomJS. Selenium can control PhantomJS in the same way that it does any other browser.

How does it help me to take a screen capture?

As we said before, PhantomJS can run JavaScript, so all we have left to do is to write a short script that searches for the image location on the page and let PhantomJS run the script.

After receiving the location we can use PhantomJS to take a screen capture, despite the fact that PhantomJS is a Headless browser it still can render a web page as well as a web driver.

Code sample:

Running several instances of PhantomJS – problems and solutions

Problem #1: zombie processes. In our app we create and kill PhantomJS processes, we have noticed that after some time there are many zombie instances of PhantomJS.

Solution #1: for unknown reasons, occasionally we are unable to create a new PhantomJS instance. This happen when an exception is thrown and a new PhantomJS process starts. Now we need to manually find the process id and kill it.

Problem #2: low success rate on high CPU usage - when CPU reached 100% we were receiving a lot of errors from PhantomJS.

Solution #2: number of PhantomJS instances should be set according to 'computing power'. Notice that most of the time PhantomJS won't consume much CPU but there are websites for which this isn't the case, you should take this into consideration when you decide how many PhantomJS processes you would like to run.

Problem #3: sometimes the screen capture fails without any apparent reason.

Solution #3: we were able to increase the screen capture success rate by using a retry mechanism.  

Why you should use reCAPTCHA in public websites?

The problem:

We've developed an API which allows users to search and upload Images.
Any application that wants to query it uses an API key which allows it to perform different actions according to its permissions. 

Recently we started to expose some of the API's abilities in public websites.
For example, see the PicScout Search Tool on www.picscout.com (and press the "Launch Tool" button).
Here’s the issue: Exposing the key to unknown users can make us vulnerable to spam and abuse.

The solution:

In order to overcome this problem we decided to use Google reCaptcha.

Using this tool means that only real people can pass through the system, as opposed to malicious bots.                         

Reaching this solution included client and server side adaptations. On the client side, we added support to the reCaptcha widget. This widget is shown to the users before their first action in the site and afterwards only if their token has expired. On the server side, we added a second layer of authentication. This authentication is enforced only on API keys that are public, meaning those used on public sites. When making a request, the users must send an API key as well as a token supplied to them by Google reCaptcha. The server verifies this token combined with some secret agreed between the server and Google. If this information is successfully verified, the resource is returned to the user. Otherwise, the request fails.

That's about it on how we use  reCAPTCHA at PicScout.

Riddle me this

We recently published some code riddles,

It was really fun writing them and we had a lot of good responses from Software developers who enjoyed solving them.

The solvers of the riddles got a nice T-Shirt:

For those of you who enjoy riddles here they are:

1. Follow the bread crumb trail from here:
   
2. Go to http://riddle.guru 

Enjoy :-)

Managing dependent jobs in Jenkins

The problem

It is well known that Jenkins can handle job dependencies based on maven dependencies.

But, how can we manage dependencies between Jenkins jobs that are based on .Net code?
Of course, we can manage job dependencies manually, marking in each job what are its dependent jobs, this takes a lot of time to maintain and is also error prone.

We looked into some options (there weren't many) and couldn't find anything that quite fitted our needs.
This is because here in Picscout, each of our Jenkins jobs is mapped to a single solution.
It can run MSBuild , or unit tests on each relevant project in the solution.
If, for example, we take NDepend powerful API and try to adjust it to our needs, we can use it to know what assemblies are referenced by our solution's projects.
But what are the solutions that hold those assemblies? and by what order should we build them? this is for left for us to implement.
Surely there must be a better alternative.

The solution

We decided to write something of our own.
We wanted a tool that will integrate well with Jenkins.

While Jenkins can run any type of script or executable, if you run your code within Jenkins itself (using groovy system script) you will be able to use its internal API, to do things like start new jobs, wait for them to complete and analyze their build result quite effortlessly.
This however means you have to write your code on a JVM based language-

That is why we opted to write our tool in Java.

The dependency tool we wrote can map solution and project files in given folders and build a dependency chain for each project and solution.

Given a project, it can tell you what projects (by order) will be affected as a result of a change in this project and same is true for solutions.

Now, all that is left to do is to integrate it with Jenkins and Git.

Git/Jenkins Integration

The process we built is made of a few steps:

1. We use git-hooks to identify changed folders, we than find what solutions are in those folders.

2. We send the list of changed solutions to a special job we wrote in Jenkins.

3. The job runs a small Groovy system script , this script finds the dependent jobs using the dependency tool, runs them and and decides if the git commit can be accepted to our master branch (if all the jobs passed).

finally, the dependency tool can also be integrated with Jenkins dependency grpah view plugin to draw the dependencies :

(we are still working on this one)

Source/Deployment

The dependency tool can be found here along with some example usage projects and groovy scripts.

The tool is also deployed in Maven repo.

Please notice it is licensed under the MIT license.

PicScout is Hiring !!!

Hi all,

PicScout is looking for top notch SW engineers that would like to join an extremely innovative team.

If you consider yourself as one that can fit the team, please solve the below quiz and if your solution is well written - expect a phone call from us. You can choose any programming language you like to write the code.

Don't forget to also attach your CV along with the solution.

Candidates that will finally be hired will win a 3K NIS prize.

So here it is:

We want to build a tic–tac–toe server.
The server will enable two users to log in. It will create a match between them and will let them play until the match is over.

The clients can run on any UI framework or even as console applications.(We want to put our main focus on the server for this quiz). Extra credit is given for: good design, test coverage, clean code.

Answers can be sent to: omer.schliefer@picscout.com

Running UI tests in parallel mode

At Picscout, we use automated testing.

Running tests is an integral part of our Continuous Integration and Continuous Deployment workflow. 
It allows us to implement new features quickly, since we are always confident that the product still works as we expect.

The automation tool that we are using is Selenium (Selenium is an open source set of tools for the automatic running of browser-based applications).

Despite the many benefits of Selenium, there is one drawback that constitutes a bottleneck: the running time of the tests.

For example, in one of our projects, we need to run 120 UI tests, which takes 75 minutes - a long time to wait for a deployment.

To handle this situation, we developed a tool that runs the tests in parallel mode.

Using this tool, we were able to reduce the run time to 12 minutes of tests.

How it works:

Two tests can be run in parallel mode as long as they are not affected by each other.
We avoid writing tests that use and modify the same data, since they cannot be run in parallel.

The assumption is that two tests can be run in parallel mode if each test has a different id.

When writing a new Selenium test, we add a “Test Case” attribute to the test.

The attribute will be the id of the test.

The tool reads the Selenium project dll file,

Separates the tests into different queues according to their test cases and each queue runs in parallel mode.

13:43:51          Parallel Nunit Console

13:43:52

13:43:52  - Number of parallel queues: 6, number of tests: 29

13:43:52

13:43:52  - Number of serial queues: 1, number of tests: 3

The tool runs 10-15 threads of tests, instead of one thread in serial mode (one by one).

There are two more options in the tool. 

The first option is "update local DB." 

This creates or updates the local DB (a minimized DB, just for running UI tests). 

The second option is for the UI tool to run the tests in parallel mode. 

These two features allow us to run the tests on a developer’s station before the code is pushed, and on our build machine after the code is pushed.

That's how we run UI tests these days.

Code retreat about logging

At PicScout we have various ways to improve our software craftsmanship abilities. One of them is doing code retreats.

The code retreats are led by two of our software engineers. They are responsible to choose an interesting exercise for the R&D team to perform.

We usually do 2 or 3 sessions, each time writing code in pairs. Between each session we have a discussion about the previous session and decide what to do in the next session. In between we enjoy Pizza and beers at the curtesy of Picscout J

I would like to elaborate about our last code retreat, led by Ram and Galit from our R&D team.

Session 1

The first session was about writing some complicated code that does a lot of complicated logic with a movie repository. We were asked to implement an interface which retrieves bulks of movies from the repository, and filter them according to some given rules.

After the first session we regrouped and a few brave volunteers submitted their compiled code which was invoked by a small program written by Ram and Galit.

When the program returned wrong results, the developers that wrote it were asked to look at the logs and explain what went wrong.

They found it a bit hard to do because, well… there were no logs.

Than the real (evil) purpose of the code retreat was discovered:

How to write log messages that can be used in production environment to give useful insights for complicated production scenarios.

Session 2

In the second session we were asked to add logs to the code we wrote in the first session using our logging infrastructure (based on log4net).

After the second session we regrouped again, ran a few more examples and discussed how the log prints were implemented, and how to improve them.

For example:

• Using logs to show the application flow.
• What is the log level we expect the application to write in production?
• Which message should be written in each level? (For example: No normal system behavior should be logged at a warning level.) 

Pizza and Beers

Session 3

For the final session we had, we were asked to write a small AOP (aspect oriented programming) example that was used to add some repeating logs messages.

This was a nice exercise that showed us how we can add logs to our code simply by adding attribute to our method thus keeping the code cleaner.