Author Archives: Austin Engel

Sprint Retrospective 1 – Libre Food Pantry

The first sprint for the Libre Food Pantry software went very well for the most part. Since it was a spike sprint, it was mostly looking up tutorials, making sample projects, and brainstorming ideas.

What worked well for me was that I found a great tutorial on Node.js with Express which also shows you how to connect to and use a MongoDB database. This tutorial gave me a great foundation on how to run a server and handling HTTP requests. The tutorial had great explanations of why we are doing each thing step by step while other tutorials lack such explanations and just show you how to do whatever you are trying to do. From this tutorial I made a To-do list web application using Express, MongoDB, Ajax (Ajax code was provided from a source), Mongoose, and EJS(Embedded JavaScript) as practice for the Libre Food Pantry backend and also to make my skill/understanding more solid by practicing everything I learned from the tutorial. This also gave me a reference to look back on if I ever forget how to do a certain thing.

What did not go so well was my understanding of the project as a whole/how it all fits together. Studying the architecture of the project a few times did not do it for me. It took a while but learning Express, eventually asking my teammates about the technologies they are working with, how they fit in with the rest of the project and studying the architecture again after each new piece of knowledge finally helped it all click.

Some things my team and I could improve on would be to be more interactive on GitLab. By the time we made a repository to upload all of our progress, it was more than half way through the sprint. This meant that we could not review what our teammates were doing and have an understanding of our progress as a team. Also, our communication and teamwork could have improved as well. Instead of working on individual sample projects, we all should have worked together on a single sample project using everything that we learned. This would have been a better learning experience for us since that is what we will be doing eventually for the main project. We also could have had better communication with the product owner. I felt at times that not just me but my whole team was confused or stuck with what was wanted/expected from us. Towards the end of the sprint we eventually asked the product owner some important questions that really helped us move forward for the next sprint. Since we were mostly learning the foundation for new technologies this sprint it did not necessarily effect our productivity, but our motivation and confidence.

A change that I could make as an individual is to improve on communication. I felt that I did not have a good understanding of the technologies that my teammates were researching and how they intertwined with what I was working on. For example I did not understand what RabbitMQ was and what it had to do with the project when all I had to do was ask my teammate researching it to explain. Eventually towards the end of the sprint I did this and it helped my understanding of the project greatly.

Links:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Backend/NodeJSTutorial/NodeJSPractice – Repository where I uploaded files from each tutorial video.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/new-sample-project/-/tree/main/Backend/TodoListApp – Repository holding files for the to-do list web application

https://www.youtube.com/playlist?list=PL4cUxeGkcC9gcy9lrvMJ75z9maRw4byYp – The tutorial I used for my sample to-do list app.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Grey Box Testing

Black and white box testing are the testing methods you usually hear about, but what is grey box testing? You probably have done a sort of grey box testing multiple times before learning other structured testing methods. While in black box testing the code structure is known and in white box testing the structure is unknown, in grey box testing, the structure is partially known. Grey box testing is sort of a combination of both black and white box testing. For example, when testing a drop down menu in a UI that your are creating, you can test the drop down on the application then change its internal code and try again. This allows you to test both sides of the application, its representation and its code structure. This is primarily used for integration testing.

The main advantages of using grey box testing include that it combines the pros of both black and white box testing while eliminating many of the negatives for each, you get the testing and feedback from both the developers and testers creating a more solid application, and makes the testing process quicker than just testing one at a time. The saved time from this also allows more time for developers to fix these issues. Lastly, it lets you test the application from both the developers and the users point of view. Some negatives of grey box testing are that there is usually only partial access to the code so you do not have full code coverage of what you are testing and also lacks in defect identification.

Grey box testing does not mean that the tester must have access to the source code, but that they have information on the algorithms, structure, and high level descriptions of the program. Techniques for grey box testing include matrix testing – states status report of project, regression testing – rerunning of the test cases once changes are made, orthogonal array testing, and pattern testing – verifying architecture and design. Grey box testing is highly suitable for GUI, functional testing, security assessment, and web services/applications. Grey box testing is especially good for web services with their distributed nature.

Sources:

Gray box testing. (2021, January 31). Retrieved April 02, 2021, from https://en.wikipedia.org/wiki/Gray_box_testing

What is grey box testing? Techniques, example. (n.d.). Retrieved April 02, 2021, from https://www.guru99.com/grey-box-testing.html

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Rubbing Elbows-Apprenticeship Pattern

