worldbrain / worldbrain-engineering Goto Github PK
View Code? Open in Web Editor NEWThis repository hosts the website documenting all our engineering pratices.
This repository hosts the website documenting all our engineering pratices.
I'm working to document where we want to be moving to with the Storybook library, how we use styled-components, how we want to move towards consistency with icons, colours, type.
We will have the details of the designs inside the documentation of story book but this documentation here will outline our plan, packages, processes and current state.
Currently the documentation addon to Storybook breaks with our setup (typescript thing probably).
It seems we never merged this PR:
WorldBrain/Memex#786
In it, I've documented some basics top facilitate good coding practices, including writing understandable and maintainable code, TDD tips and principles. Let's take what's there and organize it in a nice way.
browser.storage.local
Web Ext API and localStorage
Web API
Two years ago, we agreed to rebase feature branches on develop
before merging. There are advantages and disadvantages to both this approach, and merging develop
into feature branches before merging. Let's collect those, reach a clear agreement on why we do what, and document that.
We're using several tools to communicate from ideation of a task to the final implementation: Slack/Zoom, Notion and GitHub. Let's make this more explicit, so we can more easily discover ways to streamline the process and communicate it to contributors/followers.
One thing to still flesh out is the technical preparation of a task starts in a GitHub issue, and then when providing feedback on the implementation, the communication moves to a PR. Where to make this move from issue to PR is not always clear.
Analytics work is nearly done: WorldBrain/Memex#976
There will be lots of times in the future where we want to ensure some new (or existing) event is tracked.
Currently the analytics class instance can just be imported directly and used as-is. This is mainly to make things simple for really old parts of the codebase that still are yet to be set up nicely so that we can pass down dependencies like this - to post-pone the refactoring that will be needed.
To discourage any new uses like this it'd be nice to get some guidelines and examples on the recommended way to track an event from different parts of the codebase.
We discussed this on slack a few years back then resulted in adding the guidelines to go with kebab-case for all files.
https://github.com/WorldBrain/Memex/blob/3b9bfec6a4c2a316cfcf3549c8808f50fc7d245f/GETTING-STARTED.md#L183-L194
We could also keep CamelCase naming for modules that export a react comp, but perhaps it's simpler having a rule consistent across all types of modules. Doesn't really matter as long as we're all onboard.
We have the problem, both in the codebase and in our heads, that we have multiple names for different features or parts of the ext+app. Maybe it would be cool to have a little glossary with the terms we want to stick with and try to make any new changes adhere to that.
Some examples:
A few years back we adopted the Gitflow branching model, and since then we've discussed and added further rules to our branching model such as updating minor or patch version, depending on branch type (hotfix vs release), and having certain CI checks autorun for certain branches.
There still seems to be a fair amount of confusion about how we do things with git, and I've discovered recently we often do things like build releases before CI checks pass and fork hotfix branches from develop
. I feel these violations come from uncertainty about the whole process and differences in understanding among the team.
Having some simple instructions that are easy to follow and difficult to mess-up should help us avoid making these mistakes. We already have the CD pipeline instructions doc for the Memex Go repo, which is essentially a description of how the branching model works there:
https://www.notion.so/worldbrain/CD-Pipeline-instructions-2050caf8823948f6beb296129224f27a
I find these easy to follow, but that's probably because I wrote them. It would be good to expand on these for the Memex ext repo and get feedback from others on their ease-of-instruction and iterate
The "automated" CD pipeline still requires a minimal amount of manual steps that can be easily messed up, hence why we have an instructions doc:
https://www.notion.so/worldbrain/CD-Pipeline-instructions-2050caf8823948f6beb296129224f27a
Things we don't directly want to compile into code, or should be configurable at build time, are passed in as environment variables. This is handled in build/env.js
and there's a plugin which gets variables from the root .env
file.
To document:
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.