Skip Navigation

  • This sounds more like a Github question.

  • Reading the manual? That's cheating!

  • I’m not sure you realize how “engineering disciplines” operate as crafts.

    From the comment you are replying to:

    [...] it’s not because what we do doesn’t have an element of craft in it, it’s because the concept of craftsmanship is not enough to explain what we do.


    these comments on “operate like an engineering discipline” are mostly sourced from a cargo cult mentality

    I have nothing to say to this. Have a nice day.

  • I'm one of those who think this book is outdated (or at least needs an update remain a "must read" for people working on software). The blog post linked as a top level comments does a good job of pointing out some of the problems. That' not to say it's worthless, but if we are going to recommend books to newcomers, they should reflect the state of the art understanding of the field.

    It also reinforces this notion that software engineer has a craft component which really seems to rub some people the wrong way.

    When it comes to craftsmanship, I also oppose Uncle Bob. Again, it's not because what we do doesn't have an element of craft in it, it's because the concept of craftsmanship is not enough to explain what we do. Dave Farley does a great job of explaining the reasons in his conference talk: Taking Back “Software Engineering” – Craftsmanship is Insufficient • Dave Farley • GOTO 2022. We are not in the middle ages any longer, we need operate like an engineering discipline.

  • Apart from the historical value, the most important part of this article now is the "Note of reflection" added 10 years after it's inception:

    If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

    I don't think this work flow is relevant any more even for teams that don't do CD, to be honest. It was a messy work flow to begin with and I haven't seen it applied successfully in practice.

  • I think the developer basically killed the project. I'm not sure Moq can recover from this. I recommend everyone to move to NSubstitute as soon as possible. I suspect most of the migration can be done via Find/Replace.

  • We are publishing libraries (mostly client libraries). There are lots of legacy stuff. It's safer to own the whole feed instead of pushing it to nuget.org and hoping for the best :)

  • I also use Azure Devops + GitHub - What kind of integration are you looking for?

    Not really "looking for" it but what I meant was "pushing to GitHub packages from Azure Pipelines."

    If you’re using Azure as the build server, you can also publish your Nugets into a private feed in Azure

    That's what we do at the moment for private feeds.

  • If you are not using Azure Devops, GitHub Packages (as suggested by @nibblebit@programming.dev) can be worth looking into. They have a generous free tier.

  • Have you tried Github packages yet?

    No. Thank you for the suggestion. We use Azure Devops, but I would expect it to have good integration with GitHub. But creating a public project in Azure Devops may make more sense (so that all packages are in one place).

    [...] but what prevents you to use nuget.org?

    The only thing is possible name collisions. I didn't start looking into this, but it is a possibility. Otherwise I think we will end up doing this.

  • I believe there is already a browser add on for this. Cannot remember the name right now.

    Edit: I think this should be in Lemmy core.

  • I would add Ars Technica to that list and call it a day.

    For programming I follow YouTube channels of the conferences relevant for my tech stack (YouTube natively supports RSS). They are generally 1 hour talks but it's a great way to stay up to date.

  • Thanks for sharing. This looks really low level. The advantage of PlantUml and Mermaid is that they are supported by many systems. So, integration is a non-issue.

  • I agree that this is a challenge. One needs to slice the domain such that it can be covered this way. But this also means more people. In my experience, moving from "activity oriented" teams to "business centric" teams require an increase of the headcount.

  • Yeah, I don't know if it's a bug or a feature. I got a similar problem before with one of my posts. I think a workaround would be to post it as a link and paste the image in the Body.

  • -1 is what you get back from fork() when it fails. Normally, it returns a pid_t which is positive if you're the parent, or zero if you're the child.

    -1, when handed to kill() on Linux, means "target every process but myself and init". Therefore, when you take the return value from fork(), fail to check for an error, and later hand that value to kill(), you might just kill everything else on the machine.

    Great story.

  • In 2014 Robert Martin claimed that number of developers doubles every 5 years and says:

    As long as that growth curve continues there will not be enough teachers, role models, and leaders. It means that most software teams will remain relatively unguided, unsupervised, and inexperienced. [...] It means that the industry as a whole will remain dominated by novices, and exist in a state of perpetual immaturity.

    Not sure if the data can be confirmed or not, but if that's the case it will be difficult to maintain the best practices in our industry.

  • And because Windows and it’s eco system of applications he listed gets worse, he extrapolates this to all software.

    They admit that bias in the article:

    [...] since I've always been working in the Microsoft tech stack, I use a lot of it. Thus, selection bias clearly is at work here.

    Now, I mentioned free software as the exception. I don't have any data as to how big free software vs proprietary software. But I think his points extends at least to other proprietary software and is not limited to Windows.

    Some software get better, some get worse.

    I can agree with that.