- Maven Polyglot: replacing pom.xml with Clojure, Scala, or Groovy Script shows how you can, well, replace the XML configuration for a Maven project with a configuration in another language. This also provides some imperative-ish features to Maven projects, plus no XML except for a short description of the scripting language.
- How does a relational database work provides a (very) high level description of how a relational database does its work – and if you read carefully you can see some of the motivations behind some of the less- or non-relational database decisions out there, too.
- From user DerDingens: An Examination of Ineffective Certificate Pinning Implementations, which points out common mistakes while using certificates in Java.
- Maldivia pointed out a Java Enhancement Process draft, for Epsilon GC: The Arbitrarily Low Overhead Garbage (Non-)Collector – basically a garbage collector for Java that does absolutely nothing, for the purposes of tuning, testing, and in some cases, performance enhancements (if you know your job is short-lived, why bother running a GC if you don’t need to?) Fascinating stuff.
- From cheeser: Google, IBM back new open source graph database project, JanusGraph. JanusGraph is a fork of Titan, but its list of backers make it worth watching. Have you used a graph database before? How? What did you think of it?
- Two from DZone on git:
- Lesser Known Git Commands has some handy shortcuts for git users (and chances are good that if you’re reading this, you’re a git user.)
- Git Submodules: Core Concept, Workflows, And Tips. From the article: “Including submodules as part of your Git development allows you to include other projects in your codebase, keeping their history separate but synchronized with yours.” Great stuff.
- Oh, shit, git! is a site that shows a number of common things git users say, as well as how to fix the situations that cause them. Note that the title indicates that the readers are expected to be of age. Some examples:
- Oh shit, I did something terribly wrong, please tell me git has a magic time machine!?!
- Oh shit, I committed and immediately realized I need to make one small change!
- Oh shit, I need to change the message on my last commit!
- Oh shit, I accidentally committed something to master that should have been on a brand new branch!
- Oh shit, I accidentally committed to the wrong branch!
- Oh shit, I tried to run a diff but nothing happened?!
- F*ck this noise, I give up.
It’s worth noting that your editor has used at least a variant of all of these statements, most of them even in recent memory.
- User whaley, in a moment when he wasn’t accompanied by roosters, cows, and goats, pointed out “Suffering-oriented programming“, saying that it convinced him that “make it work, make it pretty, make it fast” is the right approach, as compared to “make it work, make it fast, make it pretty.” Good read.
- From Reddit: “Recaf is an open-source framework for authoring extensions (dialects) as libraries for Java. You can redefine every major syntactic element of the language, either add new ones or create your own flavor of Java that matches your needs. It can be used to give syntactic support to libraries, to generate and instrument code. Last but not least you can experiment with the design and implementation of Java extensions in plain Java.” Seems like another tool to compete (sort of) with Lombok and Autovalue.
This list was originally supposed to be published over a week ago, but life’s been busy. Sorry, folks! Happy St. Patrick’s Day!
- A succesful Git branching model considered harmful is a response to another article, A successful Git branching model. Both models can work; which one works better for you depends on a lot of factors that are likely to be unique to your development environment. (I’ve used both: I find the “cactus model” better, personally.)
- The Four Software Engineering Personality Types describes four personalities (surprise) in development environment: Iron Man, Michaelangelo (the sculptor, not the Teenage Mutant Ninja Turtle), Yoda, and Captain America.
- Iron Man is a tinkerer – get 90% of the project done, really quickly.
- Michaelangelo is the detail-oriented, deep-diving programmer – the one who spends years on a given project, working out every detail. Michaelangelos’ projects tend to be unusable until they’re done – then they’re mission-critical and awesome.
- Yoda is a teacher (or, if you like, a puppet with a hand up his… I mean, “a teacher.”) These are the guys who know tons of stuff, and show it to others, growing an organization and providing wisdom – and a great lever when they focus on doing specific tasks.
- Captain America is the workhorse, the one who’ll roll up his sleeves and do the unpleasant work. Like in the comics, Captain America and Iron Man go well together; Iron Man rockets through the stratosphere, flashy and quick, and Captain America cleans everything up and makes it work well.
- And now into our selection of excellent DZone content: Abstraction Considered Harmful..? has a bit to say about abstractions: they’re good, but sometimes they’re leaky (and therefore can be bad). But mostly they’re useful. From the article: “Abstraction, in and of itself, is not harmful. On the contrary, it’s necessary for progress. What’s harmful is relying on impenetrable barriers to protect our precious programmers from hard problems. After all, the 21st-century engineer understands that in order to play in the sand, we all need to be comfortable getting our feet a little wet from time to time.”
- In Anatomy of a Good Java Test, Sam Atkinson (who will show up again in this same collection of interesting links) walks through a simple recipe for good testing. It looks like it’s based around JUnit4 and Hamcrest – hardly awful choices, but also not necessarily the state of the art (or the only way to write good tests). Good baseline, though.
- In In Defense of the Fifth Year Developer, Matthew Casperson argues for some of the abstraction discussed earlier – the point’s not very clear, but complex code laden with abstractions is easier to test and verify, because it breaks problems down into identifiable units.
- And back to Sam Atkinson: In Constructor vs. Getter: A Better Way he discusses the use of no-operation classes to wrap optional behavior (thus:
NoOpNotifier, with methods that do nothing, instead of a
nullthat has to be checked). This simplifies the code path (a good thing), and also helps with that pesky abstraction thing. Good article.