Author Archives: mfelipe98

Study the Classics

            In the “Study the Classics” learning pattern of the Apprenticeship Patterns book, the focus is on catching up with the well-known literature or practices in the field when your knowledge of theory is more limited. Luckily, I feel as though Worcester State has prepared me well with a mix of theory and practical, technical skill, but this pattern stood out to me, nonetheless. Sometimes, when talking with peers or reading online from people more experienced than I am, I find I can get bogged down in references to things I have no knowledge of. This usually detracts from what I was initially trying to find out about. There’s more than enough “good” material out there for many, many lifetimes worth of learning. What concerns me is finding the right material and learning about it in the best path. Even if I can find all the proper materials for my learning goals, working through it can be difficult or impossible if I don’t go about it in the correct way.

            As the pattern mentions, exposing your ignorance is as essential part of opening yourself up to learning. This is something I don’t think I really have a problem with, as I usually try to put my ego to the side when taking on new tasks. What I really need to start doing is also mentioned in the pattern: keep a reading list and read constantly. I’m not great on this front. Perhaps these are particularly difficult tasks for college students because most of our work comes outside of our courses anyways, but I could definitely stand to try more, especially once I’m out of college.

            I also find difficulty in using the classics to inspire more current learning. I do feel confident applying my knowledge to new topics (I feel confident that my knowledge is translatable) but discerning the relevant material from the outdated in the first place can be difficult. This is a very handy skill and I think it probably comes with an expanded knowledge base anyways. As long as I get on the road of continued learning and studying the classics, I think this skill should develop.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Stubs vs. Mocks

            Having started to learn about stubs with relation to testing in class, I went to do some further research on the functionality and usefulness of this testing strategy. I found a great deal of articles comparing stubs with mocks and evaluating their differences. I haven’t heard of mock testing before, so this was interesting to look into. Turns out, it’s pretty similar to some work we did in class. I found this great article detailing the differences which also gives a simple, understandable example.

            The main difference in stubs vs mocks is that stubs are looking to see a certain behavior, while mocks are also setting an expectation and then verifying that expectation. This is demonstrated with the use of a couple examples. Stub methods are created in the example by not doing anything but printing out “_____ is working fine.” This is to check that the correct method is being called and in the proper context. On the other hand, a mock uses a third party library (Mockito) which creates a mock Mathematics object in a test setup. Then, still in setup, the expectation is set: when(maths.sub(2,1).thenReturn(1); This is just saying 2 – 1 = 1. And finally, this expectation is verified in the test with Assert.assertEquals(1, s.subNumbers(2,1)); If this explanation seems choppy, sorry, I tried to condense 44 lines of code down to just this. Anyways, the idea is that a mock object is made, expectations are set, and then they’re verified. So both stubs and mocks are useful kind of white-box-ish testing styles, but mocks seem to have a higher level of testability. This doesn’t mean they’re necessarily better or more useful, but they have their purpose too.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Sweep the Floor

            In the “Sweep the Floor” learning pattern of the Apprenticeship Patterns book focuses on the transition when joining a team. Being the newbie is not an easy task, especially when unsure of your skills, so finding your place and claiming suitable work can be a struggle at times. Since I will hopefully be joining a software development team in the coming years, or even next year as an intern, getting accustomed to working on a team and proving my value while not finding myself in too deep on work that I am not ready for will be a somewhat tricky line to toe. This pattern focuses just on that.

            The idea of sweeping the floor, while not meant to be taken literally, can be a literal task. It means to take the tasks that need to be done but no one wants to do. This can either be menial tasks or simply tasks that are painfully boring or something. Although not attractive, this can be a way to start making progress on a team and pay your dues. It can help gain the trust of the team if the tasks are done well, oftentimes because they can be important sub-tasks which free up the way for higher-level developers to make more meaningful progress, so they’re still quite important.

            Having the humility to take on tasks like this is not something I’m worried about; I do not come into the field with a large ego. I knew nothing about computer science before I started my major. I’m not afraid of having to build from the ground up. I’m actually quite eager to. Others’ evaluation of my work will be the most valuable to me, a concept which is alluded to in many other learning patterns within the book. I think this is a great idea and helps carve out a position on a team which can only stand to grow.

            It’s also important to consider the downsides that the pattern mentions as well. Becoming the one that other developers dump the meaningless/annoying tasks on is clearly not the goal, so making sure to not get complacent and expressing an eagerness without overstepping bounds is essential. Nevertheless, I love this idea and plan on going through with it once I join a software development team.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Scrum Quality Assurance

            Given that we are working in a Scrum team in our Software Development capstone and that we got ample practice with the Scrum in our Software Project Management course, I thought it would be interesting to see the crossover between quality assurance and the Scrum workflow. Scrum is also widely used, so this should be important to know for the future as well. I found this article: which talks about the role of quality assurance on a Scrum team.

            It’s important to remember that the members of a development team do not have pre-defined roles. It’s assumed each member of the team can collaborate with any part of a project, even if certain members have more specialization in certain areas, like product testing in this case. With that in mind, it makes the Definition of Done all the more important. Requirements for testing should be documented and understood by the development team and the product owner. This prevents conflicts during the sprint review if the development team thinks something like compatibility testing needs more work and the product owner is ready to deploy. If there is a more comprehensive Definition of Done, these conflicts are avoided since they would have been discussed ahead of time.

            Quality assurance on a Scrum team is a large part of the process and requirements are developed during sprint planning. It’s important that there is close collaboration during the sprint between the development team and the product owner though, even though the development team is delegated most of the decision-making responsibility for how work will be completed. This keeps the whole team in tune and avoids conflict. It also provides for a closer, more efficient work environment as understanding is enhanced throughout the team and the owner.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Software Testing Life Cycle

            I was interested in learning more about how software testing works in the professional world on a software development team. Since we are learning about the crafting of software tests in our class, I thought it would be interesting to learn how the pieces are put together, like how developing requirements goes into crafting tests and then executing them. It’s an essential part of a software development team, of course, and I’m sure I’ll be doing plenty of it in my future. I found this resource: from Tutorials Point that gave an overview of the “Software Testing Life Cycle” (STLC) which help put the pieces together for me.

            First, what is the STLC? It deals strictly with testing and “starts as soon as requirements are defined… by stakeholders.” Sidenote, this reminds me of test-driven development, which, by my understanding, is a common practice in software development these days. The STLC consists of 7 parts. The first is requirement analysis, at which point the team analyzes the application under test (AUT) at a high level. Then comes test planning where a strategy for testing is devised. Then is test case designing which is applying the requirements and making tests according to the planning. Then is the test environment setup for integrated testing. This is the last step before actual testing. Next is test execution which yields defect reporting. This either validates tests or finds bugs. Last is test closure, where testing is finished and matrix, reports, and results are completed.

            This was great to see the pieces come together. This very basic overview helps me see what working on software testing in the professional world would be like. Seeing a timeline also provides context for some of the things we’ve been learning in class.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Find Mentors

            The “Find Mentors” learning pattern from the Apprenticeship Patterns book is one that I definitely should have focused on earlier. This pattern is focused on find more experienced developers around you early and leveraging their knowledge and practice to take steps forward in your apprenticeship. Keeping with the master craftsman and apprentice theme, no apprentice will learn as effectively without someone to help them along their way and point out the unknown unknowns. The pattern recommends reaching out early and often. The only downside is rejection, which is easy to get over, especially if it is followed by acceptance at some point.

            In my computer science journey, I need to take this message to heart. Oftentimes, I try to do most of my learning on my own. I know I can have a kind of unorthodox way of teaching myself things, so I usually try to stick to myself when learning. I do quite often leverage the help/advice of peers though. Most of the people I’ve become closer with in the WSU computer science program I have worked closely with and either have some knowledge to gain from them or have some to share. While I realize working with peers is great, I definitely have fallen short on the front of getting help from those who are leagues ahead of me, like my professors. Looking back, I definitely should have attended more office hours and been in closer contact with my professors and advisors. That’s a goal I have for grad school, especially since I hope to be working as a research assistant, so this would be perfect.

            As the pattern mentions, it is difficult to get over the awkwardness of asking someone to mentor you. I’m not really sure how or who to reach out to in a professional setting, and I’m also not sure of what I would be looking for from a mentor. Although mentoring in school is great, it would probably be quite different than mentoring in a workplace. This is something I should look further into. Who can I reach out to as a mentor and what should I be looking to gain from them? If I can get the answers to questions like these, I think I would feel more comfortable filling the apprentice role.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Retreat into Competence

            The learning pattern “Retreat into Competence” from the Apprenticeship Patterns book is something that gave me great comfort to read. The idea is that, when overwhelmed by your ignorance in the face of a complex problem or task, it can be beneficial to temporarily fall back onto what you know. This can boost your confidence, refresh your mind, and/or reveal relevant applications of the knowledge you do have. All of these things can make tackling your ignorance easier, or at least a little more manageable.

            As the book points out time and time again, it is very beneficial to accept what you don’t know and face it head on, but sometimes this can leave you stranded. There are many times that learning new concepts can feel like reading a different language or can make my eyes glaze over for 10 minutes before I realize that I haven’t been paying attention and need to start again. In times like these, I believe this learning pattern is very beneficial.

            For example, in the current course, I needed to learn Vue.js for the project. It’s a pretty straightforward task, but doing it was not very easy. I still wouldn’t call myself comfortable with Vue.js, but I definitely made some substantial progress in the face of feeling totally overwhelmed. When there were times that I didn’t know how to approach the sub-problems of learning that I faced, I found it supremely useful to take time off and look at other parts of the project which I felt more comfortable with. I retreated to things like looking over the backend API endpoints and practicing them a little bit before returning to Vue.js. These breaks allowed my mind to refresh as I could read over materials again with a better understanding and then practice the problems I was facing.

            I think the main difference in what I was doing was that I did not set blocks of time for my retreats into competence. When I returned to my real work, I sure felt more confident and had less of a sense of imposter syndrome, but sometimes these breaks were too long and help me back from real progress. I think measuring some finite time will help greatly in picking myself back up without being a hinderance to progress. There are plenty of times I know I will become lost in the capstone, as well as down the road in every project I work on, so I predict this learning pattern will be a very helpful tool.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Boundary Value Testing & Equivalence Partitions

            I was looking for some materials to supplement the work we are doing in Software Quality Assurance and Testing (CS-443) and I came across a nice article from ReQtest entitled What is Boundary Value Analysis and Equivalence Partitioning? I found this to be a good supplement to our in-class activity on boundary value testing, summarizing some of the key ideas. It helped me nail down the concepts and is a nice, short resource for me.

            The article begins describing boundary value analysis. It highlights it is focused on, well, the boundary values, as, “for the most part, errors are observed in the extreme ends of the input values.” This directly relates to the topics covered in class, but is limited as it is mostly focused on single inputs, rather than testing for multiple inputs like we did in class. The article then provides a couple example for an input domain of 1 to 100. The exact boundary values would be 1 and 100, just below boundary values would be 0 and 99, and just above boundary values would be 2 and 101. This seems similar to robust boundary value testing. However, the article doesn’t consider multiple inputs, so there is no noting of nominal inputs or the single fault assumption, or worst-case boundary value testing. Nonetheless, I find it is a concise way of summarizing normal boundary value testing.

            The article then goes on to describe equivalence partitioning, which is the division of, “test input data into a range of values and selecting one input value from each range.” This goes more towards describing the domain of input values and somewhat alludes to physical and arbitrary boundaries. These are not described within the article, but are worthy of noting. The example given is again in the 1 to 100 acceptable range. The article states that one valid input class is anywhere within the 1 to 100 range, another is any value below 1, and the last is any value above 100.

            Together, these two topics do well to sum up the different ranges of inputs for boundary value testing, with equivalence partitioning touching on a little bit of worst-case boundary value testing. Overall, I thought this was a worthwhile article and was helpful. I can see myself returning to it when I actually am writing tests. Boundary value testing is quite useful in many cases, so it’s a topic I’m happy and interesting in learning more about and practicing.  

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Create Feedback Loops

            The pattern called “Create Feedback Loops” in the Apprenticeship Patterns book focuses on finding ways to identify areas of knowledge which are lacking and how to overcome them. One point which I found summed up the learning pattern quite well was, “An apprentice probably shouldn’t work on not making mistakes early as much as they should be working out how to identify the mistakes you make.” In the context of feedback loops, this means that rather than skimming over the areas of understanding which are lacking, find someone to support the necessary learning and identify/correct mistakes, as this can provide a solid platform for learning. As for the areas which a “white belt,” such as myself, feels comfortable in, there should be people to feel comfortable with going to for review or correction. Essentially, you don’t know what you don’t know, which can be a huge hinderance to progress.

            I find this to be a particularly tricky learning pattern. Not that it’s hard to understand, but finding the proper resources and mentoring is not easy, especially during the current semester full of social distancing and online isolation. I think I’m very open to being corrected or shown a newer and better way to do the things I’m already good at, but finding someone to help me in the first place can be a struggle. I totally agree with the premise, but building a feedback loop is no easy task.

            I think incorporating this at a college level is definitely the best place to start, and I’m happy to be continuing my education at grad school as it gives me more time and opportunities to receive feedback in a lower pressure setting. Sure, my grades depend on my performance, but I don’t have a team/company relying on my work, and I don’t rely on the quality of that work for my well-being and forward progression as a professional. Also, having peers to work with and derive feedback loops from is better for starting as we are equals, rather than getting feedback from higher-level developers or something.

            I think one way I could implement this into my current learning is in the capstone. Perhaps there would be some time to do pair programming. I think this could be super helpful as it’s similar to working through an example problem, but I also have the support of a peer who could share knowledge and provide insight on how my train of thought is flowing, whether positive or negative. I’m happy to incorporate this pattern into my learning.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

This was easily accomplished by everyone. This was learning the issue board.

This was us choosing a Scrum master. We decided on Tim Drevitch.

This was our review of the LibreFoodPantry website which was to get an idea of LFP.

This was creating the requirements for the GuestInfo EventSystem, in which I linked resources and described the requirements.

This was the most time-intensive task. I linked multiple tutorials for Vue.js, all of which I completed. This encompassed most of the first two weeks of the sprint for me.

This is the repository I made which contains all of the simple examples we created for small Vue.js, Express, and MongoDB applications to pull from.

These 3 activities are encompassed in the GuestInfoSystem section of Thea’s Pantry. There is a repository for frontend and backend work. It has basic files for each which is taken from the WNE example.

This is created a sample Vue.js project, which is on the example work repository.

            Overall, I think we worked quite well as a group, and I would attribute a good deal of it to how well our sprint planning went. We were thorough in going through topics which we felt we needed to cover and created individual cards for everything so that all of our tasks were tangible. Furthermore, we were fair in our division of labor and honesty in what we wanted to do while still taking on enough responsibility as individuals to support the team as a whole. What worked well towards the end of the sprint was also when we focused on what we hadn’t yet finished and allotted the work evenly. Not only this, but we had also made enough progress that I found it to be helpful to have a sort of progress report session in class. We were going through with our Scrum meetings daily, but it was more in-depth, and we were able to articulate what we had done and where our progress was taking us. This was very helpful and perhaps we could incorporate this into our Scrum meetings, allowing us to have a better stream of communication.

            There weren’t many things that didn’t go well for us, but a few include some lacking communication at times and a lack of due dates. As I articulated previously, I was only able to notice any lacking communication when we did communicate better. It wasn’t that our communication was impeding our progress, but it definitely helped to have a clearer picture of the project as a whole when each of us was clearer about our individual progress. As far as a lack of due dates, we became a little rushed towards the end of the sprint since we spent a little too much time completing our learning tasks. If we set limits on these tasks, because they were more open ended, we could have gotten some of our more rushed late sprint activities done faster.

            As far as changes to be made as a team, I would focus on making the changes I stated previously. To get better communication, we should make better use of the cards on the GitLab issue board. Each card should have documentation of information learned and progress made it on it. This makes it much easier for everyone to read the cards instead of having to check Discord or wait for the in-class meetings. Also, we should start putting due dates on the cards for our own sake. This would keep us on track better.

            Individually, I should plan out my time more. I was feeling lost with Vue.js so I spent a lot of time on it. I got into stuff that, later on into the sprint, I found out that I didn’t even need. I need to be better at setting due dates and creating more incremental tasks. I took a couple longer tasks and rather than breaking them down, would try to accomplish a couple things at once which could have been subdivided. This, along with better documentation on the GitLab cards, should put me in a better spot for success in the next sprint.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.