Author Archives: Camille

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.

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.

Sprint #2 Retrospective

Hello!

It’s that time of the month again, we’ve just finished up sprint number 2, and now I’ve got to write about how it went! 

I think this sprint was considerably more productive than the last one (even if I still couldn’t get my assigned issue done). I managed to parse out how I am going to make timestamps for the rabbitMQ messages, and I did a significant amount of testing with some files, to the point where I basically had everything working by the end of sprint 2. It would have been implemented were it not for the fact that I ran into some last minute errors that I couldn’t get fixed in time. Like the last post I made, the merge request will be available at the bottom of the post.

I think I did a much better job at communicating with my group this time around. I think I was a little shy before, plus overwhelmed at having to learn a new skill and be a productive member of a group. Now though, I’ve been pretty consistently talking to my group about what I’m working on, and I’ve been asking questions on things that trip me up, which I would consider a wild improvement over last time.

 In terms of things that didn’t go so well, I could do with some better time management skills. If I had planned out my work a bit better, I probably would have had ample time to fix the errors I was getting, and I might even have been able to implement everything I had been working on. I’m not going to fret about that though, I just have to keep that in mind and make sure I give this sprint all the time it needs from me to get everything done. 

As with myself, our group has been doing a lot more communicating lately. Most of it has been really good, but a good chunk of it has not been very on topic. I’m not about to be some kind of narc that wants every minute of every day be spent working, that sounds utterly miserable, but I would like more of our discussions being related to what we are working on.

After looking in the book, I think the apprenticeship pattern that relates the most to this sprint was “Expose Your Ignorance”. The pattern states that the best way to fill gaps in my knowledge is to reveal them to my group, so that I might be more encouraged to find what I am missing. I’ve been the one working on rabbitMQ for two sprints now, and as such, I think it is easy to assume that I know every aspect of what it going on, but the longer I work on this project, the more small problems seem to come out of the woodwork. Oh sure, we have the code needed to send messages, but there is no queue for them to go into, so what is the point, etc. So, had I read this pattern at the start of the sprint, I think it would have been more productive to know what kind of stuff I was missing, so I can avoid any unexpected problems. I would have laid out the plan for the sprint, done some research on everything I was doing if I wasn’t 100% solid on it, and had some better fundamental knowledge going into that sprint than what I had. 

As usual, I will try to keep the things I learned in mind, but I will continue working on my issue, knowing that I do not have all the knowledge I need, and being willing to ask for help in finding it.

 

 

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

 

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

Sprint #2 Retrospective

Hello!

It’s that time of the month again, we’ve just finished up sprint number 2, and now I’ve got to write about how it went! 

I think this sprint was considerably more productive than the last one (even if I still couldn’t get my assigned issue done). I managed to parse out how I am going to make timestamps for the rabbitMQ messages, and I did a significant amount of testing with some files, to the point where I basically had everything working by the end of sprint 2. It would have been implemented were it not for the fact that I ran into some last minute errors that I couldn’t get fixed in time. Like the last post I made, the merge request will be available at the bottom of the post.

I think I did a much better job at communicating with my group this time around. I think I was a little shy before, plus overwhelmed at having to learn a new skill and be a productive member of a group. Now though, I’ve been pretty consistently talking to my group about what I’m working on, and I’ve been asking questions on things that trip me up, which I would consider a wild improvement over last time.

 In terms of things that didn’t go so well, I could do with some better time management skills. If I had planned out my work a bit better, I probably would have had ample time to fix the errors I was getting, and I might even have been able to implement everything I had been working on. I’m not going to fret about that though, I just have to keep that in mind and make sure I give this sprint all the time it needs from me to get everything done. 

As with myself, our group has been doing a lot more communicating lately. Most of it has been really good, but a good chunk of it has not been very on topic. I’m not about to be some kind of narc that wants every minute of every day be spent working, that sounds utterly miserable, but I would like more of our discussions being related to what we are working on.

After looking in the book, I think the apprenticeship pattern that relates the most to this sprint was “Expose Your Ignorance”. The pattern states that the best way to fill gaps in my knowledge is to reveal them to my group, so that I might be more encouraged to find what I am missing. I’ve been the one working on rabbitMQ for two sprints now, and as such, I think it is easy to assume that I know every aspect of what it going on, but the longer I work on this project, the more small problems seem to come out of the woodwork. Oh sure, we have the code needed to send messages, but there is no queue for them to go into, so what is the point, etc. So, had I read this pattern at the start of the sprint, I think it would have been more productive to know what kind of stuff I was missing, so I can avoid any unexpected problems. I would have laid out the plan for the sprint, done some research on everything I was doing if I wasn’t 100% solid on it, and had some better fundamental knowledge going into that sprint than what I had. 

As usual, I will try to keep the things I learned in mind, but I will continue working on my issue, knowing that I do not have all the knowledge I need, and being willing to ask for help in finding it.

 

 

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

 

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

