Coder Social home page Coder Social logo

de-labtory / it-chain Goto Github PK

View Code? Open in Web Editor NEW
176.0 22.0 55.0 62.67 MB

Lightweight & Customizable Block Chain

License: Apache License 2.0

Go 98.50% Batchfile 0.11% Shell 0.95% Dockerfile 0.44%
blockchain it-chain light-chain chain opensource private-blockchain

it-chain's Introduction

it-chain Build Status License Language Coverage Status

it-chain simulate video

it-chain

click image to watch video

An Ongoing Event

Overview

Lightweight Customizable Chain For All

The it-chain is an easily modifiable block chain that can fit into any domain. To make it easier to customize, we have divided the it-chain into several independent components and minimized dependencies between them.

It should not be used in production at this time.

Architecture of it-chain

The it-chain is implemented as six independently operating core components(txpool, Consensus, Blockchain, Peer, Authentication, iCode), each communicating via the Asynchronous Message Queue Protocol (AMQP). AMQP is an event bus connector that generates and distributes events for internal core components according to external messages coming into the gateway, and each core component receives and operates events that it has already registered.

A more detailed explanation is given below.

Tutorial

How to install it-chain and run simple icode(smartContract) can be found in the tutorial docs.

Requirements

  • Go-lang >= 1.9
  • Docker >= 17.12.0
  • Rabbitmq >= 3.7.7

Contribution

Contribution Guide
CONTRIBUTION

Contact

Slack URL : https://it-chain-opensource.slack.com/

License

It-Chain Project source code files are made available under the Apache License, Version 2.0 (Apache-2.0), located in the LICENSE file.

Open source license in use LICENSES

Designed by

@Hyemin choi
@Jieun Oh
@Jongmo Moon

Sponsorship

bigpicturelabs inc.

it-chain's People

Contributors

agwab avatar byron1st avatar emperorhan avatar frontalnh avatar gy741 avatar hackurity01 avatar hea9549 avatar hihiboss avatar hoonkii avatar jlggg avatar joosjuliet avatar junbeomlee avatar junngo avatar kimjunhui avatar kshinlee avatar luke9407 avatar makehoney avatar nesticat avatar owljoa avatar rla1219 avatar sangyeonk avatar sinramyeon avatar ttkmw avatar xodhx4 avatar yojkim avatar zerofruit avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

it-chain's Issues

grpc gateway 관련 이벤트

grpc gateway 관련 이벤트 논의
#163

이부분은 Network를 통해서 전송되는 부분인데 
이부분을 공통포맷으로 정의하고 싶어서 Grpc-gate event보면 
다른 피어로 전송하는 데이터는 모두 []string과 body []byte, protocol 로 되어있는데 
여기서 leaderID와 body에는 transactions의 byte그리고 protocol에 
TransactionSendEvent가 들어가야 되지 않을까 하는데 이부분은 얘기를 해봐야 할듯? 

을 제안하고있는것에대한 논의

it-chain의 기본 시나리오들에 대한 정의 필요

it-chain-Engine을 구성하는 여러 서비스들이 어떤 이벤트로 어떻게 동작하는지에 대한 전체적인 뷰를 갖기 위해서 기본적으로 다음 6가지 시나리오가 정의되야 합니다.

  • [SC.TC] Transaction 생성: 사용자(클라이언트)로부터 Transaction 생성 요청이 왔을 때의 시나리오
  • [SC.TS] Transaction 동기화: TxPool은 지속적으로 다른 it-chain node들과 동기화되는데, 이 동기화 시나리오
  • [SC.BC] Block 생성(a.k.a. Consensus): 합의 과정에 대한 시나리오 (가장 크고 복잡할 것으로 예상)
  • Block 동기화: Block도 TxPool 처럼 지속적으로 동기화되는데, 이 부분에 대한 시나리오들
    • [SC.BSNB] 새로운 Block을 받았을 때 시나리오
    • [SC.BSNN] node가 신규로 네트워크에 진입하여 Block을 동기화 받을 때 시나리오
    • [SC.BS] 이미 네트워크에 있는 상태이지만, Block 내용에 불일치가 발생하여 동기화 받을 때 시나리오

