Git Product home page Git Product logo

primitives's Introduction

Primer Primitives

npm package

This repo contains values for color, spacing, and typography primitives for use with Primer, GitHub's design system.

primer primitives diagram

Install

This repository is distributed on npm. After installing npm, you can install @primer/primitives with this command.

npm install --save @primer/primitives

Usage

Storybook | Docs

Primitive data is served in several formats from the dist/ folder:

  • dist/scss contains SCSS files that define CSS variables to be imported into other SCSS files
  • dist/json contains JSON files for each set of primitives
  • dist/js contains CommonJS-style JavaScript modules for each set of primitives, as well as an index file that loads all of the primitives for all primitive types; you can access this via require('@primer/primitives'). The JavaScript modules also include TypeScript typings files for use in TypeScript projects.

Deprecating variables

To deprecate a variable, define a mapping from the deprecated variable to its replacement(s) in a file called deprecated.json in the appropriate subdirectory of data:

  data/
    colors/
+     deprecated.json
    spacing/
    ...
// data/colors/deprecated.json

{
  "text.primary": "fg.default", // this means: `text.primary` is deprecated. Use `fg.default` instead
  "auto.blue.4": ["accent.fg, accent.emphasis"], // this means: `auto.blue.4` is deprecated. Use `accent.fg` or `accent.emphasis` instead
  "text.white": null // this means: `text.white` is deprecated. We don't have a replacement for it
}

During the build process, the deprecated.json files will be added to a dist/deprecated directory organized by variable category:

  dist/
    js/
    ts/
    json/
    scss/
+   deprecated/
+     colors.json

Removing variables

When you're ready to remove a variable, first remove it's definitions:

// data/colors/vars/global_light.ts
import {get} from '../../../src/utils-v1'

export default {
  text: {
-   primary: get('scale.gray.9'),
    secondary: get('scale.gray.6')
  }
}
// data/colors/vars/global_dark.ts
import {get} from '../../../src/utils-v1'

export default {
  text: {
-   primary: get('scale.gray.1'),
    secondary: get('scale.gray.3')
  }
}

Then remove it from deprecated.json and add it to removed.json:

// data/colors/deprecated.json
{
- "text.primary": "fg.default"
}
// data/colors/removed.json
{
+ "text.primary": "fg.default"
}

During the build process, the removed.json files will be added to a dist/removed directory organized by variable category:

  dist/
    js/
    ts/
    json/
    scss/
    deprecated/
+   removed/
+     colors.json

V8 Tokens

With /primitives version 8, design tokens have been moved to json files in the src/tokens directory. Those tokens are compiled with style dictionary in scripts/buildTokens.ts.

To make working with tokens easier, we added some additional functionality on top of what style dictionary comes with:

Extending and Overwriting

We have two main color modes: light and dark. Additionally we have specific accessibility modes based on those, such as light high contrast.

We added a way to create a mode by only including the changes from the main mode. We call this overrides. Overrides are cerated in src/tokens/functional/color/[light|dark]/overrides/ and have to be added to themes.config.ts to work. In the individual files, e.g. light.high-contrast.json5 you can now add tokens in the same structure as in any main file, e.g. primitives-light.json5 to replace them.

Transforming Colors with Alpha and Mix

Alpha

You can create color tokens that inherit a color but have a different alpha value by adding the alpha property. Note: The original alpha value will be replaced by your value. If you add alpha: 0.4 to a color, it doesn't matter if the color you reference has no alpha or alpha: 0.7, the new token will always have newly the defined value of alpha: 0.4.

{
  muted: {
    $value: '{base.color.blue.3}',
    alpha: 0.4, // the opacity value of the color === 40% opaque
    $type: 'color',
  }
}

Mix

In rare cases, you may need to create a color between two steps in the color scale, e.g. between gray.4 and gray.5. A common example are interactive states, like hover where a full step on the color scale would be to much. For those cases you can use the mix property.

