DEV Community: Chukwunazaekpere

Deploying Multiple NodeJS Servers on a Single DigitalOcean Droplet; Managed by PM2, Without Using an ecosystem.config.js file

Chukwunazaekpere — Wed, 05 Oct 2022 17:17:26 +0000

Firtly, my servers are nginx-based and certified by certbot - let's encrypt. Hence, I'm assuming you're acquainted with this setup. Now, unto the epicenter of our problem.
A major problem using the prescribed (best-practise) procedure for deploying several NodeJS server instances on digitalOcean (referred to as DO hereafter), is that; environment variables become difficult to locate; once the server is started. This becomes a bigger trouble when there are more than one servers, to be used on a single droplet. I circumvented through this challenge, by doing the following;

a) Create various folders, on DO named w.r.t how you'd like PM2 to identify these servers; i.e. if you've got 3 servers to deploy on a single droplet, you'd say;
e.g plutonium_server, neptunium_server, promethium_server

b) clone your repo into each folder: git clone https://github.com...

c) cd into the repo; sudo nano package.json

d) in your start script, enter: "pm2 start <your start file>"
e.g: "pm2 start ./backend/dist/index.js"

ensure your package.json file has got an engines object; (recommended for deployment)
e.g engines: {
                "node": "18.1.0",
                "yarn": "1.22.18"
             }

e) save the file by saying; 
ctrl + x then shift + y then enter

f) install your project dependencies; yarn install

g) copy your environment variables; create the environment variable file as you have it locally 
e.g: cd backend/src/config && sudo nano .env

h) copy and paste the contents of the local env-file into the newly server .env file you can call the env file whatever 

name you perceive; but as programmed locally. Just ensure the extension is appended. Repeat step e.

i) spin the server: yarn start

j) rename the server: pm2 restart 0 --name plutonium_server

k) you can now run pm2 logs or pm2 list for monitoring

l) subsequently, all you need do next time is: pm2 start plutonium_server, pm2 stop plutonium_server etc

m) replicate this procedure; to deploy other instances.

Thanks for reading.

Custom Routes In Flask Using Flask Restful

Chukwunazaekpere — Mon, 25 Jul 2022 12:04:00 +0000

In this short tutorial, I'll illustrate how we can use flask to write an API; with the following goals:
a) Defining custom routes
b) Separating routes, controllers, models, validators etc into their respective folders

I'll at a later time put up a post to aid us in understanding my style of architecture, when it comes to Flask.
Defining Custom Route
Let's take a hypothetical blog-site for instance. I'm assuming in your project you've got a users, comments and posts folder. The reason for this, bothers on the fact that you'd want to separate the models, routes, controllers etc for posts and users. Your users controllers would definitely concern, but not limited to; registration, login, forgot-password, change-email, etc. While those for posts would include edit-post, delete-post, create-post etc. You would agree with me that clustering this transactions in one file, would definitely wear you out, if not possibly, get you insane. FurhterMore, since Flask-Restful only supports the known HTTP-verbs, "GET", "POST" etc it'd as well not sound manageable, to define new classes for each post, delete etc operations respectively. One would think that to achieve a login and register transaction would require different classes as below (in your routes.py file);

routes.py
class LoginView(Resource):
    logging.basicConfig(level=logging.INFO)
    logging.info("Entered the LoginView...")

    def login(self):
        print("\n\t Login route....")

class RegisterView(Resource):
    logging.basicConfig(level=logging.INFO)
    logging.info("Entered the RegisterView...")

    def register(self):
        print("\n\t Register route....")

This problem can simply be solved, pythonically, as below;

from flask_restful import (
    Resource,
    request
)
import logging

from ..models.models import Users
class AuthViews(Resource):
    logging.basicConfig(level=logging.INFO)
    logging.info("Entered the auth views...")

    def login(self):
        print("\n\t Login route....")


    def register(self):
        print("\n\t Register route....")


    def post(self):
        print("\n\t Login-Data: ", request.data)
        print("\n\t Login-Data: ", request.url)
        url = request.url
        if "login" in url:
            login = self.login()
        elif "register" in url:
            register = self.register()
        elif "forgot-password" in url:
            register = self.forgot_password()
        else:
            etc....

auth_routes = ["/auth/register", "/auth/login"]

Then in your app.py file, you'd register your resource like so;

...
from routes.routes import AuthViews, auth_routes
app = Flask(__name__)
api = Api(app)
api.add_resource(AuthViews, *auth_routes)

Thanks. Next, I'll show you how to define models, using PyMongo.

