JacobFW

I'll be honest I just feel like complaining about this because this has been driving me nuts for a while.
Has Google Search just been a complete piece of s@#! for anyone else?
It keeps getting super fixated on one word in your query and ignores everything else, and not just for one search result, but a good majority of them.
Or where it instead decides to search for terms indirectly related to something I searched, like since I live in Dallas, there have been several times I've searched for something in or about Dallas, and usually I have several results show up on the first page where it searched for "County" instead of "Dallas", despite a)  "County" wasn't something I typed, and b)  the result it pulled up still had nothing to do with what I searched for and c) there were no other keywords for what I searched for on that page.
It's cool and all that it can search for similar words/concepts but Christ it still needs to be used to return meaningful results.
 
And yes, because I know someone is going to bring these up:
I am using search operators to try to have it focus more on certain parts of my query I do have popular results disabled  
 
 

Summary
Apple is moving to settle a class action case in the US from a group of small developers. This will involves a few changes to the app store rules and some promises about how long other things will stay as they are.

* Developers will now be permitted to use email addresses/accounts created during signup in the apps to contact users to direct them to pay outside of the app store without apple taking any cut.
* Apple will keep the 15% Small Business Program program active for at least another 3 years
* Apple is creating some form of fund for such companies (based in the US) to `help them`
 
My thoughts
The removal of the rule that used to ban us devs from contacting people who crated their account on your iPhone app is a big deal. It enables a lot of companies that have free tires to go ahead let users create accounts on the phone then email them to prompt them to upgrade (Spotify is a great example).  

This could be a nice solution for FloatPlane also worth noting Luke was mistaken before apple no longer (have not for many years) require the price you use in the app store to be the same as the website.  Floatplane could have a button in app (when you have logged in) instead of saying `subscribe` next to a creator it could say `email me more info` or something 😉 For floatplane if they want to they could also get into the media program that has 15% rate but they would be required to develop a TV os app.
 
The other changes a nice so that we are not worried at all of a sudden the 15% rate will jump up to 30% again.
Sources
https://www.apple.com/newsroom/2021/08/apple-us-developers-agree-to-app-store-updates/

Well first off one thing you need to specify is if you're doing this in your browser (client side javascript), or on your local server (server side/node).
As previously mentioned there are solutions available for node.  There are likely dozens of libraries capable of doing this in the browser, however normally node solutions tend to infect search results when you're looking for client side javascript solutions.
With that being said you might want to check out this post for a browser based solution (note: i haven't tested it myself).
https://stackoverflow.com/questions/8238407/how-to-parse-excel-xls-file-in-javascript-html5
 
Another important thing to bear in mind is that there are several different excel formats. XLS and XLSX are NOT the same thing at all, and will likely require different solutions (though if you have a library that works for one format you might as well try the other).
 
Additionally Excel itself can read a bunch of other file types and convert them to spreadsheets.  CSV, TSV, and html tables are just a few examples.
You can rename any of those file types to .XLS or XLSX and Excel will pretty much parse it without issue.
 
The simplest solution on your end though would to be to just have the user convert the file to a csv before hand and upload that.  At that point you're just working with a plain text file, which would be a lot easier.
 
 
 

Just using the words "alignment" and "css" in the same sentence is giving me flashbacks.  That crap has given me trauma.

Question for LTT.  In the last few years laptop manufacturers have adopted Apple's practice of riveting the effing keyboards to the laptop frame.  So if anything happens to the keyboard (which are usually one of the first/easiest pieces of a laptop to be damaged) it becomes a freaking nightmare to replace, and usually just ends up with you having to get a brand new laptop.  What used to be a $30, 15 minute fix you could do yourself now essentially totals your laptop.
 
I would just really like to know why LTT has not been calling manufacturers out on this? Linus has spent years complaining (rightfully imo) in nearly laptop review about the atrocious webcams & microphones included in laptops, but I can't think of any reviews he's brought this up in.

I'll assume this is a question. 

A good rule when you encounter these "universal rules" in programming, I think, is this:
do your absolute best to follow them unless you understand why people say that, and why they could be wrong People often say "don't use switch statements" or (especially this one) "don't use goto". However, both have their legitimate uses, and are the best solution in some cases. If you can say why that is the case, then feel free to use them. If you can't, then probably don't. 
 
 
There are definitely times when writing js code that I have used globals, and definitely times I technically could have, but avoided doing so in favour of a better solution. But, I'm also a CS graduate, and have been working professionally in software development for some time, so I sincerely hope I'd be able to make those determinations 😄

I will also say this: those rules mostly apply to writing "real" code, when making applications you plan to actually run and do something productive. If you're just playing around trying to learn, don't stress about it. It's much better to keep progressing in your learning experience and commit a couple faux-pas than to run into one, get stumped, and quit.

So I think there's actually at least two different questions that need to be answered for this to make sense
 
1)  How is the webpage you view and interact with generated, both initially and as you use it?
2)  Is the DOM just a parsed version of the HTML text or is there more to it than that?
 
