Author Archives: fbaig34

Sprint 3 Retrospective


This was about filtering the data for the report.

We were able to get sample data from the other teams as a JSON object and used fake data to download report as csv.

Created a docker container registry and implemented it on gitlab.

Edited backend code so it takes a date and retrieves data based on that date.

Created the backend endpoints to receive the start and end dates from frontend.

The thing that worked well was that we got the system to actually run and get messages from rabbit mq which gets saved in the database to be used to pull the report. We were also able to connect it to the frontend and get a wsu style theme for the website. I think there was a lot that worked well considering this was our last sprint and we could not rely on another sprint add more work.

Some things that did not work well in this sprint was that we did not have as good of time management because there was so many projects for each class so we had to find chunks of the day to work when we can. However, I think our group gets a lot done under pressure and is able to complete a lot more in a few hours nearing the deadline as opposed to those same hours with free time. If we had more time to space things and did not have to worry about many other cs classes, then it would be much easier to focus on making the website as efficient as possible.

A few changes that we could make for future sprints as a team was to keep our eyes on the main goals of the sprint and not on small details. I feel like we were stressing on small aspects of the project when the big important features would have been just better to work on. We were struggling taking so much time to work with docker and get some of its aspects to work, and this took a way from upgrading and making the backend and frontend more efficient. I think next time we would spent as much time from the beginning to get the website up and running and having all the functions work properly for a user, then focus on the small details that won’ t take as much time to figure out in comparison to the bigger parts.

A few changes I could make as an individual is to find a balance with working on my team and working on my own. I feel that I was either working with the team too much or my own most of the time. I think in future it would be a lot more clear what our goals were and what to work on as the sprint went, but for this a lot of the task were things we could work on together and help each other out. I think even with all the factors we were still able to produce efficient work.

Overall, I think this sprint went very well and we got a lot accomplished. In the last week of the sprint we were panicking because of how much other projects we had to from 4 other cs classes and 5 including this class. However, we put our focus 100% on accomplishing everything and looking back we got more than enough done. It was very helpful to work in a team where we would help each other out and make brainstorming and planning a lot more easier. I think this sprint and this class in general will help us out in our future endeavors especially in the work field. A lot of the planning is what helped us out and our website was able to run which was very helpful for us to know that we did it. I’ll appreciate everything that I learned these past 4 years and from every professor and good luck to everyone on their future goals.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Practice, Practice, Practice – Apprenticeship Pattern

This apprenticeship pattern might be one of the most important ones in the book because it is something that can be applied to any aspect of life, especially for software development. You need to practice your craft and work on improving it by practicing it each and every day or at least the times when you can in an environment without interruptions or deadlines to help you focus. Software architects need to make mistakes to learn and they need to practice in order to learn. The mindset for this type of approach is to always be ready to perform and be as prepared as you can. If you don’t take action on what you need to know, then you will just be stagnant and stuck in the same place. The pattern doesn’t only talk about practice to improve, but talks about practicing in the best way. You need to try and practice in the best way possible by getting periodic feedback or getting more analysis on your mistakes. Practice will be come permanent in the wrong if you don’t constantly focus on way to improve the way you practice to learn in a more efficient way. This is why it says to practice in a relaxed environment so when you make mistakes you are comfortable with making mistakes and not burdened by it.

I think the biggest takeaway and thing I would add to this pattern is that the only way to learn is by doing and not focusing immensely on theoretical. Anyone can learn the theoretic aspect of software in a short period of time, but there takes more effort and practice to learn the practical aspect since you learn by doing. If someone were to learn all the rules and basics of a sport, but not practice actually playing the sport, then they will not be good at the sport. This is very similar to developing software, since you need to learn the theoretical aspect, but in order to be good you need to keep on practicing and learning. It is essential to always be prepared and up to date with how to learn and the most efficient way to learn a specific software. Overall, the end goal is improvement and to learn to adapt and adjust as time goes on for the most out of your software journey.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Test Automation