Deploying a MERN (Typescript) project: on Digitalocean, Netlify and Mongo-atlas; with custom domains.

Chukwunazaekpere — Mon, 30 May 2022 10:15:08 +0000

Hi. It's been a while. With this post, I'll be teaching you how to deploy a MERN-Typescript application; with what I call 'branched deployment' and using your preferred domain names on these servers. I'm a fullstack developer; hence; efficiency and optimisation is my watch-word. The 'branched deployment simply imply, that; I've got the backend (built with NodeJS-Express) seated at digitalocean; the frontend (built with ReactJS) seated at netlify's server and my database (MongoDB) seated at Mongo-atlas. Crazy, right?
Now; there are definitely great advantages with the 'branch deployment'; these advantages simply rests on the basis of having a loosely-coupled system, which ensures a tightly secured sequence for all sides (BE, FE and DB) of the application. So, to reach my backend, you'd need my security sequence, which is different for the frontend(FE) as well as database(DB); as compared to having everything at a place where if I could access the security sequence, then I've got full control of all sides. With this mode of deployment, manageability, optimisation, reduction in downtime, elimination of the 'series-effect' and more are some of the priviledges which this mode earns a fullstack-developer and most importantly, sanity. The series-effect happens, when a code-break in the FE, BE or DB at anytime in development or production, affects every sides of the application. But, with this mode of deployment, that can never be observed. This is not to say that there aren't disadvantages to this mode of deployment. However, the trade-offs are worth it, for the magnitude of advantages being earned. Secondly, this mode is what I'd recommend for teams.
I'll discuss in a separate post, how to follow on this mode of deployment from development stage; so as to achieve this purpose. But, for now, I'll assume the following;
1) You've got the application prepared and ready to deploy.
2) You've got your functioning account on all these servers; DigitalOcean, Netlify, Mongo-Atlas
3) You're acquainted with Linux commands; as this would enable you control your linux server from your workstation (or local IDE), rather than DO's bash or your dashboard.
I'll make this post a series; so as not to make it tiring for anyone who loves to follow this path of deployment. Firstly; I'll discuss the deployment sequence of the backend (server). The following are the procedures towards the proper deployment of the server;
a) SSH activation of our droplet, to enable us remotely communicate to the droplet from our IDE
b) Creating another root user, updating and upgrading the linux (Ubuntu OS).
c) Installing current or required version of NodeJS and yarn
d) Git-clonning the repo where our project has been pushed to our droplet
e) Creating as well as hiding our environment (*.env) files on the droplet
f) Installing the pm2-package, and editing our package.json file so as to start the application with the package.
g) Installing the node_modules (package dependencies) of our application
h) Installing Nginx to enable us create custom-domains for our FE and DB
i) Securing our BE with certbot
There's a whole lot; that I know. But; I'll take it gradual as much as I can; with the required illustrations where necessary. That should do for now; please, stay tuned for the updates to follow. Thanks

Writing Custom Routes in Django RestFrameWork (DRF) Viewsets.

Chukwunazaekpere — Wed, 01 Dec 2021 09:31:38 +0000

Django RestFrameWork (DRF) has proven to be the most valuable and helpful library for Django. It's viewset capability is an admirable resource to enable backend devs define robust urls with embedded route structures. These routes would have required you to write a unique url; but thanks to the resourceful context of viewsets from DRF. I'd be sharing some helpful insight to harness your use of the DRF. This would be categorised on the following:
i) Decorators
ii) custom routes
Let's get on then.
Now, let's take an authentication url for instance, the functionalities you'd definitely want to incorporate, would include, but definitely not exclusive to the following;
a) signup
b) signin
c) forgot password
Personally, I'd include more routes (according to Django's legacy or rules: explicit is better than implicit);
d) OTP
e) user-details
You could have some other you'd like to include, provided they fall under the collective action of authentication and authorizaion.
Now, here comes the question: wouldn't it be cumbersome, that you'd have to write a unique view and then, define a unique url for all these authentication actions? definitely, it would (I don't need to be told).
That's what DRFs' viewsets helps us solve; and as the name implies, "view-sets". You gerrit? Sure you did.
Let's define an API then, using the DRF's viewsets. I'll section the procedures as below;
i) Start a new project I'll assume you're acquainted with django's best practices about starting a new project i.e creating a virtual environment, defining env files etc. Secondly, the folder structure, for a newly created app in django comes with a views.py file. You can rename that to viewsets.py.
ii) Define the viewset class for users (say users is an app on your django project):