1)  One thing you'll notice on most pages is that if you go into the Inspect Element viewer, and compare that to the HTML when you go to View Source, you'll see that while they may have a little in common, there's still usually vast differences between them (technically they could be the same, but that's fairly uncommon as we're about to see).  When you request to go to a page, your browser will download the initial html (which is what you see under View Source).  In that HTML however are usually script tags, which contains code the browser will execute.  In many sites this code will then finalize the web page that you'll see and interact with, and setup handlers for what happens when you, the user, clicks on certain buttons, or interact with various parts of the pages.  You have to remember that HTML doesn't really "do" anything.  It's more of schematic, that describes how the page should be constructed (think back to old sites from the 90's/early 2000's).  If you click on a button to go to a certain menu or submit an order, it's the script code that runs in the background on your browser, modifying the web page that you see to respond to your requests.
 
When you click on Inspect Element, you're viewing all the changes to the web page that have taken place up to that point, starting with the browser downloading the initial source, running the initial scripts, and any other changes the scripts have made up to that point based on how you've interacted with the page.
 
2)  The HTML (both what's loaded at the start and what the script code has modified as time has gone on) does govern the overall structure of the DOM, but there is more to it in that.  First and foremost what you have to understand is the DOM is essentially a specialized database, which is designed both to aid the render engine as it creates what you see in the browser, and to allow script to interact with it quickly and easily.  The data in the HTML is parsed and stored in the DOM's internal format, but then the DOM also has the ability to store extra data along with that.  Additionally you can store handlers along with that data, so that if say, the user clicks on this element, it should execute a certain piece of code which the developer can specify, or if say the mouse hovers over a certain box or button, it should show a small tooltip which gives a description of what that's for.
 
TBH I feel like this is a case where reading the theory/description of what is happening might just confuse you more.  I would suggest reading some tutorials on Javascript & JQuery, and play around with it yourself.  I think it will make a lot more sense once you see how it works when you use it yourself.
 
 
 

Best bet would be to find an introductory tutorial for node.js which shows you how to return a file based on an http request.
This one may be of some help to you
https://www.tutorialspoint.com/serving-html-pages-from-node-js
 
 

Absolutely wonderful video from criminaly underrated channel...can almost guarantee basically the same thing applies to Perseverance.
 

Let's say you have a 10gb file you want to copy.
Your program will initialize a certain number of threads (lets say 10 in this case).
Essentially what we'll do is divide the file into fixed size chunks, and we'll assign a thread to copy each chunk.  To be clear, we won't actually move data around to divide it, just give it different start and end bounds in the file. So the thread that copies the first chunk will get the bounds 0-99mb, thread 2 will get 100-199mb, thread 3 will get 200-299mb, etc.
For Spinning Drives, a multithreaded copy is probably going to be slower due to it having to move the read head around, which is the slowest part of any read/write operation (could be wrong; if so please correct me).  For SSDs however multithreaded copy can be very helpful.
 
DMA does help to speed up this process but it isn't a substitute for multithreaded file copy. 
To see why let's take a high level look at copying data from one machine to another.
 
Source Drive -> Local Memory -> Send over Network -> Remote Memory -> Remote Drive.
 
Not at first glance you might think "okay, that's pretty straightforward, how are you actually improving on that?"
Well the issue here is the local memory.  When you do a read operation what you're basically doing is providing a memory buffer where you need the data, the file, and the number of bytes you want.  Prior to DMA, when the data was first read from the drive into memory, it didn't get copied into that buffer.  Instead it got copied into another buffer, then into another buffer, then another one, and possibly only then into the buffer you provided (but there could be more buffers).  This same process would then happen in reverse if you were writing data, and pretty much the same thing would happen when sending data over the network (only difference is the data ends up in the NIC rather than the drive).  All this copying of course makes the process much slower.
 
DMA simply cuts out as many of those unnecessary copies and buffers as possible, and instead lets memory devices access the direct memory the calling program/device needs the data to end up in.
 
 
 
 
 
 
 
 

Let's say you have a 10gb file you want to copy.
Your program will initialize a certain number of threads (lets say 10 in this case).
Essentially what we'll do is divide the file into fixed size chunks, and we'll assign a thread to copy each chunk.  To be clear, we won't actually move data around to divide it, just give it different start and end bounds in the file. So the thread that copies the first chunk will get the bounds 0-99mb, thread 2 will get 100-199mb, thread 3 will get 200-299mb, etc.
For Spinning Drives, a multithreaded copy is probably going to be slower due to it having to move the read head around, which is the slowest part of any read/write operation (could be wrong; if so please correct me).  For SSDs however multithreaded copy can be very helpful.
 
DMA does help to speed up this process but it isn't a substitute for multithreaded file copy. 
To see why let's take a high level look at copying data from one machine to another.
 
Source Drive -> Local Memory -> Send over Network -> Remote Memory -> Remote Drive.
 
Not at first glance you might think "okay, that's pretty straightforward, how are you actually improving on that?"
Well the issue here is the local memory.  When you do a read operation what you're basically doing is providing a memory buffer where you need the data, the file, and the number of bytes you want.  Prior to DMA, when the data was first read from the drive into memory, it didn't get copied into that buffer.  Instead it got copied into another buffer, then into another buffer, then another one, and possibly only then into the buffer you provided (but there could be more buffers).  This same process would then happen in reverse if you were writing data, and pretty much the same thing would happen when sending data over the network (only difference is the data ends up in the NIC rather than the drive).  All this copying of course makes the process much slower.
 
DMA simply cuts out as many of those unnecessary copies and buffers as possible, and instead lets memory devices access the direct memory the calling program/device needs the data to end up in.
 
 
 
 
 
 
 
 

Summary
NASA has released the full video showing the descent and landing of Perseverance on Mars.  Need I say more?
 
 
 

Summary
NASA has released the full video showing the descent and landing of Perseverance on Mars.  Need I say more?
 
 
 

Summary
NASA has released the full video showing the descent and landing of Perseverance on Mars.  Need I say more?
 
 
 

Summary
NASA has released the full video showing the descent and landing of Perseverance on Mars.  Need I say more?
 
 
 

Short answer is no.  Source code is intentionally meant for people.  The naming schemes, indentation, comments, etc.  All are meant to make it easier for a developer to look at the code and have an idea of what problem the code is trying to solve.  Machine code is meant to be easy for the cpu to execute, not for a person to read.
 
Don't get me wrong; yeah, some sort of AI could absolutely guess at the source code looked like based on the machine code, but you're still not going to have the naming schemes, you're not going to have the comments, and no matter how good the AI is, it will always be a guess.
And even assuming you had an AI that could recreate 90%+ of the source code, why the f*@# are you wasting an AI on something like that?????
 
Modern Vintage Gamer has a great video on how the source code for Diablo was reconstructed.  The only way they were able to do it was because of excess information left in the commercial versions.
 

I'd recommend learning Python.  Has some amazing numerical libraries these days, and since it's a general purpose language, you have a lot more flexibility in terms of what you can do.
 
And it being free never hurts either.

I'd recommend learning Python.  Has some amazing numerical libraries these days, and since it's a general purpose language, you have a lot more flexibility in terms of what you can do.
 
And it being free never hurts either.

I'd recommend learning Python.  Has some amazing numerical libraries these days, and since it's a general purpose language, you have a lot more flexibility in terms of what you can do.
 
And it being free never hurts either.

RIP Tyler.  This year just keeps taking so much.

RIP Tyler.  This year just keeps taking so much.

ARC for me no matter what TV has been a pain for me, but yeah I think the problem with Samsung is that the smart TV functions are on at the same time, so it kinda craps for me as well, and recently been worse than usual.

So, a little backstory.  Earlier this year I decided to upgrade my entertainment center.  I got a 65" Samsung TV (~$500) and a Vizio 5.1 Surround Sound System (~$250).  Nothing super fancy by any means, but a decent upgrade from what I had before.  The surround sound system in particular I was really looking forward to, and made sure the TV was compatible with it.
So, get it setup.  Have my HTPC hooked up, Switch & Blu Ray player.  Find out about ARC, and get that setup, so everything can play through the sound system without needing a bunch of wires.......
 
Except ARC is really flaky, and I can't get it to work reliably.  If I switch sources, sometimes the sound will switch right away, sometimes it switches after a few minutes, and sometimes it never switches, and even switching back to the previous source won't work, and I have to turn the tv off, power off the speakers and back on, then turn the tv back on for the sound to work again.
 
Just a bit irritating as you can imagine.
 
But, then I realized yesterday that the TV has optical out for audio, and the speakers has optical audio in.  PERFECT!!!  I can just have video & audio go into the TV, and then output the audio to the speaker system.  And it works!  So far none of the same issues with the audio not switching when the video does like I was having with ARC.  Great...................
 
 
except surround sound no longer works.  And so I've spent the last several hours playing around with it and researching it.
 
Turns out, Samsung only supports anything better than stereo if it's with ARC, over the TV tuner, or using one of the built in apps in the TV.
Apart from that.... Samsung's response is a giant FU.
 
So, definitely going to be awhile before I get anything to do with my entertainment system from Samsung.
 
 
 

Would recommend sticking with native javascript, but I will admit that it's somewhat dependent on exactly how "simple" your "simple" website actually is.
 
One thing to bear in mind though is that if later on down the line you decide that some upgrades are needed to your code that turns your "simple" site to a much more complicated one which would be better written in a js framework, this may involve a complete rewrite of your existing simple site.  To be fair though, that might actually be better for you in the long term.  I've had plenty of projects that started out simple, then later on required additional features, and while trying to figure out how to modify my existing code I'll have a realization and go
"Damn, if only i had done ______ when I originally wrote this, it would make these modifications much easier and give me a lot more flexibility in the future if any additional changes are needed."
Then inevitably the question becomes, should I rewrite the existing code, or try to force fit a solution into it?  And I've had too many occasions where I chose the second option (or had to deal with someone else who chose the second option) and depleted regretted it later on, because once you have to revisit code to add upgrades to it, I can guaran-damn-tee you that you will have to do it again, and again, and again.  And if your code isn't setup to better suit the more complicated structure, you'll just cheap polishing that turd over and over with each new change, and each new change becomes harder to write, and harder to debug.
 
So no, I don't think that starting off with regular js and then later on rewriting it for a framework is a bad thing, and in fact might just save your mental health.
 
 

Would recommend sticking with native javascript, but I will admit that it's somewhat dependent on exactly how "simple" your "simple" website actually is.
 
One thing to bear in mind though is that if later on down the line you decide that some upgrades are needed to your code that turns your "simple" site to a much more complicated one which would be better written in a js framework, this may involve a complete rewrite of your existing simple site.  To be fair though, that might actually be better for you in the long term.  I've had plenty of projects that started out simple, then later on required additional features, and while trying to figure out how to modify my existing code I'll have a realization and go
"Damn, if only i had done ______ when I originally wrote this, it would make these modifications much easier and give me a lot more flexibility in the future if any additional changes are needed."
Then inevitably the question becomes, should I rewrite the existing code, or try to force fit a solution into it?  And I've had too many occasions where I chose the second option (or had to deal with someone else who chose the second option) and depleted regretted it later on, because once you have to revisit code to add upgrades to it, I can guaran-damn-tee you that you will have to do it again, and again, and again.  And if your code isn't setup to better suit the more complicated structure, you'll just cheap polishing that turd over and over with each new change, and each new change becomes harder to write, and harder to debug.
 
So no, I don't think that starting off with regular js and then later on rewriting it for a framework is a bad thing, and in fact might just save your mental health.