DEV Community: patricianicole

Introduction to Java Enterprise Edition

patricianicole — Sun, 27 Mar 2022 03:35:03 +0000

Java Enterprise Edition (Java EE) is a collection of abstract specifications that together form a complete solution for commonly faced challenges during software development.

Words that are typically heard while studying Java EE includes:

Application Server : It is a concrete implementation of the Java EE abstract specifications. Examples include Payara Server (Glassfish), IBM OpenLiberty, and JBoss Wildfly.
Java Specification Request (JSR) : It is a formal request to the Java community process for addition and enhancements to technologies. It is a body that standardizes APIs on the Java Technology platform and is used to group APIs into silos, e.g. JAX-RS (Java API for RESTful Web Services). For every JSR, there is always a default reference implementation.
Reference Implementation : It is the concrete realization/implementation of an abstract JSR. For instance, the reference implementation for JAX-RS is called Jersey. Java EE in itself is a JSR. Thus, an application server is a collection of the various reference implementations for the Java EE JSR. Java EE is JSR 366, and one of its reference implementation is Glassfish 5.
Jakarta EE : It is Java EE going forward. Oracle moved the Java platform to be hosted by the Eclipse Foundation.

Java EE Basics

There are three key APIs in Java EE.

Java Persistence API (JPA) . It is responsible for storing and retrieving information from relational databases, which can be extended to handle NoSQL databases. It is the data layer of an application.
Context and Dependency Injection (CDI API) . It is a standardized way to create highly decoupled applications. It manages various interactions of different components to allow loose decoupling.
Java API for RESTful Web Services (JAX-RS) . It exposes resources over HTTP protocol as webservices.

Context and Dependency Injection API

Dependency Injection is a specific form of inversion control (software strategy where individual components have their dependencies supplied to them). This externalizes dependency in the application to create loosely coupled components.

CDI Features

Dependency Injection (Typesafe) : Allows declaration of dependency on types, so that the compiler catches error during runtime.
Lifecycle contexts : The ability to bind the lifecycle and interaction of stateful components to well-defined but extensible lifecycle components.
Interceptors : This allows interception of requests to access a certain method.
Events : A way to develop highly decoupled applications. Events can be fired while observers listen for the fired events.
Service Provider Interface (SPI) : A set of hooks and API and interfaces that can be used as extensions, e.g. Apache libraries.

Some concepts under the CDI API,

CDI Bean Discovery : A mechanism where the dependency injection runtime analyzes and discovers beans for it to manage default bean discovery mode, i.e. beans that are annotated, e.g @Annotated. There are three types of bean discovery mode, ALL (includes those beans that are not annotated), ANNOTATED, and NONE.
CDI Container : A factory in which Java classes comes in and goes out with their functionality and features. It is an application that manages beans.
Bean and Contextual Instance : A bean is a template which a developer creates. A contextual instance is an instance of a bean created by the CDI container and is managed by it.

Java Persistence API

JPA is used to map objects to relational database tables. The Java Persistence API meets the ORM manifesto tenets.

ORM Manifesto (Object Relational Mapping Manifesto)

Objects not Tables : Developers write objects not table.
Convenience, Not Ignorance : An ORM should be convenient. Developers should at least have minimum knowledge on relational databases. ORM is not a way to mask ignorance but convenience.
Unobtrusive not transparent : An ORM should make it so that developers are able to control what is in the database and have complete control on what is being persisted.
Legacy Data, New Objects : Expect ORM to allow creation of new objects from legacy data, i.e. reverse engineer legacy database to Java objects.
Just Enough, not too much : Expect ORM to give us all the tools to solve generally encountered problems due to impedance mismatch (term used to refer to problems that occur due to difference between database model and programming language). An ORM should not be excessively heavy weight.
Local but mobile : The data is local but there should be an ability that enables the persistent state of the application to travel to different parts of the application.
Standard API, pluggable implementation : Rely on a standard API but can be swapped implementations if needed.

Some important concepts under JPA,

JPA Entity

The most unit component of JPA entities is a plain old java object (POJO). Every entity must have a unique identifier.
There are commonly used annotations on JPA entities such as @MappedSuperClass annotation which enables the use of superclasses containing the common fields of entities. @AttributeOverride annotation is used to override entities od the superclass. @column is used to customize database mappings. @Transient annotation can be used for fields in the entity class that should not be mapped to the database.
Access type : The process by which the persistence provider accesses states in the entity. Field access happens when the provider accesses class fields directly through reflection. Property access happens when the java bean property methods are used to access states, i.e. use of getter and setter methods. To use property access, the getter method must be annotated with @ Id. Mixed access type uses both field and property access in the same entity class using @access annotation.

Java API for RESTful Web services

REST Architecture Constraints

Client and server is independent of each other.
Stateless : Every single request that comes to the server is a self-contained unique request. The server does not make any assumption from the previous request.
Cacheable : The system should support caching at different levels to improve performance and scalability.
Uniform Interface : Means that the client should have general uniform interface for accessing resources on the server and also for interacting with the resources on the server.
Layered System : The server can be implemented in different layers in a way such that a client need not to worry about a layer system, e.g. a server that supports load balancing.

Some common concepts related to JAX-RS

HTTP GET method : A request for a resource or resources. A GET request method is idempotent, meaning that making the same request to a method over and over again should not and must not change the state of a resource or data on the server.
HTTP POST method : A POST request is used to create new resources on the server. It causes a change on the dataset in the server. The POST normally has a body where payload or whatever we want to create on the server is posted or attached.
HTTP PUT method : This is used semantically to update resources on the server.
HTTP DELETE method : It is used to delete resources on the server.
Content types: There are several content types that can be consumed and is produced by request methods, (1) XML, (2) CSV, (3) EXCEL (4) TEXT (5) JSON.
JAX-RS has a concept of message body writer. They are API constructs used to convert the Java types to relevant type the client expects. @Produces annotation can be used to specify the type to which the Java object response is converted.
The @Consumes annotation tells the JAX-RS runtime the type of content a given resource method consumes. The JAX-RS runtime will then convert the JSON content passed as a payload to a Java object of type similar to the method parameter.
JAX-RS Exception Mapper : API construct used to map exceptions to HTTP responses. The @ Provider annotation is used to register an exception mapper to the JAX-RS runtime programmatically.

This is just a very basic introduction to Java EE. Each key API needs more delving to be able to create web application using Java EE.

Thank you for reading!!

My First Hacktoberfest : Feasting on issues for the badge

patricianicole — Sun, 24 Oct 2021 14:51:06 +0000

Hi I am Pat, and this year is my first #hacktoberfest. From the title, I sound like a #hacktoberfest villain, don't I?

SPOILER ALERT: I am not :).

This year, I started getting active on github and the DEV community because of my learning goals. With that, I also learned about a lot of dev events, one of which, #hacktoberfest.

I decided to enter out of curiosity, exploring a lot of projects with the good first issue tag to get the hang of it. Finding issues was easy, the problem was, I got a bit late and almost all of them are dibbed/taken already. It was fine. The bad part was some contributors were commenting on threads, messaging the maintainers to accept the PRs. Sometimes requesting these maintainers to add the #hacktoberfest tag for the request to be counted in their #hacktoberfest participation tally. It kind of feels off because it seems to me that the desire to contribute stemmed from the acquisition of a badge after the event and not the genuine desire of contributing to the open source community.

I reflected on this first #hacktoberfest experience and realized that if I want to successfully complete the event, I have to be actively exploring the open source community not just during October. Finding issues is very easy to do, but familiarizing with how an open source project work, reading the contributor guidelines carefully, setting up local development, analyzing the open issue, etc. take time. Completing issues that are not menial requires preparation.