from rest_framework import viewsets, status
from .serializers import UsersSerilizer # assuming you've also defined a serializer
from .models import Users # say you've got a users model
from rest_framework.decorators import action
from rest_framework.response import Response

class UsersViewSets(viewsets.ModelViewSet):
    queryset = Users.objects.all() # a queryset variable is mandatory
    serializer_class = UsersSerializer 
    permission_classes = []
    def create(self, request, *args, **kwargs): # ----- for creating a new user
        super().create(request, *args, **kwargs)

    def list(self, request, *args, **kwargs):  # ----- for listing all users
        super().list(request, *args, **kwargs)

    def update(self, request, *args, **kwargs):  # ----- for updating a user
        super().update(request, *args, **kwargs)

    @action(methods=["POST"], detail=False, url_path="forgot-    password")
    def forgot_password(self, *args, **kwargs):
        #... logic
        return Response(data=<whatever data>, status=status.HTTP_201_CREATED, content_type="application/json")

From the above code, it's obvious that the super keyword is referring to a the methods of a superclass; which implies that you can override those methods as required for your application use case. However, looking at the fourth method, its structure looks different compared to others. Thats a method, defining a custom url: forgot password.
The symbol @, denotes the syntax of a decorator (a function; you can read about decorators in python). This is the procedure for telling DRF that you'd like to define a custom url; because the default methods won't suffice.
The arguments include:
a) methods: what HTTP verb is this url performing?
b) detail: a boolean; tell DRF if this is a detail route i.e if the route construct would require a primary-key, unique email etc, to return a specific instance.
c) url_path: what would you like to call this route?
With the above configuration, you could as well include an otp-verification (just saying) view as well, handle the business logic and return a response (as always). The next step is registering this viewset,so as to be recognised by the app.
iii) Define a router.py file: this is the file from which we'd register all the viewsets in the app i.e you could have product_viewsets, authentication_viewsets, finance_viewsets etc. You'd register a viewset in like so:

from rest_framework import routers
app_router = routers.DefaultRouter()
# import the viewsets from your various app module
from users import viewsets as users_viewsets
# register your routers as 
app_router.register("auth or whatever you prefer (avoid trailing slashes)", users_viewsets.UsersViewSet, basename="auth")
#... other viewsets registration

This router.py file must be located in the same directory as the applications urls.py file.
iv) Connect the router.py file to the apps' urls.py file: finally, in the apps' urls.py file, register the router.py file like so:

from .router import app_router
from django.urls import path, include

urlpatterns = [
    path("your-site/", include(app_router.urls), 
]

we can therefore refer to our custom route as:

http://localhost:8000/your-site/auth/forgot-password # for the local server. Don't forget it's https, in production.

Let me know if there are places you find discontinuities. Thanks.

Finding out the RGB value of an image with python

Chukwunazaekpere — Mon, 25 Oct 2021 10:16:58 +0000

As a fulstack developer, challenges comes up in their very unfamiliar forms; hence, the need to be open minded and patient as a developer. I bring you the knowledge of seeking out the RGB or HEX values of an image; using python. So; say for instance, you were working on a mobile app (in my case) and a logo was given to you by the client; and he wants you to use the color codes on the logo as the primary colors for the app; however; without giving you the color codes for any of the colors on the logo. Let's get on then!!!
Step 1: Create a python script or module: If you're going to need the functionality of finding out colr codes on images, a python module would be preferable. Otherwise, create a singular script.
Step 2: Install the PIL library: install the python manage library. You could create a virtual environment or continue with the working workspace already active. The command below installs the PIL (python image library).

pip install pillow

Step 3: The code::

from PIL import Image
import os
filename = os.path.join(os.path.dirname(__file__), "your_image_filename.format")
# ensure that the image exists in your current working path

with Image.open(filename) as rgb_image:
    image_color = rgb_image.getpixel((30,30))
    print(image_color)

The RGB values are displayed; you can then copy to an image picker to get the HEX - values. Thank you!

Project setup for NodeJS-React using Typescript: Running both servers (Express and React) concurrently

Chukwunazaekpere — Wed, 13 Oct 2021 14:25:37 +0000

Developing, whilst seeing the changes update immediately is a feature which eases the programmer of any unplanned certainty as he or she gets to see the effect of each line of code on the frontend and backend. I'll be demonstrating how to setup a MERN project to run both the NodeJS and React servers concurrently. From hereon, I'll be referring to the backend as BE, frontend as FE and database as DB. I'll also be working from a linux environment. Not to worry, whenever ther's a command peculiar to linux, I'll indicate. Additionally, I'll be using yarn (Yet Another Resource Negootiator); you can as well use npm (node package manager). I'll always give the analogical comands for npm as well. Let's get started.
firstly, create a folder; I'll call mine projectOsmium.
a) cd into your project folder and create two folders like so;

