You know what stinks? Sites like the Washington Times that throw so many advertisements into your face that you'll never actually get the information you want.

You know what would rule? Being able to have a personal killfile for URLs that stink when you go to a search site.

You can do this now on a search-by-search basis. Try this:

https://www.google.com/search?q=nationals+barry+svrluga

Now try this:

https://www.google.com/search?q=nationals+barry+svrluga+-site%3Awashingtonpost.com

Very different results.

If we had enough people stop using, idk, geeksforgeeks.com (which just asked me to sign in and turn off my adblocker about four times, and not all at once, by which I mean I scroll and it asks again, and I read a while and it asks again; ARGH!!1!) or w3schools.com (which I often get in results when I want MDN... yes, I normally search with MDN in the terms now), maybe Google would learn not to include these things as high in the search rankings.

Just an idea. Guess I should write a browser extension.

Labels: Google, search

Amazingly (or perhaps not), Firefox (macOS 106.0.1 (64-bit)) slammed me back to using Google as its  toolbar search engine. I had been using DuckDuckGo for years.

Luckily Firefox had a pop-up telling me as much, actually bragging about it, so I knew to set it back. But I did test it once before swapping, and this was not a drill. The update to Firefox wasn't showing me the wrong dialog; it had slammed me back to Google.

/sigh

Profiteering weirds the internet.

Labels: firefox, Google, hats o' money

From The Verge: "Google says Apple ‘should not benefit from bullying’ created by iMessage lock-in."

“iMessage should not benefit from bullying. Texting should bring us together, and the solution exists. Let’s fix this as one industry,” tweeted the official Android account.

"Wow, that's rich." -Firefox

Labels: apple, Google, open

Remember in April when I complained about how hard Apple is selling me services, and how it made it sound like I would lose email?

Guess who else is selling me services? You got it. Google. Well, specifically Gmail.

 

 

Let's give that a shot.

Wait, okay, that's actually kind of helpful! has:attachment larger:10M is a neat search suggestion to get rid of some oversized emails.

Unfortunately I only have 125 that match. That's not nothing -- 125 at even just 10 megs each is well over a gigabyte, giving me nearly 8% of my 15 gigs of free space back and hopefully silencing this message for a while.

But what really hits me is the coincidence that Apple and Google are both yelling at me to pay something [or pay more in Apple's case] at the same time. 

Interestingly, Outlook seems to hard cap at 50 gigs even when you're paying $70 a year (includes 1 tb OneDrive). Google offers 100 gigs in gmail for $20 a year. Apple lets you lump email in with your iCloud, so potentially 2 terabytes (!??!), but that's shared with your iCloud backups, messages, and pictures, and runs $10 a month, so... Fastmail charges $5 a month for 30 gigs and $9 for 100, which seems to be obviously too much until you recall they aren't profiting on what's in your emails.

Regardless, what getting caught on both ends with "upgrade now!!1!" adverts tells me is that companies aren't scaling storage over time, as it becomes cheaper for them. And storage isn't being updated year over year because having people run out of storage is a profit center.

Not crazy, but not coincidental either. This is a decided, "let's all charge for services" play by all the companies. There's money in them thar hills.

Labels: apple, cloud, gmail, Google, hats o' money, icloud, outlook

With all this autocomplete in Gmail and Outlook, do you suspect it's mining my composition to suggest completions for me? For others? If I tab, is that a training point?

(That one's pretty innocuous, but I complained in Outlook that the suggestions were so long it was slowing me down... I was composing as I typed and reading through the suggestions to see if they were better. They weren't. They only wasted my time.)

I mean, of course they're stealing our labor, right? Even though I'm just a coder, my English degree doesn't appreciate what this blog called [in this case talking about captchas and Street View ids for Google]...

... yet another ruse devised by Google to make you train their robots for free

I recently bought a domain for personal email and was going to try it out with Fastmail as the host. This kinda pushes up the timetable on that experiment [he said as he typed into his Google-hosted blog].

Edit: This one's a little better example of robo-suggesting (and is actually what I was going to write), though still not nearly as bad as what I got in Outlook, which was nearly writing my email itself.

Labels: ai, Google, hats o' money, labor, outlook

Noticed something called googlesoftwareupdatedaemon eating up my CPU this morning, and was able to google (well, duck) up this from a MacRumors forum:

The good news [if you are having trouble with googlesoftwareupdatedaemon] is, you can go to the LaunchDaemons folder

(in Finder: Menu Bar > Go > Go to Folder…, enter /Library/LaunchDaemons, click the Go button)

and then delete the offending daemon, probably com.google.keystone.daemon.

Empty Trash, Restart. Done.

I'm not quite yet ready to delete it, but it's interesting to learn where this stuff lives.

Labels: chrome, Google, macOS, noteToSelf

Oh google. Your raw source makes me something something.

Why is this in the page itself? Why do you need so much source to display your page? What ever happened to humans writing html code?

I know I sound like an assembly programmer in the land of OO, but it still makes me sad. ;^)

