Day 3 - Get rid of a warning

All the warnings I found turned out to be from upstream dependencies :frowning: so not much I can do there. Hopefully Laravel will update the math dependencies soon :crossed_fingers:

I’m actually surprised but I didn’t have any warnings. Guess I have a day off!

2 of the gems in my project were outdated and had to be updated to get rid of the warnings!

Fixed a small broken window this morning by removing a notice in the logs about an undefined variable!!

removed a deprecation warning from Tailwind :slight_smile:
opting in to the change

Where there is smoke there is fire.

Warnings elimination is a pet project of mine. I’m fortunate to have a splunk license which has the wonderful ‘typelearner’ command which finds the ‘kinds of log messages’ and I have it send me a monthly list of all the kinds of warnings across all my applications which I try to work through.

So no new warnings today. A pile of unknown routes, and failed logins, which is expected user behavior. (I do keep an eye on the volume of those two).

Created a PR to handle 3-4 red console warnings that show up when running the code.


I found no warnings at my code, however I got a warning from a 3rd party package. I investigated a little and noticed that there is already an open issue at GitHub.

So many warnings! We have a lot of modules in our project, and I’m investigating a way to enforce warnings as errors per module so we can tackle them iteratively.

In the process of upgrading from Ruby 2.6 to Ruby 2.7 so took this time to fix the warnings related to that. Also looked at one of my open source projects to fix some dependabot warnings. Cheers! :rocket:

Late to the game today. The day was filled with technical writing, quite intense, so I didn’t have time to get to the daily task until now.

An warning from clang (double-quoted include "someheaderhere.h" in framework header, expected angle-bracketed instead) on one of our frameworks heeded! Yay!

Crunched for time, so I resolved something small– a linter warning in a test. My project’s test suite has many so-called ‘useless assignments.’ They are a symptom of copy-paste, and they waste developer time because you have to read and think about each one. A small win!

I checked for warnings and couldn’t find any warning in my repo.

I have a Swift project and I use SwiftLint for code consistency and so fixed a bunch of error related to inconsistent code formatting.

I took the time to tune my linter config (rubocop) to avoid unneeded warnings in my editor. I was ignoring them and other important warnings.

We have warning when booting up puma that rufus-scheduler is starting a thread in app boot… which leads to the realization that the scheduled taks might not be running as expected… more investigation needed, but for now, I’ve filed it in the issue tracker…

I forgot to log this yesterday—I started fixing warnings related to old usage of should and stub in a Rails/RSpec test suite. I made a little headway in 20 minutes, but removing all the deprecated syntax will take longer. Added to my to-do list.

We had spring running in production, which produced a warning when booting up. I moved it to it’s correct group in the Gemfile, and the warning is gone now

Bit late, but did this today on a public repo owned by my former employer (LOL). There were a bunch of markdownlint warnings in the Readme, so I fixed them & opened a PR: Address some markdownlint warnings in README by pzelnip · Pull Request #13 · bambora-na/ · GitHub

I pay pretty close attention to getting rid of warnings. I’ve been observing a different project each day and finally found a warning today. I have an older project deployed to Heroku – with 2 warnings. No Procfile, and Your Ruby (2.6.2) has a bundler bug.

The Procfile is not a giant deal since Rails now uses Puma by default (instead of webrick). Added Procfile.

Upgrading the Ruby version took more than 20 minutes but most unattended. No more warnings.