Also, stack trace should show you everything you need to know to fix this, or am I missing something? (no experience with Ruby)
Otherwise, I see the cleanups and refactoring as part of normal development process. There is no need to put such tasks in Jira - they must be done as preparation for the regular tasks. I can imagine that some companies take agile too seriously and want to micromanage every little task, but I guess lack of time for refactoring is not the biggest problem.
"why don't you just" comments are easy :) (I made one)
debugging in codebases with a lot of magic (rails) is hard. it can be very difficult to follow calls around unless you're quite the expert. certain styles of programming really frustrate me, but then again I program like a scientist so the kinds of things I'm prone to do frustrate software engineers (for loops nested 8 deep, preference for single character variables, etc.)
You’re spot-on with the “magic” of Rails. While it can be very powerful and feature-rich, it can feel like a black box at times and stack traces aren’t always accurate or helpful. To be fair, this happens with a lot of library-heavy frameworks though, Spring Boot being a prime example of this.
> This has the unfortunate side effect that if it drops and no one adjusts the threshold then people can add more issues without failing the build.
Our tests are often written with a list of known exceptions. However, such tests also fail if an exception is no longer needed - with a congratulatory message and a notice that this exception should be removed from the list. This ensures that the list gets shorter and shorter.
I use it to get the keywords and ideas, then use the normal search engine to get the facts. Still, even in this limited capacity I find the LLMs very useful.
GDPR says no. Also, when you are using a cloud service it is no longer private use, you are sharing the surveillance video with Amazon (and almost certainly with the USA three-letter agencies) too.
Not necessarily. The clear language would help consumers determine what they are getting out of the transaction. Many could decide it is not worth it or would search for a better deal elsewhere (where they could buy the book, not just rent it). I'm sure Amazon would come up with new ways to combat this though.
holy shit. it really is the end, isn't it? cut the company into pieces and sell to the highest bidder. three letter agencies would be interested... a couple months ago.
To be fair, they are elected by shareholders, so it does make sense to prioritize shareholders.
But with a company like Intel, one does really need long term vision to maximize value in the long run. We don't know if he's looking for quick fixes (short term) or long term fixes.
He's been on the board that hired the last 3 CEOs, so I have little faith in their getting things right.
Intel started having issues before pat. Now, I sold my amd shares a few years ago and stopped following the semi sector, but as long as I have memory Intel was starting to show cracks after a few ryzen iteration(s). I mean, they were still faring well, but it was clear - at least to me - they were stuck with less competitive products
They missed two epochal changes in the semiconductor industry - mobile and AI/GPU. They don't have a contract foundry business that could compete with TSMC. They appear to be failing with the thing the originally should have been capable of, their next gen chips.
When they missed out on mobile it appeared to be a big blunder, especially when one considers the long term impact of electricity usage in datacenters. When Apple released the M1 chips that could run x86 faster than native, it was clear what was going to happen to Intel. Intel is now done -- dead, finished. This is a legacy business where the owners can try to get more money than they paid for it, but if they have to put up new capital (that isn't free government money), they will not be getting their money back.
AMD was at a very similar spot a decade ago. It took time, pain and faith, but they turned it around. Intel could very well do the same, but its Lisa Su has just got fired a few months before the plan started sprouting.
It's not one or the other though - a bit of safeguards here and there would make you even more productive, imho. Code reviews are indispensable for sharing knowledge within a team, automated deployments help deliver the system reliably and without unplanned downtime, and tests... People start appreciating tests when the red lights warn them about breakages in some completely unrelated places that they didn't even think were affected by what they did. And I'm not talking about 100% coverage - even covering just some of the trickier, but important flows helps immensely.
I don't disagree generally, and in fact we're starting to build those safeguards where I am ;)
Having said that process and bureaucracy is still what they are and they tend to eat up more cycles as time goes on, even if only because they're administered by humans.
Sure. Of course you can't commit to the main branch and your commit will never pass code review (which is a requirement for merging), let alone the automated tests in CI that apply formatting and fail if anything is not formatted as it should be.
These safeguards save so much time that there should be no excuse for not having them.
Not wanting pipelines to fail because someone put an extra space after the line, or because someone's text editor didn't put a new line at EOF, or put a unicode BOM or whatever is a pretty good reason not to have this "safeguard".
reply