Author Archives: Camille

Sprint #3 Retrospective

 Hello

I cannot believe how quickly this year has come to a close. It seems like just yesterday I was struggling comprehending what I was doing in this course, but now I have gotten to the point where I feel like I have a grasp on how things are actually going. In terms of what got done, I implemented Rabbit at long last, and it only took me 3 sprints to get here! Along with that I made sure the messages we were sending matched the specifications posted on discord, and I made sure that the messages were only being sent if the requests themselves were valid (i.e. weight isn’t null, and it won’t take more than the inventory has). I think I really came into my own near the end of my time in this class,  I did a good job speaking to my group more often, I put out a number of good commits, and overall I had a better grasp on what was actually going on, which I certainly couldn’t say at the start. Though if I had to pinpoint something that didn’t work very well, I definitely think it was my communication with my group about what all of my work actually does. I get consistently asked what certain ports are being used for, and near the end of the sprint we ran into a snag relating to a library I was using. If I had explained what everything was more thoroughly, it could have prevented some headaches in my opinion. Our team continues to work quite well together, we communicate pretty openly at meetings, and I am not afraid to ask questions like I was before. I think near the end of the sprint we kind of lost focus a bit, and we, myself included, started slacking off on things once the majority of the sprint’s work had been done. We might have been able to come up with some other issues than the ones we have posted on Gitlab, but perhaps we wouldn’t have, who can really say for sure, our stuff is basically already done from my understanding. As for me, I am trying not to slack on any of the work required for this class in the last weeks of the semester. While the last presentation is a good week or so away, I am trying to make myself as available as possible, and I am trying to keep on top of everything so that the presentation isn’t rushed. 

For the design pattern I’ve chosen for this post, I went with something that I feel really encapsulates all of the work I’ve done over the course of the semester, and that is Sustainable Motivations. The pattern states that a software craftsman should hone their skills to cope with ever changing specifications and demands from customers. It recommends trying to remain motivated by writing things down that motivate you about your work, and trying to keep in mind that not every day programming will be perfect. Throughout the course of the semester I have had a kind of moving target problem with the scope of my work. At the beginning, the issue I was assigned requested I use RabbitMQ to send messages on inventory actions, but it did not mention the fact that RabbitMQ wasn’t implemented in the Inventory Backend at all. So suddenly, the scope of my work had changed dramatically, and I spent most of the first sprint stressing that I wasn’t doing as much as I should while I got RabbitMQ running. Later on, things like queue creation and library conflicts became a problem, and it seemed like the further I got in, the farther away completion of my goal was. I think if I had read this pattern at the start of the semester, or even at the start of sprint 3, I would have taken some time to actualize that I was never going to have a static goal with this kind of work, and perhaps I would have cut myself a little slack in that regard. 

Overall I’ve enjoyed this class quite a bit, and my time in college in general, since I am graduating. I’ve learned a lot from this course, and gained a lot of experience that I will doubtlessly use in industry. So, all that remains now is for me to coast through the finish line, and see where my career takes me from there.

Thanks for reading my blog! Who knows when or if I’ll post again, but it’s been interesting writing about all the work I’ve been doing for classes in a public facing way. I might even try this whole thing again sometime, who knows! :p

 

Merge Requests:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/69

 https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/68

 https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/66

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint #3 Retrospective

 Hello

I cannot believe how quickly this year has come to a close. It seems like just yesterday I was struggling comprehending what I was doing in this course, but now I have gotten to the point where I feel like I have a grasp on how things are actually going. In terms of what got done, I implemented Rabbit at long last, and it only took me 3 sprints to get here! Along with that I made sure the messages we were sending matched the specifications posted on discord, and I made sure that the messages were only being sent if the requests themselves were valid (i.e. weight isn’t null, and it won’t take more than the inventory has). I think I really came into my own near the end of my time in this class,  I did a good job speaking to my group more often, I put out a number of good commits, and overall I had a better grasp on what was actually going on, which I certainly couldn’t say at the start. Though if I had to pinpoint something that didn’t work very well, I definitely think it was my communication with my group about what all of my work actually does. I get consistently asked what certain ports are being used for, and near the end of the sprint we ran into a snag relating to a library I was using. If I had explained what everything was more thoroughly, it could have prevented some headaches in my opinion. Our team continues to work quite well together, we communicate pretty openly at meetings, and I am not afraid to ask questions like I was before. I think near the end of the sprint we kind of lost focus a bit, and we, myself included, started slacking off on things once the majority of the sprint’s work had been done. We might have been able to come up with some other issues than the ones we have posted on Gitlab, but perhaps we wouldn’t have, who can really say for sure, our stuff is basically already done from my understanding. As for me, I am trying not to slack on any of the work required for this class in the last weeks of the semester. While the last presentation is a good week or so away, I am trying to make myself as available as possible, and I am trying to keep on top of everything so that the presentation isn’t rushed. 

