DEV Community: Bijay Kumar Pun

RAD And V Models of SDLC

Bijay Kumar Pun — Mon, 28 Mar 2022 03:14:15 +0000

SDLC - Software Development Life Cycle

What is SDLC ?
SDLC is a structured process that aims at developing high quality software, at the lowest cost with shortest production time. International standard for software lifecycle process is defined in ISO/IEC 12207.

SDLC Stages:

Plan
Design
Implement (Develop)
Test
Deploy
Maintain

SDLC Models:

Waterfall Model (1970s to 90s)
Prototyping Model
Iterative Model
Spiral Model
V-shaped Model
Agile
Scrum
Kanban

V-shaped Model
This model is also known as Verification and Validation model, and is an extension of Waterfall model with testing phase integrated in each SDLC stage. Thus, in this model, Testing and Development goes in Parallel.

Requirements <----------> Acceptance Testing
Specification <--------> System Testing
Architectural Design <------> Integration Testing
Detailed Design <-------> Unit Testing
< Coding >

The coding phase connects validation phase and verification phase.

Pros:

Highly disciplined model, easy to understand and manage
Effective for projects where requirements are fixed and well understood

Cons:

Less adaptive to change
Not appropriate for large and complicated projects
Working software is produced towards the end only

RAD Model
RAD (Rapid Application Development) is a combination of Prototyping and Iterative models. In this model a working model of the product is rapidly developed and iterated to fit the requirement of the customer. This also means the writing of the software phase itself involves collecting requirement for the development phase.
In RAD model there is minimal planning as the product changes rapidly with each iteration. Unlike V-shaped model where the working product is only obtained towards the end, in RAD model workable product (prototype) is delivered on every iteration.

Phases of RAD
Business modeling
Data Modeling
Process Modeling
Application Generation
Testing and Turnover

These phases are iterated over and over until the required product is reached.

Pros:

Highly adaptive to change
Reduced development time
Least planning required
Feedback oriented

Cons:

System must be modular to be iterative
High cost for smaller projects due to multiple iterations
Demands user's involvement
Highly skilled developers needed

DevOps Internship Assignment | Week 1_

Route Model Binding in Laravel

Bijay Kumar Pun — Wed, 29 Apr 2020 09:42:01 +0000

Route Model Binding provides a mechanism to bind/inject a model instance in the route. It's a neat way to validates a model Id injected in the route by injecting a Model instance.

Implicit Binding
In this method, we directly inject the model instance by passing the type hinted variable as a parameter in the closure. The type hinted variable name should match the route segment name.

Route::get('api/posts/{post}',function(App\Post $post){
return $post->title;
});

Here, the {post} URI segment in the URL matches the type hinted $post variable.
Laravel will then automatically inject the model instance that has an id field matching the corresponding value from the request URI, i.e {post}, if not matched a 404 HTTP response will be automatically generated.

In default case the default column looked for is the id column but can be changed by using the getRouteKeyName() Eloquent function.

public function getRouteKeyName(){
return 'slug';
}

Now the route will have slug instead of id.

Explicit Binding
In this method, we explicitly bind a model to the segment of the route.

Explicit binding can be done by using Router::model() method. This can be used inside boot() method of RouterServiceProvider class.

//RouteServiceProvider.php
public function boot(){
parent::boot();
Route::model('post',App\Post::class);
}

This bounds all {post} parameters to the App\Post model, meaning a Post model will then be injected in the route.

The difference between implicit and explicit binding is explicit binding allows putting extra logic.

Another way of explicit binding is by overriding resolveRouteBinding() method on the Eloquent model itself.

//App\Post model
public function resolveRouteBinding($value)
{return $this->where('slug',$value)->first()??abort(404);
}

Binding a resource controller in Laravel

Bijay Kumar Pun — Wed, 29 Apr 2020 02:33:53 +0000

What is resource controller?
Laravel has some conventions/rules for all of the routes of a traditional REST/CRUD controller called resource controller. Laravel also comes with a generator out of the box and a convenient route definition that allows binding an entire resource controller at once.
Simply put, resource controller is used when all CRUD operations are performed. Meanwhile, if performed manually, then plain controllers are used.

