I download a lot of different stuff all the time. Often times I don't actually get around to cleaning it up. Thus, I decided I needed to build a script to further encourage my bad habits.

Here I've built a script for both Windows and Linux. It's designed to take all the files in the current directory and move them into their own folders based on their extensions. Why is this useful?

It's fucking useful when you're not having to swim through fucking mountains of content.

Anyways without any further ado here are the scripts.

Linux

#!/bin/bash
for i in *.*; do
filename=$(basename -- "$i")
extension="${filename##*.}"
extension="$extension"files
mkdir "$extension"
mv "$i" "$extension"
done

Windows

@echo off
for %%i in (*.*) do (
if not exist %%~xifile md %%~xifile
)
for %%i in (*.*) do (
if "%%i" NEQ "movingFiles.bat" move "%%i" "%%~xifile"
)

As a Java developer, reasons to kill other programmers:

- static mutable variables
- WRITING to static mutable variables
- API call with Framework X didn't work. Add Framework Y along with X and try that. Wrap X in try/catch statement. Catch block fires framework Y.
- six, seven, ten levels of nested code. Zero thought put in organization
- 6K LOC Java files
- spring (singleton? Maybe) object assigning values in static mutable (see pt.1)
- a couple of unit tests in code base that no longer work. Zero unit tests in new code
- unit testing disabled in CI pipeline
- empty catch blocks
- pass mutable data between threads. Modify in various places concurrently.

You know what grinds my gears. Spaghetti code, bloated code base with 5000 line files, and poor file organization.

Seriously really pissing me off right now. Its like walking into a library and there's no shelves and the books are just thrown into massive piles.

I've spent so much time trying to figure shit out just to implement basic things. Its messing with my productivity and making me hate my job.

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.

My file structure:

Documents -
- That one impeccably structured folder that I never remember to put anything in

- Gigantic project folder that will some day kill me in my sleep

- That one unrelated folder that all of my non project scripts just end up in. No structure whatsoever

- about 2 billion loose files

I am scratching my head since 2 days cause a rather large Dockerfile doesn't work as expected.

CMD Execution just leads to "File not found".

Thanks, that's as useless as one ply toilet paper...

Whoever wrote the Dockerfile (not me…) should get an oscar...

Even in diarrhea after eating the good one day old extra hot china takeout from dubious sources I couldn't produce such a dumpster fire of bullshit.

The worst: The author thought layering helps - except it doesn't really, as it's a giant file with roughly 14 layers If I count correctly.

I just found out the problem...

The author thought it would be great to add the source files of the node project that should be built as a volume to docker... Which would work I guess....

Except that the author is a clueless chimp who thought at the same time seemingly that folder organization means to just pour everything into one folder....

Yeah. That fucker just shoved everything into one folder.

Yeeeeeesssssssss.

It looks like this:
source
docker-compose.mounts.yml
docker-compose.services.yml
docker-compose.yml
Dockerfile-development
Dockerfile-production
Dockerfile
several bash scripts
several TS / JS / config files
...

If you read the above.... Yes.
He went so far to copy the large Dockerfile 3 times to add development and production specific overrides.

I can only repeat what I said many times before: If you don't like doing stuff, ask for fucking help you moron.

-.-

*gooozfraba*

Anyways...

He directly mounts this source directory as a volume.

And then executes a shell script from this directory...

And before that shit was copied in the large gooozfraba Dockerfile into the volume.

Yeeeaaah.

We copy stuff inside the container, then we just mount on start the whole folder and overwrite the copied stuff.

*rolls eyes* which is completely obvious in this pit latrine of YML fuckery called Dockerfile.

As soon as I moved the start script outside the folder and don't have it running inside the folder that is mounted via volume, everything works.

Yeah.... Maybe one should seperate deployment from source files, runtime related stuff from build stuff.

*rolls eyes*

I really hate Docker sometimes. This is stuff that breaks easily for reasons, but you cannot see it unless you really grind your teeth and start manually tracing and debugging what the frigging fuck the maniac called author produced.

I continue to internally read and study about Smalltalk in an effort to see where we might have FUCKED UP and went backwards in terms of software engineering since I do not believe that complex source code based languages are the solution.

So I have Pharo. Nothin to complex really, everything is an object, yet, you do have room for building DSL's inside of it over a simple object model with no issue, the system browser can be opened across multiple screens (morph windows inside of a smalltalk system) for which you can edit you code in composable blocks with no issues. Blocks being a particular part of the language (think Ruby in more modern features) give ample room for functional programming. Thus far we have FP and OO (the original mind you) styles out in the open for development.

Your main code can be executed and instantly ALTER the live environment of a program as it is running, if what you are trying to do is stupid it won't affect the live instance, live programming is ahead of its time, and impressive, considering how old Smalltalk is. GUI applications can be given headless (this is also old in terms of how this shit was first distributed) So I can go ahead and package the virtual machine with the entire application into a folder, and distribute it agains't an organization "but why!!!! that package is 80+ mbs!") yeah cuz it carries the entire virtual machine, but go ahead and give it to the Mac user, or the Linux user, it will run, natively once it is clicked.

Server side applications run in similar fashion to php, in terms of lifecycles of request and how session storage is handled, this to me is interesting, no additional runtimes, drop it on a server, configure it properly and off you go, but this is common on other languages so really not that much of a point.

BUT if over a network a user is using your application and you change it and send that change over the network then the the change is damn near instant and fault tolerant due to the nature of the language.

Honestly, I don't know what went wrong or why we are not bringing this shit to the masses, the language was built for fucking kids, it was the first "y'all too stupid to get it, so here is simple" engine and we still said "nah fuck it, unlimited file system based programs, horrible build engines and {}; all over the place"

I am now writing a large budget managing application in Pharo Smalltalk which I want to go ahead and put to test soon at my institution. I do not have any issues thus far, other than my documentation help is literally "read the source code of the package system" which is easy as shit since it is already included inside. My scripts are small, my class hierarchies cover on themselves AND testing is part of the system. I honestly see no faults other than "well....fuck you I like opening vim and editing 300000000 files"

And honestly that is fine, my questions are: why is a paradigm that fits procedural, functional and OBVIOUSLY OO while including an all encompassing IDE NOT more famous, SELECTION is fine and other languages are a better fit, but why is such environment not more famous?

I think my worst trait is my lack of organization outside a work environment

I spent a few hours cleaning my old hard drives and I freed up 600GB of just duplicate files. Everything from driver backups and progam exe's to simple text documents

Most were in subfolders of a folder named some variation of 'sort_later' :/ oof

My homies really out here giving me three units to test spread out across two + four thirds of a file and expect me not to raise an eyebrow.

No, that is not three + one third. That would imply that the thirds all belong to one unit, or one file for that matter.