How I came up using logical relationships describing my problem-domain


I have end of last year (2016) started working part of my time as release manager with the regular duty of building software artifacts out of legacy Java EE Components (web applications, web services, batches).

 There are a number of tools which we use to:
  • build and release software, namely Maven, Jenkins and Nexus
  • define clusters and their properties for our applications to be deployed on
  • check or adapt the apps configuration, then deploy the software artifacts
  • monitor the deployed applications
Each of these functions implies working with a different toolset, which implies a lot of user navigation in complex directory structures, file systems or web hierarchies, with either an IDE
such as Intellij, a directory/web browser, or by using tools like Git or BitBucket.

 Facing this complexity of information can at times be challenging, given that:
  • our build system and toolset undergo regular changes
  • the effort of navigating the information cannot be easily automated, since the tools are specialized into one problem domain, where navigation is typically only possible in one direction e.g. “top-down”: open a software project with the IDE, navigate to the appropriate resources, locate the specific parts to be reviewed or amended
  • many applications have to be maintained in parallel in a consistent manner
  • there is a natural tendency to forget actual answers to the question: “where is that stuff actually configured” ?
I have then started defining Prolog(*) predicates for most of our abstractions, such as:
  • application
  • application jar file
  • application parameter
  • application deployment street (family of clusters where an application gets deployed)
  • deployment cluster
and within 1000 lines of code been able to come up with a usable workbench to navigate and interact (via queries in the Prolog console) with our system in a repeatable manner.

 Most important is the fact that Prolog predicates enable me to navigate the information in whichever ways I want to, since the predicates can be used in one or the other direction with no problem at all: most often in my work is some “bottom-up” navigation required to identify which applications are actually concerned by a software or configuration change.

 Another aspect is that all these predicates can be combined on the spot with no effort at all, to perform complex queries such as:

 “What clusters will be impacted if I change the version of a jar file due to a software fix ?”

 This question implies navigating through these relations

 application jar file > application > application deployment street > deployment cluster

 Both aspects involve a lot of work if using a separate set of tools.

 I will in the spirit of this blog start a set of articles covering aspects of Prolog development which I found most useful and not being properly covered elsewhere.

 Happy reading !

 (*) with SWI Prolog: http://www.swi-prolog.org

Comments

Post a Comment

Popular posts from this blog

A possible solution for using the janus interface on MacOS with docker

 Experimenting with the Janus module on docker Janus is a new development that comes with swi-prolog version 9:  janus documentation Having attempted to run the example in the above link, I tried the following steps to install and use the spacy python package: pip install spacy docker run -it --rm --network host -v $(pwd):/opt/janus\ -v /path/to/python3.11/site-packages:/opt/python\ swipl ?- consult('/opt/janus/test_janus.pl'). ?- py_add_lib_dir('/opt/python'). ?- noun("This is a sentence.", Noun). ERROR: Python 'ImportError': ERROR: Error importing numpy: you should not try to import numpy from its source directory; please exit the numpy source tree, and relaunch your python interpreter from there. ERROR: Python stack: ERROR: File "/opt/python/spacy/__init__.py", line 6, in module ERROR: from .er...
Read more

Meaningful Xml Diffs with SWI-Prolog

Introduction Building on the previous article I wrote on using the SWI Prolog Xpath predicate for analyzing Xml Node Set relationships, I now describe a way to produce a tree oriented diff based on similar techniques. The goal of such a diff is to identify objects of 2 Xml trees which differ by a given sub-node. In a sense is that diff not a fully general diff, as it focuses on 2 or 3 levels: object sub-or-descendant node resp. property when required, property of the sub-or-descendant node specified by the user, within the Xml tree structure. Another important goal of this diff is to be able to accommodate a different ordering of these objects in the Xml structure, which is normally a constraint which most editors or developer tools can’t cope with. In the following sections I will again use a similar fictitious tree example as in the precedent article. Resources for this article Prolog source code and XML examples are available on  [github] ...
Read more

Prolog DCG "distilled" - Part 3 - Capturing and assembling textual elements from rules

Image
Capturing and assembling textual elements from rules This article builds on the previous ones, featuring a small parser for Org Mode files. I use the Clocking feature of emacs to capture how long I work on specific tasks.  However from time to time,  I have to aggregate data over several files, on a monthly or yearly basis, and this is where the small tool described here can prove useful. The code and tests for this article may be found [ here ]. One of the tests may be run in SWI-Prolog with those steps:                ?- consult('/path/to/clocking_tool.pl').                true.             ?- test_parse_clock(Start, End, Elapsed).             Start = [2020-2-5, 16:6:0], End = [2020-2-5, 17:26:0], Elapsed = 1:20 ;             false. A version for Tau-Prolog can be found  [he...
Read more