24 May 2016

Fixing "resource modena.css not found" in SBT

I have a project that is building a system in Scala. Its GUI is being defined using the ScalaFX system, which is a thin layer that delegates to the underlying JavaFX tools, components and features.

The application was running with a fine-looking GUI in early testing, but all the builds were being driven by the IDE. For various reasons, we wanted to migrate the build to the SBT system.

But upon launching with
$ sbt run
we would get entries like this in the console:
[info] Running StartHere
May 21, 2016 8:50:28 PM com.sun.javafx.css.StyleManager loadStylesheetUnPrivileged
WARNING: Resource "com/sun/javafx/scene/control/skin/modena/modena.css" not found.

The application would compile without issue and would run correctly, but looked terrible. For instance there would be no edges visible for buttons or for text box input fields.

Obviously, a dependency was missing from the build.sbt file. It was easy enough to add, with a line like the following:
unmanagedJars in Compile += Attributed.blank(file(System.getenv("JAVA_HOME") + "/lib/ext/jfxrt.jar"))

With that in place, the code continued to compile without issues, and the run no longer contained the warning. And since the basic stylesheet was now being found at runtime, the GUI once again looked like it should.

18 May 2016

TinT: Composition vs Inheritance vs Unit Testing

This episode of Testing in the Trenches describes, with appropriate modifications to protect the parties involved, a unit-testing situation I encountered on a client's project.

One question I was asked in a job interview some number of years ago was: "For code reusability, which is better: Inheritance or Composition?"

As I recall from the interview, I chose one - in my case, Inheritance - and defended my choice: there is conceptual power in defining higher-level, common traits and behaviors higher up the hierarchy, and re-using it in its sub-classes, or overriding and refining it when more specific behavior is required. Or something like that.

It was obvious from my interviewer's reaction that he was not impressed with my answer. And I have occasionally wondered, in hindsight, if I should have not chosen either, but talked about both and shown my grasp of both concepts. That might have been the better interview technique.

After all, a couple years later, with more time on a handful more Object-oriented projects, I had developed a different answer to that question. Now I would say, "it depends on the situation."

If one class is a proper sub-class of another, that is, if it is a more specific kind of the other thing, Inheritance makes sense. Think "Is-A" when describing their relationship. An apple is a kind of Fruit; a RedDelicious is a kind of Apple. The ability to define, at the Fruit level, behavior common to all fruits, is a powerful feature of the Object-Oriented programming paradigm.

On the other hand, when one class is a piece of another class, when one is a component part of the other, then Composition makes sense. Think "Has-A" when describing their relationship. A FruitBasket has a RedDelicious in it. One would not expect RedDelicious behavior to have any inherent relationship to that of the FruitBasket. A good abstraction of the problem domain would relate them through Composition. The code reuse of my interview question would come through the proper encapsulation of data and behavior in the right places of the system.

On the third hand, for the three-handed among us, if the two classes come from different problem domains, even if they share some surface similarities, then Composition again likely makes the most sense. A class defined in solving one problem should most likely not inherit from a class that solves a different problem. So in an Education sub-system, ClassList might be better related to the ArrayList data structure by Composition rather than Inheritance. At the very least, Composition would give ClassList access to the public API of ArrayList, but would allow it to define its own API specific to its problem domain, and for its own clients.


13 May 2016

Windows .BAT Script to launch task, then loop until done

My last post described my discovery of the Windows Schtasks.exe utility to trigger via the command-line a scheduled task on a local or - more relevant to the challenges I was facing - on a remote server. I described its ability to query the state of the task, and to launch it.

Of course, since my whole purpose was to automate a tedious manual section of our build process, Schtasks.exe is helpful but hardly the end of the story.

To benefit from that new knowledge, I now need to create a Windows shell script that our Continuous-Integration tool Jenkins can launch. This post is almost a stream-of-consciousness blog as I play with this problem.

The requirements are that the script launch the remote scheduled task, poll its status until it is complete, and end with an appropriate result code. Some minimal logging of activity would also be nice.

To begin, I created a .BAT file and created a labelled section to trigger the remote task:
:LaunchBuild
REM  QUESTION: What if it is already running? Should we wait? Abnormal-end? Skip?
schtasks /run /s MyRemoteServer /tn MyBuildTask

11 May 2016

Trigger Windows Scheduled Task from Remote Computer via Jenkins

One thing I love about working in Information Technology is the opportunity - the NEED - to constantly learn new things. If a week goes by in which I have not looked up something on StackOverflow or other message boards, I start lobbying my team for more challenges.

This week, I learned the power of running "SCHTASKS.exe" from a command-line script for a remote server in a Microsoft Windows environment.

If you don't know Schtasks, you can read up on it here: https://msdn.microsoft.com/en-us/library/windows/desktop/bb736357(v=vs.85).aspx

In a nutshell, it is the command-line interface for the Windows Task Scheduler, and allows you (or a system administrator) to create, change, run, query, terminate, and delete scheduled tasks on a work-station, either the local one or a remote one.

Not all of the features are available in older versions. In my scenario below, this was relevant as the local computer will be a Windows 8 machine, and the remote server is, shall we say, a much older Windows version. So check the documentation carefully for older versions.

Using Schtasks, we can launch an existing scheduled task on a remote computer with:
schtasks /run /s MyRemoteServer /tn MyScheduledTaskName

The parameters are reasonably straight-forward:

4 May 2016

TinT: Avoiding User Interactions

This episode of Testing in the Trenches describes, with appropriate modifications to protect the parties involved, a situation I encountered on a client's project that challenged our efforts to create a suite of automated unit tests and what we did about it. It is adapted from one of the internal Tips that I regularly sent to the team.

One of the key goals in unit testing is that we can run the suites of tests quickly. When the tests run in just a handful of seconds, we get fast feedback when issues arise. It is easier and safer to resolve those issues when the developer's mind is still on the problem they were working on.

And tests that run quickly are less of a perceived interruption to the work of a test-averse developer. This increases the odds that the developer will adopt the practice of running the test suite before committing their code.

But a run of tests comes to a complete halt when user interaction is required. For example, a path through the code that creates a pop-up message box brings the test run to a halt. None of the tests can proceed until they receive user input.

How can we write our unit tests to be independent of user interaction? It is tough when we want to test code that looks like this:

if ( myFile.getPath().length() > uiFields.getField(downLoadFileFN).getMaxWidth() )
{
   JOptionPane.showMessageDialog(getFrameInFocus(),
      "The selected path exceeds the width of the entry field.\n"
      + "Please select a different path."
      "Error",
      JOptionPane.ERROR_MESSAGE);
   doSomethingHere();
}

It may be an important condition in our logic, one that really needs to be covered by one or more unit tests. But as soon as a test fulfills the if-condition, a warning box pops up and everything pauses until it is dismissed. That is, of course, the behavior we want in production, but it is not helpful in automated testing.