A Humanities Forum panel discussion recorded at UMBC during the Spring semester was featured on the “Marc Steiner Show” on Tuesday, June 5. The topic was “Race and the Civil Rights Movement in Music and Media,” and the discussion featured Derek Musgrove, assistant professor of history; Michelle Scott, associate professor of history; Marc Steiner, host of the “Marc Steiner Show” and Daphne Harrison, emerita professor in Africana Studies and founder of the Dresher Center for the Humanities. The discussion was moderated by Kimberly Moffitt, assistant professor of American Studies.

The full discussion can be heard here. For more information about the Humanities Forum, visit the Dresher Center’s website; the fall 2013 Humanities Forum schedule will be announced soon.

More than twenty years ago, Tulay Adali stepped onto UMBC’s campus as an assistant professor right after receiving her PhD. Much has changed since then.

Now a professor of Computer Science and Electrical Engineering, Dr. Adali runs a highly active Machine Learning for Signal Processing Lab (MLSP­Lab). Her recent appointment as an IEEE Signal Processing Society Distinguished Lecturer has prompted invitations to speak around the world about her research in the theory and development of algorithms for signal processing. This March, Dr. Adali was awarded the University System of Maryland Regents’ Faculty Award for Scholarship, Research, or Creative Activity.

Her secret to success?

“Planning or thinking about the future is not something I do,” said Dr. Adali in her acceptance speech at the Presidential Faculty and Staff Ceremony where she was honored in March. “I rather make sure I enjoy what I do and have fun along the way.” Her technique seems to be paying off. For proof, just take a look at the recognition received by her research in two distinct areas: the development of powerful data­driven methods, and the analysis and fusion of medical imaging data. In 2008, Dr. Adali was elected a fellow of the American Institute for Medical and Biological Engineering (AIMBE). In 2009, the Institute of Electrical and Electronics Engineering (IEEE) elected her a fellow for her work on the theory and practice of statistical signal processing.

In 2011, a paper by Dr. Adali and colleagues titled “Complex ICA using nonlinear functions” received the 2010 IEEE Signal Processing Society Best Paper Award. The work develops a complete framework, allowing for the processing of complex data in a manner similar to the real­valued case, eliminating the need to make many of the simplifying assumptions commonly employed. The results of this NSF­funded study led to the development of a complete data­driven framework that enables joint use of sample dependence and higher­order­statistics.

Dr. Adali’s work in medical image analysis and fusion has also gained notoriety. She has been working on methods for data­driven analysis of medical imaging data, and for the analysis of functional magnetic resonance imaging (fMRI) data for understanding brain function. She and her colleagues discovered that fusing more than two modalities increases the sensitivity and specificity of the analyses of fMRI, electroencephalography (EEG) and structural MRI data. In March 2011, an IEEE Spectrum article mentioned her success in obtaining very high classification accuracy in identifying mental disorders in patients. Then in April 2011, in addition to her ongoing projects funded by the NSF, NIH, and the Mind Research Network, she received a grant from Michelin Research to study irregular wear detection in tires, where the new data-driven framework is applied to a completely new problem domain.

These notable research advances made Dr. Adali stand out as a nominee for this year’s Regents’ Faculty Award for Scholarship, Research, or Creative Activity. It is the highest honor given by the Board of Regents to faculty members, given to faculty members who have gone above and beyond the call of duty. This year, Dr. Adali joins only three other USM faculty members who were recognized for their exceptional research contributions. “Dr. Adali has been steadily building her research career and I am not surprised by the award since her research is remarkable,” says Dr. Carter, CSEE Department Chair. “I see her continuing to grow her research in areas of signal processing for medical applications and becoming a key UMBC faculty member

Another chance to catch the most interesting, and important, articles from the previous week on MIT Technology Review.

PHPUnit has hinted at parallelism since 2007, but, in the meantime, our tests continue to run slowly. Time is money, right? ParaTest is a tool that sits on top of PHPUnit and allows you to run tests in parallel without the use of extensions. This is an ideal candidate for functional (i.e Selenium) tests and other long-running processes.

ParaTest at your Service

ParaTest is a robust command line tool for running PHPUnit tests in parallel. Inspired by the fine folks at Sauce Labs, it was originally developed to be a more complete solution for improving the speed of functional tests.

Since its inception – and thanks to some brilliant contributors (including Giorgio Sironi, the maintainer of the PHPUnit Selenium extension) – ParaTest has become a valuable tool for speeding up functional tests, as well as integration tests involving databases, web services, and file systems.

