Author Archives:

Apprenticeship Patterns Blog – A Different Road

For this week’s blog post, I read the section  “A Different Road ” from chapter three of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section talked about how taking a different road could be a risky or life-changing event.  Despite this risk, I believe that one should be not afraid to do something different with your life. A change no matter whether they seem good or bad at the time will teach you something new or a new experience that can drive you to push forward. The author started the section by talking about explaining how saying goodbye to the craft can be risky, but  “Even if you leave the road permanently, the values and principles you have developed along the way will always be with you” I think this is very true, no matter the change, the principles you have acquired so far in the career will always be there for you.

Currently, I want to talk about the sad reality and risk one may face when one changes a craft. The author talked about how a person switched from an IT job to be a teacher and afterward it was hard for the person to get back to the industry because “most HR people in big companies didn’t like it.” Sadly, most software companies nowadays see the gaps in a person’s career, and you must justify within their value system why you left and why you are coming back now. Also, as technology is evolving daily, companies want individuals that are willing to learn quickly and adapt to the environment rapidly. The solution suggested in this section I found quite helpful, which was to Write down some of the other jobs you think you would enjoy doing, find people who are doing those jobs and ask them questions regarding them. This interaction will help an individual to decide if they are making the right decision to choose a different path. Reading this section made me think of what my life will be if I choose a different road, it is risky, but is it worth it. Sometimes you must risk It for a greater reward.

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Be the Worst

There is a saying in China: Better be the tail of a lion than a fox’s head! There is another saying: Better be the head of a chicken than the tail of a phoenix.


Surround yourself with developers who are better than you. Find a more robust team where you can be the weakest member and have room to grow. In the beginning, you may not feel confident in your life, but the process of developing and learning in the workplace that makes you stronger is lovely. In this society, no one will care how beautiful and challenging your strategy is. The most important thing is the result. Have you grown and become stronger during this period of enduring learning?

Remember, the probability of being rejected or thought strange by a potential mentor is not high, and the potential payoff is enormous. Even if the person isn’t interested in taking you on as a full-time apprentice, asking her out to lunch can be a valuable investment of time and money, like why dinner with Warren Buffett was auctioned off at such a high price. An early-stage businessman, or an established businessman who has achieved success in a particular field, is all vying for this opportunity. Do they care about the meal? No, they need to learn something from talking to Buffett. Such as looking at the market, investment vision, and the future development trend of business. In computer learning, the principle is the same. By talking with the people above us or the successful people, we can get the information and direction beneficial to our future development. Opportunities are for those prepared, and the accumulation of experience and insight in life will make you soar when opportunities come.

Ask lots of questions.

Tasks such as maintaining build systems, product support, responding to maintenance requirements, bug fixes, code reviews, eliminating technical debt, creating project wikis, updating documentation, acting as a sounding board for other people’s ideas, and so on. Typically, you focus on the less risky edges of the system rather than the core, which often has many dependencies and a lot of complexity. Jean Lave and Etienne Wenger look at apprenticeships in different industries and find that “in the workflow, the tasks of a novitiate are often placed at the end of a branch, rather than in the middle of a series of clips of work” (Situational Learning, p. 110). These fringe tasks benefit the team and you as an apprentice, as they are often skipped in school classes and fill in the gaps. The experience still helps when you become a skilled worker because many of your mentors understand how important it is to do the tedious work. After all, if no one cleans the floor, the team can’t do the glamorous work because it is Mired in a mess.

What’s the most grubby task your team has been putting off for months? It should be the one that everyone complains about, and nobody wants to fix. You solve it. Don’t hold your nose and force yourself to do it; See if you can solve the problem creatively in a way that exceeds people’s expectations and is fun for you. Many people feel that this is a job that is not worth their time. If you don’t do well, you will help the team take the blame. If you do well, the team will take the credit. But you grow as you solve what the team can’t do.

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

The difference between Stubs and Mocks

A mock is an object that can set an expected value, which will verify that the desired action has occurred. The stub is the object that you pass to the code under test. You can set expectations on it to work in specific ways, but those expectations are never verified. The stub’s properties will automatically behave as standard properties, and you cannot set expectations on them.

If you want to verify the code’s behavior under test, a simulation with appropriate expectations is used and validated. If you’re going to pass only values that might need to work somehow but are not the focus of the test, you can use stubs.

Important note: Stubs will never cause a test to fail. 

I believe the most significant difference is that you have written the stub with predetermined behavior. Thus, you will have a class that implements the dependencies that you have disguised for testing purposes (most likely an abstract class or interface), and a class will handle the method only through the response that is set. They don’t do anything fancy, and you’ve already written stub code for them outside of testing.

Simulations are expectations that stubs must set during testing. The simulation is not set up in a predetermined way, so you have the code to perform the simulation in your tests. The mockery is determined at run time because the code that sets expectations must be run before they do anything.

