On this Software Development Capstone journey part of my assignment is to choose 10 Individual Apprenticeship Patterns out of 35 patterns among Chapters 2-6 from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsmanby Dave Hoover and Adewale Oshineye. For my eighth individual Apprenticeship pattern I decided to blog about “Nurture Your Passion” pattern.

Summary

When you feel as if you have been hired into a software developer job that is asphyxiating your passion. Sometimes the best solution is to work on some side projects that you find interesting in your work place. If you can not find something interesting at work, then you can dedicate some time on the side building some “Breakable Toys”. Another approach is to ensure that you keep reading great literature in our field that will essentially help carry you through difficult times, such as ones that threatens your passion for the craft. You should also make sure that when joining an organization, that you are joining one with a career path that is related or will lead to your passion. This pattern also suggest us to make sure we “set clear boundaries that define the sort of environment you are willing to work in”. Understand that sometimes you run the risk that the boundaries you set might cause you to “get passed over for pay raises, promotions, kudos, or popularity. But these boundaries are necessary if you are going to break free of hostile conditions and keep your passion strong”.

My Reaction

This pattern helps you understand the importance of doing something you are passionate about. I agree with this idea because it make sense, we need to insure that we are nurturing our passion in order for us to remain happy and passionate about what we do. I found this pattern to be interesting but also useful and thought-provoking. This pattern has definitely changed the way I think about my profession and the way I think, the reason being is that it has made me realize that whatever I do, I should make sure it is something I am passionate about and I am always trying to find ways to keep that passion for the craft alive.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

For this week’s blog I decided to write about the chapter “Record What You Learn” from our textbook of software apprenticeship patterns. The context of this pattern is that you learn the same lessons/ideas/things over and over and over again but you never seem to retain the information or you retain it for a short period of time and then forget it. I personally find this to happen to me every so often. Sometimes in class we will learn a lesson and I will not retain the information and when it comes time to use the information we learned or to prove our knowledge of the subject on a test or examination or project (some form of graded material) I will draw a blank. This is extremely frustrating because most of the time I know that we have learned this topic and that I was in that lecture but somehow someway I have forgotten what that thing we learned is. The problem being set up by the book is this; You don’t learn from history or historical mistakes and you are doomed to this repetition of failure due to your lack of discipline to take notes or record what you learn in a way that you wont forget it. The solution to this problem is rather simple; record what you have learned. Do it in some way that sticks with you – a way that makes sense for you. Two different people might have two different ways of remembering information. Maybe I can write notes down in a journal from lecture and be all set whereas my classmate (let’s call him Jim for the sake of conversation) can’t retain information from reviewing basic lecture notes. Maybe in order for the information to stick with Jim he needs to do it hands-on a few times. Once he does it himself physically he will remember how to do it because he knows he’s done it before and has the confidence he’s done it correct in the past. I hope to improve my retention of knowledge by finding more avenues to retain my information as opposed to just relying on lecture notes.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

This is the blog call “AI at Google: our principles” by Sundar Pichai, he is Chief Executive Officer of Google. In this blog he talked about the principles of AI at Google. The main purpose of AI is to help us, its potential to improve our lives. Beyond that, AI to help people tackle urgent problems. These benefits are why Google invests heavily in AI research and development and makes AI technologies widely available to others via our tools and open-source code. This is powerful tool that mean we must be responsibility to get this right. These are seven principles to guide Google’s work going forward. They want to set to concrete standards that will actively govern the research, product development and business decisions.

Objectives for AI applications: Advances in AI will have trans formative impacts in a wide range of fields, including healthcare, security, energy, transportation, manufacturing, and entertainment. They also take into account a broad range of social and economic factors and will proceed where they believe that the overall likely benefits substantially exceed the foreseeable risks and downsides. They recognize that distinguishing fair from unfair biases is not always simple, differs across cultures and societies. They will seek to avoid creating or reinforcing unfair bias. They will continue to develop and apply strong safety and security practices to avoid unintended results that create risks of harm, and will incorporate our privacy principles in the development and use of AI technologies. AI tools have the potential to unlock new realms of scientific research and knowledge in critical domains like biology, chemistry, medicine, and environmental sciences. They aspire to high standards of scientific excellence as we work to progress AI development.

And the applications that they will not design AI for, such as weapons or other technologies whose principal purpose or implementation is to cause or directly facilitate injury to people. Technologies that cause or are likely to cause overall harm or gather or use information for surveillance violating internationally accepted norms.

Look at AI for long term, this is the technology that will stay with us in the future. There are many voices about this subject. Although I don’t have all my trust and believe in company and operation. This is the future we cannot avoid, that’s mean we have to be careful and monitor it to goes right direction. We need to set regulations and principles, I am agreed with these principles by Google. But we need to make sure that they keep their words.

From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.

