Showing posts with label computer. Show all posts
Showing posts with label computer. Show all posts

Thursday, October 7, 2021

World Wide Web Cookies

I'm more interested in smokestack industries and civil engineering achievements, but computers have become an important industry. I generally ignore that industry because I spent over 40 years working in it, and it is no longer an interesting learning curve for me. And it is not photogenetic. And it is going downhill. (I did some posts about Google's new Sep 2020 version of the blog authoring software over a year ago. It is still horrible compared to the previous version except for the search function.) But I did learn something new this week that is worth noting.

One day I tried updating the maps in my Garmin GPS. It told me that it did not have enough memory for the new maps. I hit that problem a few years ago and discovered that I could increase the memory by sticking a 16GB micro-memory card into it. So I figured no problem, I now have a 32BG card that I can use. Then I learned that after I exited the Garmin Express program on my PC, I could not launch it! (It was originally launched by the setup program.) I tried the icon on my taskbar, the one in the popup side bar on the left and the one on the desktop. None of them worked. I got it going again by uninstalling it and reinstalling it. Then I learned that it thought the 32GB card also could not hold the new maps. So I went to their web site to see what a replacement unit would cost.

But the point of this post is that evening, while I was reading my Facebook timeline, two entries were suggested by Garmin. One was for truckers and the other was for aviators. And the next day I got this suggestion.
From Facebook

So does Garmin's web server talk to Facebook's ad server or are their industry standards for naming cookies so that different companies can share information about a user's web activity?

The next day I got the same video in my Facebook timeline. So I started clicking things. I found an option to stop it. They wanted a reason. When I clicked the option Repetitive, I got another option to stop all ads from Garmin. I quickly clicked that one as well. Hopefully this insight into incestuous information between companies for the sake of advertisements will come to an end.

And Facebook itself has been flaky this week. In addition to their five hour outage, today it fails every time I try to edit a comment to fix a spelling error.




Saturday, May 15, 2021

AI is 100% Artificial and 0% Intellegent

I've been having a problem with Facebook the last few weeks because it started deleting my comments that contained a URL to Google Maps. Facebook declared them to be a violation of Community Standards. When it first started doing that, the content of my comment was gone. And when I clicked through the various levels of explanations I learned it was considered spam because I was self-promoting. If they were URLs to my Blog, I could by it. But I get no benefits from Google Maps references. (Actually, I don't get benefits from my blogs either because I won't monetize them.) Then the notification of deletion changed to include the content of the comment. But the new notifications didn't have any explanation. I've worked around this problem by learning how to use GPS coordinates.



My Facebook problem is small compared to what Google did to me after supper on May 14, 2021. I'll start with the short story: it deleted the five posts to which I added a photo!

And now for the long story because every regular reader knows I can't say anything in 144 words or less.

I use Google's product Blogger to edit my blogs with a browser. And I use Google's product Chrome for my browser. After supper, when I clicked the edit URL of a post to which I wanted to add a photo I got a screen with a red background telling me, to paraphrase, I accessed a phishing site. (I did a bunch of editing before supper with no problems.) Now, is Blogger sending bad stuff to Chrome, or is Chrome buggy? Either way, it is a Google product that has gone bonkers. I clicked through the pages to proceed anyway because I knew the editor does not ask for personal information. What I did not notice was the red "Dangerous" text to the left of my URL because the editor seemed to be working OK. For a while. Then I started getting "Update Failed" when I clicked the update button. About that time I noticed that I could not find one of the posts that I had changed when I wanted to go back and add something more. So I saved the content of the post that was still in my browser, which was the Fairfield one. And I noticed the "Dangerous" label. I figured out how to label it as "Allow." I don't know if that fixed it or if closing the browser window and opening a new one fixed it. But I was able to be productive the rest of the evening. Then when I was done working on the blog and was reading my eMail, I noticed the notifications that more than two of my posts had disappeared.

I then proceeded to loose sleep. At about 4:00am I confirmed that the result of a Google search...

 ...was indeed bogus.


So I created a new post that is a small subset of the info that I had so that I could fix my links in other posts to this post. The new version of the blogger that we were forced to use in Sep 2020 is far worse than the older version. But one thing is better, the search function. Specifically, I can search the bodies of all of my posts in a blog for occurrences of the now bad link:
    body:"blogspot.com/2015/12/joliet-il-ud-tower-santa-fe-and-gm-vs.html"
I found five occurrences in three posts which I changed to the new post.

