Coder Social home page Coder Social logo

gravity's Introduction

DXOS

DXOS

NPM Discord

We build Composer: an extensible app platform where developers can extend their intelligence. Open-source. Multiplayer. Local-first. Private.

The DXOS SDK takes care of peer-to-peer collaboration for local-first apps without central sync servers.

Learn more about the the mission.

SDK Demo

Shown below are two sessions of an application using ECHO to replicate state peer-to-peer in real-time.

ECHO

Documentation

DXOS Resources

Contributions

Your ideas, issues, and code are most welcome. Please take a look at our community code of conduct, the issue guide, and the PR contribution guide. To learn about how to set up for development and contribution to DXOS, see the Repository Guide

License: MIT Copyright 2022 © DXOS

gravity's People

Contributors

alexwykoff avatar dboreham avatar dmaretskyi avatar hubertnastaly avatar richburdon avatar rzadp avatar telackey avatar

Stargazers

avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar

Forkers

nytyn

gravity's Issues

Demo QA Requirements

  • One static location page updated daily with the results of the latest test run qa/index.md
  • A listing of features which are working and which are not
  • A link to the safe version of Teamwork to use for demonstrations
  • section on Teamwork
  • link to Teamwork test plan
  • link to console
  • list of demo-able apps (versions) that have been tested and good to go
  • update process so that there is a qa domain (qa.dxos.org) for testing
  • dxos.org domain only for tested demo-able apps (which should when implemented obviate the need for the "white list" above)
  • link to any testing/coverage/CI reports
  • link to kanban with QA issues (e.g., setting up runtime reporting)

12/11/2020 Testing Status

Broken Items

Arena

  • Bot Invitations ❌ Currently broken due to step in mesh migration
  • Cross-apollo invites ❌ Currently broken, cause unknown

Teamwork

Unstable Items

  • Cross-network invites appear to be working in the happy path scenario, VPN case still not working. Context added dxos-deprecated/sdk#290

Demo Instructions

  • Chessbot invite is BROKEN don't do it.
  • Cross-apollo invites are not working in Arena only.

Service Payments MVP Scope

Background:

https://github.com/wirelineio/wns/blob/master/docs/content/block-diagram.md
https://github.com/dxos/gravity/blob/master/docs/content/diagrams/overall-system.png
https://docs.google.com/document/d/1nazq_qOzNRyz1PCjE93YNeiyJzQAukbdxjUE-iGUtnI/edit?ts=5f851427
https://github.com/wirelineio/testnet/milestone/2

To be addressed:

  • Point of service interface
  • Wallet for service provider
  • Point of consumption interface
  • Wallet for consumer
  • MVP service coverage (a bot posting on a party; signal service; kube ping response?)
  • Devnet/Testnet terminology clarification

Devops

Standardize across all repos:

  • AGPL-3.0 (LICENSE and package.json)
  • README format and content (e.g., remove npm publish instructions)
  • README badges
  • other common files (e.g., CHANGELOG, CODE_OF_CONDUCT)
  • config (package.json, lint, GH actions, etc.)
  • template repo
  • master/main

12/08/2020 Testing Status

Broken Items :

Arena :

