Author Archives: Michael Duquette

REST – INSOMNIA(c)

This week let’s take another peek at the FoodKeeper API. We’ll review the endpoints and how to submit a request to retrieve data. Before we jump into this you need to download and install a REST client. I highly recommend Insomnia, the app not the sleep disorder, (download it here) I’ll wait… Now that you have Insomnia installed let’s talk about endpoints. Last week we covered the four primary HTTP verbs used with REST. Did you have a chance to visit https://www.restapitutorial.com despite the name of the website these aren’t tutorials on how to make REST calls but more like development guidelines for developers writing REST API’s.

So why did I recommend it? Because understanding how a good RESTful API is designed will make it easier to craft your REST calls. So the 4 basic HTTP verbs (POST, GET, PUT and DELETE) are CRUD (Create, Read, Update, Delete) operations. · POST = Create · GET = Read · PUT = Update · DELETE = Delete Kind of makes sense, right? These also make up the endpoints you access with your REST client. In JAVA we add an annotation to the class and the getter and setter methods to define the endpoint. For the FoodKeeper API we are using the Spring Framework (https://spring.io/) to help setup the Rest components. After all the imports are declared the class must be annotated with @RestController so that the compiler knows how to process it. Each endpoint must be annotated to reflect what it does. A POST endpoint would be annotated like this: @PostMapping(“/list/new”) The part in parenthesis indicates the URL path that you would pass as part of the REST Client call and is the actual endpoint. Let’s look at an online example. In a new tab on your browser go to: http://dummy.restapiexample.com/ The site lists 5 public endpoints you can practice against: · GET /employee · GET /employee/{id} · POST /create · PUT /update/{id} · DELETE /delete/{id} Note the curly braces with id in between them – this indicates that you will be passing a value.
Open your REST client, in Insomnia you would type in the URL in the White field in the top center of the screen and select the REST Method to the left of it: Click the Send button and watch the Right hand column you will see it populate with employees. This is the first entry in the list that was returned for me: Play around and get familiar with your REST Client and hit some of the other endpoints at

http://dummy.restapiexample.com/ TIP: For the endpoints above with {id} just append the url string with a number like this: http://dummy.restapiexample.com/api/v1/employees/6821 All right go play and learn something! #CS@Worcester #CS448

From the blog Home | Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

SOLID – Like a (Open/Closed) Rock

TLDR: your code should be open for extension but closed for modification. o Keep the current functions, Classes, modules immutable o Extend, in a composable way (try to avoid inheritance as it tends to couple things) Read the full article about the Open/Closed Principle from CodeBurst here The main idea is that in one part of your code you have your abstractions such as classes that do one thing and do it well. You don’t want to be modifying them and should be keeping them clean and cohesive. You ready for this? The Open/Closed Principle = COMPOSITE DESIGN PATTERN – mind blown! How about that, we’ve come full circle back to design patterns. Now… where’s that duck? Don’t get your beaks out of joint, no ducks this time we are going to be working with coffee machines instead. I really enjoy a great cup of coffee! This article over on Stackify has a great code example of applying the Open/Closed Principle to a CoffeeMachine app. To summarize: You have a BasicCoffeeMachine Class it has a constructor, a public method to add ground coffee, and a public method that brews a filter coffee. A BasicCoffeeApp class that prepares a HashMap with ground coffee, instantiates a BasicCoffeeMachine object, and calls the prepareCoffee method to brew the coffee. Pretty simple right? Our app brews us a fresh pot of filter coffee. Well what if we upgrade our pot to include an integrated grinder? Now we can brew espresso also but our CoffeeApp doesn’t support this kind of brewer. Sounds like some code changes to the CoffeApp are in order. Why don’t we also update it so that we don’t need to adapt to future types of coffee machines. So how do we do this? Well, let’s start off by extracting what we can to create an interface. Let’s pull out what’s mandatory for controlling a coffee machine, but none of the optional stuff. Since the only real “control” in the BasicCoffeeMachine is the brewCoffee method we can put that up in an interface and have BasicCoffeeMachine implement the interface (CoffeeMachine). Now we can add more implementations of CoffeeMachine. See what we’ve done there? Just by adding the interface and implementing more variations of the CoffeeMachine we’ve adopted the Open/Closed Principle. So, what’s next? We’re not done refactoring, we need to modify the CoffeeApp to make use of the CoffeMachine interface by instantiating instances of it for the different coffee types. Make mine a tall black with a shot of vanilla and please go check out the code example and the full article here. #CS@Worcester #CS343

From the blog Home | Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

Gradle: Test test

Testing Testing Testing… A few weeks ago we focused on JUnit testing using Gradle. I thought I would share a few things I learned along the way getting my projects setup for JUnit testing with Gradle. Since our testing is centered around Jupiter (JUnit5) there are a few unique things you need to do to get Gradle to behave as expected. If you are using Jupiter for your JUnit testing you need to have Gradle version 4.6 or later installed. So let’s start there. Verify the version of Gradle you have installed: Open a bash shell in your projects root directory and run: ./gradlew –version If you are not running a version greater than 4.6 update to the latest version before proceeding. Let’s setup our project to use Gradle. Open a bash shell in your projects root folder and run this: gradle init –type java-library –dsl groovy –test-framework junit This tells Gradle that we are creating a new JAVA project and that we will be testing with JUnit. It will take a few seconds to run and once complete you should see a message that says: BUILD SUCCESSFUL in xxseconds 2 actionable tasks: 2 executed Now check out your project folder. You will now see 3 new folders: gradle .gradle src and the following new files: .gitignore build.gradle gradlew gradlew.bat settings.gradle We are going to start off making changes to the build.gradle file. Using your favorite editor (I prefer Notepad++)open build.gradle and verify that the following is your frist entry following the commented docs: 1 plugins { 2 // Apply the java-library plugin to add support for Java Library 3 id ‘java-library’ 4 } This tells Gradle that it is going to be building a JAVA program. Now we need to make sure that Gradle gets the required and dependencies so add the following to build.gradle: 20 dependencies { 21 // This dependency is exported to consumers, that is to say found on their compile classpath. 22 api ‘org.apache.commons:commons-math3:3.6.1’ 24 // This dependency is used internally, and not exposed to consumers on their own compile classpath. 25 implementation ‘com.google.guava:guava:27.0.1-jre’ 26 // Use JUnit test framework 27 testImplementation ‘junit:junit:4.12’ 28 testImplementation ‘org.junit.jupiter:junit-jupiter-api:5.5.0-M1’ 29 testRuntimeOnly ‘org.junit.jupiter:junit-jupiter-engine:5.5.0-M1’ 30 } We tell build.gradle which frameworks to include for the JUnit testing. Jupiter is backwards compatible but if we want to run any JUnit 4 test we include that junit:4.12 dependency. This just ensure the correct flavor of JUnit is used for the testing. Now we’ll add one more line to our build.gradle to make sure we enable Gradle’s native JUnit 5 support. Add the following lines after the dependencies: 33 test { 34 useJUnitPlatform() 35 } Now hop back into your IDE and work on your project. Save all of your changes and navigate back to your project folder. Open up the src folder. You will see the following sub-folders: main test Both of these contain a folder called java. You will move your JAVA files into the java folders in the main and test subfolders. EXAMPLE: Let’s say I am working a project that has Duck.java , Pond.java , and DuckTest.java. Both Duck.java and Pond.java should be moved to ../src/main/java and DuckTest.java would be moved to ../src/test/java Once you’ve moved your files into the correct location run this in your bash shell: gradle build Once this succeeds run this in your bash shell: gradle test Once this finishes and you get a success message navigate to your project folder and go to /build/reports/tests/test/ and open up the index.html. This will give you a breakdown of how your gradle test went. Now that you’ve sucessfully setup Gradle you need to go back into your IDE and clean up your projects paths so that you are working in the src/main/java folder and the src/test/java folder. See easey peasey lemon squeezy! Next week we’ll go over how to intigrate our projects with GitLab so that GitLab does the testing for us. In the meantime checkout the docs up on Gradle.org related to testing with JAVA & JVM: https://docs.gradle.org/5.2.1/userguide/java_testing.html#using_junit5 #CS@Worcester #CS443

From the blog Home | Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

Patterns Part Deux – A Rusty Duck

Last week we discussed some of the design patterns we’ve been studying. We shuffled those poor ducks around a lot! We did finally land on the Singleton Pattern. The Singleton restricts the instantiation of a class to one “single” instance. Also providing a single point of access to the instance. Wait, is that our new type of duck, The Singleton Duck? How would that work? Is Singleton Duck like Leisure Suit Duck? Just more aloof and dapper? Ok let’s not get carried away with the ducks. The Singleton design pattern is part of the Creational group of patterns. Design Patterns are typically broken out into three general categories: Creational patterns – these provide object creation mechanisms that promote flexibility and reuse of code. Structural patterns – these patterns show how to assemble objects and classes into larger structures while keeping the structures flexible and efficient. Behavioral patterns – these take care of effective communication and assigning responsibility between objects. What’s similar between these three categories? At their core they all promote flexibility and efficiency. Is this why we use design patterns? Well, to some degree yes. Design patterns can be thought of as tried and true solutions to common problems in software design. Over on [Refacturing.guru](https://refactoring.guru/design-patterns) they show 22 designs patterns that fall into the three categories above. Shall we dig into all 22 of them? How about, instead of me typing each one out with a description, you head on over there and check it out. One of the things I found helpful with the information on Refactoring.guru is the description and breakdown of each of the patterns. Here’s a high-level what each pattern contains from Refactoring.guru. Each pattern starts off with a description (the Intent) and has the following sections: Intent Problem Solution Real-world analogy Pseudo-code Applicability How to implement Pros and Cons Relations with other patterns The real-world analogy helped to solidify the concepts and I found the pseudo-code helpful. Sticking with Singleton pattern here is the How to Implement section from Refactoring.guru: How to Implement 1. Add a private static field to the class for storing the singleton instance. 2. Declare a public static creation method for getting the singleton instance. 3. Implement “lazy initialization” inside the static method. It should create a new object on its first call and put it into the static field. The method should always return that instance on all subsequent calls. 4. Make the constructor of the class private. The static method of the class will still be able to call the constructor, but not the other objects. 5. Go over the client code and replace all direct calls to the singleton’s constructor with calls to its static creation method. Pretty straight forward right? Knowing that these design patterns exist, not necessarily memorizing them, and understanding their benefits is a handy tool to have in your box of tricks. Which brings up next weeks topic: Utility Belt – Accessory or Fashion Necessity? Don’t forget to check out [Refacturing.guru](https://refactoring.guru/design-patterns) ! #CS@Worcester #CS343

From the blog Home | Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

REST not relaxing

Part of working with the LibreFoodPantry includes working with the FoodKeeper-API. So let’s talk about API’s, specifically REST API’s. REST is an acronym that means REpresentational State Transfer. REST is a resource based, not action based, architectural style that has six design constraints. REST architectural style, data and functionality are considered resources and are accessed using Uniform Resource Identifiers (URIs). The clients and servers exchange representations of resources by using a standardized interface and protocol – typically HTTP. BUT… REST is not HTTP! In order to be considered a RESTful API the design must meet the first 5 of these 6 design constraints: Client–server – The interface separates the client from the server. Cacheable – Clients can cache responses. Responses have to, implicitly or explicitly, define themselves as cacheable, or not. This prevents clients from reusing stale or inappropriate data in response to further requests. Uniform interface – REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and hypermedia as the engine of application state. See this article on DZone for a better understanding of HATEOAS: https://dzone.com/articles/hypermedia-driven-rest-services-with-spring-hateoa Stateless – The necessary state to handle the request is contained within the request itself. Layered system – The layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot “see” beyond the immediate layer with which they are interacting. Code on demand (this is the only optional constraint) – REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts. This simplifies clients by reducing the number of features required to be pre-implemented. Generally, the four primary HTTP verbs used are as follows: GET Read a specific resource (by an identifier) or a collection of resources. PUT Update a specific resource (by an identifier) or a collection of resources. Can also be used to create a specific resource if the resource identifier is known before-hand. DELETE Remove/delete a specific resource by an identifier. POST Create a new resource. Also a catch-all verb for operations that don’t fit into the other categories. A little digging on the web and you will find a lot if resources concerning REST. One very helpful sight I found for getting a better understanding is https://www.restapitutorial.com When you dig deeper into and need to use a client I recommend Insomnia (https://insomnia.rest/) #CS@Worcester #CS448

From the blog Home | Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

Quackers about Patterns

So far we’ve dealt with design smells and played with the Duck factory. Which is a great segue into our next topic, Design Patterns, one of which is the Factory Pattern. Design patterns allow us to look at our code, usually as the need for changes arise and utlize the benefits of a design pattern. With our Duck Factory exercises this is where we began. We created duck objects and added them to a pond. As the number of types of ducks changed so did their behaviors. Does a rubber duck quack? Can a cement duck float? Does decoy duck fly? Our initial Factory design pattern worked fine until we our duck types changed and it became evident that the design pattern needed to evolve. Out first iteration took the factory design pattern and migrated to an Abstract Factory pattern. Now our ducks could inherit behaviors from interfaces. But should a decoy duck be inheriting quack behaviors? The Abstract Factory design pattern is really just a transitional pattern to the Strategy Pattern. As we moved our code around it became clear that we were making things a little more complicated than they needed to be. We were starting to introduce some needless design smells. The advantage of the Strategy Pattern is it favors encapsulation. The “Strategy” is to define a set of algorithms, encapsulate each one and make them interchangeable. This allows the algorithms to vary independently from the clients that use them. In the case of our Duck Factory and the ducks (and duck sub-classes) use the encapsulated behaviors (and sub-behaviors) to fly, quack, squeak, and in the case of cement duck sink. We covered 3 other design patterns and next week I’ll touch on those. Until then happy coding! #CS@Worcester #CS343

From the blog Home | Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

Stinky Duck

Stinky Duck – We’ve been doing some fantastic exercises centered around design smells. These are the seven primary design smells: ● Rigidity ● Fragility ● Immobility ● Viscosity ● Needless Complexity ● Needless Repetition ● Opacity I’m not going to waste your time giving you the definitions. Where’s the fun in that, do a little research and find out why your code may smell a little funky. But I do want to talk about ducks. Not just any ducks, stinky ducks. Some of the exercises we’ve been doing have been centered around “The Duck Simulator”. What does a duck do? Well that depends on the duck, right? Mallard Ducks can fly, swim, and quack. But a Decoy Duck does not fly, does not quack, and does not swim. Though Decoy Duck can float. How do ducks relate to Object Oriented Programming? Let’s imagine a Duck as a JAVA class. In our first pass of designing a duck we made a Duck super class with sub-classes of each type of duck. What’s wrong with having a duck super-class and sub-classes for each type of duck? Look back at the seven smells. can you see it? What’s going to happen when we start adding more duck types? We’ll end up with a lot of repetitive code. What’s the quickest way to reduce repetitive code? What about using inheritance? Inheritance will help but now we’re overriding a bunch of methods for the different duck types. Decoy duck doesn’t need a quack method. We would have to override the quack method. In fact for every duck type we would have to override methods that are inherited from the super-class. You know, because they are inherited. We could look at our super class (Duck) and see where we can improve the code. Well look at that, all the duck types have something in common. They exhibit specific behaviors. They fly (or not) and quack (or not). We can take these behaviors and create interfaces. Our goal should be to make the super class fixed but extensible. Now if we keep adding new types of ducks (Ghost ducks and Rocket Ducks anyone?) we will be able to identify additional areas for clean up. See, our simple Duck went from a slight smell to a real funk quickly. The design smells can be reduced to a manageable level by following the prinicples of clean code. We’ll talk more about design smells and clean code next week. #CS@Worcester #CS343

From the blog Home | Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

Moving from Gitlab to Github

Let’s face it, there is no one perfect platform for hosting repositories. This isn’t a debate about whether Github is better than Gitlab. They both have their pluses and minuses. Recently, we had to move a repository from Gitlab to Github. Without using a migration utility we were able to successfully migrate by following a few steps which I will outline below. This is the approach that we utilized and worked for us using these tools: · Gitbash (https://gitforwindows.org/) · Notepad++ (https://notepad-plus-plus.org/downloads) At a high level the steps we followed are (*Note* this a high level overview see the steps below for the details): · Fork and Clone from Gitlab · Move, find and replace all pointers at the file system level · Create an empty repository on Github · Fork and clone the empty repository from Github into a new folder · Copy all the Gitlab project folder to the Github project folder · Push to the Github repository Read the below steps a couple of times. DO NOT just skim them (something I am guilty of doing frequently) but read through them and make sure to pay attention to the NOTES. Steps/Details: To demonstrate the steps taken I’ve created two folders GitLab and GitHub. We’ll start by working in the Gitlab folder first. From your Gitlab dashboard fork and clone the repository into the local GitLab folder. Navigate to the GitLab repository folder locally. The goal here is to go folder by folder and using Notepad++ replace all instances of gitlab with github. Take your time and do each folder individually. Not every file will have a reference to gitlab in it but Notepad++ has a handy replace all feature that will make this short work. As you are traversing the folders rename any folders that are named gitlab to github as well. Once you finish renaming everything open git-bash in the gitlab folder and copy everything to your github folder: CP is the bash copy command -avr translates to -a = preserve attributes, file modes, ownership, timestamps… -v = verbose output -r = copy directories recursively On Github create a new empty repository. Open a new git-bash window from the new github repository folder you copied everything into. To retain your Git history follow the instructions from Github to push an existing repository from the command line (make sure you are in the github repository folder) : NOTE: If you get this error: fatal: remote origin already exists Do not proceed with the git push. Run this from you git-bash session: git remote rm origin If you don’t receive any additional errors re-run the git remote add origin followed by the git push. At this point you have moved your repository to Github. Verify your app is working correctly and if you are getting any errors go back and double check to make sure you changed all the references from gitlab to github everywhere including folder names. #CS@Worcester #CS448

From the blog Home | Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

Heroku, a Haiku for you

Heroku a haiku: Constant deployment Integration on the fly Heroku for you Let’s talk about the devops cycle. It’s comprised of several different layers. We’re going to focus on Continuous Integration (CI), Continuous Delivery(CD), test automation, and configuration management. More importantly we are going to focus on connecting our Gitlab repository with Heroku. We’ll do this so we can get the CI/CD environment setup for our branch of the LibreFoodBank. So what do we need to accomplish this? We’ll need our repository on Github migrated to Gitlab. This has already been done and we will be working from a specific forked branch for our testing. We’ll need our Heroku account setup. This has already been setup for us. Since we are stepping into this project at this phase we should just need to follow some basic steps to link the two. Once we have confirmation that all the steps work correctly and are repeatable we will create working documentation for other teams to utilize. Here’s the high altitude overview of how we will accomplish this: Setup Gitlab account Generate a pair of SSH keys Setup staging and production environments in Heroku Setup tests Setup the CI environment on Gitlab Install and register Gitlab Runner Configure the pipelines and fire it up Again this is the 20000 foot look at how we are going to get where we need to be and we’ll be taking notes as we go! #CS@Worcester #CS448

From the blog Home | Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.

UML, U of what?

What’s UML? Go ahead look it up, I’ll wait. No, not UMass Lowell it’s Unified Modeling Language. The current UML Standard, 2.0, has been around since 2005. With 14 different diagram standards UML allows individuals to work at a much higher level of abstraction. I’m familiar with UML from creating ERD diagrams while doing RDBMS work. As a developer it allows me to write pseudo-code quicker, cleaner and platform independent. From a developers stand point, let’s take a look at an example and break it down. I found the example below at https://medium.com/@smagid_allThings/uml-class-diagrams-tutorial-step-by-step-520fd83b300b I really enjoy the content at Medium.com, the articles, reviews and tutorials are all helpful and well written. This is a typical Class diagram representing 4 classes: Animal, Duck, Fish, Zebra. Notice how each of the four blocks are structured the same. Let’s focus on the Animal block. In the upper box notice that Animal is written with a bold font. This indicates that Animal is a concrete class. Abstract classes would be italicized. The next box down is where you define attributes. Public attributes are denoted using a + while private attributes use a -. Looking at our example this would translate into JAVA like this: public Int age; public String gender; The lower box is for methods or functions. The same convention is used for dentoing public or private methods. In the Animal class the example would translate to: public isMammal(){ }; public mate(){ }; Note the example is missing the return types for methods. The convention is to follow the paranthesis with a colon and list the return type. In our example isMammal would be +isMammal () : boolean Relationships between the classes are denoted using lines, arrows and diamonds. In our example the solid line with the white filled arrow indicates inheritance. The article/tutorial above has a great png showing the different relationship lines. The number of online resources for information related to drawing UML diagrams is staggering. For more information and to take a deeper dive into UML go to the source and check it out https://www.uml.org #CS@Worcester #CS343

From the blog Home | Michael Duquette by Michael Duquette and used with permission of the author. All other rights reserved by the author.