This past sprint session was my teams final sprint for the semester and our main focus is now on our final presentation. During the first sprint we spent time setting up front end and back end files with the goal of making a simple system to secure with Keycloak. The Keycloak implementation in itself took much more time than anticipated so our final product is Keycloak securing a simple front end vue application. There were many roadblocks in getting Keycloak to work – JavaScript connector not working, figuring out how to create a shared realm with multiple users, and general issues coming up with each step we took in trying to link it with a web app. Initially we have assigned different team mates to different areas of our project but by the middle of the second sprint getting an instance of Keycloak to work became an all hands on deck priority. I did spend some time working on a backend with the hopes of linking it with our front end however there is not enough time in the semester. The front end, back end, and API should each have their own dev container and this is something the next semester students can pick up, however I did go in and create a dev container for the API. I wanted to make the system ready for future semesters to pick it up from there and link the pieces together. The most important part is we have figured out how to attach Keycloak to any web application and the next semester students should be able to use our research to secure LibreFood Pantry with Keycloak.

Our group worked well during our final sprint and I think our communication skills all improved greatly over the course of the three sprints. Keycloak being an add on to any system comes with many “wires” to connect to the existing system and we experienced issues at almost each next step of connecting it to the vue app. Our team had to learn how to communicate at each road block and work together to solve the problem. I think towards the end we improved by talking about these issues during class and finding solutions on the spot and making decisions then rather than taking the issue home and trying to figure it out on your own. Most of us have preferred to work on coding projects individually however that isn’t how real programming jobs work. In an office setting the software development team will be expected to collaborate on the project and constantly merge code together and all work on different pieces of the same over all system. I’m grateful to have a better idea of how to work with other developers and this will help me in my first programming job.

I am proud with the final product we created. We hit the main goal of understanding Keycloak and learning the steps to implement it with any web application and if we had more time in the semester I think our group would have been able to connect it to LibreFood Pantry, and I am excited to see the next semester students take our work to the end.

From the blog CS@Worcester – Site Title by lenagviaz and used with permission of the author. All other rights reserved by the author.

This sprint I feel as though my team and I made a lot of progress. One aspect of our project that was really holding us back was getting a keycloak instance up and running. We were able to follow a tutorial guide online to make a basic vue app and secure it with keycloak and all create our own users in the realm.

Our team worked very well this semester and I believe we were able to improve our communication in our team. We have implemented a twice a week virtual check in on thursdays and saturdays and that has been a great way to check in with each other and this has improved our progress.

One thing we should work on during the final sprint is getting our demo up and running and secure it with keycloak. Although our team communication has improved I believe we should begin to make better use of the issues board and add more updates to issues as we work on them through the week.

From the blog CS@Worcester – Site Title by lenagviaz and used with permission of the author. All other rights reserved by the author.

“Craft over Art” was a great apprenticeship pattern to read about and I found myself relating to the ideas with my own work. A craft is an art that has functionality – a painting you can look at and hang on the wall, but a table or couch provides you with functionality. Good software should be written so it looks good and performs is purpose.

When constructing a piece of software it’s important to look at the tools we are going to use. A programming language, a laptop or PC, a good IDE, Unit Tests, and an outline of what the system should look like. No one starts a craft such as furniture building by grabbing a piece of wood and one by one assembling the project. They first create a blueprint with measurements, a model, and gather all necessary materials before they begin following their blueprint. I enjoy this analogy because I’ve made this mistake in the past when writing code. I would usually go line by line and fix mistakes one by one as I find them. This way of writing code is quite slow and it can be easy to drop a project because it seems too large or difficult. Now I follow a plan when I write my code and even if a method I’m working on has issues, I’ll move on to the next method. I’ll also create my methods before hand and leave them empty until I begin working on one to ensure I’m still following the system I designed for the project.

Art is also an important factor of crafting. If my code is messy, unorganized, and does not have good flow it will be incredibly difficult to refactor the code later on. When we enter the workforce it’s unlikely we will be writing a piece of software completely on our own. Your code will be combined with dozens and hundreds of other programmers work and it’s important that the system works well together.

From the blog CS@Worcester – Site Title by lenagviaz and used with permission of the author. All other rights reserved by the author.

This week I really enjoyed reading “The Long Road” from the apprenticeship patterns. In computer science, often many of us feel like we need to learn as much as we can in the four years we are getting our degree and then go out and apply that in a full time position. The reality is that we only learn the basics in our undergraduate degree – enough to gain strong logic and critical thinking skills and enough to get that first job. The real learning comes from actually working as a software developer and there is no “end” to how much you can learn in software engineering.