The mix proeprty mixes the color it gets into the main color from the $value attribute. The amount added is controlled by the weight. A weight of 0.1 adds 10% of the color, and a weight of 0.75 adds 75%.

A mix proprty must always have a color and a weight child. color can be a hex value or a reference to a valid color. The weight property must receive a value between 0.0 and 1.

{
  control: {
  $value: '{base.color.gray.4}', // main color
  $type: 'color',
  mix: {
    color: '{base.color.gray.5}', // color to mix into the main color
    weight: 0.2, // amount of the mix color that is added === 20% of gray.5 is mix into gray.4
  },
}
}

Extensions property

According to the w3c design token specs, the $extensions property is used for additional meta data.

For our Figma export we use the following meta data:

  • collection the collection that the token is added to within Figma
  • mode the mode that the token is added to within the collection in Figma
  • scopes the scopes that are assigned to the token in Figma, the actual Figma compatible scopes are retreive from an object in the figmaAttributes transformer

Code example

  bgColor: {
    $value: '{borderColor.accent.muted}',
    $type: 'color',
    $extensions: {
      'org.primer.figma': {
        collection: 'pattern/mode',
        mode: 'light',
        scopes: ['bgColor'],
      },
    },
  }

Token names and @-hack

Token names have to be in camelCase or kebab-case and may only include letters, numbers and -. This is enforced by the token validation (npm run lint:tokens). The only acception is the @-hack. This is used when you want to have a default value and sub-values, e.g. bgColor.accent and bgColor.accent.muted. In this case you can create the follwing structure. The @ will be removed from the name and act as the default value.

{
  bgColor: {
    accent: {
      "@": {
        // values for accent (default)
      },
      "muted": {
        // values for accent-muted
      }
    }
  }
}

License

MIT ยฉ GitHub

primitives's People

Contributors

adrian5 avatar auareyou avatar binarymuse avatar broccolini avatar camertron avatar colebemis avatar ctmayn avatar dependabot[bot] avatar edokoa avatar github-actions[bot] avatar jonrohan avatar josepmartins avatar joshblack avatar jsoref avatar juliusschaeper avatar konradpabjan avatar langermank avatar liram11 avatar lukasoppermann avatar mperrotti avatar primer-css avatar primer[bot] avatar rezrah avatar shawnbot avatar simurai avatar smockle avatar tobiasahlin avatar vdepizzol 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

primitives's Issues

Update repo structure

Hey,

with our update to the build process I think we should reconsider the folder structure (I am sure you are thinking the same ๐Ÿ˜„ )

There are different ways of thinking about this repo. One would be the following:

This is a design token repo, so the tokens are the product (the main code)
This means:

  1. src/ holds our tokens as they are the source
  2. dist/ holds our converted tokens
  3. build.ts is moved to folder scripts/build.ts
  4. extracted modules (e.g. name conversions, formats, etc. for Style Dictionary) can be placed in a subfolder of root like libs, modules or config (since it is config for SD)

What are your thoughts @rezrah @langermank ?

Add font stacks to primer-typography

As in primer-react:

export const fonts = {
  normal: [
    '-apple-system',
    'BlinkMacSystemFont',
    '"Segoe UI"',
    'Helvetica',
    'Arial',
    'sans-serif',
    '"Apple Color Emoji"',
    '"Segoe UI Emoji"',
    '"Segoe UI Symbol"'
  ].join(', '),
  mono: [
    'SFMono-Regular',
    'Consolas',
    '"Liberation Mono"',
    'Menlo',
    'Courier',
    'monospace'
  ].join(', ')
}

imported via:

import {fonts, fontSizes, lineHeights} from 'primer-typography'

Low contrast for ANSI colors

Not sure if this is a primitives issue but am opening just in case

GItHub's VSCode theme uses primers primitives ANSI color values for the integrated terminal color theme. There are several open issues in regards to low contrast (mostly pointing to the GitHub Light Default theme) rendering some text unreadable. Is this something the primer team can look into?

