Author Archives: timdrevitch

Sprint #3 Retrospective Blog Post

For the third and final sprint of our project for this semester, we had the biggest list of tasks to complete. Not only did we have a tremendous amount of tasks, but almost all of them where big and difficult tasks. In our previous sprints, we had a lot of tasks that were smaller or that related to learning rather than creating. This made this sprint much more difficult for everyone. Some cards that I had to complete by myself were not too bad. One of them was simply to update the frontend example that I produced in sprint 2. We changed some things on it in order to have a smoother experience for the user when they are a returning customer. The questions that could be skipped if a returner logs in now will be autofilled in (with the availability to change their previous answers). Many other tasks I worked on were much bigger and were not solo tasks. Before the end of the sprint, I was able to help with tasks such as implementing the GuestInfoDB. It was extremely important for us to get as much of our tasks done as possible before the end of this semester so that future students could used what we have worked on to improve or even finish it all next year. We tried to write as much as we could in the cards themselves on GitLab in order to help anyone realize what we were trying to accomplish. Even if we failed to finish some cards, starting them and writing what our thoughts where will help future students when they get to the steps that we got to. We were able to utilize work from previous students this semester in the same way. By the end we were able to get a basic frontend working to an extent that ended up not being too bad in my opinion. Even the cards that we did not end up completing should be very helpful for future people working on this project, whether it be Capstone students or WSU employees. Before moving on from this project, we were instructed to add our thoughts and ideas to cards that we had not yet completed for that exact purpose, and from what I have seen from my group, that should be pretty useful in the future. It was nice being able to work on a real life example for this class, and it is something I actually wish I had done more often throughout my undergrad. Everything this semester, especially for this course, definitely helped improve my understanding of how projects would be worked on in the real world, and I am thankful for being able to learn in that way!

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Software Quality Assurance and Testing Blog Post #5 (Test Automation)

For my fifth and final topic review for Software Quality Assurance and Testing, I decided to go over test automation. I found a lot of good sources on the internet to help me understand what it is. A lot of the testing practices that we have learned about this semester have been manual testing rather than automated testing. This just means that we would write the tests and go through them ourselves rather than let the computer do it by itself. This works really well with testing methods like discovery testing and usability testing. The reason we would use automation testing is because it is much easier to have the computer run tests for us (especially in cases in which we have repetitive testing). We do not want to be wasting our time running repetitive tests over and over again when the computer could do it all much faster and with a lot less effort. Test automation’s main appeal is the speed that comes with it. One would think that we should just use this type of testing all the time, but the reason we do not is because some testing methods have to be done manually. One of the best sources I found was on testim.io, and I will make sure to add the link for that at the bottom of this post. The article is very good because it describes what automation testing is, what its criteria are, what types of tests are classified as automation, and the general process of using this testing method.

https://www.testim.io/blog/what-is-test-automation/

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Software Quality Assurance and Testing Blog Post #4 (Program Graphs and DD Path Graphs)

The latest topic in my Software Quality Assurance and Testing class has been learning how to read and write program graphs and DD path graphs. We also have been learning how to make DD path graph tables that correspond with the DD path graphs and the program graphs. Our most recent assignment was all about these topics. With the amount of work we have put into learning these, the assignment proved to not be too difficult for me. It is generally easy to know how to read the program graphs because pretty much every node corresponds with a single line of code in a program. Where it gets tricky is when the program has loops and if statements. Converting to a DD path graph from the program graph is also not too hard if you know what you are doing. A lot of nodes from the program graph can be clumped together into single nodes (like all the instance variables for example). Lastly, creating the DD path graph table takes in account both the program graph and the DD path graph, but again is not too difficult to read or fill out. The amount of time we have spend on these topics in class while doing in-class activities has helped me tremendously, because looking at the graphs without knowing what you are looking at can be daunting and confusing. As much as I enjoy being able to understand the graphs and make them if I want, it is even more enjoyable knowing that these topics can all be used in real life. It is always very reassuring when I try to research topics from class and they seem to be very prominently used in the real world with lots of examples and helpful sources to teach me about them. In this case, these topics all seem to be used a lot and also seem to be very helpful for those who have used them before to study how a program could be working (or how it could be failing).

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Sprint #2 Retrospective Blog Post

