Tuesday, December 31, 2019

What is Virtual Environment Wrapper



virtualenvwrapper is a set of extensions to Ian Bicking’s virtualenv tool. The extensions include wrappers for creating and deleting virtual environments and otherwise managing your development workflow, making it easier to work on more than one project at a time without introducing conflicts in their dependencies.

Below are the features

Organizes all of your virtual environments in one place.
Wrappers for managing your virtual environments (create, delete, copy).
Use a single command to switch between environments.
Tab completion for commands that take a virtual environment as argument.
User-configurable hooks for all operations (see Per-User Customization).
Plugin system for creating more sharable extensions (see Extending Virtualenvwrapper).

pip install virtualenvwrapper


$ export WORKON_HOME=~/Envs
$ mkdir -p $WORKON_HOME
$ source /usr/local/bin/virtualenvwrapper.sh
$ mkvirtualenv env1
Installing
setuptools..........................................
....................................................
....................................................
...............................done.
virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env1/bin/predeactivate
virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env1/bin/postdeactivate
virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env1/bin/preactivate
virtualenvwrapper.user_scripts Creating /Users/dhellmann/Envs/env1/bin/postactivate  New python executable in env1/bin/python
(env1)$ ls $WORKON_HOME
env1 hook.log

Now we can add softwares into this virtual environment

(env1)$ pip install django
Downloading/unpacking django
  Downloading Django-1.1.1.tar.gz (5.6Mb): 5.6Mb downloaded
  Running setup.py egg_info for package django
Installing collected packages: django
  Running setup.py install for django
    changing mode of build/scripts-2.6/django-admin.py from 644 to 755
    changing mode of /Users/dhellmann/Envs/env1/bin/django-admin.py to 755
Successfully installed django



References:
https://virtualenvwrapper.readthedocs.io/en/latest/

What is a typical format for Changelog file


What is a typical format for Changelog file

What is a change log:
A changelog is a file which contains a curated, chronologically ordered list of notable changes for each version of a project.

Why keep a changelog?
To make it easier for users and contributors to see precisely what notable changes have been made between each release (or version) of the project.

Who needs a changelog?
People do. Whether consumers or developers, the end users of software are human beings who care about what's in the software. When the software changes, people want to know why and how.

# Changelog
All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

Example is below.

## [Unreleased]