For the design pattern I’ve chosen for this post, I went with something that I feel really encapsulates all of the work I’ve done over the course of the semester, and that is Sustainable Motivations. The pattern states that a software craftsman should hone their skills to cope with ever changing specifications and demands from customers. It recommends trying to remain motivated by writing things down that motivate you about your work, and trying to keep in mind that not every day programming will be perfect. Throughout the course of the semester I have had a kind of moving target problem with the scope of my work. At the beginning, the issue I was assigned requested I use RabbitMQ to send messages on inventory actions, but it did not mention the fact that RabbitMQ wasn’t implemented in the Inventory Backend at all. So suddenly, the scope of my work had changed dramatically, and I spent most of the first sprint stressing that I wasn’t doing as much as I should while I got RabbitMQ running. Later on, things like queue creation and library conflicts became a problem, and it seemed like the further I got in, the farther away completion of my goal was. I think if I had read this pattern at the start of the semester, or even at the start of sprint 3, I would have taken some time to actualize that I was never going to have a static goal with this kind of work, and perhaps I would have cut myself a little slack in that regard. 

Overall I’ve enjoyed this class quite a bit, and my time in college in general, since I am graduating. I’ve learned a lot from this course, and gained a lot of experience that I will doubtlessly use in industry. So, all that remains now is for me to coast through the finish line, and see where my career takes me from there.

Thanks for reading my blog! Who knows when or if I’ll post again, but it’s been interesting writing about all the work I’ve been doing for classes in a public facing way. I might even try this whole thing again sometime, who knows! :p

 

Merge Requests:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/69

 https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/68

 https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/66

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint #3 Retrospective

 Hello

I cannot believe how quickly this year has come to a close. It seems like just yesterday I was struggling comprehending what I was doing in this course, but now I have gotten to the point where I feel like I have a grasp on how things are actually going. In terms of what got done, I implemented Rabbit at long last, and it only took me 3 sprints to get here! Along with that I made sure the messages we were sending matched the specifications posted on discord, and I made sure that the messages were only being sent if the requests themselves were valid (i.e. weight isn’t null, and it won’t take more than the inventory has). I think I really came into my own near the end of my time in this class,  I did a good job speaking to my group more often, I put out a number of good commits, and overall I had a better grasp on what was actually going on, which I certainly couldn’t say at the start. Though if I had to pinpoint something that didn’t work very well, I definitely think it was my communication with my group about what all of my work actually does. I get consistently asked what certain ports are being used for, and near the end of the sprint we ran into a snag relating to a library I was using. If I had explained what everything was more thoroughly, it could have prevented some headaches in my opinion. Our team continues to work quite well together, we communicate pretty openly at meetings, and I am not afraid to ask questions like I was before. I think near the end of the sprint we kind of lost focus a bit, and we, myself included, started slacking off on things once the majority of the sprint’s work had been done. We might have been able to come up with some other issues than the ones we have posted on Gitlab, but perhaps we wouldn’t have, who can really say for sure, our stuff is basically already done from my understanding. As for me, I am trying not to slack on any of the work required for this class in the last weeks of the semester. While the last presentation is a good week or so away, I am trying to make myself as available as possible, and I am trying to keep on top of everything so that the presentation isn’t rushed. 

