Category Archives: Week 12

Final Project Update: Taking a different shape than planned

The final project for this class is taking on a different form than I initially planned. I had planned to use google sheets API in my project, and while I am not ruling out that possibility, I am running into some roadblocks. The API seems to require authentication that I can’t get to work quite right. I may end up using a different solution for a backend, but we will see.

I am also thinking that my front-end will end up looking not much like my wireframe. At this point I’m not sure I care. Figuring out HTML and CSS implementations for something that I’ve had no experience in for this project is very difficult, and I think I (like most people), will end up modeling my project off of something that already exists. As I posted last week, Tour of Heroes is a very appealing course and I am learning a lot by deep-diving into it. I would highly suggest implementing that into the course. It utilizes a lot of concepts that are useful in angular and in the project: buttons, pages, loops, and CSS stylings, and more.

The other roadblock I am running into is that the work this semester sure has been back-loaded. 5 classes, 3 projects and 4 exams to prepare for is a tough ask. As an adult student with a job and a mortgage, it sure gets stressful. I will definitely not pretend to be the most overworked student ever, and people have definitely overcome tougher obstacles. Yet even still, my despair is immeasurable.

From the blog CS@Worcester – Alan Birdgulch's Blog by cjsteinbrecher and used with permission of the author. All other rights reserved by the author.

Mock Testing

Recently in CS-443 I was introduced to testing using
mocking. Mock testing makes use of a mocking framework (we used Mockito in class)
to create mocks which the place of regular objects. A mock can call the methods
of its associated class or interface, but it will return a default value of 0
instead of actually running the behaviors specified in the class’ methods. It
is also possible to tell the mock to return specific values other than the
default to make sure that different methods return different results. It was
interesting to learn about implementing Mockito and working with mocks in my
projects, but there was one question that I kept asking myself: What is the
point? Why go through the trouble of setting up mocks when you could just
finish writing the code and test its actual behavior? I decided I would search
for an answer to these questions on my own, and in doing so I came across an
article by Michael Minella titled “The Concept of Mocking.”

The article can be found here:

https://dzone.com/articles/the-concept-mocking

Unlike the example in class, this article teaches mocking
and its purpose clearly and simply. This purpose, as the article explains, is
to test functions without executing other functions that they depend on. The
article demonstrates this with a simple example which includes a doLookup
method that calls a lookupByKey method. By using mocks, it is possible to test
doLookup without needing to make sure lookupByKey is also working correctly. This
extremely simple example has helped make the point of mocking much clearer to
me. It still seems better to me to write tests based on the actual code of a
project, but I can see mocking being useful in situations where the code a project
depends on is not all accessible. I think the example in class may have been
too complex an introduction to mocking, and the difficulties I had getting the
example code to work made it difficult for me to understand the basic concepts behind
mocking. The simplicity of this article enabled me to see the purpose of
mocking, which I think will make it easier for me to apply what I learned from
the class activity.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

FPL&S 3: Component Interaction, Custom Services, and Fear of Commit

After completing the file upload portion of the project last week, I found myself in fear of committing my changes. I have always had this problem: I want each commit to be concise, change as little as possible, and even have perfect whitespace. This minimizes changes and makes it easier to track down commits where bugs are introduced, but moving forward like this will slow me down, as it has in the past.

But once I made that first commit, things starting progressing quicker. It was time to start adding more Components. Once I could interact with the files I was uploading, it was time to be able to delete files. With more functionality and interaction with the cloud storage, it was best to remove this behavior from the Components and move them to a Service. This custom service class handles all interaction with the cloud storage service, so there aren’t some components adding files and others deleting files. Everything is nicely encapsulated, and user interaction only needs to forward actions to the Service.

I do wonder if there are downsides to this design, and whether Angular might have features I’m missing that may be better suited. However, I definitely believe that UI Components in any framework should delegate user interaction to another class that contains the logic. Even so, is importing a Service class the proper avenue? I have also considered passing commands in each Component up to the main app Component, which would have a single reference to the custom Service I created. This would quickly complicate the application architecture, however, because changes in the cloud storage will require updates in the children Components. For example, the list of Files will have to update, and a file shouldn’t be removed from the UI unless the delete action is successful, requiring a callback to be passed down to children.

