User: There’s a bug in the app

Dev: How do I reproduce it?

User: I don’t want it reproduced, I want it fixed!

Dev: …

Someone on a Facebook group asking how they can make a video auto-play with sound at maximum when a visitor hits the home page.

Me: Here’s how: Log into your site via SSH and cd to the docroot. Type “rm -rf” and hit Enter. Then throw your laptop in the river and go work at McDonald’s. Because if you are stupid enough to ask this question, you are too stupid to be allowed to own a website.

First day of college

- Enters the class

- Class starts

- Teacher starts teaching JS with notepad as editor on windows xp

- Leaves

Don't cry on weekends.

Cry on your workdays and get paid for it.

Don't let capitalism win.

I got an alert for a job and decided to apply for it.

First, it forced me to make a new account on their HR site. Strike one.

Second, it forced me to upload my resume to then make me re-construct my work history from scratch because these stupid resume import systems never get anything right. Strike two.

Third, it requires me to provide a PHONE NUMBER for EVERY employer I've ever had!? Over a 26-year career? When half those companies either no longer exist or the people I knew phone numbers for, and their phone numbers, are LONG GONE? Get outta here!

Three strikes, you're out!

I’m so tired of egocentric lying management executive types.

Executive: You should be thinking about how you speak to the “leadership”.

Me: How about stop lying, blaming me for your own mistakes, and then blackmailing?

Guy has never heard ‘no’ in his life.

Seriously, иди на хуй.

So, I was going to complain about JS being finicky and not making a damned bit of sense, but it turns out that it wasn't JS's fault. Not entirely, anyway. It was the halfassed JS minifier middleware (written by the legendary dev himself) that was breaking the JS while writing it to the page.

The original problem:
My code worked. I removed some comments. Big ol' block of //'s. And suddenly $() isn't a function. But if I call $(); at the top, it all works!

It turns out the "minifier" caused JS to think my code was chaining off the previous JS line in the rendering pipeline instead of being a separate statement. so all it really needed was a `;` at the start. What threw me, though, was the last line of the previous blob of (non-minified) JS was a comment, so it should be a separate statement, right?

But as it turns out...

```
console
// JS really is finicky.
.log('Sigh.');
```

A couple weeks ago I was criticizing C#, I humbly swallow my words.

Microsoft hates this one trick to improving computer performance:

‘’’pkill teams’’’

Not *having to* work for a salary job after being 40 years old.

$work is migrating to a new HR performance review service (15five). Instead of a private (ish) review once a quarter, it'll be public (and uneditable) reviews due every friday. Better make sure that review is perfect.

also, praising a coworker is required.

<sarcastic thumbs-up>

Mom : what do you want to be?
Child : engineering
Mom : why?
Child : because engineer never study.
🤥😅😂😂🤐

Been there in my college days.😌

Fuck project setups that

- Have huge nested enterprise folder structures like Java

- Use tons of shell scripts / makefiles

- Have every config file in the root folder

- Don't tell me what I need / how to build

I know some of these can't really be changed easily, but fuck this cluttery mess!

4tb

riiiight....

Is it just the novice in me that finds the Haskell community's misguided obsession over character count really annoying? Learn You a Haskell For Greater Good states

> Shorter code means less bugs

A lot of people and resources seem to share this opinion, but it's obviously false. Simpler code means less bugs, but look at this function which just means "apply this applicative to each element of a list"

> sequence :: (Applicative f) => [f a] -> f [a]
> sequence = foldr (liftA2 (:)) (pure [])

This isn't "less buggy", it's fucking madness. The same in JS, the king of unreadable languages, would be:

function sequence(seq, val, apply = (f, x) => f(x)) {
seq.map(f => apply(f, val))
}

Seriously, how can you design a strictly typed language that gets beaten by JS in readability?

passive income from some dumb shit

johnny be good (developer)

QA ticket. Images are pixelated blah blah blah increase pixelation to make them pretty.