The second sprint of the semester started a bit rough for me with my surgery, but I was able to get most (if not all) of my work done throughout the weeks we worked. I was able to help a lot with creating the cards and giving them descriptions at the start, and then the first week or so of the sprint I was very busy. After this initial period, I was able to catch up on my work and get a lot done. I was primarily in charge of getting an updated example of our front end based on an old one that was provided to us from previous years. For this, I used google forms, but in the end I had to take screen shots of all my work and upload those in case the forms document that I created got deleted or lost. This will be helpful for our team and for any students working on this project in the future. There is still a bit of work I need to do on this example to make it perfect for what we want, but this has been added as a small task for me to complete in the next sprint. Overall, our entire team did very well getting a lot done, and although I did not get the backend coding assigned to me, I was able to lend my insight and some advice and code to my teammates. This sprint was a lot different than our previous sprint primarily because it had less to do with learning how to use cards and work in a sprint and had more to do with getting real work done to further our progress on this project. I presume that the next sprint will be even more important, and we will have a lot of hard work to do to try to complete all or most of our cards. Some things that worked well this sprint were our team’s hard work ethic for getting everything done and our ability to communicate well and let each other know what needs to get done and what we need help with. For this sprint, we actually added a member because of the IAmSystem team splitting up after the first sprint. This was not a problem at all and in fact was more helpful because we were able to get even more cards completed over the couple of weeks we had to work. If I were to change anything or expect anything more from the next print, it would be that I personally will be able to get a lot more work done earlier in the sprint without having a surgery as a distraction. I am excited to see how far we can get on this project by the conclusion of this semester, and hopefully we will be able to get a nice looking and working project by the end. This whole experience has been great for me so far for learning how to work in groups for sprints, and I know that after college I will run into many projects where I have to work like this.

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog Post #8

For my final blog post pertaining to the apprenticeship patterns in the textbook, I decided to review the pattern entitled “Rubbing Elbows.” The situation that this pattern pertains to when the apprentice has almost plateaued and has been working on their own for projects. In this situation, the book explains that the apprentice will sometimes feel like they are missing things (like better ways of solving problems), but that they are not able to find these things on their own during their plateau. The reason I chose to review this specific pattern is because I can relate to it. On my free time outside of school, I have worked on projects on my own, and I know there are better ways to program what I am making but because I work on my own, I find it difficult to find those new and possibly better ways or working. The book’s solution to this problem is to find someone else to work with in order to learn more and have a different perspective on your projects/work. “Find ways to sit with another software developer and accomplish a hands-on task together, side-by-side. There are some things that can only be learned while you are sitting with another software developer to accomplish a shared objective.” I have actually done this before with a classmate while working on making iOS applications for fun, and it was an enormous help. Even if the person you are working closely with does not have a different solution to your problems, the added outside perspective proves to be not only helpful, but also necessary. I was especially excited when reviewing this pattern because I feel like I already am great at working with others, and the fact that that skill could be a good thing for my career is reassuring. The book describes how working with someone else could have many benefits even if it is only once a week. It helps keep you motivated and helps keep the other person motivated as well. If working with a certain person becomes not so motivating, the book explains that this does not mean you should give up, but perhaps you should think about working with someone else who could be even more motivating to collaborate with.

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Software Quality Assurance and Testing Blog Post #3 (Black-Box vs. Gray-Box vs. White/Clear-Box Testing)

On the first exam for my Software Quality Assurance and Testing course, and in activities previous to it, Black-Box, Gray-Box, and White/Clear-Box Testing were important topics/definitions to thoroughly understand. Not only did we have to know the meanings of these terms, but we had to be able to compare them and know how those testing methods are used. White/Clear-Box Testing is when the tester knows the contents of a function or method. This comes with its advantages and disadvantages of course. The advantages are that it is very easy to navigate the complexity, get legible test cases, and makes debugging smoother. The disadvantages would include bias being used by the tester and possibly longer and more expensive testing in general. On the other hand, Black Box testing is quite the opposite. The tester is not able to view the inner workings of the function/method and is only able to test based on what inputs are given and what outputs are received. Although this seems counterintuitive for a testing method, it also has advantages and disadvantages that make it a viable option. The advantages would be that it would take less time and expenses to test and that it eliminates tester bias altogether. The disadvantages are that because the tester is not able to see the inner workings of the function or method, it makes it harder to debug, find complexity, and have easy to read test cases. The two methods are basically opposites. Lastly, Gray-Box Testing is somewhere in-between the two. The tester knows a little bit about the inner workings of methods and functions, but is not focused on them completely like in White/Clear-Box Testing. This makes all of the advantages and disadvantages even out more overall which could be good in some cases but could also not be a valid testing option in other cases. Before this semester, I actually had never even heard of these terms, and it was interesting to go through and research them for this post and for my course!

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog Post #7

For my second to last apprenticeship pattern blog post review, I would like to talk about simply because of how close it hits to home with me is the pattern entitled “Draw Your Own Map” in the textbook readings. This pattern is based on the fact that throughout the lives of software developers, there will be many times in which jobs or opportunities will not quite fit what they are capable of or are even interested in doing. The main issue brought up in this chapter was that none of the career paths provided to young software developers are often fitting for them. The reason that I chose to review this specific pattern is because I believe it relates to me very deeply as I am worried that whatever direction I end up taking after college may not be right for me. I already have many different options and directions that I could take from here and the opportunities are almost more daunting than exciting at this point. I am worried I will make the wrong choice early on. The book tried to solve this problem by basically saying that I choose my own destiny. “Identify a logical but ambitious next step for your career. Understand that it’s not up to your employer, your career counselor, or your professors to give you a hand up.” Sometimes the guidance of others is not what is needed even if it is with good intentions, because more often than not, I should know what I like best. The book also explains that no matter what direction I want to choose, it is important for me to make sure to take the first step. Without the first step, the dominos will not start falling and there will be no momentum toward my goals. If others (such as employers) try choosing a path that is not right for me, I must reflect and make the decision to stay on the course that I personally see best fitting for me. Obviously, when working, I should complete my roles and not give up, but in the end, it is not wrong for me to change direction and even switch career opportunities for my own betterment if I feel I need to.

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Software Quality Assurance and Testing Blog Post #2 (JUnit 5 Testing With Gradle)