위 시나리오의 주 목적은:

  1. 어떤 서비스가 어떤 이벤트를 소비하며,
  2. 소비되는 이벤트가 전체 시나리오의 어느 지점에 존재하는지를 파악하고,
  3. 통합 테스트에 활용 하기 위함입니다.

it-chain 개발이 어느정도 궤도에 오르고 있으므로, 이 부분에 대한 명확한 정의가 필요해보이네요.

오프라인에서 말씀드린 코멘트에 대한 제안인데 의견이 다를수도 있을것 같아서 등록합니다!

제가 주로 사용하던 파이썬에서는 아래와 같은 코멘트를 다는 것이 convention이였습니다.
인텔리제이 기반 파이참에서 주석 생성시 함수 원형을 보고 자동으로 저렇게 :param 같은 것들이 만들어집니다.
저런 표준방식의 코멘트가 좋은점은 tool(파이썬의 경우는 sphinx)을 이용한 자동 documentation을 할 때,
편합니다. 그리고 tool까지 안가더라도 코드를 나중에 읽어도 눈에 잘 들어오고요 :)

def load_data(p_user_id: str, target_dir: str, only_user_data: bool=False, fix_user_sample: int=None, fix_imposter_sample: int=None)
-> [np.ndarray, np.ndarray] or np.ndarray:
"""
load legitimate user's data and imposters' data from csv files
:param p_user_id: legitimate user's id(initial)
:param target_dir: target directory for finding requested user data
:param only_user_data: if true, return user data only. if false, return user and imposter data
:param fix_user_sample: fix the number of legitimate user sample to return
:param fix_imposter_sample: fix the number of imposter sample to return
:return: legitimate user data and imposter data
"""

