How to use Firefox with Selenium 3.0.0-beta2

0.00 avg. rating (0% score) - 0 votes

Selenium 3 brings about a whole new slew of changes. Perhaps among the most frustrating is the fact that the existing, built-in Firefox driver no longer works as it did in Selenium 2.53.1. It took a little research, but I finally found a solution that allows Firefox to work with Selenium 3.0.0-beta2.

Follow the below instructions and you should be good to go.

  • Be sure Firefox is up to date (47.0.1).
  • Be sure both selenium-server and selenium-java are up to date in your pom.xml file (3.0.0-beta2).

  • Download the geckodriver 0.10.0 (0.8.0 for support of 32-bit Windows OSes)
  • Put the driver into your project (Mine is in /src/test/resources)
  • Configure Selenium to run:
// Sets the marionette and path to the gecko driver
System.setProperty("webdriver.firefox.marionette", “C:\\path\\to\\geckodriver.exe”);

// The following overrides the Firefox first run page 
FirefoxProfile profile = new FirefoxProfile(); 
profile.setPreference("", 0); 
profile.setPreference("browser.startup.homepage_override.mstone", "ignore");

// Create the webdriver
WebDriver driver = new FirefoxDriver(profile);
  •  Run your tests normally.

Php – If vs Switch

0.00 avg. rating (0% score) - 0 votes

I’ve been wondering for a while now if the switch statement is really more efficient than the if statement in php. I’ve read quite a few articles stating that it was. I wanted to test this out for myself.

The Test:

