[{"content":"Why? I have been fascinated by Japanese culture for a very long time. One aspect that has always caught my attention is the longevity and overall health of Japanese people.\nAn interesting element of Japanese culture is that people spend a lot of time sitting on the floor. Most of you have probably seen scenes in Japanese movies where people sit on the floor around a low table.\nThis made me wonder whether sitting on the floor could be one of the factors contributing to their health and longevity, and whether I could apply this habit to my own life.\nEvery time you sit down on the floor and get back up, your body has to perform a physical movement. In a way, it is similar to doing a squat each time, and squats are very beneficial for the body. In addition, sitting in a meditation-like position encourages us to maintain better posture.\nSince I had already been practicing meditation for a long time and owned a meditation cushion, I decided to run an experiment: I replaced the office chair I used for work with my meditation cushion.\nI modified my desk so that its height would be suitable for working while sitting on the floor, and I began the experiment.\nThe First Month The first month was much more difficult than I expected. After the first few days, I was already close to giving up. My knees and back hurt, and despite my experience with meditation, I did not feel comfortable sitting on the floor for such a long time.\nIt quickly became clear that sitting on the floor for eight hours a day was very different from meditating for thirty minutes.\nDespite the initial difficulties, I decided to continue the experiment and give my body enough time to adapt.\nAfter the first month, the pain in my knees and back disappeared, and I started to feel much more comfortable. I also noticed a slight improvement in my posture.\nTwo Years Later, I Still Work on the Floor It has now been two years since I started this experiment, and I have no intention of going back to sitting in an office chair. I feel much better than I did before, my posture has improved significantly, and I can no longer imagine spending many hours sitting in a comfortable office chair—which, ironically, no longer feels comfortable to me at all.\nI have also discovered that sitting on the floor allows us to use many different positions, which can also have a positive effect on the body. Spending the entire day in a single position is very unhealthy.\nYoga can be helpful here. Many asanas can be adapted to sitting and working at a computer, allowing us to regularly change the position in which we work.\nWhat do you think about this kind of workspace? Would you consider replacing your chair with a floor setup? Or maybe you have your own unusual way of working at a computer that makes you feel more comfortable or helps you stay active?\nOriginally published on CoderLegion.\n","permalink":"https://spaceshaman.github.io/posts/why-i-replaced-my-chair-with-a-meditation-cushion/","summary":"\u003ch2 id=\"why\"\u003eWhy?\u003c/h2\u003e\n\u003cp\u003eI have been fascinated by Japanese culture for a very long time. One aspect that has always caught my attention is the longevity and overall health of Japanese people.\u003c/p\u003e\n\u003cp\u003eAn interesting element of Japanese culture is that people spend a lot of time sitting on the floor. Most of you have probably seen scenes in Japanese movies where people sit on the floor around a low table.\u003c/p\u003e\n\u003cp\u003eThis made me wonder whether sitting on the floor could be one of the factors contributing to their health and longevity, and whether I could apply this habit to my own life.\u003c/p\u003e","title":"Why I Replaced My Chair with a Meditation Cushion"},{"content":"User management is one of those problems that rarely feels difficult enough to deserve much attention.\nUntil you implement it for the fifth time.\nRegistration, login, sessions, email verification, password resets, password changes, account deletion, roles, permissions — none of these features are particularly unusual. But almost every application needs some combination of them, and the implementation often ends up tightly coupled to whatever framework, ORM, or infrastructure the project happened to use at the time.\nThat was the problem that led me to build UserHarbor.\nUserHarbor is a framework-agnostic Python library for user account management. The goal is not to build another web framework or a complete identity platform. Instead, it provides a small domain-level API for common account operations while leaving HTTP, databases and email delivery to separate integrations.\nSince I first wrote about the project, the interesting part has increasingly become not just the authentication API itself, but the boundary between the core and its integrations.\nThis article expands on my original introduction to UserHarbor, focusing on how the architecture evolved as the project grew.\nThe problem I wanted to solve Imagine building two applications.\nOne uses:\nFastAPI SQLAlchemy PostgreSQL SMTP Another uses:\nFlask MongoDB an external email API The user-management rules are mostly the same.\nA password still needs to be validated and hashed. A verification token still needs to expire. Password reset tokens still need to be protected. Sessions need to be created and invalidated. Roles and permissions need to be checked.\nBut in many libraries these rules are mixed together with database models, HTTP handlers or framework-specific abstractions.\nI wanted the opposite.\nThe core should know what should happen, but not necessarily how the application stores or transports the data.\nThat leads to an architecture that looks roughly like this:\nApplication / Framework │ ▼ UserHarbor │ ├── UserStore │ └── database / ORM / custom backend │ └── EmailSender └── SMTP / API / custom provider The core owns things such as registration, validation, password hashing, token generation, token hashing, session handling and authorization rules.\nThe adapters own infrastructure.\nA small domain-level API UserHarbor currently handles the common account lifecycle:\nuser registration email verification login sessions logout from one or all sessions password change password reset account deletion roles and permissions It deliberately does not expose HTTP endpoints itself.\nThat means code using the core can look like this:\nuser = harbor.register( username=\u0026#34;jane\u0026#34;, email=\u0026#34;*Emails are not allowed*\u0026#34;, password=\u0026#34;StrongPassword123!\u0026#34;, ) harbor.verify_email(verification_token) session_token = harbor.login( username=\u0026#34;jane\u0026#34;, password=\u0026#34;StrongPassword123!\u0026#34;, ) current_user = harbor.get_current_user(session_token) The same UserHarbor instance can be used from FastAPI, Flask, Django, a CLI application or something that does not expose HTTP at all.\nAuthorization follows the same idea:\nharbor.roles.create(\u0026#34;admin\u0026#34;) harbor.permissions.create(\u0026#34;users.delete\u0026#34;) harbor.roles.grant_permission( \u0026#34;admin\u0026#34;, \u0026#34;users.delete\u0026#34;, ) harbor.grant_role(\u0026#34;jane\u0026#34;, \u0026#34;admin\u0026#34;) if harbor.has_permission(session_token, \u0026#34;users.delete\u0026#34;): delete_user() Or, if access should be enforced:\nuser = harbor.require_permission( session_token, \u0026#34;users.delete\u0026#34;, ) UserHarbor implements simple role-based access control, but leaves application-specific authorization policy outside the core. It intentionally does not try to become a general policy engine.\nFramework-agnostic does not mean framework-unfriendly One thing I wanted to avoid was making framework independence come at the cost of developer experience.\nFor example, there is an official userharbor-fastapi integration.\nInstead of manually writing authentication routes and dependencies, a FastAPI application can configure UserHarbor and attach the adapter:\nfrom fastapi import FastAPI from userharbor import UserHarbor from userharbor_fastapi import UserHarborFastAPI harbor = UserHarbor( secret_key=\u0026#34;your-secret-key\u0026#34;, store=store, email_sender=email_sender, ) auth = UserHarborFastAPI(harbor) app = FastAPI() app.include_router( auth.router, prefix=\u0026#34;/auth\u0026#34;, tags=[\u0026#34;auth\u0026#34;], ) The adapter provides the framework-specific layer: routers, request schemas, bearer authentication dependencies, error mapping and helpers for requiring roles or permissions.\nThe important part is that FastAPI still does not leak into the UserHarbor core.\nYou can replace the web framework without replacing the account-management logic.\nThe harder problem: what does it mean to implement UserStore? Originally, separating persistence behind a UserStore interface seemed like the obvious solution.\nDefine an interface, implement the methods, and now SQLAlchemy, MongoDB, Redis or anything else can provide storage.\nBut there is a subtle problem.\nMatching method signatures does not mean two storage implementations behave the same way.\nConsider a password reset token.\nShould creating a new token remove an older token?\nWhat happens when a user is deleted?\nShould their sessions disappear automatically?\nWhat should happen if a transaction fails halfway through a password change?\nShould deleting something that no longer exists raise an error?\nThese behaviors are part of the storage contract even though Python\u0026rsquo;s type system cannot express them.\nThis became one of the most important changes in UserHarbor 0.7.0.\nTurning the adapter contract into executable tests UserHarbor now ships a reusable contract test suite for UserStore implementations.\nAn adapter can import the complete suite:\n# tests/test_user_store_contract.py from userharbor.testing.user_store_contract import * Then it only needs to provide a clean store:\nimport pytest @pytest.fixture def user_store(): store = create_user_store() try: yield store finally: dispose_user_store(store) The same tests can then run against SQLAlchemy, an in-memory implementation, or a completely different persistence backend.\nVersion 0.7.0 introduced 57 reusable contract tests covering users, password hashes, verification tokens, password reset tokens, sessions, roles, permissions, relationships and transaction behavior.\nThis changes the meaning of an adapter.\nA compatible UserStore no longer just claims to implement an interface. It can demonstrate that it follows the behavioral semantics expected by the core.\nFor example, the contract specifies that:\nusernames and email addresses are unique user creation and the initial verification token are atomic a new verification token replaces the previous one a new password reset token replaces the previous one deleting a user removes their sessions and related tokens repeated relationship assignments are idempotent deleting roles and permissions removes their assignments successful transactions commit failed transactions roll back nested transactions participate in the outer transaction These details are easy to overlook when implementing another backend, and they are exactly the type of differences that can produce authentication bugs which only appear much later.\nFor me, this was an important step in the architecture: the abstraction is now described not only by Python protocols and documentation, but also by executable behavior.\nA template for building new storage adapters To make that process easier, I also created userharbor-inmemory.\nIt is a minimal in-memory UserStore implementation that passes the complete storage contract.\nIt serves two purposes.\nFirst, it is useful for tests and examples where a real database is unnecessary.\nSecond, the repository itself can be used as a template for creating new storage integrations. A developer can start with a working implementation and passing contract tests, replace the in-memory backend incrementally, and continuously verify that the new adapter still behaves correctly.\nThe idea is that creating something like a future database adapter should mostly become:\nworking UserStore template │ ▼ replace persistence implementation │ ▼ run shared contract tests │ ▼ add backend-specific tests instead of reverse-engineering the expected behavior from the core implementation.\nKeeping security behavior inside the core Another important architectural boundary is that storage adapters never receive raw tokens for persistence.\nUserHarbor generates the raw verification, reset and session tokens, but hashes them before passing them to UserStore.\nThe raw token is given only to the part of the application that needs it — for example, to an email sender or to the user after login.\nThe database stores the hash.\nThe core also owns behavior such as token expiration and session validation.\nSensitive account-discovery flows are designed to return neutral responses where appropriate. For example, requesting a password reset for an unknown email address does not reveal whether that account exists.\nThere are also account lifecycle notifications for events such as:\nsuccessful email verification password changes password resets account deletion The EmailSender interface decides how those messages are delivered, but it does not decide when the operation is valid. That decision remains in the core.\nSQLAlchemy without owning your application The official SQLAlchemy adapter is useful out of the box, but one design requirement was that adopting UserHarbor should not force an application to adopt a completely separate user model.\nBy default, the adapter can manage its own user table.\nBut applications that already have a SQLAlchemy model can provide it instead:\nstore = SQLAlchemyUserStore( SessionLocal, user_model=AppUser, ) Applications can also map their model to a richer public user object instead of being limited to UserHarbor\u0026rsquo;s minimal representation.\nThe documentation now also covers using the adapter with Alembic migrations rather than relying on metadata.create_all() at application startup.\nThat distinction matters because examples should be easy to run, but real applications need a sensible path toward managing schema changes properly.\nInstallation The core can be installed on its own:\npip install userharbor Or with selected official integrations:\npip install \u0026#34;userharbor[sqlalchemy,smtp,fastapi]\u0026#34; For experimenting with the complete official stack:\npip install \u0026#34;userharbor[all]\u0026#34; The main official integrations currently include SQLAlchemy storage, SMTP email delivery and FastAPI support.\nWhat I deliberately do not want UserHarbor to become Feature creep is an easy trap for this kind of project.\nOnce you have authentication, it is tempting to add OAuth. Then social login. Then MFA. Organizations. Teams. ACLs. Resource ownership. Admin panels. A policy language.\nEventually the \u0026ldquo;small authentication library\u0026rdquo; becomes an application framework.\nThat is specifically what I am trying to avoid.\nThe core should remain focused on common account-management primitives.\nMore specialized functionality can exist as integrations or separate libraries if there is demand for it, but it should not make the basic package more complicated for everyone else.\nOne of the design principles of UserHarbor is therefore deliberately boring:\nstability is more important than feature count.\nOnce the public API stabilizes, I would rather spend development effort on security, reliability, compatibility and performance than continuously expand the scope of the core.\nCurrent status UserHarbor is currently at version 0.7.0.\nThe project is still young, and I do not consider the API stable or the library ready for production use yet.\nAt this stage, the project is as much about validating the architecture as adding functionality.\nThe areas I am particularly interested in getting feedback on are:\nthe boundary between the core and integrations the UserStore contract the contract-testing approach the FastAPI integration custom storage backends the shape of the public API what should — and should not — belong in the core There are plenty of good framework-specific authentication libraries in Python.\nUserHarbor is exploring a slightly different question:\nCan the account-management domain itself be reusable across frameworks and infrastructure, while integrations remain small, replaceable and independently testable?\nSo far, I think that boundary is turning out to be the most interesting part of the project.\nLinks Documentation:\nhttps://userharbor.github.io/userharbor/\nRepository:\nhttps://github.com/userharbor/userharbor\nFastAPI integration:\nhttps://github.com/userharbor/userharbor-fastapi\nSQLAlchemy adapter:\nhttps://github.com/userharbor/userharbor-sqlalchemy\nSMTP adapter:\nhttps://github.com/userharbor/userharbor-smtp\nOriginally published on CoderLegion.\n","permalink":"https://spaceshaman.github.io/posts/building-userharbor-framework-agnostic-user-management-for-python/","summary":"\u003cp\u003eUser management is one of those problems that rarely feels difficult enough to deserve much attention.\u003c/p\u003e\n\u003cp\u003eUntil you implement it for the fifth time.\u003c/p\u003e\n\u003cp\u003eRegistration, login, sessions, email verification, password resets, password changes, account deletion, roles, permissions — none of these features are particularly unusual. But almost every application needs some combination of them, and the implementation often ends up tightly coupled to whatever framework, ORM, or infrastructure the project happened to use at the time.\u003c/p\u003e","title":"Evolving UserHarbor: From a Framework-Agnostic Core to Executable Storage Contracts"},{"content":"While working on a SaaS application recently, I once again had to implement the same user account flow:\nregistration login sessions email verification password reset password change account deletion basic roles and permissions None of that was especially hard.\nBut it was repetitive.\nI had written similar code before, and I did not want to keep rebuilding the same user-management boilerplate in every new Python project.\nSo I started working on UserHarbor.\nWhat is UserHarbor? UserHarbor is a framework-agnostic Python library for user account management.\nThe idea is simple:\nkeep the core small, predictable, and independent from any specific web framework, database, ORM, or email provider.\nThe core handles the account-management logic. Integrations are handled by separate adapter packages.\nSo instead of building something only for FastAPI, Flask, Django, or one specific stack, I wanted a core that could be used in different kinds of Python applications.\nFor example:\nFastAPI apps Flask apps Django apps CLI tools internal tools custom Python services Why not just use a framework-specific library? There are already good tools for specific frameworks.\nBut I wanted something slightly different.\nI did not want the user-management logic to be tightly coupled to:\na web framework a database layer an email provider a specific request/response model Instead, UserHarbor uses small interfaces for things like storage and email delivery.\nThe main interfaces are:\nclass UserStore: ... class EmailSender: ... The core does not care how users are stored or how emails are sent.\nThat part belongs to adapters.\nInstallation Install only the core package if you want to provide your own UserStore and EmailSender implementations:\npip install userharbor Install the core package with the official SQLAlchemy, SMTP, and FastAPI adapters:\npip install \u0026#34;userharbor[sqlalchemy,smtp,fastapi]\u0026#34; Or install all official integrations at once:\npip install \u0026#34;userharbor[all]\u0026#34; Official adapters At the moment, there are a few official adapter packages:\nuserharbor-sqlalchemy — SQLAlchemy storage userharbor-smtp — SMTP email sender userharbor-fastapi — FastAPI integration This keeps the core small while still making the common setup easy to install and use.\nQuick example Here is a longer example using SQLAlchemy storage and SMTP email delivery:\nfrom sqlalchemy import create_engine from sqlalchemy.orm import sessionmaker from userharbor import UserHarbor from userharbor_sqlalchemy import SQLAlchemyUserStore from userharbor_smtp import SMTPEmailSender engine = create_engine(\u0026#34;sqlite:///users.db\u0026#34;) SessionLocal = sessionmaker(bind=engine) store = SQLAlchemyUserStore(SessionLocal) store.metadata.create_all(engine) email_sender = SMTPEmailSender( host=\u0026#34;smtp.example.com\u0026#34;, port=587, username=\u0026#34;smtp-user\u0026#34;, password=\u0026#34;smtp-password\u0026#34;, from_email=\u0026#34;noreply@example.com\u0026#34;, ) harbor = UserHarbor( secret_key=\u0026#34;your-secret-key\u0026#34;, store=store, email_sender=email_sender, ) # Register a user harbor.register( username=\u0026#34;jane\u0026#34;, email=\u0026#34;jane@example.com\u0026#34;, password=\u0026#34;StrongPassword123!\u0026#34;, ) # Verify email address harbor.verify_email(\u0026#34;verification-token-from-email\u0026#34;) # Login session_token = harbor.login( username=\u0026#34;jane\u0026#34;, password=\u0026#34;StrongPassword123!\u0026#34;, ) # Verify session if harbor.verify_session(session_token): print(\u0026#34;User is logged in\u0026#34;) # Get current user current_user = harbor.get_current_user(session_token) print(current_user.username) # Create roles and permissions harbor.roles.create(\u0026#34;admin\u0026#34;) harbor.permissions.create(\u0026#34;users.delete\u0026#34;) harbor.roles.grant_permission(\u0026#34;admin\u0026#34;, \u0026#34;users.delete\u0026#34;) harbor.grant_role(\u0026#34;jane\u0026#34;, \u0026#34;admin\u0026#34;) # Check access if harbor.has_permission(session_token, \u0026#34;users.delete\u0026#34;): print(\u0026#34;User can delete users\u0026#34;) current_admin = harbor.require_role(session_token, \u0026#34;admin\u0026#34;) print(current_admin.username) # Logout harbor.logout(session_token) # Change password session_token = harbor.login( username=\u0026#34;jane\u0026#34;, password=\u0026#34;StrongPassword123!\u0026#34;, ) harbor.change_password( old_password=\u0026#34;StrongPassword123!\u0026#34;, new_password=\u0026#34;EvenStrongerPassword123!\u0026#34;, session_token=session_token, ) # Send password reset email harbor.send_password_reset(\u0026#34;jane@example.com\u0026#34;) # Reset password harbor.reset_password( new_password=\u0026#34;NewStrongPassword123!\u0026#34;, reset_token=\u0026#34;reset-token-from-email\u0026#34;, ) # Delete account session_token = harbor.login( username=\u0026#34;jane\u0026#34;, password=\u0026#34;NewStrongPassword123!\u0026#34;, ) harbor.delete_account( password=\u0026#34;NewStrongPassword123!\u0026#34;, session_token=session_token, ) Full FastAPI example with official integrations If you want to try the full setup with FastAPI, SQLAlchemy, and SMTP, install all official integrations:\npip install \u0026#34;userharbor[all]\u0026#34; Then create a FastAPI application:\nimport os from fastapi import FastAPI from sqlalchemy import create_engine from sqlalchemy.orm import sessionmaker from userharbor import UserHarbor from userharbor_fastapi import UserHarborFastAPI from userharbor_smtp import SMTPEmailSender from userharbor_sqlalchemy import SQLAlchemyUserStore engine = create_engine(\u0026#34;sqlite:///users.db\u0026#34;) SessionLocal = sessionmaker(bind=engine) store = SQLAlchemyUserStore(SessionLocal) store.metadata.create_all(engine) email_sender = SMTPEmailSender( host=os.getenv(\u0026#34;HOST\u0026#34;, \u0026#34;smtp.example.com\u0026#34;), port=int(os.getenv(\u0026#34;PORT\u0026#34;, 587)), username=os.getenv(\u0026#34;USERNAME\u0026#34;), password=os.getenv(\u0026#34;PASSWORD\u0026#34;), from_email=os.getenv(\u0026#34;USERNAME\u0026#34;, \u0026#34;\u0026#34;), ) harbor = UserHarbor( secret_key=\u0026#34;your-secret-key\u0026#34;, store=store, email_sender=email_sender, ) auth = UserHarborFastAPI(harbor) app = FastAPI() app.include_router(auth.router, prefix=\u0026#34;/auth\u0026#34;, tags=[\u0026#34;auth\u0026#34;]) if __name__ == \u0026#34;__main__\u0026#34;: import uvicorn uvicorn.run(app, host=\u0026#34;0.0.0.0\u0026#34;, port=8000) Design principles The project is built around a few constraints.\nThe core should stay small UserHarbor is not meant to become a full identity platform.\nThe core focuses on basic account-management flows:\nregistration login sessions email verification password reset password change account deletion simple role-based access control Anything highly application-specific should stay outside the core.\nAdapters should live outside the core Database, ORM, email, and framework integrations should be separate packages.\nThat keeps the core independent and makes it easier for other people to build their own integrations.\nFor example, someone could build:\nuserharbor-redis userharbor-mongodb userharbor-sendgrid userharbor-resend userharbor-django userharbor-flask without changing the main package.\nThe API should be boring I am trying to keep the public API explicit and predictable.\nNo hidden framework magic. No forced database model. No dependency on one specific way of building Python applications.\nCurrent status The project is still early.\nThe basic flows work, but I do not consider the API fully stable yet. It is not something I would call production-ready today.\nRight now I am mostly looking for feedback around:\nthe public API the adapter architecture the boundary between core and integrations the SQLAlchemy integration the FastAPI integration whether simple RBAC belongs in the core what a good developer experience for custom adapters should look like Links Documentation:\nhttps://userharbor.github.io/userharbor/\nRepository:\nhttps://github.com/userharbor/userharbor\nFastAPI integration:\nhttps://github.com/userharbor/userharbor-fastapi\nSQLAlchemy adapter:\nhttps://github.com/userharbor/userharbor-sqlalchemy\nSMTP adapter:\nhttps://github.com/userharbor/userharbor-smtp\nFeedback welcome I would appreciate any feedback, especially from people who have built user-management flows multiple times in Python projects.\nDoes this adapter-based approach make sense?\nWould you expect simple roles and permissions to be part of the core, or should they live in a separate package?\nAnd if you were integrating this into your own project, what would you want the API to look like?\nUpdate: I later wrote a deeper architectural follow-up about UserHarbor\u0026rsquo;s adapters and executable storage contract.\nOriginally published on DEV Community.\n","permalink":"https://spaceshaman.github.io/posts/i-built-userharbor-a-framework-agnostic-user-management-library-for-python/","summary":"\u003cp\u003eWhile working on a SaaS application recently, I once again had to implement the same user account flow:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eregistration\u003c/li\u003e\n\u003cli\u003elogin\u003c/li\u003e\n\u003cli\u003esessions\u003c/li\u003e\n\u003cli\u003eemail verification\u003c/li\u003e\n\u003cli\u003epassword reset\u003c/li\u003e\n\u003cli\u003epassword change\u003c/li\u003e\n\u003cli\u003eaccount deletion\u003c/li\u003e\n\u003cli\u003ebasic roles and permissions\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eNone of that was especially hard.\u003c/p\u003e\n\u003cp\u003eBut it was repetitive.\u003c/p\u003e\n\u003cp\u003eI had written similar code before, and I did not want to keep rebuilding the same user-management boilerplate in every new Python project.\u003c/p\u003e\n\u003cp\u003eSo I started working on \u003cstrong\u003eUserHarbor\u003c/strong\u003e.\u003c/p\u003e","title":"I built UserHarbor — a framework-agnostic user management library for Python"},{"content":"I build software and open-source tools. I am most interested in the entire development process—from the initial idea and architecture design to a working, useful solution. I work across different areas of software development and choose technologies to fit the problem rather than fitting the problem to a particular stack.\nMy projects include libraries, real-time APIs, database tools and automation for everyday development tasks. Whatever the area, I care about clear architecture, simple solutions and tools that solve a specific problem without unnecessary complexity.\nIn both work and life, I try to follow the principle: Simple is better than complex.\nSelected projects UserHarbor — a framework-agnostic user management system for Python applications. SocketAPI — a lightweight real-time API framework using one multiplexed WebSocket connection with endpoint-like actions and subscriptions. SQLift — a deliberately small command-line migration tool for SQL databases. ORMagic — a simple and lightweight ORM for Python, built on top of Pydantic. autopy.fish and autoenv.fish — Fish plugins that automatically activate Python environments and load variables from .env files. Find me online GitHub LinkedIn CoderLegion spaceshaman@tuta.io ","permalink":"https://spaceshaman.github.io/about/","summary":"\u003cp\u003eI build software and open-source tools. I am most interested in the entire development process—from the initial idea and architecture design to a working, useful solution. I work across different areas of software development and choose technologies to fit the problem rather than fitting the problem to a particular stack.\u003c/p\u003e\n\u003cp\u003eMy projects include libraries, real-time APIs, database tools and automation for everyday development tasks. Whatever the area, I care about clear architecture, simple solutions and tools that solve a specific problem without unnecessary complexity.\u003c/p\u003e","title":"About"}]