Giter Club home page Giter Club logo

go-template's Introduction

go-template

A gif displaying go-template in action

Build status No Dependencies MIT License Pre-Commit Enabled Go v1.19+ Makefile Included

A bleeding-edge Go project generator for your next project ๐Ÿ˜‰

TL;DR

cookiecutter gh:notsatan/go-template

OR

cookiecutter https://github.com/notsatan/go-template

And you're good to go! Jump to the setup section directly for quick setup instructions ;)

๐Ÿ’ฅ Features

This is a batteries-included cookiecutter ๐Ÿช template to get you started with the essentials you'll need for your next Go project ;)

Development

  • Supports Go v1.19, v1.20 and v1.21
  • Automated code formatting with gofmt and gofumpt
  • Sort imports with goimports and gci
  • Ready to use pre-commit setup, complete with a ton of hooks already configured in .pre-commit-config.yaml
  • Security checks with gosec, code duplication checks with dupl, magic number checks with go-mnd
  • Configured .editorconfig, .dockerignore and .gitignore - you won't have to bother with trivialities
  • Enforce good programming practices with go-critic, gocyclo, gocognit and stylecheck
  • Code linting with golangci-lint, complete with a ready-to-run .golangci.yml configuration file
  • Easy setup with Makefile - run linters, check for codestyle, run tests and generate coverage reports - all with a single command
  • Multiple test modes supported by the Makefile - allowing you run tests as frequently as you need, without having to run long tests (>20 sec) everytime (ugh).

Deployment

  • Github Actions with predefined workflows including CI/CD, release drafter and optional code coverage with Codecov
  • All Github actions can be run manually if needed
  • A simple Dockerfile with multi-stage build to containerize your apps while ensuring smallest possible image sizes
  • Always up-to-date dependencies with @Dependabot - enabled by default, remove dependabot.yml to disable!
  • A simple shell script to generate compiled binaries for multiple OS/architectures with checksums for verification
  • Automated release management with Release Drafter, pre-configured to handle the default Github labels (and more) through release-drafter.yml

Community

  • Ready to use pull request and issue templates out of the box
  • Files such as LICENSE, CONTRIBUTING.md, CODE_OF_CONDUCT.md, and SECURITY.md will be generated automatically.
  • Semantic Versions specifications with Release Drafter
  • Fork friendly - projects generated through go-template use relative links. Forks link to themselves instead of your project -- even for soft forks, ensuring there are no confused users!

๐Ÿ”ฌ Setup Instructions

Installation

To start using the template, install the latest version of Cookiecutter (make sure you have Python and pip installed)

pip install -U cookiecutter

Once you have cookiecutter installed, move over to the directory where you want to generate your project and run
cookiecutter gh:notsatan/go-template

Alternatively, you can achieve the same results with the command

cookiecutter https://github.com/notsatan/go-template/

Input Variables

Cookiecutter will ask you to fill some variables that will be used to generate your project from this template. This section lists all the input variables, their default values, and what they are used for

Quick Note: Cookiecutter needs all inputs to have a default value. Many of the defaults for the setup resort to this repository (for example, the module path points to this Github repository, license owner name refers to me, etc)

These defaults must be filled with actual values during the setup!


Parameter Default Value Usage
project_name example-project Name of the project. A directory of this name will be created in the current working directory
project_description Based on project_name A small description of the project, used to generate GNU license file, and default readme
go_module_path Based on project_name Complete Go module path for the generated project, use a valid Github URL to enable Github specific features
license_owner example Used in LICENSE and other files. Can be the name of a person or an organization.
base_branch master The stable/base branch. Used for build status badges and release-drafter (if you enable Github specific features)
contact_email "" Email to get in touch with project stakeholders. CODE_OF_CONDUCT.md and SECURITY.md will be removed if empty. Why is this needed?
github_specific_features y Yes or No (y or n). Dictates if Github-specific features should be included in the project (issue templates, pipeline, etc). More Info
private_project n Yes or No (y or n). Inquires if the project repository generated will be publicly accessible, or private. Why is this needed?
use_codecov y Yes or No (y or n). Decides if Codecov is to be used in the project or not. Checkout Setting up codecov
use_precommit y Yes or No (y or n). Decides if pre-commit configs should be included with the generated templates
go_version 1.17 The version of Go to use in the project. Can be either 1.16, 1.17 or 1.18
license MIT The license you want to use in the generated project. One of MIT, BSD-3, GNU GPL v3.0 and Apache Software License 2.0

