Software Craftsmanship raises some of the thorniest and most sensitive questions about software development and comes to the controversial conclusion of finding answers in a system that has thrived for hundreds of years: technology. Software Technology is a systematic expression of the author’s ideas and attempts to answer the difficult questions that have been plaguing the software industry. How should we restructure the process of building software, such as we want it to be effective?

 

The author of Software Craftsmanship has been emphasizing the role of the craftsman in the project. Craftsmen sounds is a very old word, the craftsman in other industries is a what kind of person I want to say, must be done in the field of a good man, I explain the below mentioned software process artisans do what kind of person, craftsman is mentioned there is a very rich in the process of software development experience, after years of development, products are well received by customers, has a certain reputation, they can submit a robust, high quality of the user application. A good craftsman can make or break a project. This shows that the human factor plays a very important role in the development of the project. Someone I have been thinking without learning software engineering in software development has a very important role in understanding of software engineering make me realize software can also like assembly line engineering, development mode, people do not development process, mainly the development process of software engineering control, a relatively fixed process, as long as people do some mechanical work can complete this project. In the current environment, software engineering ideas are still dominant, but software technology ideas also have their base of support, such as workers in the open-source community.

 

Software technology of the main pressure is a very important role in the whole project, software process is very strict requirements of the team, the team first small number, no more than 15 people, the general team is three people, but for the team of personal ability request, the other teams also are in high demand of health, a more stable team, team members can develop the tacit understanding.

 

The book Software Craftsmanship gives us a good development model, but many projects in the current environment are developed using software engineering ideas. Why is this? In my analysis, the main reason is that software technology requires too much of the team, and there are too few excellent craftsmen, so it is difficult for many companies to organize such an efficient team. Right now, the idea of software craftsmanship can only be seen in the open-source community, where many of the true craftsmen are gathered.

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

We are at the point of life that in a few years we all be fully working adults. It is crazy to think that 4 years of college just flew by so fast. This semester the software capstone class will be the most interesting and challenging I believe. When it comes to reading a book, I have no patience at all, but after reading the introduction, something about this book: Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman is making me want to read it appropriately. It is possible to be that I can relate to this book on so many levels and it is relevant to me. After just reading the introduction I feel like it changed the way I think and view my profession.

All the patterns in the book are interesting and powerful in a way that we can adapt and combine these patterns in many ways and situations. One of the patterns that stood out to me the most was “Be the worst” from chapter four. The author has explained the concept very well in which it states that “Surround yourself with developers who are better than you. Find a stronger team where you are the weakest member and have room to grow” This statement Is very interesting and when I think deep into it, I believe that being worst in a team at least for me is a motivation to work hard and grow to improve. The goal is not to stay the weakest but instead work my way from the bottom to the top.

The author also talked about the risk factor that associates with being worst in the team including dragging the team down, good teams do not tolerate you, and the risk of being fired. Although I do agree that in situations all these scenarios could be possible but on the positive side this can motivate a person to improve and build a mindset that helps the individual. I do not think I disagree with any aspects of the pattern but, these patterns and the whole book have certainly changed the way I think about a certain aspect of software development. I realized that I need to work even harder and push myself to the limits for me to get where I want in life.

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

Software frameworks are reusable “semi-finished” software for domains (such as ERP, computing, etc.) that implement common parts of the domain and provide well-defined points of variability to ensure flexibility and extensibility. In other words, the software framework is the softwarenation of the results of domain analysis and the template for the final application in the domain.

With the expansion of software scale, wide application and the development of software reuse technology, the software reuse based on subroutine and class has a lot of shortcomings:

(1) The library of the subroutine is becoming more and more huge, which makes it difficult for its users to master

(2) Most classes are too small to do all the useful work by themselves

It is for these reasons that a set of classes (modules) are considered as a whole in reuse, resulting in a software framework. The software framework contains at least the following components:

(1) A series of modules to complete the calculation become components

(2) The relationship between components and the interaction mechanism

(3) A series of variable points (hot spots, or adjustment points)

(4) Behavior adjustment mechanism of variable point

