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
![](/static/devrant/img/pipeless-devrant-banner-white.png)
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "gunpowder"
-
I noticed you can no longer uninstall Facebook apps from Samsung phones, only disable. Figured I would give 'disable' a try and see what it means. Apparently it means the icon will be gone but I will still get notifications, which I can click on the open the app. Whoever made this deal with Facebook should be fired from a mossy cannon using to much gunpowder.8
-
I'm finally writing unit tests consistently thanks to a simple file organization decision.
I'm not doing pure TDD, but at least I'm writing the tests immediately after writing a module, and I make sure they run ok.
What I'm doing is Instead of putting the test files in a "tests" dir at the root of the project, I have the tests right next to the source code.
So if I have a dog.x file, I also have a dog.test.x file next to it.
I'm not inventing gunpowder here. I've seen several people do this.
But it's something that is not generally made a default or advised to do.
Like I said; test frameworks in general go with the classic "tests" dir.
But for me this is day and night in whether I write the tests or not.
Which makes sense. Imagine the classic scenario of the "tests" dir, and you just created a file deep into a hierarchy, let's say src/lib/console/windows/dog.x
This means that if you want to write tests for that, you need to make sure the hierarchy tests/lib/console/windows/dog.test.x exists
If the test file already exists, but you want to access both files, you need to traverse deep for each.
Also, it's actually harder to keep track which files have unit tests and which do not.
Meanwhile, if the test files are next to the source, all these problems disappear.
That doesn't mean there are no other challenges with testing, like testing untestable things, like system calls or http requests, but there are ways to deal with that. -
Flask people
so I was given this old flask project, around 3k lines written in py2, the code is simply old and not refactored. So, it's pile of shit. Migrations completely botched as the original author created reference to live data in models.
Very strict line formatting resulting in backslashed ternary conditions.
Even saw manually formatted json responses... _line by line_.
My job is to clean this mess and eventually do as much as possible to freshen the whole project.
Currently just refucktoring the code as it's the only easy thing to do out of everything that could be done (it's still slow process).
Any tricks and tips? currently considering to try upgrading it to py3 but it feels like throwing gunpowder into already burning house.3