The software engineering practices I’ve studied and written about this past semester are at the front of my mind. My current solution is rather simple, and although I am anticipating possible problems, I am not over-engineering and adding unnecessary complexity. I am following Clean Code principles from Robert C. Martin; making code easy it read, making it work, and refactoring when necessary.

The overall design of my final project is beginning to solidify. I naively thought I would download all file metadata from the cloud storage when loading the web page and then maintain them from there, but I’ve realized that all of this data is going to have to be stored in another database, which I will access using a REST API. This will store all the file data and URLs to the files themselves and will be a good chance to practice with data synchronization between databases.

Through the next week I will implement the database. Once I have this synced client-side, I can add Components to search/filter the files and load the files that are selected by the user.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

10 Software Testing Trends

Hello again everyone and welcome to my fourth entry for the semester on this blog. today we are going to talk about some software testing trends. As the title of this post suggests, we will be talking about ten of them today. The article was written by Ulf Eriksson (Really cool name) and i started this article by skimming and it seems to be very short and concise, which means it’ll be easier for me to write about. I will only be writing about the five i found the most interesting.

So obviously, this article is going to be about trends that everyone should be seeing in 2019. Ulf leads off with mentioning the “evolution of new testing approaches” (Eriksson) due to new developments with Agile and DevOps. He then begins his list with discussing Agile. He says that Agile is being used in more and more comapanies. He then talks about what Agile is and how it works, but if you’re reading this you probably know what agile is so I won’t bore you with that. The next part caught my eye because it has to do with machine testing. I don’t know much about machine testing, but it still has my interest. Ulf describes how it is used as follows: Test suite optimization (redundancy), predictive analytics(key parameters), log analytics(automatic executing), traceability (test coverage), and defect analytics(identifying high risk areas). The next trend is the adoption of DevOps. This part was very short and it talks about continuous integration and continuous delivery. Another trend was shortening the delivery cycle. This section talks about how new technologies are being used in order to speed up the deliveries. This is interesting because this will always be a trend. New technologies are coming out everyday, so it is impossible for this trend to die down. Ulf also discusses big data testing as a trend, and I chose to write about this because it isn’t my concentration so it is interesting to read about this considering I am not studying it. Basically this kind of testing makes sure the large amounts of data are being verified correctly. In other words, this tests the quantity and quality of data.

I would have loved to write about every trend on this list, but this blog would be way too long and I would lose all my reader(s) about halfway through. However, Ulf Eriksson did a great job with this article. He didn’t go into much detail about every trend because some of them should have already been known. However, the lesser know trends were explained very well. This article was a very interesting read because I’m in quality assurance testing now, and it is nice seeing topics I learned in class in articles. I would recommend this to any testers out there.

https://dzone.com/articles/10-software-testing-trends-to-watch-out-for-in-201

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Creating Workflow Diagrams & Beginning the GitLab Migration

Last week started on Monday with trying to resolve why the DCO bot would not show up as a status check for a GitHub repository. I tried enabling it for the test organization instead of an individual repository and that still wasn’t working. Eventually by searching the error message that appeared in the box I found out through an article for enabling CI that in GitHub you need to manually trigger the process before you can enable it as a status check. This solved the issue and after creating a branch, committing to it, and merging it with master, the DCO bot ran for the first time and then showed up as a status check in the branch restrictions menu. I updated the pull request with a comment about this since it resolved a discussion that had been ongoing with Dr. Jackson. After that, I commented on the workflow diagrams issue to see which sections should have diagrams created for them. I looked over the contributing document and thought that Getting ready to work, Work, and Getting your work reviewed and merged all seemed like they could use some diagrams. Finally, I figured out what I would be doing for the rest of the week and planned questions for the next day’s meeting. 

Tuesday started with a research meeting that was quickly joined by Dr. Jackson over the phone. We discussed various things including the ongoing project board issue that needs to get resolved so we could update the documents with which board structure to use and how to set it up. We also talked about changing to a different license for some of the project files. I helped to resolve a Discord issue with server joining messages. Most of what I would be working on for the rest of the week was beginning the migration from GitHub to GitLab as it was at this point a pretty sure thing that we were going with this platform. I would start this by deleting the previously imported repositories and re-import them.

