Giter VIP home page Giter VIP logo

example's Introduction

Example Design System

This design system is based on the NL Design System architecture.

For more info about the NL Design System and learn about things happening in our open source community, join the #nl-design-system Slack via praatmee.codefor.nl!

✂ In your own repository: remove the "Getting started" section below!

Getting started with the NL Design System template

This template contains all relevant linting rules used by the NL Design System repository. It also contains the Storybook setup with two example components and two example general documentation page. Feel free to add or modify those documentation pages and use the example components as an initial template to create your own storybook components.

Install prerequisites

You need to have the following tools installed to run Storybook locally:

Customize organization settings

  1. Choose a prefix for your organisation. For example: the main NL Design System uses nl-, The Hague uses denhaag-, and you can choose something unique for you to use.
  2. Modify .stylelintrc.json by replacing the prefix example with the prefix you have chosen, in the following rules: custom-property-pattern, selector-class-pattern, keyframes-name-pattern, scss/dollar-variable-pattern and scss/percent-placeholder-pattern.
  3. Choose and register an npm organisation on npmjs.com, if you haven't already. This is very important to keep your project secure. The core NL Design System uses @nl-design-system/, and you can choose something for yourself. This prevents others from adding their code to your teams codebase.
  4. Modify all package.json files to use your npm organisation scope. Don't forget the locally linked packages under devDependencies. Find and replace all occurences of @example/ in your project with @your-organisation/. Run pnpm install to install each package in under the new organisation directory in each node_modules/.
  5. Modify .npmpackagejsonlintrc.json to require your organisation scope in package names, by configuring the valid-values-name-scope property.
  6. Modify the imports in /packages/storybook/config/preview.tsx and packages/web-components-stencil/src/button/index.scss to use your prefix.
  7. Modify proprietary/design-tokens/style-dictionary.config.json to output .yourprefix-theme instead of .example-theme.
  8. Modify preview.tsx to use yourprefix-theme instead of example-theme as default theme for Storybook stories.

Run storybook

  • Install dependencies: pnpm install
  • Run storybook: npm run storybook

Change the theme of your storybook to match your brand

In .storybook/customTheme.js the theme used by NL Design System can be found. By changing those properties one can style the storybook to match ones brand. Checkout https://storybook.js.org/docs/react/configure/theming to learn more about all the possible configurations to brand this storybook.

Adding UX and other documentation without a component implementation

  1. In src/demo-empty-component an example story of a documentation first (or documentation only) component can be found.
  2. Copy this folder
  3. Rename to match your component
    • The folder
    • The x.stories.mdx to component-name.stories.mdx
    • The title of the Meta component in component-name.stories.mdx
  4. Add the UX guidelines inREADME.md
  5. Optionally add the component specific accessibility or content guidelines in docs/accessibility-guidelines or docs/content-guidelines.
  6. Optionally add the Figma component in component-name.stories.mdx by adding part of the Figma url to the Figma component <Figma title="Link" url="file/..." />

Adding design tokens

Add global tokens to /brand.css. Add tags to make them appear in the Storybook Design token addon. For example @tokens Colors and @presenter Color. See https://storybook.js.org/addons/@tommyem/storybook-design-token for more details.

Adding the component implementation to storybook

In src/demo-link-component an example story and web-component can be found. All steps below are represented in this demo-link.stories.mdx example. To add a component implementation to storybook, we use the <component-name>-stories.mdx which already contains the documentation pages or create one with placeholder documentation by following step 1-3 from the Adding UX and other documentation without a component implementation chapter.

  • Create a component template function that takes variable arguments. If an argument might contain childnodes, use the sanatize package to prevent unsafe content and injections. Place this Template function above the Meta component
  • Declare a story for each component variation and bind the template
  • Declare the possible inputs, with types and a description in the argTypes property of the Meta component in stories.mdx.
  • Add an Argstable component in your stories.mdx
  • Optionally add a different status to the Meta parameters. The options and colors can be found in storybook/config/preview.tsx

Configuring the GitHub repository

