From dddf50bc0907b72a6025e292ca5458abc0feac6c Mon Sep 17 00:00:00 2001 From: Charles Wyble Date: Sun, 16 May 2021 15:01:19 -0500 Subject: [PATCH] importing upstream --- src/engineering/ee-setup.md | 47 ----------------- src/engineering/mdx.mdx | 99 ----------------------------------- src/engineering/tech-talks.md | 12 ----- 3 files changed, 158 deletions(-) delete mode 100644 src/engineering/ee-setup.md delete mode 100644 src/engineering/mdx.mdx delete mode 100644 src/engineering/tech-talks.md diff --git a/src/engineering/ee-setup.md b/src/engineering/ee-setup.md deleted file mode 100644 index 04c6564..0000000 --- a/src/engineering/ee-setup.md +++ /dev/null @@ -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` \ No newline at end of file diff --git a/src/engineering/mdx.mdx b/src/engineering/mdx.mdx deleted file mode 100644 index 8109f4f..0000000 --- a/src/engineering/mdx.mdx +++ /dev/null @@ -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: - - - -Because of the components passed to `MDXProvider`, I can include this hedgehog by just adding `` 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: - - - -
-
- - -```js - -import { Spin } from 'antd' - -## Some Markdown - - - -``` - -### 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. \ No newline at end of file diff --git a/src/engineering/tech-talks.md b/src/engineering/tech-talks.md deleted file mode 100644 index d245af1..0000000 --- a/src/engineering/tech-talks.md +++ /dev/null @@ -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) \ No newline at end of file