Monday, January 2, 2017

Lagrange multiplier to solve "Mushroom Scientists" problem

Yesterday I was trying to solve this problem on codeforces and found its solution very interesting .. to be honest I had to do alot of research to understand the editorial solution .. so I managed to write a clearer documentation for how to solve these kind of problems.

First of all the problem is that you are trying to maximize f(x,y,z) = x^a Y^b Z^c with the constraint function g(x,y,z) = X+Y+Z = S ..

First of all if (a,b,c) = (0,0,0) then the maximum you get for f(x,y,z) is 1 :) .. otherwise lets solve the problem of at least having one of them > 0.

We can use Lagrange multiplier to solve this problem by doing the following:

=> f(x,y,z) = ƛg(x,y,z) -> Lagrange multiplier
=> x^a . y^b . z^c = ƛ(x+y+z)

by taking derivative d/dx we get:

=> ax^(a-1) . y^b . z^c = ƛ(1+0+0) = ƛ -> (1)

by taking the derivative d/dy we get:

=> bx^a . y^(b-1) . z^c = ƛ(0+1+0) = ƛ -> (2)

by taking the derivative d/dz we get:

=> cx^a . y^b . z^(c-1) = ƛ(0+0+1) = ƛ -> (3)

This implies the following:

=>  ax^(a-1) . y^b . z^c = bx^a . y^(b-1) . z^c = cx^a . y^b . z^(c-1) = ƛ
=> (1) = (2) = (3)

By solving  (1) and (2) together we get:

=> ax^(a-1) . y^b . z^c = bx^a . y^(b-1) . z^c = ƛ
=> ax^(a-1) . y^b = bx^a . y^(b-1)
=> bx = ay
=> a/x = b/y -> (4)

By solving (2) and (3) we get:

=>  bx^a . y^(b-1) . z^c = cx^a . y^b . z^(c-1)
=> bz = cy
=> c/z = b/y -> (5)

From (4) and (5) we get:

a/x = b/y = c/z -> (6)

Now we can use this fact in g(x,y,z) we get:

=> x+y+z = S
=> x+bx/a+cx/a = S
=> ax+bx+cx = Sa
=> x = Sa/(a+b+c) -> (7)

Doing the same for y and z you get:

=> y = Sb/(a+b+c)
=> z = Sc/(a+b+c)

Now the problem is solved and here is my code:

Monday, July 18, 2016

Web Test Automation

Most of tech companies now realise that manual testing is not as effective as anticipated and wanted to automate the whole process of users going to their websites performing some actions, submitting a form, or triggering a search,... etc.

You have probably thought many times of automating some repetitive tasks that you do every day or sometimes multiple times per day. Some people automate making their morning coffee - Believe me :).

Testing is one of the repetitive tasks that developers tend to do very often everyday .. Why? because it's important to make sure that things are working as expected before pushing them to production.

In this post I will not talk about the theory of automation or the frameworks themselves as there are plenty of articles for this purpose .. This article is just to introduce you to the world of automation and point you towards the next step.

Links to read


Phantom JS
Selenium headless mode

Steps to run this example

  • Create a maven project and copy these files
  • Make sure you download chrome driver from here
  • Edit the path to your chrome driver installation
  • Run the class


In this example I will use Selenium framework to test Amazon DE website and search for something there .. then print the search page title .. No assertions/checks will be done as it depends on your business and the purpose of your test.

Pom.xml that defines libraries used:

Cheers ;)

Thursday, March 10, 2016

Mockito for better unit tests

Today I'm going to introduce you a very nice framework that allows you write good unit tests that cover only the parts of code that you want to test and stub all other dependencies .. but obviously in order to do that your code must be written in a testable way.

To know more about testability please refer to this wiki document.

  • What is Mockito?
  • How to use it?
  • Example
What is Mockito?

Mockito is a framework that  allows you writing unit tests that only test your piece of code by mocking and stub all other components that your piece of code depends on.

In other words if you want to test your integration with other libs and components then its not unit test any more .. its called integration test which is not covered in this post.

How to use it?

You can configure mockito using maven or simply download the lib from here.

For maven configuration you can define the dependency in your pom.xml as here.


Note: I will use junit in the following example and in case you are not familiar with junit please refer to this.

Let's start by a very simple example that you have a class that reads a comma separated String and return it as a List<String> .. It reads this String by calling another class CSVReader that can either read it from file/database/network .. so in case you want to test your class only without being dependant on the CSVLineReaderClass you should mock the reader class.


Usually when running unit tests you need to get rid of the overhead of setting up other dependencies and want to see how your class/function behaves not how others behave.

Implementation of CSVLineParser:

The unit test should look like this, and you can add more test cases :).

When you run the test cases you will see the nice green results which means that all cases have passed correctly.

When you do something wrong like this :) .. you will see the unit tests failing.


In fact that's really nice, its really safe when you or someone else in your team mistakenly does these kind of stupid issues, its better to catch it during development than catching it in pre-production or on production and embrasse yourself and your team :D.

Mockito has way more than this simple example, but as usual I like to introduce you with very small nice things and then you can continue reading and see other features of the framework :).

I hope you like it.