ES6 and beyond - What i really like

Hi dear software companions. It has been a long time. A lot had happened in between. I even changed a residence :)
But enough about me. Let's talk some JavaScript. Recently i have read a book called You Don’t Know JS: ES6 & Beyond written by Kyle Simpson. I was fully overwhelmed with the amount of new features and syntax shortcuts (or how people like to call it syntax sugar) in ES6. Until now i did not have any contact with ES6.
Quite a few things i found interesting. For example one of those things are Proxies.

As i was reading about proxies i realized that many times in the past i was thinking how nice it would be to have structure like this available (together with some kind of syntax for classes which is now also available).
Let's try to define a really simple Proxy in ES6.

As you all probably know, proxy is nothing more than a "stand-in" object, which sits in front of real object. It can do some light-weight work or preparation until the real object is ready or created. Of course there are a lot of applications for proxies and software is full of them. You can easily find a lot of examples and explanations.

Proxy

In ES6 we define a proxy by passing the original object and handlers. What are these handlers? Handlers are just a list of specially named functions which we can use to do some work. So here is an example for handlers (sometimes called traps) which are invoked when when a property on an object is accessed and when the property is set:


If you run this for example in ES6 Fiddle you should get output like:


So pretty neat stuff. I really like this syntax and feature in ES6. It is clear and handy. I could also not resist using some template strings which also came with ES6.
You are probably wondering now how can you know which named functions are available for handlers. Have a look here at MDN for a complete list of handler traps available to proxy object.
You will often use Proxy and Reflect (introduced also in ES6) in combination. Handlers/traps are called when a meta programming task is executed on an object and the Reflect API is used to execute those tasks directly on the object.

This is all for now. I will post shortly some more on proxies and how they could be used.

Core Java Web Services on JBoss

Introduction

This blog post deals with Web Services. Well, to be more exact, it deals with "plain" java web services on JBoss. That means we are going to create a web service without any additional frameworks (like CXF, Axis etc.).

JBoss it self provides support for web services. So if you are really trying to build basic web service (or if you just wish to learn about web services and try different things), JBoss Web Services should be a good starting point.

Here we go!

Spring Security - Two Security Realms in one Application

This blog post is mainly about Spring Security configuration.
More specifically it is intending to show how to configure two different security realms in one web application.
First security realm is intended for the browser clients. It enables us to log in with in the login page and access protected resources.
Second security realm is intended for the REST web service requests coming from an android application. On each request, the REST client should send required information to the server and this information will be used to decide if the RESTfull request should be allowed to pass.
The two security realms (configurations) are distinguished by different URL patterns of resources in the web application. In both configurations we are able to reuse same authentication logic.

TDD benefits example

Hello everyone,
this is my first blog ever about test driven development (TDD).
The goal of this post is to show one of the many benefits of developing code in this direction, which means: unit tests first, implementation later.
Basically you should develop your most basic implementation first (maybe a class and a single method). Then you go and write a simple unit test for that method. At first run unit test will fail. Then you steadily increase the complexity of your implementation to achieve what is needed by your unit test. Finally when you do that, you can again increase the complexity of your test, by adding more test methods to test even more implementation code functionality. As you do that, some of the tests will fail again. Then you should keep refactoring the implementation code to make the tests green and so on.. That is the basic overview of how TDD should work.
The example i am about to show you is a simple piece of code written in Java, and unit testing framework is junit. So here we go.