Sprint Retrospective

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/issues/9

Here I am finding out about docker, posted resources to videos for the team.

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/ApproveGuestService/-/wikis/Docker-Documentation

Created a document that highlighted the key commands that would be used for docker containers and images.

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/issues/28

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/issues/27

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/issues/23

https://gitlab.com/LibreFoodPantry/modules/visitmodule-tp/approveguest/Plan/issues/26

These are the endpoints that I reviewed and moved to done.

From the very beginning of the spring we had assigned everyone an issue of what they needed to start on. From there each respective person worked individually on their assigned task until moving onto the next one. This was working well for our team in the beginning and for me, because I had a higher weight task, because everyone had something to work on. However, once I thought I was done researching docker and creating the wiki for the docker commands, I had run short of things to do with docker. My main task was familiarizing myself with docker but since we were not going to be using docker until at least the next sprint, there was little to do with everything I had just learned.

Another tough issue was the actual design of our endpoints. Our teams had not yet gotten the documentation of what would be stored for information on each person. For our initial design we made simple variables that could be replaced once the correct information was present. Eventually we were able to change into the correct variables with proper documentation.

Our team was very good at coordinating with the others when it came to work on our endpoints. We had originally designed them each with base variables as described before. After the documentation was given, the main problem that arose was the communication between other teams. We needed to understand what we were pulling from other teams and what they would be pulling from us. Our team did well to communicate and document the interaction and solutions on GitLab.

I think something that our team could do better in the division of tasks. For next sprint, as mentioned in class, we will be waiting to assign the next task once someone has completed theirs. I believe this will allow for a smoother distribution of work. Another team improvement, we could have better documentation when working through GitLab. When different people were working on different task, it was easy for the work completed to be missed. It can also cause a lack of understanding through the team if there is not much to go off of.

An improvement I could make would to be to take on a greater responsibility. I need to communicate to my teammates that I need to take on more work than previously because I felt a lot of time was wasted. I have to be better at involving myself in the ongoing process of something new in order to immerse myself, even if it is just to help push someone to the end of their goal. Another change I will make going into the next spring will be better documentation. I posted a document in the wiki for reference, but should be in markdown on the page for everyone to see easily.

Dig Deeper Pattern

This pattern focuses on being able to decompose problems entirely and understand each part thoroughly. Many times, in the work force, people will only have enough approximate knowledge to help them get through their days, but when problems arise, they become useless. It is extremely important to be able to take all parts of a problem and truly understand them. To be able to decompose these large problems, it is important to study and understand every part that goes into it. While doing this however, it is important not to become too narrowly focused on one idea.

I connected with this pattern a lot due to the fact that many times when working on a project, I will run into an issue that I can provide a “hacky” fix to by reading it online, but I never acquire the knowledge of that topic specifically. I often times make the excuse that school causes timelines and completion of projects that are often unreasonable to be able to fully delve into the project. However, I need to start taking these problems apart piece by piece in order to start fully learning anything I come into contact with. If I am able to start with small sections of material, eventually there will be overlaps in knowledge that will build on top of each other until the projects that I’m faced with, now appear to be far easier. It is often overwhelming to start off researching into an entire idea of a project but being able to take small slices of it will make it far more manageable.

I enjoyed in this pattern how they discussed that often times there is a more knowledgeable person in order to fill in the gaps that you may have. In the workforce this can be a co-worker or a higher-up, but often times it is the teacher in school. Being able to create the knowledge for oneself is far superior in the long run than consistently going to the person that may have a better understanding. In order for anyone to reach that status of knowledge, they all took their time to break down and understand individual components of any problem they run into.

Apprenticeship Patterns

In the introduction section of this book, I found it interesting on how the author focused on using the medieval definition of apprenticeship. The author rejected the idea of simply imitating those ways, but rather he adapted from them. While still marinating the core values and goals of apprenticeship, he was also able to help define it in terms of software development. Another interesting part was when the story of “emptying your cup” was told. I can sometimes find myself falling into this trap instead of allowing for me to fully take on whatever help is coming my way in order to broaden my knowledge. One of the chapters that seems to coincide with me is chapter 3, Walking the Long Road. In the introduction, the author talked about how it can be daunting to see people that are miles ahead of you in the software community. However, once you put aside your pride and see how these other people are mastering their craft, you will see they are constantly learning on the same “road”. I personally enjoyed reading this section because often times when I see code or software that I genuinely feel lost in, it can feel hopeless. But everyone that seems to be far more knowledgeable, was once right where you are and eventually you can reach that level. Another chapter that resonated with me was chapter 6, which discussed creating your own curriculum. I am often overwhelmed by the constant thought of grades that I worry solely on completion of the project rather than acquiring the knowledge that will last. When I am able to freely search and learn about whatever I am working on, I thoroughly enjoy learning all the finite details in order to be able to use and grow my abilities. Another part of the introduction that I thoroughly enjoyed was when the authors discussed apprenticeship patterns. Too often in software books the author tells you their experience and how they succeeded, but there will be no correlation to you. The apprenticeship patterns were studying and tested in order to provide a far broader platform to build from. This will allow anyone to develop far better skill sets for many different expertise. I really enjoy when a book is able to have the foresight of not simply trying to show you the way to do something, but rather provide you with a toolbox that you can use to be applied to any scenario. The last part of the book that I found helpful was when they discussed “putting on the white belt”. This simply means you are going into something with no knowledge but an open mind. Too often there are people, myself included, that are skilled in one area that then leaks ignorance into the next rather than allowing for them to fully embrace new knowledge.

