Here’s some Mac mini, iPad Pro, MacBook shots

https://t.co/C9W4D96e2K

https://t.co/qa6JsO8zbE

Here’s an interesting rig - MacBook screen sharing a Mac mini which is running Xcode and testing suite which auto runs app on several devices - personal build server. You could never connect the mini to a display from moment of purchase, ever

If you cover the Face ID camera it will tell you it’s covered and where the camera is located with an on screen arrow

Here’s the iPad Pro’s new Apple Pencil mounting

Oh and if you look closely you’ll see the new pencil menu

More from Tech

Venkatesh Rao
@vgr

There are only 3 real challenges to free speech at the tech level a) the need for CDNs at scale b) distortions of net neutrality c) nation-state firewalls.

All other claims are about social governance on private sites, where applying free speech doctrine is a stretch at best

Baseline free speech has expanded modestly since 1776 or whatever your reference point is.

About 20% beyond core case of government-critical speech in formally public spaces and media I'd say.

You can (for example) have more kinds of conversations in a bar without getting punched or kicked out by other patrons or management. You can teach more things in colleges than 100 years ago.

That's a genuine de facto increase in practical, informal free speech/expression.

But online free "speech" is, as @reneed has pointed out, not an expansion of free speech at all, but an expansion of reach. It is like the secondary freedom of the press to print as many copies as they can afford, not primary freedom to say what they want

If a newspaper wants to print more copies it has buy more printing equipment and front more upfront costs. Reach for a paper publication is not "free", but a function of desired circulation, which in turn is a function of demand prediction etc. But that logic is obscured online.

Nicolas
@necolas

A brief analysis and comparison of the CSS for Twitter's PWA vs Twitter's legacy desktop website. The difference is dramatic and I'll touch on some reasons why.

Legacy site *downloads* ~630 KB CSS per theme and writing direction.

6,769 rules
9,252 selectors
16.7k declarations
3,370 unique declarations
44 media queries
36 unique colors
50 unique background colors
46 unique font sizes
39 unique z-indices

https://t.co/qyl4Bt1i5x

PWA *incrementally generates* ~30 KB CSS that handles all themes and writing directions.

735 rules
740 selectors
757 declarations
730 unique declarations
0 media queries
11 unique colors
32 unique background colors
15 unique font sizes
7 unique z-indices

https://t.co/w7oNG5KUkJ

The legacy site's CSS is what happens when hundreds of people directly write CSS over many years. Specificity wars, redundancy, a house of cards that can't be fixed. The result is extremely inefficient and error-prone styling that punishes users and developers.

The PWA's CSS is generated on-demand by a JS framework that manages styles and outputs "atomic CSS". The framework can enforce strict constraints and perform optimisations, which is why the CSS is so much smaller and safer. Style conflicts and unbounded CSS growth are avoided.

Patrick McKenzie
@patio11

A thread on HN about bad code in legacy projects both makes me think how little we've learned as a discipline over the years and, honestly, how little credit we give ourselves for some pretty major

Fun going down this list and thinking: "Hmm, plausible at a well-run modern software shop", "Hmm, possible, but requires implausible tradeoffs", "Literally disallowed by languages", and "If you were to attempt doing that our test suite wouldn't let you merge."

I think we as an industry celebrate (not quite the right word) failure too much and don't celebrate success nearly enough. There is no DailyWTF for competent execution, word of which generally stays pretty local to the source while incompetence passes into legend.

Alrighty let me try to thread the needle on being the change I want to see in the world while not giving away anything that will get me in trouble:

Ruby has wonderful developer ergonomics. Typed languages are easier for machines to guarantee the correctness of. We built a type checker for Ruby (and I believe it is slated for OSS release sometime).

c.f.

Ameya
@Finstor85

After getting good feedback on yesterday's thread on #routemobile I think it is logical to do a bit in-depth technical study. Place #twilio at center, keep #routemobile & #tanla at the periphery & see who is each placed.

So I have been studying this entire communication layer as its relevance is ever growing with more devices coming online, staying connected, and relying on real-time communication. Not that this domain under penetrated, but there is a change underway.
— Ameya (@Finstor85) February 10, 2021

This thread is inspired by one of the articles I read on the-ken about #postman API & how they are transforming & expediting software product delivery & consumption, leading to enhanced developer productivity.

We all know that #Twilio offers host of APIs that can be readily used for faster integration by anyone who wants to have communication capabilities. Before we move ahead, let's get a few things cleared out.

Can anyone build the programming capability to process payments or communication capabilities? Yes, but will they, the answer is NO. Companies prefer to consume APIs offered by likes of #Stripe #twilio #Shopify #razorpay etc.

This offers two benefits - faster time to market, of course that means no need to re-invent the wheel + not worrying of compliance around payment process or communication regulations. This makes entire ecosystem extremely agile

Zeke Hausfather
@hausfath

There has been a lot of discussion about negative emissions technologies (NETs) lately. While we need to be skeptical of assumed planetary-scale engineering and wary of moral hazard, we also need much greater RD&D funding to keep our options open. A quick thread: 1/10

Energy system models love NETs, particularly for very rapid mitigation scenarios like 1.5C (where the alternative is zero global emissions by 2040)! More problematically, they also like tons of NETs in 2C scenarios where NETs are less essential. https://t.co/M3ACyD4cv7 2/10

There is a lot of confusion about carbon budgets and how quickly emissions need to fall to zero to meet various warming targets. To cut through some of this morass, we can use some very simple emission pathways to explore what various targets would entail. 1/11 pic.twitter.com/Kriedtf0Ec
— Zeke Hausfather (@hausfath) September 24, 2020

In model world the math is simple: very rapid mitigation is expensive today, particularly once you get outside the power sector, and technological advancement may make later NETs cheaper than near-term mitigation after a point. 3/10

This is, of course, problematic if the aim is to ensure that particular targets (such as well-below 2C) are met; betting that a "backstop" technology that does not exist today at any meaningful scale will save the day is a hell of a moral hazard. 4/10

Many models go completely overboard with CCS, seeing a future resurgence of coal and a large part of global primary energy occurring with carbon capture. For example, here is what the MESSAGE SSP2-1.9 scenario shows: 5/10