Developers through the software framework behavior adjustment mechanism, peculiar to the general application domain software module bound to the variable point of a software framework, and got the final application system, this process is called software example of a software framework, the existence of software framework allows developers will be the main energy on the development system of the module, so as to improve software productivity and quality.

The behavior adjustment mechanism of the software framework refers to how to adjust the variable part of the framework for the specific application and how to add the method and rules of the specific application module at the variable point.

Ii. Software architecture

Software architecture is a sketch of a system. The objects described by software architecture are abstract components that directly constitute the system. The wires between the components describe the communication between the components explicitly and in relative detail.

Software architecture, by definition, is divided into two camps of ‘constituent’ and ‘decision-maker’, which are described as follows:

The componentized view of software architecture is that the system is described as computing components and their interactions. It has two very obvious characteristics:

Focus on the object of architectural practice — software, with the software itself as the object of description.

This paper analyzes the composition of the software, and shows that the software is not a whole in the sense of “atom”, but a whole composed of different parts connected through a specific interface, which is very important for software development.

Decision-makers believe that software architecture involves a series of decisions, mainly including:

Organization of software systems

Choose the structural elements that make up the system, the interfaces between them, and the behavior that these elements exhibit when they cooperate with each other

How do you combine these elements so that they gradually synthesize into larger subsystems?

The architectural style used to guide the organization of the system: these elements and their interfaces, collaborations, and combinations

Software architecture is concerned not only with the structure and behavior of the software itself, but also with other features: usage, functionality, performance, elasticity, reuse, understandability, economy, and technical constraints and trade-offs.

Personal understanding: When software engineering has a certain scale, software development does not exist in the form of data structure + algorithm, but “divide and conquer” software based on many factors such as technical choices and user needs. The main task of the architect is to divide the software into different modules and define the interfaces between modules.

Sources:

https://softwareengineering.stackexchange.com/questions/229415/difference-between-an-architecture-and-a-framework#:~:text=An%20architecture%20is%20the%20the,that’s%20designed%20to%20be%20extended.&text=Frameworks%20are%20specifically%20designed%20to%20be%20built%20on%20or%20extended.

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

I. Concept of system architecture

By Edward Crawley, Bruce Cameron, And Daniel Selva co-authored SYSTEM ARCHITECTURE: Strategy and Product Development for Complex Systems. In the book, the word “system” is defined in this way: a system is a set of entities and their relationships, whose functions are greater than the sum of their respective functions.

In other words, the function has to be 1+1>2, which is called emergence. For example, a pile of bricks and wood cannot provide shelter from the wind and rain, but they can form a warm house. The function of the house is greater than the sum of the functions of the pile of materials, so the house is a system.

Now that you know what a system is, let’s look at what a system architecture does:

1) Determine the form and function of the system. To put it bluntly, it’s analyzing requirements.

2) Determine the entities, forms, and functions of the entities in the system. It’s dividing up the system. To accomplish this task, the book proposes some points of attention: identifying potential entities, focusing on important entities, abstracting entities, and defining the boundaries of the system and the environment in which the system resides.

3) Determine the relationship between entities. This includes identifying relationships between internal entities and entities located at boundaries and defining the form and function of those relationships. That is to define internal and external interfaces.

4) Forecast emergence. The prediction of final function realization, performance realization, and also the prediction of system failure, is the emergence of non-expectations.

II. The book also explains the architect’s function from another perspective:

1) Disambiguation. That is, the architecture is designed so that you don’t have a vague understanding of the requirements.

2) Define the system concept. Put forward the overall solution, define the key terms in the system, define the key measurement criteria.

3) Design decomposition. The key to breaking down the system into entities and the relationships between entities is to control the complexity of the system and not overscale it.

It can be seen that the system architecture is a step between the requirements and the implementation, which not only analyzes the requirements but also proposes a feasible implementation scheme.

The system architecture is suitable for a team composed of one or a few people because many people will lead to insufficient integrity of thinking. If multiple people work together, the best form is also to divide up the hierarchy, with a hierarchy of units to be completed by a single person. This requires a high level of knowledge, synthesis, analysis, and imagination on the part of the architect.

Sources:

Click to access Preface.pdf

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