Sprint #2 Retrospective

Hello!

It’s that time of the month again, we’ve just finished up sprint number 2, and now I’ve got to write about how it went! 

I think this sprint was considerably more productive than the last one (even if I still couldn’t get my assigned issue done). I managed to parse out how I am going to make timestamps for the rabbitMQ messages, and I did a significant amount of testing with some files, to the point where I basically had everything working by the end of sprint 2. It would have been implemented were it not for the fact that I ran into some last minute errors that I couldn’t get fixed in time. Like the last post I made, the merge request will be available at the bottom of the post.

I think I did a much better job at communicating with my group this time around. I think I was a little shy before, plus overwhelmed at having to learn a new skill and be a productive member of a group. Now though, I’ve been pretty consistently talking to my group about what I’m working on, and I’ve been asking questions on things that trip me up, which I would consider a wild improvement over last time.

 In terms of things that didn’t go so well, I could do with some better time management skills. If I had planned out my work a bit better, I probably would have had ample time to fix the errors I was getting, and I might even have been able to implement everything I had been working on. I’m not going to fret about that though, I just have to keep that in mind and make sure I give this sprint all the time it needs from me to get everything done. 

As with myself, our group has been doing a lot more communicating lately. Most of it has been really good, but a good chunk of it has not been very on topic. I’m not about to be some kind of narc that wants every minute of every day be spent working, that sounds utterly miserable, but I would like more of our discussions being related to what we are working on.

After looking in the book, I think the apprenticeship pattern that relates the most to this sprint was “Expose Your Ignorance”. The pattern states that the best way to fill gaps in my knowledge is to reveal them to my group, so that I might be more encouraged to find what I am missing. I’ve been the one working on rabbitMQ for two sprints now, and as such, I think it is easy to assume that I know every aspect of what it going on, but the longer I work on this project, the more small problems seem to come out of the woodwork. Oh sure, we have the code needed to send messages, but there is no queue for them to go into, so what is the point, etc. So, had I read this pattern at the start of the sprint, I think it would have been more productive to know what kind of stuff I was missing, so I can avoid any unexpected problems. I would have laid out the plan for the sprint, done some research on everything I was doing if I wasn’t 100% solid on it, and had some better fundamental knowledge going into that sprint than what I had. 

As usual, I will try to keep the things I learned in mind, but I will continue working on my issue, knowing that I do not have all the knowledge I need, and being willing to ask for help in finding it.

 

 

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

 

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

Sprint #2 Retrospective

Hello!

It’s that time of the month again, we’ve just finished up sprint number 2, and now I’ve got to write about how it went! 

I think this sprint was considerably more productive than the last one (even if I still couldn’t get my assigned issue done). I managed to parse out how I am going to make timestamps for the rabbitMQ messages, and I did a significant amount of testing with some files, to the point where I basically had everything working by the end of sprint 2. It would have been implemented were it not for the fact that I ran into some last minute errors that I couldn’t get fixed in time. Like the last post I made, the merge request will be available at the bottom of the post.

I think I did a much better job at communicating with my group this time around. I think I was a little shy before, plus overwhelmed at having to learn a new skill and be a productive member of a group. Now though, I’ve been pretty consistently talking to my group about what I’m working on, and I’ve been asking questions on things that trip me up, which I would consider a wild improvement over last time.

 In terms of things that didn’t go so well, I could do with some better time management skills. If I had planned out my work a bit better, I probably would have had ample time to fix the errors I was getting, and I might even have been able to implement everything I had been working on. I’m not going to fret about that though, I just have to keep that in mind and make sure I give this sprint all the time it needs from me to get everything done. 

As with myself, our group has been doing a lot more communicating lately. Most of it has been really good, but a good chunk of it has not been very on topic. I’m not about to be some kind of narc that wants every minute of every day be spent working, that sounds utterly miserable, but I would like more of our discussions being related to what we are working on.

After looking in the book, I think the apprenticeship pattern that relates the most to this sprint was “Expose Your Ignorance”. The pattern states that the best way to fill gaps in my knowledge is to reveal them to my group, so that I might be more encouraged to find what I am missing. I’ve been the one working on rabbitMQ for two sprints now, and as such, I think it is easy to assume that I know every aspect of what it going on, but the longer I work on this project, the more small problems seem to come out of the woodwork. Oh sure, we have the code needed to send messages, but there is no queue for them to go into, so what is the point, etc. So, had I read this pattern at the start of the sprint, I think it would have been more productive to know what kind of stuff I was missing, so I can avoid any unexpected problems. I would have laid out the plan for the sprint, done some research on everything I was doing if I wasn’t 100% solid on it, and had some better fundamental knowledge going into that sprint than what I had. 

As usual, I will try to keep the things I learned in mind, but I will continue working on my issue, knowing that I do not have all the knowledge I need, and being willing to ask for help in finding it.

 

 

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

 

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

