Author Archives: Austin Engel

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

https://www.guru99.com/unit-test-vs-integration-test.html#:~:text=Unit%20Testing%20test%20each%20part,see%20they%20are%20working%20fine.&text=Unit%20Testing%20is%20executed%20by,performed%20by%20the%20testing%20team.

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.

Set-up Task #5

One thing that I liked about the website is the content under the vision and mission subheadings on the Libre Food Pantry About page. I like and find it interesting that it both teaches and helps the community by enhancing computer science education while providing free software for local food pantries. All while showing that free open source software can be used for social good and help society. The new website is easier to use than the old one and looks better as well. The layout looks cleaner and it is easier to find things. I find the switch for changing night and day mode in the top right corner useful/enjoyable.

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.

Introductory Blog Post CS-443 & CS-448

Hello, my name is Austin Engel. I have already made a blog for previous courses so this is my new introductory. I am a senior at Worcester State studying computer science and am very excited to start my last semester and learn important topics before graduating in May.

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.

AngularJS

This post today is about AngularJS based off of the article AngularJS-Overview by TutorialPoint. AngularJS is a structural framework for dynamic web applications that was developed in 2009 by Misko Hevery and Adam Abrons. Its latest version 1.2.21 is now maintained by Google. AngularJS lets you use HTML as a template language and then allows you extend the the syntax to express application components. It is a framework used to build large scale and high performing applications that are easy to maintain. General features include that it is open source and licensed under Apache license version 2.0, it is an efficient framework able to create Rich Internet Applications (Web apps that are able to perform the normal features and functions of normal applications), provides an option to write client side applications using Javascript under an efficient Model View Controller method, and AngularJS is cross-browser compliant so that it automatically handles JavaScript for each browser. The advantages of AngularJS are that it has the ability to make single page applications in a clean way, provides data binding capabilities to HTML giving it a responsive experience, it is unit testable, uses dependency injection, gives the ability to provide more functionality with less code, and it can run on all major browsers and smartphones. The disadvantages are that it is not secure and not degradable. Since it is a framework that is JavaScript only, it is not safe so server side authentication is a must. Also since it is all JavaScript, if the user disables it, the webpage would show nothing but the basic page.

This relates to class because we were looking at the process and components that go into web applications. I selected TutorialsPoint because I have used it before for overviews, tutorials, and references. It has proven to be a reliable source to me so I do not have to worry about getting the wrong information. Their reviews online are typically very well rated with key words such as reliable, useful and helpful. I have found those three keywords to be true with this article. I had learned many things since I did not know much about AngularJS prior to reading the article. Some of these things include that it is very useful for single page applications and that it is not very secure. This is very useful for me to learn about because I am currently planning a single page web application project so it is an option for me to utilize.

Source: https://www.tutorialspoint.com/angularjs/angularjs_overview.htm

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.