Friday, August 30, 2013

HomeBrew: Installing right software to Mac OS X

Mac OS X can behave polite - one can install required software using HomeBrew http://brew.sh/

Homebrew installs the stuff you need that Apple didn't.
brew install wget

For example, let's prepare our Mac OS X for Jenkins CI

brew install  -v --devel --build-from-source --fresh wget automake autoconf libtool libzip pkg-config libimobiledevice



HtmlUnit and HtmlUnitDriver

Cool stuff. Give it a try later on, not for testing but just for some apps purposes.

HtmlUnit

This is a Java framework for testing webapps. It's a wrapper around the Jakarta HttpClient and provides a more friendly API. The project is hosted athttp://htmlunit.sourceforge.net/

HtmlUnit Driver

This is currently the fastest and most lightweight implementation of WebDriver. As the name suggests, this is based on HtmlUnit.

Pros

  • Fastest implementation of WebDriver
  • A pure Java solution and so it is platform independent.
  • Supports Javascript

Cons

  • Emulates other browser's JS behaviour (see below)

Javascript in the HtmlUnitDriver

None of the popular browsers uses the javascript engine used by HtmlUnit (Rhino). If you test javascript using HtmlUnit the results may differ significantly from those browsers.
When we say "javascript" we actually mean "javascript and the DOM". Although the DOM is defined by the W3C each browser out there has its own quirks and differences in their implementation of the DOM and in how javascript interacts with it. HtmlUnit has an impressively complete implementation of the DOM and has good support for using javascript, but it is no different from any other browser: it has its own quirks and differences from both the W3C standard and the DOM implementations of the major browsers, despite its ability to mimic other browsers.
With WebDriver, we had to make a choice; do we enable HtmlUnit's javascript capabilities and run the risk of teams running into problems that only manifest themselves there, or do we leave javascript disabled, knowing that there are more and more sites that rely on javascript? We took the conservative approach, and by default have disabled support when we use HtmlUnit. With each release of both WebDriver and HtmlUnit, we reassess this decision: we hope to enable javascript by default on the HtmlUnit at some point.

Enabling Javascript

If you can't wait, enabling Javascript support is very easy:
HtmlUnitDriver driver = new HtmlUnitDriver();
driver.setJavascriptEnabled(true);
or
HtmlUnitDriver driver = new HtmlUnitDriver(true);
This will cause the HtmlUnitDriver to emulate IE's Javascript handling by default.

Emulating a Specific Browser

Notwithstanding other considerations above, it is possible to get HtmlUnitDriver to emulate a specific browser. You should not really be doing this, as web-applications are better coded to be neutral of which reasonably recent browser you are using. There are two more constructors for HtmlUnitDriverthat take allow us to indicate a browser to emulate. One takes a browser version directly:
HtmlUnitDriver driver = new HtmlUnitDriver(BrowserVersion.FIREFOX_3);
The other uses a broader capabilities mechanism:
HtmlUnitDriver driver = new HtmlUnitDriver(capabilities);

srcs:
https://code.google.com/p/selenium/wiki/HtmlUnit
https://code.google.com/p/selenium/wiki/HtmlUnitDriver

Start process, get PID of just started process, and terminate the process by PID later

Ok, let's say we have a usecase - a job on Jenkins CI that needs to start a background process, remember PID of the process, pass the PID to some later cleanup. And we need something that will work on Linux and on Mac OS X (yes, even this OS can behave polite).

So 1st, let's start a process and remember it's PID. This is done via $! shell environment variable. The $! variable will have PID of latest started process. So here is an example:

nohup tail -f /var/log/syslog > /tmp/$BUILD_TAG.log & export LOGGER_PID=$! 
# $BUILD_TAG - is an environment variable provided by Jenkins CI, it has unique job execution identifier

2nd, let's remember the PID

echo -e "LOGGER_PID=$LOGGER_PID" > /tmp/$BUILD_TAG

3rd, let's use the PID and send SIGTERM to the process if it is still alive. We'll wrap it to a shell script.

#!/bin/bash
. /tmp/$BUILD_TAG  # read to LOGGER_PID env variable

kill_proc(){

  local pid_alive=`ps ax| awk '{print $1}' | grep -e "^$LOGGER_PID$" >>/dev/null; echo $?`;
   # ps ax| awk '{print $1}' - will print to stdout PIDs without surrounding spaces
   # grep -e "^$LOGGER_PID$" >>/dev/null; - will search for the PID, ^ and $ are important, just in case our PID is a substring of some other PID on system
   # echo $? - will echo exit code of last command
  if [ $pid_alive -eq 0 ]; then 
    kill $LOGGER_PID; # sending  SIGTERM to the process
    sleep 10;
  else
    echo "Proc with PID $LOGGER_PID already terminated" 
  fi;  
}

kill_proc;




Thursday, August 29, 2013

Configure log-level of messages sent to console

To configure log-level of messages sent to console one can do as it said in /etc/sysctl.conf

# Uncomment the following to stop low-level messages on console
kernel.printk = 3 4 1 3

The four values in kernel.printk denote:
  • console_loglevel
  • default_message_loglevel
  • minimum_console_loglevel
  • default_console_loglevel respectively.
Following log levels are valid (man syslog):

#define KERN_EMERG    "<0>"  /* system is unusable               */
#define KERN_ALERT    "<1>"  /* action must be taken immediately */
#define KERN_CRIT     "<2>"  /* critical conditions              */
#define KERN_ERR      "<3>"  /* error conditions                 */
#define KERN_WARNING  "<4>"  /* warning conditions               */
#define KERN_NOTICE   "<5>"  /* normal but significant condition */
#define KERN_INFO     "<6>"  /* informational                    */
#define KERN_DEBUG    "<7>"  /* debug-level messages             */