Sprint #2 Retrospective

Hello!

It’s that time of the month again, we’ve just finished up sprint number 2, and now I’ve got to write about how it went! 

I think this sprint was considerably more productive than the last one (even if I still couldn’t get my assigned issue done). I managed to parse out how I am going to make timestamps for the rabbitMQ messages, and I did a significant amount of testing with some files, to the point where I basically had everything working by the end of sprint 2. It would have been implemented were it not for the fact that I ran into some last minute errors that I couldn’t get fixed in time. Like the last post I made, the merge request will be available at the bottom of the post.

I think I did a much better job at communicating with my group this time around. I think I was a little shy before, plus overwhelmed at having to learn a new skill and be a productive member of a group. Now though, I’ve been pretty consistently talking to my group about what I’m working on, and I’ve been asking questions on things that trip me up, which I would consider a wild improvement over last time.

 In terms of things that didn’t go so well, I could do with some better time management skills. If I had planned out my work a bit better, I probably would have had ample time to fix the errors I was getting, and I might even have been able to implement everything I had been working on. I’m not going to fret about that though, I just have to keep that in mind and make sure I give this sprint all the time it needs from me to get everything done. 

As with myself, our group has been doing a lot more communicating lately. Most of it has been really good, but a good chunk of it has not been very on topic. I’m not about to be some kind of narc that wants every minute of every day be spent working, that sounds utterly miserable, but I would like more of our discussions being related to what we are working on.

After looking in the book, I think the apprenticeship pattern that relates the most to this sprint was “Expose Your Ignorance”. The pattern states that the best way to fill gaps in my knowledge is to reveal them to my group, so that I might be more encouraged to find what I am missing. I’ve been the one working on rabbitMQ for two sprints now, and as such, I think it is easy to assume that I know every aspect of what it going on, but the longer I work on this project, the more small problems seem to come out of the woodwork. Oh sure, we have the code needed to send messages, but there is no queue for them to go into, so what is the point, etc. So, had I read this pattern at the start of the sprint, I think it would have been more productive to know what kind of stuff I was missing, so I can avoid any unexpected problems. I would have laid out the plan for the sprint, done some research on everything I was doing if I wasn’t 100% solid on it, and had some better fundamental knowledge going into that sprint than what I had. 

As usual, I will try to keep the things I learned in mind, but I will continue working on my issue, knowing that I do not have all the knowledge I need, and being willing to ask for help in finding it.

 

 

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

 

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

Sprint #2 Retrospective

Hello!

It’s that time of the month again, we’ve just finished up sprint number 2, and now I’ve got to write about how it went! 

I think this sprint was considerably more productive than the last one (even if I still couldn’t get my assigned issue done). I managed to parse out how I am going to make timestamps for the rabbitMQ messages, and I did a significant amount of testing with some files, to the point where I basically had everything working by the end of sprint 2. It would have been implemented were it not for the fact that I ran into some last minute errors that I couldn’t get fixed in time. Like the last post I made, the merge request will be available at the bottom of the post.

I think I did a much better job at communicating with my group this time around. I think I was a little shy before, plus overwhelmed at having to learn a new skill and be a productive member of a group. Now though, I’ve been pretty consistently talking to my group about what I’m working on, and I’ve been asking questions on things that trip me up, which I would consider a wild improvement over last time.

 In terms of things that didn’t go so well, I could do with some better time management skills. If I had planned out my work a bit better, I probably would have had ample time to fix the errors I was getting, and I might even have been able to implement everything I had been working on. I’m not going to fret about that though, I just have to keep that in mind and make sure I give this sprint all the time it needs from me to get everything done. 

As with myself, our group has been doing a lot more communicating lately. Most of it has been really good, but a good chunk of it has not been very on topic. I’m not about to be some kind of narc that wants every minute of every day be spent working, that sounds utterly miserable, but I would like more of our discussions being related to what we are working on.

After looking in the book, I think the apprenticeship pattern that relates the most to this sprint was “Expose Your Ignorance”. The pattern states that the best way to fill gaps in my knowledge is to reveal them to my group, so that I might be more encouraged to find what I am missing. I’ve been the one working on rabbitMQ for two sprints now, and as such, I think it is easy to assume that I know every aspect of what it going on, but the longer I work on this project, the more small problems seem to come out of the woodwork. Oh sure, we have the code needed to send messages, but there is no queue for them to go into, so what is the point, etc. So, had I read this pattern at the start of the sprint, I think it would have been more productive to know what kind of stuff I was missing, so I can avoid any unexpected problems. I would have laid out the plan for the sprint, done some research on everything I was doing if I wasn’t 100% solid on it, and had some better fundamental knowledge going into that sprint than what I had. 

As usual, I will try to keep the things I learned in mind, but I will continue working on my issue, knowing that I do not have all the knowledge I need, and being willing to ask for help in finding it.

 

 

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

 

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