To generate recource controller:
php artisan make:controller MySampleResourceController --resource

Resource Controller Binding
// routes/web.php Route::resource('tasks','TasksController');

To list all the route:
php artisan route:list

Laravel Controllers

Bijay Kumar Pun — Tue, 28 Apr 2020 15:55:45 +0000

Exceprts from the book Laravel: Up and Running by Matt Stauffer

Requests can come to applications not only via routes, but also cron jobs, Artisan command-line calls, queue jobs etc.
Controller's primary job is to capture the intent of an HTTP request and pass it on the rest of the application.

To create controller, run:
php artisan make:controller <controller-name>

This creates a controller class inside app/Http/Controllers/.
Additionally, the --resource option can be used to autogenerate methods for basic resource routes like create() and update()

Artisan's make namespace provides a lot tools for generating skeleton files for a variety of system files.

A common controller method example:
//SomeController.php public function index(){ return view('tasks.index') ->with('tasks',Tasks:all()); }
The above can be used as:
//route/web.php Route::get('/','SomeController@index');
This loads the resources/views/tasks/index.blade.php or resources/views/tasks/index.php and passes it a single variable named tasks which contains the result of the Task::all() Eloquent method.

Subdomain Routing and Namespace Prefixes in Laravel

Bijay Kumar Pun — Tue, 28 Apr 2020 12:52:51 +0000

Excerpts from the book Laravel Up and Running by Matt Stauffer

Subdomain routing is like route prefixing yet with scope only within the subdomain.

Two primary uses of subdomain routing

Present different section of the application to different subdomain
Set part of the subdomain as parameter