I the world today, everyone is looking for fast solutions and fast technology. The world is expanding rapidly, especially in technology, so many things are being automated to increase how fast things get done. There comes test automation that falls into these categories to make testing faster, and not rely on manual testing which would take much more time. A lot of the manual testing methods people may use such as regression or unit testing manually, is a time waster and is not efficient for people to do constantly when it can be automated. For test automation, the tests are run automatically and the goal of it is to improve the quality of the software in the most efficient way possible. There is a general criteria that needs to be followed in order for a test case to be suitable for automation. These requirements include that the tests are repeatable and there are many factors for this steps. In order for tests to be repeatable, they need to first set up the test by including the data and environment. Then they need to execute the function and the part of the software that is being tested. And lastly once everything is run, the data needs to be cleaned and the environment it was created in. The next criteria is that it needs to be determinant, which means that the output of the test is the same each time with the same input. The last criteria is that it needs to be unopinionated, meaning human judgment and error in that tense cannot be a factor when the tests are run. Now all the different types of automated tests include code analysis, unit testing, integration testing, automated acceptance testing, regression testing, performance test, etc. Overall, automation has made testing a lot more efficient and the process a lot more easier in a way since it saves much more time than having manual tests in many circumstances.


From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Object-Oriented Testing

Some of the common methods of testing we know and learned are unit testing, which tests the software at a single unit or class file, and we also have system testing that tests different part of the system. However, as software is becoming more complicated and there are many class files in a software project, one important method of testing that has become useful over the years is object-oriented testing. Normal testing methods won’t be able to be used in these sorts of circumstances because of the different object-oriented features such as inheritance, polymorphism, abstract classes, and other related concepts to it. There are different ways to test the classes and the same methods for testing functions won’t be able to be applied because a single function is completely different than an entire class output.

For object-oriented testing, there are a lot more dependencies that are required compared to normal testing styles. Testing functions are a lot more simpler than testing objects and so more factors need to be taken into account. The first additional testing method for object oriented testing is known as fault based testing. This way of testing tries to come up with test cases that predict any faults that are possible and these test cases are there to solve the errors. The fault based testing doesn’t find all the possible errors and it only tests for the requirements of the client. The next type of testing method is class testing based on method testing and for this one each method is tested similar to unit testing and all the methods are tested for a class one time at the bare minimum. The next type is random testing is for random test cases that is responsible for the operations that are related to behavior of certain categories of the software. The next version of testing for object-oriented testing is partition testing which takes into account inputs and outputs for a certain category and this reduced the total number of test cases. The last contrasting test case is scenario-based testing which takes into account different actions that a user will take and tests for those separate scenarios. Overall, object-oriented testing has similar concepts to conventional testing but there are many other types of testing that are also included that vary from the normal way.


From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective


This was for designing how the database would look and the schemas for all the different fields required.

This was for the implementation part of the reporting database that I designed.

This was for reviewing css and html using tutorials online.

I worked on designing the API for some of the backend endpoints by playing around with swagger.

We worked on creating an open api yaml file that will be used in the next part of the sprint.

The thing that worked well in this sprint for our group, the reporting system, was that before we started the sprint we were able to break down more efficiently what everyone’s role would be. For this sprint we added one more person, and they were responsible for their iam system and each of us had our roles. However, this time I was able to work separately on my issues and then meet with them team for issues that are related to the whole team and how we can help each other out. A lot of the database stuff I was working on was related to the backend aspect, so I worked on that with the other teammate who was assigned the backend role.

Some things that didn’t work well was that we had problems with some of the things we were supposed to do with the report. It was unclear in the beginning what aspects would go in the report and which teams would be sending what. So for this sprint there was a lot of meetings to figure out more of the aspects of the report and not as much as being able to implement the features required.

A few changes we could have made as a team for future sprints are to have the meetings with other teams or product owner about the specifics earlier on in the sprint. This way we can focus on creating the different schemas and backend as well as frontend implementations that are required for the overall pantry and not be stuck on the details. With this procedure, we can get more work done and if there is any confusion we can meet and clear it up after we have done some more implementations on our parts.

Changes I can make as an individual to improve the sprint is to figure out all the details of my role first, then start working. There is not point in getting confused on what to do and start working without a clear grasp. This is where I can work with my team more and ask more questions about a certain issue I have. Instead of working independently on all my tasks, I can ask my team for certain things that there are issues on.

