BowerStudios.com

From: digitalOcean.com

keytool -delete -alias -keystore lib/security/cacerts -storepass changeit

I used to think that the brain was the most wonderful organ in
my body. Then I realized who was telling me this.

I was having difficulty getting UFW working with NAT, but this guide from James T worked out for me.

In particular, I was leaving off the commit afterwards in the beforerules file. I thought the file would only handle one commit, but 2 seemed to work just fine.

The other thing main thing to do was updating the config file for ufw in /etc/default/ufw.

Configuration for NAT

An excellent writeup as usual from Mr Haki

The Log4j extras javadocs are here

There's a nice description of the different types of timeouts that can be used with HttpClient at baeldung.com

Was tearing my hair out why this was failing yesterday.
sql.call('{call PACKAGE.MY_STORED_PROC(?,?,?,?,?) }',
[studentId, firstAssignmentDate, lastAssignmentDate, sectionCode, termCode])

The Error:
Message: Invalid column type
Line | Method
->> 8921 | setObjectCritical in oracle.jdbc.driver.OraclePreparedStatement
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| 8396 | setObjectInternal in ''
| 9176 | setObjectInternal in ''
| 5024 | setObject in oracle.jdbc.driver.OracleCallableStatement
| 234 | setObject . . . . in oracle.jdbc.driver.OraclePreparedStatementWrapper


It failed with that error after I added some validation code. However, I could copy the code to the Grails Console, and it would work. If I called the Service from the Console, it would not work.

???

Apparently the Stored Procedure functionality of Groovy does not play well with @CompileStatic. I had added that with the validation code as an afterthought, and it was apparently the wrong thing.

Flattery is like cologne -- to be smelled, but not swallowed.

From David Larochelle's blog

You can use:
COPY TABLE_NAME TO STDOUT WITH CSV HEADER
to push the output to a csv file.

There are multiple ways to do this. I was particularly interested in getting it to run without the additional "groovy " in the front. Silly, but it was interesting.

I found an interesting question on unix.stackexchange.com regarding how to specify the interpreter for a script which came in handy in case you are using gvm (sdktool).

The result
Create a file - myscript.groovy - with contents:

#! /usr/bin/env groovy
println "executing some groovy"

Make the file executable:
chmod +x myscript.groovy

Now we can run it:
./myscript.groovy

Really doesn't save us much from:
groovy myscript.groovy

But it IS possible. It is also documented at docs.groovy-lang.org