The tech industry is constantly evolving and every two years it seems like there is a shift in how technologies are used or new technologies are introduced. A software engineer cannot stop learning once they have learned everything it takes to perform their programming job well. Skills they learn in that job will always carry over, however they may end up working with completely different or newer frameworks and they have to start the process of learning again. That’s why as software engineers we should have the mindset of “always learning” rather than “learning something new when needed to”.

From the blog CS@Worcester – Site Title by lenagviaz and used with permission of the author. All other rights reserved by the author.

My favorite chapter in this week’s reading was chapter 4 “Accurate self assessment”. When you are a studying computer science in college you are introduced to new topics each semester and by the end, you have developed a good understanding of the material. Once that happens, a new semester starts and you are back to being a beginner in a topic. What we don’t think about often is in the workplace, there will be a large amount of learning initially however over time that can level off. Software engineering is a field that is constantly growing and changing, and I like the advice of always aiming to be the weakest member of your team to start off and work your way up. This is great advice because it keeps you in a place where you are always learning new things as the industry changes.

The topics of chapter six ties in really well with chapter four, almost as a way to teach the reader how to accomplish the goals of chapter four. Computer science is a growing field, but it’s also one of the fields with the most free available information on it’s topics shared online amongst other computer scientists. When you leave school it’s your responsibility to keep learning and decide how much you want to do. Read constantly is one of the pieces of advice I think is great, whether it’s books, blogs, articles, etc. A good goal to aim for when you are outside of school and start your job is to try and spend a half hour every reading different materials in CS.

This chapter also brings up a good point about learning to code in programming tutorials and how limiting that can be at times. It’s definitely a great starting point, however it shouldn’t be the long term way to learn. A software engineer should have the skills to approach any kind of debugging problem and develop their own solution. That’s why it’s so important to have good logical thinking and algorithm skills and work on solving a variety of different programming problems rather than follow many full project programming tutorials.

From the blog CS@Worcester – Site Title by lenagviaz and used with permission of the author. All other rights reserved by the author.

In the second half of the semester we began working with the API code for the Worcester State food pantry project. As I worked with the API code, I never really took the time to gain a deeper understanding of how APIs work and I wanted to explore that as I wrap up my final assignments. I found this video explaining the basics of Web APIs to be very helpful and fill in gaps I had in my understanding of the topic. 

API stands for application programming interface and web APIst provide mechanisms users can use and interact with where the workings of that mechanism are hidden to the user. The video gave a great example of a way to visualize how APIs work: when you enter an elevator you have a set of buttons that take you where you want to go, but you don’t see or know exactly how it does it. Web APIs are the medium between the client (user) and the server (the web servers). HTTP protocol (HyperText Transfer Protocol) is used to transfer data through the web. Every link on your web browser is in HTTP form with a path and parameters or query – for example, I am editing this in google docs and my browser is in the form of docs.google.com/document/d/encryption/edit. Servers offer responses in various different codes such as 200 (success), 400 (client error), or 500 (server error). The information that is sent over can be in two different formats: XML or JSON. They have different formats but the same function of transferring data. 

JSON is the standard for APIs because most programs are using javascript and it provides easy integration. Many modern APIs use the REST architecture (Representational State). REST APIs use an end point just like the HTTP path and the method, which defines what kind of action is being performed (GET, POST, DELETE). Headers contain information about the type of request and the body is the JSON object. API requests have four parts: The end point (the path), the method (which HTP call is being made), the header which contains additional information, and the body (the message or data that is being sent). 

This video did not mention YAML files and that was part of the API system I was still struggling to understand, and came across a great breakdown:

https://idratherbewriting.com/learnapidoc/pubapis_yaml.html

The food pantry API code is made up of many different YAML files. YAML is similar to mark up languages but it removes all the brackets and other syntax making it easier and faster to read. YAML and JSON are related, making the two easy to integrate. YAML file syntax uses indentation to denote different levels and each different level is an object with dashes indicating variables. JSON uses quotation marks and brackets whereas YAML uses dashes and semicolons.

From the blog CS@Worcester – Site Title by lenagviaz and used with permission of the author. All other rights reserved by the author.

There is a strong usage of java programming for almost every computer science student I have encountered. Every one of my programming classes has been taught in java, with the exception of a free elective where I took a Matlab class. For most students, if they want experience working with a functional programming language they need to take an elective course or teach themselves in their free time. Some of the most common functions/procedural programming languages are C, SQL. Java, C++, and Ruby are examples of object oriented programming. For a while, I didn’t quite understand the differences between object oriented programming and functional programming languages. I wanted to take some time this week to revisit that idea and learn the pros and cons of each programming style and which one is preferred. 