Hello dear readers. In this blog post I would like to write about Refactoring, documentation and software framework. While explaining what they are I will try define why are they needed.

Refactoring is very used term in software development and has played a major role in the maintenance of software. Refactoring is one of the most self-evident processes, but it is surprisingly difficult to perform properly. In most cases, we deviate from strict refactoring and execute an approximation of the process; sometimes, things work out and we are left with cleaner code, but other times, we get snared, wondering where we went wrong. In either case, it is important to fully understand the importance and simplicity of barebones refactoring. Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations. The cumulative effect of each of these transformations is quite significant. By doing them in small steps you reduce the risk of introducing errors. You also avoid having the system broken while you are carrying out the restructuring — which allows you to gradually refactor a system over an extended period of time.

I also want to talk about documentation in this blog post. For a programmer reliable documentation is always needed. The presence of documentation helps keep track of all aspects of an application and it improves on the quality of a software product. Its main focuses are maintenance, development, and knowledge transfer to other programmers. Successful documentation will make information easily accessible, simplify the product, help new users learn quickly, provide a limited number of user entry points and help cut support costs. Documentation is usually focused on the following components that make up an application: business rules, troubleshooting, server environments, application installation, database/files and code deployment.

A software framework is a concrete platform where common code with general functionality can be specialized or overridden by developers or users. Frameworks take the form of libraries, where a well-defined API is reusable anywhere within the software under development. There exist some features that make a framework different form other library form. These features are: default behavior, inversion of control, extensibility, non-modifiable framework code.

I am attaching the following links that will help you have a better understanding of these concepts as these blog posts also provide examples.
https://refactoring.com/
https://medium.freecodecamp.org/why-documentation-matters-and-why-you-should-include-it-in-your-code-41ef62dd5c2f
https://www.quora.com/What-is-a-framework-in-programming

From the blog CS@Worcester – Danja's Blog by danja9 and used with permission of the author. All other rights reserved by the author.

Hello again, readers! Today I dove into an article by Peter Wayner detailing 5 different design architecture patterns for software design and their benefits and weaknesses.

The first is Layered architecture. This is where data enters the top layer and as it passes through each layer, the layer performs a specific task. A major benefit is that each layer is maintainable, testable, can easily be assigned roles, and are easy to update and enhance. However, this can result in the source code being very messy, the code can be slow, the whole program can be hard to understand, and changing a small part could be impossible as you may need to change the whole program.

The second is Event-driven architecture. A central unit is built that accepts all data and then delegates task to separate modules to ensure that your program isn’t just waiting around for something to happen. This allows for the program to be scalable, adaptable, and easily extendable. This can lead to complexity when testing and error handling can cause troubles in development. Essentially, the more each module is dependant on the others, the more troublesome the entire program becomes.

The third architecture is Microkernel architecture. This architecture uses a set of core operations that are repeated over and over again in different patterns depending on the data given. If needed, different modules can be tacked on to allow the program to perform different functions and patterns. The difficulty with this architecture is that getting the plug-ins and microkernels to cooperate can be tricky. There is also the trouble of not being able to modify the microkernel once plug-ins start to depend on the microkernel.

The fourth architecture is Microservices Architecture. The main idea here is to build a number of different tiny programs that will handle one specific task instead of having one big program do everything. This also allows some individual programs to be scalable up to a large size while others are kept small. Some downsides are that some tasks can’t be easily split up into a single microservice. Each microservice must also be independent or the cloud can become unbalanced. Lastly, if tasks are split up amongst several microservices, the communication costs can begin to skyrocket.

The final architecture is Space Based architecture. This architecture is designed to split up processing and storage between multiple servers. This protects against collapse under a great load. Data is stored across the nodes and information stored in RAM. This does make many simple tasks quicker but can also slow down computational tasks. This architecture can also be referred to as Cloud Architecture. The main drawback with this is that with RAM databases, transactional support is difficult. Testing the entire system can be difficult as well.

This was an interesting read as it went one step higher than what we learned in class so far. This covered the upper level where multiple programs come together while in class we cover designing a single program. The Space Base architecture was quite familiar as I learned about it in a Cloud Computing course I took earlier in the year that dealt with Hadoop. The Microkernel architecture was cool as well as I personally use Eclipse to work on in-class projects and learning more about its overall architecture is something I thought I would never dive into. The Event-Driven Architecture has given me an idea for a way to work on the final project that was recently assigned to us in class. Hopefully, it works out as putting something you learned to use is always a rewarding experience.

Until next time readers. Have a wonderful day and see you next week!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

As I take another step towards Software Quality Assurance Testing. I decide to research I topic discuss in class the other day. The topic being Mocking in testing using mockito. For this blog I will be talking about a blog that relates to my topic of interest. It’s name is “What is Mocking in Testing?” by Piraveena Paralogarajah.