For the design pattern I’ve chosen for this post, I went with something that I feel really encapsulates all of the work I’ve done over the course of the semester, and that is Sustainable Motivations. The pattern states that a software craftsman should hone their skills to cope with ever changing specifications and demands from customers. It recommends trying to remain motivated by writing things down that motivate you about your work, and trying to keep in mind that not every day programming will be perfect. Throughout the course of the semester I have had a kind of moving target problem with the scope of my work. At the beginning, the issue I was assigned requested I use RabbitMQ to send messages on inventory actions, but it did not mention the fact that RabbitMQ wasn’t implemented in the Inventory Backend at all. So suddenly, the scope of my work had changed dramatically, and I spent most of the first sprint stressing that I wasn’t doing as much as I should while I got RabbitMQ running. Later on, things like queue creation and library conflicts became a problem, and it seemed like the further I got in, the farther away completion of my goal was. I think if I had read this pattern at the start of the semester, or even at the start of sprint 3, I would have taken some time to actualize that I was never going to have a static goal with this kind of work, and perhaps I would have cut myself a little slack in that regard. 

Overall I’ve enjoyed this class quite a bit, and my time in college in general, since I am graduating. I’ve learned a lot from this course, and gained a lot of experience that I will doubtlessly use in industry. So, all that remains now is for me to coast through the finish line, and see where my career takes me from there.

Thanks for reading my blog! Who knows when or if I’ll post again, but it’s been interesting writing about all the work I’ve been doing for classes in a public facing way. I might even try this whole thing again sometime, who knows! :p

 

Merge Requests:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/69

 https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/68

 https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/66

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint #3 Retrospective

 Hello

I cannot believe how quickly this year has come to a close. It seems like just yesterday I was struggling comprehending what I was doing in this course, but now I have gotten to the point where I feel like I have a grasp on how things are actually going. In terms of what got done, I implemented Rabbit at long last, and it only took me 3 sprints to get here! Along with that I made sure the messages we were sending matched the specifications posted on discord, and I made sure that the messages were only being sent if the requests themselves were valid (i.e. weight isn’t null, and it won’t take more than the inventory has). I think I really came into my own near the end of my time in this class,  I did a good job speaking to my group more often, I put out a number of good commits, and overall I had a better grasp on what was actually going on, which I certainly couldn’t say at the start. Though if I had to pinpoint something that didn’t work very well, I definitely think it was my communication with my group about what all of my work actually does. I get consistently asked what certain ports are being used for, and near the end of the sprint we ran into a snag relating to a library I was using. If I had explained what everything was more thoroughly, it could have prevented some headaches in my opinion. Our team continues to work quite well together, we communicate pretty openly at meetings, and I am not afraid to ask questions like I was before. I think near the end of the sprint we kind of lost focus a bit, and we, myself included, started slacking off on things once the majority of the sprint’s work had been done. We might have been able to come up with some other issues than the ones we have posted on Gitlab, but perhaps we wouldn’t have, who can really say for sure, our stuff is basically already done from my understanding. As for me, I am trying not to slack on any of the work required for this class in the last weeks of the semester. While the last presentation is a good week or so away, I am trying to make myself as available as possible, and I am trying to keep on top of everything so that the presentation isn’t rushed. 

For the design pattern I’ve chosen for this post, I went with something that I feel really encapsulates all of the work I’ve done over the course of the semester, and that is Sustainable Motivations. The pattern states that a software craftsman should hone their skills to cope with ever changing specifications and demands from customers. It recommends trying to remain motivated by writing things down that motivate you about your work, and trying to keep in mind that not every day programming will be perfect. Throughout the course of the semester I have had a kind of moving target problem with the scope of my work. At the beginning, the issue I was assigned requested I use RabbitMQ to send messages on inventory actions, but it did not mention the fact that RabbitMQ wasn’t implemented in the Inventory Backend at all. So suddenly, the scope of my work had changed dramatically, and I spent most of the first sprint stressing that I wasn’t doing as much as I should while I got RabbitMQ running. Later on, things like queue creation and library conflicts became a problem, and it seemed like the further I got in, the farther away completion of my goal was. I think if I had read this pattern at the start of the semester, or even at the start of sprint 3, I would have taken some time to actualize that I was never going to have a static goal with this kind of work, and perhaps I would have cut myself a little slack in that regard. 

