Author Archives: Austin Engel

Use the Source Luke – Apprenticeship Pattern

In this post I will be discussing the apprenticeship pattern, “Use the Source” written by Adewale Oshineye and Dave Hoover in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, 2009. This pattern is for people who have not developed in environments that have stressed the importance of the ability to read source code. Developers often spend much more time reading source code than actually writing it. Often times developers cannot understand the code and have to rewrite it themselves. As stated in the book, Bill Gates once said, “one of the finest tests of programming ability is to hand the programmer about 30 pages of code and see how quickly he can read through it and understand it”. People who can absorb design patterns, algorithms and data structures through real code become great programmers because they are learning from every good programmer each line at a time.

The authors suggest picking an algorithmically sophisticated open source project and take note of the algorithms, data structures, and design decisions made in the code that are new to you. Then, write a blog post for each new idea you learned. While doing this, download the lates version of the project and try to work out why the developers made certain decisions in the design and architecture and try to work out ways you would have done it. Figure out if your way wouldn’t work or would actually be a better solution. This will cause you to think deeper about the reason the project is coded the way it is.

I found this design pattern very interesting because I would agree that the ability to read code is very important and my lack of experience doing so has caused me lots of problems in the past. Often times I have had to rewrite code I was not able to understand or attempt multiple times to understand a piece of source code before finally getting it. I would say that I have improved, but there is still lots of room for improvement in the future. I like the idea of examining open source projects and I think I will do so very soon.

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.

The Deep End – Apprenticeship Pattern

In this post, I will be writing about “The Deep End” apprenticeship pattern from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Adewale Oshineye and Dave Hoover, 2009. This apprenticeship pattern is for software craftsmen who feel that they need more experience and need to be challenged by complex problems and bigger projects. This pattern suggests that these people jump in at the deep end and just go for these challenges.

Waiting until you’re ready for too long can turn into never taking that next step and therefor never moving ahead. Rather than a plateau where you are consolidating your skills, you can end up in a rut where your lack of growth turns into mediocrity. This book suggests when offered a high-profile role, difficult problem, or large project, accept these offers. Even if you don’t feel ready, there is a reason these opportunities are available to you and you should take these opportunities and hold on tight. As the authors stated, “risks are opportunities seen through half shut eyes of fear”. Growth can only happen when you take on scary, challenging jobs. This does not mean lying to get a job you cannot do or not prepared for as you will definitely be in over your head. It means taking the opportunities as they are presented to you.

An action suggested by the authors to help you get started with this pattern is to think about your biggest most challenging projects. Write down the complexities of these projects as a reference for your new projects. Answer questions such as “what is the biggest codebase you have ever built on your own?” and “what is the biggest, most successful project you have ever worked on?” in terms of number of developers and size of the project. Find a certain way to use these questions on all of your past projects to use them as a metric or index and write it down. This will help you gauge where your next projects fall compared to you past ones. Using this chart or diagram will help you figure out which way your career is going and whether you are growing as a developer.

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.

Breakable Toys – Apprenticeship Pattern

The “Breakable Toys” apprenticeship pattern, written by Adewale Oshineye and Dave Hoover in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, 2009, is about creating projects on your own in order to learn from them. Experience is more often built through failure than success.

Sometimes, in the workplace, it is not acceptable to fail when people are depending on you. This places a pause on your learning. As the book explained, 3-ball jugglers will not be able to step up to juggling 5-balls without trying and failing first. Only the jugglers who keep trying and failing will be able to move up to juggling 5. This is the same with software development and why the authors recommend you make “breakable toys”. This means creating your own projects on your own time that are fun to work on. During the development of these projects you can fail and not hurt or let anyone down. This allows you to grow and improve your skills.

