importing upstream

This commit is contained in:
Charles N Wyble - admin 2021-05-16 15:01:19 -05:00
parent d372224ed6
commit dddf50bc09
3 changed files with 0 additions and 158 deletions

View File

@ -1,47 +0,0 @@
---
title: Setting up PostHog EE
sidebar: Handbook
showTitle: true
---
Rough instructions on how to "get the EE version running in all its glory".
Currently for internal use only.
### Getting it up and running
`docker-compose -f ee/docker-compose.ch.yml up`
### Fixing broken frontend build
`docker run ee_web yarn build`
### Running Python + Webpack locally
- Run all the services
- Stop local kafka, clickhouse and zookeeper instances if you have them
- Same for redis, though it doesn't really matter much
- `docker-compose -f ee/docker-compose.ch.yml up db redis zookeeper kafka clickhouse`
- Add to `/etc/hosts`:
- `127.0.0.1 kafka` (setting KAFKA_URL later doesn't seem to work)
- Run the frontend
- `yarn build`
- `yarn start` or click "▶️" next to `"start"` in the scripts section of package.json.
- Run the backend
- `export DEBUG=1`
- `export PRIMARY_DB=clickhouse`
- `export DATABASE_URL=postgres://posthog:posthog@localhost:5439/posthog` (note the `9` in `5439`)
- Run migrations: `python manage.py migrate && python manage.py migrate_clickhouse`
- Run the app: `python manage.py runserver` (or set it up via your IDE)
- Run the worker: `./bin/start-worker`
- Setting up PyCharm debugging
- Copy the env when needed:
- `;DEBUG=1;PRIMARY_DB=clickhouse;DATABASE_URL=postgres://posthog:posthog@localhost:5439/posthog`
- Backend config:
- Set up a `Django Server`
- For django support, set the project folder to the project root
- Settings: `./posthog/settings.py`
- Worker config:
- Set up a python configuration
- script_path `./env/bin/celery` (replace `.` with the project dir)
- parameters `-A posthog worker -B --scheduler redbeat.RedBeatScheduler`
- Tests:
- All the same, except skip `DEBUG=1` in the env settings.
- Set as the "target" in run configuration `ee/clickhouse`

View File

@ -1,99 +0,0 @@
---
title: Website MDX Setup
sidebar: Handbook
showTitle: true
---
import { Spin } from 'antd'
What better way to document MDX than with MDX?
## Rationale
There were a few moving parts involved with setting up MDX so it might make sense to have them written down.
## What's MDX?
Not in scope here - but it's essentially React in Markdown.
## How do we make it work?
### Plugin
The first thing we need is `gatsby-plugin-mdx`. That's configured in `gatsby-config.js`.
We also need `gatsby-source-filesystem` but we already use that for Markdown remarking.
### createPages
There is a plugin that creates MDX pages for you, but it was a bit limiting with regards to templates. Hence, we implement page creation ourselves
in `gatsby/createPages.js`.
That does 2 GraphQL queries - one for Markdown files, and the other for MDX files.
The response is almost the same, with a few differences.
Here, for the MDX part, we pass the page (node) `id` as part of the context for the template to process each page. More on this later.
### MDX Template
`TemplateMdx.tsx` is almost the same as our traditional post template, however, it queries MDX pages based on their ID
which we passed via the `createPages` context.
The GraphQL query will return everything we need, from content to frontmatter, and we use the component
`MDXRenderer` to render the body, and `MDXProvider` to pass some context that is available to all MDX pages.
In this case, we pass references to components that can then be used without imports directly on MDX pages, like this hedgehog:
<BasicHedgehogImage />
Because of the components passed to `MDXProvider`, I can include this hedgehog by just adding `<BasicHedgehogImage />` in my
MDX file - no import needed.
However, if I want to include something from a module, I can also do so. Here's a spinner component from AntD:
<Spin />
<br />
<br />
```js
import { Spin } from 'antd'
## Some Markdown
<Spin />
```
### mdxImportGen
The `mdxImportGen.js` script handles global MDX imports automatically. This is currently a quick implementation that can improve
and be made more robust in the pre-commit process. Essentially, it prepares a file based on all the components in our `src/components` directory
which is then used to pass the components to `MDXProvider`, making them available everywhere.
Doing globally available imports this way was important for 3 main reasons:
- Relative imports in MDX can be annoying
- Keeping MDX files clean
- Making MDX a nice experience even for less technical people that update our website
### CodeBlock
To create syntax-highlighted code blocks in Markdown, we use a plugin that handles it automatically.
However, this plugin does not work for MDX. As such, we establish a `CodeBlock` component passed alongside the others
as a prop to `MDXProvider`. It operates on `pre` tags.
This component leverages the `prism-react-renderer` module, which does not have the Okaidia theme that we use on Markdown pages.
As such, we could either switch themes or port the Okaidia CSS into the acceptable format. The latter was done and
the ported theme styles can be found in `src/lib/okaidia/index.js`.
## Final note
A final point is that a lot of this setup was done this way because we want to keep Markdown alongside MDX for now.
However, it could be worth considering migrating entirely in the future to simplify things, if MDX meets our needs entirely.

View File

@ -1,12 +0,0 @@
---
title: Tech Talks
sidebar: Handbook
showTitle: true
---
We encourage engineers to give tech talks on topics they're interested in/knowledgeable about.
## Previous talks
- PostHog Cloud Infrastructure ("Infra Brown Bag") by [James Greenhill](/handbook/people/team#james-greenhill-software-engineer)
- [Let's Talk About PyCharm](https://drive.google.com/file/d/1GV08S638NzY1H0DI7w9ZHNSE4CcVbe6y/view?usp=sharing) by [Marius Andra](/handbook/people/team#marius-andra-software-engineer)