This blog was very interesting and does a good job introducing to readers what mocking is and why it is used. I suggest this blog to readers with no experience or knowledge to the software framework known as mockito and/or the mocking concept.

A brief summary about the blog “What is Mocking in Testing?” by Piraveena Paralogarajah.

What is mocking?

Mocking is the notion of making “a replica or imitation of something”.

Where and why is mocking use?

Mocking is used in unit testing. It is used on object that depends on other objects in order to isolate the object by having it mock and simulate the behavior of the original object. Mocking is done using general types of mocking frameworks. A few of these framework mentioned by the blog are the following:

• “Proxy based ( eg: EasyMock, JMock, Mockito)”
• “Byte code Manipulation / Classloader remapping ( eg: jMockit, PowerMock)”

What is Proxy based Mocking? How it works?

“A proxy is just an object which will be used instead of the original object. If a method of the proxy object is called than the proxy object can decide what it will do with this call:

• delegate it to the original object
• handles the call itself”

The blog goes on and list the limits of Proxy and the fact that “proxy does not require an instance of an interface /class if the proxy handles all method invocations itself”.

What is Classloader remapping based Mocking?

Is the notion of telling “the class loader to remap a class reference to the class file it loads”.

ALL QUOTES ARE FROM THE BLOG “What is Mocking in Testing?” by Piraveena Paralogarajah. 

I enjoy the blog and also learned that there are other types of mocking frameworks not just mockito which I will have to look into more. That being said if you take the time to read the blog I am blogging about you will get more detail information on what mocking is and why it is used and a few other mocking related details such as the general types of mocking framework.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

Angular Unit Testing

For this week’s blog post I thought I would take a look at Angular Testing considering in class we have been discussing it and are going to use it for our final project. From the site I found they go into great detail as why it is good to use angular and overall how to conduct it properly. They first start off by listing an example of code that complies properly and “works” but under a more complex situation with dozens of tests in a suite it may begin to fall apart. They go on to explain that for every run it will recompile the components and operations taking up to 75% of your time recompiling and not actually running the tests themselves. Next, they show an Angular Testbed monkey patch that will patch the testing framework resetting the testing module before each run and each test. The TestBed.resetTestingModule function they use will clean up all the overrides, modules, module factories and disposes all active fixtures as well, essentially cleaning up what you have. A _initIfNeeded function then comes into play , preserving the factories from the previous run doing what they need to do. If the flag is false the TestBed function will re-create components required for the test, creating a new zone and testing module but not recompiling anything if moduleFactory is in its correct place. After this they run the code they have, clocking in at a 24 second run time to complete its test suite. Then they apply the patch by calling a setupTestSuite function and replacing beforeEach with beforeAll causing the run time to become 8 seconds. A notice 3x time increase in time efficiency for this certain example. With this patch it allows them to preserve the compliation results and re-use them for multiple test per suite.

After this they start up Karma parallel tests, allowing for the tests to be run in parallel. This website shows all the code which is quite lengthy and I wouldn’t want to subject you all to a blog post that takes up too much space. By clicking the link below you can see all the code they have and more. All and all this website was pretty handy and interesting with what they described and how to show angular to its potential.

https://blog.angularindepth.com/angular-unit-testing-performance-34363b7345ba

From the blog CS@Worcester – Matt's Blog by mattyd99 and used with permission of the author. All other rights reserved by the author.

In the post Mock? What, When, How? by Lovis Möller, he discusses mocking and when to use it. Mocking is a strategy used in test-driven development where a mock object is created to test the interactions and dependencies this class has with other classes. Lovis talks about looking at his own and other people’s code and determines some situations in which he would use or would not use mocking, and why he would or would not use it.

Lovis first point is that you should only mock types that are internal to your program, and avoid mocking external types. External types may have dependencies of their own that you don’t know about, and could change in a later version of the code. Avoiding mocking makes your code more adaptable for future versions. The next thing Lovis recommends is that you do not mock values. If you mock values, you aren’t actually testing any useful part of the code. Lovin states:

“Mocking is a technique that is used to make the relationships and interactions between objects visible.”

The last big example Lovis gives is to not to mock concrete classes. The example and associated code he gives makes it pretty clear, as the result depends on a method that has not been covered by the mocked methods within the code. It is easy to see how this could get out of hand if you had to covered each method of a mocked class for your mock testing.

I had a lot of trouble understanding mocking and when you would want to use and and why before reading this post. Although it is still a difficult concept to understand why we are making these mock objects, seeing circumstances in which you would or wouldn’t want to use mocking, and alternatives to mocking make it a little easier to see how it is testing a program and why it is a useful concept. The quote I selected above made this even more apparent to me. Mocking isn’t testing the implementation or your program so much as the relationships between objects and their methods and how they interact.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.