When working on software development projects there are many repetitive tasks to do, may it be the deployment of a binary, starting of different servers in docker containers or standalone, the exchange of config files for different environments, the migration of a database or something simple as the navigation to deep paths on the command line to do some editings or server starts there. All this tasks can be annoying and over time they add up to a significant amount of time which is not very productive. The logical counter measure for a developer should be to automate as much as possible of this recurring tasks. For example you can bundle up the start of different docker containers via docker compose or delegate some tasks to a CI server but in the end some tasks will remain which you have to trigger manually -at least on your development machine- which is where your shell can become handy with a feature called ‘alias’. An alias is an automation feature which at least every popular Linux/Unix/macOS shell provides. With an alias you can define a new command that executes a series of shell commands completely automatic.
I have a rule of thumb defined where I try to automate every manual task by an alias which I have to do at a minimum of three times a week (to be honest I also do an alias if I have to do a task two times every week just because it is such a handy feature).
To define a new alias all you have to do is to add it to the config file of your shell. In the case of the very popular bash shell this file is called .bashrc (on macOS you have to use the .bash_profile file when you use bash) while for zsh it is called .zshrc but in both cases the file sits in the users home folder. All you have to do is to open your rc file with an text editor, scroll to the end and add a new line starting with the keyword ‘alias’ followed by the alias name you chose and the command that should be executed. A sample command could look like this:
alias cdwildfly="cd ~/programming/java/servers/wildfly/"
Flyway is my favourite tool when it comes to database migrations because its convention over configuration approach makes it fairly easy to use while bootstrapping and configuration is reduced to a minimum. For those of you who don’t know anything about database migration tools (evolutionary database design) in short the concept is to track SQL scripts with your source code which reflect the actual version of your database that matches the code version to run properly. This could be done without any framework but what tools like Flyway or liquibase bring to the table is the ability to check automatically at build- or start-time if the database is at the latest available version and if not run all available SQL scripts from the actual database version to the newest one available. Flyway can be used with all the major SQL dialects, many different relational databases and has plugins for a huge variety of frameworks to be integrated into. For more detailed information visit the projects website.
As I’m a heavy Java EE user I ran into the problem that Java EE has no special support by Flyway. My problems with this are that there is no build in way to get the actual JPA datasource (defined in the persistence.xml) and there is no solution provided that wires Flyway in the startup process to run the migration scripts at startup. Flyway provides integration plugins with this functionalities for other frameworks like Spring Boot but fortunately it is not that complicated to realise the same thing in Java EE.
In many scenarios it is no problem to trigger Flyway in the right moment as it is possible to integrate it in the maven build process or start it manually via the command line but both solutions doesn’t fit my needs. I want to have Flyway check my database at startup as the production server is not the server where the build process happens and I want to avoid a situation where I have to execute a shell command manually after deploying a new version. For this cases Flyway can be started from the source code as well. As it has to be run before the application starts and tries using the database you have to make sure that the Flyway scripts are run before that. I found two solutions to make this work. The first one uses Hibernates “Service Provider Interface” (SPI) -I use WildFly in this example which comes with Hibernate- to register a new integrator and grab the datasource via a little bit of reflection code while the second approach (which is my favourited solution) defines a new singleton bean which uses @resource injection to get the datasource.
When generating Excel Sheets it is sometimes necessary to remove rows which match a given criteria afterwards. The first idea for this would be to use removeRow(Row row) but this has the problem that it deletes all the row contents and leaves the empty row in your sheet which is probably not what you want. To remove the rows as a whole the shiftRows(int startRow, int endRow, int n) is needed.
Lets say we have a xls file with column A being the title which is always filled but we want to remove every row in which the data column B is not filled. For this case the following snippet would be appropriate …
Jetbrains has come up with a solution for the scrolling problem with IntelliJ IDEA based IDEs under macOS Sierra. They released a modified JDK8 which hast to be set as boot JDK for IntelliJ. You can download the JDK here.
For setting it as the boot JDK you need to got to action menu. This is reached under macOS by pressing ⌘ + ⇧ + a (in other words cmd + shift + a) buttons and entering in the search box the term “switch IDE boot JDK”.
The new JDK will be part of the next stable release of IntelliJ and is actually available as part of the 2016.3 EAP.
As this seems to fix the scrolling issue there are still reports of problems with the context click behavior.
As I’m a huge fan of IntelliJ IDEA I don’t use eclipse very often during the last years but I have a dedicated project where I need to regularly use for creating deployments and connect with some remote test servers. So I have to deal with eclipse and its problems, too. A recurring problem for me with eclipse is that it stumbles upon its own not cleaned up metadata which causes problems that are not obvious to solve at first sight. Most of them are gladly quick to fix if you know what you have to do.
A common problem of that sort is when, after selecting the workspace, eclipse fires up a popup with the message “The default workspace … is in use or cannot be created. Please choose a different one”. Most of the time the workspace is not in use but the problem can be caused by an unexpected closing of eclipse which prevents it from cleaning up its metadata correctly. The solution for this is easy. Just navigate to the workspace folder and delete the .lock file in the hidden .metadata directory..
If you are using a mac like me the easiest way is to do it on the shell because the finder by default doesn’t show hidden folders.
Now eclipse should start with your workspace as expected.