Roberto Cortez

Published: 73 articles

Having a child is one of the most memorable moment you can experience. Parents have a huge responsibility with this new life and it starts right away when they have to choose the name. Our name is something that we keep for life (most of the times), so it needs some careful consideration. With literally thousands of names to choose from, how about using some Java technology to help us?

Yes, I wrote a small Java application to help me choose my baby name!

Requirements

First of all, we have to define some rules!

Basic Rules

A short name (but not to short)

In the first half of the alphabet

Without special characters

A short name, so it easy to call him. In the first half of the alphabet, because in Portugal we have this stupid rule where kids get seated in the classrooms in alphabetic order, so letters in the end of the alphabet get to sit in the end of the room! And finally, a name without special characters (we have a few in Portugal), to be easier for foreign people to use.

Advanced Rules

Exists in at least three languages (Portuguese, Spanish and English)

Sounds and Writes the same in all three languages

To cover the fact that I was born in a Spanish speaking country, that we live in Portugal and English for the globalization.

Constraints

There are also some constraints. In Portugal, you cannot use any name you want. You need to pick the name from an approved list of names. Of course, this is a comprehensive list of names that covers all common names. It is mostly used to avoid giving a stupid name to your kid. If your curious about it, check the list here.

Advanced Rules are more Interesting

Beider-Morse Phonetic Matching

When searching for a way to determine if a word or a name exists in another language and sounds the same, I came across with the Beider-Morse Phonetic Matching.

The main objective of Beider-Morse Phonetic Matching consists in recognizing that two words are written in a different way actually can be phonetically equivalent, that is, they both can sound alike. But unlike soundex methods, the “sounds-alike” test is based not only on the spelling but on linguistic properties of various languages.

How?
It tries to guess the language of the word following specific language rules and then calculates a phonetic value for that word. For instance:

tsch, final mann and witz are specifically German

final and initial cs and zs are necessarily Hungarian

cz, cy, initial rz and wl, final cki, letters ś, ł and ż can be only Polish

Rosette API

The Rosette API is a Text Analysis Toolkit, that provides multiple services to perform text analysis. They also have a Name Translation service with a REST endpoint that you can use to feed in names and the desired language and return the right translation with a confidence score. Their API is useful to double check results obtained with the Beider-Morse Phonetic Matching.

They have fantastic support, providing libraries to integrate with their API’s in multiple languages and also a lot of samples you can use. Check their Github repo here.

behindthename.com

The Behind the Name website provided with the etymology and history of first names, plus a comprehensive list of names and what languages do they exist. On top of that, they also provide an API to check that information, so you can use it to triple check the results from Beider-Morse Phonetic Matching and the Rosette API.

Final Results

After all, rules are applied and filtered the initial list, only 2 names remained. One is the obvious Lucas and the other was David. So, both these names exist, are written and are pronounced in the same way for Portuguese, English, and Spanish.

Proof it works?

Well, now I’ve just go to any random Starbucks and something with the name Lucas and confirm that they got it right. So far so good!

If you find this interesting, I even published the code in a Github repo. Check it out.

Note for Lucas: Lucas if you read this when your older, please excuse me for having such a geeky father.

The Fifteen Meeting of Coimbra JUG was about Application Servers. For a long time, developers complain about Application Servers. Developers find them heavyweight and the current trend is to develop lightweight, isolated and contained services. Most call this approach Microservices. In my opinion, there is not a 100% accepted definition of what a Microservice is, but this is another story. Anyway, are Application Servers prepared to answer the new demands? António Gonçalves has the answer in is new session. Have a look and decide for yourself:

Just Enough App Server

Neither too big nor too small. What you need is “just enough app server” to support only the subset of APIs and services your application needs.

In this session I will make an inventory of Java EE application servers (Weblogic, Websphere, JBoss, GlassFish), Profile Web (Tomee, Payara, Siwpass) and Servlets (Tomcat, Jetty, Undertow). If Microservices is want you want, I will introduce other modular solutions such as WildFly Swarm, KumuluzEE, Spring Boot or Dropwizard. I will talk about performance, war, executable jar, monitoring, management, optimization, use cases and some personal feedback… all this by showing code and executing several types of applications (from the simplest to more complex) in several kinds of containers … and maybe even on a Raspberry Pi.

I’ve used NetBeans very briefly around 2006 or 2007, can’t remember exactly, so I’m not the best person to talk about it. Geertjan was kind enough to collaborate with my Java Tip of the Week and make a video with me while going through some of the NetBeans features. I was also very happy to have my first guest speaker in my videos.

I have to say that I was very surprised with NetBeans. I would definitely keep an eye on it and maybe use it for some stuff. Just watch the video and decide for yourself:

Do we have someone that wants to make an Eclipse one to complete the set? I’ll be happy to do it.

It’s not secret that my favourite IDE is IntelliJ IDEA. You have already seen me using it in my previous videos, so it was just a matter of time to bring it as a topic. Here it is! Not trying to convince anyone to change or to start an IDE flame war. It’s enough already with the Java EE vs Spring wars.

Anyway, in a bit longer than 5 minutes this time, I went through some of the features that I use the most in IntelliJ, on Navigation and Code Generation.

Before Java 8, Interfaces were a closed contract, meaning that after you published an Interface, every implementation would have to implement every method present in the Interface. If you changed your mind later and wanted to add new methods, you couldn’t without breaking the compatibility. Implementations would need to add the missing code to the new methods. The Collections API is a good example. It was designed since the early versions of Java, but it was missing operations that would help every day developer.

With Java 8, we can now implement methods in the Interface directly. This is done via a Default Method with the default keyword. As the name says, we are providing a default implementation for the method. So, if any implementation does not implement the method, it would use the default implementation. This change allowed to expand and extend API’s behaviour without breaking compatibility.