All values entered while setting up the Cookiecutter template will be saved in cookiecutter-config-file.yml, you can refer to them in the generated project ๐Ÿ˜‰

Important: Go through this section if you're creating a project that will be owned by a Github organization

Post Installation

When Cookiecutter completes generating your project, move into the project directory. Let the Makefile install and setup the resources needed for the project to run locally, use

make local-setup

Once the Makefile command is done with the setup, be sure to install GolangCI-Lint (this won't be handled by the Makefile command). GolangCI is used to run a bunch of linters on your code, when integrated with the pre-commit config file, this would ensure multiple linters are automatically run on your codebase with every commit - and optionally every push to the remote if you have enabled the linter action

Head over to the GolangCI-Lint website for installation instructions. And that's it. You should have your own project up and running by now :)

๐ŸŽฏ What's Next

Start playing around with the generated template :')

If you're a beginner with Go, I would like to recommend some articles, blogs and other resources that helped me learn Go - these will (hopefully) be of some help to you

  • Go Official Docs: For Go, the official documentation is an excellent place to start learning. Highly recommened resource for beginners.
  • Effective Go: A blog post that is a part of the official documentation, yet important enough to be a separate point by itself! Gives you an in-depth idea of how to structure and write your Go code. Recommended read once you've learnt the basics of Go
  • Uber's Style Guide for Go: Slightly opionated at times, a great resource nevertheless. Gives a very detailed look at what "bad" Go code is, and how to rewrite it to be simpler and more effective. Recommended read for people with some experince in using Go (less so for people with no experience)
  • Go Code Review Comments: A part of the Go Wiki, can be seen as a supplement to Effective Go (mentioned above)
  • 50 Shades of Go: A collection of common traps and gotcha's for Go devs! Recommended read once you start writing code in Go, not recommended for complete newbies - can potentially drown you with excess information

General

Articles and resources which were of great help to me when making this template

โ‰๏ธ FAQ

Why is my Email ID needed?

Like all other fields, the contact_email field is also optional. You can choose to leave this value blank, and the template will work normally.

The email field is used to generate CODE_OF_CONDUCT.md and SECURITY.md โ€” both of which require people to get in touch with project stakeholders directly, either to report a violation, or a bug!

Note: If you choose to leave the email field blank, neither SECURITY.md nor CODE_OF_CONDUCT.md will be generated by the template! Since both of these files require people to get in touch directly, not having an email ID makes these files be redundant. If you still want these files, you can manually add them to the generated project!

What does the github_specific_features field do?

Not every project generated using this template needs to be hosted on Github. There are many other Git hosting-providers out there, each of them as valid as Github.

At the same time, Github happens to be the most popular code hosting platform - as such, projects generated by go-template include a lot of features that would ensure a very smooth development experience on Github, but would be redundant anywhere outside Github. Some examples of this would be Github pipelines, Github actions, issue templates, pull request templates, and more.

In case you do not plan to use Github as a code-hosting platform for your project, you can use this field to ensure the generated project is free of Github-specific files/code.

Note: If Github specific features are required, the value of go_module_path should be a path to a Github repository (does not matter if it exists). This would be used for dependabot.yml

Why do I need to inform if the generated project will be public?

As of now, the only change(s) being made based on this are all restricted to the README file of generated projects. This is required as some badges used in the README require the project to be accessible by shields.io โ€” the service behind these badges!

For private projects, these badges will either be removed or modified, to prevent cases where badges break down for private repositories!

How to integrate Codecov for automated code analysis?

Codecov is a code analysis tool, go-template can generate a project with pre-configured support for Codecov code analysis. With Codecov enabled, the CI pipeline will generate a code coverage report everytime tests are run.

Note: The process listed here depends on Github workflows, as such, if you choose not to use Github features (through the github_specific_features field), or to not use Codecov (through the use_codecov field) - you'll have to figure this bit yourself!

Follow Codecov Docs to activate Codecov for your project repository.

Once you've activated Codecov for your project, you should be able to see the Repository Upload Token. Copy this token, and add it as a secret to your Github repository.

The name of the secret should be "CODECOV_TOKEN" (no spaces, copy-paste the string as it is). The value of the secret would be the Repository Upload Token obtained from Codecov.

Save this secret and you're done with setting up Codecov, code coverage reports should be available with the next run of the CI pipeline.

How to fix ValueError: Attempt to enable Github-specific features when module path does not belong to github?

This error would be thrown when you chose to enable Github specific features, but, the Go module path you used does not match against Github. Currently, go-template uses the following regex expression to validate module paths

^github.com\/[a-zA-Z0-9\-]+\/[a-zA-Z0-9\-]+\/?$

This check is needed is to ensure the dependabot.yml config will add the repository owner as a reviewer whenever dependabot raises a pull request for a dependency update.

How do I configure dependabot for Github organizations?

By default, if you choose to enable Github features, the dependabot.yml config file will use the Go module path to figure out the owner of the repostiory, and assign any pull request raised to the repository owner

In simpler terms, if the Go module path is

github.com/notsatan/go-template

Any pull request raised by dependabot will assign notsatan (me) as the reviewer.

While this works well for normal users, at the same time, for organizations, dependabot will try to assign pull requests to the entire organization!

To fix this, once the project is generated, simply edit the dependabot.yml file and modify the values under reviewers and assignees.

โœ”๏ธ TODOs

Stuff that's in the plan - contributions are welcome! Please raise an issue before you start working (especially if you're picking up one of these tasks);

  • Integrating goreleaser - Automated releases sure sounds cool!
  • Minor improvements to .golangci.yml - The generated file should be enough to give users (developers) a rough idea of configs.
  • Possible integration with mkdocs-material for projects that need a documentation. Should definitely be optional though!
  • Add Earthly? Not sure if this is needed in the first place.
  • Customize build-script.sh to generate binaries/executables for selective OSes
  • Option to generate private projects - Shield badges and need the project to be public. It would be great to have an option to generate private projects using go-template! (Accomplished via #52)

๐Ÿ† Acknowledgements

The main inspiration behind this template was TezRomacH's python-package-template โ€” which I've greatly enjoyed using at one point of time.

The lack of any similar templates for Go was a large part of why I decided to Go ahead and make one myself. And of course, huge appreciation for Cookiecutter, without which such a flexible template would not be possible.

๐Ÿฅˆ Similar Projects

Other similar project(s) that you might want to check out;

P.S. If you know of any project similar to go-template (that isn't listed here), let me know and I'll be happy to list it ;)

Forks of go-template are welcome as well - given they have significant changes compared to upstream!

P.P.S. The emoji for this section fits well :p

๐Ÿ›ก๏ธ License

MIT License

This project is licensed under the terms of the MIT license. See LICENSE for more details.

go-template's People

Contributors

domdom82 avatar leviable avatar notsatan 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

Watchers

 avatar  avatar  avatar

Forkers

jgarte domdom82

go-template's Issues

Suggestion: use `main` for base_branch

Gentle suggestion to use main for default base_branch instead of master.

Avoiding the broader debate about the reasons for and utility of the name change, the industry is trending in the direction of using main as the default base branch, and is arguably beyond the critical mass of adoption necessary. The major players in the space (GitHub, Gitlab) and associated tooling have already or will soon be switching to main, and as a related tool go-template might be best served by adopting that change now.

Ran into exception while running validator: `is_module_hosted_on_github`

Hi!

Thanks for your repo!
The first time I try it failed. Don't know why

โ•ฐโ”€$ cookiecutter gh:notsatan/go-template
You've downloaded /Users/mac/.cookiecutters/go-template before. Is it okay to delete and re-download it? [y/n] (y):
  [1/12] project_name (example-project): sqlite_saver_go
  [2/12] project_description (SqliteSaverGo is a Go application created using https://github.com/notsatan/go-template):
  [3/12] go_module_path (github.com/example/sqlite_saver_go): github.com/HaveF/sqlite_saver_go
  [4/12] license_owner (example): havef
  [5/12] base_branch (master): main
  [6/12] contact_email ():
  [7/12] github_specific_features (y):
  [8/12] private_project (n): y
  [9/12] use_codecov (y):
  [10/12] use_precommit (y):
  [11/12] Select go_version
    1 - 1.21
    2 - 1.20
    3 - 1.19
    Choose from [1/2/3] (1):
  [12/12] Select license
    1 - MIT
    2 - BSD-3
    3 - GNU GPL v3.0
    4 - Apache Software License 2.0
    Choose from [1/2/3/4] (1):


Ran into exception while running validator: `is_module_hosted_on_github`
Stacktrace: `ValueError: Attempt to enable Github-specific features when module path does not belong to github`


go-template is still under development, if you feel that the error is incorrect, you are encouraged to raise an issue at:
	https://github.com/notsatan/go-template

ERROR: Stopping generation because pre_gen_project hook script didn't exit successfully
Hook script failed (exit status: 246)

I also checked the issues, but without luck.

Thanks for your help again!

Feature: Add support for Fuzzing in Makefile

Go 1.18 introduced Fuzzing as a method of testing

While there is nothing in the generated template that would interfere with Fuzzing, it would be nice to have an explicit Make flag to run fuzz tests. Can also trigger both normal and fuzz tests within the test-suite flag

This change would also require some minor documentation changes for the fuzz flag

Warning messages from `golangci-lint` for abandoned/deprecated linters

Running linters on a project generated with go-template results in the multiple warning messages;

WARN [runner] The linter 'deadcode' is deprecated (since v1.49.0) due to: The owner seems to have abandoned the linter. Replaced by unused. 
WARN [runner] The linter 'varcheck' is deprecated (since v1.49.0) due to: The owner seems to have abandoned the linter. Replaced by unused. 
WARN [runner] The linter 'ifshort' is deprecated (since v1.48.0) due to: The repository of the linter has been deprecated by the owner.  
WARN [runner] The linter 'structcheck' is deprecated (since v1.49.0) due to: The owner seems to have abandoned the linter. Replaced by unused. 
WARN [linters_context] structcheck is disabled because of generics. You can track the evolution of the generics support by following the https://github.com/golangci/golangci-lint/issues/2649.

Apparently, a handful linters have been abandoned/deprecated in sometime. The .golangci.yml generated needs to be modified to deal with these messages

Note that none of these are error messages, or will fail the linter/pipeline. Just some annoyances that need to be addressed

Docker: Improve build efficiency

The current Dockerfile does not use layers from previous builds efficiently.

For example, since the step to copy project files i.e. COPY . . comes before installing dependencies, any changes to code would change the hash for the layer. And the next layer would go on to reinstall dependencies since the hash for the previous layer has been modified!

A non-exhaustive list of improvements that can be made to the Dockerfile;

  • Dependencies should be (re)installed only if go.mod or go.sum files are modified!
  • Switch to using go mod download instead of go get/install
  • Remove RUN commands to create work directories - docker will create directories implicitly

Good to have;

  • Reduce number of build steps

Docker builds should be able to detect build modes

With #27, the Makefile allows creating two types of docker images;

  • Images in debug mode use golang as the base image for the final build - meaning that debug builds have go installed in them, and can be shell-ed into. This comes at the cost of relatively large build sizes
  • Images in production mode use scratch as the final base image - resulting in extremely small build sizes, at the cost of an almost empty container that won't be helpful for debugging!

Currently, there is no way for applications to "detect" if they are being run in debug mode or production mode!

Implementing a way to detect this would lead to nifty use-cases such as applications switching their logger to debug level when the application is being run in the debug container and more

jinja2.exceptions.TemplateSyntaxError: expected token 'end of statement block', got '+'

vitex@NAX008380:~/Projects/Custom/Packaging$ cookiecutter gh:notsatan/go-template
project_name [go-template]: KbHostnames2Networks
project_description [Kbhostnames2Networks is a Go application created using https://github.com/notsatan/go-template]:
go_module_path [github.com/notsatan/go-template]: git.xx.cz/users/xxxx/repos/hostnames2networks
license_owner [notsatan]: XX a.s.
base_branch [master]:
contact_email []: [email protected]
github_specific_features [y]: n
use_codecov [y]: n
use_precommit [y]: n
Select go_version:
1 - 1.17
2 - 1.16
3 - 1.18
Choose from 1, 2, 3 [1]: 2
Select license:
1 - MIT
2 - BSD-3
3 - GNU GPL v3.0
4 - Apache Software License 2.0
Choose from 1, 2, 3, 4 [1]: 1
Traceback (most recent call last):
  File "/home/vitex/.local/bin/cookiecutter", line 8, in <module>
    sys.exit(main())
  File "/usr/lib/python3/dist-packages/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/home/vitex/.local/lib/python3.8/site-packages/cookiecutter/cli.py", line 140, in main
    cookiecutter(
  File "/home/vitex/.local/lib/python3.8/site-packages/cookiecutter/main.py", line 101, in cookiecutter
    result = generate_files(
  File "/home/vitex/.local/lib/python3.8/site-packages/cookiecutter/generate.py", line 352, in generate_files
    generate_file(
  File "/home/vitex/.local/lib/python3.8/site-packages/cookiecutter/generate.py", line 169, in generate_file
    tmpl = env.get_template(infile_fwd_slashes)
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 830, in get_template
    return self._load_template(name, self.make_globals(globals))
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 804, in _load_template
    template = self.loader.load(self, name, globals)
  File "/usr/lib/python3/dist-packages/jinja2/loaders.py", line 125, in load
    code = environment.compile(source, name, filename)
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 591, in compile
    self.handle_exception(exc_info, source_hint=source_hint)
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 780, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/lib/python3/dist-packages/jinja2/_compat.py", line 37, in reraise
    raise value.with_traceback(tb)
  File "./Makefile", line 47, in <module>
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 497, in _parse
    return Parser(self, source, name, encode_filename(filename)).parse()
  File "/usr/lib/python3/dist-packages/jinja2/parser.py", line 901, in parse
    result = nodes.Template(self.subparse(), lineno=1)
  File "/usr/lib/python3/dist-packages/jinja2/parser.py", line 888, in subparse
    self.stream.expect('block_end')
  File "/usr/lib/python3/dist-packages/jinja2/lexer.py", line 386, in expect
    raise TemplateSyntaxError("expected token %r, got %r" %
jinja2.exceptions.TemplateSyntaxError: expected token 'end of statement block', got '+'
  File "./Makefile", line 47
    {%- endif +%}

Dump stderr logs in project `tmp` directory

Projects generated using go-template dump stderr messages in a text file in the /tmp directory. The reasoning behind this was that stderr output distracts users when everything is working, and with this setup, if there's a crash users can head over to the file in the /tmp directory to take a look at the logs.

STDERR=/tmp/$(PROJECTNAME)-stderr.txt

But, there can be several scenarios where running Makefile commands might result in messages being printed to stderr โ€” even if there are no failures โ€” for example, warning messages. In such cases, users might not even be aware of the warning messages unless they keep checking the log file in /tmp (which is something that I doubt most people do).

Projects generated using go-template allow for a local tmp directory inside the project directory.

# Ignore directories containing binaries generated and other stuff
tmp/**

Though, at the moment, this tmp directory is not being automatically created through the post-gen hook (maybe this needs to change as well).

This issue simply suggests altering the existing behaviour to dump stderr logs generated by Makefile commands in the project local tmp directory instead of the global /tmp directory.

Release drafter does not draft new releases

For a new project generated using go-template, release-drafter does not work out-of-the-box as expected. When a new pull request is merged, release-drafter runs as an action, but fails to update the draft release with information related to the merged pull request.

This bug might be related to the fact that a specific version of release-drafter is pinned in workflow currently

jobs:
release-drafter:
runs-on: ubuntu-latest
steps:
# Drafts release notes as Pull Requests are merged into "master"
- uses: release-drafter/[email protected]
env:
{%- raw %}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
{%- endraw %}

Feature: Add support for Go versions beyond 1.18

The Cookiecutter template generated allows choosing versions between 1.16, 1.17 and 1.18

The template needs to be updated to support the later versions of Go that have released since. Ideally, this should be as simple as modifying the user choices, provided the naming used to generate docker templates, etc holds up. Needs some minor testing before this can be confirmed

Bad example command in docker/README.md

The README.md file generated in the docker/ directory specifies a command that is incompatible with the generated Dockerfile. Specifically:

image

Since the final image created by the Dockerfile is a scratch image, there is no shell to attach to:

$ docker run -it --rm -v $(pwd):/workspace go-template-test bash
docker: Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "bash": executable file not found in $PATH: unknown.

The suggested command should probably be something like this:

$ docker run --rm go-template-test
Running project: go-template-test

It might also be worthwhile to add support to the Makefile for generating a "production" image that is based on scratch, and a "development" or "debug" image that is based on an alpine or bash image. For instance:
make docker-gen DEBUG=true

src directory not idiomatic Go?

Hi,

first of all, I really like your project. I've been searching for a ready-to-use template for go projects for some time and so far have only found cookiecutter-golang but I like yours more.

However, I am a bit puzzled by the generated src folder inside the generated project. That seems to me non-idiomatic go as described here

In my case I would probably delete the src folder after the project has been created.

Can you explain your reasoning behind using such a folder? I'm just trying to understand why you think it's needed.

GCI deprecated `local-prefixes` in YML configs

The YML for GCI linter no longer supports the local-prefixes field as mentioned in the updated linter-settings for GCI. Attempting to use the field results in a warning;

WARN [linters context] gci: `local-prefixes` is deprecated, use `sections` and `prefix(github.com/notsatan/go-template)` instead. 

Docker: Debug-friendly docker images

... Add support to the Makefile for generating a "production" image that is based on scratch, and a "development" or "debug" image that is based on an alpine or bash image. For instance:

make docker-gen DEBUG=true

Originally suggested by @leviable in #23

Allow running workflow(s) manually

As of now, projects generated using go-template will have workflows that are designed to run automatically on certain triggers (pushes/merges, etc). At the same time, Github also allows specifying a dispatch trigger that can be used to manually trigger a pipeline from the UI โ€” meaning, no need to push empty/pseudo-empty commits just to trigger a pipeline!

Allows users to manually triggering pipeline would be a powerful feature, and allows for a lot of possibilities.

Ran into exception while running validator: `is_module_hosted_on_github`

Ran into exception while running validator: is_module_hosted_on_github
Stacktrace: ValueError: Attempt to enable Github-specific features when module path does not belong to github

go-template is still under development, if you feel that the error is incorrect, you are encouraged to raise an issue at:
https://github.com/notsatan/go-template

ERROR: Stopping generation because pre_gen_project hook script didn't exit successfully
Hook script failed (exit status: 246)

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.