Wednesday I started this GitLab migration and deleted all of the previous repositories in the LibreFoodPantry GitLab group. I then imported all of the projects from GitHub to my account and transferred them to the LFP group. One issue that I discovered when importing the projects was that it didn’t link issues that were created by some users on GitHub that didn’t have a GitLab account and it made me the owner of these un-linked issues. After that, I read over the license that Dr. Jackson suggested we start using. After reading it over, I agree with Dr. Wurst that it seems a little too complicated. After getting a response from Dr. Jackson on which sections to create diagrams for, I started working on this by creating a new feature branch. I started with the Getting ready to work section. I looked at the links he suggested for how commit diagrams were designed and somewhat used some of the styling from these later when I was creating my commit diagrams. As I was creating the diagrams, I was running through the workflow myself to see that it worked properly for me. I ended up adding some git commands into the contributing document that I thought would be helpful. I also created a new issue that I discovered when testing this workflow about how to shops update their master branch when changes are made in LFP’s upstream. I suggested using GitLab’s auto repository mirroring function that takes care of this automatically. I also tested out pushing an empty commit to a new branch and creating a work-in-progress merge request back to the LFP project. I thought it was cool that when you push to a branch after doing this the commits also go to the WIP merge request so others can see your progress. By the end of the day I had created diagrams for Getting ready to work and the work sections. 

Thursday was exciting. A decision had finally been reached and we would end up using GitLab and Discord! After seeing this I posted my migration issue and also replied what was the best document to follow for importing repositories. It was decided that shop managers would re-import the projects so that they would be the owners of any issues that didn’t properly link in the import. I then went back to the diagrams and tested out how you update a feature branch from the master branch. I realized that I forgot to add the developer’s computer to the diagrams and went back to the previously created diagrams and added this. I also wanted to figure out where upstream was pointing to and realized that it was the LFP project’s master branch after some searching. I then had to figure out how to set the upstream’s master for a cloned repository of this from the shop fork, this was aided by a past exercise from CS348. I think this command should probably be added to the contributing document since it is not mentioned and not something that happens automatically. I also discovered some other issues that should be touched up on in the contributing document but I wanted to finish the diagrams before migrating to GitLab so my commits would transfer over properly. The hardest part of the diagrams was creating the commit graphs. I figured this out by looking at the commits that were on the different branches through the Web UI and after that I discovered that GitLab has a commit graph for repositories. That helped greatly with creating diagrams for the merge commits part of the workflow. I then finished the Getting your work reviewed and merged diagram and pushed that to the branch. 

On Friday there was a bunch of notifications since a lot of new issues were created on GitLab since we started migration to this platform. I started looking at some of the new ones and also replied to Dr. Wurst’s question about why commits on his projects seem to have transferred correctly. I discovered that the issue with linking accounts is more related to issues and not commits and that GitLab seems to make dummy accounts for commits if it can’t link to an actual account. I then enabled the DCO push rule for Dr. Wurst’s imported projects. I then created a pull request for my diagrams before the ProjectTemplate repository was imported to GitLab. I  also assigned myself some new issues to work on. Later that night Dr. Jackson discovered when importing the ProjectTemplate repository that issues I created on GitHub weren’t being linked to my GitLab account on. We tried to resolve this in various ways by enabling different options. I tried signing in to GitLab with my GitHub account and set the same email address on both platforms to the same one and made it publicly viewable. Sadly, this did not resolve the issue and we would try to fix it the next day.

Saturday, Dr. Jackson decided that I should import the ProjectTemplate repository myself so that it would automatically link all of my work to my GitLab account. This worked fine except for a couple of merge commits I had done with a private GitHub email address through the Web UI. We decided this was fine and I left it as-is. Finally, I enabled DCO checks for the BEAR-Necessities-Market project and updated the issue with this information.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Going Back To Square One

Good my fellow readers!

Today I will be discussing an individual Apprenticeship Pattern from the book, Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. The pattern I would like to discuss today is naturally the first one, Your First Language, because where else is there to start but at the beginning?