Labels: cyborg, Google, human, javascript, sad, transpilation

From ShipIt Days | Atlassian:

ShipIt

24 hours to innovate. It's like 20% time. On steroids.

That's, um, nothing like 20% time.

Though, of course, 20% time was never 20% time either:

Yahoo CEO and formal Googler Marissa Mayer once bluntly denied its true existence. 

"It’s funny, people have been asking me since I got here, 'When is Yahoo going to have 20% time?'" she said on stage during an all-employee meeting at Yahoo. "I’ve got to tell you the dirty little secret of Google’s 20% time. It’s really 120% time."

That said, I think I'd take 10% time:

"It's not technically something that gets formal management oversight — Googlers aren't forced to work on additional projects and there are no written guidelines about it. Typically, employees who have an idea separate from their regular jobs will focus 5 or 10% of their time on it, until starts to "demonstrate impact." At that point, it will take up more of their time and more volunteers will join, until it becomes a real project." [attributed to "Google HR boss Laszlo Bock"]

Interesting final quote from Bock: "[The informal 20% time policy] operates somewhat outside the lines of formal management oversight, and always will, because the most talented and creative people can't be forced to work."

The interesting lesson is that you win when you convince your employee to produce more work. Maybe 20% time isn't such a bad idea for either side of the management fence. X hours of required work versus 1.2X of work the employee actively wants to give. Sounds like a win-win.

Labels: business, culture, Google, management, time

Today, I ran across a clickbaitily titled post called Just Say No to More End-to-End Tests posted at the Google Testing Blog, written back on April 22, 2015, detailing a fictional end-to-end (e2e) testing run. The scenario was very clearly fictionalized, but you can forgive most of it, as they're simply trying to illustrate a few points.

Here's their "analysis" of the test, which apparently took over a week to complete and had some serious errors with the testing apparatus as well.

What Went Well 

• Customer-impacting bugs were identified and fixed before they reached the customer.

What Went Wrong 

• The team completed their coding milestone a week late (and worked a lot of overtime). 
• Finding the root cause for a failing end-to-end test is painful and can take a long time. 
• Partner failures and lab failures ruined the test results on multiple days. 
• Many smaller bugs were hidden behind bigger bugs. 
• End-to-end tests were flaky at times. 
• Developers had to wait until the following day to know if a fix worked or not. 

...
Although end-to-end tests do a better job of simulating real user scenarios, this advantage quickly becomes outweighed by all the disadvantages of the end-to-end feedback loop:

[Criteria]	Unit	End-to-end
Fast	✓	X
Reliable	✓	X
Isolates Failures	✓	X
Simulates a Real User	X	✓

The author uses this cluster of an e2e test to argue for a preponderance of unit and integration tests...

Integration Tests

Unit tests do have one major disadvantage: even if the units work well in isolation, you do not know if they work well together. But even then, you do not necessarily need end-to-end tests. For that, you can use an integration test. An integration test takes a small group of units, often two units, and tests their behavior as a whole, verifying that they coherently work together.
...

Testing Pyramid

Even with both unit tests and integration tests, you probably still will want a small number of end-to-end tests to verify the system as a whole. To find the right balance between all three test types, the best visual aid to use is the testing pyramid. Here is a simplified version of the testing pyramid from the opening keynote of the 2014 Google Test Automation Conference:

...
As a good first guess, Google often suggests a 70/20/10 split: 70% unit tests, 20% integration tests, and 10% end-to-end tests. The exact mix will be different for each team, but in general, it should retain that pyramid shape.