Things we usually do:

  • Generate fine grained personal access token in GitHub, with rights to push npm version commits. Use a name that will be clear when the token expires, for example: nl-design-system/example GH_TOKEN. Choose "All repositories". For "Resource owner" choose the user or organisation of the repository. For "Repository access" choose "Only select repositories", and select only your repository. Expand "Account permissions", then for "Contents" select "Read and write".
  • Configure GH_TOKEN in Repository tokens, for use in the publish-npm GitHub Action. You might notice the GITHUB_TOKEN already exists, but the GITHUB_ prefix is used by GitHub itself and the token has read-only rights.
  • Go to npmjs.com and create an "Granular Access Token". Use a name that serves as hint where to reset the token when it expires, for example: nl-design-system/example NPM_TOKEN. For "Permissions", allow only "Only select packages and scopes" and choose the scope of your npm packages. Do not store the token anywhere, just copy it to GitHub once. You can always generate new tokens, and they will be protected by multi-factor authentication.
  • Configure NPM_TOKEN in Repository tokens, for use in the publish-npm GitHub Action.
  • Configure GitHub repository settings
    • General settings
      • Uncheck "Allow merge commits"
      • Should already be checked: "Allow squash merging"
      • Should already be checked: "Allow rebase merging"
      • Check "Allow auto-merge"
      • Check "Automatically delete head branches"
    • Branches
      • Add rule to protect main branch. Branch pattern should be exactly main.
        • Check "Require a pull request before merging"
        • Check "Require approvals" with at least one approval.
        • Check "Require approval of the most recent reviewable push"
        • Check "Require status checks to pass before merging"
        • Search for the following status checks, and make them required:
        • Make install a required status check.
        • Make lint a required status check.
        • Make test a required status check.
        • Make build a required status check.
        • Optional: configure Chromatic visual regression tests as a required status check.
        • Check "Require linear history"
      • Add rule to protect gh-pages branch, to prevent someone from deleting it accidentally.
  • Enable GitHub Pages to host Storybook
    • Go to Pages, choose "Deploy from a branch" with gh-pages as branch with / (root) as folder. If gh-pages is not in the list, make sure the publish-website action succeeds at least once.
    • In the "Code" tab (the home page of your repository), configure the "About" section. Use "your GitHub Pages website" as "Website" of your repository.
    • Configure "nl-design-system" as one of the topics of your repository.

If you get this the following error, you still need to configure NPM_TOKEN in your repository settings. Use "Generate New Token" in Access Tokens of npmjs.com to create a new automation tokne. Use "New repository secret" in GitHub Repository Secrets to configure it.

Run actions/checkout
Error: Input required and not supplied: token

✂ In your own repository: remove the "Getting started" section above!

Code of Conduct

We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community. Read our Code of Conduct if you haven't already.

License

This project is free and open-source software licensed under the European Union Public License (EUPL) v1.2. Documentation is licensed as Creative Commons Zero 1.0 Universal (CC0-1.0)

For information about proprietary assets in this repository, please carefully read the NOTICE file.

example's People

Contributors

robbert avatar matijs avatar yolijn avatar dependabot[bot] avatar andreabusse29 avatar alimpens avatar hidde avatar

Stargazers

Guilherme Abel avatar Eben avatar Aleksandr Beliaev avatar JinmingYang avatar Roel Antonisse avatar avatar

Watchers

James Cloos avatar Wart Burggraaf avatar

Forkers

lohbrandt

example's Issues

Patch round 2024-01

Pro-tip: ignore warnings about deprecated packages until you have completed upgrade of major releases. Often major releases will fix deprecated warnings.

Configuration

The following configuration is a prerequisite for this workflow. All of this should have already been installed and configured.

  • npm-check-updates is installed in the root, and there are three npm scripts:
    • pnpm run update-patch with .ncurc.patch.cjs as configuration file
    • pnpm run update-patch with .ncurc.minor.cjs as configuration file
    • pnpm run update-major with .ncurc.major.cjs as configuration file
    • pnpm run test-update to run the continuous integration steps as "smoke test".
  • npm-package-json-lint with .npmpackagejsonlintrc.json as configuration file
  • Require fixed version dependencies for npm:
    • .npmrc has save-prefix= to override the ^ or ~ with an empty string
    • .npmrc has save-exact=true
    • none of the existing package.json files have ^ and ~ dependencies.
    • package-json-lint checks the following rules:
      • "no-caret-version-dependencies": "error"
      • "no-caret-version-devDependencies": "error"
      • "no-tilde-version-dependencies": "error"
      • "no-tilde-version-devDependencies": "error"
  • the pnpm-lock.yaml lock file for the package manager has been committed to the git repo (and lock files for other package managers have been added to .gitignore to prevent accidentally committing those)
  • "Security advisories" for this repository are enabled, as well as Dependabot alerts.

