Author Archives: tempurashrimple

Sprint 3 – All’s Well that ends Well

So here it is, the final Sprint. I have to admit, it was a lot more lax compared to the previous two sprints.

The main things we focused on this sprint was wrapping up to prepare for the end of the semester, and making sure our work is ready for future courses. For me, this was three things. One, merging my work to main. Two, write up documentation for the future courses. And lastly, making sure my part of the presentation was ready.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-category-based/frontend/-/commit/443acdb08e49f7bb1c722fc415eb4fd27251a95d

Here is my merge request for the documentation I made.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-category-based/frontend/-/commit/16defd74aa955d6283efeb86d38ddc74b9d19caf

And here is the merge request for my work onto main.

Looking back on older work on how to do merge requests was a fun challenge, having to sift through a bunch of older courses with Professor Wurst to remind myself. I learned through Alex that the repository already contained a bash file that squash all the commits I made into one singular commit. This was extremely helpful to keep track of the commits I made.

I ran into a bit of issues when first trying to push my changes, but I later found out it was due to my Visual Studio Code trying to push to my Github account rather than my GitLab account for some reason. Easy fix was to simply reset my login info stored within the editor.

I feel as though at the end of the day, our team worked very well. We could have definitely been a bit more communicative, as I felt there were a couple moments where I would try to communicate with them in Discord chat that I would be left on read, but otherwise we were relatively clear with helping each other and staying on track. I felt like my participation in the group was a bit more equal this time around, but still lacking in comparison. Marlon and I agree that my work was a lot more abstract compared to them, so it is very hard to equate my work to my teammates.

For this Sprint’s pattern, I chose “Expose Your Ignorance” from Chapter 2. Throughout this sprint, I found myself struggling to remember how to properly use Git. Much like the pattern suggests you do, I was able to confront my peers about the issues I was having and they were able to assist me in return. I feel like I could have used this skill a lot more as throughout my entire time in this course, I didn’t really ask for help. I felt like I had to be in charge of my own work and should learn things on my own. I should take the time in the future to break that habit down.

Overall, I am happy how this sprint went. I feel as though this was absolutely a strong one, but not as strong as Sprint 2. I simply feel this due to the fact there was less of a workload being pushed in comparison, which isn’t necessarily a bad thing! I feel like throughout this course I have learned a lot about working as a team and finding my place within one. I’m hopeful I am able to utilize these skills in the workforce, and be an effective employee for whoever hires me.

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Sprint 2 – Improving!

If there’s one thing I can say happily about this sprint, its that it went seriously better then the last one!

Lately, I’ve been focused on setting up a universal design for many of the applications that are being worked on throughout all of the groups in this class. Examples of which are show below, as well as a link to the specific GitLab issue they’re tied to.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/20

The first two shown are my initial generalized mock-ups, showing a generalized feel and theme while also showing off some elements like buttons and subtitles that would be commonplace. The last two are the two latest I’ve made, specifically for the user information group, implementing many of the design critiques that other groups and the professor have given me from the initial design.

For me, I found being able to work in an environment I’m comfortable with, that being visual design, helped a ton with my comfort and goal-setting within this sprint. I felt like I was put on-track compared to last sprint, and was able to do significant work. However, that being said, I felt like I was significantly independent and on my own for a majority of it. None of my team members were doing the same as I, and the work I was doing was specifically for the entirety of the class, not just them. So it felt like there was a bit of disconnect there, and could be fixed for next sprint.

I feel as though I did a lot better than I did last sprint, I was a lot more enthusiastic then before, but I do feel I could have communicated a bit better with my team about my new path in this sprint. I felt I left them behind a little bit, especially Jaylon, who was alone in the Frontend development. Next Sprint, I plan on improving on this by trying to split the visual design aspect of my work evenly with work for my team in specific. As for our team, I cannot really comment too much about what we could change as a group, as I feel they’ve been doing fine, I’m just the weakest link they have at the moment.

For a single pattern, I chose Your First Language as found in Chapter 2, which states that you only understand one or two programming languages, but not the ones particularly known for the job at hand. I chose this one as I felt like understanding a lot of the languages being used in our repositories are something I have minimal understanding in, and need to learn better to help my group as best I can. It suggests I toy around with new languages whenever I can, to best help and learn the ones needed. I feel as though this is something I would have already done, given my lack of time to do so, as I find myself having to juggle with work from this course with my others. However, that does not mean I’m willing to give it a shot going forwards.

