✍️ @DeRomuald's Blog

[DeRomuald]

Hi and welcome to Content Lab! Here is a self paced guide to ensure you get feedback as you publish your technical blog.

Resources:

• Previous workshop recording
• Previous blog posts

Timeline:

• 📋 Dec 1st have an outline and open up issue
• 📰 Dec 8th have rough draft in
  • Mentor reviews by 12/15
• Dec 15th-20th turn in final draft

📋 Blog Outline: Write your outline in the issue directly

Requirements

Questions to consider:

• Who’s reading this? Where are they in your dev journey? What do they need to know before they can dive into this story?
• If people could leave with just one action, what would it be?
• Were there surprises or alternative problem solving you want to give a heads up to?

Sample Topics for your blog post

• Creating tests for Stripe/Cicero/Twilio
• Using Vuetify and V-cards
• Debugging a PR test failure affecting entire codebase and creating an issue for it
• System Design/Architecture design for caching capability
• Implementing Text to Speech
• Configuring secrets for APIs in codespaces
• Building Actions for [security|community|CI| etc]

Example Outlines

What makes good documentation on open source?

• Could this be a list? (3 pieces of documentation thats easy to check for and add to the project to add immediate value?
• What inspired you from the Tech documentation workshop?
• What would you help encourage other first time contributors to do?
• Is a learning curve for everyone? And whats the balance between good documentation and too much documentation? Choice architecture
• What is each space used for? Wiki vs Discussion vs Pages
• How do we search and find?
  Reference: https://blackgirlbytes.dev/conquering-the-fear-of-contributing-to-open-source
  Reference issue/PR for photos
  Conclusion: Documentation is always changing, will always be needed`

To Do: when you complete the requirements, add "outline ready" label on your issue

• Identify your topic from one of the PRs approved
• Outlining bullet points of blog roadmap
• Is your blog a List, Survey, or demo?
• Which Visuals or Diagram or Code snippets will you add
• References to resources

📰 Blog Rough draft: Format into a google doc

Questions to answer across draft

• Why is this helpful for a reader?
• What problem does this help them solve?
• What kind of experience should the reader have or that you will provide so they’re up to speed
• What larger problem is this solving?
• Were there other ways of solving this problem - what made you choose the one that you did?
• What were the positive tradeoffs? (Did it save time? Save hours? Was more secure?)
• What is the best way to present the content (i.e. code snippets, graphics) ?
• What additional resources can they provide the reader if they want more information?
• Is there a call to action?

To do: when you complete the requirements, add "draft ready" label on your issue

• intro paragraph
• context of Amplify
• paragraph on problem
• paragrph compare your solution
• paragraph impact your solution
• Less than 600 words
• Drop link to your google doc (with permissions for edits) in review issue

[DeRomuald]

Outline: Securely Adding API Secrets in GitHub Codespaces

Title

• Getting Started: How to Securely Add API Secrets in GitHub Codespaces

---

1. Introduction

• Brief overview of what secrets are and why they’re important.
• Context: Targeting beginners who are new to Codespaces and secret management.
• Hook: Example scenario of misusing an API key and its consequences.

---

2. Why This Matters

• Importance of managing secrets securely in cloud-based environments.
• Real-life example of risks associated with exposing secrets.
• Goal: Emphasize security awareness for beginners.

---

3. What You’ll Learn

• Three clear takeaways:
  1. How to add secrets in GitHub.
  2. How to use them in Codespaces.
  3. Best practices for protecting sensitive information.

---

4. Step 1: Understanding the Basics

• What is GitHub Codespaces?
  • Simplified explanation with reference to official docs.
• What is a Secret?
  • Definition and purpose of secrets.
  • Link to GitHub’s guide on encrypted secrets.

---

5. Step 2: Adding a Secret in GitHub

• Step-by-step Instructions:
  1. Log in to GitHub and open repository settings.
  2. Navigate to the Secrets section under Codespaces.
  3. Add a new secret (name and value).
  4. Save the secret.
• Reference: GitHub documentation on managing Codespaces secrets.

---

6. Step 3: Using the Secret in Your Codespace

• Accessing Secrets:
  1. Start a Codespace from your repository.
  2. Use environment variables to access secrets in code.
• Example Code:
  • Python snippet to retrieve and use a secret.
• Emphasis on error handling and beginner-friendly explanation.

---

7. Step 4: Best Practices

• Simple tips for beginners:
  1. Never share secrets publicly.
  2. Avoid hardcoding secrets in code.
  3. Use .gitignore for sensitive files.
  4. Seek help from the GitHub community if needed.
• Reference: .gitignore documentation and community forum.

---

8. Common Issues and Fixes

• Troubleshooting tips:
  • Missing secrets in Codespaces.
  • Steps to take if a secret is accidentally committed.
• Reference: GitHub guide on removing sensitive data.

---

9. Conclusion

• Recap of what was learned.
• Encouragement to practice secret management with a small project.
• Call to action: Explore Codespaces and manage secrets in a real-world scenario.

---

10. References

• Links to official documentation and related resources:
  • GitHub Codespaces: [Docs](https://docs.github.com/en/codespaces)
  • .gitignore file: [Docs](https://git-scm.com/docs/gitignore)
  • Removing sensitive data: [Guide](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository)

[DeRomuald]

Google Doc Link to Draft:

https://docs.google.com/document/d/1MNzqiVHtE5ZmsjxkQaY1d-Httx1Qq9xTxXwSY68n-rk/edit?usp=sharing