Preparation

  • Check the /.patches/ directory in the root (if present), and see if there are any npm packages that have overrides for their code.
    • When for a patch/minor/major update these package are updated, you must also create a new version of the patch file. Create a task for this in this issue.
    • Sometimes the patch is no longer necessary, because the bug that the patch is for has been fixed in the actual package. Read the commit message for the patch, or read the GitHub PR comments or the related GitHub issue comments to find out what the patch was for.
    • Ideally the patch files have a code comment in .patches/README.md explaining the conditions when the patch is no longer required.

npm dependencies

We use the npm-check-updates package to upgrade to new versions of npm packages, and have consistent versions across all packages in our mono-repository.

There are three configuration files:

  • .ncurc.patch.cjs: include packages in this array to prevent upgrading patch versions and higher.

  • .ncurc.minor.cjs: prevent upgrading to new minor versions and higher.

  • .ncurc.major.cjs: prevent upgrading to new major versions and higher.

  • Check the configuration files above, to see if some of the updates no longer need to be blocked. Ideally the entries in these files have a code comment explaining the conditions where the upgrade no longer needs to be prevented.

patch versions

We don't allow ~1.0.0 style dependencies, so patch versions will not be installed automatically (1.0.0 to 1.0.1). That's why it is important to frequently install patches yourself.

  • Run pnpm run update-patch to install new patch versions.
  • Run npm run test-update and see if the build/lint/test scripts are still OK.
  • Check if the logs contain any (new) warnings. You can compare the logs with GitHub Action logs for the main branch.
  • If a patch update is problematic, you can temporarily add the package to the "ignore updates" list in .ncurc.patch.js.

Not all package maintainers use semantic versioning, especially 0.x.x versions, and alpha and beta versions. Unfortunately they will be installed as part of update-patch, so update-patch isn't as safe as you might think. You might want to read change logs of patch upgrades below 1.0.0 to see if there are breaking API changes.

  • Check if any packages have upgrades like 0.1.2 ➝ 0.1.9, and pay extra attention to these packages.

Create a pull request at this stage already, since minor upgrades and major upgrades might take some effort. Patches sometimes contain security vulnerability fixes.

minor versions

We don't allow ^1.0.0 style dependencies (1.0.0 to 1.0.1)

  • ideally install pnpm run update-minor.
  • Run npm run test-update and see if the build/lint/test scripts are still OK
  • If a minor update is problematic, you can add the package to the "ignore updates" list in .ncurc.minor.js.

major versions

  • if there is time, install pnpm run update-major.
  • Run npm run test-update and see if the build/lint/test scripts are still OK
  • If a major update is problematic, you can add the package to the "ignore updates" list in .ncurc.major.js.

Make an issue for minor/major upgrades that require so much time we better schedule it in a sprint.

deprecations

Run pnpm install. If the log still contains deprecation warnings at this stage, check if they are direct dependencies. Are the dependencies mentioned in our own package.json files? Then it its probably worthwhile to investigate why the package is deprecated. A good information source is often the README on the page about the package on npmjs.com. They will likely mention the reason for deprecating the page (e.g: no time to install security patches, you are on your own!) and they might even suggest alternative packages.

GitHub Action

Dependabot pull requests are a great way to detect outdated dependencies in GitHub Actions.

  • Upgrade all GitHub Action dependencies

Node.js

