29 June 2016

Object-Oriented Trinity - Part 3

I currently make a living as a Software Engineer, and I am also an ordained Anglican priest. In seminary, one assignment was to write a letter to a fictional friend, explaining the Trinity in some creative imagery.  My paper sought to use Object-Oriented concepts to shed light on this great mystery of faith. This is third in a 3-part series of posts that somewhat adapts that 2005 paper to the different medium of a Blog, and to refine with my understanding as it stands now of both the Trinity and Object-Oriented programming and design.

The first part is HERE.
The second part is HERE.

Hey Christian, I'm glad to hear that you are dazzling your new company with your brilliance.

So you think something is incomplete in our discussion so far about the Trinity and Object-Oriented design? You're right. The doctrine of the Trinity says that God Almighty is both One and Three, at the same time, and we have left a third out completely so far.

The Trinity's third Person is the “Holy Spirit.” This is not the divine “soul” or a euphemism for God’s actions, or thoughts, or inner being; if that were the case, it would not make sense to call this a Person. Christians claim that the Holy Spirit is sent forth from God. It is a personal, knowable, active agent, not an impersonal cosmic force like in Star Wars, and therefore is a Person in its own right. Some of the actions of this third Person are to speak, prompt, and teach us, and to unite us with God. The Spirit must be divine, as the Father and the Son are divine, and not just a creation or an abstraction – how else would it be able to join us to God?

22 June 2016

Object-Oriented Trinity - Part 2

If you have read my limited Bio information, you may have noticed that I am a Software Engineer and also an ordained Anglican priest.

In seminary, one assignment was to write a letter to a fictional friend, explaining the Trinity in some creative imagery. The doctrine of the Holy Trinity is and to some extent has always been one of the more numinous and abstruse in Christianity.

My paper sought to use Object-Oriented concepts to shed light on this great mystery of faith. This is second in a series of posts that somewhat adapts that paper to this different forum, and to my understanding as it stands now of both the Trinity and Object-Oriented programming and design. The first part is found here.

Hi Christian! The last time I wrote, I used the Object-Oriented design pattern of the Singleton to look at the Trinity and its claim that God is One. But as you rightly point out in your reply, that barely scratched the surface of the doctrine of the Trinity. Let's go deeper.

20 June 2016

Reusing UI Sections in FXML and Scene Builder

