Wednesday, August 14, 2019

Which Clojure test runner to use?

Photo by Genaro ServĂ­n from Pexels
Clojure has a built in test framework which works very well and for most of my Clojure experience it has done the job, until yesterday.  As part of a new project I needed to integrate with Bitbucket Pipeline, specifically I needed to run my unit tests and have the build fail on a failed test and report which test failed.  Bitbucket supports this integration.

The standard way to do this is to have the test runner create a XUnit compatible XML file and have the CI tool consume this file to produce the reports.  Unfortunately, the junit.xml file created by the default Clojure test runner creates a junit.xml that does not follow the spec and Bitbucket doesn't report which tests failed.

After some research, I found that Kaocha does a much better job of creating a junit.xml that Bitbucket Pipeline can grok.  In addition, it also supports code coverage which is a great bonus.

Here is the stanza for deps.edn to make it work:

Thursday, August 8, 2019

Datomic Ions: lget does not exist


Photo by Matej from Pexels
I keep running into this exception when running Clojure in on AWS using Datomic Ions:
{ "Type": "java.lang.IllegalAccessError", "Message": "lget does not exist", "At": [ "clojure.core$refer", "invokeStatic", "core.clj", 4249 ] }
 The cause for this error seems to be that the code is trying to use either the Datomic Peer API or the wrong Datomic Client API implementation.  I am using the datomic-client-memdb for testing and if the code tries to use it on AWS, you will get that error.  Similarly, if the code tries to use the Peer library from a Datomic Ion, it will get this same error.

The problem arises from older code trying at runtime to determine if the Peer or Client API is being used.  The ways this used to be determined seem to no longer work and so the code picks the Peer when it should be the Client.

So far I have not found any code that will correctly figure out which API is being used.

Saturday, May 26, 2018

Please do not break my code

How long should code last?
I started coding in Java back in the last millennium.  I fully expect that code I wrote back then will still work on a modern JVM, indeed some it may still be running today.  It would probably run faster and better than it did when it was first written given the improvements in hardware, JIT optimizations and garbage collection.

For the last year or so I have been writing in Python ... Python 2 to be precise.  I have no hope that in 20 years any of the code I am writing today will be runnable yet alone running.  Python 3.0 was released December 3, 2008 ... almost a decade ago.  Why am I using Python 2 in 2018?

If we look at Python Versions Used in Commercial Projects in 2017 we see that I am not alone.  63.7% of commercial Python projects are still using 2.7.   If Python 3 is better (which it is) why are so many projects still not using it after so many years?

To deprecate or to break

Often language designers and library maintainers are faced with a difficult decision of deprecating code or introducing breaking changes.  There are large costs to either decision.

Back in 1996 Java introduced the deprecated tag as a way to mark code as:
  • the old API is insecure, buggy, or highly inefficient
  • the old API is going away in a future release
  • the old API encourages very bad coding practices
Fortunately, the second reason for deprecating was never really implemented.  Nothing deprecated has ever been removed from the language.  Nothing.  

Whoever made the decision to not remove deprecated code should be given a Nobel prize.

This decision means the burden of the deprecated code remains with the owner of the code.  Each release will need to test and validate code they would rather not have to maintain.  This is no small cost I am sure.

Compare this with the Python decision to make breaking changes moving from Python 2 to Python 3.  By making this decision, they try to move the on-going cost maintaining "dead" code to a one-time cost distributed across all projects using Python.  

The cost for just one company (the one I work for) to move to Python 3 will be enormous.  Because there are known breaking changes, all code will need to be treated as unreliable and have to be proven to be working correctly.  This is not just code we have written but any library we have included as well.  This represents hundreds or thousands of man-hours and increased risk ... ALL FOR NO BENEFIT.  If all goes well after weeks or months of effort, we will end up with the exact same functionality we started with.  Or, we could focus on what keeps us in business.  Hence the reason we are still using Python 2

Which means that the effort to distribute the cost of the breaking changes to everyone else has not really worked out.  2/3 of projects are still using the old code after 10 years.  The one time cost has becoming an on-going problem with no end in sight.  There are no winners in this debacle, just a fractured community.

Don't get me wrong, I like Python.  It is unfortunate that this difficult decision resulted in a situation that detracts from the usefulness of the language.

How long should code last?  As long as it is useful, not just until some language or library owner decides it is better to break it.  Please do not break my code.