ParaTest also has the honor of being bundled with Sauce Labs’ testing framework Sausage, and has been used in nearly 7000 projects, at the time of this writing.

Installing ParaTest

Currently, the only official way to install ParaTest is through Composer. For those of you who are new to Composer, we have a great article on the subject. To fetch the latest development version, include the following within your composer.json file:

"require": {
        "brianium/paratest": "dev-master"
    }
    

Alternatively, for the latest stable version:

"require": {
        "brianium/paratest": "0.4.4"
    }
    

Next, run composer install from the command line. The ParaTest binary will be created in the vendor/bin directory.

The ParaTest Command Line Interface

ParaTest includes a command line interface that should be familiar to most PHPUnit users – with some added bonuses for parallel testing.

Your First Parallel Test

Using ParaTest is just as simple as PHPUnit. To quickly demonstrate this in action, create a directory, paratest-sample, with the following structure:

Let’s install ParaTest as mentioned above. Assuming that you have a Bash shell and a globally installed Composer binary, you can accomplish this in one line from the paratest-sample directory:

echo '{"require": { "brianium/paratest": "0.4.4" }}' > composer.json && composer install
    

For each of the files in the directory, create a test case class with the same name, like so:

class SlowOneTest extends PHPUnit_Framework_TestCase
    {
        public function test_long_running_condition()
        {
            sleep(5);
            $this->assertTrue(true);
        }
    }
    

Take note of the use of sleep(5) to simulate a test that will take five seconds to execute. So we should have five test cases that each take five seconds to run. Using vanilla PHPUnit, these tests will run serially and take twenty-five seconds, total. ParaTest will run these tests concurrently in five separate processes and should only take five seconds, not twenty-five!

Now that we have an understanding of what ParaTest is, let’s dig a little deeper into the problems associated with running PHPUnit tests in parallel.

The Problem at Hand

Testing can be a slow process, especially when we start talking about hitting a database or automating a browser. In order to test more quickly and efficiently, we need to be able to run our tests concurrently (at the same time), instead of serially (one after the other).

The general method for accomplishing this is not a new idea: run different test groups in multiple PHPUnit processes. This can easily be accomplished using the native PHP function proc_open. The following would be an example of this in action:

/**
     * $runningTests - currently open processes
     * $loadedTests - an array of test paths
     * $maxProcs - the total number of processes we want running
     */
    while(sizeof($runningTests) || sizeof($loadedTests)) {
        while(sizeof($loadedTests) && sizeof($runningTests) < $maxProcs)
            $runningTests[] = proc_open("phpunit " . array_shift($loadedTests), $descriptorspec, $pipes);
        //log results and remove any processes that have finished ....
    }
    

Because PHP lacks native threads, this is a typical method for acheiving some level of concurrency. The particular challenges of testing tools that use this method can be boiled down to three core problems:

• How do we load tests?
• How do we aggregate and report results from the different PHPUnit processes?
• How can we provide consistency with the original tool (i.e PHPUnit)?

Let’s look at a few techniques that have been employed in the past, and then review ParaTest and how it differs from the rest of the crowd.

Those Who Came Before

As noted earlier, the idea of running PHPUnit in multiple processes is not a new one. The typical procedure employed is something along the following lines:

• Grep for test methods or load a directory of files containing test suites.
• Open a process for each test method or suite.
• Parse output from STDOUT pipe.

Let’s take a look at a tool that employs this method.

Hello, Paraunit

Paraunit was the original parallel runner bundled with Sauce Labs’ Sausage tool, and it served as the starting point for ParaTest. Let’s look at how it tackles the three main problems mentioned above.

Test Loading

Paraunit was designed to ease functional testing. It executes each test method rather than an entire test suite in a PHPUnit process of its very own. Given the path to a collection of tests, Paraunit searches for individual test methods, via pattern matching against file contents.

preg_match_all("/function (test[^\(]+)\(/", $fileContents, $matches);
    

Loaded test methods can then be run like so:

proc_open("phpunit --filter=$testName $testFile", $descriptorspec, $pipes);
    

In a test where each method is setting up and tearing down a browser, this can make things quite a bit faster, if each of those methods is run in a separate process. However, there are a couple of problems with this method.

While methods that begin with the word, “test,” is a strong convention among PHPUnit users, annotations are another option. The loading method used by Paraunit would skip this perfectly valid test:

