Day 3 - Get rid of a warning

Today’s exercise: get rid of a warning you’ve gotten used to ignoring.

Chances are, your code prints at least one warning during one of the following:

  • Booting your code
  • Running your tests
  • Installing dependencies
  • Deploying your app

These warnings are easy to learn to ignore with time, but there are two problems with that:

  1. Many warnings (like a deprecation warning) will turn into full-blown issues later on. This will tend to happen at inconvenient times.
  2. They act as a “broken window”: an indication that your codebase isn’t receiving the fastidious love and care it needs. These small messes quietly demonstrate to your team that messes are tolerated, and can often result in more. (More on “broken windows” https://blog.codinghorror.com/the-broken-window-theory/ )

So, today’s task is to try to nuke at least one warning.

If you boot your app, run your tests, install your dependencies, and deploy with no warnings, congrats! Enjoy your day off.

Otherwise, see if you can eliminate a broken window.

Good luck!

2 Likes

Good morning!

I took a stab at fixing some warnings about slow tests in our test suite.
It was inserting a lot of test data in the database. After having mocked all that data in memory… it still warned me about the test being slow. A bit frustrating, but I was well over 20 minutes, so I’ll save this for another time.

See you tomorrow!

1 Like

I picked a random project and found no warnings during the tests and deployment :tada:

1 Like

Only errors I had were from installing node_modules fresh. I went down a rabbit hole to later conclude it’s impossible to get rid of the warnings (peer dependancies) as some packages in my package.json are simply not (yet) compatible with the packages suggested in the warnings.

Also most packages I had to install had new peer dependancies them self, leading up to having 20% more packages just to get rid of the warnings. With some looking up on the internet it seems fine to have those peer dependancy warnings. Project also runs fine so I reverted to how it was :slight_smile:

I didn’t find any warning (that I can fix). But while searching, I stumbled upon a test that sometimes breaks for no reason and fixed that instead. I guess that counts? :smiley:

Did not find any warnings, so I guess its a day off :slight_smile:

My team mate recently cleaned up all our build time warnings so I tried to fix an obscure runtime warning. I didn’t manage to find a solution within the 20 minutes though :-1:

Most of our warnings are related to having to upgrade to Rails 6 (will take more than 20 minutes :joy:) but I found a “low-hanging” fruit where I had to upgrade the faraday_middleware gem as well as another gem that was locking its version.

Within the allocated 20 minutes I made a PR with CI status checks passing.

yeah, a day off :slightly_smiling_face: I am looking forward to tomorrow.

As a result of handling some linting warnings and errors, I have setup our CI to abort on warnings… Hopefully that will avoid broken glass :clap:

No warnings for me, as Golang is quite strict with gofmt on compile. I have been toying for a while with golangci-lint so I decided to spend this 20 minutes to configure it as a GitHub action that runs on Pull Requests.

It wasn’t 20 minutes but in a little under one hour I had it working and the few warnings that came with it were clean. Yay improvements!

Good morning!

Got rid of a warning that crept up during a dependabot PR.

Ended up improving on another PR on that project as well :rocket:

god these javascript errors are all over the place :joy:
overall a very exhausting task

Looking forward to the next day!

Got rid of SASS warning !global assignments won't be able to declare new variables in future versions.
So no more plenty of output while recompiling. Small win.

The other month I was refactoring some code and decided to a) switch method names to a more conscise ones b) keep old method names as an aliases and c) use ActiveSupport::Deprecation with ‘in a future’ disclaimer to prevent others from using old interface.
But I also kept specs for old names, so our test output showed the deprecation warning.

Today, the future has arrived. Dropped the aliases, the deprecator and specs for old interface.

Same thing that @nckrtl ! I use to try to fix them but it requires more dependencies and go on… The real rabbit hole trap !
I guess it’s an never ending task. :slight_smile:

1 Like

I added linters to my linter check and removed deadcode warnings

Well, I did not manage to find any warning in our code. We have already developed a habbit of resolving warnings soon - mostly yaml complaining about safe_load as recommended method. And last time warning, that postgres is becoming obsolete in db_url and we should use full name postgresql://....

Anyway, I have found one “broken window” in a utility syncing config files where rsync hanged in some cases. So I tried to fix that (it ended with extra README instruction to do some manual steps).

Hello everyone,

I am working an a Swift project. Luckily, there is a tool SwiftLint. We can find warnings easily. I try to nuke the warnings as best as I can.

Fixed a warning we had on an app when booted locally it warned about the database seeds being out of sync (kind of a false positive) which had to do with a custom migrate command we ran when developing locally. Got rid of it with a conditional to check if (re-)applying seeds is necessary.

Nice reminder, thanks! :smiley: