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.
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.
“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.
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”.
During this past sprint session my team and I worked on the LibreFood Pantry Identity and Access Management System. Our goals in this sprint were getting a KeyCloak implementation going and building a small API to work with keycloak and LibreFood Pantry. The first issue I created was designing our API (what endpoints should it have and what basic structure should it have). This issue had a weight of one and I was able to complete it between class on Wednesday and the following class on Monday. This involved creating the LibreAPI/src folder and using NPM to initialize the folder with a package.json file and manually add the folders. The next issue I created was to begin creating the API and writing code. This step involved watching a lot of videos and reading tutorials on how to implement a simple API. The API has two basic functions: Post a string and get an array of all the strings. Two YAML files were created in order to service the endpoints using OpenAPI implementation. I also created an issue on linking KeyCloak with our API and put in in the backlog until there was more research available and I would be able to have the other team mates catch me up on their KeyCloak information.
As an Individual I want to improve the way I communicate with my team and try to keep my focus narrowed in. During group meetings, I would find myself asking questions to the research team about KeyCloak that are very off topic from the current discussion. In reflection, I think this may sometimes throw off the group discussion and put my teammates “on the spot” to mentally shift gears to what I’m asking to try and best answer my question. I think this throws off the workflow and next sprint I plan on writing down questions that come to mind as I am working and near the start of the meeting (possibly during my stand up) and chip away at questions during that time, or bring questions up when they are relevant.
As a team I believe we worked very well together. We all have a true interest in this project and put in a lot of time outside of class to get things done. For this next sprint, we plan on all focusing on getting keycloak up and running and will revisit the code we worked on once we get past our current roadblock which is getting one instance of keycloak to work and use that as the basis for our project. One way we can improve as a team is to communicate more outside of class via discord channels and also communicate with other teams. We are in the same classroom as other teams working on LibreFood Pantry and our project needs to be linked together with everyone else’s work by the end of the semester. This means we need to take more time to talk with other teams during class or via discord voice channels.
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.
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.
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:
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.
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.
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.
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.