"this" in JavaScript/TypeScript

I have been struggling with using "this" in JavaScript, ever since I got into that area of programming.

There are lots of warnings on the web, where programmers who are used to a certain behaviour regarding "this" (Like me) can fall into this trap.

I recently found some really good resources that explain it.

There's one¹ that explains it a little regarding "this" in JavaScript.

But as I have been writing in TypeScript, I was looking for an explanation that focuses on TypeScript and helps me find the best solution to deal with this. I found that one in [2].

For example

So I've got some code that could use a bit of a look-over.

Here's the troublesome bit.

TypeScript has an excellent Tutorial, which I've used time and again to write my things. One of the pages I've used is the explanation regarding HTTP which you can find at [3].

In it they mention a "handleError" method, which can handle HTTP errors of the PlayerService. Convenient, so I used it. It works.

Next, I wished for the handleError method in the PlayerService that takes care of HTTP connections to notify the ErrorsService. So naturally, I inject the ErrorsService into the PlayerService.

Unfortunately, in the handleError, the ErrorsService is 'undefined'. (See line 30 in the gist below)

It is explained in reference [2] why this is, but I like the following quote:

“The biggest red flag you can keep in mind is the use of a class method without immediately invoking it. Any time you see a class method being referenced without being invoked as part of that same expression, this might be incorrect.”

Now there are several solutions for this described in [2].

The solution below is what I came up with on my own, and I don't really like it, but it works.

Local Fat Arrow

I prefer the solution called the "Local Fat Arrow", which looks like this:
I love it!

References

[1] Mozilla Developer Network - javascript:this

https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Operators/this

[2] Github/Microsoft/TypeScript - 'this'in TypeScript

https://github.com/Microsoft/TypeScript/wiki/'this'-in-TypeScript

[3] ts GUIDE - HTTP CLIENT

https://angular.io/docs/ts/latest/guide/server-communication.html

AdditionalCriteria

Small followup of From Hibernate to Eclipselink¹ post.

I am not entirely satisfied about the AdditionalCriteria⁴ thingy. I find it a chore to have to set a parameter on the EntityManager all the time to enable/disable it.

Biggest issue for me is that parameters set on the EntityManager are required. If they are omitted, an exception is thrown when querying.

Current solution in my software:
Turn the AdditionalCriteria on or off by means of a parameter that needs to be set on the EntityManager.

Looks like this:
Setting the parameter activePersonFilter can be done on the EntityManager as follows:

@PersistenceContext(properties =
{
  @PersistenceProperty(name = "activePersonFilter", value = "0"),
  @PersistenceProperty(name = "sundaydateFilter", value = "")
})
private EntityManager em;

Or

entityManager.setProperty("activePersonFilter", 0);

Other solutions

There are some other solutions.

