Tools & Dev Ops & Middleware

1. ivy vs maven
Ivy is dedicated as a repository for dependency hosting/management. Ivy is normally working with ant.
Maven is more than dependency management, however, has become one of the most popular dependency repository.

2. make vs ant vs maven vs gradle

make is the dinosaur age build tool, was since 1960s.
ant is also dedicated build tool, which create “target” to run using the ant libraries (java).
maven has another hat of being a build tool. it starts with settings.xml(the repository locations) and pom.xml (the individual configuration for project).
one advantages maven over ant is, maven has defined a lot conventions (which become kind of standard and provides a lot convenience, similar to spring’s being “opinionated”.) so instead of telling ant, where is the class & resources to compile from and into, maven comes with default compile command which works unless you have different than convention folder structure, (which then can be simply configured in pom.xml to tell maven).

+---src
|   +---main
|   |   +---java
|   |   |   \---com
|   |   |       \---best2lwjj
|   |   |           \---services
|   |   |                   Super.java
|   |   |                   
|   |   \---resources
|   \---test
|       +---java
|       \---resources

gradle a new challenger, which features groovy scripts instead of xml. (build.gradle & settings.gradle) which provides “unlimited” functionality conveniently. (instead of build a library or maven plugin, build.gradle can be written using a full functioning groovy language.)

3. CD & CI: jenkins vs hudson
both actually come from same origin. Hudson is first started by SUN (before being acquired by Oracle many years back). It was open source before.
After oracle bought over, the open source community since has moved to create Jenkins from the same original source code. (Jenkins become way more popular now.)

both and same as other CI & CD tools basically polling the source code repo (being svn, cvs or git); then take corresponding actions (configurable), such as ant compile/maven build/gradle integration testing etc….

4. CI & CD with gitlab
git become more and more popular. （git being another project from the Linus Torvalds, has borrowed a lot, like file system from Linux.)

one difference from other CI tools, gitlab enables customized gitlab runner, which is a dedicated server/servers to run certain tasks (configurable through tags). this creates a lot possibilities.
for example, one thing i have done in goldman was, to create a new pipeline, which was able to pick up code changes from feature branch, compile, test, integration test, build, package, put onto cloud/repository, deploy it and restart the server. all in one go, without single manual intervention.
This become possible with the gitlab tags and runners.

5. gitlab
normally master/ rc-xx / release-xx are feature branches, which are protected and monitored for automations/CI/CDs.

6. common issue with maven dependencies

https://stackoverflow.com/questions/4701532/force-maven-update/9697970#9697970

Advertisements

Front End

1. redux flux

Flux:

redux

2. jsx virtual dom

3. reactJs redux

basically similar to the flux flow(redux is one flux implementation), in (react) redux, component (user action, for example click a button) would trigger/generate an action, the action are being wrapped(like a container) within redux, it has a list registered listener (reducer) would act on the action (in redux, action is a noun, like a domain object, to tell the type of the action, and any additional parameters), reducer could 1) construct a new state (from existing + the new action), then store them in the store; 2) or with thunk, if could really take some action, for example, call a rest service, then generate a new state
after the new state, (which is always maintained/persisted in the store), the interested component could listen (observer) to these state (mapStateToProps), then update the component (display) correspondingly.

4. set up store, reducer, thunk

const store = createStore(
  reducer,
  applyMiddleware(thunk)
);

5. thunk
basically, “plain” redux, (supposed to be pure), only take in plain action (as a domain object, POJO); however, there are cases, it requires to run certain actions, (calling web service), with thunk, the “action” could be a function which then return a action(the real pojo).

export function getPosts_actionCreator_Thunk() {
  return function(dispatch) {
    return fetch("https://lwpro2.wordpress.com/super/posts")
      .then(response => response.json())
      .then(json => {
        dispatch({ type: "POST_LOADED", payload: json });
      });
  };
}

6. saga
sage is another way to implement what thunk’s. to iterate, Redux does not understand other types of action than a plain object.(for redux, actions is plain domain object).
Thunk is a middleware to extend redux, so that a function (thunk function) is put into the action creator, which could be run, and then return the action (domain object).
While saga is working in another approach. Saga is like an interceptor. So the original action creator is same, which simply return a plain domain action. However, saga can intercept all actions, if it’s saga’s interested actions (listener/observer pattern), it then intercept into its logic (the call of web service for example).

export function getPosts_actionCreator_original() {
  return { type: "POST_LOADED" };
}

export function loadPost_realFunction_original() {
    return fetch("https://lwpro2.wordpress.com/super/posts")
      .then(response => response.json());
}

import { takeEvery, call, put } from "redux-saga/effects";
export default function* interceptor_observer_Saga() {
  yield takeEvery("POST_LOADED", workerSaga);
}

function* workerSaga() {
  try {
    const payload = yield call(loadPost_realFunction_original);
    yield put({ type: "POST_LOADED", payload });
  } catch (e) {
    yield put({ type: "POST_LOAD_ERROR", payload: e });
  }
}

Architecture

Persistence

Distributed System

Algorithm

Data Structure