Author Archives: zloureiro

Unleash Your Enthusiasm

Further reading into chapter 2 I find that I relate to many of the patterns in this chapter, However, in my reading tonight I felt a specific interest in UnleashYour Enthusiasm. Unleashing Your Enthusiasm is about taking your passion for the work you do and exercising that passion. Think of it like starting at a new gym. You may not know what to do or the correct ways to do things, you may feel weak, confused, and embarrassed. Even with all of these negative feelings you know that you are excited to learn and get stronger. You may need to ask trainers for help and exercise your want for learning despite the embarrassment. This pattern is primarily about understanding that your passion used correctly is itself a valuable attribute to contribute to a team or teacher.

I find that this pattern goes hand in hand with Exposing Your Ignorance and that are one in the same. In order to unleash your enthusiasm you must be willing to expose your ignorance. If you are new to a team or project you are undoubtedly going to have to learn. You have to know that other more senior members will know more than you and will have to take the time to teach you, which for them may seem counterproductive. Being alright with your ignorance is the first step toward unleashing your enthusiasm. UnleashYour Enthusiasm is more about seeing the value in your ignorance. With this drive for knowledge it can help rekindle the flames of other more senior members who have plateaued and have their fire of passion die down to a smolder.

I find I experience the fear of exposing my ignorance quite often. At this point in my education I am always learning in everything I do. It sounds silly because it’s so obvious, but everything I have learned was once something I did not know. This means I had to overcome some fear and pursue that knowledge. Working with teams of my peers there is often a wide range of knowledge based on experience and backgrounds. It is scary to put myself out there and explain that I may not know something that they are all talking about it, but I have had the courage to do so. Many times I have done this and then had a pleasant conversation with my peers about having the drive for knowledge. It doesn’t pay to be afraid of taking the chance, that chance is knowledge and it gives others the opportunity to share something with you. I find that this unleashing of enthusiasm sparks a great pep talk for any team.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Ugh A Textbook Reading…Or?

Ugh A Textbook Reading…Or? Wait what’s all this!

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

The beginning of this book really made me feel comfortable with the reading to come. To be honest I was dreading this assignment because of the reading. However, it really reassures the reader of the purpose of the book and kicks the basic textbook mantra. Something I found quite interesting about Dave’s story was that he had failed multiple times and he still found his way into the field. He actually had help from others but it seemed to be that the most help he got was going out on his own and finding a source of his own that he could understand before he could understand the sources (or basic textbooks) that were given to him. As a new programmer myself I like this idea, sometimes your own path is longer, but perhaps a smoother one for your development. 

A great thing about this book and chapters 1-6 is it’s romanticism of the future of programming and programmers and the formulation of a guide for them. They want to see the future ‘emerge’ without repeating past mistakes just like in the medieval Europe example, the past was riddled with abuse and mistakes. I enjoy the many examples of authors who express the ideas that failure and new ideas are key in this industry, in anything really. The best thing you can do is give the effort and use failure to formulate a map and acquire a “growth mindset”. It really has the sense of a pep talk in it, it not only inspires me to keep on reading but to remember to push myself in my efforts in software development. Sharing of knowledge also seems to be a key trait to have in this industry. Helping others to grow can also help yourself to grow, I like the idea of swallowing pride and asking for help or opening up to another when you are asked for help.

Emptying the cup Chapter 2 was probably the most interesting and simply eye opening chapter for me. It was like seeing someone else get slapped for doing something that you are also doing. I see the same mistake in me as I do in them. I have learned Java and C and whenever granted the possibility of exploring something new I have always chosen to be a creature of habit and to recede into what I know best. Well maybe what I know best isn’t what is best for me. At such an early stage in my development I should certainly explore more, even just the introduction of this chapter was powerful in making me realize that.

I also really enjoyed chapter 4 Accurate Self-Assessment. I often use the term big fish in a little pond when discussing one of my other personal interests, music. Performing music pays to be a big fish in a little pond but at a certain point one will realize they’re pond is tiny in comparison and therefore so are they. It’s okay to be content with that but I find success in growth. I think it’s important to outgrow your pond and move on to another. I think it’s important to ‘be the worst’, you can only go up from there and mistakes and failures will help you grow! I’m glad to see I can  relate more of my personal self to this reading.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

First Look: LibreFoodPantry

Looking at the FOSSism link, one FOSSism I related to and liked was FOSSism #2: Be productively lost. Being that the project is open sourced, joining in may be confusing because you may not know what is going on at the time or what the scope is for development. I can relate to this being a CS major. Sometimes learning new things can be quite confusing especially when you start using code that is pre written and has framework available for you to utilize. While that can be convenient it can be bothersome if you don’t yet understand how that code works and perhaps you have different ideas on accomplishing the same thing. This FOSSism is all about embracing that confusion and worry, the open source environment invites new user and it a friendly environment to ask and learn from others.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Introduction for CS-448

This blog will be following my cs-448 class for this spring 2020 semester.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Final Project pt.3

