Sprints aren’t for you, it’s for the higher ups to have a digestible view of what’s going on in the team by presenting work done over 2-3 weeks, calibrating budgets, etc.
As a dev, yeah, sprints feel restrictive and artificial as fuck lol
If you still do the sizing (it’s not entirely wasted as it’s a reasonably effective tool to gauge understanding across the team), This can still be done without the artificial time boxing.
“How much work have we done in the last two weeks?” Just look at all the stories closed in the last two weeks. Easy.
“When will X be delivered?” Look at X and all its dependencies, add up all the points, and guesstimate the time equivalence.
Kanban isn’t a free for all, you still need structure and some planning. But you take most of that away from the do-ers and let them do what they do best… do.
I prefer V-cycle for when you have a software with known specs & Kanban for when you don’t really know what the client needs/wants. I mean those magic clients you hear about but never sees…
What happen when the repository is getting forked? Goofing with the license is all haha fun till nasty lawyers get into the picture and you get all sort of liability claims
Ofcourse its legally binding. If you include a license text with your own code on a platform that doesnt have a clause to license your code under different terms, then that license is legally valid.
But writing the license yourself without making sure that it doesnt allow for any legal loopholes is a bad idea.
Go is like that abusive partner that gives you flowers and the next day makes you feel like shit. Then another day you go to an expensive restaurant and you tell yourself that maybe it’s not so bad and they still care. And the cycle continues.
Rust is an autistic partner that sometimes struggles with telling you how much they care, is often overly pedantic about technical correctness and easily gets sidetracked by details, but with some genuine effort from both sides it’s very much a workable relationship.
With some sprinkle of libraries such as anyhow and thiserror the Rust errors become actually pleasant to use. The vanilla way is indeed painful when you start handling more than one type of error at a time.
Exactly this. Anyhow makes error handling in rust actually a joy. It’s only something you need to consider if you’re writing a library for others to use, and in that case, it’s good that rust forces you to be very very explicit
<span style="color:#323232;">const ret = try do_thing();
</span><span style="color:#323232;">
</span><span style="color:#323232;">if( ret ) | result | {
</span><span style="color:#323232;"> do_something_with_result(result);
</span><span style="color:#323232;">}
</span>
The try keyword returns any error up; the if-unwrap works with what came out of a successful call. Normally you wouldn’t have both, of course.
do_thing would be defined as a union of an error (a distinct kind of type, so it can be reasoned about with try, catch and unwrapping) and the wrapped return value.
I actually reasonably like Go. It’s simple and pragmatic but I fucking loathe its error handling. To me it just replicates one of the worst features of C
I think I’d rather code in Go than Rust. But I’m not a great Rust programmer so my opinion may not count. I can code effectively in C, C++, Go, Java, C#, Python, and a few others, but Rust is the only language that I find hard to use. I’m probably just dumb
Yes, I was using Rustrover the last time I used Rust. VSCode previously. I’ve tried to get into Rust a few times and really just failed repeatedly. Ill probably try again at some point but my experience thus far hasn’t been great
You’re not dumb. Rust is a hard language to pick. Some people probably think I’m mocking it because I made this meme but I’m really not - I love Rust. I’m mocking us mere humans trying to cope with greatness 🤣And I’m looking forward to the time when I finally “graduate” and become more productive and experienced with Rust.
And OOP in general. I also used to be infamous for such things, then I started to shorten the names, including using letters that are obvious to the user (e.g. int w, h; for width and height).
I’m not exactly sure what you mean. Doesn’t all dependency injection work the way I described?
Without being familiar with the framework, you can’t trace your way from the class getting injected into to the configuration, even if you’re experienced with the language.
I don’t think so. When I’ve seen it done it’s usually not been random values injected (except when those values are secret keys which should absolutely not be stored in code to begin with), it’s usually injecting a service. Another class, usually with a name that makes it easy to trace down. Like if you’re building an OrderService, that might take as a dependency an IProductService, which would have injected into it the class ProductService (personally, I don’t like the Hungarian notation that C# uses, but it’s a convention and my preference for sticking to strong conventions for the sake of consistency outweighs my distaste for Hungarian notation). That’s easy to find, and in fact your IDE can probably take you straight to it from the OrderService’s constructor.
It’s easy to imagine a hypothetical way that could lead to problems. But in all the code I’ve worked with, either that scenario is avoided entirely, or other context makes it absolutely clear which IProductService is being used.
programmer_humor
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.