## [1.0.0] - 2017-06-20
### Added
- New visual identity by [@tylerfortune8](https://github.com/tylerfortune8).
- Version navigation.
- Links to latest released version in previous versions.
- "Why keep a changelog?" section.

### Changed
- Start using "changelog" over "change log" since it's the common usage.
- Start versioning based on the current English version at 0.3.0 to help
translation authors keep things up-to-date.

### Removed
- Section about "changelog" vs "CHANGELOG".



References:
https://keepachangelog.com/en/1.0.0/

DNS - What are various records

DNS - What are various records

Stored in authoritative DNS servers are the DNS records, these records provide information about a domain including its associated IP address for each domain. It is mandatory for all domains to have a few necessary DNS records to be able to access a website using a domain name.

Below are few common types of records

1. A record

A (Address) Record An A record points a domain name to an IP address. For example, when you type www.google.com in a web browser, it will translate to 172.217.12.46 . This record links your website’s domain name to an IP address that points to where the website’s files live.

2. CNAME record
A CNAME record forwards one domain name to another domain name. This record does not contain an IP address. Utilize this type of record only when there are no other records on that domain name. Otherwise, conflict is introduced by any other records interfering. An example, a CNAME can just go from www.google.com to google.com and not to any additional domain name such as gmail.com.

3. MX Record (Mail Exchanger)

This type of record routes all email messages to a specified mail server on behalf of a recipient’s domain to a designated mail host. The MX records use a priority number when there is more than one MX record entered for any single domain name that is using more than one mail server. The priority number specifies the order of access to the listed mail servers. Counterintuitively, the lower number is the higher priority. For example, the priority number of 10 set within the MX record will receive the email messages first. The MX record with the priority number of 20 will be a backup if the MX record with the priority of 10 is unavailable.

4. TXT record
Utilized for information and verification purposes the TXT record discloses information to other services about your domain such as what services the domain is using. Sender Policy Framework (SPF) records are added as TXT records to help identify if email messages are coming from a trusted source.

5. NS (Name Server) Record

Name servers are servers usually owned by a web hosting company, such as Liquid Web, that are used to manage domain names associated with their web hosting customers. The NS records are created to identify the name servers for each domain name in a given DNS zone.

6. SOA (Start of Authority) Record




References :

DNS - Zone and Zone files

DNS - Zone and Zone files

A DNS zone is an administrative space within the Domain Name System (DNS). A DNS zone forms one part of the DNS namespace delegated to administrators or specific entities. Each zone contains the resource records for all of its domain names.

A DNS zone file is a text file stored on a DNS server that contains all the DNS records for every domain within that zone. It is mandatory for the zone file to have the TTL (Time to Live) listed before any other information. The TTL specifies how long a DNS record is in the DNS server’s cache memory. The zone file can only list one DNS record per line and will have the Start of Authority (SOA) record listed first. The SOA record contains essential domain name information including the primary authoritative name server for the DNS Zone.

A sample

references
https://www.liquidweb.com/kb/understanding-the-dns-process/

What Are Authoritative & Recursive name servers

What Are Authoritative & Recursive name servers

An authoritative name server is a DNS server that stores DNS records (A, CNAME, MX, TXT, etc.) for domain names. These servers will only respond to DNS queries for locally stored DNS zone files.  For example, if a DNS server in my network has a stored A record for example.com, then that DNS server is the authoritative server for the example.com domain name.

Recursive Nameserver

A recursive name server is a DNS server that receives DNS queries for informational purposes. These types of DNS servers do not store DNS records. When a DNS query is received, it will search in its cache memory for the host address tied to the IP address from the DNS query. If the recursive name server has the information, then it will return a response to query sender. If it does not have the record, then the DNS query will be sent to other recursive name servers until it reaches an authoritative DNS server that can supply the IP address.


References:
https://www.liquidweb.com/kb/understanding-the-dns-process/

DNS Lookup process - things involved

DNS Lookup process - things involved

Step 1: Requesting Website Information

First, you visit a website by typing a domain name into a web browser.  Your computer will start resolving the hostname, such as www.liquidweb.com. Your computer will look for the IP address associated with the domain name in its local DNS cache, which stores DNS information that your computer has recently saved.  If it is present locally, then the website will be displayed. If your computer does not have the data stored, then it will perform a DNS query to retrieve the correct information.

Step 2: Contact the Recursive DNS Servers
If the information is not in your computer’s local DNS cache, then it will query the recursive DNS servers from your (ISP) Internet service provider. Recursive DNS servers have their local DNS cache, much like your computer. Given that many of the ISP’s customers are using the same recursive DNS servers, there is a chance that common domain names already in its cache. If the domain is cached, the DNS query will end here and the website displayed to the user.

Step 3: Query the Authoritative DNS Servers

If a recursive DNS server or servers do not have the information stored in its cache memory, the DNS query continues to the authoritative DNS server that has the data for a specific domain. These authoritative name servers are responsible for storing DNS records for their respective domain names.

Step 4: Access the DNS Record
For our example, to find out the IP address for www.liquidweb.com, we will query the authoritative name server for the address record (A record). The Recursive DNS server accesses the A record for www.liquidweb.com from the authoritative name servers and stores the record in its local DNS cache. If other DNS queries request the A record for www.liquidweb.com, the recursive server will have the answer and will not have to repeat the DNS lookup process. All DNS records have a time-to-live value, which shows when a DNS record will expire. After some time has passed, the recursive DNS server will ask for an updated copy of the DNS record.


Step 5: Final DNS Step
The Recursive DNS server has the information and returns the A record to your computer. Your computer will store the DNS record in its local DNS cache, will read the IP address from the DNS record, and pass this information to your browser. The web browser will connect to the web server associated with the A records IP and display the website.

The entire DNS lookup process, from start to finish, takes only milliseconds to complete. For a more profound understanding let’s break down the previously mentioned DNS components that are relevant to the DNS lookup process.


References:
https://www.liquidweb.com/kb/understanding-the-dns-process/

WebRTC Do we need to have a Media server ?

WebRTC Do we need to have a Media server ?

Chrome 65 includes an upper limit to that which is used for garbage collection purposes. Chrome is not going to allow more than 500 concurrent peer connections to exist.

Assume we want to broadcast a video at a low VGA resolution. We checked and decided that 500kbps of bitrate offers good results for our needs.

Broadcasting our stream to 10 people requires bitrate of 5mbps uplink.

f we’re on an ADSL connection, then we can find ourselves with 1-3mbps uplink only, so we won’t be able to broadcast the stream to our 10 viewers.

For the most part, we don’t control where our broadcasters are going to be. Over ADSL? WiFi? 3G network with poor connectivity? The moment we start dealing with broadcast we will need to make such assumptions.

When we use WebRTC for a broadcast type of a service, a lot of decisions end up taking place in the media server. If a viewer has a bad network, this will result with packet loss being reported to the media server. What should the media server do in such a case?

While there’s no simple answer to this question, the alternatives here include:

Asking the broadcaster to send a new I-frame, which will affect all viewers and increase bandwidth use for the near future (you don’t want to do it too much as a media server)
Asking the broadcaster to reduce bitrate and media quality to accommodate for the packet losses, affecting all viewers and not only the one on the bad network
Ignoring the issue of packet loss, sacrificing the user for the “greater good” of the other viewers
Using Simulcast or SVC, and move the viewer to a lower “layer” with lower media quality, without affecting other users

The alternative is to use a Media server



References
https://bloggeek.me/media-server-for-webrtc-broadcast/