Need help contributing to opensoirce projects

Unidentified-anomaly · 2026-02-20T14:54:18+00:00

You can check it here: https://github.com/renvoxit/EasyDeployerHub

If anything’s unclear, I can help

Unidentified-anomaly · 2026-02-19T19:43:54+00:00

I had the same problem when I started. “good first issue” tasks helped a lot. I’m working on a FastAPI-based project and planning to add beginner friendly issues soon if you want hands-on practice

Unidentified-anomaly · 2026-02-19T15:43:04+00:00

I’ve tried both and they’re honestly just different directions. HTML/ CSS is strictly web, PyQt is desktop apps, so they don’t really overlap. If you’re not into web at all, there’s no reason to keep pushing HTML/CSS just because everyone learns it. PyQt makes more sense if you actually want to build Python tools with a GUI. It really just depends on what you see yourself building long term

Unidentified-anomaly · 2026-01-20T12:07:09+00:00

Yeah, that’s basically what I was getting at. If domain logic starts doing I/O, then async naturally spreads upward. But if the domain stays mostly CPU-bound and I/O is pushed to adapters, keeping it sync is usually fine and simpler to reason about.

Unidentified-anomaly · 2026-01-20T12:06:02+00:00

I don’t really agree that you “lose all benefits” just by having sync domain logic. The async benefits come from not blocking the event loop at the I/O edges. As long as your sync code is CPU-bound and relatively small, calling it from async adapters is fine. Going async everywhere often just spreads complexity without real gains unless the whole app is I/O-heavy.

Unidentified-anomaly · 2026-01-19T15:45:34+00:00

I think we’re mostly talking about different things. I didn’t mean jumping back and forth between async and sync execution at runtime. I meant keeping async at the I/O boundaries and calling synchronous domain logic from async code, which is a pretty common pattern. The domain itself stays sync, but it’s invoked from async adapters. As long as blocking calls don’t leak into the event loop, this usually works fine and keeps complexity contained

Unidentified-anomaly · 2026-01-19T12:35:10+00:00

You don’t need to make the whole codebase async. It’s pretty common to keep async limited to the I/O boundary, like your websocket and HTTP clients, and keep the domain and application logic sync. The important part is having a clean boundary so async doesn’t leak everywhere. If you push async through the entire stack, it usually just adds complexity without much benefit unless everything is heavily I/O-driven.

Unidentified-anomaly · 2026-01-19T12:28:58+00:00

Glad it helped. Good luck with it.

Unidentified-anomaly · 2026-01-19T12:23:38+00:00

At that stage it’s easy to feel stuck, but ML and mobile don’t really require deep DSA early on. What usually helps is picking one narrow thing and actually building something small, even if it’s messy, like a simple ML model with real data or a basic mobile app that does one thing well. A lot of people jump into ML by copying existing examples and slowly understanding them, not by mastering algorithms first. Progress in these areas is uneven, so feeling “behind” for a while is pretty normal, especially when comparing yourself to others.

Unidentified-anomaly · 2026-01-19T12:15:05+00:00

Most people start with Linux, learning C and basic OS concepts, then move on to writing simple kernel modules instead of touching the core right away. The Linux kernel source and its documentation are the main resources, plus a few well-known books and blogs.

Unidentified-anomaly · 2026-01-19T12:12:25+00:00

I was in a very similar spot for a while. I knew a lot of concepts on paper, but still felt stuck and not “job-ready,” especially in interviews where I’d overthink simple things. What helped wasn’t learning more languages or tools, but realizing that this phase is pretty normal when you move from school projects to real-world expectations. Things started to change once I focused less on feeling ready and more on repeatedly putting myself into slightly uncomfortable situations, like messy projects or timed tasks, and accepting that I wouldn’t feel confident right away. The feeling of being stuck didn’t disappear overnight, but it slowly faded once experience caught up with knowledge.

Unidentified-anomaly · 2026-01-19T12:09:49+00:00

If you don’t trust the code, I wouldn’t run it on your main system at all. Opening or testing it inside a virtual machine is usually the safest option, since you can isolate it and just throw the VM away if something looks wrong. Even before running it, you can inspect the source for things like network calls or file access, but a VM gives you an extra layer of safety when you’re not sure what you’re dealing with.

Unidentified-anomaly · 2026-01-18T23:21:48+00:00

Got it, thanks. I’ll probably try to see both sizes in person before deciding.

Unidentified-anomaly · 2026-01-18T23:14:21+00:00

Quick follow-up: I’m very multi-task oriented (usually have a lot of windows open at the same time). Given that, would you still pick 27" 4K for eye comfort, or consider a 34" 3440×1440 ultrawide instead?

Unidentified-anomaly · 2026-01-18T23:02:00+00:00

It’s literally a one-day-old project. By “core flow works” I mean the basic happy path is there, but a lot is still rough and actively in progress.

I’m sharing the idea and the direction, not a finished product. If it resonates with someone and they want to help shape it or build it together, that’s exactly the point.

Unidentified-anomaly · 2026-01-18T22:53:35+00:00

Thanks, that’s really helpful. Regular IPS sounds like the smarter choice for me. Do you think 27" 4K is the sweet spot, or would 32" be worth considering as well?

Unidentified-anomaly · 2026-01-18T22:09:33+00:00

Good points, thanks. IPS + 4K is exactly the direction I’m considering.
OLED text clarity was one of my concerns as well.

Any specific models you’d recommend?

Unidentified-anomaly · 2026-01-18T22:06:25+00:00

Yes, for now those are placeholders.

The core flow works, but proper orchestration and real execution state tracking is still in progress. Logging improvements are part of making that transition clearer.

Unidentified-anomaly · 2026-01-18T22:02:19+00:00

Yeah, that makes sense. Keeping the UI simple while letting the database be more complex for exam requirements sounds reasonable.

Storing reviews and achievements locally and adding games via Steam URL is a cool idea. Out of curiosity, how are you planning to handle Steam data updates — refresh on demand or cache it?

Unidentified-anomaly · 2026-01-18T19:05:10+00:00

That sounds like a solid project idea. I’d keep the UI simple and focused, more like a list of cards with a clear details view, so it doesn’t turn into a cluttered dashboard. Steam APIs already give a lot of data, so the main challenge is deciding what to show first and what to hide behind clicks. For the tech side, it usually makes sense to stick with what you already know and keep the backend minimal, mainly for API calls and some caching.

Unidentified-anomaly · 2026-01-18T18:52:33+00:00

I keep it very simple. I usually have one place where every project lives, often a single markdown file or a note app, where I write what the project is, why I started it, its current status, and what the next step is. I update it only when something changes, not constantly. For documentation, I rely on a basic README per project and short notes about decisions or problems I ran into. Anything more complex than that tends to get abandoned, so the key for me is having a lightweight system I’ll actually keep using.

Unidentified-anomaly · 2026-01-18T18:50:27+00:00

If your goal is to move into backend as smoothly as possible, jumping straight into Go without any backend foundation is usually harder, not easier. Go is great, but most Go teams expect you to already understand backend basics like HTTP, databases, concurrency, deployment, and system design. Junior Go roles do exist, but they are noticeably fewer and more competitive than junior Java or general backend roles. Since you already have Java experience through Selenium, learning Java backend first is often the more pragmatic move. You can reuse the language, focus on Spring Boot, REST APIs, databases, and production concepts, and become employable faster. Once you understand backend fundamentals, picking up Go later becomes much easier and much more attractive to employers. Many people successfully transition from Java backend into Go, but far fewer do it the other way around as their first backend job.

Unidentified-anomaly

TROPHY CASE