Eg.
Route::group(['domain'=>'api.myapp.com'],function(){ Route::get('/',function(){ // }); });

Route::group('domain'=>{account}.myapp.com'],function(){ Route::get('/',function($account){ // }); Route::get('users/{id}'function($account,id){ // }); });

The subdomain here is parameterized and will be passed as the first parameter to every grouped routes

Namespace Prefixes
Grouping routes by subdomain mean their controller may have similar PHP namespace.
Eg. for different APIs the namespace can be App\Http\Controllers\API\ControllerA
and for different subdomains, the namespace can be App\Http\Contollers\account\ControllerB etc.

These long controller references can be avoided with namespace prefixes

Eg.
__//App\Http\Controllers\ControllerA
Route::get('/','ControllerA@index');

Route::group(['namespace'=>'API'],function(){ //App\Http\Controllers\API\ControllerBRoute::get('api/','ControllerB@index');
});`

Name Prefix
Prefix can also be used for route groups. Route group name prefixes help define that every route within this group should have a given string prefixed to its name.
Ex.
Route::group(['as'=>'users.,'prefix'=>'users'],function(){ ROute::group(['as'=>'comments.,'prefix'=>'comments'],function(){ //Route name will be users.comments.show Route::get('{id}',function(){ //do something }}->name('show'); }); });

Inflating views and passing variable in Laravel

Bijay Kumar Pun — Tue, 28 Apr 2020 12:48:04 +0000

Excerpts from the book Laravel Up and Running by Matt Stauffer

View Formats
There are two formats of views in Laravel right out of the box:
example.blade.php
example.php

The first one is rendered by the Blade engine, while the latter is rendered by the PHP engine. They both reside in resources/views/.

View Loading Mechanism
Three ways to load view;
-view()
-View::make()
-Injecting with Illuminate\View\ViewFactory

Simple View Usage:

Route::get('/,function(){ return view('home'); });

Passing variable to view
Route::get('work',function(){ return view('tasks.index') ->with('tasks',Task::all()); });

The above closure loads the resources/views/tasks/index.blade.php or resources/views/tasks/index.php view and passes a single variable name tasks with the result of the result of the Task::all() eloquent method.

Using View Composers to share variables with every view
view()->share('view_variable','view_value');

L is for Laravel; Routes

Bijay Kumar Pun — Tue, 28 Apr 2020 11:23:40 +0000

Excerpts from the book Laravel Up and Running by Matt Stauffer

Route naming convention

resourcePlural.action

Eg.
photos.index
photos.create
photos.edit

Route groups

Route groups allow grouping several routes together, and apply shared configuration settings

Defining a route group

Route::group([],function(){ Route::get('hello',function){ return 'hello'; }); Route::get('world',function(){ return 'world'; }); });

Though there is no difference in separating the routes in above group, the square brackets passed as first parameter allows to pass in various configuration that can be applied to the entire route group!

Note: The function passed in as second parameter above is called closure; Laravel's implementation of anonymous function.

Another use of Route Group is the use of Middlewares.
Ex. Restricting a group of routes to logged-in users only

Route::group(['middleware'=>'auth'],function(){ Route::get('dashboard',function(){ return view('dashboard'); }); Route::get('account',function(){ return view('account'); }); });

What above code does is users need to be logged in to the application to view the dashboard or the account page.

Instead of attaching middlewares to the routes definition,it is better to attach directly to the controllers.

String that is passed in the middleware() method is the middleware, which can me chained with modifier methods only() and except() to define which method will receive the middleware

Eg.
class DashboardController extends Controller { public function __construct() //constructor method { $this->middleware('auth'); $this->middleware('admin-auth')->only('admin'); //or ->except('admin'); } }

Path Prefixes
Route groups can also be used to simplify path prefixes.
Eg. if the site's api is prefixed with /api:
Route::group(['prefix'=>'api'],function(){ Route::get('/',function(){ //Handles the path /api }); Route::get('users',function(){ //Handles the path /api/users }); });

Note: /api represents the root of the prefixed group in above example

What's inside /etc/apt/sources.list

Bijay Kumar Pun — Wed, 22 Apr 2020 17:22:55 +0000

And also quite possibly inside /etc/apt/sources.list.d/

Upfront, the /etc/apt/source.list is a configuration file for Linux's Advance Packaging Tool, that holds URLs and other information for remote repositories from where software packages and applications are installed.
Same goes with files inside /etc/apt/sources.list.d/.

Basically, when an installation command is executed, eg. apt-get install <package_name> then the Package Management System looks inside /etc/apt/sources.list and /etc/apt/sources.list.d/ for the remote repository link, and searches for the desired application to be downloaded.

" One of the reasons why there are two places for list instead of one, is in order to make sure data are not overwritten/lost during a system update. /etc/apt/source.list may be overwritten in update as this tend to happen with /etc/profile. That is also why custom configurations that generally goes inside /etc/profile file are preferably placed inside /etc/profile.d/ directory. "

A single link inside /etc/apt/sources.list file looks like this:
deb-src http://security.ubuntu.com/ubuntu eoan-security universe

On interpreting individual word:
deb-src

debian source files that needs to be compiled. It can also be deb, which means precompiled debian source files.

http://securty.ubuntu.com/ubuntu

The URL where the repository is stored

eoan-security

The version name of the repository

universe

How the software is available to end users
It can be one of Main, Restricted, Universe or Multiverse

Overall:
deb (or deb-src) address distribution_name package_type_list

Manually downloading a software package using apt

Bijay Kumar Pun — Wed, 22 Apr 2020 16:55:02 +0000

Packages are generally installed with below command:
apt-get install <package_name>
apt install <package_name>

Using the --download-only option will only download the package and not install it
apt install --download-only <package_name>

The downloaded files are inside /var/cache/apt/archives

The package can then be manually installed with dpkg -i <package_name>

Be warned it may cause dependency resolution error for a number of different reason:

The --download-only option only downloads the package and not the dependencies
dpkg can not resolve dependency, which is also why apt or apt-get were built on top of it to solve this and some other drawbacks.

Ditching apt-get for apt

Bijay Kumar Pun — Wed, 22 Apr 2020 16:35:07 +0000

Well not really ditching, but if we are to believe in linux command manuals, then apt is being encouraged over apt-get, not that apt-get is being deprecated in any sense.

I like to think of apt as a churned down version of apt-get and apt-cache. I have been regularly using apt-get. apt-cache, however, is a different story.
A quick man apt-cache tells me apt-cache performs a wide variety of operations on APT's package cache. I know APT stands for Advance Packaging Tool, and is something the debian based linux distros use for compiling and installing software packages. apt-cache, on further google search, seems to do 'stuffs' with the packages in the remote repository.

Anyway, apt has command lines most frequently used in both apt-get and apt-cache. apt tends to make performing task easier for "end users". We can think of apt-cache and apt-get as something that works on lower level than apt.

Again, point to note is that apt-cache and apt-get are like the front end to the debian's dpkg tool, which is the core tool of the Package Management System. The dpkg tool can, however, only work with locally existing software packages. It means it cannot itself download software packages from remote repositories. To overcome this, we have many other tools built on top of dpkg, out of which, and not very surprisingly, apt-get and apt-cache are some of those. And when apt-get and apt-cache are again 'combined' in a sense, we get apt.

Linux shells: interactive/non-interactive, login and non-login

Bijay Kumar Pun — Tue, 21 Apr 2020 17:31:17 +0000

Courtesy of chaos at Stack Exchange
Link:
https://unix.stackexchange.com/questions/170493/login-non-login-and-interactive-non-interactive-shells

login shell: A login shell logs you into the system as a specific user, necessary for this is a username and password. When you hit ctrl+alt+F1 to login into a virtual terminal you get after successful login: a login shell (that is interactive). Sourced files: /etc/profile and ~/.profile for Bourne compatible shells (and /etc/profile.d/*) ~/.bash_profile for bash /etc/zprofile and ~/.zprofile for zsh /etc/csh.login and ~/.login for
non-login shell: A shell that is executed without logging in, necessary for this is a current logged in user. When you open a graphic terminal in gnome it is a non-login (interactive) shell. Sourced files:
/etc/bashrc and ~/.bashrc for
interactive shell: A shell (login or non-login) where you can interactively type or interrupt commands. For example a gnome terminal (non-login) or a virtual terminal (login). In an interactive shell the prompt variable must be set ($PS1). Sourced files:
/etc/profile and ~/.profile
/etc/bashrc or /etc/bash.bashrc for
non-interactive shell: A (sub)shell that is probably run from an automated process you will see neither input nor output when the calling process don't handle it. That shell is normally a non-login shell, because the calling user has logged in already. A shell running a script is always a non-interactive shell, but the script can emulate an interactive shell by prompting the user to input values. Sourced files:
/etc/bashrc or /etc/bash.bashrc for bash (but, mostly you see this at the beginning of the script: [ -z "$PS1" ] && return. That means don't do anything if it's a non-interactive shell).
depending on shell; some of them read the file in the $ENV variable.

Linux Test Session: $PATH

Bijay Kumar Pun — Tue, 21 Apr 2020 17:22:05 +0000

To know pathname of file or link that is executed in current environment, use which

To add a path variable use export

we can also use . to add the current directory path to the PATH variable
$export PATH=$PATH:.

Path variable can both be prepended or appended, and they are separated by :

All changes, however, is temporary. These path variables are deleted when the user signs out, or when the shell is closed.

To make this permanent, the export command needs to be executed every time the system boots. This can be done in two distinct ways:

1.Via existing files:

when we login to the linux system, the login shell looks for five different startup files to process the commands from.

/etc/profile
(for login shell)
The main and the default startup file
All users execute this file
$HOME/.bash_profile
$HOME/.bash_login
$HOME/.profile
(interactive shell doesn't process .profile file)
$HOME/.bashrc
(for interactive shell)
This is run from one of the other above three files

When one of the above four files is encountered, it is executed first, while any file after that is ignored!

2.Via creating a new .sh file

Create a new .sh file inside /etc/profile.d/ with the export command. This file is executed every time /etc/profile is executed. One advantage of adding an environment variable this way is data will not be lost when system is updated. Eg. /etc/profile may be reset during system update.

Finally, execute source command to make the changes apparent to the current shell.
Eg.
source ~/.bash_profile
source ~/.bashrc

Bash shell can be started in three ways:

default login shell at login time
Interactive shell that is started by spawning a subshell
Non-interactive shell to run a script