←

Zack's CS Blog

Tag: CS@Worcester

  • CS-448: Week 15

    ztram1

    The Long Road

    The pattern “The Long Road” is about how in today’s culture, we value overnight celebrities, rising stars, and quick results. This leads to the conditioning of assuming that the shortest path possible is also the best path. With this thinking, people say to take the highest paying job and the first promotion available; however, this takes away from developers being able to slowly build up their skills.

    The first step to this pattern is to accept that this nontraditional way of thinking may be considered strange because the focus is set on learning and the long term rather than a high salary and traditional views of leadership. The pattern highlights the importance of planning for the long term, and to plan on being a software developer for decades. Planning for the long term will help to influence what jobs to take and future ambitions. The pattern emphasizes planning for the long term because it takes a long time to comprehend the deeper, more complex topics that come with software development.

    The pattern states that this is not a pattern for people who’s main focus is monetary gain. This is not to say that those who follow this pattern will not be able to make money, but it is not their main focus. If monetary gain is the main motivator for someone, they may find themselves counting down the days to retirement as opposed to the craftsman who will joyfully work until the end of their career.

    In order to plan for the long term future, the pattern suggests thinking about yourself a long time from now, 20 plus years ahead. With that in mind, imagine what you would want your professional history to look like, and the biggest influences. Using that as a baseline can help plan for future career choices.

    Conclusion

    I found this pattern to be interesting because it showed a perspective that most do not talk about. The idea that the journey of a craftsman is a long road, so should be treated as such changed the way how I view going about my own career. Rather than focusing solely on how high the salary is, focusing on learning and long term goals will lead to a more joyful and enjoyable career.

  • CS-448: Week 18

    ztram1

    Security Testing

    Security testing is an important part of software development and testing. Security testing focuses on identifying security vulnerabilities such as malicious attacks, unauthorized access, and data breaches. Testing is done by verifying the system is compliant with security standards, evaluating security features and mechanisms, and conducting penetration tests to find weaknesses.

    Security testing plays a critical role in software testing for numerous reasons. Some of these include the protection of sensitive data, meets compliance requirements, and most importantly maintains trust. An application with strong security helps build trust among clients and end users because strong security makes users feel that they can use the application without their information being at risk to be compromised. Organizations are held to security standards that are used to regulate the minimum level of security in an application. Security testing can be used to identify security vulnerabilities and ensure the application meets the set standards.

    Main types of security testing

    There are many types of security testing based what the intended use is. For example there is security testing for software applications, web based applications, APIs, and more.

    Application security testing tests the security of a software application. The process includes a combination of automated and manual testing techniques such as code analysis, penetration testing, and security scanning.

    As the name suggests, web based application security testing focuses on identifying vulnerabilities in web based applications. Testing also involves a commination of manual and automated testing; however, what is actually tested differs from application security testing. This is because testing web based applications involves methods such as SQL injection testing, and cross site scripting testing.

    API testing evaluates the security of an application’s APIs and the systems that the APIs interact with. When testing APIs, various types of malicious requests are sent to the APIs and their responses are analyzed to find potential vulnerabilities. APIs are susceptible to specific threats such as denial of service attacks, API injection, and man in the middle attacks. Man in the middle attacks are where an attacker intercepts the API communication to steal sensitive information. Therefore the goal of API security is to ensure that they are secure from attacks and sensitive information is protected.

    Conclusion

    This article was chosen because it clearly explained what security testing is, why it is important, and the different types of security testing. This was important to me because I have a very little knowledge/experience with security testing. I enjoyed learning about security testing as it plays an essential role in software development because no one wants to use an application where their information could be compromised. In the future I intend to look further into standard security measures, and how to test them.

    Resources:

    https://www.hackerone.com/knowledge-center/what-security-testing#:~:text=Security%20testing%20is%20an%20important,unauthorized%20access%2C%20and%20data%20breaches.

  • CS-448: Week 14

    ztram1

    Retreat into Competence

    This pattern is about how it is easy to get caught up in constantly learning new technologies due to the fast pace of software development, and how to manage the intense pace of learning. The pattern highlights the importance of taking a step back from the fast paced learning and to focus on honing existing skills. Trying to learn the latest tools, frameworks, and methodologies can be overwhelming. Along with the overwhelming feeling of trying to learn many skills at once, there is also a risk of never fully mastering the fundamentals. Therefore it is important to take a step back, and take time to practice fundamental skills.

    According to the pattern, being an apprentice is a rollercoaster ride. This is because there is the thrill using newly learned skills to deliver value to the customer, but there is also the terror of realizing how little is known compared to more experienced craftsman and experts. However both are normal and inevitable experiences.

    Although the pattern encourages developers to take a break from learning new skills, it also emphasizes how retreating back to competence is to not get stuck in the realm of competence. It is important to be intentional when retreating, as this pattern is only a short term fix. Spending too much time on this pattern can lead to halted learning. Being able to learn something new is a skill in itself; therefore, learning should be practiced unlike any other skill.

    In order to prevent the pattern being used, setting a time limit for honing new skills is useful. This is so one does not focus too much on retreating, and helps them stay in the habit of learning new skills. A strategy the pattern suggests is to pick a well understood topic that is self contained, and to reimplement it. This can help regain confidence to propel learning.

    Conclusion

    I found this pattern to be interesting as constantly learning new technologies can be tiring, so having a strategy to regain confidence is helpful for the future. I particularly enjoyed the analogy of a catapult to represent this pattern. The analogy being that the skill of learning new topics can be launched forward by taking a step back. The pattern has changed the way I view learning new skills, and maintaining old ones.

  • CS-443: Week 17

    ztram1

    Unit Testing

    Unit testing is a process in software testing where the smallest functional unit of code is tested. A common practice for unit tests is to first write the tests as code. Then the test code can be run automatically when changes are made. Doing this allows errors to be found, and isolated quickly if a test fails. Automating tests helps to ensure that efforts are focused on coding, rather than running tests.

    As stated previously, a unit test is a block of code that verifies the accuracy of the smaller blocks of the code such as a function. The unit test checks that the block of code runs as expected, determined by the developer’s logic. A block of code may have more than one unit test assigned to it, in order to cover the full behavior of the block of tested code.

    A block of code cannot be tested using a unit test because a unit test cannot use external data. Therefore the unit test needs to run in isolation. Because unit tests must run in isolation, this helps to improve the design of the code base to ensure that no function relies too heavily on other parts of the system. Doing this prevents code smells which can lead a rigid system due to insufficient modularization.

    Unit testing strategies

    There are strategies used when creating unit tests to ensure coverage of all test cases. Some of these strategies include error handling and numerous checks such as logic, boundary, and object oriented. Boundary checks and error handling are similar in the sense that they both check the behavior of the system based on inputs that are invalid/outside the expected input range. Object oriented checks ensure that the state of persisted objects are updated correctly. Lastly, logic checks ensures that the system performs as expected given a valid input.

    Benefits of unit testing

    A major benefit to unit testing is the increased efficiency when testing code and discovering bugs. Whenever the system code is changed, the same set of unit tests are run. If a test fails, it is easy to identify what caused the failure because tests are small and isolated. Therefore, unit tests help catch any bugs before the system reaches production. Another benefit to unit testing is unit tests act as another form of documentation. Unit tests act as documentation because developers can read the tests to see how to code should behave. Having accurate documentation is an important part of software, so that other developers know exactly what the expected behavior of the code is.

    Conclusion

    This article was chosen because I enjoyed that it explained when unit testing is less beneficial unlike other resources. This allowed me to understand when unit testing should, and should not be used. I enjoyed learning more about unit testing outside of class as it is such as integral part of software development. Therefore, I plan to implement unit testing in future projects to ensure system accuracy.

    Resources:

    https://aws.amazon.com/what-is/unit-testing/#:~:text=Unit%20testing%20is%20the%20process,test%20for%20each%20code%20unit.

  • CS-448: Sprint Retrospective

    ztram1

    Sprint 3 Retrospective

    What worked well

    The issues the team had made for this sprint were larger in scale, but broken into smaller issues. This was done mainly to have enough issues for everyone to work on. However we found that working together during the scheduled class periods led to greater success rather than working on the issues individually. The team utilized mob programming in order to complete many of the issues for sprint 3. We preferred this approach because some of the issues were dependent on other issues being completed first. Therefore each member would have to wait until the previous issue was completed to work on their issue. Because most of the team members had little experience with the topics related to the issues we worked on, mob programming was also beneficial in allowing us to problem solve together.

    What didn’t work well

    One thing that did not work well was how the team managed our time during this sprint. By the end of the sprint, the team had completed most of the issues in weight, but failed to complete all issues. The team could have communicated better to ensure we had completed all the issues before the sprint review. Although the team benefitted from mob programming, mob programming did not have to be as heavily relied on if our issues were better written. In the effort of making the issues small and concise, we may have went to far when breaking down issues. Because this was the team’s third sprint working together, we have had enough time to get used to how each other work, the workflow, and GitLab itself. Therefore for this sprint, there was more that worked well than what did not work well.

    Changes to make as an individual

    A change that could be made as an individual is to encourage others to voice their opinions on what they think should be done. As stated above, the team completed issues through mob programming which led to multiple in person meetings and discussions. During some meetings, when we would get stuck and unsure what to do, I noticed I would list ideas of what I thought the team should do. Rather than always voicing my opinion, I would make the change of asking the other team members what they thought was the best plan to solve the current issue. This change would help everyone feel that they are included in the discussion and voicing their opinion is encouraged.

    Changes to make as a team

    As a team, a change that could be made is having better time management and keeping better track of important dates. As mentioned previously, the team failed to complete all issues from this sprint. This was partly due to the team thinking we had another in person meeting to continue working on our issues. This could have been avoided if we had been more on track with due dates. There were times where a team member did not communicate well resulting in missed meetings and confusion. A change the team could have made is to work with each other so that everyone stays on task and does what is necessary to forward the team’s progress.

    GitLab Activity

  • CS-448: Week 12

    ztram1

    The Deep End

    “The Deep End” pattern is about feeling unsatisfied with the path taken when learning new skills. The path taken has been small, safe steps that has made the learning process plateau. A way to jump start the learning process is by challenging yourself with bigger things such as bigger projects, working with larger teams, more complex projects, etc.

    A solution to this pattern is to jump into the deep end, rather than waiting until you are ready. This is because the latter can lead to never starting anything, or challenging yourself to learn new skills. When a difficult problem occurs, rather than shying away, diving into the deep end and facing the problem head on is what will help in the long run. However there are some risks that are involved with going straight into the deep end. A risk is that you may get overwhelmed and fail. Although you may fail, failing is not necessarily a bad thing. Being prepared to fail, and recovering is what drives growth and provides opportunities that would be lost if the risk was never taken in the first place.

    As mentioned before, in order to grow, bigger projects need to be made as a way to challenge yourself. Previous project’s size can be quantified by looking into those previous projects and marking down how many lines of code was written with how many developers. After reviewing all previous work, a chart can be made to see where how the next project compares.

    Conclusion

    I enjoyed reading about this pattern. I found the action to the pattern to be interesting because creating a chart, representing the size of your previous work, is something I would not have thought to do. However that process can be useful when determining if a project is at a large enough scale that can challenge previous projects. The pattern has changed the way I think about failure and taking risk. I like how the pattern paints the potential of failure as something that should be invited because I feel that failure is something that is not normally deemed acceptable. The pattern has ultimately changed the way I think about taking risks because risks and recovering from failures are what key to growth.

  • CS-443: Week 15

    ztram1

    Performance Testing

    Performance testing is the process of evaluating how a system performs under specific workloads. Responsiveness and stability of the system is monitored by examining the speed, reliability, and application size. Common indicators that are used for testing are network response times, number of users the system can handle at a time, processer memory consumption, and more.

    Performance testing is an important part of the software development process. If an application is not tested before being released, users may have a negative experience because of errors that could have been found in the performance testing phase. Users that have a negative experience may be deterred from using the application in the future resulting in fewer overall users. Performance testing aims to find these errors before release, so users can have the best possible experience

    When is performance testing done?

    In software development, there are two main phases: development and deployment. Development testing focuses on individual components such as web services, APIs, and microservices. The earlier development testing begins, the earlier errors can be caught. Catching these errors early in the development phase is important because as the code base progresses, there is more and more code building on top of code that may have errors. This can make fixing the error more complicated. As the application becomes larger, comprehensiveness of the tests should also scale alongside. However, the application may get to a point where testing in the development phase becomes unreasonable and testing is done during the deployment phase. This happens when testing involves replicating a production environment, but recreating the environment is too difficult or expensive.

    Types of Performance Testing

    There are many types of performance testing that are done throughout the development process to verify the application performs as expected and can meet user requirements. Some of these performance testing types are:

    • Load Tests – Tests the application under a realistic load by simulating virtual users. Response times are monitored, which can reveal potential bottlenecks to the system’s performance.
    • Stress Tests – Similar to Load Tests, but the number of simulated virtual users is greatly increased. This is to see how the application runs when under peak activity.
    • Soak Tests – Tests are conducted over an extended amount of time, as opposed to the tests mentioned above. This test is to evaluate how the system performs when under intense loads for a prolonged amount of time.

    Conclusion

    This article was chosen because it covered a variety of topics within performance testing, so I was able to gain a general understanding of what performance testing is. Performance testing is an important process in software development because it finds potential weak spots in a system. These weak spots can come from slow response times during peak activity, long load times, etc. Therefore, performance testing should be done on all systems to improve the user experience. In the future, I intend to look further into performance testing tools and frameworks to see how I can implement them in later projects.

    Resources:

    https://www.tricentis.com/learn/performance-testing

  • CS-448: Week 11

    ztram1

    Confront Your Ignorance

    This pattern is about confronting your ignorance. After going through the “Expose your ignorance” pattern, where you identify gaps in your skillset, the next step is to confront those gaps. The main problem that comes from this pattern is that there are techniques and tools that need to be learned, but the process of actually learning these techniques in unclear. Some of these may be techniques that everyone already knows, so there is an expectation that everyone be competent in that area.

    The solution to this pattern, with the list generated from “Expose your ignorance”, is to pick an item from that list and actively fill the gaps for that item. How this can be done is a matter of preference. Some prefer to research everything they can about a topic, such as introductory articles and forums. Others prefer a more hands on approach by going straight into the topic by building a simple project. Although confronting your ignorance is mostly an individual task, asking mentors and experienced people is important to learn what information they can share with you. Asking mentors can also be beneficial as they may have learned tricks that they found themselves that may not be discoverable through documentation.

    As mentioned before, this pattern is do be done after exposing your ignorance. Exposing your ignorance is a critical step because it makes the gaps in your knowledge public, which makes your team aware of those gaps and your learning ability. Having your gaps be on display for your team encourages an environment where failure and learning are acceptable as they both play a large role in an apprentice transitioning to become a journeyman and so on.

    Conclusion

    This pattern is helpful to me because confronting my ignorance is something I struggle with at times. The pattern states that exposing your ignorance without confronting can lead to excessive humility and helplessness which are feelings I have had in the past, so this pattern helps to give some encouragement to start confronting that gaps in my knowledge. After reading the patterns “Expose your ignorance” and “Confront your ignorance”, I feel much more confident in the future on how I can improve my skills in a methodical manner.

  • CS-443: Week 14

    ztram1

    Behavior-Driven Development (BDD)

    Behavior Driven development is an approach where the focus is set on the behavior of an application for the purposes of a business. This focus is to find a common ground between developers, quality assurance teams, and business professionals. Common ground is found by defining behaviors that are written in plain language, allowing everyone to understand and agree upon the software’s behavior.

    BDD Process

    Behavior driven development begins with defining behaviors in “feature files” which are used throughout the development process. Behaviors are straightforward statements that outline a specific process in a predetermined format.

    Behaviors are written in a language called Gherkin, which use simple words such as “Given”, “When”, and “Then.” An example behavior would be, “Given the user enters an incorrect password, When they click the login button, Then they should be prompted with an error to reenter their password.” These behaviors are turned into tests with tools that check if the software behaves as intended. Because everyone is involved in this process, and agrees on the final product, confusion can be avoided.

    Advantages to BDD

    Behavior driven development leads to advantages that would otherwise be lost with other development approaches. A key advantage with BDD is better communication and collaboration. This is due to the nature of BDD as everyone from business, to quality assurance, to developers, meet together and plan everything. Because there is better communication, requirement understanding also increases. This is because requirements are explicitly defined, and everyone agrees what should be done. Due to the increase in requirement understanding, testers are made aware exactly what requirements should be tested. Ultimately the chances for the final product to be different than what was intended is less, saving time and effort.

    Disadvantages to BDD

    Because BDD is different from other development approaches, adopting the practice can be difficult. This is because teams are used to working amongst themselves, then meeting with the other teams once a final product, or an iteration of the final product has been completed. Waiting until a product has finished development before meeting the other teams can lead to wasted time and effort because what is actually delivered may be different than what the business team intended. Another reason why BDD can be hard to get used to is the overemphasis and learning curve with the tools necessary for BDD. Teams can get off track because they get caught up in learning Gherkin syntax and other tools.

    Conclusion

    This article was chosen because topics were easy to understand with the use of real world examples. Once past the learning curve, behavior driven development seems like a useful approach that fosters strong collaboration and communication. I was unaware of tools like Gherkin and Cucumber that are used to process the feature files, so learning about them was interesting. This approach is unlike others I have seen in the past; however, I am curious about how is all works. I will be looking into these tools in the future.

    Resources:

    https://www.browserstack.com/guide/what-is-bdd

  • CS-448: Sprint 2 Retrospective

    ztram1

    Sprint 2

    What worked well this sprint

    Sprint 1 was a good opportunity for the team to become familiar with each other, how we like to work individually, and the general workflow that we were to follow. After Sprint 1, Sprint 2 was much easier in terms of knowing what the team wanted to accomplish and how to accomplish it. During this sprint, we continued our weekly meetings because it was a good way for everyone to go over what was done the past week, and what needed to be done for the current week. Last sprint, we ended up leaving all of our merge requests open until the end of Sprint 1 which resulted in many conflicts which created extra work to resolve those conflicts. This sprint we decided to review and merge as issues are completed rather than leaving them until the end of the sprint. Reviewing as issues are completed helped the team to avoid merge conflicts.

    What did not work well

    Throughout the sprint, the team had issues that were dependent on the completion of other issues. An example of these issues were when the team were adding to the AddInventoryFrontend. The goal of the issue was to implement the functionality of actually adding inventory to the database which required multiple components to be added such as text fields, buttons, etc. Because the team as a whole had limited experience with frontend work, we spent time together researching implementation. When spending time together for research, we realized that implementation would be easier with the approach of mob programming. Utilizing mob programming rather than each of us being assigned an issue and completing individually helped save time. This is because if we were all assigned an individual issue then we would have to wait until the first person finishes their issue, then the next person could start their issue, and so on. Each of us would also have to pull the changes the previous person made. This process seemed inefficient, so the team decided to group the issues together and do them at once in one meeting where everyone was present.


    Last sprint we also came across problems where there was miscommunication about when we would be meeting, which we aimed to resolve this sprint. However we still faced attendance issues regarding the team’s weekly meetings.

    Changes to make as a team

    One change that we tried to resolve last sprint was the issue of some team members not attending the weekly meetings. Unfortunately this issue was not fully rectified. In hopes to settle this issue for the next sprint, the team should have a discussion to clearly restate expectations which were initially defined at the beginning of the semester.

    Changes to make as an individual

    A change that could be made as an individual is having a better grasp of what needs to be done. Mainly due to having spring break in the middle of the sprint, there were a couple instances where I would forget a standup message to inform my team on the progress I have made individually. Although this sprint was longer than the previous, it actually felt shorter to me because of spring break and canceled classes which contributed to me having to rush at the end of the sprint to get my work completed in time. I plan to manage my time better, so this does not happen for Sprint 3.

    Activity on GitLab

Design a site like this with WordPress.com
Get started