Now that I've written this post, look what I found in my email!

I'm going to publish this anyhow because of all of the mental anguish that Google caused me over the last 12 hours. At least they do still have some human judgment in their content policing.

UPDATE:
But the humans didn't actually reinstate them! When I accessed the blog link in the emails such as this one...
...I still get:

I verified that all five links still don't work. I sent feedback about the reinstatement not working using the Joliet post as the example. I have to walk away from this mess for now.

(Google Search must check all of its links every night for validity because when I did the "joliet union depot tower" search around 5:00am, my post did not appear in the results. When you consider the number of URLs that must be in their database, it is impressive that they can verify them every night.)

12:38pm: I slept until afternoon. I checked a link again. Still no joy. So the pain and anguish continue. 

First I have to determine which of the four remaining links did I use.

None



Google Search removal of bogus links is not as good as I indicated. Now my post is the second in the search results for Clarke Junction.

I got reminders of what I lost from the images search. Of course, if I click any of those images I got the now infamous "Sorry, the page you were looking for in this blog does not exist."

I save some images in case Google removes them because of the invalid link.









Wednesday, April 7, 2021

Portable Music, Portable Computer Terminals and the Adventure Game

I tend to focus on smokestack industries and civil engineering projects such as bridges and dams. But this post reminded me that music is an industry that has had a significant history.

Alfina Wise Adderly shared
Raise your hand if you remember when "portable music" looked like this!

Gary Michael Capitan posted
Remember this

That is a 45 rpm record on those players. It would have just one song on a side. When I was an older kid (1960s), the 78 rpm records were obsolete. In addition to 45 rpm records, there were 33 rpm albums. And 33 rpm records remained the standard for albums until CDs were developed. The audio industry went through several media types. Off hand, I remember vinyl, reel-to-reel tape, 8-track tape, cassette tape, CDs and mp3. I've had all of those except 8-track. Portable (hand held) versions were cassette tape (Sony Walkman came out in 1979), CDs and mp3. Now mp3 players are one of several devices that have been replaced by smart phone apps.

Kim Andrus
Metz Portable 45 Record Player and AM Radio... " Beach Party Anyone!"?
Steve Dichter: 1956 Metz. German manufacturer.
[I wonder if that used a bunch of D-cell batteries. They would not have been rechargeable back in the 1950s.]

The advent of transistor radios in the 1960s was another milestone for hand-held portable music.

The fact that the 45 rpm player came in a case reminds me that just because you put a handle on something, that doesn't mean it is portable. In the 1970s, we could take a computer terminal home at night to do more work. That was back when a phone still had a handset. The handset was important because you would dial into work and when the phone started squealing, you would shove the handset into the acoustic couplers on the back of the terminal. (The acoustic couplers are the two black circles on the back of the terminal in the photo.) And you worked at 300 baud with a roll of heat-sensitive paper that the terminal printed on. The problem is that it weighed 40 pounds, and it was almost as big as a suitcase. I use to kid people that just because something has a handle, that doesn't mean it was portable. This photo is what we upgraded to. I consider it portable because it was just 14 pounds. (There was a cover that you put on it when carrying it around.)
eBay

I (and some friends) spent some time on that model playing Adventure. I knew of one person in our office who got a perfect score. I found a version online a couple of years ago, but I could not find the maps I made in the 1970s. So I drew another map. I made decent progress the second time until I came to a random exit node. I never did learn how to control the exit so I gave up. I found an online map of the cave. [BlueRenga] But I don't see any mazes. We at Bell Labs must have gotten a more mature version. This time when I looked online I found Advent 501. This version is more modern than the one I had played because it has a pantry and a poster in the well house. I'm not even going to try to play this one.

Thursday, September 17, 2020

Facebook Lemonade: They no longer abbreviate URL displays

Facebook's Doomsday has happened. But I have discovered an escape to the classic version so that I can still get examples of how they did stuff better.

Some URLs can be rather long. When a long URL is shoved into Facebook's skinny timeline display, it consumes a lot of screen lines.



The classic version did a good job of abbreviating them so that only one screen line was consumed. Specifically, it included the domain name and the end. Actually, now that I look at it, it is smarter than using just the end. Now I'm curious what their algorithm was. But I won't be able to study how they abbreviated URLs until, hopefully, they copy that code forward into the new version.

Some URLs can fill a screen with quite a bit of gobbly-gook.

