Speed up any React app!
Blog Instead of being asleep at 19:10 on 1 April 2017, kitt created this:And article teaser read, "React can be so darn slow...but it can also be super fast! Here's how to speed up any React application."
My first thought was, "Don't use React."
$10 says, you REALLY don't need to use React. You are very likely not at a scale where it will help your development process or your site.
Amtrak Sends Spam, About Spam
Blog kitt decided around 22:40 on 30 March 2017 to publish this:I'm not sure this shouldn't be a rant, but here goes.
I received an email from amtrak.com letting me know that the email they received wasn't deliverable.
That's nice, but I DIDN'T SEND THE EMAIL.
Most spam isn't sent by the address listed in the From: field. Email is very promiscuous, and easily abused. I can, for example, send an email address with any valid From: address. That's the way email worked, and kinda still does.
Emails are sent with a bunch of meta ("hidden") data. This "hidden" data are called headers. This header information contains the various email servers an email will go through to go from the sender to the recipient, from the From: to the To: and Cc: and Bcc:. The From: information is also included in the headers.
Because I can send an email with any valid email address in the From: header (and sometimes without valid From: headers), and fake who the email is from, we now have a number of server-based technologies that let email servers know when an email is faked. We can weed out emails not sent from the person claimed in the From: header. One way, for example, is for domains to broadcast to other servers what servers are allowed to send email for that domain, what IP addresses are okay for email to originate from.
This process works, however, only when a receiving server, oh, ACTUALLY LISTENS TO THE INFORMATION PROVIDED.
In this case, Amtrak uses MicroSoft technologies configured to NOTICE the email is fake, then TREAT IT AS REAL.
These headers were included in they "oh, look, your email failed" message I received:
Authentication-Results: spf=fail (sender IP is 93.174.188.182) smtp.mailfrom=hodsden.org; amtrak.com; dkim=none (message not signed) header.d=none;amtrak.com; dmarc=none action=none header.from=hodsden.org;
Received-SPF: Fail (protection.outlook.com: domain of hodsden.org does not designate 93.174.188.182 as permitted sender) receiver=protection.outlook.com; client-ip=93.174.188.182; helo=login3.tura.ch;
Received: from login3.tura.ch (93.174.188.182) by DM3NAM05FT050.mail.protection.outlook.com (10.152.98.164) with Microsoft SMTP Server id 15.1.977.10 via Frontend Transport; Thu, 30 Mar 2017 09:50:29 +0000
Date: Thu, 30 Mar 2017 11:50:28 -0700
From: " Facebook 3 friend request" <notification+s05kejk4yjxx@hodsden.org>
To: <mxgx@amtrak.com>
OH LOOK! "domain of hodsden.org does not designate 93.174.188.182 as permitted sender"
RIGHT THERE! "domain of hodsden.org does not designate 93.174.188.182 as permitted sender"
OOOOOOO! "domain of hodsden.org does not designate 93.174.188.182 as permitted sender"
And again: "domain of hodsden.org does not designate 93.174.188.182 as permitted sender"
If you KNOW that you're receiving spam, don't tell me another server is sending spam, DELETE THE FUCKING SPAM. REJECT the fucker.
For the love of the ailing fragile overloaded internet infrastructure, don't fucking tell me you received spam, because your email is fucking spam.
I had a clever line here next about Amtrak and not trusting them, but as I reread what I wrote, I realized, that Amtrak NOTICING the email is fake, then TREATING IT AS REAL is an accurate reflection of American society these days. Clinton running a porn ring out of a New York City pizza joint, AND A GUY SHOWING UP WITH GUNS TO CHECK IT OUT? Come on, people. You know that is fucking fake, and you treat it as real. Cheetoh claiming his office has been bugged, and everyone going "oh oh oh, he said it, it must be true," AND YOU KNOW HE'S AN IMMATURE BABY. The emperor has no clothes. Amtrak doesn't have an IT department able to configure email servers. Talk about the large mirroring the small mirroring the large.
Technology is great, until it isn't.
Blog Yeah, kitt finished writing this at 12:15 on 30 March 2017Technology is great.
When it works.
When it doesn't work, it can become one of the most incredibly frustrating things.
Take the cafe I frequent for lunch, for example. It has a mobile app for ordering. In reality, the mobile app is the ONLY way to order at this cafe. A cafe guest opens the app, adds whatever to her order, pays for the food and drinks, then waits for maybe 2-3 minutes before hearing her name and picking up her food.
It's a simple, easy, little-human-interaction process.
When it works.
I had changed my password on the cafe's site yesterday afternoon. When I went to use the app today, it wouldn't let me in, my password was wrong. Okay, enter the updated password.
Can't connect.
Update again.
Can't connect.
Update again.
Connection, password updated, app opened.
I added items to my order. Can't connect to add these items to order.
I try again. Can't connect to add these items to order.
I try again. Can't connect to add these items to order.
I try again. Items added.
I click the pay button.
Can't connect.
I wait. I click the pay button. Can't connect.
Repeat one more time before, you know what? I'm not really all that invested in this cafe. I'm not all that hungry after a delicious cup of tea and a less-delicious but still good chocolate bar this morning. I really don't need to deal with the aggravation of this cafe's inability to keep a network up and going.
So, I left.
I'll hang around and work on this project I'm on now for another hour or two, but then I'm leaving, and working elsewhere. The sun is shining, the day is cool but not cold, the wind is crazy and interesting. No reason to be frustrated by this infernal cafe network / technology fail.
Technology is great, when it works.
Just like frustrations and disasters are opportunities for something new.
I wonder where the nearest park is.
The Arrows Of Time
Book Notes Yeah, kitt finished writing this at 19:14 on 26 March 2017
This is book three, and the conclusion, of the Orthogonal series.
Having become invested in the storyline of Egan's Eternal Flame (read: fission reactor), I, of course needed to finish the series. No, no, not of course, but in this case, worth finishing.
We still have some of the physics going on, so realizing Egan had written up the physics of his world in more depth and posted it on his website was a delightful discovery.
This book continues another three or so generations past the previous generations book, with women being able to survive childbirth instead of splitting into their children, dying in the process. Which is great, yay, women are on more equal footing, though the society does have the echos of "better when" and "oh, shit, how do we integrate our progressive thinking with the antiquated beliefs of the homeworld when we return?"
In this book, time travel is possible, with people being able to send messages back to their own selves. Information can't just create itself, however, and the mountain becomes stagnant, with the utter domination of the council and its control of information backward in time.
Just the sort of thing rebels would work to destroy, lest the world stagnate. Which it does. Of course.
I liked this book more than the first one, less than the second one, with the conclusion being realistically improbable and fictionally necessary. I ended up enjoying this series and recommend it to anyone who likes science in their science fiction.