Category: Uncategorized

My first Macintosh was a Centris 610, which you’ve probably never heard of. The line survived less than a year, though it introduced the case that would later be used in the Quadra 610 and Power Mac 6100. It was a pretty good Mac. The power button eventually fell off, but it was repaired with glue.

I bought a Mac Studio this weekend. As I purchased it, I stopped the Genius to check the specs on the box before realizing there was no way I’d be getting less than the computer I wanted. I was getting the base model.

The OS seems to basically live in the Efficiency cores, with the occasional 75% burst on the first two Performance cores. There are six more Performance cores all but untouched. Of course, when I build code there’s a more sustained usage of additional cores. I could see a Mac Studio with an M1 Ultra being useful for that, but this one better fit my budget.

I needed a monitor for my PC laptop this year. At a coworker’s suggestion, I got a 43″ 4K TV instead. The results were a little mixed, as I couldn’t get the PC to drive it a more than 30Hz. I had the same problem with my M1 MacBook Air. The Mac Studio can not only run this at 60Hz over HDMI, but it can also run four 6K displays over USB-C. Getting a new monitor is out of my budget for now, but I plugged in my 27″ Thunderbolt Display via a Thunderbolt 2 Adapter and was able to extend the desktop to it, too.

The biggest flaw is the front ports. It has two USB-C ports and a SDXC slot on the front. USB-A and the headphone jack are only available on the back. I just don’t understand why Apple can’t put headphone ports on the front of their computers where they’d be actually useful.

Overall, I’m pretty impressed. Technology is always marching on, but this seems a huge leap over even last year’s M1 MacBook Air.

One thing that getting older gives you is perspective. What excites youth is looking ahead at the infinite possibilities the future promises. I think that maybe wisdom comes from combining the two. With infinite possible paths forward, it’s useful to occasionally look back to see what’s worked, what hasn’t, and why.

I’m involved in a big software project – BeLooped – that has incredible potential and yet has not progressed at a speed anywhere near what I would like. The other evening, I sat back and pondered why some projects I’ve worked on have succeeded while others have not. I concluded that a big factor is the development approach.

I guess another thing age gives you is enough experiences that you see analogies. So I’m going to use one. I’m also involved in a CoHousing project: CompassCoHousing.com and I’m part of that project’s development team. This will be a 40-unit facility. It was after we found land to build on that the real fun began.

We hired a geotech engineer to do soil samples to make sure we’ll be building on a firm foundation. We’ve consulted with Fortis as they have a large pipeline running through a portion of the property. We’ve had multiple meetings with Langley Township staff regarding road access, height restrictions, upcoming environmental bylaws and far more. We’ve shown Canada Post our plans, to learn where they need to access for mail delivery. We brought in a cohousing expert all the way from California at least 3 times to give advice on the overall design (he didn’t seem to understand that it rains here, though). We’ve hired a building architect (turns out they do much more than just draw pretty pictures) and a landscape architect. We’ve recently selected a mechanical engineer and will also need a communications team (internet/phone), a security consultant, a ventilation specialist… the list goes on and on and on.

Actual construction is going to take very little time compared to the “prep work”. And you know what? A software project needs the same level of diligence. Gone are the days of “cowboy coding”, where one good programmer could hold everything in their head.

What it takes to create a build or commercial grade software is: a good plan. That old adage “failure to plan is planning to fail” is absolutely true. Here are three of my pre-coding requirements:

1. a product philosophy — the big vision of what you’re building and what differentiates it (the “what”), how it will improve the world, and why you in particular want to build it in the first place (the “why”). It better be compelling, because all projects take longer than you think they will. Plus, you need buy-in from the developers.
2. a manual — you must must must must write the operating manual before the software is built. People may tell you that you’re wasting their time, coders will tell you that they “think in code” and that it’s more efficient to just start coding. They’re full of the waste products from a bull’s breakfast and lunch.
   I assure you that not writing a manual — or having staff that don’t read it — is the single biggest mistake you can make.
   If you cannot easily and succinctly describe how your software works, then the design is wrong. And despite what coders will tell you, they really are in love with their code and don’t want to throw it away and start over. The earlier you catch design flaws, the higher the chance of success. Writing a manual forces better design.
   The purpose of the manual is to test your design. Again: if you can’t explain it in terms simple enough that your grandmother can understand then the software will be too hard for normal humans to operate.
3. low-res mockups — I do these on 3 x 5 cards, and they’re hand-written. I draw on the plain white side of the card, and write any explanations on the lined side. That gives me approximately the information density of a smartphone screen.
   I then number the cards and for each control I write the number of the card that shows what happens if that control is accessed. This allows me to physically play with the “flow” of running the program. By laying the cards out on a flat surface, you can also see the depth of what it takes to get to any particular function.
   You can do pixel-perfect design later to show to investors and the like, but nothing beats a pencil and a stack of 3 x 5 cards when it comes to rapid turnaround. It’s easier emotionally to throw away a card than to change code.