/**
     * @test
     */
    public function twoTodosCheckedShowsCorrectClearButtonText()
    {
        $this->todos->addTodos(array('one', 'two'));
        $this->todos->getToggleAll()->click();
        $this->assertEquals('Clear 2 completed items', $this->todos->getClearButton()->text());
    }
    

In addition to not supporting test annotations, inheritance is also limited. We might argue the merits of doing something like this, but let’s consider the following setup:

abstract class TodoTest extends PHPUnit_Extensions_Selenium2TestCase
    {
        protected $browser = null;
    
        public function setUp()
        {
           //configure browser
        }
    
        public function testTypingIntoFieldAndHittingEnterAddsTodo()
        {
            //selenium magic
        }
    }
    
    /**
     * ChromeTodoTest.php
     * No test methods to read!
     */
    class ChromeTodoTest extends TodoTest
    {
        protected $browser = 'chrome';
    }
    
    /**
     * FirefoxTodoTest.php
     * No test methods to read!
     */
    class FirefoxTodoTest extends TodoTest
    {
        protected $browser = 'firefox';
    }
    

The inherited methods aren’t in the file, so they will never be loaded.

Displaying Results

Paraunit aggregates the results of each process by parsing the output generated by each process. This method allows Paraunit to capture the full gamut of short codes and feedback presented by PHPUnit.

The downside to aggregating results this way is that it is pretty unwieldy and easy to break. There are a lot of different outcomes to account for, and a lot of regular expressions at work to display meaningful results in this way.

Consistency with PHPUnit

Due to the file grepping, Paraunit is fairly limited in what PHPUnit features it can support. It’s an excellent tool for running a simple structure of functional tests, but, in addition to some of the difficulties mentioned already, it lacks support for some useful PHPUnit features. Some such examples include test suites, specifying configuration and bootstrap files, logging results, and running specific test groups.

Many of the existing tools follow this pattern. Grep a directory of test files and either run the entire file in a new process or each method – never both.

ParaTest At Bat

The goal of ParaTest is to support parallel testing for a variety of scenarios. Originally created to fill the gaps in Paraunit, it has become a robust command line tool for running both test suites and test methods in parallel. This makes ParaTest an ideal candidate for long running tests of different shapes and sizes.

How ParaTest Handles Parallel Testing

ParaTest deviates from the established norm in order to support more of PHPUnit, and acts as a truly viable candidate for parallel testing.

Test Loading

ParaTest loads tests in a similar manner to PHPUnit. It loads all tests in a specified directory that end with the *Test.php suffix, or will load tests based on the standard PHPUnit XML configuration file. Loading is accomplished, via reflection, so it is easy to support @test methods, inheritance, test suites and individual test methods. Reflection makes adding support for other annotations a snap.

Because reflection allows ParaTest to grab classes and methods, it can run both test suites and test methods in parallel, making it a more versatile tool.

ParaTest does impose some constraints, but well-founded ones in the PHP community. Tests do need to follow the PSR-0 standard, and the default file suffix of *Test.php is not configurable, as it is in PHPUnit. There is a current branch in progress for supporting the same suffix configuration allowed in PHPUnit.

Displaying Results

ParaTest also deviates from the path of parsing STDOUT pipes. Instead of parsing output streams, ParaTest logs the results of each PHPUnit process in the JUnit format and aggregates results from these logs. It’s much easier to read test results from an established format than an output stream.

<?xml version="1.0" encoding="UTF-8"?>
    <testsuites>
      <testsuite name="AnotherUnitTestInSubLevelTest" file="/home/brian/Projects/parallel-phpunit/test/fixtures/tests/level1/AnotherUnitTestInSubLevelTest.php" tests="3" assertions="3" failures="0" errors="0" time="0.005295">
        <testcase name="testTruth" class="AnotherUnitTestInSubLevelTest" file="/home/brian/Projects/parallel-phpunit/test/fixtures/tests/level1/AnotherUnitTestInSubLevelTest.php" line="7" assertions="1" time="0.001739"/>
        <testcase name="testFalsehood" class="AnotherUnitTestInSubLevelTest" file="/home/brian/Projects/parallel-phpunit/test/fixtures/tests/level1/AnotherUnitTestInSubLevelTest.php" line="15" assertions="1" time="0.000477"/>
        <testcase name="testArrayLength" class="AnotherUnitTestInSubLevelTest" file="/home/brian/Projects/parallel-phpunit/test/fixtures/tests/level1/AnotherUnitTestInSubLevelTest.php" line="23" assertions="1" time="0.003079"/>
      </testsuite>
    </testsuites>
    