mkdir {backend,frontend}

b) Acquiring the required files for the FE: cd into the frontend directory. I'll be working with typescript. Enter the command below to get a project structure with typescript template:

yarn create react-app <projectName> --template typescript
i.e yarn create react-app osmium --template typescript

c) Preparing package.json file to run both servers: cd out of the FE folder; you can simply do:

cd ..

Now lets get the required resources to run both servers.
i) Make a package.json file to hold our scripts, dependencies etc:

yarn init -y
or npm init-y

The above command will immediately create a package.json file for you. To add a tsconfig.json file, you'd enter:

tsc --init

The above command will create a tsconfig.json file for you.
However, the above command can only work, if you've got typescript installed. If you haven't, do:

yarn add -g typescript

d) Organising the tsconfig.json file:
the recommended key-value pair for the tsconfig.json file,is highlighted as below:

{
  "compilerOptions": {
    /* Visit https://aka.ms/tsconfig.json to read more about this file */

    /* Basic Options */
    // "incremental": true,                         /* Enable incremental compilation */
    "target": "esnext",                                /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', 'ES2018', 'ES2019', 'ES2020', 'ES2021', or 'ESNEXT'. */
    "module": "commonjs",                           /* Specify module code generation: 'none', 'commonjs', 'amd', 'system', 'umd', 'es2015', 'es2020', or 'ESNext'. */
    // "lib": [],                                   /* Specify library files to be included in the compilation. */
    // "allowJs": true,                             /* Allow javascript files to be compiled. */
    // "checkJs": true,                             /* Report errors in .js files. */
    // "jsx": "preserve",                           /* Specify JSX code generation: 'preserve', 'react-native', 'react', 'react-jsx' or 'react-jsxdev'. */
    // "declaration": true,                         /* Generates corresponding '.d.ts' file. */
    // "declarationMap": true,                      /* Generates a sourcemap for each corresponding '.d.ts' file. */
    // "sourceMap": true,                           /* Generates corresponding '.map' file. */
    // "outFile": "./",                             /* Concatenate and emit output to single file. */
    "outDir": "./backend/dist",                              /* Redirect output structure to the directory. */
    "rootDir": "./backend/src",                             /* Specify the root directory of input files. Use to control the output directory structure with --outDir. */
    // "composite": true,                           /* Enable project compilation */
    // "tsBuildInfoFile": "./",                     /* Specify file to store incremental compilation information */
    // "removeComments": true,                      /* Do not emit comments to output. */
    // "noEmit": true,                              /* Do not emit outputs. */
    // "importHelpers": true,                       /* Import emit helpers from 'tslib'. */
    // "downlevelIteration": true,                  /* Provide full support for iterables in 'for-of', spread, and destructuring when targeting 'ES5' or 'ES3'. */
    // "isolatedModules": true,                     /* Transpile each file as a separate module (similar to 'ts.transpileModule'). */

    /* Strict Type-Checking Options */
    "strict": true,                                 /* Enable all strict type-checking options. */
    // "noImplicitAny": true,                       /* Raise error on expressions and declarations with an implied 'any' type. */
    // "strictNullChecks": true,                    /* Enable strict null checks. */
    // "strictFunctionTypes": true,                 /* Enable strict checking of function types. */
    // "strictBindCallApply": true,                 /* Enable strict 'bind', 'call', and 'apply' methods on functions. */
    // "strictPropertyInitialization": true,        /* Enable strict checking of property initialization in classes. */
    // "noImplicitThis": true,                      /* Raise error on 'this' expressions with an implied 'any' type. */
    // "alwaysStrict": true,                        /* Parse in strict mode and emit "use strict" for each source file. */

    /* Additional Checks */
    // "noUnusedLocals": true,                      /* Report errors on unused locals. */
    // "noUnusedParameters": true,                  /* Report errors on unused parameters. */
    // "noImplicitReturns": true,                   /* Report error when not all code paths in function return a value. */
    // "noFallthroughCasesInSwitch": true,          /* Report errors for fallthrough cases in switch statement. */
    // "noUncheckedIndexedAccess": true,            /* Include 'undefined' in index signature results */
    // "noImplicitOverride": true,                  /* Ensure overriding members in derived classes are marked with an 'override' modifier. */
    // "noPropertyAccessFromIndexSignature": true,  /* Require undeclared properties from index signatures to use element accesses. */

    /* Module Resolution Options */
    "moduleResolution": "node",                  /* Specify module resolution strategy: 'node' (Node.js) or 'classic' (TypeScript pre-1.6). */
    // "baseUrl": "./",                             /* Base directory to resolve non-absolute module names. */
    // "paths": {},                                 /* A series of entries which re-map imports to lookup locations relative to the 'baseUrl'. */
    // "rootDirs": [],                              /* List of root folders whose combined content represents the structure of the project at runtime. */
    "typeRoots": ["./backend/src/types", "../node_modules/@types"],                             /* List of folders to include type definitions from. */
    // "types": [],                                 /* Type declaration files to be included in compilation. */
    // "allowSyntheticDefaultImports": true,        /* Allow default imports from modules with no default export. This does not affect code emit, just typechecking. */
    "esModuleInterop": true,                        /* Enables emit interoperability between CommonJS and ES Modules via creation of namespace objects for all imports. Implies 'allowSyntheticDefaultImports'. */
    // "preserveSymlinks": true,                    /* Do not resolve the real path of symlinks. */
    // "allowUmdGlobalAccess": true,                /* Allow accessing UMD globals from modules. */

    /* Source Map Options */
    // "sourceRoot": "",                            /* Specify the location where debugger should locate TypeScript files instead of source locations. */
    // "mapRoot": "",                               /* Specify the location where debugger should locate map files instead of generated locations. */
    // "inlineSourceMap": true,                     /* Emit a single file with source maps instead of having a separate file. */
    // "inlineSources": true,                       /* Emit the source alongside the sourcemaps within a single file; requires '--inlineSourceMap' or '--sourceMap' to be set. */

    /* Experimental Options */
    // "experimentalDecorators": true,              /* Enables experimental support for ES7 decorators. */
    // "emitDecoratorMetadata": true,               /* Enables experimental support for emitting type metadata for decorators. */

    /* Advanced Options */
    "skipLibCheck": true,                           /* Skip type checking of declaration files. */
    "forceConsistentCasingInFileNames": true        /* Disallow inconsistently-cased references to the same file. */
  },
  "exclude": ["../node_modules"],
  "include": ["./backend/src"]

}