Libre Food Pantry

I enjoyed reading about the FOSSisms because it is all about starting to work on your first open-source piece with others. Since this is my first time working collaboratively to this extent on open-source software I found that it was quite useful to read in order to better adapt to the upcoming challenges. I really enjoyed the particular FOSSism about being productively lost. This means that you will not always know the entire scope of the open-source project you are working on. This means you should take it upon yourself to research deeper Into the project while helping strengthen your skills in the areas you already know well. I wrote about this one because too many times I have been lost in a project and felt hopeless but by taking a deeper dive into each individual component, it allowed for me to grasp the concept.

Mutation Testing

PIT mutation testing is great way to test code that may seem like it passes everything, but still contains errors. Mutation testing will insert these faults into your code and will then retest the code to make sure they are properly handled. If a mutated test is killed, that means it was properly accounted for by the test cases and code. If a mutation survives that means that somewhere in the code, there is an error that is not being handled properly. An example of mutation testing will be something along the lines of taking a less than sign ( < ) and making it into a less than or equals ( <= ) to see if the code will be able to kill this mutation or if it survives then something must be fixed.

Final Project

My final project has not been an easy task to deal with thus far. After going far in depth with one of my designs, I came to discover that the use of angular material alongside bootstrap which caused quite a few problems. I have decided to do a full overhaul into angular material. The reason I am choosing angular material is because there seems to be more typescript capabilities while bootstrap seems to be heavy on javascript and css. By going down this path I have been able to make steady progress with my current version of my application which at the time is mostly an interactive sidebar. The main concern I will have this week is being able to make the workouts appear on the home page. I would like to be able to use angular to create a visually appealing layout which will allow for the user to go through the different workouts and select the ones that they would like to use. If I was able to have more time on something like this my end goal would be to add in I/O devices such as being able to print your workout after it has been created. Due to time restraints I will have to remain with simply being able to select and track the wanted workouts on the app. Another large problem I will have to come up with a solution with is whether or not there will be a way to save workouts, or have the workouts appear and when the next desired workout regime is needed, to simply delete the old and then add to the new one. Another issue I have run into is being able to seamlessly add in new workouts to the app without having any effect on the previously existing workouts. This next week will be the time to grind out any and hopefully all of these problems. I have been diving deeper into angular material in order to get a better understanding. I have also been researching more html and css as I have not had much prior experience with these. This has caused me quite a bit of stress because very minute changes have broken the entire app, but I believe that by completing this I will have gained the necessary knowledge of what will be needed in the future. I am excited to complete this app but it is also been an extremely difficult time which will all pay off in the end.

Final Project-Week 1

I will be completing a final project for my CS-343 class. I plan to implement a workout planner using angular and webstorm. The general idea of the website will start with the homepage. On the home page there will be any workout that the user has created. Here it will show the workout types, how many reps/sets and what each workout is. Along the side bar there will be a list of muscle groups. The user will be able to click on these side bars to display a list of different exercises that they could choose from. When the user clicks on an exercise, the tab will open up to a display a picture or video of the workout. From here the user will also be able to set their reps and sets count in which they want to add to the workout. To get started on this process I will be designing each of the slides for each workout. Once these slides are created, I will host them together in a folder. These will then be able to be used and manipulated by implementing a new component called workouts. This will contain and html file for designing the basic template of the slides and their layout. The next will be a css file. This file will allow for me to implement more stylistic changes to the pages. The last two components in the workout section will be .spec and a typescript file. The typescript file is where all the code that will allow for the user to manipulate and change pages. This will also include the code which will allow for the user to take add their reps and sets to the workout. For the first week I have been working putting together each of the slides that will be used for the site.