Overall I’ve enjoyed this class quite a bit, and my time in college in general, since I am graduating. I’ve learned a lot from this course, and gained a lot of experience that I will doubtlessly use in industry. So, all that remains now is for me to coast through the finish line, and see where my career takes me from there.

Thanks for reading my blog! Who knows when or if I’ll post again, but it’s been interesting writing about all the work I’ve been doing for classes in a public facing way. I might even try this whole thing again sometime, who knows! :p

 

Merge Requests:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/69

 https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/68

 https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/66

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint #3 Retrospective

 Hello

I cannot believe how quickly this year has come to a close. It seems like just yesterday I was struggling comprehending what I was doing in this course, but now I have gotten to the point where I feel like I have a grasp on how things are actually going. In terms of what got done, I implemented Rabbit at long last, and it only took me 3 sprints to get here! Along with that I made sure the messages we were sending matched the specifications posted on discord, and I made sure that the messages were only being sent if the requests themselves were valid (i.e. weight isn’t null, and it won’t take more than the inventory has). I think I really came into my own near the end of my time in this class,  I did a good job speaking to my group more often, I put out a number of good commits, and overall I had a better grasp on what was actually going on, which I certainly couldn’t say at the start. Though if I had to pinpoint something that didn’t work very well, I definitely think it was my communication with my group about what all of my work actually does. I get consistently asked what certain ports are being used for, and near the end of the sprint we ran into a snag relating to a library I was using. If I had explained what everything was more thoroughly, it could have prevented some headaches in my opinion. Our team continues to work quite well together, we communicate pretty openly at meetings, and I am not afraid to ask questions like I was before. I think near the end of the sprint we kind of lost focus a bit, and we, myself included, started slacking off on things once the majority of the sprint’s work had been done. We might have been able to come up with some other issues than the ones we have posted on Gitlab, but perhaps we wouldn’t have, who can really say for sure, our stuff is basically already done from my understanding. As for me, I am trying not to slack on any of the work required for this class in the last weeks of the semester. While the last presentation is a good week or so away, I am trying to make myself as available as possible, and I am trying to keep on top of everything so that the presentation isn’t rushed. 

For the design pattern I’ve chosen for this post, I went with something that I feel really encapsulates all of the work I’ve done over the course of the semester, and that is Sustainable Motivations. The pattern states that a software craftsman should hone their skills to cope with ever changing specifications and demands from customers. It recommends trying to remain motivated by writing things down that motivate you about your work, and trying to keep in mind that not every day programming will be perfect. Throughout the course of the semester I have had a kind of moving target problem with the scope of my work. At the beginning, the issue I was assigned requested I use RabbitMQ to send messages on inventory actions, but it did not mention the fact that RabbitMQ wasn’t implemented in the Inventory Backend at all. So suddenly, the scope of my work had changed dramatically, and I spent most of the first sprint stressing that I wasn’t doing as much as I should while I got RabbitMQ running. Later on, things like queue creation and library conflicts became a problem, and it seemed like the further I got in, the farther away completion of my goal was. I think if I had read this pattern at the start of the semester, or even at the start of sprint 3, I would have taken some time to actualize that I was never going to have a static goal with this kind of work, and perhaps I would have cut myself a little slack in that regard. 

Overall I’ve enjoyed this class quite a bit, and my time in college in general, since I am graduating. I’ve learned a lot from this course, and gained a lot of experience that I will doubtlessly use in industry. So, all that remains now is for me to coast through the finish line, and see where my career takes me from there.

Thanks for reading my blog! Who knows when or if I’ll post again, but it’s been interesting writing about all the work I’ve been doing for classes in a public facing way. I might even try this whole thing again sometime, who knows! :p

 

Merge Requests:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/69

 https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/68

 https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/66

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint #3 Retrospective

 Hello

