diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index b9df3d5..e0e94a5 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -1,46 +1,70 @@ -# Contributing to SpeakCode +# Getting Started with Github -Thanks for stopping by. This repo collects writing about how developers work with code, and the main thing I am looking for is your learning path into tech. +## Setting up your environment -You do not need to be senior, credentialed, or certain about anything. The point of the collection is that the paths are different. +Setting up your environment is essential to becoming a contributor using Github. Once your environment is set, you can monitor your activity through the [website](https://github.com/) or [mobile app](https://github.com/mobile). To contribute to this website, you need to set up your own GitHub account. -## What this repo accepts +## Create a GitHub account and set up your profile -**Learning path submissions.** Your route into a technical role, what you had to learn, what you are still learning. This is the main contribution. Template and prompt are in [learning-path.md](../learning-path.md). +Need a GitHub account? [Create one](https://github.com/join). Here's an opportunity to get creative with a username that describes your best qualities. You can use an existing GitHub account to contribute to the website repo or any other repo you are currently using. Don't forget to complete the profile associated with your account. The profile is a way of communicating your interest and what you like to do technically. -**Corrections.** Broken links, wrong information, code samples that no longer reflect current practice. These are welcome and I would rather hear it than not. +>[!NOTE] +> Profiles are public. Please do not put any personal information in your profile. The entire GitHub community can view what you have written. -**Discussion.** Open an issue if you disagree with something in the README or want to add to it. You do not have to write a PR to start a conversation. +## Setting up the GitHub Stack -## What this repo does not accept +The recommendations provided are based on the setup used by professionals contributors. -* Promotional content, product pitches, or recruiting posts. -* Contributions that are not yours to give. If you are writing on behalf of an employer, make sure you have the rights. -* Anything with personal information in it. Everything here is public and stays public. +### Install Git -## How to submit +[Git](https://git-scm.com/downloads) (also known as Git Bash) A command-line-based tool that allows you to submit pull requests, manipulate the branches you created and update your local(forked) copy of the repo. The documentation for [how to use Git](https://git-scm.com/doc) is available online. This tool is available on Linux. -1. Fork the repo. -2. Create a branch off `main`. -3. Add your file. For learning paths, use a new markdown file rather than editing someone else's. -4. Open a pull request against `main`. +Free CodeCamp recommends this [list](https://www.freecodecamp.org/news/10-important-git-commands-that-every-developer-should-know/) of Git commands developers should know. -Name your PR after your technical role. Examples: `system-admin`, `data-scientist`, `sre`, `technical-writer`, `platform-engineer`. If your role does not fit a tidy label, use the closest one and explain in the PR description. +### Visual Code -New to any of this? See [Getting Started with Github](./Getting%20Started%20with%20Github.md) for setup. +[Visual code](https://code.visualstudio.com/) is available in Windows, Mac, and Linux. It is a lean editing tool that has multiple uses for development. The installation is simple and documented on the site. There is an extensive marketplace for extensions to enhance your experience using this tool built right into the application! Extensions allow you to work more closely with Github and publish branches without leaving the Visual code. -## Review +[Walkthrough using Visual Code for your first Pull Request](https://code.visualstudio.com/docs/editor/github). +It is crucial to **get a local copy of the repo before you start working on the site's content.** -I read every PR. It is one person doing this, so it may take a few days. If a week goes by with no response, comment on the PR and it will surface. +>[!NOTE] +>New branches and pull requests should only be created in your copy of the repo. You will not be making commits directly to **main**. However, you should pull **main** into your local repo to ensure you are working with the latest published content. It will reduce the risk of conflicts and unintentionally overwriting published content once your pull request merges. + +In the documentation, user groups, and support channels, you'll see the terms like **master** and **origin**. Our content will reference the actual names within the repo whenever possible. -I edit lightly. Typos and formatting, yes. Your voice and your opinions stay as you wrote them, including the ones I disagree with. +### Refresh your local repo often -If something gets declined, you will get a reason, not just a close. +It is essential to regularly update your local copy of the repo to ensure you have the latest changes. All of the updates approved by the reviewer and merged into the repo will be part of this update. A good routine is to update your local repo before you create or update any open pull requests. -## A note on AI-assisted writing +For example, use Git Bash to update your local repo. Change the current working directory to your local project. -Use whatever tools help you write. What I care about is that the experience is actually yours. A learning path that reads as generated has nothing in it worth collecting, because the whole value of this repo is that these are real routes real people took. +```bash +/c/github/bc/website (main) -## Code of conduct +$ git checkout main +$ git pull upstream main +``` + +Completing this step before you edit or create content will reduce the possibility of a [merge conflict](https://docs.github.com/en/github/collaborating-with-pull-requests/addressing-merge-conflicts/about-merge-conflicts#resolving-merge-conflicts). + +### Github Desktop + +If you are new to Github or would like a quick visual of what's going on in the repo, this is the tool for you. At a glance, you can see the history of changes in the repo you are working in, your latest changes as well as branches you've created. You can use the Github desktop application to get a copy of any repo you are working in. The GitHub website can connect directly to your desktop. The tool also can publish your branch instantly to the repo. + +Want to leverage Github Desktop? See [Contributing and collaborating using GitHub Desktop](https://docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop) + +### Gitpod + +Interesting in trying the online experience? Try https://www.gitpod.io/docs/quickstart + +### Tips + + The information will be helpful as you being a journey with Github or to refresh your skills. This list is subject to change based on availability. If one of the links no longer works, please advise us, or share a link you've found useful. + +- [GitHub Docs](https://docs.github.com/en) +- [Markdown Cheatsheet](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) +- [Basic syntax of markdown](https://www.markdownguide.org/basic-syntax/) +- [GitHub markdown syntax PDF](https://guides.github.com/pdfs/markdown-cheatsheet-online.pdf) +- [Create an issue or Pull Request](https://docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop/working-with-your-remote-repository-on-github-or-github-enterprise/creating-an-issue-or-pull-request) -Be decent to people. Disagree with ideas, not with the person holding them. Anything that reads as harassment gets removed and the contributor blocked, no discussion. diff --git a/.github/Getting Started with Github.md b/.github/Getting Started with Github.md index 2830e82..e0e94a5 100644 --- a/.github/Getting Started with Github.md +++ b/.github/Getting Started with Github.md @@ -1,64 +1,70 @@ -# Getting Started with GitHub +# Getting Started with Github -Setup notes for anyone contributing to this repo for the first time. If you already work in GitHub daily, skip this and read [CONTRIBUTING.md](./CONTRIBUTING.md) instead. +## Setting up your environment -## Create an account and set up your profile +Setting up your environment is essential to becoming a contributor using Github. Once your environment is set, you can monitor your activity through the [website](https://github.com/) or [mobile app](https://github.com/mobile). To contribute to this website, you need to set up your own GitHub account. -Need a GitHub account? [Create one](https://github.com/join). Pick a username you will be comfortable with in a few years, since it follows your commits around. +## Create a GitHub account and set up your profile -Fill out the profile. It is how you communicate what you are interested in and what you like to work on. You can monitor your activity through the [website](https://github.com/) or the [mobile app](https://github.com/mobile). +Need a GitHub account? [Create one](https://github.com/join). Here's an opportunity to get creative with a username that describes your best qualities. You can use an existing GitHub account to contribute to the website repo or any other repo you are currently using. Don't forget to complete the profile associated with your account. The profile is a way of communicating your interest and what you like to do technically. -> [!NOTE] -> Profiles are public. Do not put personal information in your profile or your commits. The entire GitHub community can see it, and commit history is difficult to clean up after the fact. +>[!NOTE] +> Profiles are public. Please do not put any personal information in your profile. The entire GitHub community can view what you have written. -One setting worth checking before your first commit: **Settings > Emails > Keep my email addresses private**. Without it, whatever email is in your local git config gets published with every commit you make. +## Setting up the GitHub Stack -## Setting up your tools +The recommendations provided are based on the setup used by professionals contributors. -### Git +### Install Git -[Git](https://git-scm.com/downloads) is the command-line tool for submitting pull requests, managing branches, and updating your local copy of the repo. Documentation for [how to use Git](https://git-scm.com/doc) is online, and it is good. +[Git](https://git-scm.com/downloads) (also known as Git Bash) A command-line-based tool that allows you to submit pull requests, manipulate the branches you created and update your local(forked) copy of the repo. The documentation for [how to use Git](https://git-scm.com/doc) is available online. This tool is available on Linux. -freeCodeCamp keeps a [list of Git commands](https://www.freecodecamp.org/news/10-important-git-commands-that-every-developer-should-know/) worth knowing early. +Free CodeCamp recommends this [list](https://www.freecodecamp.org/news/10-important-git-commands-that-every-developer-should-know/) of Git commands developers should know. -### Visual Studio Code +### Visual Code -[VS Code](https://code.visualstudio.com/) runs on Windows, Mac, and Linux. It is a lean editor with an extension marketplace, and it handles GitHub work without leaving the application, including publishing branches. +[Visual code](https://code.visualstudio.com/) is available in Windows, Mac, and Linux. It is a lean editing tool that has multiple uses for development. The installation is simple and documented on the site. There is an extensive marketplace for extensions to enhance your experience using this tool built right into the application! Extensions allow you to work more closely with Github and publish branches without leaving the Visual code. -There is a [walkthrough for your first pull request](https://code.visualstudio.com/docs/editor/github) in their docs. +[Walkthrough using Visual Code for your first Pull Request](https://code.visualstudio.com/docs/editor/github). +It is crucial to **get a local copy of the repo before you start working on the site's content.** -Get a local copy of the repo before you start working on anything. +>[!NOTE] +>New branches and pull requests should only be created in your copy of the repo. You will not be making commits directly to **main**. However, you should pull **main** into your local repo to ensure you are working with the latest published content. It will reduce the risk of conflicts and unintentionally overwriting published content once your pull request merges. + +In the documentation, user groups, and support channels, you'll see the terms like **master** and **origin**. Our content will reference the actual names within the repo whenever possible. -> [!NOTE] -> Create branches and pull requests in your own fork. You will not commit directly to `main`. Pull `main` into your local copy regularly so you are working against current content. It reduces the risk of conflicts. +### Refresh your local repo often -### GitHub Desktop +It is essential to regularly update your local copy of the repo to ensure you have the latest changes. All of the updates approved by the reviewer and merged into the repo will be part of this update. A good routine is to update your local repo before you create or update any open pull requests. -If you are new to GitHub or want a visual read on what is happening in a repo, [GitHub Desktop](https://desktop.github.com/) shows history, your local changes, and your branches at a glance. It connects directly to the website and publishes branches in one click. +For example, use Git Bash to update your local repo. Change the current working directory to your local project. -See [contributing and collaborating using GitHub Desktop](https://docs.github.com/en/desktop/overview/getting-started-with-github-desktop). +```bash +/c/github/bc/website (main) -### Working in the browser +$ git checkout main +$ git pull upstream main +``` -You do not have to install anything to make a small edit. GitHub's web editor handles single-file changes, and pressing `.` in any repo opens a full editor in the browser. For a one-file learning path submission, that is often enough. +Completing this step before you edit or create content will reduce the possibility of a [merge conflict](https://docs.github.com/en/github/collaborating-with-pull-requests/addressing-merge-conflicts/about-merge-conflicts#resolving-merge-conflicts). -## Keep your local copy current +### Github Desktop -Update your local copy before you create or update a pull request. It reduces the chance of a [merge conflict](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/about-merge-conflicts). +If you are new to Github or would like a quick visual of what's going on in the repo, this is the tool for you. At a glance, you can see the history of changes in the repo you are working in, your latest changes as well as branches you've created. You can use the Github desktop application to get a copy of any repo you are working in. The GitHub website can connect directly to your desktop. The tool also can publish your branch instantly to the repo. -```bash -$ git checkout main -$ git pull upstream main -``` +Want to leverage Github Desktop? See [Contributing and collaborating using GitHub Desktop](https://docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop) -If `upstream` is not set yet, that is the original repo you forked from. GitHub documents [configuring a remote for a fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/configuring-a-remote-repository-for-a-fork). +### Gitpod -## Reference +Interesting in trying the online experience? Try https://www.gitpod.io/docs/quickstart -This list changes as tools and docs move. If a link is dead, open an issue or send a replacement. +### Tips + + The information will be helpful as you being a journey with Github or to refresh your skills. This list is subject to change based on availability. If one of the links no longer works, please advise us, or share a link you've found useful. - [GitHub Docs](https://docs.github.com/en) +- [Markdown Cheatsheet](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) - [Basic syntax of markdown](https://www.markdownguide.org/basic-syntax/) -- [GitHub markdown syntax](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax) -- [Creating an issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue) -- [Creating a pull request from a fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork) +- [GitHub markdown syntax PDF](https://guides.github.com/pdfs/markdown-cheatsheet-online.pdf) +- [Create an issue or Pull Request](https://docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop/working-with-your-remote-repository-on-github-or-github-enterprise/creating-an-issue-or-pull-request) + diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md index 33ada8b..bbcbbe7 100644 --- a/.github/ISSUE_TEMPLATE/feature_request.md +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -1,20 +1,20 @@ --- -name: Suggestion or correction -about: Propose a change to the content in this repo +name: Feature request +about: Suggest an idea for this project title: '' labels: '' assignees: '' --- -**What is this about?** -Which file or section. A link is fine. +**Is your feature request related to a problem? Please describe.** +A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] -**What is wrong or missing?** -Dead link, outdated information, a code sample that no longer reflects current practice, or a topic you think should be covered. +**Describe the solution you'd like** +A clear and concise description of what you want to happen. -**What would you change it to?** -If you already have a replacement in mind, put it here. If not, say so and I will work it out. +**Describe alternatives you've considered** +A clear and concise description of any alternative solutions or features you've considered. -**Anything else** -Context, sources, or screenshots. +**Additional context** +Add any other context or screenshots about the feature request here. diff --git a/.github/workflow/github-actions-demo.yml b/.github/workflow/github-actions-demo.yml new file mode 100644 index 0000000..711d62e --- /dev/null +++ b/.github/workflow/github-actions-demo.yml @@ -0,0 +1,17 @@ +name: GitHub Actions Demo +on: [push] +jobs: + Explore-GitHub-Actions: + runs-on: ubuntu-latest + steps: + - run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event." + - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!" + - run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}." + - name: Check out repository code + uses: actions/checkout@v2 + - run: echo "💡 The ${{ github.repository }} repository has been cloned to the runner." + - run: echo "🖥️ The workflow is now ready to test your code on the runner." + - name: List files in the repository + run: | + ls ${{ github.workspace }} + - run: echo "🍏 This job's status is ${{ job.status }}." diff --git a/.github/workflows/greetings.yml b/.github/workflows/greetings.yml index 2f66753..ee1cb11 100644 --- a/.github/workflows/greetings.yml +++ b/.github/workflows/greetings.yml @@ -1,6 +1,6 @@ name: Greetings -on: [pull_request_target, issues] +on: [pull_request, issues] jobs: greeting: @@ -12,11 +12,5 @@ jobs: - uses: actions/first-interaction@v1 with: repo-token: ${{ secrets.GITHUB_TOKEN }} - issue-message: | - Thanks for opening your first issue here. I read all of them, and it is one person doing this, so give it a few days. If a week goes by with nothing, comment again and it will surface. - pr-message: | - Thanks for your first pull request to SpeakCode. - - A few things while you wait: name your PR after your technical role if this is a learning path submission, and check that nothing personal made it into the file. Everything here is public. - - I edit lightly. Typos and formatting, yes. Your voice stays as you wrote it. + issue-message: 'Message that will be displayed on users first issue' + pr-message: 'Message that will be displayed on users first pull request' diff --git a/.github/workflows/link-check.yml b/.github/workflows/link-check.yml deleted file mode 100644 index 40d6de3..0000000 --- a/.github/workflows/link-check.yml +++ /dev/null @@ -1,25 +0,0 @@ -name: Link check - -on: - push: - paths: - - '**.md' - pull_request: - paths: - - '**.md' - schedule: - - cron: '0 9 1 * *' - workflow_dispatch: - -jobs: - check-links: - runs-on: ubuntu-latest - steps: - - name: Check out repository code - uses: actions/checkout@v4 - - - name: Check markdown links - uses: lycheeverse/lychee-action@v2 - with: - args: --no-progress --verbose --accept 200,206,429 './**/*.md' - fail: true diff --git a/README.md b/README.md index 5c6a6d9..9e04bd6 100644 --- a/README.md +++ b/README.md @@ -1,99 +1,43 @@ ## **Speak Code** - -SpeakCode - Let's create something useful. +SpeakCode - A collection of code samples created and shared by the community ## **Do you speak code?** -I started this repo in 2021 around a simple idea: developers reuse code. Maintenance, new features, upgrades, monitoring. Very little of it gets written from nothing. The hard part back then was finding usable code and knowing whether it fit. - -Five years later the finding part is mostly solved. Ask a model, get working code in seconds. The knowing part is not solved, and I do not think it is close. - -That gap is what this repo is about now. - -### **What changed** - -Generation is cheap. A model will produce a function, a class, an entire service, and most of the time it runs. What a model cannot do is know your codebase. - -* It does not know why that service was written the way it was. -* It does not know which requirement the change is tied to. -* It does not know what your team agreed to three sprints ago. -* It does not know what breaks downstream. - -That is context, and context is the work. The judgment about whether a change belongs is the part that did not get automated. - -### **Examples of code that gets reused** +Developers reuse code as part of maintenance, new development, or upgrades. Automation can be a framework designed to deploy new releases; with minor edits to existing code. SRE (Software Reliability Engineers) use code to monitor web, application, and database activities. -**Microservices** (single-function modules with well-defined interfaces and operations). +Using an existing library of code, developers can develop new functions or features within the application. These changes are made for accessibility or a change in standards or needs of the business. -```java -/* HelloWorld.java - */ +### **Examples of code that can be recycled or reused** -public class HelloWorld -{ - public static void main(String[] args) { - System.out.println("Hello World!"); - } -} -``` +**Microservices** (A distinctive method of developing software systems that focus on building single-function modules with well-defined interfaces and operations.). -**Web APIs** and other web-related components. The 2021 version of this file used `XMLHttpRequest`. Most code written today uses `fetch`, and a model will hand you either one depending on what it saw in training. Knowing which belongs in your codebase is on you. +**Web APIs** (an application programming interface for either a web server or a web browser) and other web-related components often reuse code. -```javascript -const res = await fetch("https://api.example.com/products/3"); -const data = await res.json(); -console.log(data); -``` +**Object-oriented programming (OOP)** organizes software design around data, or objects, rather than functions and logic -**Object-oriented programming (OOP)** organizes software design around data, or objects, rather than functions and logic. +**Modular programming** is a design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality. -**Modular programming** separates functionality into independent, interchangeable modules, where each contains everything necessary to execute one aspect of the desired functionality. +### **Tips for building a code library** -```python -def greet(name): - """ - This function greets to - the person passed in as - a parameter - """ - print("Hello, " + name + ". Good morning!") -``` +* Choose a consistent method for storing and editing modified code. Github is an excellent example of retaining code ownership, history, and change. -### **Why open source matters here** +* If using a template, maintain the framework and save copies separately for changes. -Open source is the reason any of this works. The libraries, the runtimes, the package managers, the models themselves in many cases. Most of it is maintained by people who are not paid to do it. - -There is a difference between using open source and participating in it. - -* **Using** is installing the package and moving on. -* **Participating** is filing the issue, writing the doc, reviewing the PR, showing up to the working group. - -Participating is also where the standards get set. Formats, protocols, and specifications are written by whoever shows up to write them. If you build on top of open source and never contribute back, someone else decides what that foundation looks like. - -Documentation counts. Filing a clear issue counts. You do not have to ship a feature to be useful. - -### **Tips for building your code library** - -* Choose a consistent method for storing and editing modified code. GitHub is an excellent example of retaining code ownership, history, and change. -* If using a template, maintain the framework and save copies separately for changes. * Research templates and APIs for usability and accessibility. + * Well-documented code and use case. -* Keep the reasoning, not just the code. Six months from now the code will still be there and the reason will not. ### **Challenges?** -* Limited knowledge or access to usable code. -* New role or job with limited experience. +* Limited knowledge or access to useable code. +* New role or job with limited experience * Code base changes and a new language is used. -* Generated code that runs but nobody can explain. -* Review load that grows faster than the team. -In 2021 developers spent hours looking through blogs and forums for usable code. Now they spend that time deciding whether generated code belongs. The bottleneck moved. +Developers can literally spend hours look through blogs, forums, and support for useable code. -### **Where this goes** +### **We need your help** -SpeakCode is where I write down what I am learning about how developers actually work with code. It is not a product and it is not finished. It gets updated when I have something worth saying. +**Speak Code** is a way to share your learnings with the community. We are collecting code from the global developer community to share with the world. We are community driven and just getting started so we appreciate your support. -There is one idea written up here rather than built: [open-source-plan.md](./open-source-plan.md), on what a modern replacement for openQRM might look like. It is on paper, not in progress. +Check out our [shopping list](shopping-list.md) to see what we are looking for. -Contributions are open. See [learning-path.md](./learning-path.md) if you want to add your own path into tech. diff --git a/hacktoberfest.md b/hacktoberfest.md index 388d51c..d8ee840 100644 --- a/hacktoberfest.md +++ b/hacktoberfest.md @@ -1,19 +1,10 @@ # Hacktoberfest 2021 -![image info](./images/hacktoberfest.png) - -SpeakCode participated in Hacktoberfest in October 2021. This page is kept as a record of that. - -## What it was - Over 100k people from all over the world participate in Hacktoberfest every October by going to GitHub, choosing a repository, and contributing to it. -Contributions are made by submitting a pull request to a participating repository. In 2021, four accepted pull requests were required to complete the event. - -## Note on the rules +Contributions are made by submitting a pull request (PR) to any Hacktoberfest-affiliated repository. Your participation in Hacktoberfest will be counted once your pull request is judged acceptable (we'll go over how that works in the upcoming sections). -The rules have changed since 2021. Maintainers now opt repositories in, low-quality PRs are handled differently, and the requirements shift year to year. Check the current Hacktoberfest site before using anything on this page as instructions. +To be eligible to participate in Hacktoberfest, you must submit at least four accepted pull requests to any of the participating repositories. -## Still open -The [learning-path.md](./learning-path.md) contribution is not tied to October. It stays open year round. +Check out our [shopping list](shopping-list.md) to see what we are looking for. diff --git a/images/many-roads.jpg b/images/many-roads.jpg deleted file mode 100644 index 08289d8..0000000 Binary files a/images/many-roads.jpg and /dev/null differ diff --git a/images/placeholder.txt b/images/placeholder.txt new file mode 100644 index 0000000..8b13789 --- /dev/null +++ b/images/placeholder.txt @@ -0,0 +1 @@ + diff --git a/learning-path.md b/learning-path.md deleted file mode 100644 index 629ad17..0000000 --- a/learning-path.md +++ /dev/null @@ -1,65 +0,0 @@ -# Learning Path - -## The road you choose - -![image info](./images/many-roads.jpg) - -Many pathways have led or are leading you to your technical career. Some are traditional or non-traditional, others a mix of both. Some of us learn by doing, others by attending boot camps or another type of training or certification. - -Whatever your learning path is, it has to be continuous, because technology is not constant. That was true when I wrote it in 2021 and the last five years made the point for me. Roles that did not exist then are hiring now. Skills that were core are handled by tooling. The people doing well are the ones who kept learning, not the ones who picked correctly the first time. - -Because there are so many factors involved, I wanted to take the opportunity to explore technical roles and how people got there. College, bootcamp, self-taught, certifications, career change, all of it. - -## Contributing your path - -For this contribution **(Pull Request)**, I need the following information. - -Paste this into a blank `markdown` file and start editing. - -```txt -### Your current role - -### How many years in that role - -### List your path to learning -* How did you discover your current role? -* What skills did you need? -* What did you have to learn? -* What are you still learning? - -### How has your work changed in the last few years? -Tooling, AI, remote, layoffs, whatever moved for you. - -### Recommendations: books, camps, online courses -Provide links whenever possible. - -### One or more key things you have discovered while you are learning. - -### A positive message for those that are starting out. -``` - -Name your PR based on your technical role. Some examples: - -* system-admin -* data-scientist -* data-engineer -* sre -* devops-engineer -* platform-engineer -* security-analyst -* qa-engineer -* solutions-architect -* customer-success-architect -* ml-engineer -* ai-engineer -* technical-writer -* developer-advocate -* developer-educator -* product-manager -* support-engineer - -New to pull requests? See [Getting Started with Github](./.github/Getting%20Started%20with%20Github.md) in this repo. - -## Last words - -The goal is to collect this knowledge in one place. The bigger goal is to show that many paths lead to technology. If it helps someone keep going or start, that is a job well done. diff --git a/open-source-plan.md b/open-source-plan.md deleted file mode 100644 index e1d6d74..0000000 --- a/open-source-plan.md +++ /dev/null @@ -1,75 +0,0 @@ -# An Idea, Not a Project - -## What this is - -This repo used to carry a full source copy of openQRM 5.3.50 Community Edition, committed directly, 14MB of it. I removed it. Nothing in SpeakCode referenced it, and vendoring GPL source inside an Apache-2.0 repo is a question nobody needed to answer. - -But removing it left something worth writing down. openQRM did a job that has not been fully replaced, and I want to put the idea on paper. - -To be clear about what this document is: an idea I am thinking through in public. I am not building it. If someone else wants to, take it. - -## What openQRM did - -It managed heterogeneous data center infrastructure from one place. Bare metal and virtual machines, across Xen, KVM, VMware, and others. Diskless boot, so servers provisioned without local storage. Storage plugins, IP management, monitoring folded in, configuration management through Puppet. - -One control plane over hardware you already had, whatever shape it was in. - -Development slowed. The last community release was 5.3.60 in August 2024, and it was mostly dependency updates and PHP 8 compatibility. The project changed hands in 2020. It is still maintained, but it is not moving. - -## What replaced it, and what did not - -Kubernetes took the workload orchestration piece and took it decisively. If your problem is scheduling containers across a fleet, that argument is settled. - -What did not get replaced cleanly: - -* **Bare metal provisioning** as a first-class concern rather than a prerequisite you solve separately. -* **Mixed estates.** Physical servers, VMs on two different hypervisors, and containers, managed together instead of through three tools. -* **Small operators.** Kubernetes assumes scale and a platform team. A lot of infrastructure is neither. - -Tools exist for each piece. MAAS and Tinkerbell for metal. Proxmox for VMs. Terraform for declaration. Ansible for configuration. They are good tools. They are also separate tools, and the person holding them together is doing integration work that openQRM did in one place. - -That gap is the idea. - -## The shape of it - -If someone built this now, I do not think it looks like openQRM rewritten. It looks like this: - -**Declarative, not clickable.** Infrastructure state in version control, reconciled continuously. openQRM was a web console over imperative actions. Everything since has moved the other way, and for good reason: the console does not tell you why something is the way it is. - -**Provisioning as a plugin surface, not a core.** Metal, hypervisors, and cloud providers behind one interface. The value is the abstraction, not any single backend. - -**Inventory as the primary object.** Most infrastructure pain is not deployment, it is not knowing what you have. What is running, on what, since when, patched to what level, owned by whom. - -**Boring by default.** Infrastructure tooling that requires its own platform team has recreated the problem it solved. - -**Honest about scope.** Not a cloud. Not a Kubernetes competitor. A management layer for infrastructure that is not going to be containerized, which is more of it than the conference talks suggest. - -## Why this belongs in a repo about writing code - -Because the reuse question runs through it. - -Every piece of the above exists somewhere. The work is not invention, it is composition and judgment. Which projects are maintained. Which licenses compose. What you take as a dependency versus what you own. - -A model will generate a provisioning script in seconds. It will not tell you whether MAAS is still maintained, whether the license fits, or whether your team can operate it at 3am. That is context, and context is the whole job. - -## Open questions - -Things I do not have answers to: - -* Is the mixed-estate problem large enough to sustain a project, or is everyone quietly living with three tools? -* Does inventory-first inevitably become a CMDB, and is that a good thing or the failure mode? -* What license makes this composable rather than cornered? -* Is the honest answer just better documentation for tools that already exist? - -That last one is real. Sometimes the gap is not a missing tool. - -## If you want to take this - -It is yours. Open an issue if you want to argue with any of it, or tell me it already exists and I missed it. That is a useful outcome too. - -## References - -* openQRM Community Edition: https://openqrm-enterprise.com/community-edition/ -* MAAS: https://maas.io/ -* Tinkerbell: https://tinkerbell.org/ -* Proxmox VE: https://www.proxmox.com/en/proxmox-virtual-environment/overview diff --git a/shopping-list.md b/shopping-list.md new file mode 100644 index 0000000..ac17d58 --- /dev/null +++ b/shopping-list.md @@ -0,0 +1,47 @@ +# Code Shopping List + +## We are looking for code samples in: + +Initially we are collecting pull requests in following areas: + +Newer Languages: +* Elixir +* Go +* Dart +* Julia +* Pony +* TypeScript +* Kotlin +* Nim +* Python 3 +* PureScript +* Reason +* Rust +* Swift + +We are also interested in + +* Python +* C +* Java +* C++ +* R +* JavaScript +* PHP +* SQL + +## The pull request + +The pull request should have the following information + +* Codebase - what language is used +* Description of what the code does +* Link to code setup to run from laptop. (ie. https://www.python.org/) +* Tested and functioning code. Working code please. +* Sample data, or results. + +We are working on a template, but for now make sure your PR covers all the points mentioned. + +Please contact the maintainer if you have any questions. + + diff --git a/tmp/testfile.md b/tmp/testfile.md new file mode 100644 index 0000000..8b13789 --- /dev/null +++ b/tmp/testfile.md @@ -0,0 +1 @@ +