Check the Node.js website to see what the long term support version is ("Node LTS")

  • Upgrade to the latest minor Node LTS version (long term support)
    • package.json
    • .nvmrc
    • .github/workflows/*: configure node-version or reference node-version-file: ".nvmrc"
  • Vercel: go to project Settings ➝ General ➝ Node.js version and select the new major version

pnpm

  • Upgrade to latest pnpm version
    • .github/workflows/*": upgrade pnpm version in GitHub Actions for pnpm
    • package.json under engines. "^version" is usually okay, an exact version dependency is undesirable for developer experience, unless everyone develops in Docker containers. You can install an exact version of pnpm in GitHub Action if you want to.

Vulnerabilities

  • Check the "Security" tab of this GitHub repository and consider the Vulnerabilities
  • Upgrade all vulnerable dependencies, or dismiss the alerts with a good reason.

Docker images

Currently this repo doesn't have a docker-compose.yml where image needs to be updated, or any Dockerfile where FROM needs to be updated.

Patch round 2024-03

Pro-tip: ignore warnings about deprecated packages until you have completed upgrade of major releases. Often major releases will fix deprecated warnings.

Configuration

The following configuration is a prerequisite for this workflow. All of this should have already been installed and configured.

  • npm-check-updates is installed in the root, and there are three npm scripts:
    • pnpm run update-patch with .ncurc.patch.cjs as configuration file
    • pnpm run update-patch with .ncurc.minor.cjs as configuration file
    • pnpm run update-major with .ncurc.major.cjs as configuration file
    • pnpm run test-update to run the continuous integration steps as "smoke test".
  • npm-package-json-lint with .npmpackagejsonlintrc.json as configuration file
  • Require fixed version dependencies for npm:
    • .npmrc has save-prefix= to override the ^ or ~ with an empty string
    • none of the existing package.json files have ^ and ~ dependencies.
    • package-json-lint checks the following rules:
      • "no-caret-version-dependencies": "error"
      • "no-caret-version-devDependencies": "error"
      • "no-tilde-version-dependencies": "error"
      • "no-tilde-version-devDependencies": "error"
  • the pnpm-lock.yaml lock file for the package manager has been committed to the git repo (and lock files for other package managers have been added to .gitignore to prevent accidentally committing those)
  • "Security advisories" for this repository are enabled, as well as Dependabot alerts.

Preparation

  • Check the /.patches/ directory in the root (if present), and see if there are any npm packages that have overrides for their code.
    • When for a patch/minor/major update these package are updated, you must also create a new version of the patch file. Create a task for this in this issue.
    • Sometimes the patch is no longer necessary, because the bug that the patch is for has been fixed in the actual package. Read the commit message for the patch, or read the GitHub PR comments or the related GitHub issue comments to find out what the patch was for.
    • Ideally the patch files have a code comment in .patches/README.md explaining the conditions when the patch is no longer required.

npm dependencies

We use the npm-check-updates package to upgrade to new versions of npm packages, and have consistent versions across all packages in our mono-repository.

There are three configuration files:

  • .ncurc.patch.cjs: add packages to the reject array in this file to prevent upgrading patch versions and higher.

  • .ncurc.minor.cjs: add packages to the reject array in this file to prevent upgrading to new minor versions and higher.

  • .ncurc.major.cjs: add packages to the reject array in this file to prevent upgrading to new major versions.

  • Check the configuration files above, to see if some of the updates no longer need to be blocked. Ideally the entries in these files have a code comment explaining the conditions where the upgrade no longer needs to be prevented.

patch versions

We don't allow ~1.0.0 style dependencies, so patch versions will not be installed automatically (1.0.0 to 1.0.1). That's why it is important to frequently install patches yourself.

  • Run pnpm run update-patch to install new patch versions.
  • Run npm run test-update and see if the build/lint/test scripts are still OK.
  • Check if the logs contain any (new) warnings. You can compare the logs with GitHub Action logs for the main branch.
  • If a patch update is problematic, you can add the package to the reject list in .ncurc.patch.js.

Warning

Not all package maintainers use semantic versioning, especially 0.x.x versions, and alpha and beta versions. Unfortunately they will be installed as part of update-patch, so update-patch isn't as safe as you might think. You might want to read change logs of patch upgrades below 1.0.0 to see if there are breaking API changes.

  • Check if any packages have upgrades like 0.1.2 ➝ 0.1.9, and pay extra attention to these packages.

Create a pull request at this stage already, since minor upgrades and major upgrades might take some effort. Patches sometimes contain security vulnerability fixes.

minor versions

We don't allow ^1.0.0 style dependencies (1.0.0 to 1.1.0)

  • Run pnpm run update-minor to install new minor versions.
  • Run npm run test-update and see if the build/lint/test scripts are still OK
  • If a minor update is problematic, you can add the package to the reject list in .ncurc.minor.js.

major versions

  • if there is time, install pnpm run update-major.
  • Run npm run test-update and see if the build/lint/test scripts are still OK
  • If a major update is problematic, you can add the package to the reject list in .ncurc.major.js.

Make an issue for minor/major upgrades that require so much time that they need to be scheduled it in a sprint.

deprecations

Run pnpm install. If the log still contains deprecation warnings at this stage, check if these warnings are for direct dependencies (Are the dependencies mentioned in our own package.json files?). If so, it is probably worth it to investigate why the package is deprecated. A good information source is often the README on the page about the package on npmjs.com. They will likely mention the reason for deprecating the page (e.g: no time to install security patches, you are on your own!) and they might even suggest alternative packages.

GitHub Action

Dependabot pull requests are a great way to detect outdated dependencies in GitHub Actions.

  • Upgrade all GitHub Action dependencies. These can be cherry-picked from pull requests that were opened by Dependabot if you like.

Node.js

Check the Node.js website to see what the current long term support version is ("Node LTS")

  • Upgrade to the latest minor Node LTS version (long term support) by updating the following files:
    • package.json under "engines"
    • .nvmrc
    • .github/workflows/*: configure node-version or reference node-version-file: .nvmrc
  • Vercel: go to project Settings ➝ General ➝ Node.js version and select the new major version

pnpm

  • Upgrade to latest pnpm version
    • .github/workflows/*": upgrade pnpm version in GitHub Actions for pnpm
    • package.json under engines. "^version" (i.e. "^20") is usually okay, an exact version dependency is undesirable for developer experience, unless everyone develops in Docker containers. You can however provide an exact version of pnpm in GitHub Action if you want to.

Vulnerabilities

  • Check the "Security" tab of this GitHub repository and consider the Vulnerabilities
  • Upgrade all vulnerable dependencies, or dismiss the alerts with a good reason.

Docker images

Currently this repo doesn't have a docker-compose.yml where image needs to be updated, or any Dockerfile where FROM needs to be updated.

Patch round 2024-01

Pro-tip: ignore warnings about deprecated packages until you have completed upgrade of major releases. Often major releases will fix deprecated warnings.

Configuration

The following configuration is a prerequisite for this workflow. All of this should have already been installed and configured.

  • npm-check-updates is installed in the root, and there are three npm scripts:
    • pnpm run update-patch with .ncurc.patch.cjs as configuration file
    • pnpm run update-patch with .ncurc.minor.cjs as configuration file
    • pnpm run update-major with .ncurc.major.cjs as configuration file
    • pnpm run test-update to run the continuous integration steps as "smoke test".
  • npm-package-json-lint with .npmpackagejsonlintrc.json as configuration file
  • Require fixed version dependencies for npm:
    • .npmrc has save-prefix= to override the ^ or ~ with an empty string
    • none of the existing package.json files have ^ and ~ dependencies.
    • package-json-lint checks the following rules:
      • "no-caret-version-dependencies": "error"
      • "no-caret-version-devDependencies": "error"
      • "no-tilde-version-dependencies": "error"
      • "no-tilde-version-devDependencies": "error"
  • the pnpm-lock.yaml lock file for the package manager has been committed to the git repo (and lock files for other package managers have been added to .gitignore to prevent accidentally committing those)
  • "Security advisories" for this repository are enabled, as well as Dependabot alerts.

Preparation

  • Check the /.patches/ directory in the root (if present), and see if there are any npm packages that have overrides for their code.
    • When for a patch/minor/major update these package are updated, you must also create a new version of the patch file. Create a task for this in this issue.
    • Sometimes the patch is no longer necessary, because the bug that the patch is for has been fixed in the actual package. Read the commit message for the patch, or read the GitHub PR comments or the related GitHub issue comments to find out what the patch was for.
    • Ideally the patch files have a code comment in .patches/README.md explaining the conditions when the patch is no longer required.

npm dependencies

We use the npm-check-updates package to upgrade to new versions of npm packages, and have consistent versions across all packages in our mono-repository.

There are three configuration files:

  • .ncurc.patch.cjs: include packages in this array to prevent upgrading patch versions and higher.

  • .ncurc.minor.cjs: prevent upgrading to new minor versions and higher.

  • .ncurc.major.cjs: prevent upgrading to new major versions and higher.

  • Check the configuration files above, to see if some of the updates no longer need to be blocked. Ideally the entries in these files have a code comment explaining the conditions where the upgrade no longer needs to be prevented.

patch versions

We don't allow ~1.0.0 style dependencies, so patch versions will not be installed automatically (1.0.0 to 1.0.1). That's why it is important to frequently install patches yourself.

  • Run pnpm run update-patch to install new patch versions.
  • Run npm run test-update and see if the build/lint/test scripts are still OK.
  • Check if the logs contain any (new) warnings. You can compare the logs with GitHub Action logs for the main branch.
  • If a patch update is problematic, you can temporarily add the package to the "ignore updates" list in .ncurc.patch.js.

Not all package maintainers use semantic versioning, especially 0.x.x versions, and alpha and beta versions. Unfortunately they will be installed as part of update-patch, so update-patch isn't as safe as you might think. You might want to read change logs of patch upgrades below 1.0.0 to see if there are breaking API changes.

  • Check if any packages have upgrades like 0.1.2 ➝ 0.1.9, and pay extra attention to these packages.

Create a pull request at this stage already, since minor upgrades and major upgrades might take some effort. Patches sometimes contain security vulnerability fixes.

minor versions

We don't allow ^1.0.0 style dependencies (1.0.0 to 1.0.1)

  • ideally install pnpm run update-minor.
  • Run npm run test-update and see if the build/lint/test scripts are still OK
  • If a minor update is problematic, you can add the package to the "ignore updates" list in .ncurc.minor.js.

major versions

  • if there is time, install pnpm run update-major.
  • Run npm run test-update and see if the build/lint/test scripts are still OK
  • If a major update is problematic, you can add the package to the "ignore updates" list in .ncurc.major.js.

Make an issue for minor/major upgrades that require so much time we better schedule it in a sprint.

deprecations

Run pnpm install. If the log still contains deprecation warnings at this stage, check if they are direct dependencies. Are the dependencies mentioned in our own package.json files? Then it its probably worthwhile to investigate why the package is deprecated. A good information source is often the README on the page about the package on npmjs.com. They will likely mention the reason for deprecating the page (e.g: no time to install security patches, you are on your own!) and they might even suggest alternative packages.

GitHub Action

Dependabot pull requests are a great way to detect outdated dependencies in GitHub Actions.

  • Upgrade all GitHub Action dependencies

Node.js

Check the Node.js website to see what the long term support version is ("Node LTS")

  • Upgrade to the latest minor Node LTS version (long term support)
    • package.json
    • .nvmrc
    • .github/workflows/*: configure node-version or reference node-version-file: ".nvmrc"
  • Vercel: go to project Settings ➝ General ➝ Node.js version and select the new major version

pnpm

  • Upgrade to latest pnpm version
    • .github/workflows/*": upgrade pnpm version in GitHub Actions for pnpm
    • package.json under engines. "^version" is usually okay, an exact version dependency is undesirable for developer experience, unless everyone develops in Docker containers. You can install an exact version of pnpm in GitHub Action if you want to.

Vulnerabilities

  • Check the "Security" tab of this GitHub repository and consider the Vulnerabilities
  • Upgrade all vulnerable dependencies, or dismiss the alerts with a good reason.

Docker images

Currently this repo doesn't have a docker-compose.yml where image needs to be updated, or any Dockerfile where FROM needs to be updated.

Patch round 2023-12

  • Upgrade all npm dependencies
    • at least install pnpm run update-patch
    • ideally install pnpm run update-minor
    • if there is time, install pnpm run update-major
    • make an issue for minor/major upgrades that require so much time we better schedule it in a sprint
  • Upgrade all GitHub Action dependencies
    • Dependabot PRs are a great way to detect outdated dependencies in GitHub Actions
  • Upgrade to Node LTS version (long term support)
    • package.json
    • .github/workflows/* node-version
  • Upgrade to latest pnpm version
    • .github/workflows/*
    • package.json
  • Upgrade all vulnerable dependencies

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.