Please see primer/github-vscode-theme#157 & primer/github-vscode-theme#155

Screenshots

GitHub Light Default GitHub Dark Default GitHub Dark Dimmed
screenshot-Sat-17Apr21_00 17 screenshot-Sat-17Apr21_00 18 screenshot-Sat-17Apr21_00 18_000

[Token update]: Shadows

I noticed that shadows are currently part of colors. This makes no sense as the token actually is a css shadow with offset, etc. and not just the color.

At the moment we also don't really have important reasons to make shadows adjust to color modes. In dark shadows are invisible and in light we currently keep shadows the same.

Atm I added some new shadow-colors that are used in the new shadows in #353

However I think a better approach would do not use the color scale and just use #000000 black with different opacities. And keep it the same for all color modes. This would not change much for the visual, but would allow us to keep shadows and their colors in one file without depending on color modes.

Looking at some of the shadows that e.g. @vdepizzol added we probably want to move into multi/layer shadows in the future. They look more polished and also more natural as this is how light behaves in the real world.

Using color tokens would mean we would need a lot of color tokens (one per opacity). If we end up with just 5 or 10 that would be no problem. However if we have more custom alpha values, including colors into the shadow files would allow us to avoid tokens and directly define colors inside the shadow token.

CC: @langermank @josepmartins @rezrah any objections?

Move to json5 for token source files.

Hey @langermank and @rezrah what do you think about moving to JSON5 for our token source files?

I think it would be great to be able to leave comments in the files, which is sadly not possible with json.

All it would require is one dependency, JSON5, this can simply be use in the parsers, so it has no influence at all on the Style Dictionary setup, once the parser runs.

npm package is not built for publish

Hi Primer team!

There is no dist/ directory in the latest npm package.

When I install via npm i @primer/[email protected] (v4.3.10, or npm i @primer/primitives, fails to install), only the source code is there, not the built output. See the contents to the left below:

image

Looks like a job for npm run release.

Cheers, love the dark dimmed theme!

Map v1 variables to v2 variables

Context

We will know that the v2 color system has full coverage of the existing color system when every variable currently in Primer Primitives (v1) can be either mapped to a v2 variable or moved into github/github as an app-level variable.

Do this

In the colors_v2 directory of primer/primitives, add mappings for all v1 variables. Every v1 variable should be mapped to one of the following:

  • a v2 global variable (e.g. var(--color-fg-default))
  • a v2 component variable (e.g. var(--color-btn-primary-bg))
  • a scale variable (Only variables intended to be moved out of primer/primitives and into github/github can use scale variables. Indicate that a variable should be moved to github/github with a code comment)

Use the Migration spreadsheet as a reference.

Example

Here's an example diff showing how to add a mapping from text-primary (v1 variable) to fg-default (v2 variable):

diff --git a/data/colors_v2/mixins/migration.scss b/data/colors_v2/mixins/migration.scss
index 9892178..a723b4a 100644
--- a/data/colors_v2/mixins/migration.scss
+++ b/data/colors_v2/mixins/migration.scss
@@ -2,3 +2,6 @@
 
 // Mapping of v1 variables to v2 variables
 
+$text: (
+  primary: var(--color-fg-default),
+);
diff --git a/data/colors_v2/mixins/dark_mode.scss b/data/colors_v2/mixins/dark_mode.scss
index f64f1b4..e55756c 100644
--- a/data/colors_v2/mixins/dark_mode.scss
+++ b/data/colors_v2/mixins/dark_mode.scss
@@ -87,4 +87,5 @@ $export: (
   ),
 
   // Mapping of v1 variables to v2 variables
+  text: $text,
 );
