DEV Community: Jason V. Castellano

How to Pass an Argument in Nodejs Command Line Application

Jason V. Castellano — Mon, 01 Aug 2022 14:35:00 +0000

For those software engineers who have a lot of responsibilities the terminal is their home. It's very satisfying to create your own command line by using your favorite programming language. In this post, let me show you how to create a command line application using nodejs.

But before anything else. You need to install NodeJs. If your NodeJS are not install yet. You can download it here.

Now, let us start.

Lets create your index.js file in your folder. Then inside index.js. type this code.

Now, you can open your terminal and run it.

node index FirstArgument // output: FirstArgument

As you can see the process.argv[2] is an array. Let us discuss some of the array of arguments below:

process.argv[0] - is path where nodejs is located. In my case it is /usr/local/bin/node

process.argv[1] is a path where my index file is located. In my case it is /home/thegreytangent/Desktop/dev.to/index

process.argv[2] it is first argument on my script: FirstArgument

process.argv[3] - the second argument and so on.

What if you need all the arguments? No need to worry just loop it.

Now, run it in your terminal.

node index FirstArg SecondArg ThirdArg

The expected output should be:

Argument number: 0: /usr/local/bin/node
Argument number: 1: /home/thegreytangent/Desktop/dev.to/index
Argument number: 2: FirstArg
Argument number: 3: SecondArg
Argument number: 4: ThirdArg

That's all for today!