This week on my CS Journey, I want to focus on Agile software development and its methodologies. Agile methodology is a type of project management process, mainly used for software development. It evolves through the collaborative effort and cross-functional teams and their customers. Scrum and Kanban are two of the most widely used Agile methodologies. Today I want to focus mainly on Scrum. Recently I saw that employers are looking for candidates who have experience in scrum and agile development, so it is important that we learn more about it.

 Scrum is a framework that allows for more effective collaborations among teams working on various complex projects. It is a management system that relies on step by step development. Each cycle is consisting of two-to four-week sprints, where each sprint’s goal is to build the most important features first and come out with a potentially deliverable product. Agile Scrum methodology has several benefits,  it encourages products to be built faster since each set of goals must be completed within each sprint’s time frame.

 Now let’s look at the three core roles that scrum consists of scrum master, product owner, and the scrum team. The scrum master is the facilitator of the scrum. In addition to holding daily meetings with the scrum team, the scrum master makes certain that scrum rules are being enforced and applied, other responsibilities also include motivating the team, and ensuring that the team has the best possible conditions to meet its goals and produce deliverable products. Secondly, the product owner represents stakeholders, which are typically customers. To ensure the scrum team is always delivering value to stakeholders and the business, the product owner determines product expectations, records changes to the product, and administers a scrum backlog which is a detailed and updated to-do list for the scrum project. The product owner is also responsible for prioritizing goals for each sprint, based on their value to stakeholders. Lastly, the scrum team is a self-organized group of three to nine developers who have the business, design, analytical, and development skills to carry out the actual work, solve problems, and produce deliverable products. Members of the scrum team self-administer tasks and are jointly responsible for meeting each sprint’s goals.

Below I have provided a diagram that shows the structure of the sprint cycles. I think understanding the Agile methodologies Is helpful because most of the major companies help teams and individuals effectively prioritize work and features. I highly recommend visiting those websites it provides detailed explanations of how a scrum cycle works.

Sources: https://zenkit.com/en/blog/agile-methodology-an-overview

https://www.businessnewsdaily.com/4987-what-is-agile-scrum-methodology.html#:~:text=Agile%20scrum%20methodology%20is%20a,with%20a%20potentially%20deliverable%20product.&text=Agile%20scrum%20methodology%20has%20several%20benefits

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

This week on my CS Journey I want to focus on REST API Design. In my last blog, I talked about how an API request works and how to be able to read the API documentation and use it effectively. In this blog, I will be emphasizing briefly the key constraints to REST API design. There are six important constraints to the design. Which are: Client-Server, Stateless, Cache, Uniform Interface, Layered System, and Code on Demand. Together, these make up the theory of REST.

Starting with client-server constraint is the concept that the client and the server should be separate from each other and allowed to evolve individually and independently. In other words, a developer should be able to make changes to an application whether on the data structure or the database design side at the same time it is not impacting the client server side. Next REST APIs are stateless, meaning that calls can be made independently, and each call contains all the data necessary to complete itself successfully. The other Constrain is Cache, since a stateless API can increase requests and handles large loads of calls, a REST API should be designed to encourage the storage of cacheable data. That means that when data is cacheable, the response should indicate that the data can be stored up to a certain time. 

The next constrain is Uniform Interface, having a uniform interface that allows the client to talk to the server in a single language. This interface should provide standardized communication between the client and the server, such as using HTTP with resources to CRUD (Create, Read, Update, Delete). Also, another constrain is a layered system. As the name implies, a layered system is a system comprised of layers, with each layer having a specific functionality and responsibility. In REST API design, the same principle holds, with different layers of the architecture working together to build a hierarchy that helps create an Application. Also, A layered system helps systems to increase flexibility and longevity and it allows you to stop attacks within other layers, preventing them from getting to your actual server architecture. Finally, the least known of the six constraints is Code on Demand which allows for code to be transmitted via the API for use within the application. Together, these constraints make up a design that operates similarly to how we access pages in our browsers on the World Wide Web.

Overall, I learned the most important aspects of REST API Design. The blog was certainly helpful to understand the key constraints very well. I have only mentioned the main important parts of it. I highly recommend everyone taking a look at the source below. 

