Orie Steele

Have you ever thought about how compliance laws are a lot like design systems? I recently spoke with Joe Toscano, founder of DataGrade, and he made a fascinating comparison. Joe explained how Brad Frost's atomic design methodology took an engineering approach to design: → Creating standardized elements → Templatizing them → Scaling them across a system This led to the rise of human interface guidelines (HIGs) from tech giants like Google, Apple, and IBM. But here's where it gets really interesting: Joe argued that privacy laws and regulations are like the ultimate HIG for product design. Just like how HIGs provide rules and constraints for design systems... Compliance laws set guardrails for what we can and can't do with user data. If we design something that isn't compliant, it doesn't matter how sleek the UI is. Legal requirements become the top-level framework we have to design within. That's what got Joe into studying laws - to understand this new "design system" for building products. So next time you're cursing a lengthy legal doc or trying to make sense of GDPR... Remember, it's all just part of the atomic design of compliance. — Do you agree with the analogy of compliance laws as the ultimate design system? Why or why not? Hear more of Joe's unique perspectives on the intersection of product, privacy, and law on the latest episode of The Minimum Viable Podcast.

4

"If you're relying on AI not becoming 100X better, you're about to get steamrolled." -- Jason Warner, ex-CTO of Github and CEO of poolside How we code and build software is being rapidly transformed with AI. Sitting down with Jason the future looks clearer. Over the next 5 years: 🌏 All 7 billion people can code 🏗️ Search bars will spit out software 🔋 AI will generate its way out of data scarcity 🌩️ Foundation models to become cloud companies I unpack the 5 year frontier of software development in Future of Code: AI-led Software Development https://lnkd.in/gze2QSbu #AI #Software #Code

11

GM! Excellent post from my colleague at MIN3 - Katie H.. It is the latest in her series of video explainers covering some of the demo AI and crypto products that MIN3 has created to deliver real business value in a way that is seamless to the customer. Earlier in the series she introduced us to her Grandma (courtesy of our AI artwork tool). In this post on our Onchain Wallet Creation Tool, see if you can spot the part where she had to edit out swearing at herself for messing up the take 🤬 😁 On a serious note, as the tokenisation of real world assets (both tangible and intangible) explodes, many companies are going to be selling digital assets (NFTs etc.) to their customers. As we pointed out in Monday's post (see link in the comments), the native user experience associated with onchain wallets (where these assets will be managed and secured) is currently too confusing for the average user. That's why we've created tools like the one that Katie is demo-ing. We can seamlessly create an onchain wallet for a customer at any point in a user journey (e.g. at sign-up), and allow customers to access these wallets (and their contents) through the standard web or app experience (e.g. through their Account page via single sign-on). The customer doesn't even need to know that they are dealing with onchain assets. ⛓ However, if they want to full custody their digital assets, the tool allows them to transfer them to another wallet without having to worry about gas fees etc. Simple! ⛽ #crypto #blockchain #technology

5

8 Comments

If you are working with Docker... I highly recommend looking at the Slim toolkit. https://lnkd.in/gX_Gb9Kf Why? Slim allows developers to inspect, optimize, and debug their containers using its xray, lint, build, debug, run, images, merge, registry, vulnerability (and other) commands. It simplifies and improves your developer experience building, customizing and using containers. It makes your containers better, smaller and more secure while providing advanced visibility and improved usability working with the original and minified containers. Don't change anything in your container image; minify it by up to 30x to make it secure, too! Optimizing images isn't the only thing it can do, though. It can also help you understand and author better container images. Keep doing what you are doing. No need to change anything. Use the base image you want. Use the package manager you want. Don't worry about hand-optimizing your Dockerfile. You shouldn't have to throw away your tools and your workflow to have small container images. Node.js application images: from ubuntu:14.04 - 432MB => 14MB (minified by 30.85X) from debian:jessie - 406MB => 25.1MB (minified by 16.21X) from node:alpine - 66.7MB => 34.7MB (minified by 1.92X) from node:distroless - 72.7MB => 39.7MB (minified by 1.83X) Go application images: from golang:latest - 700MB => 1.56MB (minified by 448.76X) from ubuntu:14.04 - 531MB => 1.87MB (minified by 284.10X) from golang:alpine - 258MB => 1.56MB (minified by 165.61X) from centos:7 - 615MB => 1.87MB (minified by 329.14X) Rust application images: from rust:1.31 - 2GB => 14MB (minified by 147.16X) Java application images: from ubuntu:14.04 - 743.6 MB => 100.3 MB

4