In this post, we learn to add arguments in our nodejs CLI. Thanks for reading. You can leave a like or a share if it is helpful and ask any questions in the comments below. (-:

Introduction to Domain Driven Design

Jason V. Castellano — Mon, 25 Jul 2022 00:14:00 +0000

It's been more than 50 years before the software architecture was invented, but still project delayed and mismanagement cannot be solve. Some things inevitable because its a moving target, trust me that is the reality. It has been experience by all software engineer. In this article let me share you this software architecture approach.

Domain Driven Design (DDD) is an architectural pattern that will help succeed and to understand the software that we are building by modeling the classes based on the business requirements. Setting aside the technology that you must use and focusing on the problem domain is what you must do. Therefore, all you need is pen and paper. This design pattern are using strategic and tactical modeling tools to solve business problems.

DDD is not about technology. Instead, its all about understanding the problem space in the business domain.

To understand how the business works, you need to participate some discussion with your team to develop software discovery and knowledge crushing. Before we learn DDD, let us discuss first the overview of architectural layer.

Layered Architecture

Back then, there were only two layers: presentation and data. So, where is the business logic? Traditionally, business logic has been coded in the presentation layer (a.k.a user interface). This will make development faster - if you are a solo developer. Eventually, layered architecture emerged, dividing code responsibilities into four layers.

Presentation Layer - There is only one job for this layer, and that is to display the data for the user.
Application Layer - This layer is thin. It does not contain any business logic. The state of the task is in progress inside of this layer.
Domain Layer - This is the heart of the software. All the business logic is inside here. The domain layer is persistent ignorance. The domain layer in DDD is purely a class object. Unlike other patterns, the database and entity are one such as MVC.
Infrastructure Layer - You can imagine this as a supporting layer. It gives communication between other layers. One of the codes inside the infrastructure layer is an email sender.

The Three Pillars of Domain Driven Design

In order to understand the deep topic of this pattern, we need to be familiarize what actually DDD made up.

Ubiquitous language

In doing domain driven design, it is important the the software engineers and domain expert should work together. They are no vs us, there will be always us. The result of creating ubiquitous language will benefit all the people who are working in the software because both developers and client speak in the same language. Ubiquitous language is the language of business, therefore, the engineer who are working the system must understand the business.

For the mean time, let us consider that the bounded context is the a boundary around the system.

The customer inside the bounded context is a ubiquitous language. Therefore, customer has a different meaning in each boundaries.

Strategic Design

The main objective of this design is to identify the bounded context, ubiquitous language, and context map inside the system.

Bounded Context - You can imagine this like a boundary of your ubiquitous language. For instance, the customer in delivery context and finance context has a different meaning. In finance context customer is the entity or the main entity of that context, while in delivery context the customer is only a value object of the order. If the discussion does not match in the customer scenario, it means you’re team is out of context. We will discuss deeply about entity and value objects later in this article.
Context Maps - When you are done creating a two or more bounded context, there is a relationship between those boundary. Context mapping is way to model and to connect by visualizing the relationship of those context.

Tactical Design

This design is used when you create your domain model inside of your bounded context. The building blocks are entities, value objects, aggregates, services, and repositories. I will explain only the overview of those building blocks in this article.

Entities - it is a class that has identity and it remains the same thought out your system.
Value Objects- it is also a class but unlike entities it has no identity. Value objects are being used by the entities to represent the attribute such as age, address, and so on. The attribute is validated inside the value object class.
Services - every layer has a service. For instance, one of the services inside the application, it is called the application service. The purpose of application service is to handle the flow of use cases in the system.
Repositories - If you are a software engineer, you have heard this already and probably you have an idea of what it is. Repositories are an abstraction of your database (SQL code). You named the abstraction based on the language that the business uses such as getAllSingleStatusUsers() just like that.

Conclusion:

In software development, there are no single solution in every problem. If you have a small application or the requirements is only basic CRUD functions, I think you don't need a DDD. It all depends in the application that your are building. You can try this DDD architecture design if your application will grow and has many functions. I hope you finally understand the basic concept of DDD. In my next article let us discuss deeply about entities and value objects with some sample codes.

What kind of architectural pattern you are using now? Are you facing some challenges when the application grows? Let me know in the comment and don't forget to share this article. Thanks for reading. (-:

Basic Guide in Estimating Project Size by Using Story Points

Jason V. Castellano — Sun, 01 May 2022 03:31:48 +0000

As a software engineer, we always underestimate the size and completion of the project. In this article I will discuss some tips on how to estimate a software project.

Let us give some analogy in order to fully understand the scenario.

Supposedly, my task is to transfer a bunch of cardboard boxes from the garage into the store room. When I looked at the task, I estimated that it would take a total of seven hours to transfer all the boxes. What I am doing is estimating only the duration avoiding the size estimation of the task.

For instance, I will try to estimate again , but this time, my estimation is based on computing the pile of cardboard boxes, its weight, and the distance. So, let's estimate:

They are 50 boxes.
Each box has a weight of 30 kg.
Transfer distance is 15 meters from garage to store room.

However, learning that information still is not enough. We need to know the average time of transfer of each box from the said location.

Based on my capacity, I can transfer each box 7 meters in one minute then rest for 15 seconds and move again 8 meters in one minute and 15 seconds, the total is 2 minutes and 30 seconds each box. Since we are estimating those numbers, we don’t give the exact number, instead to consider the margin of error. Therefore, the final estimation to transfer each box is 3 minutes. It takes me more or less two and half hours to transfer all 50 boxes from the garage to the store room.

What are Story Points?
Story points are units of measure for expressing an estimate of the overall effort required to fully implement a software feature or any other piece of work.

When the software engineer gives the points in each feature, don’t expect that those points are the same. This is commonly happening in software development, whereas two back end engineers that have the same skill set will have different story points in the same task. One reason for this is that the two of them have a different perception and process to accomplish those tasks. The goal here as a project manager is to collect all the story point of each engineer to make a future prediction of the accomplishment of their task.

Let us discuss how to use story points in the software development environment.

For instance, there are two software engineers named Bob and James. Bob is a NodeJS Developer that works in the backend and James is a ReactJS developer that works in the frontend. The project manager gives Bob and James the list of features. Set the points in each features and the most complicated feature points rated will be 10.

Let us discuss the points given by the two software engineers.

Bob rated the login by 5 points. If you ask bob, bob will tell you that is because when the teacher will login:

He needs to filter the username and password.
Check the username if has spaces in the first and last of the word and trim the words
Check the username and password if it exists in the databases, etc.

Meanwhile, James’s rate 4 because:

He needs to create two input boxes in the form,
Validate the characters in the input box while the user is typing,
If error detected it will display in the form interfaces what is something wrong.

Those tasks are not so hard for James but a little complicated for bob.

Let us proceed to the next use case “Teacher can add grades” features. This is more complicated in the backend because when adding grades there was another functionality trigger to it.

Validate if grades are numeric.
Grades should not be less than 60 and not greater than 100.
Insert grades to database.
Notify students of those grades already added.

There is some notification involved when adding grades, therefore, bob rate 8 points in the backend. In the frontend, James gives 4 points because it's simple for James to create a form that validates the grades before submitted.

Now you already understand and see the benefits of story points. When you check other features that have an equal point in the previous, there is a possibility that the time and effort involved are the same. In the backend, login and add student are the same points rated by Bob. Therefore, you can estimate the time and effort to complete the task of Bob based on his previous story points. That’s how other companies estimate the overall effort and time in order to develop the application.

If you are a software engineer reading this you can now create an estimation or functionality rating (story points) of the features you are working on. And if you are a project manager I bet you already know this kind of strategy.

In estimating always remember:

In a good shoe, I wear size six, but a seven feels so good, I buy a size eight. - by Dolly Parton in Steel Manolias

Hope this article helps you understand the basics of story points. Let me know from the comment below if you have some suggestion or what technique you use to estimate your software project.

Thank you for reading and happy estimating. (-:

*Sources: *
Cohn, Mike. Agile Estimating and Planning. Prentice Hall PTR, 2012.