Huy Trong Nguyen huytrongnguyen

We're not talking about "clean code", We're talking about something more...

Defend against the impossible, because the impossible will happen

There are many definitions for Defensive Programming, but from my point of view, all the thing you need to know is:

Never trust the input (user input, function parameters, ...). Do whitelists not blacklists, don't check for the invalid types but check for the valid types, excluding all the rest.
Don't reinvent the wheel, use something that's already out there, well tested, trusted by thousands of developers and stable. The only reasons why you should build something by yourself is that you need something that doesn't exists or that exists but doesn't fit within your needs.
Shouldn't trust other developer's code.
Write SOLID code

DDD and Onion Architecture

In order to create good software, you have to know what that software is all about. You cannot create a banking software system unless you have a good understanding of what banking is all about, one must understand the domain of banking.

What is Domain-Driven Design

Domain-driven design (DDD) is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.

Its premise is: >

Folder Structure

Motivations

Clear feature ownership
Module usage predictibility (refactoring, maintainence, you know what's shared, what's not, prevents accidental regressions, avoids huge directories of not-actually-reusable modules, etc)

C# class equivalent Java enum

C#'s enums seem to be more simplistic than the Java 1.5+ implementation. Enumerations in the CLR are simply named constants. The underlying type must be integral. In Java an enumeration is more like a named instance of a type. That type can be quite complex and contain multiple fields of various types. For example, in Java, you can create an enum like this:

package io.github.huytrongnguyen.reference;

import lombok.Getter;

@Getter

Last month, I released a library called Extension React that helps you to write React applications by composing a component, adding application logic in services then boxing them in container. But it's still not separate the view and behavior completely. Based on Angular application architecture, I revise Container concept and named Component for clarification.

A component controls a patch of screen called a view. You define a component's application logic—what it does to support the view—inside a class. The class interacts with the view through an API of properties and methods. For example:

// dashboard.js
import { Route, Component } from 'ext-react';
import DashboardStore from '~/stores/dashboard';
import DashboardView from './dashboard.view';

All right, everybody! Welcome to my talk. ES2016, the evolution of JavaScript. First a little bit about me. My name is Jafar Husain. I'm a tech lead at Netflix, I work for Falcor, an upcoming open data platform, which we intend to release pretty soon, and I'm also one of Netflix's representatives on TC-39, which is JavaScript's standard's committee. This talk used to be called ES7, the evolution of JavaScript, but something happened a couple of committee meetings ago. We decided to change ES6 to ES2015 and ES7 to ES2016. I want to explain this name change. We as a committee want to start shipping JavaScript every year. Just the way you would ship software in an agile way, we want to add features and ship them

	<!doctype html>
	<html lang="en">
	<head>
	<meta charset="utf-8">
	<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
	<title>AngularJS</title>
	</head>
	<body ng-app="app">
	<section navbar></section>
	<section ui-view></section>

	{
	"name": "angular-cms",
	"version": "1.2.32",
	"scripts": {
	"build": "webpack",
	"serve": "yarn build && webpack-dev-server --hot --inline --open"
	},
	"babel": {
	"presets": [
	"env"