The thing is: when GUI interfaces came along, it started a trend where marketers advertised that no manual was needed. And developers believed the marketing hype. I can see why: that marketing message speaks to the ego of the average developer.
Developers like to believe that their design is clear enough for “users” to automaticaly figure things out. This is demonstrably false. It’s “form over function” — just because it’s pretty doesn’t mean it’s easier to use!

Then there’s efficiency: I was in the education administration industry for a long time, and there were scads of school admin products that were pretty easy to understand, but were inefficient for the school staff that had to use them. The best admin system that I ever saw had on-screen menus with up to 9 single-digit choices. On first use, it seemed old-fashioned and kind of blah. But the secretaries caught on real quick — 1-5-2 might go down 3 layers in a hierarchy to exactly where they wanted to enter or view certain data. To a first-time user, it seemed inefficient, but in short order the navigation literally became muscle memory and couldn’t be beat.

Naturally, this product lost out to sexier (and much slower) GUI-based systems.

While a flashy GUI UX impresses the people who make purchasing decisions, it’s not always what makes the people who USE the software more efficient. Unfortunately, those people are a few layers down in the hierarchy, which is we’re not seeing the productivity improvements that are promised.

You’re writing the manual as a guide for the coders, just as architectural drawings are for the builders, not the tenants/owners. If you can’t describe it succinctly, the design is bad. So before you start your next project, save yourself time by writing the damn manual!

And if you don’t believe me: hire a team of construction workers to build a 40-unit CoHousing project. Tell them start building today, without any architectural drawings and see how well that goes…

It will be entertaining for others to watch, if nothing else.

There’s no doubt that 2020 has brought a lot of “worst things.” But I think one of the worst things from the perspective of human nature has been how well QAnon conspiracy theories have caught on.

Cosmopolitan has a fascinating profile on how “wellness influencers” were caught up in the Trump conspiracy theories:

An extensive list would be pretty difficult, but I wanted to build a list of a typical processor every few years. This gets more difficult in later years as more variations of processors exist and companies stopped giving them clear names. You can find a more complete list at Transistor Count on Wikipedia.

I’m not trying to compare how “good” these numbers are, only showing a progression. I think it’s also important to note that a lot of those transistors are not added complexity but cache, so the progression isn’t necessarily what you think. But it does show increased complexity and the ability to fit more into less space.

Year	CPU	Transistor Count
1975	MOS Technology 6502	4,528
1978	Intel 8086	29,000
1979	Motorola 68000	68,000
1982	Intel 80286	134,000
1984	Motorola 68020	190,000
1985	Intel 80386	275,000
1987	Motorola 68030	273,000
1989	Intel 80486	1,180,235
1990	Motorola 68040	1,200,000
1993	Intel Pentium	3,100,000
1994	PowerPC 601	2,800,000
1997	Pentium II	7,500,000
1999	Pentium III	9,500,000
2000	Pentium 4	42,000,000
2005	Cell	250,000,000
2006	Core 2 Duo Conroe	291,000,000
2008	Intel i7	731,000,000
2011	Six-core Core i7/8-core Xeon E5	2,270,000,000
2014	Xeon Ivy Bridge-EX (15-core)	4,310,000,000

Here are Apple’s CPUs. Again, how “good” these numbers are isn’t the point, just that there’s a progression here.

Year	CPU	Transistor Count
2013	Apple A7	1,000,000,000
2014	Apple A8	2,000,000,000
2016	Apple A10 Fusion	3,300,000,000
2017	Apple A11 Bionic	4,300,000,000
2018	Apple A12 Bionic	6,900,000,000
2019	Apple A13 Bionic	8,500,000,000
2020	Apple A14 Bionic	11,800,000,000
2020	Apple M1	16,000,000,000

My first computer was a TRS-80 Color Computer, based on a Motorola 6809 launched in 1978 with 9,000 transistors. It was about 52mm by 14mm (or 728mm²). The Apple M1 has about 1.7 million times the number of transistors. I don’t think we have exact dimensions of the M1, but it’s certainly smaller than 13mm by 13mm (less than 170mm²).

Chris’s first CPU was the 6502, which launched in 1975 with about half the number of transistors of the 6809.

Yeah, I know… that doesn’t sound like a Technology article. But I got to thinking about how important it is that companies like Apple are striving to becoming energy and CO2 neutral. So I resorted to some arithmetic…

In April 2019 CO2 accounted for 413 millionths of our atmosphere — about 0.0413% of the atmosphere by volume. It’s a little bit higher now.

But “by weight” is different than “by volume”. CO2 is heavy compared to, say, Nitrogen (which is around 78% of the atmosphere).