diff --git a/data/colors_v2/mixins/light_mode.scss b/data/colors_v2/mixins/light_mode.scss
index a5d9087..a2a411f 100644
--- a/data/colors_v2/mixins/light_mode.scss
+++ b/data/colors_v2/mixins/light_mode.scss
@@ -87,4 +87,5 @@ $export: (
   ),
   
   // Mapping of v1 variables to v2 variables
+  text: $text,
 );

Acceptance criteria

This issue is complete when the v2 coverage check in primer/primitives outputs 100%:

CleanShot 2021-05-14 at 11 31 31@2x

Format script is very unhelpful and not the same as lint

Problem

While yarn lint passes, yarn format fails. This is often only noticed in the PR as I don't run format and lint.
However the output is very unhelpful.

Expected behavior

  1. If yarn lint passes, yarn format should pass as well
  2. If either fails in a PR, the issues should be reported in the action or in the PR as a comment. If people add a PR via github they have no chance of knowing what is wrong.

Cleanup / re-structuring of color tokens

Hey,
I want to discuss some opportunities of cleaning up the color tokens in this issue and see what we can remove or move.

Marketing tokens

Relates to https://github.com/github/primer/issues/1366

Do we want to have marketing tokens in primer/primitives or should they live in primer/brand?
If we keep them in primer/primitives can we move them into a marketing-light.json file and maybe implement a common naming convention?

Currently we have the following variables

    --color-marketing-icon-primary: #218bff;
    --color-marketing-icon-secondary: #54aeff;
    --color-mktg-btn-bg: #1b1f23;
    --color-mktg-btn-shadow-outline: rgb(0 0 0 / 15%) 0 0 0 1px inset;
    --color-mktg-btn-shadow-focus: rgb(0 0 0 / 15%) 0 0 0 4px;
    --color-mktg-btn-shadow-hover: 0 3px 2px rgba(0, 0, 0, 0.07), 0 7px 5px rgba(0, 0, 0, 0.04), 0 12px 10px rgba(0, 0, 0, 0.03), 0 22px 18px rgba(0, 0, 0, 0.03), 0 42px 33px rgba(0, 0, 0, 0.02), 0 100px 80px rgba(0, 0, 0, 0.02);
    --color-mktg-btn-shadow-hover-muted: rgb(0 0 0 / 70%) 0 0 0 2px inset;

Syntax highlights

@simurai mentioned that we have variables for both prettylights and codemirror. The idea would be to somehow combine this, or remove one set completely, as there are some duplications. Maybe we can have a generic setsyntax-light.json and use the variables in both codemirror and prettylights?

ANSI

We currently provide two sets of ANSI colors (that differ). --color-ansi-[black/red/...] and --color-checks-ansi-[black/red/...].
Can we remove the checks set and use the default ANSI set instead?

Base color scales

As discussed with @vdepizzol and @langermank we are planning to remove the --base-color-scale-red-... variables and not ship any color scale, only functional colors.

Feedback wanted

Please mention:

  • Anything you think should be removed or simplified
  • Any issue you see with the above mentioned changes

/ CC: @rezrah @langermank @josepmartins @jonrohan @colebemis @tobiasahlin @simurai @vdepizzol

Button component associated colors are inconsistent.

I noticed a few issues with the colors in the btn section of component themes.

  • All the variants don't have all the colors. For eg - the activeBg is only available for the default button and not for primary etc
  • Many colors are defined with just the hex and not a functional variable or any variable. hoverBg and disabledBg
  • Colors for primary button are not available in the functional colors list at all.
  • No colors defined for invisible button
  • Should the shadow values be more parameterised? For eg - selectedShadow: (theme: any) =>inset 0 1px 0 ${alpha(get('scale.green.9'), 0.2)(theme)}, how do we determine the alpha value?
  • There was also this PR raised in @primer/components to highlight missing colors in danger and primary variants.

With this issue, I wonder if it possible to either

  • Get rid of the btn component colors and directly use functional color variables. OR
  • Make the btn component colors robust and work for all scenarios.

cc - @ashygee, @colebemis