The pattern starts by defining itself as a pattern for those who have surface knowledge of a couple of languages. It suggests that this particular pattern is for those who need to learn a language to solve a problem at work for example, or need to know a language for a job interview. It then launches into the solution, through execution of the pattern. To put it plainly the pattern is to pick a language and learn it. Having a problem to solve helps the process by giving you a goal to work towards and a drive to keep learning. It is also advised to take things slow and in small steps. It is also suggested to find a community and learn from its members as some methods or teachings may only be spread by word of mouth. It ends by reminding the reader to not get stuck with one language and to spread out into other languages.

I will admit, with this being the first pattern in the book I expected it to be for total beginners but it is aimed at just about everyone. What I find interesting about this pattern is that it seems to cater well to those who have never really picked up coding before or someone who, like myself, have had years of high school and college education in coding. I will admit that the amount I know about all the languages I have learned about is somewhat shallow. Some go deeper but many are probably not that far off from just surface knowledge. I might just try following this pattern after graduation. At first, I would have only recommended this pattern for only beginners who haven’t had formal schooling but after reconsidering, I think even those like myself who have had formal schooling can benefit from this pattern.

That’s all I have to draw from this first pattern and I hope to get more from future patterns. Until next time readers!

 

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

“Expand Your Bandwidth” Apprenticeship Pattern

I am writing this blog post about the “Expand Your Bandwidth” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about learning about a greater variety of topics than just what tends to be the most relevant. The chapter describes the problem as having a narrow understanding of software development that focuses only on the low-level details of past work. The solution to this is to just start learning about different things. I think that this is a relevant concept that I seem to be dealing with at the moment. My specialty is computer science, and I have a deep understanding of many of the fundamental concepts in computer science. Software development, though, involves much more than just computer science, and I have not researched software development beyond researching computer science. The problem here is that I have a narrow understanding of software development, and the solution is to research the other topics that are important to understand besides computer science.

I think that this chapter relates closely to the “Concrete Skills” apprenticeship pattern. The main difference is that this assumes you already have a full set of skills that are already being applied in a day job, and “Concrete Skills” is about developing those skills in the first place. I have not yet begun a career in software development, though, so these problems are effectively the same. I have a narrow understanding of software development, and this narrow understanding is a set of concrete skills.

There are often times that I do research new and unfamiliar concepts, but these tend to be concepts that are still within the field of computer science and not software development. I do have a goal of learning and understanding more, and there are a lot of topics that I find interesting enough to read about, develop some experience with and practice applying. This book constantly emphasizes the importance of a willingness to read, practice, research and learn, but it puts an equal emphasis on software development. My concerns should be lessened by just applying myself more toward software development in particular.

From the blog CS@Worcester – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Studying the Classics

 

 

 

 

 

 

 

 

 

 

 

Link to the article: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch06s03.html

 

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Expand Your Bandwidth

The apprenticeship pattern of “Expand Your Bandwidth” refers to the situation in which you’ve picked up a basic set of skills, however your understanding of software development is still narrow and only focused on the low-level details of what you’ve been working on. In this situation, you’ve only been taking in a relatively small amount of information gradually, but sometimes you need to take in a large amount of information and efficiently absorb it. So in this case, “Expand Your Bandwidth” means to be able to do just that.

I can see how this pattern is really important and would be immensely helpful to master, but being able to take in more information than you’re used to and at the same time efficiently absorb it, understand it, retain it, and apply it is a tall task. No doubt that mastering this early on in your career will be a massive boon.

This pattern includes some useful examples of where you could seek out new knowledge and experiences. For example, signing up for Google Reader or any other blog aggregator and subscribing to software development blogs that interest you is definitely a good idea to learn about a variety of topics from multiple perspectives. If nothing else, this is something that I certainly plan on taking away from this post. Rather than wasting my time on websites like Reddit, I think it’s in my best interest to spend that time reading something more productive. I also think subscribing to a moderately high-traffic online mailing list and trying to answer people’s questions is a good idea as well (maybe something like stackoverflow).

Overall, I’d say that this pattern made me understand a little better about how an apprentice will have to take in much more information than they’re used to taking and also be able to process and retain it, while at the same time not getting overwhelmed by it. Of course there are times in which you should stop focusing on expanding your bandwidth and come back to the craft, so it should only be used as a means to an end.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.