If I have one suggestion for myself next year, that is, explore fun/interesting open-source projects in advance, start contributing, familiarize with the contributor's guidelines and the open issues. And I feel like hacktoberfest will be completed in a breeze that way.

I can say I failed my first hacktoberfest, but I think the experience served me well.

Happy hacking!

Java Interfaces

patricianicole — Tue, 24 Aug 2021 01:26:46 +0000

📌 Interfaces in Java

An interface is a reference type, similar to a class that can contain only constants, method signatures, default methods, static methods and nested types.
Interfaces cannot be instantiated - they can only be implemented by classes and extended by other interfaces.
Note that an interface can extend any number of interfaces. The interface declaration can include a comma-separated list of all the interfaces that it extends.

The Interface Body

The interface body can contain abstract methods, default methods and static methods. All of these methods in an interface are implicitly public, static, and final.

Implementing an Interface

A class can implement more than one interface. The implements keyword is followed by a comma-separated list of the interfaces implemented by the class.

Using an Interface as a Type

When a new interface is defined, a new reference data type is defined. The interface names can be used anywhere a data type can be used. If a variable is assigned an interface type, any object assigned to it must be an instance of a class that implements the interface.

Evolving Interfaces

To avoid the scenario where implementing classes need to change because of the additions to the implemented interface:

Create a new interface that extends to the changed interface. In this way, implementing classes only need to change what interface to implement, whether the child or the parent. Now users of the code can choose to continue to use the old interface or to upgrade to the new interface.
Alternatively, new methods can be defined as default methods. Since implementations are provided for default methods, users who have classes that implement interfaces enhanced with default or static methods do not have to modify or recompile them to accomodate the additional methods.

Default Methods

Default methods enable one to add new functionality to the interfaces of the library to ensure binary compatibility with code written for older versions of that interfaces.

A default method in an interface is defined with the default keyword at the beginning of the method signature. All method declarations in an interface, including default methods are implicityly public so the public modifier can be omitted.

Extending Interfaces that Contain Default Methods

When an interface with a default method is extended,

There is no need to mention the default method at all, which lets the extended interface inherit the default method
The default method can be redeclared which makes it abstract
The default method can be redefined by overriding it

Static Methods

A static method can also be defined in an interface. It is a method that is associated with the class in which it is defined rather than with any object. Every instance of the class shares its static methods. Now this helps in organizing helper methods.

Integrating Default Methods into Existing Libraries

Default methods enable the addition of new functionality to existing interfaces and ensure binary compatibilty with code written for older versions of those interfaces. In particular, default methods enable the addition of methods that accept lambda expressions as parameters to existing interfaces.

Summary

An interface declaration can contain method signatures, default methods, static methods and constant definitions. The only methods that have implementations are default and static methods
A class that implements an interface must implement all the mothods declared in the interface.
An interface name can be used anywhere a type can be used.

Cheers to continued learning 🍻!

RESOURCES

[1] Java Doc, What is an Interface

Library Project 📖

patricianicole — Tue, 17 Aug 2021 01:30:30 +0000

Entry for The Odin Project's library exercise under the full javascript path

Live preview can be found here

One can add a book in the library with its title, author, a brief review of the book and a pseudo-name of who added the book.

WIL/Thoughts 🤔

Firebase

I was looking for a free online database and found firebase. The site allows user to add books and saves them in the firestore. It is similar to a mongo database, where for each project, there is a number of collections and for each collection, there are documents. In this project, I am saving each book as a document.

There are also a lot of ways in which firebase can be added in an application, one through CDN and another through npm/yarn. I opted to use CDN for this exercise. Why? I do not have any particular reason, to be honest, it felt more convenient 😆.

I also checked the documentation to check how to connect my site to the project in the firebase, and that went well.
TailWindCss

I wanted to try some CSS frameworks outside from what I have already used like bootstrap and material. It does not feel different from the two.
JS Revealing Module Pattern (RMP)

I tried this pattern to practice closures in JS. RMP defines functions in closure areas and only use variables on access. I think this is a nice way of doing encapsulation, without all the boiler plate of OOP languages.

This is the 3rd entry of the series. They are very simple, tweaked exercises for the refresher topics in The Odin Project.

Github repository of the project can be found here

As always, cheers to continued learning 🍻!

To-Do List ✍️

patricianicole — Tue, 10 Aug 2021 01:31:27 +0000

Live preview and can be found here

About 👨‍🏫

The todo list have projects or separate lists of todos. When a user first opens the app, there is some sort of ‘default’ project called 'Home' to which all of the todos are put. Users can create new projects and choose which project their todos go into. localStorage is used to save user’s projects and todos between sessions.

WIL/Thoughts 🤔

Tried revisiting and reading about SOLID principles to properly write a maintable code.

📌 Single Responsibility Principle . Design classes/functions in a way that it is only doing ONE thing.

📌 Open/Closed Principle - For me , this is very difficult to apply. You really have to think carefully about each class design, its associations, relationships etc.

📌 Liskov Substitution Principle - It is like saying that a child can act as a proxy to the parent (my definition for simplicity 😆). I believe this is almost always enforced in OOP languages like Java.

📌 Interface Segregation Principle - In simple terms, interfaces should not force implementing classes to implement methods they do not need. That is why we have functional interfaces, interfaces with only one abstract method. This special type of interface enforces ISP.

📌 Dependency Inversion Principle - At first, I had trouble understanding what the second rule of this principle meant.

High-level modules should not depend on low-level modules. Both should depend on abstractions.

This is achievable by using constructs such as interfaces to facilitate loose coupling between modules.

Abstractions should not depend upon details. Details should depend upon abstractions.

I did not quite understand what it meant at first. After searching through the web, this 👇 is the best answer I found.

🥇 It means that if the details change they should not affect the abstraction. The abstraction is the way clients view an object. Exactly what goes on inside the object is not important. Lets take a car for example, the pedals and steering wheel and gear lever are abstractions of what happens inside the engine. They do not depend on the details though because if someone changes my old engine for a new one I should still be able to drive the car without knowing that the engine changed.

The details on the other hand MUST conform to what the abstraction says. I would not want to implement an engine that suddenly causes the brakes to double the speed of the car. I can re-implement brakes any way I want as long as externally they behave the same way.

And those are my WIL(What I Learned) thoughts for a very, very simple to-do project.

Check out the code of the exercise in this link

This project is taken from the The Odin Project todo list exercise.

As always cheers to continued learning 🍷!

What's the Weather? 🌦️

patricianicole — Tue, 03 Aug 2021 01:01:23 +0000

This is a JavaScript exercise I worked on under The Odin Project to get familiar with the basics of promises, callbacks and a little about async/await.

The live preview of this assignment can be found here. It is a weather forecast site using a weather API. The look of the page can change based on the description of the weather. The Giphy API is used to find weather related gifs and display them.

WIL/Thoughts 🤔

The most important thing I learned in this exercise is the basics of asynchronous JS, specifically callbacks and promises. I wrote my basic understanding of it in a different dev.to post. I also got acquainted with async and await but I am still to get comfortable of using these keywords.

📌 async

This tells the JS engine that the function is asynchronous. Functions with the async keyword automatically returns a promise. It is said that async is just a syntactical sugar for promises 😆 .

📌 await

This keyword can only be used inside a function prefixed with async. When used, it tells JS to wait for the value of the asynchronous function called. In promises, the then method is called on the function object returning a promise. By using await, you just need to assign the return object of an async function and treat the result just like any other variable.

📌 Cross-Origin Resource Sharing