Discourage usage file for stylelint

To discourage usage of tokens like base colors we should reactivate the warning from the primer styleLint plugin.

As an input we need to create a json file like the deprecated or removed files.

This is, so that the decision which tokens usage should be discourage lies within the primer/primitives and not within the stylelint plugin repo.

How to deal with hover and selected component colors

Hey @langermank and @josepmartins,

in the old setup we have used color2k.darken to create hover and selected colors.
We need to define how we want to deal with this now.

Option 1: Use predefined color scales

I am assuming we want to avoid this as it creates unpredictable colors, correct? In this case one option would be to choose a color from the scale that is close to the darkened version.

Option 2: Use overlay

Technically we could just add a second color on top, that is black with opacity. However this is also unpredictable and will probably create a lot of complications, so I would like to avoid this.

Option 3: Continue with darken

If we are fine with have computer generated colors we could also continue with darken and add a darken transformer.
In this case however, we should define some requirements for a selected and hover color. Do we want to achieve a specific contrast to the existing color. Should it be darkened by a specific lum value? (We could try to use HSLuv here to get accurate decrease in lightness, as hsl is not very accurate).

Validation for token files

Describe the bug

Currently the source files .json5 are not validated which can lead to issues.

The idea to solve this is to use typescript types like this: https://github.com/primer/primitives/blob/design-token-type/%40types/DesignTokenJson.ts and validate the json files against it.

Maybe by using something like typescript-json-validator we can create a validation schema. This could maybe be used with eslint schema validation.

Expected results for the validator

  • work with .json5 files
  • use typescript types to validate .json5 files
  • validate all .json5 token and print helpful error messages to console
  • checks should if possible:
    • verify the properties names
    • verify properties are not missing
    • verify the values of the properties (at least in part), including custom values (if we get this to work with one example we can later on add validation for more values)

Stretch

  • add this to CI action so that the checks are done for every PR

Define a code styleguide to have more consistent code.

We should define more guidelines on style decisions for code. Maybe we can extend on the gihub eslint and create something for primer/primitives and primer/brand.

Some rules could be:

  • use type for type imports
  • group type imports last

consider to generate `sass variables` format.

For now, primitive data is served in several formats:

  • dist/scss
  • dist/json
  • dist/js

But in dist/scss, it has only mixins with all color CSS variables and make the bundle size is large. But in some scene (maybe just mine probably...) , only some colors are needed, but have to import them all.

So, wouldn't is better to generate an sass variables format like this?

// _dark.vars.scss

$canvas-default: #0d1117;
$fg-default: #c9d1d9;
// more....

usage:

@use "@primer/primitives/dist/scss/colors/_dark.vars" as dark;

:root {
  --color-canvas-default: dark.$canvas-default;
}

.box {
  color: dark.$fg-default;
}

In my case, I wrote a script to generate the vars.scss files base on json format. this issue is just a feature request.

Issues with exports

I was working with @ampinsk on using this module and we ran into a couple of issues:

First, while primer-primitives is importing the other modules here: https://github.com/primer/primer-primitives/blob/9ad6f7c7b8d7a982820146d4c1679af9124657a1/modules/primer-primitives/index.js#L1-L3

those modules aren't listed as dependencies in the primer-primitives package.json.

$ npm install --save primer-primitives
$ node
> require("primer-primitives")
Error: Cannot find module 'primer-colors'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:548:15)
    at Function.Module._load (internal/modules/cjs/loader.js:475:25)
    at Module.require (internal/modules/cjs/loader.js:598:17)
    at require (internal/modules/cjs/helpers.js:11:18)

Secondly, the individual modules don't seem to be exporting their values correctly:

$ npm install --save primer-colors
$ node
> require("primer-colors")
Error: Cannot find module 'primer-colors'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:548:15)
    at Function.Module._load (internal/modules/cjs/loader.js:475:25)
    at Module.require (internal/modules/cjs/loader.js:598:17)
    at require (internal/modules/cjs/helpers.js:11:18)

