Hello World: Software Development

Not long after I discovered IntelliJ IDEA groovy inspection issues in my last post regarding result data tables, I discovered interaction-based testing  groovy inspection issues, too.  This time, interaction expectations like this have inspection problems: 1 * mock.someMethod(argument) This time, I had to disabled the groovy "Incompatible type assignments" inspection because spock's syntax confused the IDE. Spock seems interesting from an expressive standpoint, but it comes at the cost of static inspections.  Given groovy's history of loose typing and the like, I am not too surprised by this information.  I am a huge fan of mockito historically.  I am trying Spock out now, but I'm not sure I am a fan.

When writing a data driven table test in Spock  where my result is a simple boolean true or false, I discovered that IntelliJ IDEA runs an inspection and decides that the code can be simplified by simply removing the result value.  This means it wants to take a result data table that looks like this: where:  checkpoint   || result  "2018-10-22" || false  And make it look like this: where:  checkpoint   || result  "2018-10-22" ||  After allowing this inspection to make a change,  the test will no longer run.  IntelliJ offers the option to ignore this inspection at the method or class level with an annotation: @SuppressWarnings("GroovyPointlessBoolean") Unfortunately, this solution also causes the code to not compile. The only solution seems to be to either ignore the warning and let the little yellow box remain yellow or to disable this inspection entirely within IntelliJ IDEA.  I chose the latter, and disabled it only within Groovy

I've recently been working on a project to integrate with a 3rd party.  This is normal work in software development; we constantly work to make this system talk to that system and so on.  The web has made this a lot easier, as many groups are moving their APIs to a more standard kind of setup.  REST is ruling the integration world right now (as far as I can tell), and I don't see that changing any time soon. Security... is a different matter.  Authorization and authentication tools keep evolving, sometimes in sync with integration... and sometimes not.  Spring is currently pushing out new and shiny updates to spring boot ( 2.1.0 just came out! ), but spring security has not necessarily been keeping up.  This isn't unique to spring.  The 3rd party integration I'm working on is still using OAuth1.0 (NOT 1.0a if I can believe the documentation).  When I saw that, I am sad to say that I was not surprised. Sparing the debate of OAuth1.0a vs OAuth2.0 and the comparison of