In the tsconfig.json file above, the rootDir and outDir are important. They tell typescript where to get the source codes and store the transpiled javascript files, respectively. Hence, in your BE folder, ensure you have created the src folder. Immediately you run the command "yarn dev", the "dist" folder will be created automatically.
e) Setting-up scripts to run servers: in your package.json file, create the scripts object and enter the following:

.....
"scripts": {
    "client": "yarn start --prefix frontend",
    "server": "nodemon ./backend/dist/index.js",
    "dev": "rm -rf ./backend/dist/index.js && tsc && concurrently \"yarn server\" \"yarn client\",
    "start": "node ./backend/dist/index.js"
}
.....

e) Adding the required devDependencies libraries:
the required devDependencies libraries can be gotten as shown below:

yarn add nodemon concurrently -D // the -D flag implies that the resources are devDependencies

You can now run:

yarn dev

Connect your DB and other resources.
Thank you for reading!

Setting-up a Django project for production

Chukwunazaekpere — Tue, 05 Oct 2021 06:43:24 +0000

Setting up a django project is an expertise worthy of mastery. This is pretty important because; lousiness can be permitted and forgiven, whilst developing locally. However, you would definitely pay dearly, if an attacker should trail your backend-system. This trailing becomes feasible, due to the fact that; confidential variables e.g SECRET_KEY, DATABASE_URL, STATIC_URL, MEDIA_URL or some confidential link etc, required to be kept secret; in a .env file, was mistakenly loosed in the production code. A single link being exposed, can give an idea into several other links or services, to an experienced attacker (cracker). Hence, a proper project setup, is of utmost priority, from the inception of the project. A great advantage to this, is that once setup, it becomes very easy to make reference, from whatever point or line of code in the project. However, this might feel cumbersome, while starting out. Nevertheless, this is unnegotiable as a matter of fact. I'll be working from a Linux environment and hence certain command-line commands will definitely be unique to the platform. You can always lookout for the analogical command specific to your platform. However, these commands will only be used when there are no alternatives. Onward then!
In sequence, let's outline the procedures:
a) Create a folder; I'll call mine projectTungsten

mkdir projectTungsten