In this post, I will be writing about the “Rubbing Elbows” apprenticeship pattern from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Adewale Oshineye and Dave Hoover, 2009. This pattern is for people who typically work alone when it comes to developing software and feel as if they had reached a plateau, not learning superior techniques and approaches.

The Rubbing Elbows apprenticeship pattern suggests that in order to cure this, you should work side-by-side with another software developer to complete hands on tasks. This can help you learn things that cannot be taught in a classroom or online. This is because you will pick up on certain micro-techniques that you can only really obtain through experience or being around/working with another developer. These techniques can add up, providing a significant increase to your skill. An example of this pattern given in this book is pair programming. When used correctly, it can be one of the best ways to learn. Pair programming (especially with a mentor) can help you pick up other skilled developers’ habits and lets you observe how they polish those habits to improve their own skill.

If you do not have this opportunity at your workplace, the book suggests that you find someone who is interested in contributing to open source projects. It suggests you should take one night a week to work with this individual on the project in a sort of pair programming manner, learning from each other as well as motivating each other.

I completely agree with what this pattern says. Working together with someone on a project or tasks, side-by-side, especially with someone with greater skill can greatly boost your skill, and exposes you to certain things that you cannot be taught directly. Not only with coding, but with other hobbies in my life, being around others really helped me pick up on things quicker. For example, I started snowboarding last year. I had three friends who I would primarily ride with, two extraordinarily better, and one the same skill level. I had been motivated by the one the same skill level, and learned from him by observing certain techniques and habits that helped him improve. I had also picked up certain styles, techniques and habits of the ones already at a high skill level, boosting my knowledge and understanding. Now a year after starting this new hobby, I am more skillful than 70% of people on the mountain(not to be smug). This is greatly because of going with my peers.

Hoover, D. H., & Oshineye, A. (2010). Apprenticeship patterns: Guidance for the aspiring software craftsman. Sebastopol, CA: O’Reilly.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Share What You Learn -Apprenticeship Pattern

The “Share What You Learn” apprenticeship pattern, written by Adewale Oshineye and Dave Hoover in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, 2009, is about sharing your knowledge. This is for software apprentices who have solely focused on their own growth/improvement. Sharing what you learn can benefit yourself as well as others. This is because it helps you learn to communicate what you know effectively, but also helps people who are on the same path as you, trying to learn the same things.

Maintaining a blog, tutorial channel, etc. during your early apprenticeship years can be great for your growth as a developer. You may feel like you only have a basic understanding of some topics that you have just learned, but this may benefit others more than you would think. As the book states, your basic understanding will translate to an easy to understand, straight to the point article, blog post, etc. that will help other apprentices who are right behind you in the journey to becoming a master. So don’t think that you need to leave it to someone who has an extreme in depth understanding of the topic, often times what they will give back to the community will not be as beginner friendly. You must be careful when sharing knowledge though and make sure that you are not spilling a companies secrets that can ruin your relationship with your team or get you in legal trouble.

I like this apprenticeship pattern in particular because it benefits yourself and others at the same time. Teaching is a great way to learn for both the teacher him/herself, and the student/learner. A certain part of this pattern really caught my attention and that is to not worry about leaving these posts/tutorials to people who have greater knowledge of the topic. Often times when learning something new, I will go to forums rather than tutorials. On these forums you can often find threads where students are asking the same questions about a topic that you are wondering yourself, and a lot of times other students will respond to these questions with their understanding of the topic. This is a great starting point for learning something new because often times there are basic, easy to understand, straight to the point responses that can kickstart your learning of the topic.

Hoover, D. H., & Oshineye, A. (2010). Apprenticeship patterns: Guidance for the aspiring software craftsman. Sebastopol, CA: O’Reilly.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Learn How You Fail – Apprenticeship Pattern

Today I will be writing about the “Learn How You Fail” apprenticeship pattern from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Adewale Oshineye and Dave Hoover, 2009. This pattern is for everyone. Everybody has failed at something and will again in the future. If you are not failing then you are not pushing the boundaries of your capabilities, and/or you are overlooking these failures.

The problem addressed in this apprenticeship pattern is that you have enhanced your success through learning, but failures and weaknesses remain. The solution to this is to gain an understanding of the habits, behaviors, and patterns that has led you to failure. With self knowledge, you can make conscious choices to avoid these behaviors/habits or to break them and give you an idea of your limitations. As explained in the book, This can help you make a decision whether to fix a problem or cut your losses. If something is going to be a disproportionate investment of time and money only for a small improvement, it may be time to improve on something else instead. Excepting your limitations is important, seeking for perfection will only disappoint. This could mean letting go of some areas of expertise that cannot benefit you as much if you do not have the time to maintain those skills.

