This one was easy for me; my team makes it a point to resolve all warnings before merging code. Our philosophy is, today’s warning is tomorrow’s 500 error.
3 Likes
This was nice…
I started with a warning in my console when I start guard, about how I ought to use bundle exec guard instead. I changed .bashrc to now my habit of typing ‘guard’ will actually do bundle exec guard.
Then I squashed some ignored errors related to bootsnap that were happening during deployment (which I documented here.
And then I made some progress removing some of the deprecation warnings in React that are blocking the upgrade to React 16. It’s a long road to clear out all the old Flux stores and replace them with Redux, but starting from the first warning and just trying to get rid of it turned out to be a good strategy today.
I take this 20 minutes to solve warnings and pitfalls in the package install for the application and the deploy system.
I was happy about see changes in the app that I had almost dead, so I take another 20 minutes to put some linters to locate bad practices. Now I have more fix in my todo list, related to this.
I loved the link to additional reading material good stuff!!
I already cleaned most of my compilation (C code) and only had one warning that had to do with a compiler open issue. I used these 20 minutes to finally dig online and find how to suppress this warning for this specific compiler bug and I’m finally at 0 warnings! yeah 
1 Like
I fixed a permissions warning which only affected our development builds. Still plenty of warnings (both compiler and runtime) to go, but it’s a good start.
1 Like
Not sure this will count 
but only warning we had… I created an issue for it yesterday and now we’ve a PR that solves it (although seems like solution pops other warnings) https://github.com/consul/consul/issues/2287
1 Like
Nice work all 
Got a late start (I have the flu 
), but managed to tackle the last and most persistent warning in our rspec suite. Nothin’ but green dots!
4 Likes
That was an easy one. Guess I owe that to my OCD when I see any sort of warning on the test suite or so
This was an easy win I really got a kick out of! Our code base hada handful of warnings before any rails or rspec commands, so I cleaned those up first.
That led me to want to get our Rspec output cleaner, so I went through and removed all the text that was printing while tests ran. A few of our former devs liked to feel like this tests were “talking to them”, so there were whole blocks of puts calls that were cluttering our output. It was such a good feeling to see that output finally back to green dots, instead of line after line of silly dialogue! 
I really like the concept of warnings as a “broken window” in our code. It feels good to have things at a clean baseline. This should make it easy to keep that way - people will notice if a new warning shows up, now, instead of just lumping them all together visually and ignoring them. Huzzah!
I knew there was something specific to my environment (vs. a pairing station that I do a chunk of my development on) which was causing rspec to yell only on my laptop. This finally gave me the excuse to do the research I never thought I cared enough to do. And now my tests can run without complaining right off the bat!
Ember builds were throwing a few warnings when booting the app because of a few out of date packages and untranslated strings.
These strings were mostly translated by a teammate, I took care of the last one and got rid of a postcss warning and another warning from an out of date package. Finally, took care of some deoptimization warnings when I trimmed down the size of another file (though this happened by luck )
Now the only warnings thrown on boot are by the app build process which is much more involved, but next up to go
1 Like
We had one warning when booting up our node app in the dev environment.
(node:86610) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
Currently on node 8 so this doesn’t crash the process, but in the future when trying to upgrade node this would have cause our dev app to not boot up.
This was always something in the back of my mind, feels great to finally squash this!
Hi guys and gals,
I’m a little late to the party because in my case 20 minutes wasn’t enough. What do you guys do when the warning that you want to remove depends on a specific version of Ruby? Will you upgrade your application to use that version? Taking into account that this change will also impact production environments. Let me know your thoughts on this.
Thanks,
Depends on the warning, and which Ruby you’re running in production, and how hard it would be to switch in production.
Upgrading the production Ruby version is probably a task you’ll need to do multiple times over the years, so it’s probably worth documenting the process and any gotchas that come up the first time you do it.
That’s what I did for the previous time, and when I just switched my app to Ruby 2.5 after Christmas (not necessarily a best practice, upgrading before the x.x.1 release) that documentation was super useful, and led to a smooth upgrade process.
IMO, a warning that relates to your Ruby version is definitely one you want to pay attention to, at least in terms of making sure your app could upgrade Ruby if necessary.
1 Like