The second assignment I worked on in my Software Quality Assurance and Testing class combined what we learned about JUnit 5 testing and using Gradle to automatically run all the tests fast and easy. This assignment proved to be more difficult than I was expecting, but in the end, I got very good at it and learned what I needed to. Downloading Gradle in the first place was my initial issue, since it seemed much easier to get it with a Windows machine than my Mac. Some classmates were kind enough to assist me and let me know about a software called Homebrew that basically is able to download Gradle for me. This was so helpful, and it was installed in no time! The second thing that make this assignment more difficult was that the actual tests I had to write were much harder than my first assignment. It took a lot of debugging and testing over and over again to finally get all of the tests to pass correctly. For some reason, many of the errors I ran into were primarily because I have made silly mistakes like grammar or syntax faults. All the repeated testing and debugging made me so much better at writing the methods correctly. The last thing that I would like to reflect on from this assignment is something I should have covered in my previous blog post. It is that pushing my projects to GitLab has changed. Of course, it has not changed that much, but just slightly. Rather than using the command “git push origin master,” I now have to write “git push origin main.” This is not too big of a deal for me, but at first I did not understand what I was doing wrong because of my pushes not working. I believe all of these things together will be a big part of my first exam in this class, and because of that, I am happy I was able to briefly discuss them in this blog to get a little extra review on them before that date!

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog Post #6

With the semester nearing its end, I do not have many more apprenticeship patterns to review on here. Because of this, I am trying to choose patterns that have the most relatability to me. For that reason, I chose to review the pattern in the book entitled Sustainable Motivations. It is all about developing your technical skills in order to maintain your ability to work well given different project goals and situations. The problem that I am trying to solve by learning this skill/pattern is the fact that this line of job is often rigorous, difficult, and stressful. I need to learn to love what I do and be good at what I do when I am not loving it. The book explains how there are many days, weeks, and months where my job will be extremely fun and enjoyable, but that there are also many times when it will be quite the opposite. The important thing is for me to keep moving and working through the not-so-good times and continue to stay motivated as much as I can throughout the process. The book has some great tips and examples of how to stay motivated during the harder times. First, I should be working hard to move up in the ladder of my jobs rather than just fulfilling my personal duties. This is especially apparent when I am not enjoying what I am working on and mainly working for the money aspect. The second example is when I could possibly want to quit and I decide to pull through and finish what I am working on. It proves valuable and exciting to finish things whether you liked the process or not. Lastly, the book shows that pulling through the tough and hard times will help your reputation as a worker and a programmer immensely and that in doing so, more opportunities with open up. This whole pattern resonates with me so much because of how ominous real life jobs feel to me at the moment. I know that if I follow those three examples/tips, I will not regret it! Bad times will happen, and pulling through will only help me grow.

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Sprint #1 Retrospective Blog Post

After the first month of my final semester, my capstone course has proved to be an interesting experience so far.  As much as we are working in groups to create a database dedicated for the food pantry, I believe we really are striving to strengthen our skills with using the SCRUM method of group work.  Our first sprint went very well in my eyes.  We have not gotten much done in terms of making the frontend and backend of our database, but we accomplished a lot when it came to getting tasks done that we chose to try to complete at the beginning of the sprint.  Our team worked very well together and it seemed as though everyone was contributing heavily towards finishing our tasks quickly and completely.  Personally, I thought I contributed a lot of research, work, and extra effort for the team to help everyone out.  We decided to make me the team’s SCRUM Master which in all honesty did not force me to have much more responsibility at all, but it was helpful for me to learn from the product owner and relay back to the team.  I tried keeping helpful information posted both on discord and on gitlab for the team and for myself.  This proved very helpful.  In the future (for later sprints and for in similar situations in real life), I believe we could have done a better job communicating outside of our class periods.  It may have help our group get things done even smoother than how we already did if we had been running a better communication system.  This however was not really anyone’s fault as we were still able to get most of our tasks done and because of the fact that everyone is taking a lot of classes right now and not just this one.  On a personal note, I think it would have relieved some stress for me if I could have tried spacing my work for this group out throughout the week rather than getting things done in one or two sessions per week.  This would have made it easier for me to communicate problems if I had had any and would have reflected better on my final completions at the end of the sprint.  Again though, it is more difficult when I am taking other courses and not having this project as my main job or focus.  The main issue that I think my group and I will run into for the next sprint is that we will have more tasks related to building the database now rather than the more learning and reviewing bases tasks we had in sprint one.  Like I stated earlier, this sprint seems more like one in which we get familiarized with how the rest of the sprints will be done and how to work as a group with SCRUM.  However, I think we picked up on what we needed to do very fast, and everyone seemed to have put in a lot of good work and dedication.  Because of this, I know that even if the tasks in the next sprints become more difficult, we will still be able to get great work done and have a successful product in no time!

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.