A method recommended by the author is to keep a list of your current skillset and boundaries. This way you can have an organized view of these boundaries and decide which areas you would like to push/explore. I found this interesting because it is similar to the “Record What You Learn” design pattern that I had written about in my previous post. By writing down your experiences, you can gain a greater understanding of what is happening. This way you can grow as a developer. Writing down your habits, actions and patterns which cause you to fail, can help you move forward from the endless loop of repeated actions leading to failure. I like this pattern because it accepts that you will fail sometimes, but whats worse than failing is to not push your boundaries. This pattern helps you understand and map out your boundaries so you can push them in an organized, thoughtful way.

Hoover, D. H., & Oshineye, A. (2010). Apprenticeship patterns: Guidance for the aspiring software craftsman. Sebastopol, CA: O’Reilly.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Record What You Learn – Apprenticeship Pattern

In this post I will be discussing the apprenticeship pattern, “Record What You Learn” written by Adewale Oshineye and Dave Hoover in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, 2009. This pattern is design towards people who end up learning the same lessons over and over again or going through the same experiences or failures but can never get the details or reasons to stick.

The solution suggested is to create a blog, notebook, or wiki that you can treat as a journal and record important things that you learn. This is not to write down and forget about. Throughout your career you should return to this journal to review it and make new connections in your memory. When reviewing you should update what is written as more knowledge and experience is accumulated over time. The authors even suggest creating two blogs, one a public record and one a private. This allows you to share the lessons you have learned and also get feedback on what you have written with the public record and be able to be brutally honest with yourself in the private record. Internal and external feedback allows you to have an honest and accurate self-assessment. The main goal of this pattern is to keep a journal of your path to mastery so that you can reflect on and learn in the future.

I found this particular apprenticeship pattern interesting because this morning I was thinking about starting a notebook in which I can keep any important lessons as well as important details. This way I would be able to look back on it frequently and grow as a developer. This could include important concepts, design patterns or failures that I can learn from as I move forward. This book has provided a useful structure in which I can follow and also has inspired me to follow through with it since I have said I was going to do it a few times already but never have. Also, it has given the idea of two journals in which one can be private and one public. Maybe also different journals for different topics such as one for design patterns, one for lessons learned, one for important topics, etc.

Hoover, D. H., & Oshineye, A. (2010). Apprenticeship patterns: Guidance for the aspiring software craftsman. Sebastopol, CA: O’Reilly.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Static vs. Dynamic Testing

In this post I will be talking about what static and dynamic testing is and how they differ.

Static testing’s objective is to find and prevent any errors in the early stages of a software’s development. This sort of testing is done without execution of the code. Some methods of static testing are manual and/or automated reviews of the code, requirement documents and document design. Some examples of the documents reviewed in this stage are test cases, source code, user documents and web page content. This is primarily verification.

Dynamic testing’s objective is to check the functional behavior of software, how it conforms to the business requirements and fix any errors that have been found. Its system, its usage and its performance are tested through execution of code. This sort of testing is done at any stage of the testing life cycle and can be white or black box testing. Most of the time it is validating the outcome is what is expected.

Some key differences between the two types of testing are that in static testing you do not execute the program, you analyze and review the documents and code. In dynamic, you execute the program and analyze the behavior. The goal of static testing is to prevent defects when developing the software while the goal of dynamic testing is to fix the defects. The costs of finding defects in static testing is less than of dynamic testing and the return on investment for static is greater than of dynamic. This is because of the development stage that each are executed in. Since static testing is done in the early stage before compilation it is preventing before it happens. Since dynamic is performed at the end of the development stage, you are only fixing technical debt.

Techniques for static testing include technical reviews, inspection, code reviews, and walkthroughs. Techniques for dynamic include unit testing, integration testing and system testing. Ultimately, static testing involves some sort of checklist and process and dynamic testing includes test cases and execution.

Source: https://www.guru99.com/static-dynamic-testing.html#:~:text=Static%20testing%20is%20about%20the,testing%20is%20performed%20after%20compilation.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Sweep The Floor