Fortunately, if the molar weight of both Air and CO2 are known (and they are), there’s an easy way to figure out how much of air’s weight is due to CO2:

0.0413 V% x molar mass of CO2 / molar mass of air = 0.0413 x 44.0095 / 28.97 = 0.06274% of the atmosphere is CO2 (by weight).

Doesn’t seem like that should be a problem, right? It’s not even 1% of the total weight. It’s just 6.274 one-hundredths of a percent of the air by weight!

Well… if you draw a 1” square on your floor, the air above it weighs about 14.7 pounds. That’s called “One Atmosphere” of pressure. Out of that 14.7 pounds, CO2 will be 0.06274% of 14.7 = just 0.0092285 pounds.

I’m almost convinced! For sure there’s no problem! That’s less than 1/100th of a pound!

Except… a square mile is 5280 x 5280 feet, or 63,360” x 63,360” = 4,014,489,600 square inches. So the air above a square mile of the earth will contain 4,014,489,600 x 0.00922285 pounds of CO2. That’s 37,025,035 pounds.

Okay, so maybe we have a problem after all.

37,025,035 pounds is a lot. It’s 18,512 tons. Or 16,794,273 kg.

You see, this is the problem with climate change and a lot of other things in life: us humans are not really good at understanding really small things or really big things. Time, weight, money, atoms, the distance to the next nearest star, how rich Bezos is… all inherent mysteries to our puny brains.

The amount of CO2 in the atmosphere is a problem. A big problem. And it’s still getting worse every year.

But look on the bright side: you can now understand that trees really do come from air. They’re mostly carbon that they’ve absorbed through photosynthesis, water and the CO2 in the air that surrounds us all.

Probably we could use more trees.

According to TechCrunch, Apple is delaying their new anti-tracking features. Instead of shipping with iOS 14, it will ship in an update early next year.

Expected out later this year, iOS 14 will contain a new prompt that asks users whether they would like to opt into this kind of targeted ad tracking. Developers will be able to integrate this prompt into their apps as soon as iOS 14 is released, but they will not be required to, as Apple indicated they would earlier.

Apple won’t force developers to let users opt out of tracking until next year – TechCrunch. (2020, September 3). TechCrunch. https://techcrunch.com/2020/09/03/apple-delay-ios-14-privacy-ad-tracking/

This is bad news for privacy-concerned individuals. Even though Apple already has some of the strongest privacy protections on the market, and shipping in the first calendar quarter of 2021 isn’t that long of a delay, every day a little more damage is done to your privacy.

Over on Daring Fireball, John Gruber doesn’t mince words (though the emphasis is mine):

The entitlement of these fuckers is just off the charts. They have zero right, none, to the tracking they’ve been getting away with. We, as a society, have implicitly accepted it because we never really noticed it. You, the user, have no way of seeing it happen. Our brains are naturally attuned to detect and viscerally reject, with outrage and alarm, real-world intrusions into our privacy. Real-world marketers could never get away with tracking us like online marketers do.

Online privacy should be modeled on real-world privacy. (2020, September 3). Daring Fireball. https://daringfireball.net/2020/09/online_privacy_real_world_privacy

Gruber’s writing on this is terrific and you should read it in its entirety. There are some great real-world analogies. The bit I’ve emphasized is totally the right response to this, and the delay makes me angry. I think everyone should be concerned over this. Every day these fuckers get a little more data about you and it needs to stop.

I’m really curious to know if there are technical problems with this, or if Apple is just giving advertisers more time to adapt. If it’s the latter, they won’t. It’s in advertisers’ best interest to drag their feet as long as possible on this.

MacRumors has a summary of new security features coming in iOS 14.

With every iteration of iOS, Apple adds new privacy features to better protect iPhone and iPad users, and iOS 14 is no exception. This year’s update is worth downloading for the privacy protections alone, which include Privacy Reports in Safari, recording indicators, an option to share approximate location with apps instead of precise locations, and more.

iOS 14 privacy features: Approximate location, clipboard access warnings, limited photos access and more. (2020, August 21). MacRumors. https://www.macrumors.com/guide/ios-14-privacy/

There are a number of really great ideas in here. One of my favorites is how Apple has handled clipboard access. Instead of prompting the user to allow or disallow clipboard reads, iOS just tells the user if it happened. This tells you how often an app is reading the clipboard, rather than just that it has read it once and may read it again in the future.

There are a number of places where clipboard reads are completely innocuous. In our app BeLooped, for instance, we have several screens where the user can type a code that’s received over email, text message, or given out loud by another user. These screens “taste” the clipboard to see if it contains a code when they first open, and again if you switch to another app and back. If it’s not one of our codes, we do nothing with the value.

I’m pretty confident we can explain this behavior to our users: those prompts will only appear “unexpectedly” on screens asking for a code. But if Apple had prompted for permission instead and included an option to let apps always access the clipboard, you’d have no idea when we were accessing it. This bucks Apple’s pattern of asking first and allowing the app to be given “whenever it wants”-type access, but in a particular case where it makes sense.