The authors recommend building a wiki as it helps you “record what you learn” (see my other post) and also teaches you a deeper understanding of web development such as HTTP, REST, data migration and concurrency. This is a great way to learn about web environments. It recommends starting small with just an interface, then as your skills improve you can experiment with things such as tagging and ranking algorithms. Another recommendation is to build a new game every time you learn a new language. These are simple games such as tic-tac-to, Tetris, or Snake. This will help solidify your knowledge of the new language. These projects are meant to be low risk to allow room for failure, and also to be fun. If it is not fun, another project will gain your attention and the one you are currently working on is going to gain dust.

The main point of this pattern is to create opportunities to venture outside your boundaries. If you are stuck only doing what you know then you wont learn anything new. When learning something new, often times you will fail. It is the best/only way to really learn.

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.

Sprint Retrospective 3 – Thea’s Pantry

The third sprint went fairly well. For the third sprint I did most of the backend from the get request endpoint to the response that returns the CSV report. To do this I first created the endpoint which gets two query strings from the request: start and end date for which I use as a date range for the data to put into the report. I then send the query strings over to the Report module which has all of the functions to create the report. In this module I first turn these query string dates into ISO dates and then query the guest and inventory data collections for any records between those dates. Then I make it search both object arrays returned by each collection for matching IDs and merge each of those objects with matching IDs into one object in an array. Then, turn that object array into a string with CSV format, have it create a file once that is done with the CSV text, and send a response back to the front end with a download of that file. After creating methods to do all of that, I connected the backend with Haoru’s beautiful front end and tested the system fixing any bugs.

What worked well this sprint was my gained knowledge and experience with Node.js and MongoDB. This allowed me to complete more complex operations with them and create what was needed. Because of this, I was able to finish most of the backend conforming with most of the requirements. Also what went well was how smoothly it integrated with Haoru’s front end, only needing a few tweaks, I wasn’t sure what to expect initially.

What didn’t work well was our teamwork. I would say that our teamwork depreciated since our last sprint due to the amount of work that was needed to get done. Since we all had stuff to do we didn’t have much time to merge everything together. For example, Derin worked on dockerizing our application, but needed more discussion to put it all together than either of us had time to give. Another example was with Migena’s keycloak system, where again, there wasn’t enough time to merge with the main application. Our production was higher than last sprint but at the cost of communication.

What we could have done better as a team was time management. Since we sacrificed how much we got done last sprint in order to work on teamwork, we had a lot of work to do this sprint. If we had organized our time a little better we could have had more time to combine our work this sprint and as a result would have a more complete system.

What I could have done better this sprint would have been to take some extra time to work with Migena and Derin. We came very close to our goals for the end of the semester, with one more sprint I believe we would easily have finished the base idea of what the system would be. Although I was very busy with the backend, I’m sure it would have been doable to combine our progress if I we took an extra 2-3 hours over the course of the sprint.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend – link to the main application with the modules spoken about in this post.

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.

Sprint Retrospective 2 – Thea’s Food Pantry

The second sprint definitely improved from the first sprint. In this sprint we mostly worked on the Message Queue, sending and receiving JSON data and then inserting it into a local MongoDB database. We did this with RabbitMQ and the ampqlib Node.js package. To do this we first created sample JSON objects then stringified these objects in order to send it to the message queue. Then we pull them off the message queue with our receive module, parse the string back to JSON, and send it over to the Insert module where we then put a timestamp on the data and insert it into the database. I also designed the endpoints and researched how to put JSON data into a CSV formatted file for the report.

What worked well was our teamwork this sprint. Me and Derin worked together to make the send and receive files, changing them to send to two queues, and deciding how we were going to do it. I would say that the teams teamwork has improved greatly from the first sprint where we all kind of did our own thing. This sprint we took the time to communicate and combine our knowledge to get stuff done.

What did not go so well was our production rate. We did not get a whole lot done, as we only worked on the message queue. This could be partly due to getting used to working with others as we had to focus more on communication than work. This means that we did not get to work on dockerizing our application, working with Migena to integrate our keycloak system, or any other of the backend functions such as the endpoints.