Parsing JUnit logs does have some minor drawbacks. Skipped and ignored tests are not reported in the immediate feedback, but they will be reflected in the totaled values displayed after a test run.

Consistency with PHPUnit

Reflection allows ParaTest to support more PHPUnit conventions. The ParaTest console supports more PHPUnit features out of the box than any other similar tool, such as the ability to run groups, supply configuration and bootstrap files, and log results in the JUnit format.

ParaTest Examples

ParaTest can be used to gain speed in several testing scenarios.

Functional Testing With Selenium

ParaTest excels at functional testing. It supports a -f switch in its console to enable functional mode. Functional mode instructs ParaTest to run each test method in a separate process, instead of the default, which is to run each test suite in a separate process.

It’s often the case that each functional test method does a lot of work, such as opening a browser, navigating around the page, and then closing the browser.

The example project, paratest-selenium, demonstrates testing a Backbone.js todo application with Selenium and ParaTest. Each test method opens a browser and tests a specific feature:

public function setUp()
    {
        $this->setBrowserUrl('http://backbonejs.org/examples/todos/');
        $this->todos = new Todos($this->prepareSession());
    }
    
    public function testTypingIntoFieldAndHittingEnterAddsTodo()
    {
        $this->todos->addTodo("parallelize phpunit tests\n");
        $this->assertEquals(1, sizeof($this->todos->getItems()));
    }
    
    public function testClickingTodoCheckboxMarksTodoDone()
    {
        $this->todos->addTodo("make sure you can complete todos");
        $items = $this->todos->getItems();
        $item = array_shift($items);
        $this->todos->getItemCheckbox($item)->click();
        $this->assertEquals('done', $item->attribute('class'));
    }
    
    //....more tests
    

This test case could take a hot second if it were to run serially, via vanilla PHPUnit. Why not run multiple methods at once?

Handling Race Conditions

As with any parallel testing, we have to be mindful of scenarios that will present race conditions – such as multiple processes trying to access a database. The dev-master branch of ParaTest sports a really handy test token feature, written by collaborator Dimitris Baltas (dbaltas on Github), that makes integration testing databases much easier.

Dimitris has included a helpful example that demonstrates this feature on Github. In Dimitris’ own words:

TEST_TOKEN attempts to deal with the common resources issue in a very simple way: clone the resources to ensure that no concurrent processes will access the same resource.

A TEST_TOKEN environment variable is provided for tests to consume ,and is recycled when the process has finished. It can be used to conditionally alter your tests, like so:

public function setUp()
    {
        parent::setUp();
        $this->_filename = sprintf('out%s.txt', getenv('TEST_TOKEN'));
    }
    

ParaTest and Sauce Labs

Sauce Labs is the Excalibur of functional testing. Sauce Labs provides a service that allows you to easily test your applications in a variety of browsers and platforms. If you haven’t checked them out before, I strongly encourage you to do so.

Testing with Sauce could be a tutorial in itself, but those wizards have already done a great job of providing tutorials for using PHP and ParaTest to write functional tests using their service.

The Future of ParaTest

ParaTest is a great tool for filling in some of the gaps of PHPUnit, but, ultimately, it’s just a plug in the dam. A much better scenario would be native support in PHPUnit!

In the meantime, ParaTest will continue increasing support for more of PHPUnit’s native behavior. It will continue to offer features that are helpful to parallel testing – particularly in the functional and integration realms.

ParaTest has many great things in the works to beef up the transparency between PHPUnit and itself, primarily in what configuration options are supported.

The latest stable version of ParaTest (v0.4.4) comfortably supports Mac, Linux, and Windows, but there are some valuable pull requests and features in dev-master that definitely cater to the Mac and Linux crowds. So that will be an interesting conversation moving forward.

Additional Reading and Resources

There are a handful of articles and resources around the web that feature ParaTest. Give them a read, if you’re interested:

• ParaTest on Github
• Parallel PHPUnit by ParaTest contributor and PHPUnit Selenium extension maintainer Giorgio Sironi
• Contributing to Paratest. An excellent article on Giorgio’s experimental WrapperRunner for ParaTest
• Giorgio’s WrapperRunner Source Code
• tripsta/paratest-sample. An example of the TEST_TOKEN feature by it’s creator Dimitris Baltas
• brianium/paratest-selenium. An example of using ParaTest to write functional tests

So you found an internship, Now what?

Full article found HERE.