Overall, I think the second sprint was really helpful managing confusion with the project and sorting it out to a solution by meeting with the team and others. I think we helped each other out with the details by meeting with other teams and the product owner who had more details about the product we were supposed to make. I think it was a good learning experience and successful sprint and I am looking forward to the next sprint.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

A Different Road – Apprenticeship Pattern

What this apprenticeship pattern talks about is completely different from a typical software architect approach. This pattern talks about what you should do if as you go on the long road and your journey as a software developer, you stumble on something different that you feel would be beneficial towards. It gives an example of how some software developer completely left software development to teach surfing half way across the world. There are many examples and situations as to why someone may not want to be software architect anymore. However, no matter the situation, this pattern talks about how it isn’t a good decision to just burn bridges and forget everything you learned on your journey in developing code and all these other technologies that you put in time to learn. You had many systems that you learned to do things and implemented them in order to do things faster and be able to learn many new things at a faster. Instead of just leaving all this behind, the pattern says to use all that knowledge and move forward to apply it in your new field whichever direction that may be. It is never helpful to just forget everything if you start something new but to learn from your experiences.

This pattern may seem kind of odd to software developers and architects since they want to develop code, but this can be helpful down the line. I would say if there is something you like differently down the road then this pattern will be very helpful. It does not need to be specifically about completely changing fields and you entire lifestyle till then. It can also be related fields in computer science and the direction you want to take. Let’s say you were a software developer for many years, but there comes a time where you are more interested in the big data field and want to make a switch. You feel it will be more beneficial to your life so whatever the reason be, you can still hold on to the principle as a full time coder and applying to the other field. In this way a lot of things are connected and it will be helpful to manage change. The main thing I would say in life is to be comfortable with the idea that you may not be familiar with the change at the moment but you have to trust the path you will take to find those solutions.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance – Apprenticeship Pattern

This apprenticeship pattern is called expose your ignorance and the name for it is kind of straight forward but it is an important matter for a software craftsman. Often times there are many things that a software craftsman does not know and the goal is to find out the things they don’t know and learn about. They need to gain more experience with the new technology and not be shy about learning. Exposing your ignorance means being able to put your ego aside and write down things that you currently aren’t capable of doing so you can move forward and learn about them. Also when working with teams, it is important to communicate to your client or product owner that the work you are doing requires a learning process and don’t just tell them you know what the technology is already. This way you will build stronger relationships over time. The goal is to find a balance between not knowing a certain thing and being able to learn it.

I think this pattern is important for software craftsmen because often times people will become certain and expert with a certain technology and want to only stay on that path. They aren’t willing to navigate in other directions but become more experts in that field. However, for craftsmen we need to keep on being interested in the journey and learn more things that we are ignorant about. The goal is to be able to learn things and as the journey goes along, you will be able to master things but it shouldn’t be the end goal. The people who are experts are aiming to be masters at the technology and learn the most they can about it because that’s their end goal and it is not about overall learning for them. This is why craftsmen need to expose their ignorance and find out things that they aren’t currently able to do. Then the next step is to figure out how to learn it and create a learning guide that will work for them. Overall, this is an important pattern for craftsmen to improve their knowledge.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Stay in the Trenches – Apprenticeship Pattern

What this apprenticeship pattern starts off talking about is how you have been developing extraordinary code for years, meeting the standard for the company, but all of a sudden you are offered a management position which will in fact take you away from coding into another direction. Now the pattern states that this may be tempting and show that you are leveling up, but it is actually sort of an illusion in a way. You may feel that a promotion will help you out, but in this case it is taking away from the journey you have took so far and the motivation to be a good programmer. When you take the promotion, then you will start deteriorating in the skill of programming slowly as time passes by. What staying in the trenches means is to stay true to your passion, and try to find rewards for you exemplary work in some other sort of way by negotiating with the company.