After starting work on our front end code we needed to create a method to allow users to search our database for a specific ‘artist’ name or by all artists that contain a specific letter or String entered by the user. For example, if the user input the letter “A” then they would be presented with a list of all artists whose names start with “A”. In order to create this function we needed to start with the backend.

In our Java rest api we needed a get method to search our database. The query in SQLite would be “select * from artists where name like ..%”. The “..%” is where the name of the artist we are searching for would go, but since we want the query to be unique to user input the “%” basically acts as a “don’t care”. This allows for whatever the string is that the rest of it doesn’t need to be specified and all artists will be returned that contain that string. To allow our users to input the string to be searched for we setup the query slightly differently in our backend. We use the query “select * from artists where name like ?”. The question mark acts as an operator to take user input. Then we use the statement:

statement.setString(1, name + ‘%’);

This statement sets the string we’re searching for to the first (and only) input from the user and then adds “%” after the string. Here’s a look at our full method: 


public ResponseEntity<Object> getArtistByName(@PathVariable String name) throws SQLException {

   PreparedStatement statement = 

conn.prepareStatement(“select * from artists where name like ?”);

   statement.setString(1, name + ‘%’);

   ResultSet rs = statement.executeQuery();

   ArrayList<Map<String, String>> results = new ArrayList<>();

   while ( {

       Map<String, String> temp = new HashMap<>();

       temp.put(“ArtistId”, rs.getString(“ArtistId”));

       temp.put(“Name”, rs.getString(“Name”));



   return new ResponseEntity<>(results, HttpStatus.OK);


Then in our front end Typescript code we connect to the rest api backend with this method:

getArtistsByName(str: string): void {

 this.error = null;

 let tempStr = str.replace(” “, “%20”);

 this.http.get<Artists>(‘http://localhost:8080/artists/&#8217; + str)

   .subscribe(response => {

       this.searchArtist = response;



     (error: HttpErrorResponse) => {

       this.error = error;




This method allows us to get all the results to the front end so that we can then print the results on our web page for the user to see. We continue to do this by implementing our html code to display these results in drop down lists for the user.

The idea of our project developed into a web page that allows users to search through a database of music artists and their albums and allow the user to select an album that they wish to download. They cannot truly download music from out web page but this is a framework for the idea of a web page with that purpose.

From the blog cs@worcester – Zac&#039;s Blog by zloureiro and used with permission of the author. All other rights reserved by the author.


Mockito is a framework in Java that creates Test Doubles for users that can be used with Junit. Test Doubles as described in my last blog are basically simplified tests for your code that more or less test setup over functionality. They are used to help you make sure you are setting up your code correctly in the early stages before it gets overly complicated. It’s good practice to test at this early stage in the process because simple setup and organization errors can become an overwhelming problem further down the line if you don’t find them early on. Mockito is a great framework to help you quickly generate these Test Doubles. Mockito creates mock objects with dummy values to make sure tests pass, as long as your setup is correct.

Check out this code example:

package com.journaldev.mockito;

import static org.junit.jupiter.api.Assertions.assertEquals;

import static org.mockito.Mockito.when;

import org.junit.jupiter.api.Test;

import org.mockito.Mockito;

import com.journaldev.AddService;

import com.journaldev.CalcService;

public class CalcService1Test {


void testCalc() {

System.out.println(“**— Test testCalc executed —**”);

AddService addService;

CalcService calcService;

addService = Mockito.mock(AddService.class);

calcService = new CalcService(addService);

int num1 = 11;

int num2 = 12;

int expected = 23;

when(addService.add(num1, num2)).thenReturn(expected);

int actual = calcService.calc(num1, num2);

assertEquals(expected, actual);



This code uses a mock() method.

To continue reading about this example check out this website:

From the blog cs@worcester – Zac&#039;s Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Test Doubles

Test Doubles is a term used to describe code tests that are basically imposters of themselves. They are unfinished and simplified versions of what the actual tests would be. Thus, they are doubles of their true forms. Theses doubles are written in order to satisfy and verify that you code is functioning and is setup at the most basic level. Test Doubles contain three different types; Stubs, Mocks, and Fakes. Each of these types is used in a different way to help get your testing going but without getting too complicated. 

A fake test allows us to take a shortcut when testing functionality. Say you have a database that your code connects to. Instead of starting up and running a connection you could have hard coded values in your code that you retrieve for your tests. So in this way you aren’t really testing the right values but that your code is able to get values at all.

A stub has a similar idea with using hard coded values to satisfy your tests. Essentially all you do is create a test, then make sure that the code that is being tested has exactly the results that are expected. For example, if you’re testing if a rectangle object is a square then you don’t actually create the rectangle, instead you return the expected value to the test class.

A mock is used when we just want to verify that our code is being called or accessed correctly without actually functioning the way we are intending. If you have a method you want to make sure is called correctly you can have that method be empty but when it is called it prints a string “Method … accessed correctly”. This way you know that you are calling the right method without having to actually test its functionality yet.

Here is a link that helps explain these Test Doubles:

From the blog cs@worcester – Zac&#039;s Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Path Testing

Path testing is a great way to ensure that your code is concise and understandable. It allows you to see the flow of your code and the direction in which it travels depending on conditions, loops, and the order of the code. The name is self explanatory you are essentially testing the “path” of the code. This kind of testing is not in the same field as something like a Junit test. This is a visual test that doesn’t use software persay. It’s more like a diagram that allows you to test and figure out the logic of your code. Here is a diagram I found online that helps explain this type of testing.

In this diagram you can see that the numbered nodes match up with the lines of code. This helps to make the details of the code abstract and to bring the path of the code into the forefront. This isn’t very detailed code but it shows how conditionals effect the path of your code. Certain nodes are passed through and others are not depending on these conditionals. Setting up these diagrams for your code can help you understand your code better and thus eliminate redundant testing or create more useful tests.

Here’s a link to a website giving a good explanation of path testing.

From the blog cs@worcester – Zac&#039;s Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Final Project pt.2

Zac Loureiro

My last final project blog left off with us having a connection established between Java rest api and a SQLite database. We accomplished this through use of Java imports that were available to us. The next step was finding out how to actually access our database with queries that are sent with our backend Java rest api. We started with a simple get method, in the rest api format it is a @GetMapping method. We were just trying to run a query to get all the ‘artists’ in our database, ‘artists’ being music artists is one of the tables in our database. The query in SQLite would be “select * from artists”. There are a series of methods available with the sql imports in Java to help execute this query using the backend. Here is a look at our complete method:


public ResponseEntity<Object> getAllArtists() throws SQLException {

   PreparedStatement statement = conn.prepareStatement(“select * from artists”);

   ResultSet rs = statement.executeQuery();

   ArrayList<Map<String, String>> results = new ArrayList<>();

   while ( {

       Map<String, String> temp = new HashMap<>();

       temp.put(“ArtistId”, rs.getString(“ArtistId”));

       temp.put(“Name”, rs.getString(“Name”));



   return new ResponseEntity<>(results, HttpStatus.OK);


The line @GetMapping(“/artists”) establishes our path for the rest api. The lines PreparedStatement statement = conn.prepareStatement(“select * from artists”); 


ResultSet rs = statement.executeQuery();

are available via the sql imports. The first of these two lines creates the query as a variable “statement” of type “PreparedStatement” within our connection. Then a variable “rs” of type “ResultSet” is set equal to “statement.executeQuery()”. This sets “rs” equal to the result of the query, which in this case is all the artists in the database. Then the data of the artists is loaded into an ArrayList of type Map<String, String> and returned. Returning an ArrayList of Maps is best for functionality when we got to working on our front end code. Since artists had two fields “ArtistId” and “Name”, which are both Strings, saved the data in a Map<String, String> so that both variables were easy to access. This way we could pinpoint any artist in the database when we began to search for specific artists. Our next task was to create methods that allowed our users to search for a specific artist by name. We needed to also add a post method to allow users to add an artist to our database.

From the blog cs@worcester – Zac&#039;s Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

Final Project pt.1

For my final project in my Software construction, design, and architecture class, my partner and I had the idea of creating a web page that was able to access data of a SQLite database. The structure of this project was to connect to a database using Java as a backend and use Rest api to send out sql commands. We needed to run the backend on a server using a Spring Boot framework available to us. Once our connection was setup and our backend methods to access the database was ready we had to create the front end. We used Typescript and Java Angular to create our front end, or in other words our web page. The typescript code had to connect to the Java rest api so our chain of connections from the top goes; Typescript and Angular -> Java Rest api -> SQLite database. 

Starting the project the very first obstacle we ran into was connection Java rest api to the SQLite database. It was something we had never done before, but thankfully there was helpful resources online. We found out that there was a series of Java imports to facilitate this function. A few imports needed are as follows:

import java.sql.*;

import java.sql.Connection;

import java.sql.DriverManager;

import java.sql.ResultSet;

import java.sql.SQLException;

import java.sql.Statement;

Using these imports we were able to create an object of type ‘Connection’ in order to establish the actual connection to the database. Here is our method:

public static Connection getConnection() {

   if (conn == null) {

       try {

           conn = DriverManager.getConnection(“jdbc:sqlite:” + dbpath);

       } catch (SQLException e) {




   return conn;


The set method to set our path:

DatabaseSQL.setPath(“C:/…(insert path here)…”);

We are now able to get the connection inside our Java rest api classes that contain our SQLite query methods using this statement:

Connection conn = DatabaseSQL.getConnection();

As I said this information can be found through many sources online so we were lucky such a function was available for us to use at our disposal. We needed the connection to be established before we could proceed with anything else because the entire project relied on accessing the database. However, in order to actually know if our connection was working we couldn’t rely on the absence of errors. We needed to create a rest api method to access the database and give us a result so that we could be sure.

From the blog cs@worcester – Zac&#039;s Blog by zloureiro and used with permission of the author. All other rights reserved by the author.