Next ticket: why is the site so slow. Need to be optimized blah blah blah

Two big moments today:

1. Holy hell, how did I ever get on without a proper debugger? Was debugging some old code by eye (following along and keeping track mentally, of what the variables should be and what each step did). That didn't work because the code isn't intuitive. Tried the print() method, old reliable as it were. Kinda worked but didn't give me enough fine-grain control.

Bit the bullet and installed Wing IDE for python. And bam, it hit me. How did I ever live without step-through, and breakpoints before now?

2. Remember that non-sieve prime generator I wrote a while back? (well maybe some of you do). The one that generated quasi lucas carmichael (QLC) numbers? Well thats what I managed to debug. I figured out why it wasn't working. Last time I released it, I included two core methods, genprimes() and nextPrime(). The first generates a list of primes accurately, up to some n, and only needs a small handful of QLC numbers filtered out after the fact (because the set of primes generated and the set of QLC numbers overlap. Well I think they call it an embedding, as in QLC is included in the series generated by genprimes, but not the converse, but I digress).
nextPrime() was supposed to take any arbitrary n above zero, and accurately return the nearest prime number above the argument. But for some reason when it started, it would return 2,3,5,6...but genprimes() would work fine for some reason.

So genprimes loops over an index, i, and tests it for primality. It begins by entering the loop, and doing "result = gffi(i)".
This calls into something a function that runs four tests on the argument passed to it. I won't go into detail here about what those are because I don't even remember how I came up with them (I'll make a separate post when the code is fully fixed).

If the number fails any of these tests then gffi would just return the value of i that was passed to it, unaltered. Otherwise, if it did pass all of them, it would return i+1.

And once back in genPrimes() we would check if the variable 'result' was greater than the loop index. And if it was, then it was either prime (comparatively plentiful) or a QLC number (comparatively rare)--these two types and no others.

nextPrime() was only taking n, and didn't have this index to compare to, so the prior steps in genprimes were acting as a filter that nextPrime() didn't have, while internally gffi() was returning not only primes, and QLCs, but also plenty of composite numbers.

Now *why* that last step in genPrimes() was filtering out all the composites, idk.

But now that I understand whats going on I can fix it and hypothetically it should be possible to enter a positive n of any size, and without additional primality checks (such as is done with sieves, where you have to check off multiples of n), get the nearest prime numbers. Of course I'm not familiar enough with prime number generation to know if thats an achievement or worthwhile mentioning, so if anyone *is* familiar, and how something like that holds up compared to other linear generators (O(n)?), I'd be interested to hear about it.

I also am working on filtering out the intersection of the sets (QLC numbers), which I'm pretty sure I figured out how to incorporate into the prime generator itself.

I also think it may be possible to generator primes even faster, using the carmichael numbers or related set--or even derive a function that maps one set of upper-and-lower bounds around a semiprime, and map those same bounds to carmichael numbers that act as the upper and lower bound numbers on the factors of a semiprime.

Meanwhile I'm also looking into testing the prime generator on a larger set of numbers (to make sure it doesn't fail at large values of n) and so I'm looking for more computing power if anyone has it on hand, or is willing to test it at sufficiently large bit lengths (512, 1024, etc).

Lastly, the earlier work I posted (linked below), I realized could be applied with ECM to greatly reduce the smallest factor of a large number.
If ECM, being one of the best methods available, only handles 50-60 digit numbers, & your factors are 70+ digits, then being able to transform your semiprime product into another product tree thats non-semiprime, with factors that ARE in range of ECM, and which *does* contain either of the original factors, means products that *were not* formally factorable by ECM, *could* be now.

That wouldn't have been possible though withput enormous help from many others such as hitko who took the time to explain the solution was a form of modular exponentiation, Fast-Nop who contributed on other threads, Voxera who did as well, and support from Scor in particular, and many others.
Thank you all. And more to come.

Links mentioned (because DR wouldn't accept them as they were):
https://pastebin.com/MWechZj9