Update:
Facebook fixed this in less than a day! Kudos for Facebook.


Wednesday, September 16, 2020

Google Lemonade: GOOGLE HAS DESTROYED SOME OF MY NAMED ANCHORS!

When I was writing about the Cos Cob Power Plant, I wanted to reference my notes on ComEd's Fisk Power Plant using the link https://industrialscenery.blogspot.com/2014/05/midwest-generation-power-plants.html#fisk. But when I tested that link, it didn't work! So I looked at the HTML of the target notes. What I expected to find was the named anchor:
<a href="https://www.blogger.com/null" name="fisk"></a>
What I found was:
<a href="https://www.blogger.com/null"></a> 
Note that the "name" attribute is missing! The href attribute is something that Blogger adds after I type in <a name="fisk"></a> and it's extraneous. BTW, I learned years ago that <a name="fisk"/> doesn't work.

The Midwest notes had three named anchors, and all three of them were missing the "name" attribute. So I added it back in. The new version no longer adds a bogus href attribute, which is good.
<a name="fisk"></a>
I quickly spot checked another post that had named anchors, and it was OK. So I lost some sleep trying to figure out how to find the destroyed named anchors in my thousands of posts. The new version supports a "body" search which looks at the HTML as well as the visible text. So the query I needed was the boolean expression:
body:blogger.com/null and not body:name=
But Blogger doesn't support boolean expressions. (But believe me, the new search is far better than the search in the legacy version since the author's search in the legacy version broke April 3, 2018. I've been having to find posts using just a label. In fact, the search function is the only thing I have found so far that is better in the new version.) So I needed to do two body queries and eliminate from the first result those posts that appear in the second result. But the results of these searches is so big that I haven't taken the time to even force a loading of all of the results.

Then yesterday I was working on my Met "bridge to nowhere" notes and discovered that the forward reference https://industrialscenery.blogspot.com/2016/12/the-met-and-its-abandoned-bridge-over-c.html#met did now work. So I switched to HTML and searched for "/null" to add " name="met"". But I did not find it! So I added "zzz" to the notes where the name should be and looked for zzz in the HTML. To my horror, there is no <a> element for a named anchor! So I can't even search for "/null" to find where I have problems.
<a href="https://www.facebook.com/dennis.debruler.7">Dennis DeBruler</a> The former "L" bridge in the background. Now it is just a signal bridge. This "L" route was replaced by the Dearborn subway.</td></tr>
</tbody></table>
zzz<br />
The Metropolitan West Side Elevated Railroad was the third one built in Chicago and the first to use electric traction. [<a href="http://www.chicago-l.org/operations/lines/garfield.html" target="_blank">GarfieldPark</a>]
 So I added "<a name="met"/> to see if it still needs the </a> text. The resulting HTML is:
<a name="met">
That is not correct HTML, but it did work when I tested it.

So now I have the situation that Google has destroyed some of my named anchors and I have no way of finding what needs to be fixed. Named anchors is a feature that I use rather frequently so I was glad when I saw that the new version supported adding them. Google has since removed that support.

Unlike Google destroying URLs, I have no idea what causes it to destroy named anchors so I don't know what to avoid doing. In fact, I don't even know if it was the new or the legacy version that destroyed them! They may have been broken for years, and I just now happened to need a broken one. 

In the case of URLs, I have to avoid removing the formatting of text. I did a quick test. This bug is still there even though I found and reported that content destruction bug soon after they released the new version. (The correct domain in the screenshot is not blogger.com.) At least they improved their URL display a few weeks ago so that it is easier to check the URL content.

I did force the entire results of the "body:name=" results to be loaded and I saved the results below as a series of window captures so that a year or so from now I can see how many more named anchors Google has destroyed. But before I did that, I took a nap. After sleeping on it, I realized that would give me a list of posts that would have damage, but I wouldn't know the names that got lost. But then it occurred to me that I could find the lost names by searching the blog for links to the name. To test this theory, I searched for posts that referenced the Midwest posts:
body:"https://industrialscenery.blogspot.com/2014/05/midwest-generation-power-plants.html#"
And got:
If this doesn't remind me of the names, then I can go into a post, switch to HTML and search for ".html#" to find the names. Hopefully, when I learn the names, I can remember where they belong in a post.

Current posts that have named anchors























If sweeping out 21 screenshots and saving them wasn't a torturous enough waste of my time, I remembered that I have a second blog. Fortunately, I don't cross reference as much in that blog.