I cannot believe how quickly this year has come to a close. It seems like just yesterday I was struggling comprehending what I was doing in this course, but now I have gotten to the point where I feel like I have a grasp on how things are actually going. In terms of what got done, I implemented Rabbit at long last, and it only took me 3 sprints to get here! Along with that I made sure the messages we were sending matched the specifications posted on discord, and I made sure that the messages were only being sent if the requests themselves were valid (i.e. weight isn’t null, and it won’t take more than the inventory has). I think I really came into my own near the end of my time in this class,  I did a good job speaking to my group more often, I put out a number of good commits, and overall I had a better grasp on what was actually going on, which I certainly couldn’t say at the start. Though if I had to pinpoint something that didn’t work very well, I definitely think it was my communication with my group about what all of my work actually does. I get consistently asked what certain ports are being used for, and near the end of the sprint we ran into a snag relating to a library I was using. If I had explained what everything was more thoroughly, it could have prevented some headaches in my opinion. Our team continues to work quite well together, we communicate pretty openly at meetings, and I am not afraid to ask questions like I was before. I think near the end of the sprint we kind of lost focus a bit, and we, myself included, started slacking off on things once the majority of the sprint’s work had been done. We might have been able to come up with some other issues than the ones we have posted on Gitlab, but perhaps we wouldn’t have, who can really say for sure, our stuff is basically already done from my understanding. As for me, I am trying not to slack on any of the work required for this class in the last weeks of the semester. While the last presentation is a good week or so away, I am trying to make myself as available as possible, and I am trying to keep on top of everything so that the presentation isn’t rushed. 

For the design pattern I’ve chosen for this post, I went with something that I feel really encapsulates all of the work I’ve done over the course of the semester, and that is Sustainable Motivations. The pattern states that a software craftsman should hone their skills to cope with ever changing specifications and demands from customers. It recommends trying to remain motivated by writing things down that motivate you about your work, and trying to keep in mind that not every day programming will be perfect. Throughout the course of the semester I have had a kind of moving target problem with the scope of my work. At the beginning, the issue I was assigned requested I use RabbitMQ to send messages on inventory actions, but it did not mention the fact that RabbitMQ wasn’t implemented in the Inventory Backend at all. So suddenly, the scope of my work had changed dramatically, and I spent most of the first sprint stressing that I wasn’t doing as much as I should while I got RabbitMQ running. Later on, things like queue creation and library conflicts became a problem, and it seemed like the further I got in, the farther away completion of my goal was. I think if I had read this pattern at the start of the semester, or even at the start of sprint 3, I would have taken some time to actualize that I was never going to have a static goal with this kind of work, and perhaps I would have cut myself a little slack in that regard. 

Overall I’ve enjoyed this class quite a bit, and my time in college in general, since I am graduating. I’ve learned a lot from this course, and gained a lot of experience that I will doubtlessly use in industry. So, all that remains now is for me to coast through the finish line, and see where my career takes me from there.

Thanks for reading my blog! Who knows when or if I’ll post again, but it’s been interesting writing about all the work I’ve been doing for classes in a public facing way. I might even try this whole thing again sometime, who knows! :p

 

Merge Requests:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/69

 https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/68

 https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/66

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Sprint #3 Retrospective

 Hello

I cannot believe how quickly this year has come to a close. It seems like just yesterday I was struggling comprehending what I was doing in this course, but now I have gotten to the point where I feel like I have a grasp on how things are actually going. In terms of what got done, I implemented Rabbit at long last, and it only took me 3 sprints to get here! Along with that I made sure the messages we were sending matched the specifications posted on discord, and I made sure that the messages were only being sent if the requests themselves were valid (i.e. weight isn’t null, and it won’t take more than the inventory has). I think I really came into my own near the end of my time in this class,  I did a good job speaking to my group more often, I put out a number of good commits, and overall I had a better grasp on what was actually going on, which I certainly couldn’t say at the start. Though if I had to pinpoint something that didn’t work very well, I definitely think it was my communication with my group about what all of my work actually does. I get consistently asked what certain ports are being used for, and near the end of the sprint we ran into a snag relating to a library I was using. If I had explained what everything was more thoroughly, it could have prevented some headaches in my opinion. Our team continues to work quite well together, we communicate pretty openly at meetings, and I am not afraid to ask questions like I was before. I think near the end of the sprint we kind of lost focus a bit, and we, myself included, started slacking off on things once the majority of the sprint’s work had been done. We might have been able to come up with some other issues than the ones we have posted on Gitlab, but perhaps we wouldn’t have, who can really say for sure, our stuff is basically already done from my understanding. As for me, I am trying not to slack on any of the work required for this class in the last weeks of the semester. While the last presentation is a good week or so away, I am trying to make myself as available as possible, and I am trying to keep on top of everything so that the presentation isn’t rushed. 

