Skip to content
View tgotwig's full-sized avatar
  • Germany, Frankfurt am Main
  • 12:37 (UTC +02:00)

Organizations

@Snowbear-Squad @life-science-squad

Block or report tgotwig

Block user

Prevent this user from interacting with your repositories and sending you notifications. Learn more about blocking users.

You must be logged in to block users.

Please don't include any personal information such as legal names or email addresses. Maximum 100 characters, markdown supported. This note will be visible to only you.
Report abuse

Contact GitHub support about this user’s behavior. Learn more about reporting abuse.

Report abuse
tgotwig/README.md

Who is Thomas Gotwig? 🤔

Hellooo there! 👋 I'm a passioned programmer with background in Bioinformatics from my Bachelor study 👨‍🎓 Mainly interested in DevOps, Cloud and Multimedia topics 🧑‍💻

⚡️ Recent activities
  1. ❌ Closed PR #67 in tgotwig/vidmerger
  2. 💬 Commented on #53 in tgotwig/vidmerger
  3. 💬 Commented on #53 in tgotwig/vidmerger
  4. 📖 Created new wiki page Section-Subsection in tgotwig/vidmerger
  5. 📔 Created new repository tgotwig/dotfiles
💡 My Coding Principles
↳ ☝️ General ones
  • Check for consistency across tools and platforms — use diff checkers on editor content and use things like the GitHub and Confluence search across all your projects and wiki pages.
↳ ☕ Java, Python, ...
  • Keep code compact — limit function parameters (ideally ≤ 3), avoid deep nesting, and stick to a reasonable maximum line length.
  • Use consistent and meaningful naming — predictable naming patterns make searching, navigation, and bulk refactoring (e.g., find & replace) much more reliable and efficient.
  • Don't write db queries by hand — do it via repository functions.
  • Let an code generator generate classes for you — when dealing with an OpenAPI spec.
  • Write tests at multiple levels — use unit tests to check always one function without I/O (mock external dependencies where needed), integration tests to check always one function with real I/O, and end-to-end tests to check a full chain of functions (like Camunda or Selenium workflows, or a cli tool).
↳ 🌳 Versioning (Git)
  • Use a Git GUI tool like GitKraken — a visual overview often leads to cleaner commits and makes advanced Git features (like interactive rebase or working with submodules) more accessible.
  • Keep commits focused and atomic — aim for “one logical change per commit” to make reviews easier and enable selective acceptance or reversion.
  • Maintain a consistent code style — avoid mixing style and functional changes in one commit; first apply the style update, then the logic change.
  • Preserve full commit history when migrating repositories — instead of squashing into a single commit, add the new remote and push as-is.
  • Write meaningful commit messages — use the imperative mood (“Add feature,” not “Added feature”), and avoid vague messages like “Update” to help others understand changes at a glance.
  • Tag commits not only for versioning — but also to highlight other special commits.
  • Create a backup branch before doing a complex rebase — to not accidently overwrite commits in a wrong way.
↳ 🌐 Networking
  • Document the network layout using a diagram that includes key IPs, DNS names, and boundaries between subnets or zones.
  • List physical and virtual devices in a table with their IPs, DNS names, and MAC addresses, group them in CIDRs.
  • Prefer DNS names over hardcoded IPs, for better clarity and minimal fixes when the IP changes.
  • Provide a central "intranet" homepage linking to all important internal services.
↳ ⚙️ Automation
  • Build the project ideally with 1 cmd — after cloning it, typically via Taskfile, also in CI / CD.
  • Centralize testing and releasing via CI / CD — and run them mostly during pull requests.
  • Monitor your resource usages — and have reportings before server crashes due to it.
  • Backup your data frequently in 3 ways — while removing some versions over time.
  • Don't try to automate everything — have runbooks for certain tasks.
↳ 🐳 Containerization
  • Configure via env vars — better than via files with different encodings and permissions.
  • Grant 3rd party access via scoped tokens — avoid overly permissive ones.
  • Print all logs to the terminal — for a flexible understanding.
  • Develop with dev images — with all your fav tools in it.
  • Minimize images — for running in production.
↳ 🔮 Terraform
  • Design modules for reusability — for deploying slightly different resources easily.
  • Manage the state file in an object storage — ensure it’s versioned, and use a lock file to prevent concurrent modifications. Consider maintaining a shared calendar for coordinated infrastructure changes.

🐿️ ChipChap - GUI app For editing chapter infos in video and audio files. (WiP)

🤓 Dev Links 👉 Chocolatey | Dev | Observable | Stackoverflow | Vagrantup

🍻 Social Links 👉 LinkedIn

Pinned Loading

  1. vidmerger vidmerger Public

    📼 Merge video & audio files via CLI

    Rust 140 12

  2. tgotwig tgotwig Public

    :octocat: Github portfolio about me, Thomas Gotwig

    5

  3. dotfiles dotfiles Public

    🔗 Config files and how to share them

  4. dev-images dev-images Public

    💿 alpine, node, ubuntu

  5. homelab tg.net homelab tg.net
    1
    Network diagram with its main components, where:
    2
    
                  
    3
    - `tg.net` is the network, as well as the homepage name.
    4
    - `pihole` is the DNS server and `nginx` the reverse proxy for enforcing HTTPS.
    5
    - `pi.tg.net` is mounted via SMB in my homelab project, which is managed using Git.