The Thirteen Meeting of Coimbra JUG was about Databases and how to keep their Schema versioning and controlled. While not being directly related to Java, it’s very common for every Java developer to come across with a project that needs to use a Database. Usually developers worry about versioning the code, but nobody cares about the Database. Shouldn’t the database be treated the same was as the code, since it’s also a part of the application? For that reason, we think this is a good topic to have on our JUG.
To talk about this very challenging topic, we had the pleasure to host Nuno Alves. Nuno is a very experience DBA, with more than 10 years of experience with Oracle, PostgreSQL, MSSQLServer and DB2. He is the right man to have on your team to deal with the Database stuff!
The session itself covered ER modelling, versioning of SQL scripts, deployment and documentation. It also had a demo of a tool called Flyway to version and control scripts executions in different environments.
In the end, we would like to thank Praxis and Critical Software for sponsoring the event with the venue, food and drinks for everyone! Thank you very much for your support!
This week Java Tip of the Week is about Maven. I’ve recently had session at Jfokus, called Maven Taming the Beast with the following abstract:
Maven Taming the Beast
Love it or hate it (and a lot of people seem to hate it), Maven is a widely used tool. We can consider that Maven has been the de-facto standard build tool for Java over the last 10 years. Most experienced developers already got their share of Maven headaches. Unfortunately, new developers are going through the same hard learning process, because they don’t know how to deal with Maven particularities. “Why is this jar in my build?”, “I can’t see my changes!”, “The jar is not included in the distribution!”, “The artifact was not found!” are common problems. Learn to tame the Maven Beast and be in complete control of your build to save you countless hours of pain and frustration.
Since the presentation was only 15 minutes long (video should be available later), I made this week Java Tip of the Week a small demo of some of the issues discussed and the commands you can use to fix them:
For reference, here are the commands:
Command
Description
mvn dependency:list
Displays the list of dependencies for the project.
mvn dependency:tree
Displays the dependency tree for the project, including transitive dependencies.
mvn dependency:analyze
Analyzes the dependencies of the project and determines which are: used and declared; used and undeclared; unused and declared.
mvn dependency:tree -Dverbose
Displays the dependency tree for the project, including transitive dependencies and omitted dependencies due to Dependency Mediation.
mvn install -Dmaven.repo.local=/tmp/.m2
Points Maven local repository to a new directory, forcing Maven to download everything again.
This week Java Tip of the Week we are going to continue to look into some of the new features introduced in Java 8. It’s about Time! The new Date Time API.
And in good Time we got it. Have you ever coded a real application without using any kind of object to represent Date or Time? I don’t think so. All of us are obsessed with Time, so it makes sense that we get a first class support to perform all kinds of operations when coding something. This was not the case prior to Java 8.
Java Date Calendar
Before Java 8, working with Date and Time was not an easy task. The old java.util.Date is not thread safe, represents years as two digits, uses a zero based index for months and is mutable. A real mess!
It’s replacement java.util.Calendar, was not much better. Still a mutable class, also with a zero based index for months. Some say it was even more broken than java.util.Date.
Displaying the Date / Time was not exactly easy. You needed to use yet another object to perform the proper formatting with DateFormat.
Finally, I don’t even want to discuss all the trouble you had to work with Timezones.
If I want to calculate yesterday day, but I only have an add method available. What do I do? Add -1 of course. Makes perfect sense!
Calendar set
Calendar .set
Java
1
2
Calendar calendar=Calendar.getInstance();
calendar.set(Calendar.MONTH,20);
Set the Month to 20? That can’t possibly work, right? Wrong! java.util.Calendar will just convert this to a valid Month and move the year, meaning that the 20 Months is actually September of the next year. Confused? You should be.
Joda Time
You could fix most of these by using a widely popular Date Time library called Joda Time. Is still the way to go if you can’t use Java 8 yet.
