opensearch-project / dashboards-search-relevance Goto Github PK
View Code? Open in Web Editor NEWTools to help search relevance engineers and business users tune search results for their OpenSearch applications.
License: Apache License 2.0
Tools to help search relevance engineers and business users tune search results for their OpenSearch applications.
License: Apache License 2.0
As part of the discussion around implementing an organization-wide testing policy, I am visiting each repo to see what tests they currently perform. I am conducting this work on GitHub so that it is easy to reference.
Looking at the Dashboards Search Relevance repository, it appears there is
Repository | Unit Tests | Integration Tests | Backwards Compatibility Tests | Additional Tests | Link |
---|---|---|---|---|---|
Dashboards Search Relevance | Certificate or Origin, Changelog Verifier, Lint Checker | #152 |
I don't see any requirements for code coverage in the testing documentation. If there are any specific requirements could you respond to this issue to let me know?
If there are any tests I missed or anything you think all repositories in OpenSearch should have for testing please respond to this issue with details.
Add dashboards-search-relevance plugin to source code page: https://opensearch.org/source.html#
We are launching an experimental search results comparison UI and are looking for feedback on this feature so we can work with the community to make it better.
In the Results field of Search Relevance / Compare search results, the text wrapping is bizarre.
With the query {} on the sample_data_ecommerce index, the first result (with a certain window width) looks like this:
category:
["Men's
Clothing"]currency:
EURcustomer_first_name:
Eddiecustomer_full_name
:Edd
ie
Underwoodcustomer_gender:
MALEcustomer_id:
38customer_last_name:
Underwo
Three problems:
Result should be formatted like this:
category:
["Men's Clothing"]currency:
EURcustomer_first_name:
Eddiecustomer_full_name:
Eddie Underwoodcustomer_gender:
MALE
customer_id:
38customer_last_name:
Underwoodcustomer_phone:
day_of_week:
Mondayday_of_week_i:
0email:
[email protected]manufacturer:
Chrome 107.0.5304.87 on macOS 12.6 Intel
(I don't know why the colon after "category" is missing here -- I couldn't reproduce that.)
As part of our continued efforts to improve OpenSearch Dashboards, we are planning to upgrade the underlying Node.js version from v14 to v18. This change will enhance performance, add new features, and bolster security. However, such major version changes might also affect the compatibility of existing plugins. Here is more introduction: opensearch-project/OpenSearch-Dashboards#3601.
Therefore, we kindly request assistance in testing this plugin the compatibility of with this new version of Node.js. We've prepared a branch with the Node.js v18 upgrade, which you can find here:
https://github.com/AMoo-Miki/OpenSearch-Dashboards/tree/node-18-webpack-4
We appreciate your support and cooperation in ensuring a smooth transition to Node.js v18 for the entire OpenSearch Dashboards community.
We need to integrate something like https://github.com/opensearch-project/observability/blob/main/.github/workflows/dashboards-observability-test-and-build-workflow.yml for this project. It should go into https://github.com/opensearch-project/dashboards-search-relevance/.github/workflows/
Relevance engineers want to use different ranking techniques to deliver the best results for their users in search applications. This feature will allow users to see search results for a single user query using two different DSLs, including external rerankers, on the same OpenSearch Dashboard UI.
Highlight any research, proposals, requests or anecdotes that signal this is the right thing to build. Include links to GitHub Issues, Forums, Stack Overflow, Twitter, Etc
Summarize the core use cases and user problems and needs you are trying to solve. Describe the most important user needs, pain points and jobs as expressed by the user asks above. Template: When <a situation arises> , a <type of user> wants to <do something>, so they can <expected outcome>. (Example: When searching by postal code, a buyer wants to be required to enter a valid code so they don’t waste time searching for a clearly invalid postal code.)
Does this have a REST API? If so, please describe the API and any impact it may have to existing APIs. In a brief summary (not a spec), highlight what new REST APIs or changes to REST APIs are planned. as well as any other API, CLI or Configuration changes that are planned as part of this feature.
Describe if the feature has any security considerations or impact. What is the security model of the new APIs? Features should be integrated into the OpenSearch security suite and so if they are not, we should highlight the reasons here.
If this feature will require breaking changes to any APIs, ouline what those are and why they are needed. What is the path to minimizing impact? (example, add new API and deprecate the old one)
Describe the feature requirements and or user stories. You may include low-fidelity sketches, wireframes, APIs stubs, or other examples of how a user would use the feature via CLI, OpenSearch Dashboards, REST API, etc. Using a bulleted list or simple diagrams to outline features is okay. If this is net new functionality, call this out as well.
Will this change the existing user experience? Will this be a breaking change from a user flow or user experience perspective?
Describe the value that this feature will bring to the OpenSearch community, as well as what impact it has if it isn't built, or new risks if it is. Highlight opportunities for additional research.
Describe what it will take to build this feature. Are there any assumptions you may be making that could limit scope or add limitations? Are there performance, cost, or technical constraints that may impact the user experience? Does this feature depend on other feature work? What additional risks are there?
What are known enhancements to this feature? Any enhancements that may be out of scope but that we will want to track long term? List any other open questions that may need to be answered before proceeding with an implementation.
Need UX and product input to define what's attractive demo page
In order to maintain high standards on this project, I propose that we set the unit test coverage target to 80% because we are starting with 80% coverage now and a threshold of 2% (effectively making our target to fail a build at 78% coverage. CodeCov docs are here: https://docs.codecov.com/docs/github-3-customizing-codecov. I'll submit a PR that should close this issue.
None
Maintaining technical standards and setting a bar for builds.
No
No
Refactoring the dashboards-search-relevance
plugin can provide several benefits, making the application more maintainable, scalable, and efficient. The primary purposes for refactoring the plugin are:
Improve code readability and maintainability: Refactoring helps in simplifying complex code structures and making them more readable. This ensures that other contributers can easily understand and maintain the codebase in the long run.
Enhance performance and optimization: By refactoring, contributers can identify and eliminate bugs, optimize code, and improve the app's overall performance. This ensures a better user experience and faster loading times.
Increase reusability and modularity and facilitate easier testing: Breaking down large components into smaller, reusable components enhances the modularity of the application. This makes it easier to manage, test, and scale the application in the future. For example, this index.ts has several functions that cannot be easily unit tested until they are modulated.
Adhere to best practices and design patterns: Refactoring helps in aligning the codebase with industry best practices and widely accepted design patterns. This ensures consistency, reduces the chances of bugs, and makes the codebase easier to work with for other contributers .
Overall, refactoring the dashboards-search-relevance app aims to make the application more efficient, maintainable, and scalable, providing a better experience for both developers and users.
We want to make sure we have a way to easily identify issues that we haven't reviewed. By default new issues do get created with untriaged if created with a template, but this action should cover other use cases.
Add an action with the following...
name: Apply 'untriaged' label during issue lifecycle
on:
issues:
types: [opened, reopened, transferred]
jobs:
apply-label:
runs-on: ubuntu-latest
steps:
- uses: actions/github-script@v6
with:
script: |
github.rest.issues.addLabels({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
labels: ['untriaged']
})
Is your feature request related to a problem?
Following a problem in another plugin (opensearch-project/opensearch-build#2043), and coming from opensearch-project/opensearch-build#58, there's no automated testing that this plugin runs as part of the OpenSearch distribution.
What solution would you like?
Run integration tests as part of the distribution.
A bit different from the OpenSearch Gradle IntegTest, the cypress test on dashboards need to be added to https://github.com/opensearch-project/opensearch-dashboards-functional-test
When building a product or full-text search based application in OpenSearch, careful consideration and thought needs to be put into building the index based on the data being ingested. Often, a document to be indexed is derived from several different sources (e.g. databases, tables, or files). In OpenSearch, the best practice is to denormalize this data into a single document. This proposal is to build tooling that inspects source data and generates a suggested OpenSearch index mapping file so that search application builders do not need to start from scratch and also do not need to default to dynamic mapping.
Add a metrics framework on dashboards-search-relevance by instrumentation.
Will post the RFC/HLD.
A metrics framework can solve a number of problems related to monitoring and measuring the performance and behavior of dashboards-search-relevance plugin.
The new REST API /api/relevancy/stats
returns all metrics of the dashboards-search-relevance plugin. Metrics will be used to monitor existing APIs such as /api/relevancy/search/indexes
and /api/relevancy/search
. Any future APIs can be seamlessly added by calling metricsService.addMetric
. It will be configurable to setup the refresh time interval.
No security impact. All metrics are stored in memory. For metric persistence and visualization, OpenSearch or another monitoring framework can be used.
To support multiple requests, the /api/relevancy/search
URL has been changed to a batch API. This is a browser-side routing API.
Users are able to call /api/relevancy/stats
to view all metrics of the dashboards-search-relevance plugin.
No.
The reason to build is mentioned here
The reason to not build:
Limited benefits: dashboards-search-relevance is quite small and simple, there are no significant performance or reliability issues, the benefits of building a metrics framework may be limited
As of now, user behavior such as clicking is not covered. By exposing a new API endpoint, the same framework can be used.
No.
Example output:
% curl -XGET http://localhost:5603/hgn/api/relevancy/stats
{
"data": {
"relevant_search": {
"fetch_index": {
"200": {
"sum": 12.02572301030159,
"count": 1
}
},
"single_search": {
"200": {
"sum": 4.898337006568909,
"count": 1
}
}
}
},
"overall": {
"response_time_avg": 8.46203000843525,
"requests_per_second": 0.03333333333333333
},
"component_counts": {
"relevant_search": 2
},
"status_code_counts": {
"200": 2
}
}%
Title:
Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
qs vulnerable to Prototype Pollution
Description:
qs before 6.10.3, as used in Express before 4.17.3 and other products, allows attackers to cause a Node process hang for an Express application because an __ proto__ key can be used. In many typical Express use cases, an unauthenticated remote attacker can place the attack payload in the query string of the URL that is used to visit the application, such as a[proto]=b&a[proto]&a[length]=100000000. The fix was backported to qs 6.9.7, 6.8.3, 6.7.3, 6.6.1, 6.5.3, 6.4.1, 6.3.3, and 6.2.4 (and therefore Express 4.17.3, which has "deps: [email protected]" in its release description, is not vulnerable).
I believe that the comparison tool is stable and have no immediate plans to make changes to it. IMO, we should remove the experimental tag from the tool in an upcoming release.
We should try to minimize the amount of time anything is considered experimental.
None
No
No
I believe the "Experimental Feature" label should be removed, but the box it's in with the description, link to documentation, and forum should remain. https://searchapps.playground.opensearch.org/app/searchRelevance#/.
No
Experimental features are meant for features that are not ready for production due to potential API changes or performance concerns. This feature has neither of those concerns.
Follow opensearch-project/.github#125 to baseline MAINTAINERS, CODEOWNERS, and external collaborator permissions.
Close this issue when:
If this repo's permissions was already baselined, please confirm the above when closing this issue.
Coming from opensearch-project/opensearch-plugins#95, add Windows support.
Mingshi is a new contributor and will be working to help release this repo into 2.5.0 so she is being added as a maintainer. Congrats Mingshi!
Currently, the comparison tool only shows document source. Sometimes, though, I don't want to retrieve the whole document source because I have large text fields and vector fields. Also, sometimes I want to retrieve fields that are not available in source, but are available as doc values, stored fields, or are computed by a script.
The results shown in the comparison tool should include fields from the fields
property of each document. I would suggest that the result object first be populated with fields from the source (if available), then overlay the field values from the fields
property -- if a field is available in both source and fields
, the value in fields
should overwrite the value in source.
We can limit the set of fields returned using the _source
parameter in the search request, but that doesn't cover the cases where a field is not available in the source (but may be in doc values, a stored field, or be computed with script_fields
).
No
Yes. When editing a query, the DSL can get pretty verbose. The query box seems to be sized for about 8 lines of query text.
Following the JSON convention of putting one property on each line and closing curly braces on their own line, it's really hard to fit a non-trivial query on screen, meaning I need to scroll.
I would like the query boxes to be expandable vertically. I think we should add a handlebar to adjust the space allocated to queries versus results.
The following screenshot shows the problem. The query on the left is 9 lines, while the one on the right is 22 lines.
When a nightly build fails, a github action could open an issue for deeper investigation so we don't forget.
This action could handle that for us: https://github.com/jayqi/failed-build-issue-action
Add git action steps to run integration test
Changelogs for each release make it easier to cut the release.
This is a component issue for 2.6.0.
Coming from opensearch-build__3081__. Please follow the following checklist.
Please refer to the DATES in that post.
This issue captures the state of the OpenSearch release, on component/plugin level; its assignee is responsible for driving the release. Please contact them or @mention them on this issue for help.
Any release related work can be linked to this issue or added as comments to create visiblity into the release status.
There are several steps to the release process; these steps are completed as the whole component release and components that are behind present risk to the release. The component owner resolves the tasks in this issue and communicate with the overall release owner to make sure each component are moving along as expected.
Steps have completion dates for coordinating efforts between the components of a release; components can start as soon as they are ready far in advance of a future release. The most current set of dates is on the overall release issue linked at the top of this issue.
Linked at the top of this issue, the overall release issue captures the state of the entire OpenSearch release including references to this issue, the release owner which is the assignee is responsible for communicating the release status broadly. Please contact them or @mention them on that issue for help.
If including changes in this release, increment the version on __2.x__
branch to __2.6.0__
for Min/Core, and __2.6.0.0__
for components. Otherwise, keep the version number unchanged for both.
v2.6.0
.__2.6.0__
are complete.__2.6__
release branch in the distribution manifest.__2.6.0__
have been merged.Hi,
Update your plugin information in the documentation website:
https://github.com/opensearch-project/documentation-website
Example AsyncSearch:
https://opensearch.org/docs/latest/search-plugins/async/index/
Thanks.
Release Version 2.5.0
This is a component issue for 2.5.0.
Coming from opensearch-build#2908. Please follow the following checklist.
Please refer to the DATES / CAMPAIGNS in that post.
This issue captures the state of the OpenSearch release, on component/plugin level; its assignee is responsible for driving the release. Please contact them or @mention them on this issue for help.
Any release related work can be linked to this issue or added as comments to create visiblity into the release status.
There are several steps to the release process; these steps are completed as the whole component release and components that are behind present risk to the release. The component owner resolves the tasks in this issue and communicate with the overall release owner to make sure each component are moving along as expected.
Steps have completion dates for coordinating efforts between the components of a release; components can start as soon as they are ready far in advance of a future release. The most current set of dates is on the overall release issue linked at the top of this issue.
Linked at the top of this issue, the overall release issue captures the state of the entire OpenSearch release including references to this issue, the release owner which is the assignee is responsible for communicating the release status broadly. Please contact them or @mention them on that issue for help.
If including changes in this release, increment the version on 2.5
branch to 2.5.0
for Min/Core, and 2.5.0.0
for components. Otherwise, keep the version number unchanged for both.
v2.5.0
.2.5
branch2.5.0
are complete.2.5.0
release branch in the distribution manifest.2.5.0
have been merged.Release Version 2.4.0
This is a component issue for 2.4.0.
Coming from opensearch-build#2649. Please follow the following checklist.
Please refer to the DATES / CAMPAIGNS in that post.
This issue captures the state of the OpenSearch release, on component/plugin level; its assignee is responsible for driving the release. Please contact them or @mention them on this issue for help.
Any release related work can be linked to this issue or added as comments to create visiblity into the release status.
There are several steps to the release process; these steps are completed as the whole component release and components that are behind present risk to the release. The component owner resolves the tasks in this issue and communicate with the overall release owner to make sure each component are moving along as expected.
Steps have completion dates for coordinating efforts between the components of a release; components can start as soon as they are ready far in advance of a future release. The most current set of dates is on the overall release issue linked at the top of this issue.
Linked at the top of this issue, the overall release issue captures the state of the entire OpenSearch release including references to this issue, the release owner which is the assignee is responsible for communicating the release status broadly. Please contact them or @mention them on that issue for help.
If including changes in this release, increment the version on 2.0
branch to 2.4.0
for Min/Core, and 2.4.0.0
for components. Otherwise, keep the version number unchanged for both.
v2.4.0
. @macohen2.4
branch2.4.0
release branch in the distribution manifest.2.4.0
have been merged.Although config.ts is added at the top level of the plugin, it is not included in the construction artifact when using the command yarn plugin-helpers build
. The current github testing workflows always get the source code through checkout. (see examples https://github.com/opensearch-project/dashboards-search-relevance/blob/main/.github/workflows/remote-integ-tests-workflow.yml#L72-L75 and https://github.com/opensearch-project/dashboards-search-relevance/blob/main/.github/workflows/test-and-build.yml#L22-L25). We should instead utilize build artifacts for integration testing.
The existing maintainers have voted and approved adding Sean Li (sejli) and Louis Chu (noCharger) as maintainers on this repo. Can you please add them to the maintainers list, @opensearch-project/admin?
When creating a PR with "backport 2.x" or "backport 2.4" labels, the backport action succeeds, but the opensearch-trigger-bot sends e-mail that it failed with instructions:
The backport to 2.x failed:
The process '/usr/bin/git' failed with exit code 128
To backport manually, run these commands in your terminal:
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-2.x 2.x
# Navigate to the new working tree
cd .worktrees/backport-2.x
# Create a new branch
git switch --create backport/backport-30-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 61a7232068b72469263a2391b741bf86af5ed0ca
# Push it to GitHub
git push --set-upstream origin backport/backport-30-to-2.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-2.x
Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-30-to-2.x.
Label a PR "backport 2.x", merge it to main.
Expected that the merge would be successful.
N/A
N/A
This is the first time we're running backport so there may be an issue with how we're using it.
We have informally said that coverage should not drop below 80%. We also have this .codecov.yml file which may not be working right: https://github.com/opensearch-project/dashboards-search-relevance/blob/main/.github/.codecov.yml.
We should also document our expectations for coverage in the readme.
Originally posted by @macohen in #152 (comment)
Current comparison tool only display text document, which is not very intuitive comparing search results. We propose to display pictures when a url is available.
We could use greasemonkey script on client side to do the job, but it's not as easy.
Add any other context or screenshots about the feature request here.
[### What is the bug?]
Title:
Inefficient Regular Expression Complexity
Inefficient Regular Expression Complexity in chalk/ansi-regex
Description:
ansi-regex is vulnerable to Inefficient Regular Expression Complexity
ansi-regex is vulnerable to Inefficient Regular Expression Complexity which could lead to a denial of service.
(https://advisories.aws.barahmand.com/advisory/CVE-2021-3807)[
Default tab spacing in the Query text box is 4 spaces. In dev tools, it is 2 spaces, which makes the query more compact and easier to see.
From the top-left hamburger menu go to “OpenSearch Plugins -> Search Relevance”. Enter a query in Query 1 or Query 2 text box.
Expect the same tab spacing as dev tools.
Any
Add any other context about the problem.
We should add pagination and the ability to show how many results are on the page and how many results are returned by the query in the comparison UI
#55 is where this was suggested.
The 2.x branch and 2.6 branches are diverged.
The most updated commit on 2.x after 1eb4994 is 98d9b8d. But on 2.6 it's 7b992b1
Not applicable.
All commits to minor branch should go to 2.x first.
Not applicable.
Not applicable.
There are two potential ways to fix it
Note: both approachs will create new commit ids since it's backporting after branch cut. Example noCharger@14c05dc
In Compare search results, "See some examples" gives an error when it shouldn't and doesn't show the Examples slide-out.
In the Compare search results page, click in the Query box (but don't enter any text), then click on "See some examples".
It gives the error "A query is required. Enter a query." and does not show the Examples slide-out.
Clicking on "See some examples" then does display the Examples slide-out.
It should not give an error, and it should show the slide-out.
Chrome 107.0.5304.87 on macOS 12.6 Intel
Not needed.
Any content in the Query field, even a single space or an invalid query, keeps this bug from happening.
The backport delete action does not work because the action defined the label pattern to search for as "backport/" when we use "backport-"
During the 2.6.0 release, the Cypress tests for this repo (running from https://github.com/opensearch-project/opensearch-dashboards-functional-test/blob/main/cypress/integration/plugins/search-relevance-dashboards/1_query_compare.spec.js) failed because it was unable to create sample data (in the before()
step), because the sample data had been created but not cleaned up by another test.
We should defend against other tests' bad behavior so that our tests don't break.
I think https://github.com/opensearch-project/opensearch-dashboards-functional-test/blob/main/cypress/integration/plugins/custom-import-map-dashboards/import_vector_map_tab.spec.js#L14-L15 may be a model that we can copy -- delete all indices before trying to add sample data to start with a clean slate.
This is a component issue for 2.7.0.
Coming from opensearch-build#3230. Please follow the following checklist.
Please refer to the DATES in that post.
This issue captures the state of the OpenSearch release, on component/plugin level; its assignee is responsible for driving the release. Please contact them or @mention them on this issue for help.
Any release related work can be linked to this issue or added as comments to create visiblity into the release status.
There are several steps to the release process; these steps are completed as the whole component release and components that are behind present risk to the release. The component owner resolves the tasks in this issue and communicate with the overall release owner to make sure each component are moving along as expected.
Steps have completion dates for coordinating efforts between the components of a release; components can start as soon as they are ready far in advance of a future release. The most current set of dates is on the overall release issue linked at the top of this issue.
Linked at the top of this issue, the overall release issue captures the state of the entire OpenSearch release including references to this issue, the release owner which is the assignee is responsible for communicating the release status broadly. Please contact them or @mention them on that issue for help.
If including changes in this release, increment the version on __2.x__
branch to __2.7.0__
for Min/Core, and __2.7.0.0__
for components. Otherwise, keep the version number unchanged for both.
v2.7.0
.2.7.0
are complete.2.7
release branch in the distribution manifest.2.7.0
have been merged.Title:
glob-parent before 6.0.1 and 5.1.2 vulnerable to Regular Expression Denial of Service (ReDoS)
Inefficient Regular Expression Complexity
glob-parent 6.0.0 vulnerable to Regular Expression Denial of Service
Description:
glob-parent before 6.0.1 and 5.1.2 is vulnerable to Regular Expression Denial of Service (ReDoS). This issue is fixed in version 6.0.1 and 5.1.2.
The glob-parent package before 6.0.1 for Node.js allows ReDoS (regular expression denial of service) attacks against the enclosure regular expression.
glob-parent 6.0.0 is vulnerable to Regular Expression Denial of Service (ReDoS). This issue is fixed in version 6.0.1.
This vulnerability is separate from GHSA-ww39-953v-wcq6.
https://advisories.aws.barahmand.com/advisory/CVE-2021-35065
We are building QA summary based search using search pipeline. We want to use the search comparison tool to show the difference between that and normal searches. Can we add support to QA search into the comparison tool?
Basically we need to highlight the summarized answer and display the list of documents that used to summarize the answer. See attachment for details.
(to be updated)
This could also be done via client side script but not as convenient.
Add any other context or screenshots about the feature request here.
Yes. Results are limited to four lines of text governed by the width of the browser window. Many real-world documents are much larger than that.
I would like some way of viewing the full source of a document (or at least the full set of returned fields and their values).
I think any expansion should involve a small UI element (e.g. a rotating arrow or an "expand" icon), to preserve the existing "compact" feel. I would like to be able to expand individual results (rather than needing to expand all results).
Add any other context or screenshots about the feature request here.
TODO
Relevancy Workbench is an OpenSearch Dashboards plugin that comprises of different components: Query Explorer, Rules Manager and Search Analytics. These components allow search relevancy engineers to make their query results more accurate, contextual and relevant.
Search Relevance Engineers who want to create a good search experience for their end-users, by providing them with relevant search results. Also, they want to dive deeper into search analytics like top search queries, top clicks and top queries without result.
OpenSearch search relevance engineers create and test different DSL queries and Querqy queries for their search app. Query Explorer enables these developers to test these queries and rules.
Rules Manager allows search relevance engineers to manage querqy rules.
Search Analytics allows search relevance engineers to view summaries of interactions (clicks, search queries, etc) on different search apps.
Support automate version bump in https://github.com/opensearch-project/opensearch-build
When the search button is pressed and a single search is performed, an error message appears saying "An index is required. Select an index."
Three possibilities:
I would want to clarify the expected behavior.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.