header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");
<!DOCTYPE html>
        <meta charset="UTF-8">
        $a = '';

        // If Statement
        $start = microtime(true);
        if ($a == 'abc') {
            echo 1;
        if ($a == 'def') {
            echo 2;
        if ($a == 'ghi') {
            echo 3;
        if ($a == 'jkl') {
            echo 4;
        if ($a == 'mno') {
            echo 5;
        if ($a == 'pqr') {
            echo 6;
        if ($a == 'stu') {
            echo 7;
        if ($a == 'vwx') {
            echo 8;
        if ($a == 'yza') {
            echo 9;
        if ($a == 'bcd') {
            echo 10;
        } else {
            echo "<p>";
        echo "<p>End If: " . round(microtime(true) - $start, 10) * 1000 ."<p>";

        // Switch Statement 
        $start = microtime(true);

        switch ($a) {
            case 'abc':
                echo 1;
            case 'def':
                echo 2;
            case 'ghi':
                echo 3;
            case 'jkl':
                echo 4;
            case 'mno':
                echo 5;
            case 'pqr':
                echo 6;
            case 'stu':
                echo 7;
            case 'vwx':
                echo 8;
            case 'yza':
                echo 9;
            case 'bcd':
                echo 10;

                echo "<p>";
        echo "<p>End Switch: " . round(microtime(true) - $start, 10) * 1000 ."<p>";


The Result:

The if statement took 0.0190725 milliseconds.

The switch statement took 0.0061989 milliseconds.

That’s a difference of 0.0128736 milliseconds. That may not sound like much but when you take into account that the switch is 32.5 times faster in this example than the if statement, over the course of millions of computations, it is a rather significant increase.

I did change the value the statements were checking several times. Even in cases of checking five values or less, the switch statement is still around twice as fast as the if statement.


This experiment of mine is by no means scientific; I didn’t use if/else statements nor did I break the if statement if a match is found which I suspect would bring the if statement closer to the speed of the switch statement. What this does tell me is that, in most cases, it is probably better to use a switch statement than an if statement in your php code. Feel free to correct me if I am wrong.

Installing and Configuring Jenkins for Selenium Tests – Part 2

0.00 avg. rating (0% score) - 0 votes

Ilogo-2n the previous post, I talked about installing Jenkins on an Ubuntu server. Since that time, I have upgraded to Ubuntu 16.04. There is at least one small differences, but all in all its the same. When installing Maven on 16.04, the maven2 package is not available from the apt repository but maven is. Maven seems to work just fine.

One other note that I would like to point out with the previous post before moving on is that I added instructions for downloading and installing Selenium. As long as you are using Maven, this step is unnecessary if the Selenium package is included in your pom.xml file. Once Maven runs, it will automatically download Selenium and set the correct run path. I apologize for any confusion that may occur because of that.

Now, down to business.

In this post, we will be covering the following:

  • Configuring Jenkins
  • Setting the Global Tool Configurations
  • Setting the Node Configurations
  • Creating the Display
  • Installing Jenkins Plugins

Configuring Jenkins

We last left off with Jenkins installed and being able to navigate to it in a web browser (http://<server>:8080) but left off there. As you have probably noticed by now, Jenkins is complaining that it needs to be unlocked. Lets go over that now:

The following instructions show you how to unlock and initially setup Jenkins:

  1. $ cat /var/lib/jenkins/secrets/initialAdminPassword
  2. Copy that key from the terminal
  3. Paste the key into the ‘Administrator Password’ field
  4. Click on the ‘Continue’ button
  5. Click on the ‘Suggested Plugins’ option
  6. Create an admin user by filling out the form
  7. Click on ‘Start Using Jenkins’

The ‘ $ cat /var/lib/jenkins/secrets/initialAdminPassword’ command prints out the initial password in the terminal. More Information

Now that that is completed its time to move on to actually starting to configure Jenkins. Before we do anything Jenkins is built to do (ie, code deployments, running automated tests, etc.), we need to get it configured. This may get a little long, but bear with me, it will be worth it.

Setting the Global Tool Configurations

The Global Tool Configurations is the place to globally set up the various aspects of the Jenkins system. It is here we will setup the path to the Java SDK. There are other options here, but for the purpose of initially setting up Jenkins, we will only worry about the Java SDK.

  1. If you are not logged into Jenkins, please do so now.
  2. Click on the ‘Manage Jenkins’ link
  3. Click on the ‘Global Tool Configurations’ link
  4. Click the button that says ‘Add JDK’
  5. Enter a name for the JDK (I used ‘Java 8’)
  6. Uncheck the ‘Install Automatically’ box. We downloaded the JDK in the previous article already.
  7. Enter the path to the Java JDK in the JAVA_HOME input box. In Ubuntu this is usually ‘/usr/lib/jvm/java-1.8.0-openjdk-amd64’ at the time of this article. Your installation may be different, you may have a name like java-1.8.0-openjdk-x86 if you are running a 32-bit Ubuntu installation.
  8. Go ahead and click ‘Save’

Setting the Node configuration

If you are still in the ‘Manage Jenkins’ section, click on the ‘Manage Nodes’ link. If not, click on ‘Manage Jenkins’ followed by the ‘Manage Nodes’ link. The nodes are the other machines that are connected to Jenkins. For now, we only have the one, master node to configure.

  1. Click on the configuration icon on the right side. It looks like a gear.
  2. Click on the ‘Environmental variables’ checkbox.
  3. Click on the ‘Add’ button that appears.
  4. For the name, enter ‘DISPLAY’
  5. For the value, enter ‘:99’ Please note the colon before the 99.
  6. Press the ‘Save’ button.

What we’ve just done is setup the display information for the headless browsers that will be running our tests. Think of it as a ‘virtual monitor’ we just plugged into Jenkins. Now we need to put that monitor to work.

Creating the DISPLAY 

    1. create a new file called something like ‘startXvfb’ by entering the following in the terminal:
      $ sudo pico /etc/init.d/startXvfb
    2. Paste the following script into it (curtesy of Installing Selenium With Jenkins on Ubuntu – Lextech). Please note the line ‘/usr/bin/Xvfb :99 -ac -screen 0 1650x1080x24 &’ in the script. Notice the ‘:99’? This is the virtual frame buffer we set up in the node configuration; the ‘virtual monitor’. This is how Jenkins knows where to display the tests. More information

      =============== Begin Paste ============

      # Provides:          startXvfb
      # Required-Start:    $local_fs $network
      # Required-Stop:     $local_fs
      # Default-Start:     2 3 4 5
      # Default-Stop:      0 1 6
      # Short-Description:Start daemon at boot time
      # Description:      Enable service provided by daemon.
      ### END INIT INFO

      if [ -z “$1” ]; then
        echo “`basename $0` {start|stop}”

      case “$1” in
        /usr/bin/Xvfb :99 -ac -screen 0 1680x1050x24 &
        killall Xvfb
      =============== End Paste ============

    3. Save the file
    4. Make the file executable by entering the following in the terminal:
      $ sudo chmod u+x /etc/init.d/startXvfb
    5. Start the display by entering the following in the terminal:
      $ sudo /etc/init.d/startXvfb start

This will start the xvfb service; the ‘virtual monitor’ for our headless browsers to use.

Installing the Jenkins plugins

The final step to configuring Jenkins itself is to install any plugins we may need. For now, I am only going to cover the Cucumber-jvm plugin since I use it all the time. Other plugins are installed in the same manner, but the setups for them may vary.

  1. Install the Cucumber-jvm reports plugin in Jenkins.
    1. Click on the ‘Manage Jenkins’ link
    2. Click on the ‘Manage Plugins’ link
    3. Click on the ‘Available’ tab
    4. Enter ‘cucumber’ in the ‘Filter’ field at the top of the screen
    5. Check the box next to ‘Cucumber-jvm reports’
    6. Click on the ‘Download now and install after restart’ button
    7. Put a check in the ‘Restart Jenkins…’ option

Now Jenkins should be all set up to run jobs. Next time we will cover setting up a new Jenkins job and running our first one.

Thanks for learning with me.

Why I abandoned Bacula as a home network backup solution

0.00 avg. rating (0% score) - 0 votes

AAEAAQAAAAAAAAMDAAAAJGI0MmIzOTUyLTI5OTMtNGI3Ni04YWJmLTgwOGExMGIyMjhiNANote: This post was originally posted on LinkedIn on 5/22/2015

Almost two weeks ago, I posted that I had a “fun little side project” going at home. I was setting up Bacula (think Retrospect, Veritas, etc., but free for personal use) on my Ubuntu file server to backup all my home computers and have the backups in one, central location. In theory, this was ideal for me and it did work effectively to backup the local machine that was running the backup to a separate drive. However, I encountered concerns.

After hours of Googling, reading forums and scrolling through all the “you should have Googled first before asking for help” comments, thank you Linux community for your continued dedication to helping out the noobs, I finally got the configuration files all set correctly for the localhost machine; I was excited even though this should have been clue #1 that Bacula was not for me.

Clue #2 came when I was “accidentally” thrown into a backup “test”. Ok, it wasn’t really a test, it was more of an, “Oops, I shouldn’t have done that” situation, but it did end up being a really good test of how to restore a set of files that went poof. The restoration, like much of the configuration was done through Webmin, I tried to keep everything as GUI as possible which will become clear in the last clue. The restoration process was disappointing. I spent more than an hour figuring out why my Webmin module wouldn’t allow me to open the restoration path window. To be fair, this was not a Bacula issue, Bacula was not intended to be a GUI interface backup solution and the Webmin module was not written by the Bacula team.

I finally found out that the reason that I was not able to open the file path window was due to a Java security issue that I needed to set within the OS security settings as well as the the browser security settings; at this, I grew cold and shuddered. Eventually, I got my files back, but not before running into clue #3 as to why this would not be a good solution for me; there is no date indicator to indicate the date/time the snapshot was taken. This may be a limitation of the Webmin module, but I had to search for a while before finding the files to restore.

Finally, clue #4. If, for some reason, I am not able to restore a file that my wife may need immediately, the complexity of the system means that she is not going to be able to restore it on her own. This is nothing against my wife, but she does not work in the technology field; it would not work well for her. This is also why I was insistent on a GUI solution, she would have no clue how to navigate in a *nix shell, let alone restore a file from one just like I would have no clue how to navigate around a therapy patient and would probably be arrested if I even tried.

So what did I go with? I finally decided that rsnapshot was what would be the best solution for my home network. I had worked with rsnapshot in the past and it was just as easy as I remembered. It also has the ability to backup remote “clients” just like Bacula, but I have restructured my network to only backup the two file servers that sit in my basement. Perhaps later, I can incorporate rsnapshot with my Macs (currently backup to Time Machine) and Ubuntu desktop computer, but for now, this is acceptable since it backups all of our pictures hourly.

I believe Bacula would be a great Enterprise level backup solution application for an organization that may just be starting out or have monetary concerns as long as you had a dedicated IT staff to maintain it (I couldn’t find the exact cost for sure for Enterprise level editions). For me and my home network, rsnapshot will work out fine since we can all just mount the backup drive and drill through all the backups, pulling the file out that we need.

Installing and Configuring Jenkins for Selenium Tests – Part 1

0.00 avg. rating (0% score) - 0 votes


I struggled with how to post this tutorial on Jenkins. I didn’t want to be too short and incomplete that it lacked important information and I didn’t want to be too long winded that no one finds it useful. It is my hope that others will find some use in this article. It combines a lot of information from various sources that I had to hunt around to find. Even I won’t know how this post goes until I finished writing it.

I am learning about automated testing for my job, in particular, Java Selenium with Cucumber. So far, it has ignited a passion for work that I have not felt in a long time. I hope that, as I learn, I can share with those wanting to read more about automated testing; I am learning with you, the reader. So, without further ado, here we go.


The basic Jenkins setup needs the following in order to work. Most of this will be done from the command line as it would likely be set up on a headless server.

  • Ubuntu 15.04 (Installation not covered in this article)
  • Java JDK (1.8 recommended)
  • Maven
  • Selenium Server
  • Headless browsers
  • Separate Chrome driver
  • Git
  • Jenkins

Java JDK

Installing the Java JDK is simple from the Ubuntu command line.

  1. $ sudo apt-get update
  2. $ sudo apt-get install openjdk-8-jdk

And that is really all there is to it. Once the jdk is downloaded and installed, its time to move onto the next step.


Maven is just as simple to install as the Java JDK was.

  1. $ sudo apt-get update
  2. $ sudo apt-get install maven2

Like before, thats all there is to it. Moving onto the next prerequisite, we will have to do a little bit more work. Its not bad, so its time to roll up our sleeves and dig in.

Selenium Server

  1. Go to:
  2. Select the latest Java version to download
  3. Place the server in a relevant location such as /var/lib/selenium/

That wasn’t too bad now, was it. As we move on, things start to get a little more complicated but I promise you that you can do this; its not as bad as you think.

The headless browsers

The headless browser installation looks a little scary, but its not too bad. I will try to explain each of the steps as best I can as we do them. The commands to enter into the terminal will be first, followed by the explanation.

  1. $ wget -q -O – | sudo apt-key add –wget is a command to go out to the internet and fetch an element. Most often you will see it used to download files from the command line of a terminal. In this case, we are using it to install the public key for the Google apt repository that houses the Chrome web browser. The -q option turns off verbosity to the shell output and the -O concatenates all the information together into one file. In a nutshell, this installs the key to your apt repository. More information
  2. sudo sh -c ‘echo deb stable main > /etc/apt/sources.list.d/google.list’This command adds a line to the local apt repository for the chrome browser to be installed in the next step. It compliments the command from the previous step. The ‘sh’ is the shell command. The -c reads commands from the string instead of from the standard output. The greater than sign (>) is a pointer to write the text ‘debhttp://dl….etc’ to a file. More information
  3. sudo apt-get update && sudo apt-get install -y xfonts-100dpi xfonts-75dpi xfonts-scalable xfonts-cyrillic xvfb x11-apps  imagemagick firefox google-chrome-stableDon’t be intimidated. The command here installs items needed for the browsers to run in headless mode as well as the browsers themselves. The first part of this command (sudo apt-get update && sudo apt-get install -y) is actually two commands put together; apt-get update and apt-get install. The -y answers yes to all confirmation dialogs. The rest of the command is a shopping list of sorts for the apt-get install command; these are the items that will be installed. More information

Chrome driver

Even though we installed Chrome in the previous step, Selenium WebDriver needs to have a separate driver installed to run the Chrome browser. This small file can be downloaded here. Once downloaded, we need to put it in some sort of logical location. I put my copy in a folder called ‘drivers’ in the Jenkins folder (/var/lib/Jenkins). Once the file is safe in its new home, we need to be sure to make it executable. We do this by executing the following command:

  • $ sudo chmod u+x /path/to/chromedriver


Git is a version control system that is used for software development. It has a similar function as SVN, but its an entirely different and lighter-weight system. The technical explanations are outside the scope of this article so I will skip them.

It is important to know that we are not installing the repository itself, but rather the client so that Jenkins can connect to Git and grab the source code we want to test.

Installing Git is as easy as the first two items we installed. It is done in the following manner:

  1. $ sudo apt-get update
  2. $ sudo apt-get install git-core

Now that that is done, it is time to move onto the main course, installing Jenkins.


After having all of our prerequisites installed, we can now install Jenkins.

  1. wget -q -O – | sudo apt-key add –
  2. sudo sh -c ‘echo deb binary/ > /etc/apt/sources.list.d/jenkins.list’
  3. sudo apt-get update
  4. sudo apt-get install Jenkins

I am not going to go into the details of the commands here as they have been explained earlier in this article. If everything was done correctly, Jenkins should now be installed. You can verify this by going to the URL for Jenkins in your favorite browser:

As I mentioned in the opening of this article, I did not know how I was going to end it but now I think this is the perfect place… for now. Look forward to an article in the near future about configuring Jenkins to run automated Selenium tests.

Thanks for reading.