1. You can remove the additionalCriteria (set it to "") in a subclass, and use the subclass specifically. See [2].
2. You can customize any mapping in EclipseLink and add the requirements/conditions that you need. See [3].
3. I could just decide to create a view on the offending database table. Then create two entities. Sounds very similar to the first option.
4. I could solve the problem in software. Just have EclipseLink not filter anything. (Which is silly, I don't wish for my ORM to get the 1000 persons in the room from the database, if there are say only three persons active.)
5. I could remove the collection entirely, and retrieve the required Persons using a NamedQuery. (Which is bogus. I like the ORM to deal with this for me, instead of having to do it myself. It's what the ORM is for.)

Customizing a Mapping

I have recently decided to try to customize the mapping specifically in Entities that have collections containing instances of Person class. That way I have more control. See reference [3] on how this works.

It requires a @Customizer annotation.

For instance, in a Room I only wish to see the active persons.

This requires me to define the PersonsFilterForRoom as follows.

"persons"

the name of the field that contains the collection

"room"

the name of the field in the Entity of the collection

"id"

the name of the field in the Room entity that identifies it

It works pretty good.

Note

I also noticed that this way I could have two (Lazy! That's the important bit!) Collections in the same Entity at the same time referring to the same Person. One will contain all Persons and one will contain only the Active Persons.

This is ideal, for instance for Guilds.

Like so:
This way the customizer PersonsFilterForGuild is designed to only work on the activeMembers collection.

I like it!

References

[1] From Hibernate to EclipseLink

http://randomthoughtsonjavaprogramming.blogspot.nl/2014/07/from-hibernate-to-eclipselink.html

[2] StackOverflow - Disable additional criteria only in some entity relations

http://stackoverflow.com/questions/37419406/disable-additional-criteria-only-in-some-entity-relations

[3] Mapping Selection Criteria

https://wiki.eclipse.org/EclipseLink/Examples/JPA/MappingSelectionCriteria

[4] JPA Extention in EclipseLink - @AdditionalCriteria

https://www.eclipse.org/eclipselink/documentation/2.6/jpa/extensions/annotations_ref.htm#additionalcriteria

Customizing EclipseLink JPA/ORM Relationship Joins

http://onpersistence.blogspot.nl/2008/01/customizing-eclipselink-jpaorm.html

Eradicating Non-Determinism in Tests

A small blog this time.

At work we sometimes have serious problems with non-deterministic tests.

Martin Fowler mentioned how this can be prevented or dealt with.¹

I also noticed that these non-deterministic tests are (almost...) always in the end-to-end tests (or the functional tests, or however you wish to call them).

Martin Fowler also has something to say about those²

References

[1] MartinFowler - Eradicating Non-Determinism in Tests

https://martinfowler.com/articles/nonDeterminism.html

[2] MartinFowler - TestPyramid

https://martinfowler.com/bliki/TestPyramid.html

REST-assured

I am a card-carrying member of the NLJUG⁰, which provides Java Magazine (not the Oracle one) six times per year.

One of the issues contained an article about REST-assured¹.

I have been using SoapUI⁵ to test my REST services, and that works fine. It's a nice graphical userinterface for me to fiddle with parameters and urls and HTTP requests and even write tests.

I am aware that it is probably possible to integrate SoapUI into my Build Pipeline, but I was really looking for something different. Something more in the line of programming, which is of course my forte. Something I could use in my unit-tests.

REST-assured was exactly what I needed and let me tell you, it's great!

Usage

I will provide an example of how I use it.

As you can see, REST-assured is a very nice DSL (Domain Specific Language) and reads easily.

Some explanation of the above:

log().ifValidationFails()

I wish to log stuff, if the validation/test fails, so I can find out what is wrong. The output looks like

param(name, value)

for setting parameters at the end of the url, like ?stuff=value

pathParam(tag, value)

replaces {tag} in your url with the values. Convenient!

request methods

in the example above, we are using the PUT HTTP Request.

As it is used for testing, it is possible to verify the values afterwards. In the above this is visible as we expect to receive a 204 (NO_CONTENT).

We can extract the response, as is done above, to verify for example the json payload (if there is one) or get cookie values.

In the above example it is essential for the followup calls that we get the JSESSIONID cookie out of the request.

In subsequent REST calls, it is obvious that we need to send along the same JSESSIONID cookie.

See for more information reference [4].

Some notes

I tried to send parameters, but a POST defaults to FORM parameters in the body, but I already have a BODY. But using "queryParam" instead of "param" fixes this problem.

I do enjoy using the "prettyPrint" method on a Response, to properly format a JSON body and dump it to standard output and see what I get. It's nice.

Getting some values out of your JSON formatted response body does require some serious work, though. Needs more research.

I am not entirely sure, I do not enjoy using http status codes like 200 or 204. I prefer something more readable like "NO_CONTENT", but I suppose I can deal with it myself. No biggy.

Update 14/05/2017: I'm also slightly sorry to find out that rest-assured includes Hamcrest. I prefer AssertJ at the moment myself.

Postscriptum

The article in Java Magazine also mentioned WireMock³.

Though I do not use it, it seems excellent for testing the other side of the communications, if you need to test a client that communicates with a server via rest calls.

References

[0] NLJUG

http://www.nljug.org/

[1] REST-assured

Teije van Sloten Java Magazine | 01 2017

[2] GitHub - Java DSL for easy testing of REST services

https://github.com/rest-assured/rest-assured

[3] WireMock

http://wiremock.org/

[4] GitHub - RestAssured Usage

https://github.com/rest-assured/rest-assured/wiki/usage

[5] SoapUI

https://www.soapui.org/

Testing REST Endpoints Using REST Assured

https://semaphoreci.com/community/tutorials/testing-rest-endpoints-using-rest-assured

RFC2616 - HTTP status codes

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html