I believe this is because package.json for these modules specifies index.js as the package main, but the only file in the module is the json file with the definitions inside it.

Remove `mktg` colors from primer

Please verify if my logic is true

Context: I am talking about the mktg const in marketing_light.ts and marketing_dark.ts

I think it can be safely removed because:

  1. it is not exported from the files (โ†’ should mean they are not used)
  2. The colors are not present in the dist folder (โ†’ should mean they are not used)
  3. I can't find it in the code search --color-mktg-blue also not --mktg-green

Even the mktg button bg is only used once I think ๐Ÿค” . Or am I using the search wrong?

Move to npm

As @langermank, @rezrah and @lukasoppermann discussed we want to bring this repo back to npm.

npm is the default for github and we have no specific reason to favor yarn over npm.
Yarn also is less well maintained and has some problematic behaviors like hiding some warnings.

Rename primer-primitives to @primer/primitives

We'd like to rename this package to use the @primer npm scope, and move the different types of primitives into top-level imports, so:

  • primer-primitives becomes @primer/primitives
  • primer-color becomes @primer/primitives/color
  • primer-spacing becomes @primer/primitives/spacing
  • primer-typography becomes @primer/primitives/typography
  • We keep (or build at publish time?) the JSON forms of each primitive type so that other languages can consume them more easily.

Is it possible to create a custom theme that can be applied to both Rails and React libraries?

Context
We are looking to try out Primer to see if it can be a suitable choice both for our applications built in Rails as well as React. While the React project looks like it has the right level of customisation that we need, the Rails view components seem less customisable, at least from the documentation side.

Ideally it would be great to customise in a single place, and have that feed into both Rails and React libraries. However, customising the Rails library separately could also be an option if this was not possible.

I have only found this issue so far which alludes to plans to write some documentation to help achieve this.

Is there any updates on this?

Would be amazing if i can have same themes for vim. :)

Is your feature request related to a problem? Please describe.
I don't use vscode much, but really liked the themes by you guys, I was hoping if we can have the same themes and support for vim from you guys. would be amazing.

Describe the solution you'd like
Provide official support for vim, tmux, alacritty themes. I know this is kind of too much to ask, but just a thought.

Describe alternatives you've considered
Right now I use the Nord theme, which is pretty cool. just want to standardize GitHub all across tools.

Additional context
Nope.

primitives-4.3.8.tgz: Request failed \"404 Not Found\""

It seems I cannot install @primer/css pacakge because the latest @primer/primitives does not exists in registry.yarnpkg.com.

โฏ yarn add -D @primer/primitives                                                                                                                    โ”€โ•ฏ
yarn add v1.22.10
[1/5] ๐Ÿ”  Validating package.json...
[2/5] ๐Ÿ”  Resolving packages...
[3/5] ๐Ÿšš  Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/@primer/primitives/-/primitives-4.3.8.tgz: Request failed \"404 Not Found\"".
info If you think this is a bug, please open a bug report with the information provided in "/Users/yhay81/ghq/github.com/QuickWorkInc/salesnow-platform/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

publishing action seems failed.
https://github.com/primer/primitives/runs/2732578484

Eslint json5

Support for .json5 formatting

With the current setup .json and .json5 files are not formatted at all.

Reproduction steps

1. Go to any `.json5` file
2. Update it, e.g. with wrong indentation
3. see that nothing happens on save or format

Expected behavior

Saving a `.json5` file or running `format document` on it should format it correctly.

Improve DX with automated linting

Currently it takes some time for the pre-commit hook to run, which can degrade the DX during prototyping.

Solutions would be:

  1. Move linting and formatting to pre-push hook

  2. Only run select linting and formatting checks on pre-commit (and only on changed / staged files) and reserve entire run for pre-push.

I think I would prefer the second option, would this be fine for you @langermank?

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.