First, it should be noted that internship opportunities come in a variety of flavors.  Some are part-time; some are full-time.  Some are paid and some (most) are unpaid.  You might be helping out in the office, doing “whatever”–like copying, delivering documents, or data entry.  Some are resume builders; some are not, but bring in some spending cash while in college.  Or you might be doing more specific meaningful work such as analyzing samples in a lab, updating web content, or helping out on a technical report.

So, beyond the paycheck (if any), the following are my 10 target behaviors and outcomes:

(1)  Create a positive first and ongoing impression: The end game here is to gain a professional reference, obtain a letter of recommendation or blurb on LinkedIn, and have a quality resume entry.  You earn these through punctuality and presenting a professional appearance each day.  Be careful what you wear.  Yes, it’s summer.  But before you leave the house, remember that you are not going to the beach or sunbathing on the campus Quad.  If you are not certain about the dress code, ask your boss or someone in HR.  Keep your work space clean and organized and don’t be seen texting or using technology for personal purposes while on-the-clock.  Updating your Facebook status can wait until you get home. (keeping point #8 below in mind)

(2)  Deliver: Here you want to make sure that you complete any assignments, whether easy or complex by the deadlines.  “The dog ate my homework” (or its digital version) will not resonate here.

(3)  Don’t be high maintenance: You obviously want to do a good job.  Try to take notes on what is expected of you from the outset.  When questions arise while you are performing a task, don’t ask your supervisor questions every two minutes.  To the extent possible, “bank” your questions and move on to the next part.  Then, before the deadline, present your questions in batch mode in order to be able to complete the assignment correctly.

(4)  Expect downtime:  Not all internships are structured.  In many cases, the longer an organization has had an internship program on the books, the more organized it will be.  But oftentimes, the placement of an intern is new for an organization and staff is unprepared to mentor or supervise.  That being the case, fill any gaps in your day with offering to help others with something specific.  Try to learn the behavior patterns and needs of others so that you know exactly how you might be helpful.  If you are really proactive, you consider doing some industry relevant research and creating a white paper to present to your supervisor.

(5)  Log:  In some cases, you will be ask to write a weekly update or submit an end-of-stint report for course credit.  So, keep a running log of your activities including dates and what your contribution was.  That will help you later on in terms of recall and capture what you did there on your resume.

(6)  Skills: Try to identify 2-3 skills that you did not already have which you can work on developing before the end of your assignment.  If there are any opportunities for you to attend a training workshop, ask if you can take advantage of those.  There might also be some areas in which you could be cross-trained that are beyond the narrow scope of the department in which you are initially assigned. If and when you have a chance to sit in on a meeting, try to observe what leaders or successful people say and do.

(7)  Data Protection: In some cases, you might be working on a proprietary project or otherwise have access to sensitive data.  You might also be given opportunities to do some of the work remotely.  The last thing you want is to leave your MacBook in your favorite Starbucks, never to be seen again.  If you copied a spreadsheet which contained credit card account info or Social Security numbers, your organization might very well be in the headlines on CNN tomorrow morning.

(8)  Be discreet: When you get home, don’t feel compelled to Tweet “my supervisor’s wardrobe is SO 90’s! LOL!” or update your Facebook status with “another day at the office–bored out of my gourd!”.  So, if you have posted to social media that your fashioned-challenged boss needs to get with the program, a recruiter may not look at you as a compelling candidate.  Posting a picture on Instagram of Joe asleep in his cubicle might be funny to your BFFL’s now.  But, it won’t be hysterical to Joe when after gets fired and you have to face him while he’s cleaning out his desk next week.  Remember, the Internet does not forget!

(9)  Know your place: Remember to be polite and respectful of others.  Note that the workplace is diverse in terms of gender, generational cohorts, and other factors.  Try to pick up on cues as to the most appropriate ways to communicate with and address others.  This goes for both verbal and nonverbal communication.  Some prefer or deserve more formal titles like ‘Mr.’, ‘Ms.’, or ‘Dr.’.  Try to fit in, but don’t make yourself too comfortable.  Respect the boundaries and space of others.  Remember that you are just a student and only there for a couple of months.

(10)  End on a high note: As you are concluding the term of your summer internship, make sure to demonstrate your appreciation for the opportunity.  Thank your boss, mentors, or other co-workers who helped you.  A handwritten card is a small token that will go a long way in their remembering you.  It is often the small things you did to be helpful or gestures of gratitude.  You might also want to ask whether those with whom you worked would be willing to connect on LinkedIn, write you a recommendation, or keep in touch for when you are looking for a real job.  Your summer internship placement might in fact be the best prospect for your first job out of college.