b) Python version: for the moment, the most compatible python version recommended (on the basis of the required dependencies; pscopg2, django-heroku etc) for now, is python 3.8. If you've not got python 3.8 installed, get installed.

for Linux, open a terminal and run: 
a) sudo apt-get update
b) sudo apt-get install python3.8

If the above doesn't work, get on the AskUbuntu website and ask your question.
c) Setting up a virtual environment: since we would want to build with python3.8, it implies that our virtual environment must be created using python3.8. Hence, 'cd' (cd: change directory) into your projectTungsten

a) cd projectTungsten
b) python3.8 -m venv <environment name>
i.e python3.8 -m venv tungsten_admin

d) Activating the virtual environment:

source tungsten_admin/bin/activate

If everything has been correctly implemented, the above command shows up on your terminal, with the environment name in parenthesis.
e) Installing the required packages: the foremost packages required includes the following;

pip install psycopg2 gunicorn django-heroku python-dotenv django django-cors-headers

psycopg2: we'll be talking to a postgres database and require a database cursor to help us do so.
gunicorn: a Python WSGI server important, when our application goes live
django-heroku: we'll be pushing the app to heroku servers and this would aid in automatically configuring our Django application to work on Heroku.
python-dotenv: deal with environment variables
django-cors-headers: configure CORS policy

f) Configure settings for development and production:
in your project directory, cd into tungsten_admin; you'll find another folder: tungsten_admin as well. It contains settings.py, urls.py, wsgi.py etc. In this folder, create a new folder: settings. In this settings folder, create three new files:

touch {base_settings,prod_settings,dev_settings}.py

you could as well have renamed your default settings file as base_settings.py.
g) Create a '.env' file : this file should be cited in the same directory, with the manage.py file. Cut the "SECRET_KEY" in your base_settings.py file and paste in your .env file. This is where every secret detail; database, url, api keys etc should be kept.
h) Create a '.gitignore' file : this file should be cited in the same directory, with the manage.py file. In this file, add *.env, pycache, *.sqlite3 etc any other file you wouldn't want to commit to the repository.
i) Resourcing manage.py and wsgi.py: the manage.py file is used locally(in development), while the wsgi.py file, is same with the manage.py, however, is used in production by the server.
in your manage.py file, do:

"""Django's command-line utility for administrative tasks."""
import os
import sys
import dotenv

def main():
    """Run administrative tasks."""
    dotenv.load_dotenv(
        os.path.join(os.path.dirname(__file__), '.env')
    )

    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'tungsten_admin.settings.dev_settings')

    if os.getenv("DJANGO_SETTINGS_MODULE"):
        os.environ["DJANGO_SETTINGS_MODULE"] = os.getenv("DJANGO_SETTINGS_MODULE")

    # print("\n\t Get env: ", os.getenv("DJANGO_SETTINGS_MODULE"))
    try:
        from django.core.management import execute_from_command_line
    except ImportError as exc:
        raise ImportError(
            "Couldn't import Django. Are you sure it's installed and "
            "available on your PYTHONPATH environment variable? Did you "
            "forget to activate a virtual environment?"
        ) from exc
    execute_from_command_line(sys.argv)


if __name__ == '__main__':
    main()

in wsgi.py file, do:

import os
import dotenv

from django.core.wsgi import get_wsgi_application

dotenv.load_dotenv(
    os.path.join(os.path.dirname(__file__), '.env')
)

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'tungsten_admin.settings.dev_settings')

if os.getenv("DJANGO_SETTINGS_MODULE"):
    os.environ["DJANGO_SETTINGS_MODULE"] = os.getenv("DJANGO_SETTINGS_MODULE")

application = get_wsgi_application()

in your .env file, ensure you have defined the variable:

DJANGO_SETTINGS_MODULE = tungsten_admin.settings.dev_settings

j)Assigning variables: in your dev_settings and prod_settings.py files,you should do

import * from base_settings

Then, define your development variables e.g database setup, static, media etc in the respective files as you prefer.

You can spin up your local server: python manage.py runserver

Like I said earlier,it's a tedious process; however, one that would bring back fruits greater than you could imagine. Let me know your difficulties and I'd be right on time to respond. Thank you.

Writing Responsive Components in React

Chukwunazaekpere — Wed, 22 Sep 2021 09:01:40 +0000

