function_missing # lost in complexity

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 au...

Synopsis Given the complexity of the stack described in my previous post, things did not quite go into linear fashion. However as far as GODI itself is concerned, I just had to overcome a single hurdle for its installation on my system. The rest of the process was surprisingly smooth. Getting the GODI distribution From the GODI homepage I downloaded godi-rocketboost-20080630.tar.gz (which is the version including Ocaml 3.10.2) and unpacked it under my 'Ocamel' directory. As this software is not installed via 'wizard', one needs to read the README file first. In the section 'Requirements', it is clearly explained that the installation requires the GNU gcc compiler (which is best provided by the Xcode package engineered by Apple) and also other UNIX tools such as GNU make (which on my Mac is provided by Fink ). As I had already Fink installed on my Mac, the only additional step before starting the Ocaml installation was to install a Tiger-compatible version of...

Although OCaml is available as binary packages for Mac OS X, the problem is that this kind of distribution cannot easily be complemented by various packages available from the Caml Hump (an Ocaml equivalent of CPAN for Perl). This is fine as long as one only wants to experiment with the language. Beyond this, any work involving some pragmatic issues such as database persistence or internationalization, needs to be based one way or another on the functionality offered by the standard packages provided by the Ocaml community. An example of this is the Camomile library, which is the de-facto standard to handle Unicode characters in Ocaml, yet is not included in the standard Ocaml distribution. As opposed to Java, there is no simple way to drop a library (such as a jar file) in some agreed directory. The current Ocaml ecosystem relies on a source based package being built, compiled, tested, and installed into the Ocaml environment, in a fashion similar to Perl 5. Depending on the specifi...

Out of curiosity I picked in 2007 this rather dense book in the IT corner of a Toulouse book shop: "Programmation fonctionnelle, générique et objet" from P. Narbel (unfortunately for English readers this is only available in French...and also it now seems out of print). The book focuses on the concepts of functional programming, using Ocaml as a platform to experiment with. This approach, starting from the concepts and showing their application with small code examples, is clearly very didactic. Having digested most of this material over several months, I said to myself : "why not try it out and use Ocaml on a personal project ?", having in mind to create a tool to assist with the learning of the Japanese language. This is where things got rather complicated...but at the same time enlightening... Having worked for 2 decades using imperative programming languages (C, Perl, Java, JavaScript), my recent experience with JavaScript was quite revealing that f...