At a client, today I’ve facilitated a brown-bag session introducing the Clojure language to a group of java programmers.
I’ve started hands-on, live coding on a REPL. To make things easier, I’ve created a maven project that imports the clojure jar and lets you obtain dependencies from clojars. The repo is here. This repo wouldn’t have been possible without the clojure maven plugin, written by Mark Derricutt.
I’ve more or less followed this guide
I’ve found this list of links for Java 9, while in beta, useful:
Contents of the new version Java REPL workshop, with useful commands and questions & answers for installing the REPL REPL tutorial PDF Another getting started guide, by JClarity Yet another getting started guide, by Arun Gupta Information on the REPL project, (codenamed Kulla)
Humble Object I’ve read the Humble Object list of patterns, by Gerard Meszaros, including:
humble dialog humble executable humble transaction controller humble container adapter Tags: pattern, gerard-meszaros
How you know I’ve reread this small essay by Paul Graham on storing information in our heads, based on the context. On the importance of rereading, to add more contexts to the initial one.
Tags: paul-graham, reread, read
Protected Variation: The Importance of Being Closed I’ve read this article by Craig Larman in the magazine IEEE Software > Design.
Lately, I’ve found myself repeating always the same dependencies for my pet projects and katas. Usually, I prefer maven to hold my java dependencies, organized in a java project.
This is how most of them look like:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.gmaur.legacycode</groupId> <artifactId>legacyutils</artifactId> <version>0.0.1-SNAPSHOT</version> <dependencies> <dependency> <groupId>org.hamcrest</groupId> <artifactId>hamcrest-all</artifactId> <version>1.3</version> <scope>test</scope> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.11</version> <scope>test</scope> </dependency> <dependency> <groupId>org.mockito</groupId> <artifactId>mockito-all</artifactId> <scope>test</scope> <version>2.0.2-beta</version> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.
Imagine having this java class:
private static class RepeatedConstants { public static final String A = "A"; public static final String A_1 = A; public static final String A_2 = "A"; public static final Integer _3 = 3; public static final Integer THREE = 3; } I wanted to remove the repeated values in the constants, in an automatic way, because the file was big (> 4000 constants). A way of doing this is basing the differences on the values, directly.
Organize IntelliJ IDEA’s import as Eclipse ones:
While working at a client, where everyone is using eclipse, while I’m using IntelliJ IDEA, there are subtle formatting differences. One of them is in the order of the imports.
To solve it, see this link