That's a lot of info to digest.

Here's the problem: "Simulates a Real User" isn't a single point. Their chart really isn't a scorecard, though that's how it's presented.

My quick list of critiques:

1. How many jobs have given you permission to create good unit tests?
2. Of those jobs, how many programmers actually created worthwhile, real-world, success & fail case tests?
3. Of the two unit tests you have left from the filters of 1 & 2, how many jobs then also factored creating integration tests into your schedule?
4. Did you use TDD? Because otherwise the tests you made in 1-3 are crap. No, honestly. No Scottishness at all.

Look, more typical situations in my experience are that you either have lip-service unit tests [only] or that you have no testing at all.

Guess what's most valuable if you have to pull teeth to convince management that testing is important? In my experience, it's an "end to end" test. You'll get the most return on your testing resource dollar with smoke tests.

I do like to call it a smoke test, and I've had pretty good results using Selenium to automate a browser using C#. Which browser? Well, you get your biggest bang for the buck by just using one. It'd be great to test in IE, Firefox, Edge, Chrome, and even macOS & iOS Safari, but each time is a diminishing return. The first test in whatever browser is going to catch 75% of what's wrong.

I recommend using either 1.) The lowest common denominator for browser functionality, usually IE, or 2.) Whatever's the easiest to get to behave for your tests. Timing can be a pain in Selenium.

Recently, I've used Selenium's Chrome web driver. That's dangerous. Chrome seems the most fault tolerant of the browsers, and on a developer's phat box, you can add slow downs to browser incompatibilities as problems that are often hard to notice.

But one browser, going through an automated master set of user stories, will quickly ensure that the 80% of your website that's your real bread and butter works and wasn't screwed up by whatever whizbang gizmo your latest release just pushed out the door.

If there is an error, sure, it can be hard to immediately identify the exact cause, which the Testing Blog seems to think is the end of the world. And perhaps a unit test to cover each error you do discover and track down will be useful. Do that.