The difference between stubs and stubs

Tests written with simulation usually follow a test pattern of initialize-> set expectations -> exercise -> verify. The pre-written stub will be followed by an initialize-> exercise-> verify.

Similarities between stubs and stubs

The purpose of both is to remove all dependencies from testing a class or function so that your tests are more focused and straightforward when trying to prove it.

The most crucial difference between Stubs and Mocks is their intention. Explain this in the WHY stub and WHY simulation below

Suppose I’m writing test code for the Mac Twitter client’s public timeline controller

Here is the sample code for the test:




Stub: The network connection to the Twitter API is very slow, which makes my tests slow. We knew it would return the timeline, so we made a stub that simulated the HTTP Twitter API so that our test could sprint, even if I were offline.

Mock: We haven’t written any UI methods yet, and I’m not sure what we need to register for UI objects. We wanted to write test code to see how my controller would work with UI objects.

In short, there is a difference between Mock and Stub objects, and RhinoMocks recognize that they allow us to write tests that better illustrate their purpose. The mock object is used to define the expectation that, in this case, I want to call the method A () with such an argument. Record and verify this expectation with ridicule. On the other hand, Stubs have a different purpose: they do not record or validate expectations but rather allow us to “replace” the behavior and state of “fake” objects to take advantage of test scenarios.

View at

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

The Long Road

 When working on an open-source project, get in the habit of downloading the latest version of the code (preferably from their source control system) so you can review its history and track future developments. Take a look at the structure of the codebase and think about why the code is organized the way it is. Take a look at the way developers organize their code modules to see if it makes sense, and compare it to the way they might have used it. Try to refactor the code to understand why its coders made the decisions they did, and think about what the code would look like if you were the one coding it. Not only will it give you a better understanding of the projects; Also make sure you can build those projects. If you’ve found a better way to do something, you’re ready to contribute code to the project. Inevitably, as you go through the code, you’ll come across decisions you completely disagree with. Ask yourself if the developers of the project might know something you don’t or vice versa. Consider the possibility that this is a legacy design that needs to be refactored; And consider whether making a toy implementation for the relevant feature would help clarify the issue.

You end up with a toolbox filled with all sorts of quirks that you’ve collected from other people’s code. This will hone your ability to solve small problems more quickly and quickly. You’ll be able to tackle problems that others think are impossible to solve because they don’t have access to your toolbox. Take a look at the code for the Git distributed source control system written by Linus Torvalds, or any code written by Daniel J. Bernstein (known as DJB). Programmers like Linus and DJB occasionally make use of data structures and algorithms that most of us have never even heard of. They’re not magicians — they’ve just spent their time building bigger and better toolboxes than most people. The great thing about open source is that you can look at their toolbox and make their tools your own. One of the problems in software development is the lack of teachers. But thanks to the proliferation of open-source projects on sites such as SourceForge. Net and GitHub, you can learn from relatively representative code examples from the world’s programmer community.

