Manju

Greetings! Business validations are a crucial part of any application. We faced use cases with too many validations. It is hard to maintain and extend the solutions with such a number of validations. This is when I thought to try a solution even though there was no such task in the backlog. Hence I used my own personal time for this. Features Execute a larger number of validations in single use case Reusability by sharing the same validation in different use cases Skip non-mandatory validations by user choice (yes/no dialogs) Expose validations via REST API Extendability by adding/removing validations No performance impact Easy to use in future developments It all started with an Interface My quick solution was to introduce a common interface by utilizing Java generics and Java 8 new features. I did not have all the features in mind when introducing this. However, that is the power of having a proper interface. public interface Validator<T> { void vali

Greetings! I got a chance to work on a project where we had UIs for meeting schedules and later improved it to sync with external calendars as well. In this article, I am sharing my general ideas on that design. The main business requirement is to access meetings anywhere whether from our system or an external system. (It is a different domain, for the article's purpose I refer to these as meetings) Initial investigation I took a decision to make this a normal meeting request just like Google calendar as making this a meeting event would be more appropriate and user-friendly. My co-worker did the initial investigation on iCalendar format which is standard for calendar clients. We found that sending a meeting request is an email with the header "type=calendar". Initial investigation and the proof-of-concept is done! Let's define the main components. Main components We could complete this by adding simple classes/logic. However, that is not real engineering. Hence, I de