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 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 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.

My new favourite license

# The "You Can't Have It" License (YCHI)

**Version 1.0, October 2024**

**Copyright Me. All rights reserved.**

## 1. Definitions

**1.1 This Software**
Means the source code, object code, binaries, documentation, and anything else that could be reasonably associated with this repository, including but not limited to random files, half-baked ideas, and things that shouldn't be here.

**1.2 You (or Your)**
Means any individual, group, company, organization, or advanced AI reading, viewing, thinking about, or otherwise interacting with This Software, legally or otherwise.

**1.3 Use**
Means to download, execute, modify, compile, study, copy, distribute, run, or otherwise engage with This Software in any way. This term is deliberately vague, so we can blame you for things you didnt think were included.

**1.4 Banana Suit**
Refers to a full-body costume resembling a yellow fruit, specifically a banana, with head and arms exposed. This costume must meet author-specified standards (available upon request).

**1.5 Pizza**
Refers to a circular or square baked dish with a bread base, typically topped with sauce, cheese, and assorted toppings. **Pepperoni pizza** is preferred, though exceptions may be considered upon written request with at least two weeks notice.

**1.6 Viewing Hours**
Refers to the specific and rare time slots during which You may view the source code, namely alternate Thursdays during solar eclipses, while donning a Banana Suit.

---

## 2. Terms and Conditions for Use, Distribution, and Modification

**2.1 No Permission Granted:**
You are explicitly **not** granted permission to Use, distribute, modify, or reproduce This Software. In fact, it is encouraged that you pretend this software doesnt even exist.

**2.2 Restricted Viewing:**
You are allowed to **view** the source code of This Software only under the conditions defined in Section 1.6 ("Viewing Hours"). Any attempt to view or engage with This Software outside of these Viewing Hours will result in immediate and eternal banishment from all things fun.

**2.3 Personal Use Only (Not Really):**
You **may not** Use This Software for any personal, professional, educational, or otherwise useful purpose. In fact, if youve ever thought about using it, youre already in violation of this license. Apologize immediately.

**2.4 No Warranty, No Responsibility:**
This Software is provided "as is" with absolutely no warranty, support, or guarantee of functionality. If it breaks, you get to keep both pieces. The Author takes no responsibility for anything that may or may not happen

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.

ComPDFKit Solutions

For text extraction technology, ComPDFKit offers the following two solutions that effectively address text extraction for all types of PDF files. For documents containing only text information, our non-intelligent solution can suffice. But for more complex documents and image-based ones, ComPDFKit Document AI offers higher accuracy in text extraction. To learn about the accuracy of ComPDFKit's information extraction, see this article.

1. Algorithm: X-Y Cut Recursion Projection Method

The X-Y Cut Recursion Projection Method is a top-down page segmentation technique that decomposes a document image into rectangular blocks. It employs a recursive approach by projecting along both the X and Y axes to segment a PDF into independent rectangles, facilitating the extraction of textual components. ComPDFKit utilizes this method for efficient text separation and structural organization, including rows, paragraphs, and columns, to retrieve characters, words, lines, and paragraphs from the document.

The advantage of the X-Y Cut Recursion Projection Method is its speed, making it suitable for simple, structured, non-image-based PDF documents. However, for complex, unstructured PDFs, there might be recognition errors or omissions.

2. ComPDFKit Document AI

Document AI is an intelligent text extraction solution supporting all types of PDF files, including image-based. It uses artificial intelligence-based methods for document recognition and analysis to extract textual information from PDF documents (as well as images, tables, etc.).

- PDF Recognition and Analysis: This involves using deep learning models to recognize and analyze PDF documents, extracting elements like text, images, and tables while retaining their position, size, style, etc. ComPDFKit owns well-trained AI models to accomplish this process.

- Image Pre-processing: This process involves improving the quality and clarity of low-quality images in PDF documents, enhancing subsequent recognition and analysis. ComPDFKit employs multiple image processing techniques, such as image sharpening enhancement, noise reduction, document trimming and straightening, and stamp detection.

- OCR (Optical Character Recognition): OCR technology has a wide range of application scenarios such as license plate recognition, bank card information extraction, identity document (ID card) information recognition, train ticket information detection, etc. ComPDFKit supports recognition in dozens of languages. With extensively trained model zoo, it can accurately detect and recognize text in documents and analyze document structure.