After I shared my previous post, a friend pointed out this post from earlier this month:

Security questions are a form of “Knowledge based authentication,” or KBA. That is, verifying identity based on a piece of information that “only” the person you’re trying to identify would know.

Why we retired the security question. (2020, July 2). Gandi News. https://news.gandi.net/en/2020/07/why-we-retired-the-security-question/

When you fill out “fun” quizzes you’re actually filling up the bucket on what they know about you.

Wherever possible I’ve started giving random answers to security questions. I store the question and answer in 1Password so I can look it up later. 1Password has a password generator that makes passwords that look like yeJvPGstRdt6hhUau (but longer) which I use for most websites, and a password generator that makes passwords that look like seacoast-shingle-monger-exhibit-harden for passwords I might have to remember or type in. Two words should be good enough for a security answer.

I’ve seen things like the following recently on social media:

• Find out your dominant personality trait (by entering your birth month).
• Find which Chinese year you were born in (by entering your birth year).
• Discover your superhero name by entering the city you were born in and your first pet’s name.

If you participate in fun stuff like this, you’re making it easier for hackers to take control of things and potentially steal from you. And there are people who will participate just because you did.

Every time you follow a link like this and enter information, no matter how “fun” it is, you’ve giving a piece of your identity to someone you don’t know. Would it surprise you to learn that these sites can and do talk to each other? (Not all of them to all, but there’s definitely companies that specialize in this sort of thing.) Each of these pieces of information can be collated.

Once you’ve given up your birth month, it’s known.

Once you’ve given up your birth year, it’s not only known but collated with your birth month. If you’ve entered the birth day (like 13) somewhere, either alone or combined with a month, they’ve got your entire birthday.

Once you’ve given up the city you were born in and your first pet’s name, it’s known and collated with the other personal data.

Now think about the security questions you’ve set up with websites, banks, your insurance company, your cellphone company, your internet provider. They’re things like this, plus mother’s maiden name, name of your third grade teacher, etc. These are just more questions you can be asked in fun personality tests like this. When you are entering seemingly innocuous information to these sites, you are actually giving critical security information away to unknown parties that can be used in the future against you. Most things on the internet are for profit, and if you’re not sure how someone is making a profit from a particular thing it’s probably in a way you don’t like.

Brian Krebs of Krebs on Security wrote this in 2018:

On the surface, these simple questions may be little more than an attempt at online engagement by otherwise well-meaning companies and individuals. Nevertheless, your answers to these questions may live in perpetuity online, giving identity thieves and scammers ample ammunition to start gaining backdoor access to your various online accounts.

Don’t give away historic details about yourself — Krebs on security. (2018, April 9). Krebs on Security. https://krebsonsecurity.com/2018/04/dont-give-away-historic-details-about-yourself/

Please stop making it easy for hackers. Those little games aren’t innocent. This isn’t just about your safety, either. When you share these, your voice provides free advertising for them to people who trust you. There are people who would not otherwise fall for these who will out because you did.

Will Shipley posted an anecdote about Steve Jobs on Twitter. It starts with this tweet:

I feel like people don’t get why Steve Jobs was ultimately so successful. It wasn’t because of his huge ego or because he could be a complete jerk. It wasn’t because of his incredible charisma, although that helped.

Will Shipley. (2020, July 11). Twitter. https://twitter.com/wilshipley/status/1282098099997954048

Please, follow that link to see the whole story. (Twitter will automatically show his thread.)

I don’t have any Steve Jobs stories. I never met him, though I once emailed him a passionate plea to start using breakaway connectors for power on laptops. He didn’t reply, but MagSafe was introduced a couple of years later. I’m sure I’m not the only one who asked, but I’m still glad he listened to users in aggregate.

I strongly believe that a good product is used by its creators and those creators stay in touch with the people that use the product. It’s only in daily use that we uncover the flaws in our products. I know of problems in BeLooped that no more than a handful of people in the world have experienced, and they’re on my list for fixing.

One example is the performance on Android. For whatever reason, our Android programmer wasn’t testing it with a large number of groups. He just wasn’t in a lot of groups. It took Chris and I running it with many groups to determine how slow it could be. We’re now testing the Android client with much larger data sets, and while it will be a while before it performs as well as we’d like we’ve made a lot of improvements.

Another example was on iOS. Every now and then, the forum history would disappear for a user. We had very few reports on this, and no leads that could be reasonably pursued. Because we use the software ourselves so frequently, we were eventually able to notice enough details to find and solve the problem. (It was really complicated, involving a perfect mismatch of several conditions.)

We’ve got more changes requested by users coming, too. We’ve also got a long list of things we want the software to do that will help users, too.