For the design pattern I’ve chosen for this post, I went with something that I feel really encapsulates all of the work I’ve done over the course of the semester, and that is Sustainable Motivations. The pattern states that a software craftsman should hone their skills to cope with ever changing specifications and demands from customers. It recommends trying to remain motivated by writing things down that motivate you about your work, and trying to keep in mind that not every day programming will be perfect. Throughout the course of the semester I have had a kind of moving target problem with the scope of my work. At the beginning, the issue I was assigned requested I use RabbitMQ to send messages on inventory actions, but it did not mention the fact that RabbitMQ wasn’t implemented in the Inventory Backend at all. So suddenly, the scope of my work had changed dramatically, and I spent most of the first sprint stressing that I wasn’t doing as much as I should while I got RabbitMQ running. Later on, things like queue creation and library conflicts became a problem, and it seemed like the further I got in, the farther away completion of my goal was. I think if I had read this pattern at the start of the semester, or even at the start of sprint 3, I would have taken some time to actualize that I was never going to have a static goal with this kind of work, and perhaps I would have cut myself a little slack in that regard. 

Overall I’ve enjoyed this class quite a bit, and my time in college in general, since I am graduating. I’ve learned a lot from this course, and gained a lot of experience that I will doubtlessly use in industry. So, all that remains now is for me to coast through the finish line, and see where my career takes me from there.

Thanks for reading my blog! Who knows when or if I’ll post again, but it’s been interesting writing about all the work I’ve been doing for classes in a public facing way. I might even try this whole thing again sometime, who knows! :p

 

Merge Requests:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/69

 https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/68

 https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-weight-based/inventorybackend/-/merge_requests/66

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

JUnit Blues

Hello!

 

With the semester wrapping up pretty quickly, and our last homework assignment being to design an in-class assignment, I’ve been doing some brushing up on JUnit testing. Specifically, assertions, which are the crux of how JUnit tests work, by telling a given test what qualifies as a pass or fail. The assignment me and my groupmates designed revolved around the use of various different kinds of assertions, ones that we didn’t cover heavily in class. 

 As such, this week my blog of choice to read revolves around, what else, JUnit testing. Specifically, the article comes from Medium, who I’ve looked at before, and who seem to be quite the useful resource on covering both broad and specific computer science topics. I wanted to take a look at this specific article, mostly because I wanted to see some of the other topics involved with JUnit that we didn’t cover in class. I intend on running Linux on my main PC once the semester ends, and seeing how to install JUnit on specific hardware instead of importing it as a library is pretty interesting! I am very used to just pulling a library from the top of a piece of code, I am not very well versed in actually installing libraries. Granted, this is the kind of thing that Docker and VS Code are made to circumvent, as you can set it to auto install or include certain dependencies. I also enjoyed reading some of the specific recommendations for writing JUnit specific tests. Some of them we kind of touched on in class already, but it is always nice to keep myself fresh on these kinds of things. Keep tests simple and focused, avoid possible edge cases, the list goes on. Something we didn’t touch on at all in class is the various debugging modes found in JUnit, like JDWP and Standard Streams, which can be useful in troubleshooting a program. Standard Streams for instance places every print that would normally go to the main console, but redirects it to the output strea, which can be useful for seeing exactly what is going on with a program. This kind of angle to me is interesting, as I strongly associate testing with debugging, but we didn’t necessarily cover debugging very thoroughly in class, so perhaps that is something I can look up on my own time. 

 I’ve thoroughly enjoyed my time in this class, some things were a little dry like the Boundary testing near the beginning of the semester, but a lot of the things we learned, like JUnit testing or unit testing in general I can see myself using regularly in industry, and I don’t think I am wrong in thinking that. 

Thank you for reading my blog!

Camille

 

Blog Post: https://medium.com/@abhaykhs/junit-a-complete-guide-83470e717dce

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

JUnit Blues

Hello!

 