I found this video to be a great basis for answering these questions. Starting with functional programming, there are three bases that need to be followed: functions only, no side effects, and fixed control flow. Functional programming generally has less temporary variables and thus less memory intensive, and the methods are shorter and to the point. A strict control flow means as you are writing your code, you are mapping a clear input and output flow. The basis of object oriented programming are classes containing methods and attributes and creating objects. Object oriented programming is a great option for when there is going to be a lot of similar code, or many working parts of your code operate on the same basis then branch outwards with variations. With functional programming, if you have similar pieces of code being reused and rewritten, bugs could be harder to narrow down if they are embedded throughout your program. With object oriented programming, fixing a bug in the base class will fix the solution in all extended classes and implementations of those methods. 

From the blog CS@Worcester – Site Title by lenagviaz and used with permission of the author. All other rights reserved by the author.

Earlier in the semester, we learned about different design patterns as well as different code smells, which means various issues or dysfunctions you can have in your code. I wrote one previous blog about code refactoring in regards to one of my projects, this time I wanted to look through all of my code throughout my computer science degree. I have all of my old assignments and personal projects on my GitHub page. One of my assignments for process Management was to pick an old piece of code and rewrite it using principles from the clean code textbook. One of the biggest issues I had in some of my older code was fragility. Before learning about G-Unit testing and other debugging methods, if my code worked with the input I wanted to use that was enough to finish the project. For example, if my code needed to take in an integer and I typed in a string instead, the program would simply crash. As programmers, we need to anticipate beyond what it takes for the code to function, our programs need to be able to handle various inputs and be able to redirect.

I found this video to be helpful, because one of my main issues since I began programming was writing incredibly long functions, oftentimes in my old code the entire file was one large function where each while loop performed a different task. I still fall into this habit when writing code, so I’ve been trying to follow the 20 to 30 lines long rule for function. I have also been trying to keep in mind that one function should only do one thing, and that thing should be stated in the name of the function. Code that is made of multiple small working parts is much more stable and easier to read than one long code monologue. Writing long functions also Leeds to code rigidity, which is another object oriented design smell. When you have one large function, changing one thing can drastically alter how the function works. Having an error in just one part will result in the entire code collapsing, whereas if you have multiple independent functions serving a different purpose, the rest of your code will remain stable aside from one method that is causing issues.

As I elaborated before in my previous blog post, we are at the point in our computer science degree where we are learning how to write good code, not just code that works. Taking the time to learn design patterns when building your code and looking for code smells when refactoring are a great combination for writing stable code.

From the blog CS@Worcester – Site Title by lenagviaz and used with permission of the author. All other rights reserved by the author.

During this semester, our class learned how to use Docker and worked with Worcester State’s API and backend code that will manage Worcester state food pantry. Working with the API helped me to understand a bit more about web development and how HTTP calls work. I want to take this knowledge a step further and learn about different stacks for web development. I decided to learn about LAMP stack and set it up myself to host one of my projects for database designs on a home web server. LAMP stack stands for Linux, Apache, MySQL, and PHP. Apache is used as the web software, MySQL is the database that works with Apache, and PHP is the scripting language. 

I have experience using Linux and MySQL, however Apache and PHP are new to me and I needed to understand more about these components before continuing my project. Apache HTTP server is a free and open source software that is used for deploying websites. A web server’s primary goal is to act as the middleman between the host machine server and the client’s machine. A web server turns various different file types such as PHP, Javascript, Python, and turns them into static HTML files to be served through the browser. In our class, we worked with NGINX web server using the docker system. I’ve learned through my own research that NGINX is a more recent web server system and it uses threads to handle user requests, managing up to 10,000 connections simultaneously. 

This is the web tutorial I followed to set up LAMP stack on my laptop. I am running Linux Mint rather than Ubuntu, however the process is still the same. I already had MySQL installed on my laptop because of my database design class, so I just had to install Apache and PHP systems. The reason I want to configure this setup is so I can host my final project for database designs on a website. I performed an analysis of the effects Covid-19 had on the US labor market as well as examining various individual companies that thrived during the pandemic. I found the datasets online and created a database in MySQL, then wrote javascript code that graphed the results and inserted that javascript code in an HTML file. I want to pull the project together by placing my analysis on a dynamic web page that I can host from my laptop and update as new information comes in.

From the blog CS@Worcester – Site Title by lenagviaz and used with permission of the author. All other rights reserved by the author.