Details
Joined devRant on 7/2/2016
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
God - this code is disgusting! Well, let me just try to change this one repo call to return an Optional...
"Hey! The app is broken! What did you do?!?!"
God dammit... -
Greatest bit of advice I ever received going into programming: "Engineers are people who look both ways at a one way intersection"6
-
The more I show up to the office to tackle impossible client demands, the more I realize that I am living in the world of The Expert.
https://youtu.be/BKorP55Aqvgundefined expert some with green ink 7 red lines and at least one in the form of a kitten some with transparent all strictly perpendicular1 -
I recently performed a huge refactoring effort on a Java project converting both the persistence and utility layers to Kotlin. Gotta say, I think I'm starting to fall in love with programming again!
Putting aside how pretty it is now, I've reduced those two layers by over 2400 lines of code -
"We need more test coverage!"
it("should test that function") {
subject.function();
expect(true).toBe(true);
}
Coverage goes up 30%
"Awesome! Now we're TDD!" -
The time that I felt most like a Dev badass was when I had introduced an E2E test framework and added a bunch of helper classes to it so that our QA team could pick it up and write automated tests for the manual tests they had been doing for years.
Sure, the whole department got laid off after that because we had gotten a new CTO and all of my work was essentially for naught, but it made a lot of people enjoy showing up to work for the first time in a long time, and that was what mattered most to me -
So I've decided to go about converting a Java project that I've been working on to Kotlin a little bit at a time. I started out with basic entity classes converting them to simple `data class`es in Kotlin.
Eventually, I got to my first beast of a class to refactor. This class had over 40 service classes depending on it, so even a little hiccup would throw everything into chaos.
I finish all of the changes on all of the dependent classes, update the tests, and the configurations (as necessary), and I was finally ready to spin up the app to test for any breaking changes I may have introduced...
Well - I broke everything! But I was sure I couldn't have! So what the hell happened?
Turns out that as I was building my project with a Gradle watch, at one point something failed to compile, which threw an unhandled exception in the gradle daemon that was never reported.
So when I tried to run my app, gradle would continually re-throw the error in the app I asked it to run...
After turning the daemon off and on again, the app worked like a charm.10 -
"Alright everyone, we can't keep this up. Every day our builds are breaking because of test failures."
"We could just be more diligent devs and actually write/update tests based on new behavior we introduce to the system?"
"What? No! We're just going to get rid of all tests!"
a few days later
"Guys!!! Everything's on fire now! How didn't we catch these huge breaking changes!"
https://media3.giphy.com/media/...2