그런데 Go 언어의 convention을 보니 조금 다른것 같네요. golang 개발 깃헙 문서에는 아래와 같은 예시가 있었고, 링크로 가시면 부연설명도 있습니다.(링크 : https://github.com/golang/go/wiki/Comments)
godoc이라는 documentation 자동화 tool도 있네요. (https://godoc.org/)
한글버전의 comment 설명은 (https://golang.kr/doc/effective_go/commentary.html) 에서 조금 볼수 있네요.

// Package superman implements methods for saving the world.
//
// Experience has shown that a small number of procedures can prove
// helpful when attempting to save the world.
package superman

// enterOrbit causes Superman to fly into low Earth orbit, a position
// that presents several possibilities for planet salvation.
func enterOrbit() os.Error {
...
}

coding convention을 일일이 따르는건 나중에 해도 될것 같지만 코멘트나 문서에 대한 규칙(?)은 미리 정의해두어야 좋을것 같아서 제안을 드리고 제가 이번주에 해보겠다고 말씀은 드렸지만

생각해보니 토론이 필요할것 같기도 하고.. 제가 이번주는 아마 토요일에나 제대로된 작업을 할 수 있을것 같아서 그 사이 기간에 의견을 여쭤보려고 이슈 등록했습니다.

"매우 좋다!" 혹은 "이런 스타일의 코멘트를 다는것은 아직 이르다!" 혹은 "코멘트 다는것 자체가 아직은 이르다!" 등등 의견 부탁드립니다.

Implementation 분할 작업

Implementation_details.md를 각 서비스별로 분할할려고 합니다.

크게 consensus, blockchain, txpool, authentication, smartcontract, peer가 있는데 위의 문서(Implementation_details.md)를 분할하여 각 폴더 안으로 보내고 서비스별로 Implementation_details.md문서를 작성하는것이 좋은 방향인것 같습니다.

  • consensus
  • blockchain
  • txpool
  • authentication
  • smartcontract
  • peer

분할하고 정리하고 답글달아주시면 체크하겠습니다.
모든 서비스에 대해서 체크가 완료되면 close하겠습니다.

각 서비스별 bound 결정하기

  • consensus
  • blockchain
  • peer
  • txpool
  • authentication
  • smartcontract

각자 관심있는 서비스의 bound를 정하고 README.md에 정리하여 풀리퀘 보내주세요!

README에 Usage 추가

아직 golang에 익숙하지않아서요.

깃풀받아서 한번 돌려보고싶은데 어떻게 실행시키는지 잘 모르겠어요.

그래서 README에도 어떻게 사용하는지 간단하게 사용법을 명시하는 건 어떨까 제안해봅니다!

go src 구조 변경

기존 멤버들은
프로젝트의 구조가 src/it-chain -> src/github.com/it-chain/it-chain-Engine으로 바뀌었음
기존의 src/it-chain은 지우고(꼭 지워야함)

src/github.com/it-chain/it-chain-Engine위치에 git clone하거나
go get github.com/it-chain/it-chain-Engine으로 새로 받아서 작업하세요!!

처리되면 답글달아주삼 모두 달면 close하겠음

TxPool Event naming 논의

TxPool 에서 publish 하는 이벤트 목록(가칭)

  • TxReadyToBlockEvent (1)
  • TxSendToLeaderEvent (2)

(1) 자신이 리더 노드일 경우 모여있던 트랜잭션을 블록으로 만들 준비가 됬다는 이벤트를 보낸다
(2) 자신이 리더노드가 아닐경우 모여있던 트랜잭션을 리더노드에게 보낼 준비가 됬다는 이벤트를 보낸다

에대한 이벤트 네이밍 논의가필요합니다.

블록체인서비스-유비쿼터스랭기지 작성을 위한 내용 정리

아직 모르는 것이 많은데도 일단 작성한거라 틀린 부분도 많을 것이고, 정돈도 안된 느낌입니다.
그럼에도 불구하고 시간을 너무 끌다보면 진행이 안될 것 같아서 일단 올립니다.
내용 면에서 미완성이니 바쁘신 분들은 읽지 않으셨다가 다시 수정하면 그 때 읽어주시기 바랍니다.
다만 형식적인 면에서는 피드백을 주셨으면 좋겠습니다. 준범님의 블로그를 참고한 건데, 이런 형식이면 되는 것인지 확인해주시면 감사하겠습니다.

image

authentication service 리서치 및 기능 구체화

authentication 서비스는 네트워크에 permission된 peer들인지 아닌지를 혹은 client의 요청이 permission된 client로 부터의 요청인지 등을 관리, 처리하는 서비스입니다. 아직 정확하게 decentralized 한 메커니즘에서 어떻게 authentication 서비스를 지원할지 정확하게 구상된 부분이 없기 때문에 자료나 의견 부탁합니당!

특히 @김동인님의 지식이 필요할듯 합니다.

블록체인 서비스(api) 유비쿼터스 랭기지 작성을 위한 내용 정리

아직 모르는 것이 많은데도 일단 작성한거라 틀린 부분도 많을 것이고, 정돈도 안된 느낌입니다.
그럼에도 불구하고 너무 늦어져 일단 올렸습니다.
미완성이니 바쁘신 분들은 정독 보다는 훑어주셨다가 내용이 수정되면 그 때 읽어주시기 바랍니다.
다만 이런 내용이 들어가는 것이 맞는지, 이런 형식으로 쓰는 것이 맞는지 피드백 주시면 감사하겠습니다.
피드백 주시는 부분들은 바로 수정하도록 하겠습니다.
내용은 legacy/service/block-service-impl을 참고하였습니다.
@junbeomlee @byron1st @zeroFruit @emperorhan

블록체인 서비스(api)는 블록체인의 생성, 블록의 생성, 블록의 검증, 블록의 추가만을 담당한다(트랜잭션 부분은 TxPool에서 처리한다고 하셔서 트랜잭션 부분은 제외했습니다.).
블록체인은 헤더와 블록 리스트로 구성된다. 헤더는 체인헤이트, 채널이름, 피어아이디로 구성된다. 블록은 블록헤더, 블록데이터로 구성된다. 블록헤더는 넘버, 이전블록해시, 버전, 머클트리루트해시, 블록생성시각, 블록헤이트, 블록상태, 블록해시로 구성된다. 블록데이터는 머클트리, 트랜잭션리스트, 트랜잭션 인덱스, 머클트리헤이트, 트랜잭션카운트로 구성된다.

[블록체인 생성]

  1. 새로운 노드가 만들어질 때 노드의 it-chain폴더에 새로운 블록체인 데이터베이스를 생성한다

[블록 생성]
2. consensus service가 트랜잭션을 불러올 때 에러가 없고, 수행하려는 트랜잭션이 한 개 이상일 때 블록을 생성할 수 있다.
3. 새로운 블록을 생성할 때는 먼저 블록체인의 마지막 블록을 가져온다. 마지막 블록을 가져오는 과정에서 에러가 발생한다면 블록을 생성하지 않는다. 블록이 하나도 없는 장부라면(lastblock==nil) 트랜잭션이 들어있지 않은 빈 블록을 새로 생성하여 가져온다(이런 경우가 있나..? GetLastBlock에서 이미 블록을 처음 생성하는 거라면 빈 블럭을 만들어서 리턴해주는데). 마지막 블록(혹은 새로운 빈 블록)과 블록을 생성하고자 하는 Peer의 ID를 토대로 새로운 블록을 생성해준다. 이 블록에는 아직 거래 정보가 들어있지 않다.
4. 이후 수행하려는(블록에 넣어주려는) 트랜잭션을 모두 검사하고(PutTransaction 할 때 트랜잭션의 validate는 아직 보류) 문제가 없다면 블록에 넣어준다.
5. 블록에 넣어준 트랜잭션들을 토대로 머클트리를 생성한다.
6. 생성한 머클트리(정확히는 머클루트해시), 블록 생성 시각, 이전 블록 해시를 토대로 블록 해시를 생성해주고, 블록 해시 생성 과정에서 에러가 없다면 블록 생성을 완료한다.

[블록 검증]
7. 블록의 검증(PBFT 합의에서 호출됨)은 먼저 블록체인 내 블록이 하나라도 있는 지 확인한다.
8. 블록체인 내 블록이 하나도 없을 경우(lastblock==nil) 머클트리패스를 이용해 검증하고자 하는 블록의 모든 트랜잭션을 검증한다.
9. 검증 과정에서 에러가 발생하지 않았다면 검증하고자 하는 블록의 상태를 검증됨으로 고쳐주고, 검증 완료됐다는 신호를 출력한다.
10.블록체인 내 블록이 하나라도 있다면, 마지막 블록을 불러들인다. 그 과정에서 에러가 없다면 검증하고자 하는 블록의 검증을 시작한다.
11. 블록의 검증은 블록헤이트 검증, 블록해시검증, 트랜잭션 검증의 과정을 거친다.
12. 블록헤이트 검증은 해당 블록의 블록헤이트가 블록체인의 기존 블록 개수에 1개를 추가한 것이 맞는지 확인한다.
13. 블록해시 검증은 검증하고자 하는 블록의 이전 블록 해시와 블록체인의 마지막 블록의 해시가 맞는지 확인한다.
14. 트랜잭션 검증은 머클패스를 이용해 블록 내 거래 정보들을 검증한다.
15. 모든 검증을 마치고 나면 검증하고자 하는 블록의 상태를 검증됨으로 바꿔주고, 검증 완료됐다는 신호를 출력한다.

[블록 추가]
15. 합의가 완료된 블록을 블록에 추가할 때는 먼저 (1) 블록체인에 블록이 하나라도 있는 지, (2) 블록해시의 형식(arg type)이 무엇인지 확인한다.
16. (1), (2) 과정에서 블록체인에 블록에 하나도 없을 경우, 블록해시가 default일 경우(이 부분에 대한 이해가 더 필요함)에 "이 블록은 블록체인의 블록과 겹친다"는 에러를 발생시킨다.(오히려 에러가 없을 때(블록해시로 블록체인 내에서 블록을 찾을 수 있을 때) '이 블록은 이미 있다'는 에러를 발생시켜야 하는 것 아닌가..?)
17. (1), (2) 과정에서 블록체인 내 블록이 하나라도 있고, 블록 해시의 형식이 정수이거나 문자일 때 블록해시를 이용해 블록체인에서 마지막 블록을 불러들인다.
18. 마지막 블록을 불러들이는 과정에서 에러가 없다면 해당 블록이 검증된 것인지 확인한다.
19. 블록이 검증된 것이라면 블록체인 내 블록이 하나도 없는 동시에 블록헤이트가 1 이상인지 확인한다(???). 이 때 해당 블록의 이전 블록 해시와 마지막 블록의 블록해시가 다르다면 해당 블록을 블록체인에 추가하지 않는다.
20. 해당 블록을 다시 검증하고(이건 왜하지..? 이미 검증된 블록 아닌가?) 검증에 성공한다면 해당 블록을 블록체인에 추가한다.

코드 포멧팅 제안

Go에는 goimports 라고 자동으로 포멧팅(임포트 순서, 띄어쓰기 등)을 수행해주는 기본 도구가 있는데요, 코드 작성시 이걸 사용하는게 어떤지요? 이유는 다음과 같습니다.

  • merge 시 임포트 순서 같은 사소한 포멧팅 이슈로 인한 충돌 발생 방지
  • Visual Studio Code, Atom, GoLand 같은 다양한 개발 툴과 무관하게 포멧팅 유지

Visual Studio Code (go-vscode)와 Atom (go-plus)의 경우 goreturns 라는 도구를 default로 사용하고 있습니다. goreturnsgoimports 에 리턴 시 기본값 자동 배정 기능만 추가된 것이라 포멧팅 측면에선 goimports 와 사실상 동일하다고 볼 수 있죠.

다만 GoLand의 경우 추가적으로 설정을 해주어야 하는데, 이 링크를 참고하시면 설정이 가능합니다.

의견 주세요~!

CreateRepos Not found 에러 smartcontractservice_impl deploy함수 test할때

`func TestDeploy_Deploy(t *testing.T) {
currentDir, err := filepath.Abs("./")
if err != nil {
assert.Fail(t, err.Error())
}

scs := SmartContractServiceImpl{"steve-buzzni", currentDir + "/sample_smartcontract",map[string]SmartContract{}}
ContractPath := "junbeomlee/bloom"

deploy_result, err := scs.Deploy(ContractPath)

fmt.Println(deploy_result)

if err != nil {
	assert.Fail(t, err.Error())
}

fmt.Println(deploy_result)
//assert.Equal(t,nil,deploy_result)

}`

이 부분 테스트할 때

2018-02-19 6 46 52

이런 에러가 나옴!!

에러 의심 부분은
_, err = domain.CreateRepos(new_repos_name, GITHUB_TOKEN) if err != nil { return "", errors.New(err.Error())//"An error occured while creating repos!") }

이부분!!

3/31 Dead line

it-chain offline 미팅 때 얘기되었던 각자의 이번주 목표에대해 올리고 완료하신 분들은 체크박스 눌러주시면 됩니다!
모두 완료했을 경우 close하겠습니다. 그날 참여하지 못했지만 이번주 목표가 있으신 분들은 댓글로 남겨주시면 추가하겠습니다.

  • @yojkim heimdall packaging, hash까지
  • @hackurity01 DDD개념 Modeling
  • @luke9407 yggdrasill library완성 및 documentation
  • @zeroFruit blockchain 서비스 유비쿼터르 랭귀지와 modeling
  • @owljoa heimdall function input,output 정리
  • @junk-sound blockchain 서비스 유비쿼터르 랭귀지, go 공부
  • @junbeomlee bifrost완성, consensus 완성

it-chain install 문제

Actual Behavior

image

Steps To Reproduce Behavior

  • git pull origin master
  • go get

git pull 후에 go get 을 하니 에러가 뜨네요 :(
혹시 도움을 주실 수 있을까요?

SmartContractService 구조 초안

image

현재 구상 중인 SmartContractService 구조의 그림입니다.
아직 확실하게 구조를 잡거나 구체적인 내용이 나온건 아니지만 피드백 사항이 있을까 해서 공유합니다.

db, connection, auth는 library로 바꾸기

우주: db
용재: auth
준범: connection

은 각각 it-chain/leveldbhandler, it-chain/auth, it-chain/grpc-connection같은 library로 export하기

  • db
  • auth
  • connection

체크 완료후 close

Blockchain 서비스 Context Boundary 논의

Blockchain

각 P2P Network 구성원들의 블럭들을 조회, 검증할 수 있다. 합의 이전에는 아직 합의가 안된 블럭들을 저장(생성)하고 합의 과정에는 합의된 블럭들을 저장(생성)한다.

Primary Data

  • 블럭
  • 트랜젝션
  • 머클트리

Consume Event

  • 합의 이전 블럭들을 추가
  • 합의된 블럭들을 추가

Publish Event

  • 블럭 조회
  • 블럭 검증

사람이 많은만큼 대화채널을 빨리 만드는 것이 좋을 거 같아서 이슈를 올려보았습니다.
아키텍쳐가 바뀌면서 다른 서비스들과 관계 속에서 Blockchain 서비스가 어디까지의 역할을 맡을지를 먼저 생각해보면 좋을 거 같았습니다.
내용들을 엄청 뭉뚱그려 적었고 용어도 일부러 일단은 한글로 다 작성했습니다. 포멧은 일단 @junbeomlee 님께서 작성해주신 Consensus부분을 따랐습니다.

각 P2P Network 구성원들의 Block들을 조회, 검증할 수 있다. 합의 이전에는 아직 합의가 안된 Block들을 저장(생성)하고 합의 과정에는 합의된 블럭들을 저장(생성)한다.

이 부분은 제가 생각한 Blockchain 서비스의 Boundary입니다.(오류가 있을수 있습니다!ㅎㅎ) 각자 생각한 것들을 올리면서 같이 고쳐나가면 좋을 것 같습니다!

Block Sync

블록 싱크를 고민하다가 궁금한게 생겨서 이슈를 올리게되었습니다.
혹시 기존의 피어들의 블록과 새로 참여한 피어의 블록 형태에서 다음과 같은 상황말고

  • 길이는 다르지만 새 피어의 블록 모양이 기존피어 블록 모양에 일부분인 경우
기존피어: Genesis -> A -> B -> C
새 피어: Genesis -> A
  • 새 피어의 블록이 없는 경우
기존피어: Genesis -> A -> B -> C
새 피어: Genesis 

혹시 이런 상황도 가능할까요?

  • 길이가 다르고 새 피어의 블록이 기존 피어 블록 모양에 일부분이 아닌 경우
기존피어: Genesis -> A -> B -> C
새 피어: Genesis -> D

브랜치 관리 제안

it-chain은 6가지 큰 서비스로 구성이 되어 있는데요, @junbeomlee 님이 폴더 구조를 각 서비스별로 재구조화 하는 것으로 알고 있습니다.

이후, 브랜치를 git-flow 규칙을 참고해서 다음과 같이 관리해봄이 어떨지 제안드려요.

  • master: 실제로 설치, 배포해볼 수 있는 코드
  • develop: 개발 중에 단위테스트를 마친 서비스 코드가 merge되는 곳
  • feature/: 각 서비스 별로 코드가 1차적으로 푸쉬되는 브랜치

@junbeomlee 님이 제안했던대로, develop 브랜치로의 merge는 각 feature/ 브랜치에서 pull request를 던지는 것으로 합치구요. 하나의 서비스를 개발하다가, 다른 서비스 개발이 하고 싶으면, 해당 feature/ 브랜치를 pull해서 개발을 진행하면 되구요.

다들 의견 주셔서 어떻게 관리할지 픽스를 해보죠 :)

참고: git-flow

transaction service 구현

  1. Leader에게 tx를 주기적으로 보낸다.
  2. tx 버퍼 디비를 만들고 tx요청을 받으면 저장한다.
  3. block에 넣기 전에 confirm된 tx리스트를 찾아서 tx 버퍼에서 제거한다.

cli 추가

cli기반으로 it-chain engine을 컨트롤 할려고합니다.

ex)
/it-chain peer start
/it-chain icode deploy [url]

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.