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/"
Read More Read More
Most of the time when you develop an application that uses a database you are likely to use another database for your local development work than what you will use later in production. The main reason for this is that there are databases like H2 which by design are fitting the development situation while they are not very well suited for production usage. H2 i.e. has very fast startup times, can run completely in memory -this is an advantage because every time it is restarted its state is reset, too-, uses only few system resources and has a good mySQL compatibility. On the other hand it is not that popular in production as it lacks many functionalities like custom functions, an SQL interpreter etc.. Following this it is a very common scenario to use mySQL in production while using H2 for development. This way the developer can use the same database dialect for development while the local installation of a mySQL DB is not needed.
The problem with this scenario is that you need to switch the datasource to production when you build a new release and switch back to development when you want to use your local H2 for testing. This is something which can easily be forgotten and become annoying over time. Therefore it is a step which could and should be automated.
When you are using JavaEE you define your datasource depending on the application server either via an interactive tool (i.e. glassfish or payara via the asadmin command) or in a xml file (i.e. wildfly/jboss standalone.xml or TomEE context.xml). As an example I show you here a valid datasource definition in the wildly standalone.xml
<datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
<datasource jndi-name="java:jboss/datasources/ExampleMySQLDS" pool-name="ExampleMySQLDS" enabled="true" use-java-context="true">
<driver name="h2" module="com.h2database.h2">
<driver name="mysql" module="com.sql.mysql">
Read More Read More