An incredible project from Chris Hytha, documenting the gorgeous art deco architecture scattered across the country:
The prosperity of early 20th century America resulted in a boom of skyscrapers that still tower over cities across the country today. Focusing on the character and craftsmanship on display at the top of these landmark buildings in a way that can’t be seen from street level, the Highrises Collection reveals fascinating details and stories of these distinctly American icons.
An example, the Sun Realty Building in Los Angeles:
Norway is in the planning stages on a tunnel for ships to bypass having to sail around the Stad peninsula, an infamously dangerous spot with high winds, rough waters, and foul weather. It’s a 2km pathway under the base of the peninsula. Based on rough map calculation, it’ll save ferries and other ships over 30 miles of rough sailing into the open Atlantic.
When you look at the fjord-laden coastline of Norway — a thousand miles of sliced up mountains and deep chasms — it’s sort of surprising that this hasn’t been attempted before.
An interesting visual guide to fictional megastructures, like Larry Niven’s Ringworld, Arcologies, and Dyson Spheres:
Megastructures: The Visual Encyclopedia is part science book, part inspirational artbook. It contains everything from orbiting space habitats to solar system spanning stellar engineering projects. Each of the 40 structures in the encyclopedia includes a scientific explanation, followed by paintings and diagrams that bring the concept to life.
With Shape Up, the process of “shaping” new product takes investment to really understand and communicate an idea. But in the process, this precedes the “pitch”, the step where the team reviews a shaped concept and buys into working on it:
According to the book, shapers prepare pitches, pitches go to the betting table, and then the business decides at the last moment which pitches to “bet on.” Teams who follow this to the letter encounter a problem: how do you justify spending the time to shape something when you don’t know if the business will value it?
This easily leads to a situation where shaping is … underdone. Pitches become sales pitches to convince the business to spend time — to bet on — this or that problem or feature request. Those pitches focus on making the case to work on something, and they lack the rigor that goes into shaping a viable technical solution.
The pitch shouldn’t be a sales pitch. At that stage, the business shouldn’t need convincing anymore that a problem is worth sovling; the pitch is to showcase a proposed solution to the problem. So Ryan recently added a stage he calls “framing” to convey the work prior to shaping, where we can communicate the value to the business and the nature of the problem to be solved:
To solve this, I’ve coached teams to introduce a new step before Shaping that we call Framing. Framing is all about the problem and the business value. It’s the work we do to challenge a problem, to narrow it down, and to find out if the business has interest and urgency to solve it.
The framing session is where a feature request or complaint gets evaluated to judge what it really means, who’s really affected, and whether now is the time to try and shape a solution.
Brian Potter wonders why work as taxing and seemingly-mechanically simple as brick masonry is difficult to automate:
Masonry seemed like the perfect candidate for mechanization, but a hundred years of limited success suggests there’s some aspect to it that prevents a machine from easily doing it. This makes it an interesting case study, as it helps define exactly where mechanization becomes difficult - what makes laying a brick so different than, say, hammering a nail, such that the latter is almost completely mechanized and the former is almost completely manual?
Even with the number of problems we’ve solved with machines and AI, something as basic as handling mortar still requires the finesse of human hands, a task which, while actually very hard to learn (it’s why masons are still skilled artisans millennia after its invention), can be taught and repeated on autopilot by masons. It turns out non-Newtonian materials are hard for machines:
There seems to be a few factors at work. One is the fact that a brick or block isn’t simply set down on a solid surface, but is set on top of a thin layer of mortar, which is a mixture of water, sand, and cementitious material. Mortar has sort of complex physical properties - it’s a non-newtonian fluid, and it’s viscosity increases when it’s moved or shaken. This makes it difficult to apply in a purely mechanical, deterministic way (and also probably makes it difficult for masons to explain what they’re doing - watching them place it you can see lots of complex little motions, and the mortar behaving in sort of strange not-quite-liquid but not-quite-solid ways). And since mortar is a jobsite-mixed material, there will be variation in it’s properties from batch to batch.
Will Airtable become the “Metaverse for the Enterprise”? In this detailed analysis, Jan-Erik Asplund dives into the bear and bull cases for what could become of the unicorn spreadsheet successor.
The world Airtable is imagining is a world where knowledge workers no longer have to assess different vendors’ offerings when they want to build a new functionality or experiment with some new type of workflow. Instead, Airtable argues, workers should be able to spin up their own tools using building blocks as simple, but capable of as much complexity, as a set of legos.
A technical piece describing the goals for Facebook’s rewrite of the Messenger app. Interesting to see them avoiding their own React Native for this, and doing things in native iOS/Android.
A humorous post, but has a point. There’s pressure to add new tools that don’t do much but add moving parts and complexity. There’s nothing wrong with Kubernetes, but there’s a place for it (and your small team probably doesn’t need it).
The more you buy in to Kubernetes, the harder it is to do normal development: you need all the different concepts (Pod, Deployment, Service, etc.) to run your code. So you need to spin up a complete K8s system just to test anything, via a VM or nested Docker containers.
And since your application is much harder to run locally, development is harder, leading to a variety of solutions, from staging environments, to proxying a local process into the cluster (I wrote a tool for this a few years ago), to proxying a remote process onto your local machine…
We’ve been doing some thinking on our team about how to systematically address (and repay) technical debt. With the web of interconnected dependencies and micro packages that exists now through tools like npm and yarn, no single person can track all the versions and relationships between modules. This post proposes a “Dependency Drift” metric to quantify how far out of date a codebase is on the latest updates to its dependencies:
Create a numeric metric that incorporates the volume of dependencies and the recency of each of them.
Devise a simple high level A-F grading system from that number to communicate how current a project is with it’s dependencies. We’ll call this a drift score.
Regularly recalculate and publish for open source projects.
Publish a command line tool to use in any continuous integration pipeline. In CI, policies can be set to fail CI if drift is too high. Your drift can be tracked and reported to help motivate the team and inform stakeholders.
Use badges in source control README files to show drift, right alongside the projects’s Continuous Integration status.
A technical write-up on a Google chatbot called “Meena,” which they propose has a much more realistic back-and-forth response technique:
Meena is an end-to-end, neural conversational model that learns to respond sensibly to a given conversational context. The training objective is to minimize perplexity, the uncertainty of predicting the next token (in this case, the next word in a conversation). At its heart lies the Evolved Transformer seq2seq architecture, a Transformer architecture discovered by evolutionary neural architecture search to improve perplexity.
John Gruber uses the iPad’s recent 10th birthday to reflect missed opportunity and how much better a product it could be/could have been:
Ten years later, though, I don’t think the iPad has come close to living up to its potential. By the time the Mac turned 10, it had redefined multiple industries. In 1984 almost no graphic designers or illustrators were using computers for work. By 1994 almost all graphic designers and illustrators were using computers for work. The Mac was a revolution. The iPhone was a revolution. The iPad has been a spectacular success, and to tens of millions it is a beloved part of their daily lives, but it has, to date, fallen short of revolutionary.
I would agree with most of his criticisms, especially on the multitasking UI and the general impenetrability of the gesturing interfaces. As a very “pro iPad” user, I would love to see a movement toward the device coming into its own as a distinctly different platform than macOS and desktop computers. It has amazing promise even outside of creativity (music, art) and consumption. With the right focus on business model support, business productivity applications could be so much better.
Bloomberg has been publishing this video series on future technologies called “Giant Leap.” It’s well-done and a nice use of YouTube as a medium.
This one explores a number of new companies doing R&D in microgravity manufacturing — from biological organ “printing” to creation of high-quality fiber optic materials. There are still some challenges ahead to unlock growth of space as a manufacturing environment, but it feels like we’re on the cusp of a new platform for industrial growth in the near future.
This is a fascinating article from a 2004 issue of Engineering & Science that investigates the “Tunnel of Samos”, constructed on the eponymous Greek island 2500+ years ago.
One of the greatest engineering achievements of ancient times is a water tunnel, 1,036 meters (4,000 feet) long, excavated through a mountain on the Greek island of Samos in the sixth century B.C. It was dug through solid limestone by two separate teams advancing in a straight line from both ends, using only picks, hammers, and chisels. This was a prodigious feat of manual labor. The intellectual feat of determining the direction of tunneling was equally impressive. How did they do this? No one knows for sure, because no written records exist. When the tunnel was dug, the Greeks had no magnetic compass, no surveying instruments, no topographic maps, nor even much written mathematics at their disposal. Euclid’s Elements, the first major compendium of ancient mathematics, was written some 200 years later.
Since the engineers of the time dug the tunnel from both directions simultaneously, meeting in the middle, it required advanced knowledge of surveying and mathematics techniques to get the geometry just right. An inaccurate elevation, direction, or location by even a couple of degrees or inches would mean widely missing the mark to join the two tunnels. The author investigates a few possible methods for how the ancient Greeks could’ve completed the feat. A few techniques and simple tools would’ve been required, but a research team was able to recreate a potential method. Amazing that with such primitive technology they could’ve completed such a monumental project.