All in all, I feel like this sprint was a success, and am looking forwards to the next one, which will be our last sprint. Here’s to improving where I can in that one as well!

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Sprint 1 – Lackluster

Hoo boy, where do I even begin with my experience for the Sprint…

If I am to be honest, I felt like I didn’t contribute anything to this current sprint. At every angle I either was either unable to receive a task to do, or when I was, I failed to meet said task or it was taken over by someone else.

Do not get me wrong, I don’t want to blame my teammates at all, in fact, I feel as though my teammates have been quite supportive. But at times, I felt like our communication and divvying of workloads could be a bit better. I also want to admit, because of my other courses, I have been scrounging for time for working on this one, so whenever I have had a task, I’m unable to put a solid dent into it.

If I had work to show, I would absolutely show it here. But in all honesty, most of what I’ve done has just been helping others whose work I am unsure of as to where it is on GitLab, or if it has even been pushed yet. I’m aware that you have been pushing us to use all the features it contained, but we have yet to do so. The one thing I can say I’ve done and show is setting up an issue board for me and Jaylon on the Frontend, which I have been the only one to utilize thus far: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-category-based/frontend/-/boards

The other few tasks I was given, were as follows, and the reasons I wasn’t/didn’t do them is also listed.

  • Create a Mock-up app for the scanner: Project was taken over completely by Jaylon.
  • Implement a camera view into the web app: Also taken over completely by Jaylon.
  • Download and inspect a MongoDB by OpenFoodFacts (https://world.openfoodfacts.org/files/api-documentation.html): Rendered useless by Marlon, who found something better as I was in the process of de-compiling the DB.
  • Creating a README, and verifying our licenses: Small tasks that I honestly have no excuse as for why I haven’t done them. I really should at some point, but I’ve bee so focused on more important homework with due dates.

That last part is absolutely a major reason I feel lost, not only just because there’s a lack of communication and task distribution, but the lack of due dates for things makes me have no sense of urgency nor motivation, which is hard to generate for someone such as me with ADHD. Its no excuse of course, but it is absolutely a factor at play.

If I were to choose a pattern in specific from Apprenticeship Patterns, I would likely choose “Find Mentors” from Chapter 4. It discusses going down avenues not knowing where to turn to or what to do, even though it is a path others are treading. I feel as though this is a perfect summary of my situation during this sprint, and is something I will keep in mind going forwards in the next. Perhaps I should work a bit more closely with my Professor, and see if he has knowledge to imbue or assistance to give. I have already seem to have found a niche for this next sprint, with the design of our web app, so hopefully that ends up going much more swell that this week did.

If I were to say something positive about my team, however, I feel like when we meet up and work together, we are very strong and capable. It’s clear to me that everyone cares not only about our project, but each other. I have felt bad every time I end up late or absent from courses, as I feel like I am unable to contribute to this positive work effort our team is pushing. Hopefully in the future I can improve and build upon this, and make our teamwork even stronger.

Here’s hoping that the next Sprint goes a lot better!

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – What I Learned

For my capstone course this semester, I was assigned to read and review a book from authors Dave Hoover and Adewale Oshineye, known as Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by our professor, Karl Wurst. The intention of reading this was to ready and prepare myself for the challenge within this course, specifically about my skills in a field and how to cultivate and grow within said field, or “craft” as the book puts it.

To me, the most interesting part about this reading is how they attributed software development to craftsmanship. When I first thought about it initially when it discusses it in the first chapter, I immediately went “yeah that makes sense” but upon reading further and it digging at specific concepts like “what is craft” and “what makes an apprentice an apprentice”, it made me think a lot more about what a “craft” really is. Being an art minor, this definition was one that was important to me, as art in it of itself is synonymous to craft. Being able to compare my work when coding things and my work when I physically create artwork was an interesting turn of events and an epiphany I wasn’t expecting when dropping into this book. The individual breakdowns of each part of what makes craftsmanship what it is was very impressive and made me able to stand in the shoes of the authors.

When reading, I also felt a bit called out on bad habits that I definitely do on a daily basis. For example, the story told in Chapter 2’s introduction, discussing a cup already full, it reminded me of how I tend to get carried away when it comes to discussing what I know and want to share. This comes at, unfortunately, a disregard for the new information I would be trying to learn, much like how the analogy of the story goes. Another thing I felt was important and reflected on my own actions was Chapter 5, discussing how it is important to not use the internet as your only source of learning and information. Initially, I was quick to disagree with this point, as I do NOT enjoy reading in the first place (a.e. look at how long it took me to write this up) but then I sat down and realized that was another bad habit kicking in, as well as my ADHD. While yes, its true that written works contain many important informations regarding to one’s craft, especially in software development, one must also remember that “reading” isn’t the only way to absorb this information, you could find an audio transcript, as an example. Thus did I realize that this point was actually one that was really strong and heavily agreed with.

Overall, I feel further reading may be necessary for me, as this has changed a lot about the way I am thinking not only about this class and working on a development team, but also about myself and habits that I could be working on and improving. If you also would like to read the book, it is hosted here, for free: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch06.html

Until next time! (Which is, soon, because Ill be writing up another post right after this, haha)

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 0 – Set Up Task 5

Been a hot second since I wrote here, but nonetheless, I’m happy to be back. This week I’ll be taking a look at the project I will be working on all this semester for CS-448, LibreFoodPantry and Thea’s Pantry.

Professor Wurst wanted us to take a look at each project, and find things we found interesting about each. Starting with LibreFoodPantry, I actually chose their Mission statement, because it gave me a lot more insight into this project then I initially had. I had assumed it was specifically a project Worcester State was doing for Thea’s Pantry, but no. It’s actually a project that spans across multiple college campuses, which I found to be very interesting. I am curious to see if this year we will be working with any other colleges also working for LibreFoodPantry.

As for Thea’s Pantry, I chose the Technology tab, because I was curious as to the technology we were using. In specific, I was surprised to find we were working with GitLab again this semester. I have known for awhile now that the industry standard for repositories in GitHub, so I’m interested to learn and know exactly why we are using GitLab over it. I also am happy to see we will be utilizing Docker and MongoDB from previous courses with Professor Wurst.

Overall, looking into these documentation, I am excited to be working on these projects for my Capstone. Here’s to another semester at Worcester State with Professor Wurst!

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 18B – C Testing

For this week, I wanted to look at how different languages handle test cases, and I’ll continue with one I’m not the most familiar with, C! I’ve worked in small amount of C in classes at Worcester State, but have little experience outside of that. I feel like this is a good topic to discuss as knowing how other programming languages handle unit testing would be a great way to expand my knowledge when it comes to furthering my understanding of it within Java.

If you haven’t already read my other blog post on Python testing, feel free to read it right here!

Week 18A – Python Testing

For learning about unit testing in C, I consulted this article on the subject: https://interrupt.memfault.com/blog/unit-testing-basics

It seems like unit testing in C is a lot more barebones compared to Java, which in my experience utilizing C, makes sense for the language. A lot of features primarily used in Java, like object-oriented structures aren’t available in C (to my understanding, could totally be wrong).

For one major aspect, there seems to be only one assertion command in C, just simply “assert”. Theres no assertTrue, assertFalse, assertThrows, or assertEquals, just simply “assert”. And from the example given below: 

#include <assert.h>

// In my_sum.c
int my_sum(int a, int b) {
  return a + b;
}

// In test_my_sum.c
int main(int argc, char *argv[]) {
  assert(2 == my_sum(1, 1));
  assert(-2 == my_sum(-1, -1));
  assert(0 == my_sum(0, 0));
  // ...
  return(0);
}

It seems the “assert” function comes from the <assert.h> library, much like the JUnit librarys used in Java. But more importantly, it seems that “assert” is the equivalent of “assertEquals”.

It also seems like Unit Testing in C is best implemented with tools outside of a compiler for C. The ones mentioned in the article in specific were CppUTest, Unity, and Google Test. For the rest of the article, the use examples using CppUTest. It was interesting to hear one of the options being called Unity, which is the name of a game engine, which, while not written in C, is written in a mixture of C# and C++, which are both offshoots of C. Makes me wonder how testing in a gaming engine works, perhaps it’s something to look at in a future blog post, hint hint, wink wink.

CppUTest seems to implement the same SetUp() and Teardown() functions that JUnit can employ, which is really good, as these methods are important for testing multiple methods. It also seems to have more then just an Equals assertion, even though the example used is another equals example.

This gets me more interested in C, as I have been told understanding C allows you to understand other languages much more clearly. Perhaps I’ll take a deeper dive some day, who knows! Until next time, my readers~!

From the blog CS@Worcester – You&#039;re Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 18A – Python Testing

For this week, I wanted to look at how different languages handle test cases, and I’ll begin with the one I’m the most familiar with, Python! I’ve worked with Python in small amounts in the past, and have an understanding a lot of it’s syntaxes are similar to java’s, albeit simpler. I feel like this is a good topic to discuss as knowing how other programming languages handle unit testing would be a great way to expand my knowledge when it comes to furthering my understanding of it within Java.

For this, I’ll be looking at the official page for unittest on Python’s website, here:

https://docs.python.org/3/library/unittest.html

Right off the bat, I’m really interested in the fact that unittest is actually based directly off of JUnit! Which means a lot of the syntax, formatting, and framework is quite similar, just modified to fit the mold of Python.

Looking at the snippet they gave as an example…

import unittest

class TestStringMethods(unittest.TestCase):

    def test_upper(self):
        self.assertEqual('foo'.upper(), 'FOO')

    def test_isupper(self):
        self.assertTrue('FOO'.isupper())
        self.assertFalse('Foo'.isupper())

    def test_split(self):
        s = 'hello world'
        self.assertEqual(s.split(), ['hello', 'world'])
        # check that s.split fails when the separator is not a string
        with self.assertRaises(TypeError):
            s.split(2)

if __name__ == '__main__':
    unittest.main()

In this, it seems the way you define test blocks is by having a class with (unittest.testcase) and then doing “def” to define each test case.

Even the assertions are the same and written near identically, as the first three use assertEqual, which is identical to javas assertEquals, minus the s, and assertTrue and assertFalse, which are also identical to their java counterparts. assertRaises, which is used in the third test, seems to be Python’s equivalent to assertThrows, however, it seems to be a bit different in comparison. assertRaises seems to identify a specific kind of exception being raised, whereas assertThrows would just identify any exception in general.

The last line also is a block of code that allows an easy way to run all the tests, so when you run unittest.main() in a command line, it will automatically run all the tests and display the results.

There also seems to be a whole bunch of different command line options to display results and modify the ways in which its run. As an example, theres “-v”, which stands for verbosity, much like the bash command, which shows the results of each individual test being run, like below:

test_isupper (__main__.TestStringMethods.test_isupper) ... ok
test_split (__main__.TestStringMethods.test_split) ... ok
test_upper (__main__.TestStringMethods.test_upper) ... ok

----------------------------------------------------------------------
Ran 3 tests in 0.001s

OK

It seems extremely interesting and makes me want to learn more Python, which would definitely help me in my career in all sorts of ways! Next blog we will be looking at how unit testing works in C. Until then!

From the blog CS@Worcester – You&#039;re Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 13 – Benchmarking

This week I had a bit of trouble thinking about what to write…until I lucky remembered what went on today. That being the Benchmark Trailer for Final Fantasy XIV: Dawntrail, a benchmarking tool that made sure your pc was up to specifications for the new expansion pack, but also tease some of the new gameplay, locations, animations and classes to come with it!

Which got me thinking…benchmarking is a great tool when it comes to testing not only hardware, but also software too! I think the two go hand in hand, “the two” being software and hardware, when it comes to testing. And then it hit me what I should write about: I should talk about what a benchmark is, and why it is important to testing!

For this, I consulted our favorite search engine, Google, and found this site!

https://testsigma.com/blog/benchmark-testing

So, what is a benchmark exactly? According to this site a benchmark “is a subset of performance testing that refers to a set of metrics or a reference point against which you can quality check your software or applications. The purpose of this testing is to compare the previous, present, and future updates of the application against a set reference.”

Now lets break that down a bit into digestible pieces…basically, every time you create a set of tests or even a set of functions for a program, you wanna make sure its always working, whether that be in general when its compiled, or on different device. Say you want to ship out a program to users on both Windows AND Mac. Youll want to create a benchmark environment where you can test and see how well the program functions on those.

There’s various ways you can do a benchmark, either by checking the programs functionality and tests on a Virtual Machine, testing it on hardware that differs from your own, or even running it on a frien’d computer as opposed to your own.

The reverse is true as well, as seen with the Final Fantasy Benchmark shown above. The test, while it sees if the functionality works on certain machines, it also lets you know if your machine/hardware is also unable to run the software. Sometimes your hardware might be so outdated that certain kinds of software are incompatible or unable to be run due to the older processing systems or runtime of the machine.

I am interested to see if we cover this at all in class, as it definitely seems like something that is a major part of testing when it comes to both hardware and software.

But thats all from me, until next week!

From the blog CS@Worcester – You&#039;re Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 12 – Comparing Tips

For this week, I wanted to look at what some websites consider helpful tips when it comes to testing software in Java and compare that to what we have learned in class. By looking at each tip one by one and comparing it to the things Professor Wurst has taught us during our lectures.

For this, I will be looking at this website: https://www.code-intelligence.com/blog/11-tips-unit-testing-java

Tip Number 1 is to “Compose Tests before Writing Code”, which is actually what we have been focusing upon for the last few weeks, so it’s good to see that this is being reaffirmed

Number 2: Keep tests small and concentrated. This is another subject that we’ve been looking at as well, as we’ve been looking at strategies on how to concatenate code for test.

Number 3: Defining your Code Coverage. This isn’t actually something I believe we’ve spoken about in this class, however, we have discussed similar things in my previous classes with Process Management.

Number 4: Isolating Tests from External Sources. This one Im not sure if we have discussed it, but it also seems like a given, considering we have been taught to always only use tests in test classes and to pull from testing packages when importing.

Number 5: Automate wherever possible. I don’t actually think we’ve done this yet in Testing, however, this is something we have discussed previously in another class, I believe in Software Design. If you can automate something, always try to.

Number 6: Creating Mock Dependencies. This isn’t something in specific we’ve touched upon yet I feel, however it makes sense. I feel as though when I did our first homework, I kind of did something similar to this.

Number 7: Use Assertions. Yes. Absolutely we have done this in class. All if not most classes we have written use assert.equals(), assert.true(), or assert.false(), amongst others.

Number 8: Using proper names to test methods. This is something we learned way back in CS101. Always name your methods something understandable for you and your team to instantly know what it does. Never write gobbledygook names for methods, be concise.

Number 9: Keep Unit Tests Up to Date. I don’t believe this has been taught yet as most code we have worked with has been static and unchanging. However, Im sure we will have assignments where we focus on this harder. It definitely seems like something that is extremely important, as code changes so too should the tests, or else they wont work properly or even give false positives.

Number 10: Don’t Focus on Implementation. This one is interesting to me. We haven’t really spoken about implementation of code when it comes to testing. It’s very interesting to me because I have never really thought about this before, but it definitely makes a lot of sense to me. Something good to keep in mind for the future.

And lastly number 11: Create independent test cases. I actually unfortunately learned this myself the hard way with the first homework, as each class was accidentally dependent of one another if ran back to back. It’s something I definitely need to keep in mind going forwards.

And thats it! It’s definitely a lot of overlap which is great to see. Until next week!

From the blog CS@Worcester – You&#039;re Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

Week 9 – Better late than never.

Jesus, yeah I’ve kinda been slacking on my blog writings huh? So sorry for the radio silence coming from this place. Going forwards I can hopefully write every week moving forwards.

Anyways, for my first time writing for this class with Professor Wurst, being Software Quality and Testing, I wanted to talk specifically more in depth about what I had already sent him earlier this semester in our course’s Discord server, that being a video by Matt McMuscles about Sonic The Hedgehog (2006)

I have personal experience with this game, as I specifically remember going to BlockBuster when it was still around, wanting to get the game LittleBigPlanet, and my father reaching into the the bargain bin to find Sonic 06, as its better known to fans (quite the mouthful the real title is, and better to differentiate it from the original game on Sega Genesis), and handing it to me. Unfortunately, I had left the store only with Sonic 06.

The reason I relate this to Software Quality and Testing, is because this game is a heavy example of what happens when you rush it, as the video shows. This game was rushed out to shelves for the Christmas of 2006, so SEGA could make a good profit off of it, benefitting off of the increased demand that comes with Christmas.

Many things in this game show that it was improperly tested, with bugs, glitches, and even crashes all about the game. The game is held back due to this, as there is a proper and interesting idea underneath the surface. However, the lack of finding these extremely prevalent bugs and glitches lead to this being one of the worst selling titles in the Sonic franchise.

This goes to show why testing and quality assurance is so important, even in the gaming field. Video Games are software after all, just specifically for entertainment and enjoyment.

I specifically wanted to cover this for this class because it shows me why making sure the testing is as fluid as the programming to create a perfect product. This is especially true in the gaming field, which I hope to have a future in.

Needless to say, I don’t own my own copy anymore. I snapped my PlayStation 3 disc a long time ago. And months after I got it, I did end up getting LittleBigPlanet, and played it way more than this travesty.

tl;dr dont get the game in bargain bin.

From the blog CS@Worcester – You&#039;re Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.