SJGP Software

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 t

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.

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!

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

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" l

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: Unit Tests,  Integration Tests,  Acceptance Tes