Messenger ❌ (perhaps an unfinished feature? dxos/arena#48) & dxos/arena#118

Teamwork :

Changing the party name ❌ dxos-deprecated/teamwork#496
Reseting storage ❌ dxos-deprecated/teamwork#360
Reactivating a party ❌ dxos-deprecated/teamwork#501 & dxos-deprecated/teamwork#500
Inviting store bot ❌ dxos-deprecated/teamwork#485
International invites were not working as of yesterday and this morning. They time out too quickly. Tracked in : dxos-deprecated/sdk#445 & dxos-deprecated/sdk#290

Unstable Items :

Arena :

Inviting chessbot on Apollo1 to arena on Apollo1 worked just now, however, due to known issues this is D O D G Y. Tracked in : dxos/arena#112, #63, dxos-deprecated/mesh#28

Demo Instructions :

Chessbot invite works HOWEVER there is a very specific change in flow necessary.
Select wrn://dxos/bot/chess, be certain to use the Advanced pane and select wrn://dxos/bot/chess@alpha.

Toe-Stubbing Blockers to Gravity Progress

  • Dependency Management #60
  • Error message improvements for clarity
  • Full TypeScript Coverage
  • Tests in Bot Factory
  • Negative Edge Testing
  • Proper timeouts on tests
  • Performance testing
    • Memory
    • CPU
    • Networking

Payments project scope

Some thoughts:

This diagram shows one of them, how we got to deciding to use Optimism ORU: https://github.com/dxos/gravity/blob/master/docs/content/diagrams/payment-diagram-2.png

The money is on Ethereum, but Ethereum is too slow, so we make a different faster blockchain but now we have to get the money on and off that chain and that's hard/unsolved, but finally if someone figured out how to speed up Ethereum finally then we should use that technique because that was the problem we started with.

This makes some sense, except : Optimism ORU is somewhere between an idea and a prototype at this point, and : using it implies we must move to the Ethereum platform (because Optimism can be viewed as a turbocharger for Ethereum mainnet that looks and feels like Ethereum -- it isn't a standalone thing).

This implies throwing away the work we have done on CosmosSDK.

And re-implementing it on Ethereum+Optimism. Another diagram: https://github.com/dxos/gravity/blob/master/docs/content/diagrams/payment-diagram-5.png (edited)

But in the current diagrams from Ashwin/Rick they didn't do that -- there's both the old and the new designs side by side. This implies yet another bridge has to be built between the two, another layer of turtles since that bridge has the same hardness properties that we began with above.

Another thread is that we would like to use existing open source projects (make vs buy decision) for various things. Most of these target the Ethereum platform. Diagram : https://github.com/dxos/gravity/blob/master/docs/content/diagrams/payment-diagram-3.png

Since we are not Ethereum-based, to use one of these projects we then have the choice between "porting" it to our CosmosSDK blockchain, or building an Ethereum emulation capability in our blockchain.

That Ethereum emulation capability doesn't exist in a turnkey form so we would need to do some of the work ourselves. Unclear to me that this work is less effort than porting the projects to CosmosSDK.

Note that there are now two quite different reasons we have EVM in our block diagram, but the difference tends to get lost in the discussion.

Testing framework

Testing concerns:

  • KUBE console
  • KUBE logging/query services (https://www.elastic.co/elastic-stack as a candidate?)
  • Devtools
  • Gravity/simulation
  • Bots (gravity)
  • CLI diagnostics (e.g., party, network)
  • Storybook test automation
  • Party/model (specifically text) simulation

Branch name / build scheme

We would like to have, for each git repository:

  1. Stable release branches (release_1_1, release_1_2) that are built (ideally automated, but manually triggered) into versioned package public releases. Branch rather than tag because these branches may contain multiple commits done as part of both pre-release stability work, and post-release minor fixes. Never requires private dependencies.
  2. "Master" branch that contains code that is "the most recent release_x_x plus subsequent ongoing compatible development", and will usually for the basis for the next release branch when it is made. Developers can expect the code on master to pass tests and be usually fully functional (possibly broken for short periods due to integration bugs, mistaken commits etc). CI enabled to check build and run unit tests should be run on every push. Never requires private dependencies. PRs for release bugfixes and minor enhancements are made against master.
  3. "Canary" branches used for major new interface breaking and experimental development. Typically there is only one active canary branch. CI enabled to check build, unit tests, plus automated package publish to private registry. Canary branch CI builds pull dependencies from a private registry on a specified canary channel, allowing composite builds across multiple monorepos under concurrent development. PRs for incremental development of major new interface breaking and experimental development are made against the appropriate canary branch.

Gravity testing new ECHO

Milestones

  • Multi-agent test of party replication using the Database API (dxos-deprecated/echo#95)
  • Invitations (guarded replication, etc.)
  • Full HALO capabilities ported (contacts, etc.)
  • SDK/App integration

Gravity

  • Set-up NPM proxy npm/verdaccio
  • Gravity testing framework for ECHO (multi-agent)

ECHO

  • Network replication (integration of Protocol) (dxos-deprecated/echo#95)
  • Parent-Child
  • Object Model consistency test
  • Object Model consistency implementation
  • Text model

HALO

  • HALO integration (implementation of PartyProcessor)

SDK and Apps

  • SDK uses new Database API
  • Apps using new SDK/Database API (Tutorials, Teamwork, Arena)

Gravity - Halo startup test

  • 5 Agents connect to the same party
  • Each agent writes 10 messages
  • Number of agents and number of messages should be easily configured variables
  • Performance graph of ECHO under this stress test
  • A/B comparison with and without snapshotting to compare performance
  • 10 agents with 100 messages each

Docs cleanup notes

General

  • Use a spellchecker before submitting any doc PRs

TODOS

docs/content/guides/writing-code.md

Writing Code

  • TODO(burdon): Clean-up.
  • TODO(burdon): Lint instructions.

Misc

  • TODO(burdon): null vs undefined
  • TODO(burdon): async
  • TODO(burdon): Number clauses and use as reference with PRs.

((This is dangling without a header))

  • TODO(burdon): Save PyCharm style settings. <-- Is this still an issue?

docs/content/devops/git-repos.md

Set-up

  • TODO(burdon): Template (or example) repo?

Branches

  • TODO(burdon): Add example flow (echo, client, react-client, tasks-app, gravity).

Tests

  • TODO(burdon): Reference GH workflow assets.

Github Workflows and Actions

  • TODO(burdon): Standarize actions (tests, coverage, release, etc.)
  • TODO(burdon): Reference sample project with canonical workflow definitions (e.g., @dxos/echo?)

Badges

  • TODO(burdon): Reference sample project with canonical workflow definitions (e.g., @dxos/echo?)

docs/content/devops/development-guide.md

  • TODO(burdon): Reference @dxos/version-check.

docs/content/devops/tools/verdaccio/index.md

  • TODO(burdon): Why was 5736 chosen and link to registry of used port numbers. The docs reference 4873.

Fix basic docs structure

Re #49

Set up the basic docs structure and develop culture to maintain them.

  • index.md files in each folder should have links to other docs in that folder.
  • create small focused docs and do not repeat any information therein (reference them).
  • get each document reviewed by the specialist and make it know that they are responsible for maintaining the doc.

12/09/2020 Testing Status

Broken Items

Arena

  • Messenger:x: Technically works, but the control is in the wrong position. dxos/arena#118

Teamwork

Unstable Items

Arena

  • Inviting Chessbot on Apollo1 to arena on Apollo1 worked just now, however, due to known issues this is D O D G Y. Tracked in : dxos/arena#112, #63, dxos-deprecated/mesh#28
  • Chessbot will be promoted out of alpha tomorrow AM.

Demo Instructions

  • Chessbot invite works HOWEVER there is a very specific change in flow necessary.
  • Select wrn://dxos/bot/chess, be certain to use the Advanced pane and select wrn://dxos/bot/chess@alpha.

Hosting "services" on kube

  • What is our definition of a service?

Includes: signal/mesh server, vdb, dxns node, app hosting service, payment channel hub, ...

DEP1 - package naming and cross-repo integration

Each of the development branches outlined in DEP0 publishes under a separate namespace:

  • master - @dxos-nightly/*
  • dev - @dxos-dev/*
  • beta - @dxos-beta/*
  • release - @dxos/*

Packages can only have dependencies on other packages with the stability level equal to theirs or higher.
Example: @dxos-dev/sdk can depend on @dxos-dev/object-model, @dxos-beta/object-model or @dxos/object-model, but not @dxos-nightly/object-model.

We develop a set of tooling to promote packages across boundaries and verify the integrity of dependencies.

Network and Testing

A discussion on how to rationalize and unify our approach to network interaction in testing, through from unit testing up to system testing. Current situation:

Simple Stream Components

We have "lower layer" components (e.g. hypercore/FeedStore/Protocol) that present a simple replication stream interface but otherwise have no knowledge of or interest in the operation of the networking layer. This boils down to there being, somewhere, a method like : networkAbleThing.createReplicationStream() -> DuplexStream. Provided that stream is hooked up to some other peer stream, the component functions, regardless of the type of stream transport. We have built unit tests for components such as Models that are lightweight, minimally dependent, and allow a high level of control and introspection, required for those tests (e.g. the ability to selectively enable and disable replication between specific nodes). These tests are built from the components mentioned above that expose a createReplicationStream() type method, and some "orchestrating" test fixture that typically arranges to pipe the streams together and keep track of the nodes, such as @dxos/feed-replication-network. Although not strictly required by the simple stream interface, all the current tests feature a simulated network component that both maintains connections between nodes and also controls node creation. Examples: echo-environment-test and model.test.ts

P2P Network-Aware Components

We have higher layers in the system that in order to function need richer interaction with the network than exposing a single stream. For example HALO components need to "open" a p2p swarm with a topic determined internally, and they need to run kinds of Protocol over different connections. This rich interaction has been abstracted via the @dxos/network-manager interface. There are currently two implementations of NetworkManager : webRTC data channel transport using @geut/discovery-swarm-webrtc; and in-process Node.js DuplexStream transport using @dxos/discovery-swarm-memory. Neither currently has the capability to control replication. Networks are always fully reachable. We have tests using this interface that are both in-process and multi-process. Examples: 'party-manager-parties.test.js' and 'spawn-testing'.

Unification

In order to create a unified testing framework derived from NetworkManager several differences in the two approaches must be reconciled:

  1. The framework has to accommodate both "stream-aware" and "NetworkManager-aware" components.
  2. The framework has to facilitate fine control over replication.
  3. Tests using the "simulated network creates nodes" approach need to be re-written to create their own nodes, or a new generic facility for node management added somewhere.

Dependency verification tooling

  • Verify that all workspace packages share the same version specifier for a given dependency
  • Verify against NPM that the latest version is used for DXOS packages
  • DXOS package upgrade script
  • CI that runs on minimal matching version for DXOS dependencies
  • Scan yarn.lock + node_modules tree and verify that there are no duplicates

Main -> Master Conversion Tracking

Per DEP0, a subtask was to convert repos to use the now standard convention of using 'main' as the default branch instead of master.

These are the repos which remain to be converted:

Using Bot Framework for Tests

Goals

  1. Test bot code within the Gravity Orchestrator/Agent test framework.
  2. Unify the Orchestrator/Agent framework and Bot framework where practical.

Short Term Plan

  • Make an Agent compatible with Bot factory API.
  • Test Orchestrator uses Bot factory to spawn Agents, locally.
  • Tunnel Orchestrator/Agent communication via Bot factory channel.
  • Package Agent as Bot.
  • Test with remote Bot factories.

Current status:

Agent testing

  • Multiple agent processes exec'ed on the local machine.
  • Agent processes on different non-local machines. See: #30
  • Design Agent API for seamless Bot-ification.

Bot framework

  • Packaging/distribution optimizations.
  • Tunnel Orchestrator/Agent commands and status/metrics through bot factory.
  • Base/stripped down bot (no Client).
  • Bot-in-browser runtime.
  • Meta-orchestrator (place bot/agent on different machines).
  • Agents/Nodes can be packaged and run as Bots.
  • Test orchestrator can drive Bot factory.

architecture-diagram

@dxos/node-spawner tests hang/timeout in CI environment

If a jest test times out in github actions, for some reason this isn't reported as "the test timed out, fail", but rather the CI job seems to spin and is killed for excess run time.

Currently the @dxos/node-spawner tests have this problem:

@dxos/node-spawner: FAIL test/local.test.ts (9.072 s)
@dxos/node-spawner:   ✓ in-process TestAgent (46 ms)
@dxos/node-spawner:   ✕ in-process ClientAgent (5345 ms)
@dxos/node-spawner:   ● in-process ClientAgent
@dxos/node-spawner:     : Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.Error:
@dxos/node-spawner:       10 |   node.sendEvent({});
@dxos/node-spawner:       11 | 
@dxos/node-spawner:     > 12 |   node.snapshot();
@dxos/node-spawner:          | ^
@dxos/node-spawner:       13 | 
@dxos/node-spawner:       14 |   orchestrator.destroy();
@dxos/node-spawner:       15 | });
@dxos/node-spawner:       at new Spec (node_modules/jest-jasmine2/build/jasmine/Spec.js:116:22)
@dxos/node-spawner:       at Object.<anonymous> (test/local.test.ts:12:1)

I've temporarily disabled tests in this package for CI in order to get the build to pass.

Rationalize testing frameworks

Gravity should contain a set of low-level testing modules and a SMALL number of non-redundant testing frameworks (or harnesses/testbenches).

Types of test

  • System testing modules that handle set-up of client/peers (e.g., common construction of Client using SDK)
  • Agent-based: user code that uses the full stack using the bot API
    • Single process (in-memory, fake transport)
    • Spawned processes on same machine using webrtc
    • Simulated in headless browser
    • Multiple machine testing via KUBE bot-framework

Use cases

  • App/Model testing (e.g., text, object consistency)
  • Stress-testing stack/pipeline to determine throughput/latency
  • Simulation of network topologies
  • Strict in-process tests that exercise contrived boundary and race conditions

Notes

  • We should consolidate "agent" testing with the bot framework since the BotFactory-Bot management mechanism is essentially similar to the current spawn-testing framework (incl. RPC).
  • Agents typically run autonomously using parties/items/model via feed replication. However, the Bot API should be extended so that Bots can receive "events" from other sources. E.g., for testing the bot/agent could receive "commands". Bots also need this functionality (e.g., sync gmail account). This requires a bot event abstraction.

Design issues

  • Unify spawn/bot-factory life-cycle for agents/bots
  • Event abstraction for agent/bots
  • Testing/agent orchestrator to use agent/bot events
  • Snapshot models for deep comparison

Candidate repos to merge:

  • echo-environmental-test (rename; currently text-model depends on this).
  • spawn-testing
  • feed-network-replicator

Naming

In the design and code let’s use the word node consistently instead of agent. Node orchestrator, factory, etc. you spawn a node. INSIDE the node runs a bot or agent. The bot/agent is user code that may be instantiated via ipfs etc.

Nodes are peers of each other. Bots are a kind if agent. They create a Client object to interact with parties and manipulate data. But other summer kinds of agents can be instantiated within a node. Eg a random number agent that just logs numbers. Or a logging agent that just logs events.

Related: #4

Gravity - inviting more then 5 peers doesn't work

The system hangs. Possibly when bot tries to connect to the control topic

2020-11-27T13:08:27.606Z bot-factory:99946 (node:99949) UnhandledPromiseRejectionWarning: Error: Timed out in 30000 ms.
    at Timeout.<anonymous> (/Users/dmaretskyi/Projects/work/wireline/sdk/bot/bot/node_modules/@dxos/async/src/async.js:59:14)
    at listOnTimeout (internal/timers.js:554:17)
    at processTimers (internal/timers.js:497:7)
(node:99949) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:99949) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Versioning requirements

Requirements

  1. Dependency ranges should not stretch across releases with breaking changes. This will ensure that existing releases on NPM are not broken by a future breaking change in their dependency graph.
  2. We should use version ranges to deduplicate compatible packages. The reasoning is, that widely used utility packages such as crypto or async do not frequently receive breaking changes but multiple installations of the same package might be incompatible with each other. Having an efficient and automatic method to deduplicate them is essential for developer experience.
  3. Bumping major version should only happen on big releases (1-2 year intervals) and should not be dictated by changes in code.

Solution

Versioning scheme

In light of those requirements it's important to define a versioning scheme that allows us to differentiate between breaking and non-breaking changes and set those filters in our dependency ranges. Semver is widely used standard that is consistent with requirements 1 and 2, but unfortunately contradicts requirements 3, as all breaking changes in semver must bump MAJOR.

I propose a versioning scheme that is similar to semver with a single modification that MAJOR stays constant, and MINOR is bumped on breaking change. PATCH is used for non-breaking releases.

To specify dependencies we can use tilde ranges (~). ~1.2.3 would match anything from >=1.2.3 up to <1.3.0. This would allow non-breaking updates to be installed automatically. But would prevent new releases with breaking changes from breaking already published releases.

Using ranges in this way also limits our use of preids for alpha and beta releases. Specifying them as postfixes as we do now will interfere with range resolution. So instead alpha releases from main branch will be published under alpha tag on NPM, and beta releases from beta branch will be published under beta tag. Packages published from release branch will go under latest tag.

Epic : Repo standardization & cleanup

https://docs.github.com/en/free-pro-team@latest/github/creating-cloning-and-archiving-repositories/creating-a-template-repository

  • Delete 'master' and any dead branches
  • Consistent Github Actions
    • Timeouts added #65
    • Code coverage
      • Output going to wiki dashboard
    • Release-please
    • Unit tests ( >1 and remove "--passWithNoTests" from jest)
  • Protected branches
  • Cleaned up README.md and docs
  • Consistent scripts in package.json
  • Templates (in .github)
    • ISSUE_TEMPLATE.md
    • PULL_REQUEST_TEMPLATE.md

Gravity

Priorities

  • Bots integrated with gravity
  • Remote agent testing working
  • Message model multi agent party

Arena, ChessBot Quality Remediation

  • Fix ChessBot / Bot Factory so it actually can be invited to a Party and play a game of chess. Make sure to deploy it to wrn://dxos/bot/chess@alpha NOT wrn://rzadp/bot/chess dxos/arena#112
  • Daily Manual test run of the Arena test plan
  • Post-publish manual test run required for dependency updates (Arena, CLI, ChessBot, Bot Factory)
  • Verify step required for NPM package updates (ex : https://www.npmjs.com/package/@dxos/network-manager is 1.0.0-beta.107, https://github.com/dxos/mesh/blob/main/packages/network-manager/ is 1.0.0-beta.113)
  • Nightly Gravity test run for Arena, invite two bots and have them play chess vs each other
  • Add CI flow for bots so they deploy like apps
  • Update console to link to bot code like we do for apps

Testing frameworks.

We have a complex stack and many different micro-frameworks for testing these. The goal is to create a unified testing framework that is adaptable to isolate different parts of the stack (e.g., network, replication, parties, item/model consistency, etc.) And to create simulations to stress test the system.

Currently https://github.com/dxos/sdk/tree/master/testing/spawn-testing implements the most general testing framework.

For discussion:

DEP0 - A branching and naming convention across all projects

Note: OUT OF DATE, read this instead: https://github.com/dxos/gravity/blob/master/docs/content/process/branching.md

Proposal

Documentation

To be codified in long term storage via https://github.com/dxos/gravity/tree/main/docs/content/process/branching.md

Problem Statement

  • DXOS projects need a consistent and concise convention to follow regarding branches and their relation to daily work vs more stable releases.

Proposed Solution

  • Developers MUST submit their work via pull requests to the main branch. ((currently named 'master' due to grandfathered convention. duplication and migration of default branch is recommended))
    Only pull requests which pass CI and review should be merged. This presumes and requires an established CI system.
    The CI will use https://github.com/googleapis/release-please to manage publishing and semver.
  • Commit messages should follow https://www.conventionalcommits.org/en/v1.0.0/
  • The channel which will be published via this method shall be considered release
  • The latest version of the main branch at any time shall be considered master
  • Channels will follow the convention established of rising fidelity master -> dev -> beta -> release
    (ex: https://github.com/brave/brave-browser/wiki/Release-Channel-Descriptions)
  • Each step in channel layers expectations of quality.
  • For starting projects, a concatenated set of Master -> Release channels is sufficient.
  • Release conditions are managed per-project in their docs/content/process/release.md which will specify any non-automated constraints.

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.