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.