When I tried working with the open-weather and giphy API, I encountered an error related to CORS. WIL was, browsers, by default do not allow HTTP requests to outside resources. Cross-origin requests are requests sent to another domain/protocol/port and they require special headers from the remote side. This is for security purposes. We would not want a script from a hacker site to access our twitter credentials (XD as to what I understood so far). The CORS request header would contain an Origin. If the server accepts the request, a special header Access-Control-Allow-Origin would be added in the response. The response would also contain the allowed origin(the requester URL) or probably a star, denoting all. The CORS request also have two types, safe and unsafe. Safe requests can be sent on the fly while unsafe requests need some "preflight" to check if the server permits the request.

As always, cheers to lifelong learning 🍷.

JavaScript Hoisting

patricianicole — Tue, 27 Jul 2021 01:06:33 +0000

[JS#5 WIL 🤔 Post]

JavaScript hoisting refers to the process where the compiler allocates memory for variable and function declarations prior to execution of code [1]. That means that declarations are moved to the top of their scope before code execution regardless of whether its scope is global or local.

Javascript Hoisting
Javascript Context Execution: Creation and Execution Phase
Default Values: undefined and ReferenceError
let hoisting and Temporal Dead Zone (TDZ)
Variable Hoisting
Function Hoisting
Conclusion

📌 Javascript Hoisting

Conceptually speaking,

hoisting is the compiler splitting variable declaration and initialization and moving only the declarations to the top of the code.

Thus, variables can appear in code before they are even defined. However, the variable initialization will only happen until that line of code is executed.

The code snippets below show hoisting in action. The first snippet shows how the code is expected to be written: declare the function first and use/invoke it after.

function printIamHoisted(str) {
   console.log(str);
}

printIamHoisted("Am I hoisted??")

On the snippet below, the method is invoked first, and the function declaration is written next. However, both of them have the same output - they print the string Am I hoisted?

printIamHoisted("Am I hoisted?")

function printIamHoisted(str) {
   console.log(str);
}

So even though the function is called before it is written, the code still works. This happens because of how context execution works in Javascript.

📌 Javascript Context Execution

When a Javascript engine executes code, it creates execution context. Each context has two phases: creation and execution.

📌 Creation Phase

When a script executes, the JS engine creates a Global Execution Context. In this phase, it performs the following tasks:

Create a global object window in the web browser
Create a this object binding which pertains to the global object
Setup memory for storing variables and function references
Store the declarations in memory within the global execution context with undefined initial value.

Lookin back at this snippet,

printIamHoisted("I am hoisted!!!")

function printIamHoisted(str) {
   console.log(str);
}

the global execution context at this phase, would somehow look like this .

📌 Execution Phase

At this phase, the JS engine executes the code line by line. But by virtue of hoisting, the function is declared regardless of line order, so there is no problem calling/invoking the method prior the declaration.

For every function call, the JS engine creates a new Function Execution Context. This context is similar to global execution context, but instead of creating the global object, it creates the arguments object that contains references to all the parameters passed to the function. The context during this phase would look somewhat like :

📌 Only the declarations (function and variable) are hoisted

JS only hoists declarations, not initializations. If a variable is used but it is only declared and initialized after, the value when it is used will be the default value on initialization.

📌 Default Values: `undefined` and `ReferenceError`

For variables declared with the var keyword, the default value would be undefined.

console.log(hoistedVar); // Returns 'undefined' from hoisted var declaration (not 6)
var hoistedVar; // Declaration
hoistedVar = 78; // Initialization

Logging the hoistedVar variable before it is initialized would print undefined. If however, the declaration of the variable is removed, i.e.

console.log(hoistedVar); // Throw ReferenceError Exception
hoistedVar = 78; // Initialization

a ReferenceError exception would be thrown because no hoisting happened.

📌 `let` hoisting: Temporal Dead Zone (TDZ)

Variables declared with let and const are also hoisted. However, unlike variables declared with var, they are not initialized to a default value of undefined. Until the line in which they are initialized is executed, any code that access them, will throw an exception. These variables are said to be in a "temporal dead zone" (TDZ) from the start of the block until the initialization has completed. Accessing unintialized let variables would result to a ReferenceError.

{ // TDZ starts at beginning of scope
  console.log(varVariable); // undefined
  console.log(letVariable); // ReferenceError
  var varVariable = 1;
  let letVariable = 2; // End of TDZ (for letVariable)
}

The term "temporal" is used because the zone depends on the execution order (referring to time - temporal) rather than the order in which the code is written (position). However, the code snippet below will work because even though sampleFunc uses the letVariable before it is declared, the function is called outside of the TDZ.

{
    // TDZ starts at beginning of scope
    const sampleFunc = () => console.log(letVariable); // OK

    // Within the TDZ letVariable access throws `ReferenceError`

    let letVariable = 97; // End of TDZ (for letVariable)
    sampleFunc(); // Called outside TDZ!
}

📌 Variable Hoisting

Remember that all function and variable declarations are hoisted to the TOP of the scope. Declarations are processed before any code is executed. With this, undeclared variables do not exist until the code assignment is executed. Variable assignment to an undeclared variable implicitly creates it as a global variable when the assignment is executed. That means that any undeclared variable (but assigned) is a global variable.

function demo() {
   globalVar = 34;
   var functionScopedVar = 78;
}

demo();
console.log(globalVar); // Output: 34
console.log(functionScopedVar) // throws a ReferenceError

This is why it is always good to declare variables regardless of whether they are of function or global scope.

📌 ES5 Strict Mode

Introduced in EcmaScript 5, strict mode is a way to opt in to a restricted variant of JS. Strict mode make several changes to normal JS semantics

Eliminates silent errors by throwing them
Prohibits syntax that might be defined in future version of ES
Fix mistakes that make JS engines perform optimizations

With regards to hoisting, using strict mode will not tolerate the use of variables before they are declared.

📌 Function Hoisting

JS functions can be declarations or expressions.

Function declarations are hoisted completely to the top. That is why a function can be invoked even before it is declared.

amIHoisted(); // Output: "Yes I am."
function amIHoisted() {
   console.log("Yes I am.")
}

Function expressions, are NOT hoisted. This is because of the precedence order of JS functions and variables. The snippet below would throw a TypeError because the hoisted variable amIHoisted is treated as a variable, not a function.

amIHoisted(); //Output: "TypeError: expression is not a function
var amIHoisted = function() {
   console.log("No I am not.");
}

The code execution of the code above would somehow look like this

var amIHoisted; // undefined
amIHoisted(); 
/*Function is invoked, but from the interpreter's perspective it is not a function. 
Thus would throw a type error
*/
amIHoisted = function() {
   console.log("No I am not.");
}
/*The variable is assigned as a function late. It was already invoked before the assignment.*/

📌 Hoisting Order of Precedence

Variable assignment takes precedence over function declaration. The type of amIABoolean would be a boolean because the variable is assigned to a value true.

var amIABoolean = true;

function amIABoolean() {
  console.log("No.")
}

console.log(typeof amIABoolean); // Output: boolean

Function declarations take precedent over variable declarations. From the snippet below, the type of amIAFunction would be a function because on the first line, the variable is only declared, not assigned. Since function declarations takes precedence, it is resolved to type function.

var amIAFunction;

function amIAFunction() {
  console.log("Yes.")
}

console.log(typeof amIAFunction); // Output: function

Conclusion

Hoisting in JS is the compiler splitting variable declaration and initialization and moving only the declarations to the top of the code. So even though the functions and variables are called/used before they are written, the code still works. This happens because of how context execution works in Javascript.

Note that only declarations are hoisted, not initializations. For variables declared with the var keyword, the default value would be undefined. For let variables, until the line in which they are initialized is executed, any code that access them, will throw an exception. These variables are said to be in a "temporal dead zone" (TDZ) from the start of the block until the initialization has completed. Accessing unintialized let variables would result to a ReferenceError.

That is it for the basics of JS hoisting, my fifth WIL(What I Learned) dev post 😄.

As always, cheers to lifelong learning 🍷!

[REFERENCES]

Java Annotations

patricianicole — Tue, 20 Jul 2021 02:34:02 +0000

📌 Annotation Basics

Annotations, a form of metadata, provide data about a program that is not part of the program itself. It has no direct effect on the operation of the code they annotate.

Annotations hava a number of uses

Information for the compiler. Annotations can be used by the compiler to detect errors or supress warnings.
Compile-time and deployment time processing. Software tools can process annotation information to generate code, XML files and so forth.
Runtime processing. Some annotations are available to be examined at runtime.

📌 Declaring an Annotation Type

The simplest format of an annotation looks like

@Entity

The @ (sign character) indicates to the compiler that what follows is an annotation. The annotation above has a name Entity.

Annotations can also include elements which can be named or unnamed. For instance,

@Author(
   name = "Benjamin Franklin",
   date = "3/27/2003"
)

If there is only one element named value, then the name can be omitted, as in:

@SuppressWarnings("unchecked")
void myMethod() { ... }

If the annotation has no elements, then the parentheses can be omitted,

@Override
void mySuperMethod() { ... }

It is also possible to use multiple annotations on the same declaration.

@Author(name = "Jane Doe")
@EBook
class MyClass { ... }

If the annotations have the same type, then that would be a repeating annotation.

@Author(name = "Jane Doe")
@Author(name = "John Smith")
class MyClass { ... }

The annotation type can be one of the types that are defined in the java.lang or java.lang.annotation packages, like @Override and @SuppressWarnings, which are predefined Java annotations. It is also possible to define your own annotation type, i.e. custom annotations.

Where Can Annotation Be Used

Annotations can be applied to declarations: classes, fields, methods and other program elements.

As of Java 8, annotations can be applied to the use of types. This form of annotation is called a type annotation.

Class instance creation expression

new @Interned MyObject();

Type Cast

myString = (@NonNull String) str;

implements clause

class UnmodifiableList<T> implements
        @Readonly List<@Readonly T> { ... }

Thrown exception declaration

void monitorTemperature() throws
        @Critical TemperatureException { ... }

Defining the annotation type

The syntax for doing this is:

@interface ClassPreamble {
   String author();
   String date();
   int currentRevision() default 1;
   String lastModified() default "N/A";
   String lastModifiedBy() default "N/A";
   // Note use of array
   String[] reviewers();
}

The annotation type definitions looks similar to an interface definition where the keyword interface is preceded by the @ sign. Annotations are a form of interface. The body of the annotation definition contains annotation type element declaration, which look a lot like methods. They can also be defined with default values filled in.

NOTE: To make the information of an annotation appear in Javadoc-generated documentation, it must be annotated with the @Documented annotation.

📌 Predefined Annotation Types

A set of annotation types are predefined in the Java SE API.

Annotation Types Used by the Java Language

The predefined annotation types defined in java.lang are : @Deprecated, @Override, and @SuppressWarnings.

@Deprecated. This indicates that the marked element is deprecated and should no longer be used. The compuler generates a warning whenever a program uses a method, class, or field with this annotation. When an element is deprecated it should also be documented using the Javadoc @deprecated tag.

// Javadoc comment follows
    /**
     * @deprecated
     * explanation of why it was deprecated
     */
    @Deprecated
    static void deprecatedMethod() { }

@Override. This informs the compiler that the element is meant to override an element declared in superclass. While it is not required to use this annotation when overriding a method, it helps to prevent errors. If a method marked with @Override fails to correclty override a method in one of its superclasses, the compiler generates an error.
@SupressWarnings. This tells the compiler to suppress specific warnings that it would otherwise generate. For instance,

// use a deprecated method and tell 
   // compiler not to generate a warning
   @SuppressWarnings("deprecation")
    void useDeprecatedMethod() {
        // deprecation warning
        // - suppressed
        objectOne.deprecatedMethod();
    }

Every compiler warning belongs to a category. The Java language specification lists two categories: deprecation and unchecked. Unchecked warnings occur when interfacing with legacy code written before the advent of generics.

@SafeVarargs . When applied to a method or constructor, this asserts that the code does not perform potentially unsafe operations on its varargs parameter. When this annotation is used, unchecked warnings related to varargs are suppressed.
@FunctionalInterface. Introduced in Java 8, this indicates that the type declaration is intended to be a functional interface.

Annotations that Apply to Other Annotations

Annotations that apply to other annotations are called meta-annotations. There are several meta-annotations defined in java.lang.annotation.

@Retention. This specifies how the marked annotation is stored.
- RetentionPolicy.SOURCE. The marked annotation is retained only in the source level and is ignored by the compiler.
- RetentionPolicy.CLASS. The marked annotation is retained by the compiler at compile time, but is ignored by JVM.
- RetentionPolicy.RUNTIME. The marked annotation is retained by the JVM so it can be used by the runtime environment.
@Documented. This indicates that whenever the specified annotation is used, those elements should be documented using the Javadoc tool (By default, annotations are not inclueded in the Javadoc).
@Target. This annotation marks another annotation to restrict what kind of Java elements the annotation can be applied to. A target annotation specifies one of the ff. element.
- ElementType.ANNOTATION_TYPE. This can be applied to an annotation type.
- ElementType.CONSTRUCTOR. This can be applied to a constructor.
- ElementType.FIELD. This can be applied to a field or property.
- ElementType.LOCAL_VARIABLE. This can be applied to a local variable.
- ElementType.METHOD. This can be applied to a method level annotation.
- ElementType.PACKAGE. This can be applied to a package declaration.
- ElementType.PARAMETER. THis can be applied to the parameters of a method.
- ElementType.TYPE. This can be applied to any element of a class.
@Inherited. This indicates that the annotation type can be inherited from the superclass (not true by default). When the user queries the annotation type and the class has no annotation for this type, the class' superclass is queried for the annotation type. This can only be applied to class declarations.
@Repeatable. Introduced in Java 8, this indicates that the marked annotation can be applied more than once to the same declaration or type use.

📌 Type Annotations and Pluggable Type Systems

Before Java 8, annotations can only be applied to declarations. After Java 8's release, annotations can also be applied to any type use. This meant that annotations can be used anywhere where type is used., e.g. instance creation expressions (new), casts, implements clauses and throws clauses. This form of annotation is called type annotation.

Type Annotations were created to support improved analysis of Java programs way of ensuring stronger type checking. The Java SE 8 release does not provide a type checking framework, but it allows developers to write (or download) a type checking framework that is implemented as one or more pluggable modules that are used in conjunction with the compiler.

For instance, a custom plug-in check can be used to ensure that a certain variable is never assigned null.

@NonNull String str;

When this code is compiled including the NonNull module, the compiler prints a warning if it detects a potential problem, allowing developers to modify the code to avoid the error. After the code is corrected, this particular error will not occur when the program runs.

With the judicious use of type annotations and presence of pluggable type checkers, the code can be stronger and less prone to error.

There are a lot of existing libraries for type checking modules. For example the Checker Framework created by University of Washington. This framework includes a NonNull module, as well as regular expression module and a mutex lock module. See this for more information.

📌 Repeating Annotations

As of Java 8 release, repeating annotations are introduced which enables developers to use the same annotation to a declaration or type use.

Steps in Creating a Repeatable Annotation

Declaring Repeating Annotations The annotation type must be marked with the @Repeatable metannotation. For instance

@Repeatable(Schedules.class)
public @interface Schedule {
  String dayOfMonth() default "first";
  // ...
}

The value of the @Repeatable meta-annotation, in parentheses, is the type of the container annotation that the Java compiler generates to store repeating annotations. In this example, the containing annotation type is Schedules, so repeating @Schedule annotations is stored in an @Schedules annotation.

Applying the same annotation to a declaration without first declaring it to be repeatable results in a compile-time error.

Declare the Containing Annotation Type The containing annotation type must have a value element with an array type. The component type of the array type must be the repeatable annotation type. The declaration for the Schedules containing annotation type is the following:

public @interface Schedules {
    Schedule[] value();
}

Retrieving Annotations

There are several methods available in the Reflection API that can be used to retrieve annotations. The behavior of the methods that return a single annotation, such as AnnotatedElement.getAnnotation(Class<T>), are unchanged in that they only return a single annotation if one annotation of the requested type is present. If more than one annotation of the requested type is present, you can obtain them by first getting their container annotation. In this way, legacy code continues to work. Other methods were introduced in Java SE 8 that scan through the container annotation to return multiple annotations at once, such as AnnotatedElement.getAnnotationsByType(Class<T>).

Design Considerations

When designing an annotation type, the cardinality of annotations of that type must be considered. It is now possible to use an annotation zero times, once, or, if the annotation's type is marked as @Repeatable, more than once. It is also possible to restrict where an annotation type can be used by using the @Target meta-annotation. It is important to design annotation types carefully to ensure that the person using the annotation finds it to be as flexible and powerful as possible.

As always, cheers to lifelong learning!! 🍷

REFERENCES

Java Documentation: Annotations

Java Nested Classes and Lambda Expressions

patricianicole — Sun, 11 Jul 2021 09:35:48 +0000

[Java WIL🤔 Post #2]

Java has a very rich set of features that gives developers a lot of options to choose their implementation from, two of them, nested classes and lambda expressions.

I was reading a certain part of a code base and realized that I have not really fully understood the differences between the types of nested classes. The section below is heavily based from the Java Documentation for Nested Classes, so in-depth explanations can be checked here.

Nested Classes
Why Use Nested Classes
Inner Classes
Static Nested Classes
Shadowing in Nested Classes
Serialization of Nested Classes
Local and Anonymous Classes
Lambda Expressions
Functional Interface
Target Typing In Lambdas
Method References
When to Use Nested Classes, Local Classes, Anonymous Classes and Lambda Expressions

📌 Nested Classes

A nested class is a class within another class, i.e. a member of its enclosing class. It is divided into two categories: non-static and static.

Non-static nested classes are called inner classes. They have access to other members of the enclosing class, even if they are declared private.
Nested classes that are declared static are called static nested classes. They DO NOT have access to other members of the enclosing class.
As a member of the outer class, a nested class can be declared private, public, protected or package-private.
Note that outer classes can only be declared public or package-private.

📌 Why Use Nested Classes

It is a way of logically grouping classes that are only used in one place.
It increases encapsulation.
It can lead to more readable and maintainable code.

📌 Inner Classes

An inner class is associated with an instance of its enclosing class and has direct access to that object's methods and fields.
As an inner class is associated with an instance, IT CANNOT DEFINE ANY STATIC MEMBERS ITSELF..
Objects that are instances of an inner class exist within an instance of the outer class. Thus an instance of an inner class can only exist within an instance of the outer class and has direct access to the methods and fields of the enclosing instance.
To instantiate an inner class, the outer class must first be instantiated.
There are two special kinds of inner classes: local classes and anonymous classes.

public class OuterClass {
    private class InnerClass {
        // class content here
    }
}

📌 Static Nested Classes

As with class methods, a static nested class is associated with its outer class.
A static nested class cannot refer directly to instance variables or methods defined in its enclosing class. It can use them only through an object reference.
A static nested class interacts with the instance members of its outer class and other classes just like any other top level class. Thus a static nested class is behaviorally a top-level class that has been nested in another top-level class for packaging convenience.

public class OuterClass {
    static class StaticNestedClass {
       // class contents here
    }
}

📌 Shadowing in Nested Classes

If a declaration of a type in a particular scope has the same name as another declaration in the enclosing scope, then the declaration shadows the declaration of the enclosing scope.
The shadowed declaration cannot be referenced by its name alone. Note, you can actually do this : ShadowTest.this.x. Go to shadowing section of this link.
Refer to member variables that enclose larger scopes by the class name to which they belong. For example, the ff. statement accesses the member variable of the class ShadowTest from the method.

System.out.println("ShadowTest.this.x = " + ShadowTest.this.x);

📌 Serialization

Serialization of inner classes, including local and anonymous classes is strongly discouraged. When the Java compiler compiles certain constructs such as inner classes, it creates synthetic constructs; these are classes, methods, fields and other constructs that do not have a corresponding construct in the source code. Synthetic constructs enable Java compilers to implement new Java language features without changes to the JVM. However, they may vary among different implementations.
Might have compatibility issues if an inner class is serialized and then deserialize it with a different JRE implementation.
Read more at the Serialization section of this link

📌 Local and Anonymous Classes

There are two types of inner classes : local and anonymous. An inner class within the body of a method is called a local class. An inner class can also be declared inside the body of a method without naming them, i.e. an anonymous class.
The same modifiers used for other members of the outer class can be used for an inner class. For instance the access modifiers private, public, package-private protected can be used in an inner class just like how they are used for the instance fields of the outer class.

📌 More on Local Classes

public class SomeClass {
    public void someMethod() {
        class SomeLocalClass {
            // class contents here
        }
    }
}

Local classes are classes defined in a block, which is a group of zero or more statements.
Local classes can be defined inside any block, i.e. in a method body, a for loop or an if clause.
A local class has access to the members of its enclosing class. It also has access to local variables.
IMPORTANT: A local class can only access local variables that are declared final. When a local class accesses a local variable or parameter of the enclosing block, it captures the variable or parameter.
Starting Java 8, a local class can access local variables and parameters of the enclosing block that are final or effectively final. A variable or parameter whose value is never changed after it is initialized is effectively final.
Starting also in Java SE 8, if you declare the local class in a method, it can access the method's parameters.
Local classes are similar to inner classes because they cannot define or declare any static members.
Local classes in static methods, can only refer static members of the enclosing classes.
Local classes are non-static because they have access to instance members of the enclosing block. Consequently they cannot contain most kinds of static declarations.
An interface cannot be declared inside a block. Interfaces are inherently static.
Static initializers or member interfaces cannot be declared inside a local class.
A local class can have static members provided that they are constant variables. A constant variable is a variable of primitive type or type String that is declared final and initialized with a compile-time constant expression. A compile time constant expression is typically a string or an arithmetic expression that can be evaluated at compile time.

📌 Anonymous Classes

    SomeAnonyMousClass anonClass = new SomeAnonyMousClass(){
        // instance field declarations
        // methods 
        // should contain no constructor
    };

Anonymous classes makes the code more concise. It enables declaration and instantiation of class at the same time. They are similar to local classes except that they do not have a name.
While local classes are class declaration, anonymous classes are expressions, which means that the class is defined in another expression.
The syntax of an anonymous class expression is like the invocation of a constructor, except that there is a class definition contained in the code block.

HelloWorld helloWorld = new HelloWorld() {
  // code here
};

The anonymous class expression consists of the following: new operator, the name of an interface to implement or a class to extend, parentheses that contain the arguments to a constructor, just like a normal class instance creation expression and a body, which is a class declaration body.
Because an anonymous class definition is an expression, it must be part of a statement. This explains why there is a semicolon after the closing brace.

📌 Accessing Local Variables of the Enclosing Scope and Declaring and Accessing Members of the Anonymous Class

Like local classes, anonymous classes can capture variables; they have the same access to local variables of the enclosing scope.
An anonymous class has access to the members of its enclosing class.
An anonymous class cannot access local variables in its enclosing scope that are not declared as final or effectively final.
Like a nested class, a declaration of a type in an anonymous class shadows any other declarations in the enclosing scope that have the same name.
Anonymous classes also have the same restrictions as local classes with respect to their members: static initializers or member interfaces cannot be declared; an anonymous class can have static members provided that they are constant variables.
Note, the ff can be declared in anonymous class a. Fields b. extra methods c. instance initializers d. local classes
IMPORTANT: You cannot declare constructors in an anonymous class.
Anonymous classes are ideal for implementing an interface that contains two or more methods.

To summarize the hierarchy stated above, the image below shows the types of nested classes.

📌 Lambda Expressions

Lambda Expressions enables developers to treat functionality as a method argument, or code as a data.
For classes with only one method, an anonymous class, much more a named class is a bit excessive and cumbersome. Lambdas express instances of single-method classes more compactly.

📌 Syntax of Lambda Expressions

A lambda expression consists of the ff.

A comma-separated list of formal parameters enclosed in parentheses. The data type of the parameters in the lambda expression can be omitted. Moreover, the parentheses can be omitted if there is only one parameter.
The arrow token ->
The body which consists of a single expression or a statement block. The return statement can also be used, however, keep in mind that a return statement is not an expression in lambdas, so they must be enclosed in braces. Lambdas can be treated as anonymous methods - methods without names. For instance,

p -> p.getAge() >= 18
    && p.getAge() <= 25

📌 Functional Interface

A functional interface is any interface that contains only one abstract method. It may contain one or more default methods or static methods. Because it only contains one abstract method, the name can be omitted when implementing it. By doing this instead of using an anonymous class expression, a lambda expression is used. The JDK defines several standard functional interfaces which can be found in the package java.util.function.

📌 Accessing Local Variables of the Enclosing Scope in Lambda Expressions

Like local and anonymous classes, lambdas can capture variables; they have the same access to local variables of the enclosing scope. However, unlike local and anonymous classes, lambdas do not have shadowing issues.
Lambdas are lexically scoped. This means that they do not inherit any names from a supertype or introduce a new level of scoping. Declarations in lambdas are interpreted just as they are in the enclosing environment.
If the parameter passed to a lambda is declared in the enclosing scope, then the compiler generates an error, Lambda expression's parameter {} cannot redeclare another local variable defined in an enclosing scope. This is because lambda expressions do not introduce a new level of scoping. Consequently, lambdas can directly access fields, methods and local variables of the enclosing scope.
Like local and anonymous classes, a lambda expression can only access local variables and parameters of the enclosing block that are final or effectively final (value should not be changed after initialization).

📌 Target Typing in Lambdas

So how can the type of a lambda expression be determined, e.g. the type of p in the example below?

p -> p.getAge() < 18

When the Java runtime invokes the method where the lambda is passed, it is expecting a specific datatype, so the lambda expression is of this type.The data type that these methods expect is called the target type. To determine the type of a lambda expression, the Java compiler uses the target type of the context or situation in which the lambda expression was found. Thus, lambda expressions can only be used in situation in which the Java compiler can determine the target type, i.e. in :

variable declarations
assignments
return statements
array initializers
method or constructor arguments
lambda expression bodies
conditional expressions
cast expressions

📌 Target Types and Method Arguments

For method arguments, the Java compiler determines the target type with two other language features overload resolution and type argument interface.

For instance, if the functional interfaces java.lang.Runnable and java.util.Callable<V> are implemented and overloaded by a certain class like this,

void invoke(Runnable r) {
    r.run();
}

<T> T invoke(Callable<T> c) {
    return c.call();
}

Which method will be invoked by the statement below?

String s = invoke(() -> "done");

The method with argument Callable<V> will be invoked because the lambda returns a value, in this case the string done. Note that the method invoke(Runnable) does not return a value.

📌 Serialization of Lambdas

A lambda can be serialized if its target type and its captured arguments are serializable. However, like inner classes, 🛑 the serialization of lambdas are strongly discouraged.

📌 Method References

Lambdas can be used to create anonymous methods. However, there are times when it does nothing but call an existing method. In these cases, it is often clearer to refer to the existing method by name, called method referencing. They are compact, easy-to-read lambdas for methods that already have a name.
For instance this can be done in sorting an array of Person objects by age.

Arrays.sort(personListAsArray, Person::compareByAge);

The method reference Person::compareByAge is semantically the same as the lambda expression where compareByAge is a static method of the Person class.

(person1, person2) -> Person.compareByAge(person1, person1)

Kinds of Method References

There are four types of method referencing

Kind	Syntax	Example
Reference to a static method	`ContainingClass::staticMethodName`	`Person::compareByAge`
Reference to an instance method of a particular object	`containingObject::instanceMethodName`	`person1::compareByName`
Reference to an instance method of an arbitrary object of a particular type	`ContainingType::methodName`	`String::concat`
Reference to a constructor	`ClassName::new`	`HashSet::new`

📌 When to Use Nested Classes, Local Classes, Anonymous Classes and Lambda Expressions

Nested Classes enable the logical grouping of classes that are only used in one place, increase the use of encapsulation, create more readable and maintainable code. Local classes, anonymous classes and lambda expressions also share the same advantages but they are usually used for more specific situations:

Local Class . Used if creating more than one instance of a class is needed, access its constructor and/or introduce a new, named type.
Anonymous Class . Used if declared fields or additional methods are needed
Lambda Expressions .
- Used for encapsulating a single unit of behavior that is passed to the other parts of the code.
- Used if a simple instance of a functional interface is needed and some other criteria like constructor, named type, fields or additional methods are not needed
Nested Class . Used for reasons similar to those of local classes, i.e. it is necessary to make the type more widely available, and access to local variables or method parameters are not needed.
- Inner class should be used if access to an enclosing instance's non-public fields and methods are required.
- Static class should be used if there is no instance field that needs to be accessed from the class.

Getting used and familiar with nested classes and advanced lambdas with generics certainly takes a lot of reading code and practice. We will eventually get there.

As always, cheers to continued growth and learning 🍷!

REFERENCES

[1] Java Nested Classes
[2] Nested Classes in Java

Basics of Javascript Test Driven Development (TDD) with Jest

patricianicole — Sun, 04 Jul 2021 06:21:34 +0000

[JS#4 WIL 🤔 Post]

Test Driven Development (TDD)'s main idea is to simply start working on code by writing automated tests BEFORE writing the code that is being tested. There are many test-running systems in Javascript: Jasmine, Jest, Tape, and Mocha to name a few. They have their special features but the syntax is very similar. The framework chosen should not be an issue because

writing tests is less about the syntax but more on the TDD philosophy,

so I tried internalizing the concepts using Jest. My main goal while doing the exercise is to know the why's and whats of testing.

Before diving in, here are some notes I took from this brilliant talk, The Magic of Testing.

Why does most devs hate tests? Because they are slow and fragile and expensive (time).
It is perfectly valid to delete some tests.
Unit Test Goals: They must be thorough (we want them to prove logically and completely that the single object under test is behaving correctly) and stable (we dont want to break the test everytime the implementation detail is changed 😟), fast and few (write tests for the most parsimonious expression [mmmmmm 🤔]).
Do not test private methods. But break this rule if it saves money during development.
A mock is a test double, it plays the role of some object in your real app. Ensure test double stays in sync with the API.
Trust collaborators that they will do the right thing. Insist on simplicity.
Getting better at testing takes time and practice.

The object under test have three origin of messages :

📌 Incoming - messages to the object from outside
📌 Self - messages sent by the object under test to itself
📌 Outgoing - messsages sent by the object to the outside.

There are two types of messages : query and command. Queries return something or changes nothing. Command types return nothing but changes something.

📌 Grid of Test Rules

The grid of test results below shows how each type of message can be unit tested.

Message Type	Query	Command
Incoming	Assert result Test incoming query messages by making assertions about what they send back. Test the interface and not the implementation.	Test incoming command messages by making assertions about direct public side effects. DRY it out. Receiver of incoming message has sole responsibility for asserting the result of direct public side effects.
Sent to Self	Ignore: Do not test private methods.	Ignore: Do not test private methods.
Outgoing	Ignore. The receiver of an incoming query is solely responsible for assertions that involve state. If a message has no visible side effects, the sender should not test it	Expect to send outgoing command messages using mocks

📌 Advantages of TDD

Reduces bugs that may be introduced when adding new features or modifying existing features
Builds a safety net against changes of other programmers that may affect a specific part of the code
Reduces the cost of change by ensuring that the code will still work with the new changes
Reduces the need for manual (monkey) checking by testers and developers
Improves confidence in code
Reduces the fear of breaking changes during refactors

📌 Getting Started with Jest

Jest is a javascript testing framework focusing on simplicity but still ensures the correctness of the Javascript code base. It boasts itself to be fast and safe, reliably running tests in parallel with unique global state. To make things quick, Jest runs previously failed tests first and re-organizes runs based on how long test files take.

Moreover, Jest is very well-documented and requires little configuration. It indeed makes javascript testing delightful. It can be installed by using either yarn or npm.

📌 Three Modes of TDD

Obvious implementation. You write the test with the implementation since you know how to implement the method to test.
Fake it til you make it. If you know the problem and solutions, but the way you code them up is not immediately obvious to you, then you can use a trick called "fake it 'til you make it."
Triangulation . This is the most conservative way of doing TDD. If you don't even know the solution, you just get to green at all costs , red-green, red-green loop.

📌 Using Jest Matchers

Common Matchers

The simplest way to test a value is with exact equality.

test('adds 1 + 2 to equal 3', () => {
  expect(sum(1, 2)).toBe(3);
});

The code snippet above returns an "expectation" object. The toBe(3) portion is the matcher. When Jest runs, it tracks all the failing matchers so it can print nice error messages. The toBe matcher uses Object.is to test the equality.

Truthiness

In unit tests, the special values undefined, null, false might be needed to be checked also. Jest contains helpers that lets developers be explicit with what to expect. It is then good to use a matcher that most precisely corresponds to what the code is doing.

toBeNull matches only null
toBeUndefined matches only undefined
toBeDefined is the opposite of toBeUndefined
toBeTruthy matches anything that an if statement treats as true
toBeFalsy matches anything that an if statement treats as false

Numbers

There are also Jest matchers for comparing numbers such as toBeGreaterThan, toBeGreaterThanOrEqual, toBeLessThan, toBeLessThanOrEqual. For floating point numbers, there are equality matcher like toBeCloseTo.

Strings

Strings can be checked against regular expressions using toMatch.

Arrays and Iterables

toContain can be used to check if a particular item can be found in an array or iterable.

Exceptions

toThrow can be used to check if a particular function throws a specific error. It is to be noted that the function being checked needs to be invoked within a wrapping function for the toThrow exception to work.

There are also more advanced Jest matchers used for testing asynchronous code, i.e for callbacks and promises.

📌 Jest Testing Practice

This is my first time writing javascript unit tests using Jest. It is quite new so I needed some practice 😄. I tried using the obvious implementation and triangulation mode of testing for some of the methods below. The full implementation of the methods and their corresponding tests can be found in my Jest practice github repository.

capitalize(string) takes a string and returns that string with the first character capitalized.

capitalize.test.js

const capitalize = require('../capitalize');

test('should capitalize lowercase string correctly', () => {
  expect(capitalize("capitalize")).toBe("Capitalize");
});

test("should return '' for strings with length 0", () => {
    expect(capitalize("")).toBe("");
});

// other tests here

reverseString(string) takes a string and returns it reversed. Below is a snippet of the test I wrote for a normal scenario.

reverse-string-test.js

const reverseString = require('../reverse-string');

test('should reverse normal strings', () => {
  expect(reverseString("reverse")).toBe("esrever");
});

//other tests here

A calculator object that contains the basic operations: add, subtract, divide, and multiply. The following test snippet below shows that the method will throw an error message if the divisor is zero.

calculator.test.js

const calculator = require("../calculator");

//other tests here

test("should throw an error if divisor is 0", () => {
    expect(() => calculator.divide(20, 0)).toThrow("cannot divide by 0");
});

caesar cipher. A caesar cipher is a substitution cipher where each letter in the text is shifted a certain places number down the alphabet. More info can be read here.

One thing to remember from this part of the exercise is that it is not needed to explicity test the smaller functions, just the public ones. If the larger function works then it must be the case that the helper methods are functioning well.

caesar-cipher.test.js

const caesar = require("../caesar-cipher");

//other tests here

test('wraps', function() {
    expect(caesar('Z', 1)).toEqual('A');
});

test('works with large shift factors', function() {
    expect(caesar('Hello, World!', 75)).toEqual('Ebiil, Tloia!');
});

test('works with large negative shift factors', function() {
    expect(caesar('Hello, World!', -29)).toEqual('Ebiil, Tloia!');
});

Array Analysis. This function takes an array of numbers and returns an object with the following properties: average, min, max, and length.

analyze.test.js

const analyze = require("../analyze");
const object = analyze([1,8,3,4,2,6]);

test("should return correct average", () => {
    expect(object.average).toEqual(4);
});

test("should return correct min", () => {
    expect(object.min).toEqual(1);
});

// other tests here

Check out the github repository of the included snippets in here for a complete picture of the tests.

The concepts and points above are the very basics of TDD using Jest. There are a lot more to learn, from more advanced matchers, mocking, testing asynchronous parts of the code, and others. I am still to learn them and that is for another dev post 😆.

Cheers to continued learning! 🍷

[REFERENCES]

Core Concepts behind Java OOP

patricianicole — Tue, 29 Jun 2021 00:43:25 +0000

[Java WIL🤔#1]

I am reviewing for an Oracle Java Certification exam and decided to run through the documentation of Java's Nuts and Bolts. Check out the github repository for other review bullet points. Here are my notes for the core concepts behind Java's object-oriented programming (OOP).

📌 What are Objects

An object is a software bundle of related state and behavior. Software objects are often used to model real-world objects found in everyday life

Real world observations all translate into the world of object-oriented programming. Real-world objects share two characteristics, they all have state and behavior.
Software objects are conceptually similar to real-world objects; they too, consist of state and related behavior. An object stores its state in fields and exposes its behavior through methods.
Methods operate on an object's internal state and serve as the primary mechanism for object-to-object communication.
Hiding internal state and requiring all interaction to be performed through an object's method is known as data ecapsulation.
By attributing state and providing methods for changing that state, the object remains in control of how the outside world is allowed to use it.
Building code into individual software objects provide a number of benefits, including:
- Modularity : The source code for an object can be written and maintained independently of the source code for other projects. Once created, an object can be easily passed around inside the system.
- Information Hiding. By interacting only with an object's methods, the details of its internal implementaion remain hidden from the outside world.
- Code reuse : If an object already exists (might have been written by another programmer), that can be used in the program. This allows specialists to implement/test/debug complex, task-specific objects, which can then be trusted in your own code.
- Pluggability and Debugging Ease . If a particular object turns out to be problematic, it can simply be removed from the application and plug in a different object as a replacement. Similar to fixing a mechanical problem in the real world, if a bolt breaks, it can be replaced, but not the entire machine.

📌 What are Classes

A class is a blueprint or prototype from which objects are created.

In real world, many individual objects have the same kind, i.e. they are built from the same set of blueprints and therefore contains the same components.
In object-oriented terms, a class is the blueprint from which individual objects are created.

📌 What is Inheritance

Inheritance provides a powerful and natural mechanism for organizing and structuring software.

Different kinds of objects often have a certain amount in common with each other. Yet, each also defines additional features that make them different.
OOP allows classes to inherit commonly used state and behavior from other classes.
In Java, each class is allowed to have one direct superclass and each superclass has the potential for an unlimited number of subclasses.

📌 What are Interfaces

An interface is a contract between a class and the outside world. When a class implements an interface, it promises to provide the behavior published by that interface.

Methods form the object's interface with the outside world.
In its most common form, an interface is a group of related methods with empty bodies.
Implementing an interface allows a class to become more formal about the behavior it promises to provide.
Interfaces form a contract between the class and the outside world and this contract is enforced at build time by the compiler.
If the class claims to implement an interface, all methods defined by that interface must appear in its source code before the class will successfully compile.

📌 What are Packages

A package is a namespace for organizing classes and interfaces in a logical manner. Placing code into packages makes large software projects easier to manage.

A package is a namespace that organizes a set of related classes and interfaces. Conceptually they are similar to folders in a computer.
Because the program might be composed of hundreds and thousands of individual classes, it makes sense to keep things organized by placing related classes and interfaces into packages.
The Java platform provides an enormous class library (a set of packages) suitable for use in applications. This library is known as the "Application Programming Interface (API)". Its packages represent tasks most commonly associated with general-purpose programming. The Java Platform API Specification contains the complete listing for all packages, interfaces, classes, fields and methods supplied by the Java SE plaform.

❓ Quiz Time

NOTE: These questions are the review questions in the Java documentation.

Real-world objects contain ❓ and ❓. Real-world objects contain states and behaviors. A software object's state is stored in ❓. A software object's state is stored in fields. A software object's behavior is exposed through ❓. A software object's behavior is exposed through methods. Hiding internal data from the outside world, and accessing it only through publicly exposed methods is known as ❓. Hiding internal data from the outside world, and accessing it only through publicly exposed methods is known as data encapsulation. A blueprint for a software object is called a ❓. A blueprint for a software object is called a class. Common behavior can be defined in a ❓ and inherited into a ❓ using the ❓ keyword. Common behavior can be defined in a superclass and inherited into a subclass using the extends keyword. A collection of methods with no implementation is called an ❓. A collection of methods with no implementation is called an interface. A namespace that organizes classes and interfaces by functionality is called a ❓. A namespace that organizes classes and interfaces by functionality is called a package. The term API stands for ❓ ? The term API stands for Application Programming Interface.

[REFERENCES]

[1] Java OOP Concepts

Coding is NOT not for girls.

patricianicole — Mon, 21 Jun 2021 16:12:49 +0000

She Coded, 2021 👧

📌 My two cents

It is a consensus that the IT industry is a male-dominated field. I know for a fact that most women are less inclined to pursue tech as a career - probably due to genetics, or because of society-imposed gender roles.

Yes, it can be intimidating to approach and be part of a "mostly-guy" team because there will always be differences in interests. However, from experience,I have women workmates and classmates who are just as good as the guys from the team.

When it comes to work, I think about it like this.

Both men and women have two hands. Both of them have brains and two eyes. Aren't those enough to code? Last time I checked, there is no gender requirement in coding and people should internalize that. Coding is not, not for girls. Coding is not, not for guys. Coding is for people who likes to code, whether that be for a living, or as a hobby 💁.

💻 And thus, I started coding.

Honestly, at first, I am not very interested in programming. I entered computer science just because it was the most feasible choice for me that time. It is not taught in my high school so I was a little behind from my college classmates who had programming classes already. Our class composition was around 40% girls, 60% boys. I think I can say that all of them are equal in terms of programming skills. There is no such time that I have had thoughts of a classmate being good in programming because he is a boy. Our computer science lessons were tough for me, not because I am girl, but because I came from a high school with no programming background. Nevertheless I tried coding and coding. After graduation, I think I can say I was able to keep up with my classmates. (Hi classmates 👋! XD.)

💌 To the SheCoders,

The world is changing now. There are very few role models for women in tech and that also needs to change. Role models are important to help young girls dream and imagine themselves in certain fields, like IT. Many girls are probably good at coding (remember Margaret Hamilton and Ada Lovelace) but they are afraid of being the only elephant in the room or scared of being judged for their competency as girls. And there is no fun in constantly proving yourselves to others. So let us get out of our shells. All the best and I am rooting for every #shecoder, as a fellow.

💌 To the SheCoderAllies,

These allies are one of the reason why women who are in tech have stick to there strengths and did not give up in the face of a tough environment. Thank you. Hiring tech talents without stereotypes is an incredibly good move. I believe you are not missing out on hiring and/or working together with the best people for the work, whether that be a guy or a girl.

💻 Choose to challenge

As a #shecoder,
📌 I will work hard everyday to improve my coding skills.
📌 I will break into tech.

Lastly, I suddenly remember a phrase I read a long time ago.

IT is a strange field. As long as you have the skills, you are good to go.

And I think that tells us a lot.

DEV Community: patricianicole

Introduction to Java Enterprise Edition

Java EE Basics

Context and Dependency Injection API

CDI Features

Java Persistence API

ORM Manifesto (Object Relational Mapping Manifesto)

JPA Entity

Java API for RESTful Web services

REST Architecture Constraints

My First Hacktoberfest : Feasting on issues for the badge

Happy hacking!

Java Interfaces

📌 Interfaces in Java

The Interface Body

Implementing an Interface

Using an Interface as a Type

Evolving Interfaces

Default Methods

Extending Interfaces that Contain Default Methods

Static Methods

Integrating Default Methods into Existing Libraries

Summary

RESOURCES

Library Project 📖

Entry for The Odin Project's library exercise under the full javascript path

Live preview can be found here

WIL/Thoughts 🤔

Firebase

TailWindCss

JS Revealing Module Pattern (RMP)

To-Do List ✍️

Live preview and can be found here

About 👨‍🏫

WIL/Thoughts 🤔

What's the Weather? 🌦️

WIL/Thoughts 🤔

JavaScript Hoisting

[JS#5 WIL 🤔 Post]

Table Of Contents

📌 Javascript Hoisting

📌 Javascript Context Execution

📌 Creation Phase

📌 Execution Phase

📌 Only the declarations (function and variable) are hoisted

📌 Default Values: undefined and ReferenceError

📌 let hoisting: Temporal Dead Zone (TDZ)

📌 Variable Hoisting

📌 ES5 Strict Mode

📌 Function Hoisting

📌 Hoisting Order of Precedence

Conclusion

[REFERENCES]

Java Annotations

📌 Annotation Basics

📌 Declaring an Annotation Type

Where Can Annotation Be Used

Defining the annotation type

📌 Predefined Annotation Types

Annotation Types Used by the Java Language

Annotations that Apply to Other Annotations

📌 Type Annotations and Pluggable Type Systems

📌 Repeating Annotations

Steps in Creating a Repeatable Annotation

Retrieving Annotations

Design Considerations

REFERENCES

Java Nested Classes and Lambda Expressions

[Java WIL🤔 Post #2]

Table Of Contents

📌 Nested Classes

📌 Why Use Nested Classes

📌 Inner Classes

📌 Static Nested Classes

📌 Shadowing in Nested Classes

📌 Serialization

📌 Local and Anonymous Classes

📌 More on Local Classes

📌 Anonymous Classes

📌 Accessing Local Variables of the Enclosing Scope and Declaring and Accessing Members of the Anonymous Class

📌 Default Values: `undefined` and `ReferenceError`

📌 `let` hoisting: Temporal Dead Zone (TDZ)