If the DRY principle (Don't Repeat Yourself) is a core Best Practice in Object-Oriented Programming and software development, is there any way to define common user interface sections of an application in FXML? Can we avoid repeating the work that goes into laying out and controlling sections that are common across across many or even all screens?

It would be beneficial and more consistent if their layout could be defined once and reused wherever necessary. Rather than redefine a menu bar or a collection of buttons on multiple screens, create them once and apply them as needed.

Of course, this approach is nothing new. But as I explored JavaFX as a User Interface toolkit, it was straight-forward how to do this in code, but it was less clear how to do so using FXML.

To speed up user interface development, we want to use the JavaFX layout manager Scene Builder. I am using v8.2 from Gluon - thank you Gluon for backing this important tool!

15 June 2016

Object-Oriented Trinity - Part 1

If you have read any of my limited Bio information, you may have noticed that I am a Software Engineer. It was my first career, from which I took a hiatus for about a decade to do other things. One of those other things was becoming an ordained Anglican priest.

I was recently reminded of a somewhat whimsical paper I wrote in seminary, while working on my MDiv and preparing for the priesthood.

Our assignment was to write a letter to a fictional friend, explaining the Trinity in some creative imagery. The doctrine of the Holy Trinity is and to some extent has always been one of the more gnarley in Christianity.

Drawing on my first career of software development, my paper sought to use Object-Oriented concepts to shed light on this great mystery of faith. In a series of posts (Three would be the right number, no?), I will somewhat adapt that paper to this different forum, and to my ever-growing and evolving understanding of both the Trinity and Object-Oriented programming and design. Hopefully you will find this exercise somewhere between amusing and thought-provoking.

8 June 2016

Adding Items to a ListView using Scala, ScalaFX and FXML

I have been playing with writing an application using Scala, with its API defined in ScalaFX, which wraps the powerful JavaFX library. For simple exercises, coding the UI by hand was enough. But for more complex forms, I began using the JavaFX Scene Builder tool.

Fortunately, others have blazed this trail, and there are fairly stable ScalaFX and ScalaFXML libraries available.

Using the Scene Builder tool, I laid out my form and included a ListBox to hold possible gender selections.

The Scene Builder tool generated fxml code such as:
<AnchorPane maxHeight="-Infinity" maxWidth="-Infinity" minHeight="-Infinity" minWidth="-Infinity" prefHeight="208.0" prefWidth="275.0" xmlns="http://javafx.com/javafx/8" xmlns:fx="http://javafx.com/fxml/1">
   <children>
      <Label layoutX="14.0" layoutY="30.0" text="Name" />
      <Label layoutX="14.0" layoutY="71.0" text="Gender" />
      <TextField fx:id="name" layoutX="95.0" layoutY="26.0" />
      <ListView fx:id="genderOptions" layoutX="95.0" layoutY="71.0" prefHeight="70.0" prefWidth="149.0" />
   </children>
</AnchorPane>

That lays out the user interface. Now I need a Controller (if you like MVC) or Presenter (if you prefer MVP) class. I specified the class in the usual way in the fxml file, and created the Scala class to match. It looked like this:
@sfxml
class SimpleFormPresenter (
   private val name: TextField,
   private val genderOptions: ListView[String],
   private val myDependency:MySimpleFormDependency) { 
 ...
}

The @sfxml annotation triggers the ScalaFXML tool's macros to do the magic bridging between Scala, JavaFX, and FXML. We'll leave more information about that whole process for another day.

2 June 2016

TinT: Metaphors for Test Types

Testing in the Trenches (TinT) is an occasional series recounting some of the experiences I have had as a Unit Testing evangelist on various projects. Where appropriate, any references to actual details have been sanitized to protect the participants. This post is adapted from a regular email that I sent to the team, to promote and educate about testing. I secretly called these my Unit Test Propaganda Messages.

For a while now, I have been promoting among the team the idea of automated testing, especially Unit Testing, as a means to improve both our lives as developers and our software for our clients.

Recently, I was listening to a Software Engineering Radio podcast, and the speaker mentioned seven different kinds of automated testing that they do in his organization. The speaker was Mike Barker, talking about his work on the LMAX architecture, and the seven kinds of automated testing he named (around the 50-minute mark) were:

  1. Unit Tests, 
  2. Integration Tests, 
  3. Acceptance Tests, 
  4. Performance Tests (End-to-End), 
  5. Performance Tests (Micro-Benchmarks), 
  6. Static Analysis, and 
  7. Database Tests.

It got me thinking about our own environment, practices, and needs. What kinds of testing do we do? What are the benefits of automating them or not? Some of these are the responsibility of developers, others may be more for the QA team. Sometimes there is confusion about what each kind of test is and does, so let's unpack Barker's list. Since he did not go into detail about the definitions of the different types, I will add some context.

And of course other lists of essential kinds of automated tests will include different types in the list, such as GUI Tests, Regression Tests, Input/Output Tests, etc. We will leave them for another day.

To help understand the differences, let's use this metaphor: imagine the system we are building is the human body. We have to assemble all of our code to create the internal structures and sub-systems, and wrap the whole together into the publicly-visible skin, hair, etc.

Unit Testing - this is the kind of test that I promote most vigorously in our team. These are developer-written and developer-maintained tests that validate the functionality at the code level. They test small units of code - a method, a function, a component, a process, object-level behavior and state. They are so-called White-Box tests, meaning the developer can use their knowledge of the inner workings to shape their tests.

Unit Tests do add a little time to the programming task, but they save so much time in so many other ways, which speeds up the overall development process:

  1. they give quick feedback if your code is not working as expected; 
  2. they create localized regression tests to guarantee against broken or changed functionality; 
  3. they document existing and expected behavior;
  4. they provide confidence when refactoring toward a better design. 

A good unit-test suite gives developers confidence that their changes work and that they do not break or change other behavior, and because they are fast and targeted, they should be run by the developers many times a day.

We use jUnit as the framework to build and run our automated unit tests. It is not the only unit-testing framework, but is ideally suited to the task and is widely used in the industry.

In our human-body metaphor, unit tests would verify all of the little activities, such as: does the index finger curl up when you contract the outer two knuckles? what are the limits of the range of motion of the thumb? does the wrist move according to all expected degrees of freedom?

Integration Testing - these tests gather several units and test that they function together through their interfaces as expected and designed. They usually skip the user-interface portion, and test directly the integration of the components that do the work requested by the user. In our code base, too often the different tasks and units are so tangled together that it can be hard to isolate a unit to test it by itself. Some blocks of code depend too closely on the database or the GUI or other classes. As a result, we often quake fearfully in the face of the effort to create unit tests, throw up our hands, and move to a higher level of testing.