Source: https://www.mulesoft.com/resources/api/what-is-rest-api-design

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

This week on my CS Journey, I want to look closely at the topic of REST API Design. I know We have been doing several activities regarding the topic in class and the homework assignment is associated with it, however, I wanted to be very knowledgeable on the topic, so I decided to do more research. REST is an acronym for Representational State Transfer. A REST API is a way for two computer systems to communicate over HTTP in a similar way to web browsers and servers do. Let start by looking at what An API is,  An API is an application programming interface. It is a set of rules that allow programs to talk to each other. The developer generally creates the API on the server and allows the client to talk to it and the REST determines how an API should look like.

Now let’s look at the anatomy of a request is, An API request has four main important parts: The endpoint, The method, The headers, and The data or body. When an API interacts with another system, the touchpoints of that communication are considered endpoints. Each endpoint is the location from which APIs can access the resources they need to carry out to do their function. The way APIs work is using  “requests” and “responses.” Meaning that each URL is called a request while the data sent back to you is called a response.

Generally, when it comes to methods it has five types. Which are: GET, POST, PUT, PATCH, and DELETE. These methods provide meaning for the request you’re making. They are also used to perform four possible actions that are Create, Read, Update, and Delete also known as CRUD. Next, the Headers are used to provide information to both the client and the server. It can be used for many purposes, such as authentication and providing information about body content. Lastly, the body or the data is what contains information you want to be sent to the server. This option is only used with POST, PUT, PATCH, or DELETE requests.

Overall, I learned a lot from this blog. The source I used explained the topic very well. I highly recommend everyone to check it out, because it has a variety of examples and documents that you need to know about REST APIs to be able to read the API documentation and use them effectively. It also goes deep into the methods and the request meaning of each of them, I think it is very important to understand those concepts because companies all over the world are using APIs to transfer vital information, processes, transactions, and more.

Source: https://www.smashingmagazine.com/2018/01/understanding-using-rest-api/

            https://www.sitepoint.com/developers-rest-api/

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

API is short for Application Programming Interface (API), which describes a class library’s characteristics or how to use it. Your personal library may contain “API documentation” of available functionality.

A REST API in API Gateway is a collection of resources and methods integrated with back-end HTTP endpoints, Lambda functions, or other AWS services. You can use API Gateway features to help you with all aspects of the API lifecycle, from creation through monitoring your production APIs.

API Gateway REST APIs use a request/response model where a client sends a request to a service and responds back synchronously. This kind of model is suitable for many different kinds of applications that depend on synchronous communication.

When many people refer to API documentation these days, they often refer to an HTTP API that might share your application data over the web. For example, Twitter provides an API that allows users to request tweets in a specific format to easily import them into their own applications. This is where the HTTP API is potent. It can mix and match data from multiple applications to a mixed application or create an application that enhances the experience of using other people’s applications.

It is an application that allows us to view, create, edit, and delete parts.

REST is the shorthand for Representational State Transfer, which was proposed by Roy Fielding T to describe the standard way of creating an HTTP API, and he found that the four common behaviors (view, create, edit, and delete) could all be mapped directly to the implementations in HTTP.

The different HTTP methods:

• GET

• POST

• PUT

• DELETE

• OPTIONS

• HEAD

• TRACE

• CONNECT

Most of the time, when you’re looking at your browser’s dots, you’re using the HTTP GET method. The GET method is only used when you request resources from the Internet. When you submit a form, you often use the POST method to send data back to the site. As for the other approaches, some browsers may not fully implement them at all. But that’s fine if it’s for our use. We have many HTTP methods to choose from to help describe these four behaviors, and we will use client libraries that already know how to use these different HTTP methods.

Rest API benefits:

• Resource oriented, easy to see

• To GET something, you need to GET (GET is safe, does not modify the service resource), you need to POST (POST is unsafe), you need to PUT (PUT is idempotent), and DELETE (DELETE is idempotent).

• Traditional CRUD requires four different interfaces, but the REST API requires only one. (Distinguish between different requests)

Source:

https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-create-api-from-example.html

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