I think the main message of this pattern is important and how it is talking about staying true to your passion. One thing that I don’t agree with is just because you may come across a different path in life that may be outside of programming, does not mean that you should not take. There are a lot of people that won’t be able to be in the position of manager and although a person has a passion for programming, there are times when someone needs to go to the uncomfortable side to level up. It may be time to start learning more about the bigger picture of software development and managing a team of programmers, then just doing programming yourself. It will be a different change and the only way to find out whether you like it or not, is to try it out. In the future, if you believe that the role isn’t for you, then you can always go back to some role of programming at a different level. The goal however shouldn’t just be to give up programming all together, but to try some different path while also staying up to date with the programming aspect. I personally believe that this will help you out more with experience of leading a team and not only focusing on the developing aspect. The more variance experiences a person has, then in the future it can help apply in all sorts of different aspects.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Sustainable Motivations – Apprenticeship Pattern

What this apprenticeship dives deep into is that along your journey of becoming a software craftsman, there will be many times you face trials and tribulations. There will be instances where you are burdened with working on a complex project and forced to solve problems you have no idea where to even start. I am sure most of us on our journeys have faced this pressure and this feeling of whether this is all worth doing or whether we are cut out for it. However, this pattern says that we need to have clear and strong motivations when these trials come to our front door. Many people have different motivations as well as altering goals and ambitions. We are all developing software and programming for various reasons as clearly defining these things help us moving forward. We wouldn’t have made it this far if it wasn’t for some motivation that kept us going.

I think this chapter is very relevant for all of us who are trying to become software engineers and architects, and to understand that this journey isn’t just some smooth sailing. There will be times where everything feels easy and you feel lucky to even be in these circumstances. However, there will be other times that bring either the best or worst out of us when we face hard problems related to programming which can mess with us mentally. As a result of this pressure, we need to keep our road and ambition clear on where we want to be heading. Our journey is unique but to keep the journey going we need some strong interior purpose and motivation to pick up our head and keep moving forward on those days when we feel like there is no purpose for doing this. It is at these times, our mind is fogged up with the current problem and not on the bigger picture as to why we are doing all this in the first place. To clear up that fog we need sustainable motivations to be our anchor and help us get through and keep the boat moving. Overall, software architects will need to develop the mindset of believing in themselves and know they are doing what is right for them if they have a clear vision.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective Blog


I worked on reviewing docker and creating a sample docker project with the links above. These were both team issues that we all worked on.

I used tutorials online and several websites to review details about mongoDB.

I created a sample mongoDB project for practice and getting familiarized with the database.

This was for creating the main repository for the database that we will be using in reporting system.

The thing that worked well in this sprint for the group I was apart of, the reporting system, was that we organized each step of the way and tried to breakdown things to be more manageable. Each individual was responsible for certain tasks, such as in my scenario I was focusing on learning about the database aspect. Also, we had other issues assigned that were team based and so each individual in the group would work on that because it would be important for the whole team to learn about that specific issue. Overall, the planning at the beginning of the sprint helped keep the tasks we had to work on as a group clear, which led to us completing all the issues we assigned to ourselves.

Some things that didn’t work well was that we had problems in the beginning creating templates to explain what each issue was for on the cards. I think our group knew what we were supposed to do and communicated via discord, but didn’t put all the details we could have on the cards. Also, I think that when we have meetings we should focus on what we can do as a group that day and then on our own time work on the individual tasks.

Some changes we could have made as a team for future sprints are creating cards that aren’t so broad and keeping the issues more clear. Although it was the first sprint and there was a lot of learning to do, I believe that in the future when more implementations and detail will need to be done then it is important for us to break down the issues so they are representative of their point total. We can’t just put an issue and keep it so vague that once the sprint starts, it turns out the issue is a lot more complex than anticipated. Therefore, in the future as a group we can ask more questions for each issue assigned and say whether this will be enough of a task and whether the requirements are clear for the person to work on.

Changes I can make as an individual to improve the sprint is to start balancing out the work from the beginning of the sprint to the end. I feel like for the first sprint, I started off slow, in terms with how much work I got done, but towards the second half of the spring is where I completed most of the work. I think if I keep an equal balance and more momentum from the start, it will be a lot easier to manage and help myself as well as others to not be overwhelmed.

Overall, I think the first sprint was a success and it was really helpful working with a team on a project and deciding how we will break it down. I think when there is a full team working on creating something big, then each individual has ideas that we can use to help each other and be more creative in the process. The more ideas there are and brainstorming, the more thorough the end result will start to look. I am looking forward to the next sprint and further improve my experience with scrum in general.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.