Our great sponsors
- SonarLint - Clean code begins in your IDE with SonarLint
- ONLYOFFICE ONLYOFFICE Docs — document collaboration in your environment
- CodiumAI - TestGPT | Generating meaningful tests for busy devs
- InfluxDB - Access the most powerful time series database as a service
-
Mixxx <3
I don't use it myself. But it's good to see an open source solution in the DJ ecosystem. More and more DJ software go the monthly subscription route.
Oh BTW, if someone is bored: I think this library needs some RUST dev help: https://github.com/Holzhaus/rekordcrate/pull/71
-
-
SonarLint
Clean code begins in your IDE with SonarLint. Up your coding game and discover issues early. SonarLint is a free plugin that helps you find & fix bugs and security issues from the moment you start writing code. Install from your favorite IDE marketplace today.
-
> Some advices for a first timer?
Sure[0]:
* Send a proposal to strace. :)
Additionally:
(a) As others have mentioned, it's entirely normal to initially feel like one doesn't understand a new code-base of non-trivial size enough to modify it. One of the skills that participating in a programme like GSoC can provide is learning the tools & strategies that you can use to assist in growing your understanding of new code bases.[1]
(b) From an outside perspective, the fact you're aware of the existence of `strace`, have an interest in contributing to the project & have already poked around in the source code in an attempt to understand it are big positive indicators & differentiate you.
(c) That you're using a tool like `git blame` to assist in your exploration indicates that you've already learned some of the tools/strategies you can use which is also a positive. (As an aside, today I learned about the tool `git-dive` which is intended to be a more powerful form of `git blame`, you might be interested in checking it out: <https://github.com/gitext-rs/git-dive>)
(d) Also, with regard to `strace` specifically, you might gain some insight from this recent video: "strace feels like magic — let's fix that (with Rust)" <https://www.youtube.com/watch?v=engduNoI6DE>. While the video uses Rust for the implementation it also provides a general overview of how `strace` works. (This might be a useful intro to Rust syntax, if you're not currently familiar: <https://fasterthanli.me/articles/a-half-hour-to-learn-rust> (BTW, it is also extremely normal to not understand everything/anything about Rust code on first sight. :) ))
(e) Personally, in the past I've found it extremely easy to talk myself out of submitting proposals for opportunities such as this but my current perspective is: if I have doubts about whether or not I'm experienced/qualified enough to submit a proposal then I'm definitely not qualified to evaluate whether I should submit a proposal--so I definitely should submit a proposal to give those who are qualified the opportunity to evaluate it. (After all, if you don't currently maintain the `strace` project you have no idea what their experience has taught them is important in order for people to successfully contribute.)
Hope some of that is useful.
[0] re: "advices" -- in this context, "advice" is the preferred word[2]. I mention this as written communication is important & based on your previous HN comments this seems to be a pattern of incorrect pluralization rather than a typo. Note: I do not have perfect grammar. :)
[1] Also, I would encourage you to take notes of what you don't understand or issues you ran into when you start exploring a project. You can then document these hurdles/barriers to new contributors for the project so that maintainers are (at least) aware of them. This is one situation where your relative inexperience with a project is in itself valuable because your perspective is one maintainers no longer have. (And such hurdles are important to identify for projects that are actively looking to attract & nurture new contributors.)
