If you are a user of any form of computer and care one bit about your sanity, then you probably have a backup strategy. Otherwise, if all hell breaks loose and your whole computer burns to ash or the hard drive melts to a heap of metal, turning it into an ugly door stop, you’ll likely be kinda angry, maybe slightly pissed, your pulse most definitely at 180, that you’ve lost all your data. I’d certainly be, especially about all my pictures of all the festivals and places I’ve been to.
(And maybe some family 😅)
But, to be honest, I’ve been a bit lazy about backups for some time now. I do have copies of all my important files, but that’s not a backup. It’s a copy. A backup lets you go back in time and get an older version of a file or folder, not just the most recent one that has been synced.
So why is it, that I’m not as diligent as I should be? There are a few factors in that equation. It’s laziness for one, knowledge that I do have at least one copy, the fact that I haven’t had any data loss so far and stinginess. Why the latter? Up until now, being a Windows user (not any more though, on my main machine), I was relying on Acronis True Image, a commercial backup software. However, the version that I own – 2014, I think – stopped being reliable in one of the past Windows 10 versions. I simply don’t want to spend the money any more.
I’m not here to tell you that I have changed my mind on that. No. I’m, of course, coding my own solution. Why wouldn’t I? Everything is done multiple times in the Open Source community.
Read More »
Groovy Spock is a testing framework that can be used as an alternative to the venerable JUnit. In Java projects it’s probably very common (I don’t have any data, just an assumption based on how I think) to also use a Java based testing framework. The most widely known is JUnit, although not the only one of its kind (e.g. see this article on DZone). However, Java’s syntax can sometimes be rather cumbersome and verbose, and this is where a dynamic language like Groovy can help. It is often used to create nice and interesting DSLs, e.g. as the basis of the Gradle project or, as in the case of Spock, for testing.
Here’s how to integrate the Groovy Spock testing framework in a Maven based Java project.
One thing up front: I’m no fan of Groovy. I’ve worked with Grails projects for several years and using Groovy has more than once proven to be a problem. Especially in very large applications. However, I do see the benefits it can provide in certain situations and I have come to like the more expressive, although sometimes odd to read, Spock DSL in tests.
Read More »
Just recently my interest for Kotlin, JetBrains’ (the makers of the IntelliJ IDEA development environment) alternative to Java on the JVM, was piqued. These are the first things I’ve noticed.Read More »
Grails always has something new to offer, not only features but also random bugs (unfortunately). Out of the blue I couldn’t even let Grails show its own version (grails –version) let alone perform any other action. This is all I got for each and every command I tried to execute.
*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with
message transform method call failed at
../../../src/share/instrument/JPLISAgent.c line: 844
Exception: java.lang.StackOverflowError thrown from the
UncaughtExceptionHandler in thread "main"
The following runtimes were used:
- Windows 7 64bit
- Java 7 Update 71 64bit
- Grails 2.4.4
Of course I removed all temporary files and folders, the “target” folder of the project and the “.grails”, “.groovy”, “.m2” and “.ivy” folders in the user directory. Nothing helped. Some say it has to do with forking processes, but playing with those settings didn’t change a thing. After all, the error happens way earlier.
Then I came across a post that mentioned to create the “.inputrc” file (on a Linux system) because through debugging it was found that Grails tries to access this files. Well, I’m not using Linux, but since I was already in the “helplessly desperate” phase I wanted to give it a shot. Surprisingly, this file already existed.
Solution: I deleted “.inputrc” from the user folder et voilà, Grails worked again.
Recently I have updated our Grails 2.3 based web application to Grails 2.4. Although the 2.3 release was working fine, one doesn’t want to fall too far behind. I know out of experience that this can happen very fast. If you wait too long, then at some point the migration to a newer version is almost like starting from scratch, instead of just updating a few lines of code to accommodate for deprecated APIs. The biggest problem I encountered going to version 2.4 was a behavioral change regarding the validation.
Read More »
I have written about the performance of iterating directories before, in the context of Java and its switch from version 6 to 7 that brought with it the new Java NIO API. For whatever reason I felt the urge to do something similar again, but this time I wanted to compare two different approaches to recursively scanning a directory’s contents:
To make things more interesting, I implemented this in C++ using the Windows API and the Qt framework, in C# in combination with its buddy the .NET framework and, for good measure, I also threw in the old Java code from over a year ago.
Update (26.12.2014): I added additional data at the bottom of the article.
Read More »
The Grails web development framework is a very powerful tool for quickly creating web applications ranging from simple to enterprise ready. For that, it probably provides everything a developer ever needs. And if it’s not delivered by Grails itself there are many useful plugins and tons of existing Java libraries (including the JDK, of course, the underlying SpringSource Framework and the GDK).
However, there is one thing I have stumbled across several times now and a quick search on the internet shows that I’m not alone with this problem: how can I use the internationalization features from a regular Java or Groovy class?Read More »