I've ran into Drone CI about a year ago and I like it. I wanted to self-host something simple next to my gitea instance, and after a few hours I had it mostly set up. And in the course of a week I had it all figured out, I don't bother with it any more.
It's basically hands-free operation the way I have it set up, works with my gitea as said so I'm happy.
I've been meaning to get the ansible thing. Not for my home computers, my dotfiles are on GitHub, SSH keys offline, stuff backed up. But I always think that if my poor hetzner box dies, I'll have a lot of fun getting it all back up :/
Absolutely, especially si if you don't have a background in software development. Operations tasks a typical "DevOps engineer" does can help you understand the big picture, the concept of a server or service or a batch job. Configurations , environment, initialization, logging, integrations. It will introduce you to a lot of failure points - network problems, load problems, balancing problems etc.even some domain language - what's this or that service for, what is it doing, for whom. The usual way to come to backend is e.g. from school with very little of such experiences. You would come with all these ideas already as known problems. You would also learn a lot of the dev process, team work, documenting how to run something. You'll pick up basics of programming through bash and python and similar scripts. Even read some "proper" code once in a while.
After a while when you get settled, you'll learn a programming language on the side. But you'll only learn the syntax, standard library, idiomatic ways to loop or something. The problems to solve - which IMHO is often a weak point of many trainings and tutorials - will be a known thing to you, not abstract made up ideas.
So yes, you can use the DevOps role experience in your future work as a backend developer.
No, I only saw it later. I wish I made it either more skewed or straighten it up.
This is not post-processed though, SOOC.
I sometimes upload photos to my Pixelfed account. I also participate in the 52frames.com weekly challenge, so I frequently post there as well.
But recently I also started posting to my own dedicated photo site. It's ... more meaningful to me, and I can share the posts with some community (52frames mentioned above has an active Discord server, also "Focal Point with C. London" as well).
A note on my own site: I'm a techie and tend to obsess about loading times and static site generators and all that - so I end up with a typical software developer's blog - blogging about how to setup the blog itself. So for this thing I said, "I don't care about performance, SEO, anything. I'll just post photos".
So if you plan to do something like that, I suggest just going for it. Just pick a platform and start posting. After a time, you'll figure out what you want to do, in which direction to move, so can adjust later. But just getting started should be easy, and it motivates you a lot.
I wanted to suggest something like this. Code-freeze wise, you can have a "minor" and "major" problems, major problems block the feature, minor ones let it go (but you now have a tech debt, and make sure that THIS process to fixing up found issues is higher-prio then new features). Of course, you decide what is minor and what major. E.g. maybe a typo in the UI is acceptable, maybe not.
As for throwing features over the wall - I would actually suggest just changing the perspective - make QA involved earlier. The feature is not ready and not frozen unless it's been looked at by QA. Then when a thing is frozen, it's really ready. (Of course you'll still have regressions etc but that's another topic.)
I think it is a bit more than that.
You point out two things:
So, now, obviously if you wrote the "fuck it", then well, you fix it. If you found the DNS library problem - find a better lib or something.
But if you take the stance "fuck it, there's always something", you don't even have a chance of finding out. If you had a test suite running 10 seconds, and suddenly it's up by 10 more, you would notice. If you had tests running for 10 minutes, you would not.
If you had a webapp or something that always opened "fast", then suddenly it gets doubly slower, you'll notice it. But if you already started slow, you won't notice (or care, or both), when it gets even worse.
I think that's the point of the article. If we all dug in and fixed a little bit, eventually we'd have fast apps or tests or whatever. If you accept that things suck, you'll make it tripply worse. It is a conscious effort to be fast.
Yeah, there was a bit of discussion about that on Lobsters :)
I agree, there are several good starting points. But I think it's more important what the OP said about his understanding of it. I think this is a lot more important - WHY do you use plugins, HOW they help you, WHAT can they do. Like, autoimport like vscode does? Autohighlight problems? Check. Check. Autofix linting issues? Check. Find files? Check. Search the project? Check. There's a lot of things that can make your experience way better. Look up some videos. E.g. this one (if you can ignore some twitch memes, I found them mostly fun or tolerable).
Also, when you give up on vim, come back again. It's something that can take many iterations to really "get". Even if things don't work out, try again in a few years.
Also, as an alternative to VSCode, try some native editor. I personally used sublime - for weak machines, it's way better on resources then VSCode and it's electron baggage.
It's not a monopoly, but it's still an oversized influence on the market. I think the poster is arguing that: when have you heard a recruiter ask you for your bitbucket account? But they will look at github.
I largely agree with this statement. I think the original question is very widely scoped. It's like asking, "what's the best tool for hammering nails, chopping wood, cutting wood, cutting glass, polishing floors, and building skyscrapers, and the tool is used by all builders anywhere and any time in the human history?" Different people, different skills, different problems.
One thing to add that I haven't seen is that for big projects, there's often nobody that could understand it all. People either get their individual components it they understand how stuff interacts, it's very rarely expected that new people in the project, even if very experienced, can just understand everything at once.
What you said that maintainers know every single fob is very frequently not the case at all! But since they get the big picture, they know in which part to look, and with their experience, they'll know what to look for in that part, it may seem to you like magic. It's not, it's just experience.
Don't get discouraged though!
Getting into big open source projects as a junior -level can be difficult, but often isn't that hard - a lot of projects often need help and will take anything they can get. And if your experience already partially aligns with what you're getting into, even better. If you reach out and be upfront about it, you'll usually get pointed in some way.
Now, you seem to only have worked on your own, with smaller code bases. That means, you don't have a problem of code organisation. So you can't understand a solution if you don't know what the problem is.
So how would you go about it?
My suggestion is to maybe get the. 10,000ft overview. Also, understand the project workflow. Projects usually have specific ways of doing things - how to build, test, run things. Try to figure out how to build and run the software on your own. If you make it, that's a great step!
Then dig into one specific component/module/part. After a bit of study, you may be able to understand that component and find a simple thing that you can change about it. If you get this far you're golden, you're doing more then a majority of users that software.
Now if you're interested, you can dig more, or reach out to devs, saying what your experience is and how far you got, and ask them if you can help. And take it from there.