With the semester wrapping up pretty quickly, and our last homework assignment being to design an in-class assignment, I’ve been doing some brushing up on JUnit testing. Specifically, assertions, which are the crux of how JUnit tests work, by telling a given test what qualifies as a pass or fail. The assignment me and my groupmates designed revolved around the use of various different kinds of assertions, ones that we didn’t cover heavily in class. 

 As such, this week my blog of choice to read revolves around, what else, JUnit testing. Specifically, the article comes from Medium, who I’ve looked at before, and who seem to be quite the useful resource on covering both broad and specific computer science topics. I wanted to take a look at this specific article, mostly because I wanted to see some of the other topics involved with JUnit that we didn’t cover in class. I intend on running Linux on my main PC once the semester ends, and seeing how to install JUnit on specific hardware instead of importing it as a library is pretty interesting! I am very used to just pulling a library from the top of a piece of code, I am not very well versed in actually installing libraries. Granted, this is the kind of thing that Docker and VS Code are made to circumvent, as you can set it to auto install or include certain dependencies. I also enjoyed reading some of the specific recommendations for writing JUnit specific tests. Some of them we kind of touched on in class already, but it is always nice to keep myself fresh on these kinds of things. Keep tests simple and focused, avoid possible edge cases, the list goes on. Something we didn’t touch on at all in class is the various debugging modes found in JUnit, like JDWP and Standard Streams, which can be useful in troubleshooting a program. Standard Streams for instance places every print that would normally go to the main console, but redirects it to the output strea, which can be useful for seeing exactly what is going on with a program. This kind of angle to me is interesting, as I strongly associate testing with debugging, but we didn’t necessarily cover debugging very thoroughly in class, so perhaps that is something I can look up on my own time. 

 I’ve thoroughly enjoyed my time in this class, some things were a little dry like the Boundary testing near the beginning of the semester, but a lot of the things we learned, like JUnit testing or unit testing in general I can see myself using regularly in industry, and I don’t think I am wrong in thinking that. 

Thank you for reading my blog!

Camille

 

Blog Post: https://medium.com/@abhaykhs/junit-a-complete-guide-83470e717dce

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

JUnit Blues

Hello!

 

With the semester wrapping up pretty quickly, and our last homework assignment being to design an in-class assignment, I’ve been doing some brushing up on JUnit testing. Specifically, assertions, which are the crux of how JUnit tests work, by telling a given test what qualifies as a pass or fail. The assignment me and my groupmates designed revolved around the use of various different kinds of assertions, ones that we didn’t cover heavily in class. 

 As such, this week my blog of choice to read revolves around, what else, JUnit testing. Specifically, the article comes from Medium, who I’ve looked at before, and who seem to be quite the useful resource on covering both broad and specific computer science topics. I wanted to take a look at this specific article, mostly because I wanted to see some of the other topics involved with JUnit that we didn’t cover in class. I intend on running Linux on my main PC once the semester ends, and seeing how to install JUnit on specific hardware instead of importing it as a library is pretty interesting! I am very used to just pulling a library from the top of a piece of code, I am not very well versed in actually installing libraries. Granted, this is the kind of thing that Docker and VS Code are made to circumvent, as you can set it to auto install or include certain dependencies. I also enjoyed reading some of the specific recommendations for writing JUnit specific tests. Some of them we kind of touched on in class already, but it is always nice to keep myself fresh on these kinds of things. Keep tests simple and focused, avoid possible edge cases, the list goes on. Something we didn’t touch on at all in class is the various debugging modes found in JUnit, like JDWP and Standard Streams, which can be useful in troubleshooting a program. Standard Streams for instance places every print that would normally go to the main console, but redirects it to the output strea, which can be useful for seeing exactly what is going on with a program. This kind of angle to me is interesting, as I strongly associate testing with debugging, but we didn’t necessarily cover debugging very thoroughly in class, so perhaps that is something I can look up on my own time. 

 I’ve thoroughly enjoyed my time in this class, some things were a little dry like the Boundary testing near the beginning of the semester, but a lot of the things we learned, like JUnit testing or unit testing in general I can see myself using regularly in industry, and I don’t think I am wrong in thinking that. 

Thank you for reading my blog!

Camille

 

Blog Post: https://medium.com/@abhaykhs/junit-a-complete-guide-83470e717dce

 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.