But, again, unless you're doing TDD, to ask developers to write useful unit tests ahead of time almost never covers what your users are actually going to do and doesn't prevent bugs your own developers and QA are going to catch anyway. To get useful unit tests, you're going to have to spend even more time getting developers to code review others' unit tests, and you barely had time to green light unit tests to begin with. (How do I know that? If you had plenty of time, you'd be using TDD.)

And if you've gotten so far down the line that you can't tell if an error is coming from the front or back end, as in the Testing Blog's worst-case scenario, well, you have worse problems.

My suggestion if you're losing days looking for bugs your e2e tests turn up, and more days with your test lab going down?

Forget the users; your development process is broken. It's time to start arguing for TDD.

Update: Interesting to look at the slide linked in the quote, above:

And the notes address what I'm saying exactly (and argue against it):

Automated API tests are the best bang for the buck wrt tests that are easy to write and stable and a reliable signal. Integration Tests are always valuable; but we need to ration the number of integration tests one writes as they can be more difficult to debug and have a high noise factor due to all the moving pieces Automated component testing allows one to test a particular component (server) in isolation. you mock everything else out and ensure this component behaves as intended

As evident; the cone needs to be inverted in a lot of teams and companies. There is too much focus on Automated UI testing. At Google; we realized that half a decade back and have been putting in the required effort in the Integration testing and unit testing layer.

Interesting. I'm going to guess Google's coders do a much better job writing tests. If you want to convince me, talk more about how tests are written, and less about how they're better than automated UI testing if you have no testing now.

But wow, look at some later slides:

Push on Amber

• Daily pushes to prod

• Stable top of tree

• Smarter regression testing

• Critical tests cannot be bypassed

Comments to that slide:

In an ideal world; we should push on green; but we live in a practical world. I want baby carriers with beer holders; but they don’t make them. so I improvise and use my denim back pocket as my beer holder.

Not great. I've heard what's important when coding is to know which bugs to ship, but which bugs in tests to ignore? What are we doing? Later on...

How tests have become a nightmare. due to flakiness. stability.
I remember when I joined a team about 7 years back; I was excited; to be in server world @ Google. had been on client stuff before. When I asked around folks told me they had 1000s of end2end automated tests. I was like w00t! Turns out only 100s of them were providing real enough signal. some were flaky; some were broken forever.

EXACTLY. I think the Testing Blog grossing oversimplified the take-home from this fellow's presentation. I'll job bombarding pixels now.

Labels: coding, Google, selenium, tdd, testing

From allenpike.com:

[Consistency works] Except when it doesn’t

As far as consistency will get you, if you work with startups or other rapidly growing businesses, sometimes they’ll struggle with cashflow. To manage these problems, you need to apply fair but undesirable consequences when a client consistently doesn’t pay on time. While individual tastes vary, popular selections include:

• With[h]olding IP rights to the work in question
• Charging interest
• Ramping down or halting development after a warning period
• Telling a client “[Forget] you, pay me” (advanced users only, offer not valid in Hawaii or Canada)

[highlighting and PG censoring performed by me -mfn]

Had a "duh" moment reading this one. I've been lucky that most of my clients pay on time. I'm probably also lucky that I don't act like I'm only around to pluck every living dollar out of what one might act like is their tightly clenched hand. I bet it helps you to get paid in some-to-many situations if you don't act like getting paid is the only reason you're interested in them. Clients are not ATMs; they're [usually, ultimately] people. If you're interested in helping them succeed -- and can competently help them do it -- they'll be happy to bring you along.

But the "duh" moment -- to be clear, a moment when I'm slapping myself in the head -- is to withhold IP. You might do yourself one better and include in your contact that you will also assume rights to any design elements and other IP that you've been made privy to while working. I realize you could get into a mess if the client has licensed stuff that they shouldn't or can't officially allow you to use, and some folks would balk at their current clients or test data, but you get my point.

Clients don't always respond to "time out"

The problem with "ramping down... development" and "charging interest" is that they don't guarantee you'll get anything. Those are really only useful if the companies want to work with you again, or if you're owed so much it's really worth suing. That is, those two remedies usually require the client to participate in their punishment for them to be effective. (If you're currently still working for a client that agreed to and is not now paying, we need to have a talk.)

It's like being a parent -- if your only punishment requires the punished's cooperation, you're often left with a battle of wills. This includes stuff as simple as, "That's your third strike. Go to time-out." If they don't go to time out, what do you do? Pick 'em up and put them there? Stand over them and forcibly keep them in time-out? (Um, I don't recommend that, btw.) These aren't great situations, are they? [... is a rhetorical question most any parent has likely already confronted.]

But tell someone you now own their ideas and legally become their competitor? Now that's punitive and enforceable.

Litmus testing

I really can't see anyone pitching too big of a fit for that being in your contract either, if it's well written and sounds fair and even, not like you're dying to stick it to your client. Anybody who tells you they're not willing for you to own their stuff if they don't pay might not be who you want as a client, right?

If they're worried about slow times or unexpected issues, I'd feel okay negotiating the, "Pay or I can play" clause as far as they want, until they're comfortable. I'd also probably need to add some soothing language that you wouldn't use their brand itself, and would perform what you felt were minimal distinctive changes to address possible user confusion...

But at some point, a reasonable entity would have to recognize that, if they're not paying their own contractor what they contracted, that's unfair.

I should probably also add now that I don't typically fix-price something past the first contract. I don't mind taking a little bath to try and show someone I'm worth keeping around, but later, I try to make it clear that you're paying for hours of work, whatever they produce. This tends to keep clients on track if they're exceptionally cost-conscious, and also from them asking for the moon -- and from moving the moon biweekly because of some incredible insight!!1!121! they had over breakfast.

Two lessons here:

1. Well-written contracts work well as a litmus test for your clients.
2. Clients paying for time tend to be more responsible clients.

Google fails in search for blog

Headline, headline; read all about it!

One quick aside: When I was searching for Allen Pike's post, above, using a very specific string of words from the post, "to manage these problems, you need to apply fair but undesirable", Google gave me nothing, at least nothing tempting on the first page of results. That's crazy-insane.

Bing found it, no problems (though its third hit was, um, strange).

Go figure. As I've said before, Programming is Hard, (c) 1842.

Labels: bing, business, contracting, Google, google fail, hats of money, indie

I wonder if Google assigns weight to search results by viewers. That is, if your latest post on the iPhone seems to be getting lots of hits from within Apple's Campus, shouldn't that score higher than the same number of hits from random locations, at least in some situations?

Surely Google's thought of that, so if it was something they deemed useful, it's already happening, since that's pretty low hanging fruit. Hrm.

Labels: Google, search

Now when you're searching for a frequent flyer number or shipping status (for example), Inbox will show it at the top of search results–no more digging through individual emails to find what you're looking for.

Underneath any quick answers, you'll see a "Top results" section that orders emails by relevance. Below that is all the email results, ordered by date, but chances are you won't have to look here often.

Labels: email, gmail, Google, indie

This 2-3 minute tutorial steps you through uploading data to generate a map with placemarks in the new version of Fusion Tables.

This tutorial is fantastic. Take a csv of addresses, import into Fusion Tables as an address field, and poof, you've got a map of addresses with hover-over labels from whatever other field or fields you want.

Insanely easy.

Labels: Google, maps, noteToSelf

From Buzzfeed via Gruber:

Cars are giant, inefficient, planet-and-people-killing death machines. Self-driving cars — especially if they are operated as fleets and you only use one when you need it, summoning it Uber-style — would mean we could have fewer vehicles per person, less traffic congestion, less pollution, far fewer vehicles produced per year (thus lowering the environmental impact of production), and, best of all, safer streets. The blind, people with epilepsy, quadriplegics, and all manner of others who today have difficulty ferrying themselves around as they go through the mundanities of an average day will be liberated. Eliminating the automobile’s need for a human pilot will be a positive thing for society.

I can't quite figure out why the tech media thinks self-driving cars are quite as inevitable as they make out. Even if I pretend that the engineering hurdles for self-driving cars are all solved, I can still think of a fair number of reasons they wouldn't catch on.

• You're going to have a hard time "convincing" each state legislature that they should be legal.
  • Why? Because driverless means fewer, and car companies are going to lobby like crazy against them. From the article:

  • Self-driving cars — especially if they are operated as fleets and you only use one when you need it, summoning it Uber-style — would mean we could have fewer vehicles per person...

• At the start, they'll be new, higher-end vehicles.
  • Folks that buy used cars will be waiting... a long time.
• Not everyone lives in an urban area, and the more rural, the longer you're waiting for Uber et al to show up.
• How long before we're brave enough for cars to take our kids to school for us while we stay at home or work?

I can't tell how big a deal folks liking to drive will be. I mean, I love to drive, but I also love the time riding the train buys me back to get some work done. I've got to guess the first several generations will have steering wheels in most models as well, just like the one in Demolition Man -- and don't forget that Stallone exhibits ye olde machismo by driving manually later.

Doesn't the movie end with him in a '70 442 W-30? (Why yes, yes it does.)

Labels: cars, Google

So I'm unhappily debugging some inherited Python code, a language I've never used before, that's causing trouble (it's comparing .csvs, and was using giant dictionaries to keep all the rows from the first in memory, removing keys when a matching "id" column was found in the other file. But did it anticipate repeated keys in multiple csv rows? No. No, it apparently didn't), and got the attached "results" from googling for "python try catch". Hello, surreal...

And, as you can tell from the second picture, if you choose to play, after the search results are replaced by a command-line environment, things get a little Hideo Kojima-y. I remember once playing the original Metal Gear Solid with a buddy and running into Revolver Ocelot (?) in a boss battle, and he said something about how long it'd been since we'd saved, and that we weren't allowed to save now. I'm not even sure he was telling the truth, but we didn't try to save, and the battle was that much more exciting because of it.

So "This invitation will expire if you close this page," certainly convinced me into going down the rabbit hole. I mean, even if this is some sort of strange, elaborate hack, who wouldn't? I'm your huckleberry.

Turns out there's a file in my "home" directory called start_here.txt, and I'm given a programming challenge. Not too difficult, but a challenge, and a timer, and a time limit of 48 hours (I guess that was my first hint I should've waited until I was home). I don't know Python, but Java is allowed as well. Haven't really used Java seriously in a while, but I happen to have javac on the workstation (though no Eclipse or Netbeans), left over from when I decompiled an app we were using from [a vendor] to fix a bug of theirs (a casting error; they were pushing essentially a double into a single), so let's try this. A quick click on Sublime Text, a quickly hacked bat file to compile and run my class, a cmd window, and we're off.

The worst thing? I completely foobared the Google/foobar. What a freakin' idiot. I did sort of figure it was an application for employment, and I couldn't've done worse. The first problem wasn't tough, but I did my usual "race through and figure out errors later" and obo'd all over the place, which was obviously the point of the problem. I got it, but it took about 17 minutes of setup and fixing dumb errors. Idiot. I'm sure they see every failed verify call. Idiot.

Oh well. I logged in to save and guess I'll try the remaining tasks later. Not that I'm even looking for a job. Not that it's particularly ethical to interview me for a job while I'm working in my current position without telling me that's what we're doing. But that was fun, in a way.

This is what I get for searching to fix a Python issue! Programming languages are all "different dialects of the same language", a prof once told me. He was right, but it's strange what googling those dialects can do to you.

Anyhow, more about what's going on with Google/foobar here. And yes, it turns out it was an interview. Dang it. Still, from debugging Python in VIm via ssh to javac-ing an answer in 17 minutes isn't horrible, I guess. ;^)

Labels: easter egg, Google, java, Jobs, python, wtf

From StatCounter as recounted by Gruber:

Interesting results from Yahoo’s deal to serve as the default web search for Firefox:

StatCounter has also run a special report on US search engine usage by Firefox users only. Yahoo-on-Firefox usage in the US increased from 9.9% in November 2014 to 28.3% in January. Over the same period Google-on-Firefox usage in the US fell from 81.9% to 63.9%.

There's no way that lasts. I wonder what percentage is permanent.

Firefox hijacked my search bar at some point in the recent past, and after trying a single search, I was setting Google as the default search engine, peeved at the audacity of the sinking Mozilla ship to change my setting without asking. Maybe on that box I'd never swapped from Google as my default, but I certainly have played around with Bing on other Firefox installs and quickly gone back to Google.

Other folks will probably go more than a single search before getting upset enough to learn how to swap their engine, but eventually they'll notice Yahoo ain't as good as what they had before, and ask their tech-savvy friends to swap them back.

I hope. Man, can you believe it if 19% of Firefox users, already probably a slightly above-the-mean group of techies, just don't care, and figure the default search engine is always good enough?

More telling is probably, if Firefox hijacked everyone like they did me, that over 70% of Firefox users immediately swapped back to Google.

Labels: firefox, Google, yahoo

Additionally, mobile web traffic has grown substantially (especially at certain times: nights and weekends we see 60-70% of all traffic on mobile/tablet) and ad performance on mobile is much less effective, where mobile pages only make about 1/3 to 1/10th as much as a desktop page. 

Labels: ads, Google, hats of money

Labels: fail, Google

My manager then said, “More than half the company would have to lose their job in order for us to stop these tactics … so are you volunteering to be one of them?”

That was the day I learned I’d rather lose respectfully than win without honor. Once people become wary of your products or your business ethics, it’s game over. You can’t sustain for long, because you won’t keep your customers much longer.

Mozilla is heavily reliant on income from search royalties from Google, and has been for some time, so this would seem to be an exploration of other financial options – with possibly more alternative revenue streams to come?

Labels: firefox, Google, hats of money

Breaking down the admittedly messy math shows that Google didn’t exactly lose nearly $10 billion on the deal. Here are some back of the envelope calculations.

When Google bought Motorola, the hardware maker had about $3 billion in cash on hand and nearly $1 billion in tax credits. So that brings the original deal’s effective price down to about $8.5 billion.

Then, Google sold Motorola’s set-top box business to Arris for nearly $2.4 billion. That lowers the effective price to roughly $6.1 billion.

Now, Google is selling Motorola Mobility — primarily the handset business, along with a few patents — for $2.9 billion. So we’re at about $3.2 billion.

It’s worth noting a few more things. In a regulatory filing in 2012, Google disclosed that it valued Motorola’s overall “patents and developed technology” at about $5.5 billion.

Google likely offered to get out of hardware if Samsung cross-licensed their patents and stopped pseudo-forking Android. Given Samsung’s dominant position in the Android ecosystem, the Motorola bargaining chip very well may have been worth several billion dollars.

It's the enterprise, stupid

[Motorola has] focused on building a smaller number of great (and great value) smartphones that consumers love. Both the Moto G and the Moto X are doing really well, and I’m very excited about the smartphone lineup for 2014.

Labels: business, Google