The tentative plan for these slides will be to make them images and incorporate the other elements on top of the image. Each image will have a unique ID which will allow for the code to distinguish what workout the user is currently looking at. Once this large section has been completed, I plan on moving onto the homepage design where the workout will be displayed. On the homepage the user will be able to remove workouts that they no longer want or remove their whole workout plan entirely and start from scratch. Due to the set up of the app, the workouts will not save once disconnected because that would require saving the data somewhere, while the app is offline.

Define-Use Testing

Many times in testing, the thing being checked is whatever state the object that is being returned is in. While this makes sense for testing whether the output is correct, there are often times you want to make sure that the correct variables are being defined and used. In define-use testing this is exactly what is done. In define-use testing, simple ordered pairs of the lines of code in which the object is created followed by the line the object is used, are created. I.E < 3, 5 >. This allows the user to make sure there is no unused objects that can take up memory for no reason. You can also follow the path of these objects to make sure they are being executed in proper order.

Apps Made Easy With Angular

If you have ever been around anything web-based, there is a good chance you have heard or come across angular. Angular for those unfamiliar is a framework that allows for a wide range of possibilities. Angular all stems from 4 main parts: components, dependency injection, property bindings and typescript. Components are what Angular is entirely composed of. Most things created in Angular are components or collection of components. While there are still a few other concepts to angular, components are the most prominent. Components are usually comprised of HTML, CSS and JS but with angular, these are all combined into an easy to manipulate sense to allow for customization of the components. The next part of angular is the dependency injection which helps largely with dependency management. Dependencies are all in a collection together and when new components are created, the dependency for that object is automatically created and put into the collection alongside the other dependencies. This allows for the user to easily streamline dependency management as angular is able to “automatically” create and track dependencies. The next main aspect of angular is the property bindings. What this means is that the data that the app contains is separate from the what is being presented. This allows for the user to make changes to this data and automatically have it update and be displayed on the presentation side. This allows for the user to seamlessly update anything needed in real time. The last part of angular is the support and use of typescript. Javascript, for the ones unaware, is a subset of typescript. Typescript allows for a very straight forward approach to writing javascript. The user is able to write the code needed in typescript and it will be automatically generated into javascript to be used by the app.

The main benefit of angular is allowing for users to easily be able to build large scale apps with everything being self-contained in the program. A lot of the complicated processes that went along with developing apps are now very easy to be implemented with Angular. People that are not skilled in javascript generally have a much easier time adapting typescript due to the fact that the syntax is not all too different from java. Most skilled programmers are able to pickup and implement typescript rather quickly. This allows for almost anyone to be able to create and build large scale apps without having to personally be responsible for many of the complications that would prevent people from trying.

If you want to learn more, this website has a great overview of Angular:

https://www.telerik.com/blogs/all-things-angular

TypeScript/JavaScript

Ever wanted to build a website and be able to add in interactive elements to the page? With JavaScript this can all be accomplished. JavaScript is a programming language that is used with websites in order to make the design better, sleeker and an overall better website. JavaScript can also allow for people to create games and apps as well. These games would be browser based and would allow for the creator to be able to implement the useful tools that JavaScript provides. Mobile apps are starting to come around to JavaScript as well. However, JavaScript is not always the easiest to learn or pickup. That’s where typescript comes in handy.

With typescript, users are able to code with a far more interactive interface. Once the typescript is written, there is a TSC or type-script compiler that compiles the typescript code and converts it into JavaScript. This allows for a much easier integration of JavaScript because of the ease of typescript. Typescript is a rather new concept, only recently appearing in 2012 by the creator Anders Hejlsberg. Typescript has many advantages to it over JavaScript. For starters TypeScript, as mentioned before, is far easier to code and the user does not have to worry about it being converted into usable JavaScript. TypeScript is also open-source, meaning that the software for its development can be used by anyone which allows for constant improvements to be made to the software. TypeScript also comes with development tools built in. With these tools, debugging becomes far easier to do and allows for different types of testing. Another great feature that TypeScript has is that it can function with REST parameters. REST is a type of software design that I have mentioned previously in this blog. Another benefit of the TypeScript language is that it is an OOP language, or object-orientated programming language. This allows for TypeScript to be easy to maintain and keep clean.

TypeScript is essentially the next phase of JavaScript because of the fact that TypeScript is a superset of JavaScript. This means that every feature that JavaScript normally has is implemented with TypeScript. The only difference is that TypeScript, as mentioned before, has far more additional benefits to it. When it comes down to choosing whether or not to use JavaScript or TypeScript, it’s a personal choice. However, since TypeScript was recently released, it has not had as much time to spread but I believe the obvious choice would be to switch over to TypeScript because you are missing out on many great features.

https://en.wikipedia.org/wiki/TypeScript

Create your website at WordPress.com
Get started