This post will be about the “Sweep The Floor” apprenticeship pattern from the book, Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. This pattern is about finding your place on your team, contributing to the teams work to earn their trust and respect, and growing as a developer. The pattern suggests taking on the undesirable peripheral tasks when joining a new team/project. This will help you learn more about the project, development as a whole, and will keep you away from the core of the project. These tasks are often overlooked in education so this can help you fill in the gaps of education while working on something low risk. This does not mean lack in quality though. keep good quality, as bad quality on these portions of the project can become troublesome later on.

There are some problems with this pattern mentioned by the authors that I agree with. One is that you may become the guy who they use to do such dirty work, lacking in opportunity to work on more challenging tasks. Another problem is that you may become intimidated by anything that isn’t the easy yet boring work. Although you learn from this work, there becomes a point where you start to plateau from lack of challenge. The authors solution for these problems are to advocate for yourself and look for every opportunity where you can show them you are capable of contributing to higher tier work. Showing them enthusiasm and skill should make them realize that you are ready and capable to move on to more skillful tasks.

I found this useful because everyone has this starting point where they’re at their first job in a profession and need to gain the trust of their team members. Showing them that you are there to contribute can go a long way and nothing shows that better than when you do the tasks that no one wants to do. Although I already had an idea of this, the book really gave me a solid idea of what to expect to do at my first job as a developer and how to get my team to welcome me.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Unit Testing vs. Integration Testing

The basic idea of unit testing is that you are testing individual units of source code that you have written to see if there are any bugs. Usually the code is deterministic so there are set outputs. The idea of integration testing is to test how a group of modules in your application are working together including how external dependencies are working with the code. This usually involves testing something that is non-deterministic in the application.

Integration testing usually comes after unit testing and is the more expensive to maintain. While the developers will run the unit tests, integration tests are usually required to be ran by a test team. This is partly due to the difficulty in finding errors in integration tests as well as the time it takes.

Integration testing is black box testing which means you are testing the inputs and outputs of the interface. An example of an integration test would be checking the interface to see if you are brought to your profile home page when you enter your username and password. Unit testing is white box testing so you are writing test cases for certain functions to see if they perform correctly. An example of a unit test would be writing a JUnit test case to test the deposit() method and assert that when you make a deposit of $50 to your bank account object (with initial balance of $0) that your balance is now at $50.

The main takeaway is that integration testing tests the interface and how multiple modules work together while unit testing is testing the source code of one function. Unit tests are done in early development while integration tests are done after you have some sort of product complete.

Sources:

https://www.guru99.com/integration-testing.html#3

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns

The book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye gives great solutions/patterns for problems often faced by software developers, mainly apprentices or beginners of the craft. I have enjoyed reading up to where I have gotten so far (Chapter 1 plus 2-6 introductions) and it has taught as well as clarified many ideas and methods. One thing I have never thought of is how your first language will affect how you will think and learn other languages in the future. While this may be the case, the more diverse knowledge you have, the more you will improve upon this fact. For example (given by the book), people who are more comfortable with object-oriented languages should explore functional languages. This will broaden your understanding and problem solving. Another pattern I found interesting was the Be The Worst pattern. This discusses your environment and its relation to your growth. Being on a team where you are the best or most skilled does not give you much room or motivation to improve as you will not be learning from your peers. It suggests keeping yourself in an environment/team where you are the least skilled. This forces you to catch up to your teammates so that you don’t hold them back as well as forces the habits, ideas, and information of your higher skilled teammates upon you. A few patterns that addressed things I already “knew” but clarified the process at which I should take are Expand Your Bandwidth and Reading List. If you want to be a software developer then you should already know that you will be constantly learning. Expand Your Bandwidth gives solutions on how to learn more than what your job teaches you. It gives examples such as joining online academic courses, following influential developers on social media, contacting authors and more. This gives you a starting point from which you can come up with your own ways of learning or just to boost you in the right direction. The other pattern, Reading List, gives great methods on organizing your book backlog. The first suggestion is to not only keep a list of books you wish to read but the ones that you have read as well. This allows you to keep track of the books you’ve read from which you can review and find gaps or trends in your learning. This can direct you/help decide what you should read next. The pattern also suggests that you keep your book list as a priority queue. If you find a book on a topic that would be more useful or has a higher urgency then put it at the top of the list. If the bottom of the list gets to the point where you will probably never read the books in those spots then thats okay because it clearly is not a priority. I like the way this book structures these patterns too. The authors organize these patterns into Context, Problem, Solution and Action. This makes it easier to understand rather than if they were just put into normal paragraphs.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.