In this post, we'll get to understand the implementation of certain hooks in react and as well, making a custom-hook. The hooks of concern in this post are; "useEffect", "useRef" and "useState". I'll then illustrate, how these hooks can be unified into making a custom hook, for making components responsive. It should be understood that hooks can only be used in functional components.
Secondly, the name of any react-hook is descriptive; just by "syllabilising" the word into two;
use: which symbolises that the function is a hook and the other half, e.g Effect, State, Ref, Memo etc, indicates exactly the action which the hook in question carries out.
Thirdly, hooks got their rules. Therefore, it is important to first understand these rules, as they apply to all hooks, irrespective of the use-case(s).
Let's get on then, by understanding what the aforementioned hooks do and their place(s) of use.
Effect (useEffect): as the name indicates, this hook is basically used to implement an effect: re-rendering of the component, w.r.t the alteration observed in the variable(s) in the dependency array. This implies that; if you'd like for instance, your component to be aware that a new user just registered, so you could render this new user, then there must be a variable, either unique to the component or in the global state (context-API or Redux) that is made aware of this event and hence is kept in dependency array, to trigger a re-render of the component. The general form of usage is like so;

    useEffect(() => {
      //....call an API or something else
    }, [variable] // the dependency array);

State (useState): regulates the state of a variable in a functional component. Say for instance, I'd like to submit a signup form. Then, I could do the below;

interface SignupDataInterface {
    firstname: string,
    lastname: string,
    email: string,
    phone: string,
    password: string,
}

   const [signupData, setSignupData] = useState<SignupDataInterface>({
                                          "firstname": "",
                                          "lastname": "",
                                           "email": "",
                                           "phone": "",
                                           "password": "",
                                           })

The useState hook uses an array "destructuring" feature to provide the variable; signupData and a method to alter the value(s) of this variable. You shouldn't alter the variable-values through any means; but by the use of the method, provided by useState.
Ref (useRef): say you would like to keep the value of a variable after a re-render, the useRef is mostly used for this purpose i.e keeping track of the previous value of a variable. It is used like so;

const initialScreenWidth = useRef(window.innerWidth).current;

The above variable holds the initial screen width of a device irrespective of a re-render. Other use case for the useRef-hook exists. Just do the findings!.
Now, lets create our custom-hook. The reason for this is to implement responsiveness. It then implies that we would want our application to be aware of the devices' dimensions in real time.
Let's write this hook; I called it useWindowDimension (note the first word; "use"):

import { useEffect, useState, useRef } from "react";

interface DimensionInterface {
    width: string | number,
    height: string | number
};

const useWindowDimension = () => {
    // First get the devices dimensions as default value.
    const currentWidth = useRef(window.innerWidth).current;
    const currentHeight = useRef(window.innerHeight).current;

    // This is the effective way of doing it, as opposed to     setting a random value which definitely, isn't true for all devices.
    const [windowDimension, setWindowDimension] = useState<DimensionInterface>({
        width: currentWidth,
        height: currentHeight
    });

// As the devices dimensions change at any time, get the current dimension and set the new dimension as the prevai
    const getDimension = () => {        
        setWindowDimension({
            width: window.innerWidth,
            height: window.innerHeight
        });
    };
    useEffect(() => {
        window.addEventListener("resize", e => getDimension());
        return () => window.removeEventListener("resize", e => getDimension());
    }, []);

    return windowDimension;
};


export default useWindowDimension;

Now, say we would like our p-tags to show headers sizes at varying width, we'd write a component for P-tags;

import React, {HTMLProps} from 'react'
import useWindowDimension from "../../helpers/useWindowDimension";

interface Props extends HTMLProps<any> {

};

const ParagraphHeaderComponent = (props: Props) => {
    const { width } = useWindowDimension();

    return (
        <p style={{display: "flex", width: "100%", justifyContent: "center", alignItems: "center", fontSize: width > 500 ? "27px" : "23px", fontFamily: "serif"}}>
            {props.children}
        </p>
    );
};


export default ParagraphHeaderComponent;

With this, whenever we're on mobile devices, our application is aware and certainly adjusts the header size.
We could as well hide a sidebar component with this or navbar-links, whilst exposing the hamburger button etc.

Environment Variables (i.e hiding variables) in react-native-typescript

Chukwunazaekpere — Fri, 10 Sep 2021 00:52:13 +0000

With some understanding about ethical-hacking, it should be made obvious, as to how much sensitive information should be guarded, as developers, in our codes. Environment variables are hence, conceptualised, on this basis. In react-native-typescript (typescript basically), the presence of a variable in a code, must be intentionally thought about. This defines the type and consequently, the type of operation permissible on such variable.
In this post, I'll be showing you how to hide a dummy API-key. Onwards then, let's install react-natve-dotenv library, with the command below:

yarn add react-native-dotenv
or npm install react-native-dotenv

In our src folder, create a "types" folder. Create a file: "env.d.ts".
In this file, we'd define the variable name as will be used in our code and its type as well:

decalre module "react-native-dotenv" {
    export const API_KEY: string;
    export const REMOTE_BASE_URL: string;
    export const LOCAL_BASE_URL: string;
    .....
}

In our babel.config.js file, we'll add the following

module.exports = {
    presets: [
    'module:metro-react-native-babel-preset', // present by default
  ],
plugins: ["module:react-native-dotenv", {
    moduleName: "react-native-dotenv",
    allowUndefined: false
}]
}

In our tsconfig.json we'll add:

{
    ...
    "typeRoots": ["./src/types"], 
    ...
}

Then we'll define our variables and values in our ".env" file. Hence, create a ".env" file, this must sit outside your src folder i.e where your package.json file is located. In here define the variables and corresponding values;

    API_KEY = something##anything
    ...

With all these in place, one last step:
I'd create a config folder in my src folder and then add an env.ts file in the config folder. The reason for this is that; react-native has a "DEV" variable that tells if the app is in production or development mode.
Therefore, in our env.ts file, we'd do the following;

import {
    API_KEY,
    REMOTE_BASE_URL,
    LOCAL_BASE_URL
    ...
} from "react-native-dotenv;

const devEnvVariables = {
   API_KEY,
   LOCAL_BASE_URL
}

const prodEnvVariables = {
   API_KEY,
   REMOTE_BASE_URL
}

export interface EnvsInterface {
    API_KEY,
    REMOTE_BASE_URL,
    LOCAL_BASE_URL
}

// If we're in dev use "devEnvVariables" otherwise, use "prodEnvVariables"
export default __DEV__ ? devEnvVariables : prodEnvVariables;

in our code, say loginScreen.tsx, we'll do the following;


    
import envs, { EnvsInterface } from "./config/envs";
const { BASE_URL, API_KEY } = envs;
// as preffered
const handleSubmitForm = async () => {
    await axios.post(${BASE_URL}/login, {...loginData},       {headers... API_KEY)
}

Uploading images to Cloudinary in react-native-typescript, using react-native-image-picker

Chukwunazaekpere — Thu, 09 Sep 2021 05:45:09 +0000

First things first; let's setup a cloudinary account on which we'll be saving our images. If you've not gotten an account with cloudinary, check this out: "https://cloudinary.com".
Registration is easy! After the registration phase, you'll be directed to your dashboard. On this dashboard, for now, we need information on the following: upload-presets and cloud-name.
Your cloud-name is directly on the top-left corner of your dashboard(once opened). For the upload-preset, do the following:
On the top-right corner of your dashboard,
a) hit the gear icon.
b) Hit on the upload tab.
c) Scroll downwards to the upload preset section. Cloudinary has an upload-preset for you already. All you need do, is; either add a new one or edit what you've got already. It's okay to edit. What we're after, is to change the "signing mode" feature to "unsigned"; which will enable uploads without authentication. However, uploads are restricted if the upload-preset and cloud name aren't provided.
Either ways, ensure that this variables live in your ".env"-file (check out my post on "Environment variables (hiding variables) in react-native).
Codes:
Below is the code to be called upon during an upload:

<TouchableOpacity onPress={() => selectFile()} style={styles.packageImageButton}>                                        
                 //...other logic ...
               </TouchableOpacity>


    
const selectFile = async () => {
        setCloudinaryImage("");
    // Select Image to upload
    // "includeBase64" ensures that images can be converted into forms, readable by cloudinary.
    launchImageLibrary({mediaType: "photo", includeBase64: true, maxHeight: 400, maxWidth: 400}, async e => {           
    packageDetails["Package Image"] = "";
    const base64Image = e.assets![0].base64;
const base64Img = `data:image/jpg;base64,${base64Image}`;

//======Set the cloudinary details for the package image===
            const uploadedImageData = new FormData();
uploadedImageData.append("upload_preset",CLOUDINARY_UPLOAD_PRESET);
uploadedImageData.append("file", base64Img);
     setPackageDetails({
        ...packageDetails,
        "Package Image": base64Img as string
     });
    setCloudinaryImage(uploadedImageData as any);
//===============================================
        });
const uploadedImage = await axios.post(${CLOUDINARY_BASE_URL}/${CLOUDINARY_CLOUD_NAME}/image/upload/, cloudinaryImage);
packageDetails["Package Image"] = uploadedImage.data.secure_url;
    };