Changes that can be made include improving our teamwork/communication skills, everybody should learn at least an overview of the other technologies even if we are not the people implementing them, and communication with the other teams as well. We still do not know the data that will be sent to us, how we will connect our containers together etc. The last thing we should change is our productivity rate. Designing the endpoints and working on the message queue is not enough work for the sprint. There is still a lot to be done and only one more sprint left to do it. For the third sprint, we will all have to pick up the pace to get it done.

Changes I can make as an individual would be making an effort to communicate with the other teams, learning technologies I will not use directly such as keycloak, and communicating with Migena and Haoru to combine the backend with frontend and the keycloak system. I think it would be extremely beneficial for me to at least learn how keycloak works so that I can properly work with Migena to implement it into the whole system. A last thing I would change as an individual would be to take more time to understand Docker as I will be using it in the third sprint to containerize our application. I do not have a great understanding of it just yet.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/tree/main/src/subProcesses

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.

Automated Testing

Automated testing is a great option for repetitive tests such as regression and functional testing but not useable for testing methods such as discovery and usability testing that requires a human to do the work. If used correctly, automated testing can save a lot of time and therefore money. If used incorrectly, it could end up costing more than manual testing.

Certain requirements that the testing process to be automated must meet are that it is repeatable, determinant, and non-opinionated. The first requirement, repeatable, means that it must be ran more than once, or else there would be no reason to automate it. Repeatable tests have three steps: set up the tests with data and environment, execute the function and measure the result, and clean up the data and environment after testing. The second requirement, determinant, means that the outcome will be the same every time the function runs with the same input. For example, when inputted 1 and 2 to an addition function, the outcome 3 must be produced every time it is ran with those inputs. The third requirement, non-opinionated means that there must be a concrete answer. You cannot automate opinionated feedback.

Now that we talked about the requirements of automated testing, now we will discuss the three steps of automated testing: prepare, take action, and report results. In the first step, prepare, you set up the data and test environment where the tests occur. This will require either manipulation of the data or putting the program in a certain state, or both. The second step, take action, the driver will run the tests. This will happen by calling the code directly, or accessing a programs api or user interface. And lastly, report results. The automated system will record and report the results from the test.

When used properly, test automation can save money and time and provide quality test results.

Source:

Testim. (2020, February 03). What is test automation? A simple, clear introduction. Retrieved May 03, 2021, from https://www.testim.io/blog/what-is-test-automation/

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.

Code Reviews

Code reviews are one of the most productive components of software testing. What is code review? Code review is the processes of systematically checking a fellow programmer’s code for errors to prevent bugs and identify potential trouble spots such as scalability issues and buffer overflows.

Not only do code reviews save time and money in the development process, it also provides irreplaceable education to junior developers that they would not be able to obtain otherwise. This give an opportunity for Senior developers to demonstrate how to write clean code, identify problems such as memory leaks, and use shortcuts through real world application.

Some insights about code review found through analyses of the process suggest that each reviewer should only be looking at 200 – 400 lines of code per hour, authors should prepare the review with annotations and explanation of the code, and reviews should only last an hour at a time. With 200-400 lines of code reviewed and only 60 minutes at a time for each review ensures that the detection quality and rate stays high. After those marks the quality starts to drop. Annotations and explanations of code makes the author review it himself first, and then sets it up for the reviewer to understand later.

Code reviews can be done in many approaches and do not have to be long drawn out processes unless working on a software that cannot have any errors where someone’s life will depend on it. Some lightweight approaches include pair programming, sending out code through email threads for peers to review, and tool assisted review. Tool assisted review is one of the most useful. In this approach, you use a code review tool that allow the reviews to happen non-locally and asynchronously, with comment and solution tracking, notifications, and more.

Source:

What is code review? (n.d.). Retrieved May 02, 2021, from https://smartbear.com/learn/code-review/what-is-code-review/#:~:text=Code%20Review%2C%20or%20Peer%20Code,like%20few%20other%20practices%20can.

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.

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.