Application Layer
RTP: Real-time Transport Protocol (RFC 3550)
RTCP: RTP Control Protocol
SIP: Session Initiation Protocol
SDP: Session Description Protocol
RTSP: Real Time Streaming Protocol
SRTP: Secure Real-time Transport Protocol
Transport Layer
DCCP: Datagram Congestion Control Protocol
SCTP, Stream Control Transmission Protocol
TCP: Transmission Control Protocol
UDP: User Datagram Protocol
RDP: Reliable Datagram Protocol
Internet Layer
IP: Internet Protocol
IPSec: Internet Protocol Security
ICMP: Internet Control Message Protocol
Link Layer
IEEE 802
Ethernet
Tuesday, February 7, 2017
Friday, January 27, 2017
Time to change
In year 2012, when I joined Moxtra to work on Front-end Web app, I didn't know anything about Javascript, CSS or HTML5. I was using Java/J2EE while in Cisco. At that time, I googled a lot and made the following choice for Moxtra web app architecture in a short period of time.
Today I read a blog https://risingstars2016.js.org/ which listed popular front-end projects/libraries in 2016. I am totally terrified to see so many new things happening.
Popular lib/frameworks
Node.js Frameworks -> Express, Sails, Loopback, Restify
React Boilerplates -> Create React App, React boilerplate
Mobile -> React Native
Transpilers -> TypeScript, Babel
Build Tools -> Webpack, Gulp
Testing Framework -> AVA, Jest
SSG (Static Site Generators) -> Hexo, Gatsby
Most popular projects on Github
Vue.js
React
Yarn
Angular 2
Electron
Create React App
React Native
Redux
Boostrap
D3
Time to change:
ES5 -> ES6
Backbone -> Vue.js/React
Requirejs -> Webpack
Grunt -> Gulp/Webpack
Sublime -> Atom/Visual Studio Code
Mocha/Jasmine -> AVA/Jest
NPM -> Yarn
- Javascript Framework/Lib: Backbone (http://backbonejs.org/) and (http://jquery.com/)
- CSS Framework: Bootstrap (upgraded from v2 to v3) (http://getbootstrap.com/)
- CSS Preprocessor: LESS (2 years later changed to SASS) http://sass-lang.com/guide
- Template: (underscore built-in, then changed to http://handlebarsjs.com/)
- Module loader: AMD/Requirejs (http://www.requirejs.org/)
- Chart/Draw: d3 (https://d3js.org/)
- Build tool: grunt (http://gruntjs.com/)
- Package manager: NPM (https://www.npmjs.com/)
- IDE: Sublime Text 2 (http://www.sublimetext.com/2)
- Javascript: Vanilla JS/ES5 (http://es5.github.io/)
- Static code analysis tool: jshint (http://jshint.com/)
- Testing tool: qunit then behavior-driven javascript Jasmine (https://jasmine.github.io/)
Today I read a blog https://risingstars2016.js.org/ which listed popular front-end projects/libraries in 2016. I am totally terrified to see so many new things happening.
Popular lib/frameworks
Node.js Frameworks -> Express, Sails, Loopback, Restify
React Boilerplates -> Create React App, React boilerplate
Mobile -> React Native
Transpilers -> TypeScript, Babel
Build Tools -> Webpack, Gulp
Testing Framework -> AVA, Jest
SSG (Static Site Generators) -> Hexo, Gatsby
Most popular projects on Github
Vue.js
React
Yarn
Angular 2
Electron
Create React App
React Native
Redux
Boostrap
D3
Time to change:
ES5 -> ES6
Backbone -> Vue.js/React
Requirejs -> Webpack
Grunt -> Gulp/Webpack
Sublime -> Atom/Visual Studio Code
Mocha/Jasmine -> AVA/Jest
NPM -> Yarn
Tuesday, January 17, 2017
Semantic Versioning
Nodejs, bower etc all use Semantic Versioning for release version management.
Semantic Versioning, its main idea is to define the versioning rules for product release. It has 3 parts:
Major.Minor.Patch (x.y.z)
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
When we give the versioning, we need follow the rules. Initial development is suggested to use 0.y.z till it is ready for production (1.y.z)
When we declare package dependencies, we have different kinds of formats.
Semantic Versioning, its main idea is to define the versioning rules for product release. It has 3 parts:
Major.Minor.Patch (x.y.z)
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
When we give the versioning, we need follow the rules. Initial development is suggested to use 0.y.z till it is ready for production (1.y.z)
When we declare package dependencies, we have different kinds of formats.
- latest -> Takes the latest version possible. Not the safest thing to use.
- ~1.2.3 -> Any version “reasonably close to 1.2.3”. This will call use all versions up to, but less than 1.3.0
- ^1.2.3 -> Any version “compatible with 1.2.3”. This will call versions up to the next major version like 2.0.0. Could break your application if there are major differences in the next major version.
- 1.2.3 - 1.2.5 -> Anything within a range of versions. The equivalent of >=1.2.3 and <=1.2.5
- * -> Wildcards. Can be any version at all.
It is highly recommended to use ~1.2.3 format when declare package dependencies.
It is highly recommended to follow semantic versioning rules to define your owner package version.
It is highly recommended to follow semantic versioning rules to define your owner package version.
Subscribe to:
Posts (Atom)