In ODS, Bill Gates says: “The most subtle test of programming ability is giving the programmer about 30 pages of code and seeing how quickly he can read through it and understand it.” He realized something very important. People who quickly learn directly from the source code will soon become better programmers because their teachers are the lines of code written by every programmer in the world. The best way to learn patterns, idioms, and best practices is to read the open-source. Look at how other people to code. It’s a great way to stay relevant, and it’s free. — Chris Wanstrath at Ruby 2008 [

Pick an open-source project with deep algorithms, such as Subversion, Git, or Mercurial source control system. Browse through the project’s source code and jot down any algorithms, data structures, and design ideas that seem novel to you. Then write a blog post describing the structure of the project and highlighting the new ideas you’ve learned. Can you find a situation in your daily work where the same idea can be applied?

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.


 Transpilers, or source-to-source compilers, are tools that read source code written in one programming language and generate equivalent code in another language with a similar level of abstraction. A good example of a translator is the TypeScript translator, which translates TypeScript code into JavaScript. The Babel compiler can also be used for ES6 JS code to ES5 JS code.

Compilers also translate code from one language to another, but the level of abstraction is very different between the two languages. For example, compile from .java to .class files.

ES6 and ES5

To understand the translator, you must first understand the difference between ES6 and ES5 JavaScript. ES6 (ECMAScript 6) is the specification for the next version of JavaScript. Some of its major enhancements include modules, class declarations, lexical block scopes, iterators and generators, a commitment to asynchronous programming, deconstructing patterns, and appropriate tail calls.

The features are great, but most browsers do not support the specification until now. As a result, any UI application specification written in ES6 will not work in most browsers. To run these applications, you must convert this ES6 source code to the supported JavaScript version ES5. ES5 is supported by almost all browsers and is by far the most stable version.

ES6 – Brings “types” to JavaScript. Make it closer to strongly typed languages such as Java and C#. So far, most browsers don’t support it. It must be converted to ES5 to execute in the browser.

ES5 – Over the years, we’ve been writing plain JavaScript.

Translation unit

A compiler is a program-like compiler that converts ES6 JavaScript code into ES5 JavaScript code to run in a browser. When the compiler sees an expression that uses the language functionality that needs to be translated, it generates a logically equivalent expression. The resulting expression can be very similar to or very different from the source expression.

What does a translator do?

ES6 code => ES5 code (even ES4, ES3)


From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

Links to evidence of activity on GitLab.

I created a sample frontend using vue.js and learned how to build up the environment and set up a sample project.

I learned how to create a climate for vue.js on Udemy and Youtube to set up my vue.js settings. I used my tutorials to build my first sample project.

I am working with Migena for the Small Frontend, which is going to test the login feature with keycloak. We will use vue.js to build the Frontend and the third-party system, keycloak to test it. We will see how a real example of securing our system with keycloak. Our goal is to build a simple frontend to test keycloak.

I will keep meeting with the other teams working on the Frontend to discuss the Frontend’s style, format, and other components.

Reflection on what worked well?

The reflection on what worked well is that we work together with the team members we have worked with before to complete the project plan. Because we have worked together in the same group before, we have a deeper understanding of our teammates and are more accustomed to each other’s habits. There will be a relaxed and happy working atmosphere in the group, and the chemistry between the groups will encourage each other and push the project forward.

Reflection on what didn’t work well?

The reflection on what did not work well is that we didn’t know much about the project initially and thought it was a big project. When faced with the unknown challenge, we were a little confused at first. As we got to know each other and started to move forward with the project, we found that labor division was not reasonable. Because in many issues, Frontend and backend are related. Being responsible for each task affects productivity. So we have overlapping project leaders working together to complete the job, which leads to increased efficiency. It was difficult or challenging to push the task forward, but we encouraged each other through the ZOOM meeting after class.

Reflection on what changes could be made to improve as a team?

As a team with cooperation experience, smooth communication, and tacit understanding among team members are the basis and key to improving our team’s cooperation level. We would discuss the project after class and give some constructive suggestions about each other’s tasks. Good communication makes our team have chemistry. Through communication and cooperation, we have a thorough understanding of the team members’ tasks. Each knew the other’s project progress would be conducive to the overall advancement of the project. When a team member encounters a bottleneck in a task, we will appropriately slow down the overall progress and communicate with him to buffer his time to complete and push forward the overall task progress together.

Reflection on what changes could be made to improve as an individual?

As an individual, I need to improve my understanding of the Frontend more quickly to help my team better connect Frontend and backend. I need to arrange my group tasks more reasonably to help promote the whole group project’s completion. Besides, I also need to make clear my work objectives, continue to follow up on the team’s project, and make my part and the whole develop simultaneously. 

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

This is our example repository that contains everything we worked on for Sprint 1.

Review Docker: Reviewed old projects and main commands for docker.

Create Sample Docker projects: Created a sample Docker Project, Did the getting started activities.

Repository for event project: The main repository for the event project.

Learn About RabbitMQ : Learned RabbitMQ components and Implemented them using Docker.

Review Scrum :  Reviewed the scrum guide and understand the process.

For the project, I am part of the reporting team. I mainly work on the event system software that sends and receives a message to other systems using the RabbitMQ messaging system interface. I also work with the database person and did make a docker example project and a cheat sheet of all the docker commands.

What worked well / did not work well

 The thing that worked well for our group is that we were good at organizing everything and everyone was responsible for certain tasks, and I noticed that some of the tasks overlap between us. For example, the backend person must work more closely with the database person. The first few days we were a little confused, but as everything came together our workflow improved tremendously, which helped to complete all the issues for sprint 1. One thing that did not work well is that we had few problems with GitLab, our template was not loading properly at the start so we could not assign proper labels to issues. Also, during meetings, we should have done the group tasks together instead of a person just doing the task.

What changes could be made to improve as a team?

For a project, communication is the key to success. I think that as a team we should be communicating more rather than doing our tasks during the meetings. For instance, if someone is struggling to figure something out, the other team members can help the person and give insights to lead the individual in the right direction. Also, for the next sprint when we are making cards we should be more specific about the descriptions and properly think about the issue and how we can achieve it and it is clear to the person what needs to be done.  

 What changes could be made to improve as an Individual.

As an Individual, the change that I can make is to plan properly for the next sprint. The first sprint I started of slow because I was not sure how you do something or if I am doing it the right way. A properly planned sprint will help me to go with a flow and have a balance rather than getting overwhelmed by doing all the tasks towards the end of the sprint. My communication with the team should get better as we move on to the next phase.

Overall, this was a great learning experience. I think the first sprint was a success and a starting point for our team to move forward with a vision to complete the task that is assigned for us. I’m looking forward to working with the other teams to combine everything and see our progress.

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Boundary Value Analysis and Equivalence Partitioning Testing

When it comes to a large pool of input data, it is not possible to perform exhausting testing for each set of test data. There should be an easy way to select test cases from the pool so that all scenarios are covered. This is when the Equivalence Partitioning & Boundary Value Analysis testing techniques were introduced. In today’s blog, I want to do further research on the testing technique of Boundary Value Analysis and Equivalence Partitioning Testing. Equivalence Partitioning and Boundary value analysis are linked to each other and can be used together at all levels of software testing. To start, Boundary value testing is the process of testing between extreme boundaries between the partitions, for example like start, end, lower, upper, maximum, minimum, just inside, and outside values. Normally Boundary value analysis is part of stress and negative testing. Using the Boundary Value Analysis technique tester creates test cases for the required input field.

Now when it comes to equivalence partitioning or equivalence class testing is a type of black box testing technique in which the input data units are divided into equivalent partitions that can be used to derive test cases. This helps with reducing the time required for testing a small number of test cases. This technique can be applied to all levels of software testing like system, unit, and integration. One of the examples that were widely used in many resources that I have look at is: let us say a password field accepts a minimum of 6 characters and a maximum of 10 characters, that means results for values in partitions 0-5, 6-10, 11-14 should be equivalent.  The three testing scenarios will be:

1       Enter 0 to 5 characters         System should not accept

2       Enter 6 to 10 characters       System should accept

3       Enter 11-to-14-character      System should not accept.

Equally, Both testing techniques are used to reduce a very large number of test cases to a manageable piece, Both are appropriate for calculating intensive applications with such a large number of variables and input data.

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog – Nurture Your Passion

For this week’s blog post, I read the section  “Nurture Your Passion ” from chapter two of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section talked about how the work environment can stifle the passion for the craft. For example, you might be a software developer with a passion for the craft, but unfortunately the daily activities, “demoralizing corporate hierarchies, project death marches, abusive managers, or cynical colleagues.” Can become hard for your passion to grow by staying in such hostile conditions. I think this is true for the majority of the people that work in the IT field. I have seen especially my family members whose having such a hostile situation at work especially when there is a deadline that is approaching, or a software release is going on.

The author goes further into project death marches in which he explained how they are the most damaging of the hostile situations, it takes your time and energy, preventing you from taking any significant actions to protect your passion as more important issues like physical and mental health can take a toll. Now that I think about it, work pressure and stress can significantly affect one’s mental health.  I think it is important for people to take a break from sometimes and focus on something else for a little time. Identify what u like, find something at work that interests you and you enjoy doing. I liked the solution that was given to this problem which was: to grow your passion, set clear boundaries that define the sort of environment you are willing to work in. I think that creating some sort of boundaries helps and necessary to have a free hostile environment. One of the statements I do not agree with the author is how walking out of a meeting or refuse to distribute code that doesn’t meet your minimum standards will help your passion however this type of behavior can cause a conflict between your colleagues or your boss. I think the best solution if you want to follow your passion is just to do it, nurture your passion or find a job that suits well for your passion.   

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Difference Between Black-Box, White-Box

 White-box or glass-box testing is testing from a program’s source code without using the user interface. This type of testing needs to look at code syntax to find flaws or errors in the internal code in algorithms, overflows, paths, conditions, and so on, and then fix them.

Black-box testing, or black-box testing, is rigorously tested by using the entire software or a software function without examining the source code of the program or having a clear understanding of how the program or the source code of a software function was designed. Testers understand how the software works by entering their data and seeing the results. Typically, testers run tests using not only input data that is guaranteed to give correct results but also input data that is challenging and may result in errors in order to understand how the software handles various types of data.

The program under test is treated as a black box, without considering the internal structure and characteristics of the program. The tester only knows the relationship between the input and output of the program or the function of the program and determines the test cases and inferences the correctness of the test results by relying on the requirement specifications that can reflect the relationship and function of the program.

Black box testing of software is used to verify the correctness and operability of software functions. Treat the program as a black box, without considering the internal structure of the program box processing. In the program interface test, just to check whether the program function in accordance with the specification of the normal use. Black box testing is also called functional testing or data-driven testing.

White-box testing is exhaustive path testing, and black-box testing is exhaustive input testing. These two methods are based on completely different points of view, reflecting the two extremes of things. They have their own emphasis and advantages, but they cannot replace each other. In the modern concept of testing, the two methods are not separate but intersect.

It relies on the careful examination of the details of the program, the design of test cases for specific conditions, and the testing of the logic path of the software. Check the “state of the program” at various points in the program to see if the actual state corresponds to the expected state. White-box testing of software is used to analyze the internal structure of a program.


Difference Between Black-Box, White-Box, and Grey-Box Testing

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.