Day 4 - 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!

I had a horrible exception when my Spring Boot application was starting. Finally I searched for it and disabled a feature I didn’t needed that was causing the exception. Weee!

1 Like

For “warnings” are not very common in database development I used the time to fix a number of unit-tests which were always failing on local development machines due to problems with local installation.
I think that’s a bit similar to warnings - you know the tests work because you didn’t change anything in a long time on that module, but learning to ignore failing tests is not a good habit :slight_smile:

2 Likes

We have some deprecation warning triggered only in test… it’s from a backward compatibility code written during some data migration that we did quite a while ago… the warning was put so that everyone on the team would know to not use the old database column, while we are working on finishing the migration process…

For some reason that we didn’t really spend time to investigate, this warning was triggered in multiple places when running our test suite even though we didn’t see any in our production logs…

Hence, with this exercise we finally remove the whole backward compatibility routine and the warning was gone… :tada:

1 Like

One of our tests had an error that occurred 5 times in a row about a group of files that were unable to be copied. I had a feeling it had to do with our usage of paperclip and stubbing something incorrectly, so this challenge got me to:

  1. figure out which test was actually causing the error (which ended up being a pain)
  2. figure out why the test was having the problem it had
  3. understand what all we needed to do to stub the attachment correctly

Now we won’t have a wall of text in the tests, but just green dots all the way :slight_smile: (through that section at least… next up: no_proxy via a dependency’s dependency)

Bumped the runtime.txt used by Heroku from python-2.7.14 to python-2.7.15 since it was using that anyway, installed psycopg2-binary instead of psycopg2, followed the directions of a deprication warning in Django 1.9 (we are on 1.8, soon to upgrade to 1.11), but was blocked from fixing the last warning on app startup because a dependency is not being maintained and there are deprication warnings! Alas. Definitely quieter now than it was.

In one of our repos which uses Python, we install some packages via a requirements.txt but are getting a warning:

boto3 1.4.4 has requirement botocore<1.6.0,>=1.5.0, but you'll have botocore 1.6.8 which is incompatible.

I wanted to address this, but as it turns out, currently PyYAML (one of the packages the project depends on) is broken in Python 3.7 (which was released last week) on Mac if you install Python by Homebrew, see: https://github.com/yaml/pyyaml/issues/152

I tried to get a version of Python 3.6 installed, but this is actually not possible via homebrew, see:



I started down the suggested “use pyenv” path, but didn’t even get 3.7 installed (I tried the command, and it appeared to hang & didn’t have time to wait for it to finish).

As such this ended up being a bit of a bust for me. :frowning:

I work in Toad for Oracle - Base Edition, which has a fraction of the features that Professional Edition and above has. Professional Edition has automated code reviews, so PL/SQL compiler warnings come with. Base Edition doesn’t have that and if I want to see PL/SQL compiler warnings, I have to execute an ALTER SESSION to turn that on every time I login. SQLDeveloper has a way to turn this on automatically in Preferences. I downloaded and installed SQLDeveloper, turned on ENABLE:ALL in PL/SQL Compiler, and compiled one of my latest packages. I got a few warnings, fixed them, re-compiled, and the warnings went away.

1 Like

I just fixed around 20 TypeScript warnings/ errors and now can remove the | echo "TS errors ignored" from my build script :sweat_smile:

So satisfying! Well done.

1 Like

Also great move to try out SQLDeveloper! It evolved greatly during the last years. Jeff Smith would like that :smiley:

I fixed a handful of PyLint errors and warnings, some of which were genuine bugs.

1 Like

I finally took the time to update some gems that were causing warnings in the test suite. I have no idea why I never took the time to do this before as it only took a few minutes.

I fixed a warning in my jest frontend test suite, which had appeared after an upgrade of one of the test-related dependencies a while ago. In particular, jsdom doesn’t implement window.scrollTo, so one of my React component tests that uses scrollTo was throwing the warning.

Fixed like so: https://github.com/WikiEducationFoundation/WikiEduDashboard/commit/3f3fae70937de24b718b1bf9ad8e232773311e22

I think this actually was an accidental bug but removed a deprecation warning where we were passing in an active record instance to ActiveRecord::Base.find instead of an id!

I found a warning caused by outdated cucumber-rails gem. So I have killed two birds with one stone - removed warnings and updated gem :slight_smile:

Fixed a module.function is not defined (module is unavailable) warning due to defining a test mock in a test_helper.exs file instead of a normal elixir file that would be defined at compile time.

This happens to be the second time working with this library (Mox) that I’ve figured out an issue, went to see if I could submit a PR to its documentation, just to find that it was documented the whole time :sweat_smile:

When running seeded tests. removed warning from forwardable.rb “forwarding to private method”. Made methods public.