Full Width [alt+shift+f] Shortcuts [alt+shift+k] TRY SIMPLE MODE
Sign Up [alt+shift+s] Log In [alt+shift+l]
36
A little over a week ago, an unnecessary dick joke was sent to a mailing list I'm on. It's a mailing list related to a conference I go to, and the joke added absolutely no value to the conversation. Another young woman and I criticized this behavior, citing how it pushes women away from tech and conferences like this one. We were met with lots of men telling us that we were either being too sensitive, violating their First Amendment rights, or failing to note the large body of casual sexism towards men in the world. The men on this list constantly need to be reminded that women are the subject of the overwhelming majority of sexualized jokes, both within tech culture and in general. They consistently ignore how those jokes are part of the thousands of systemic paper cuts that, unsurprisingly, push women out of tech. Some men even had the gall to tell us off by saying that this wasn't the reason we don't have more women in tech because all the blame should fall on the leaky pipeline...
over a year ago

Comments

Improve your reading experience

Logged in users get linked directly to articles resulting in a better reading experience. Please login for free, it takes less than 1 minute.

More from Liz Denys

Bike Brooklyn! zine

I've been biking in Brooklyn for a few years now! It's hard for me to believe it, but I'm now one of the people other bicyclists ask questions to now. I decided to make a zine that answers the most common of those questions: Bike Brooklyn! is a zine that touches on everything I wish I knew when I started biking in Brooklyn. A lot of this information can be found in other resources, but I wanted to collect it in one place. I hope to update this zine when we get significantly more safe bike infrastructure in Brooklyn and laws change to make streets safer for bicyclists (and everyone) over time, but it's still important to note that each release will reflect a specific snapshot in time of bicycling in Brooklyn. All text and illustrations in the zine are my own. Thank you to Matt Denys, Geoffrey Thomas, Alex Morano, Saskia Haegens, Vishnu Reddy, Ben Turndorf, Thomas Nayem-Huzij, and Ryan Christman for suggestions for content and help with proofreading. This zine is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License, so you can copy and distribute this zine for noncommercial purposes in unadapted form as long as you give credit to me. Check out the Bike Brooklyn! zine on the web or download pdfs to read digitally or print here!

3 months ago 38 votes
The night sky and finding hope in the dark

I found inspiration for this pitcher's glaze design in the night sky. Whenever I feel lost, I know I can always look up and be under the same night sky, no matter where I am. Whenever I feel alone, I know I can always look up and feel connected to humanity, everyone else looking up at the same sky. Whenever I feel all is lost, the vast darkness in the night sky reminds me there are so many possibilities out there that I haven't even thought of yet. My studio practice is on a partial pause for an unknown amount of time right now; every piece I make is stuck in the greenware stage as I continue to save up to buy kilns and build out the glaze and kiln area. In some moments, this pause feels like a rare opportunity to take time to make more experimental and labor intensive pieces, but in other moments, I am overwhelmed by the feeling that pieces without a completion timeline on the horizon are just not worth doing. It's easy to bask in fleeting bursts of inspiration; it's harder to push through the periods where nothing feels worth doing. It's especially when the waves of anxiety about the unknown future of my studio practice and the waves of anxiety about the direction of the US government and the future of my country come at me at the same time. I try to ground myself, to keep myself from spiraling. I name things I can see, smell, hear. At night, I look to the dark sky. When I can, I reread Rebecca Solnit's Hope in the Dark: Hope locates itself in the premises that we don't know what will happen and that in the spaciousness of uncertainty is room to act. When you recognize uncertainty, you recognize that you may be able to influence the outcomes–you alone or you in concert with a few dozen or several million others. Hope is an embrace of the unknown and the unknowable, an alternative to the certainty of both optimists and pessimists. Optimists think it will all be fine without our involvement; pessimists take the opposite position; both excuse themselves from acting. It's the belief that what we do matters even though how and when it may matter, who and what it may impact, are not things we can know beforehand. We may not, in fact, know them afterward either, but they matter all the same, and history is full of people whose influence was most powerful after they were gone. May we all find hope in the dark and choose to act.

6 months ago 57 votes
Rising sea levels, eroding beaches, melting ice caps

When I was glazing this v60-style cone, I was thinking of rising sea levels, eroding beaches, and melting ice caps. Trying to tackle large challenges like climate change is overwhelming in the best of times, and these are not the best of times. There are many things we can personally do to reduce our carbon footprints and fight climate change, but If we want to have any chance to succeed, we need to join together and organize. If you're new to organizing, connect with local groups already doing the work you're interested in, and don't forget to look for groups pushing for change outside of just the national stage. Creating more dense walkable, transit-oriented communities is one of our strongest tools for a sustainable, climate friendly future. Generally, the bulk this work in the US happens at the state and local levels. In addition to the climate benefits, it's essential work to keep communities together and fight displacement. I personally spend a lot of my spare time organizing locally around this issue to help ensure NYC and New York State stay places everyone can thrive. I focus especially on pro-housing policies and improving transportation options and reliability so climate-friendly, less car-dependent lifestyles - and New York's relative safety - can be for everyone.

6 months ago 46 votes
Printable shrinkage rulers

Clay shrinks as it dries and even more as it's fired, so it's useful to have a way to estimate the final size of in-progress work - especially if you're making multiples or trying to fit pieces together. One way to do this is with shrinkage rulers. I figured I'd design my own shrinkage rulers and provide a way for folks to make them themselves since ceramic tool costs can add up. To make your shrinkage rulers: Download either the colorful printable shrinkage rulers or black and white printable shrinkage rulers. Print at 100% size. (These files are both 400 dpi.) Verify that the 0% shrinkage standard ruler at the top matches the size of an existing regular ruler you have. This quick calibration step will make sure nothing out of scale during printing! Cut out your rulers. Optionally, laminate or cover in packing tape to help them last longer. To use your shrinkage rulers: If you're using commercial clay, look up how much your clay is estimated to shrink. If you're using a blend of clays or custom clays, you'll have to calculate how much your clay shrinks. An easy way to do this is measure the length of a wet piece right after you form them and again after it's been through its glaze firing. You can then calculate the estimated shrinkage rate: Pick the shrinkage ruler that corresponds to your clay's shrinkage rate. If you're between shrinkage rates, you can estimate with a nearby size. Remember that shrinkage rates are estimates, and a piece's actual shrinkage depends on many variables, including how wet your clay is and how close it is to it's original composition (this can change with repeated recycling). Measure your wet piece with the shrinkage ruler! The length shown is the expected length your piece's dimension will be when fired. The fine print: Reminder that shrinkage rulers only give estimated lengths! You're welcome to print these shrinkage rulers for yourself or your business. You may use the printed shrinkage rulers privately, even in commercial applications (I hope they help your ceramic art and business!), provided you do not redistribute or resell the shrinkage rulers themselves in any form, digital or physical. Footnotes If you're working on a jar or something else that needs to fit together tightly, it's better not to rely on shrinkage rulers to get a perfect fit. In my experiences, you ideally want to make the vessel and the lid as close in time as possible and have them dry together and fire together through as many phases as possible.↩

10 months ago 81 votes
Notes on cone 6 clay bodies, part 2

I'm continuing my clay body reviews series with two very heavily grogged "sculpture" clays I've used. Note that I currently practice in a community studio that glaze fires to cone 6 in oxidation, so my observations reflect that. Standard 420 Sculpture: Cone 6: average shrinkage 8.0%, absorption 1.5% Light straw when fired to cone 6: more yellow/beige than most white stonewares so the color is something to consider in your final vision (or engobe in something else) So much grog that it’s best described as working with wet sand, non-derogatory I've made complicated open coil-based structures with this clay that have been formed across many studio sessions over a couple days, and they've survived without cracking! Wet clay attaches readily to leather hard and even slightly dry clay. Wrapping my works in dry cleaning bags until done and dry before bisque was enough - I was worried I'd have to make a damp box, but not with this clay! The grog is white and grey, and it comes in a variety of sizes, including some that is visually rather large. The grog really shows if you sand to smooth the surface. I typically dislike how this looks - the result ends up looking more like concrete than clay. If you use this for functional ware or anything you move around a lot, you'll certainly want to sand the bottom since the groggy surface is extra rough to protect tables and counters. Burnishing alone doesn't usually make this clay smooth. Can be thrown when very soft, but your hands will feel scratched if you're not used to it! Angled slab joins join readily, and support coils press in quickly and easily. Some members of my studio prefer to make plates with this clay because the high level of grog significantly reduces warping. I personally prefer to make plates with clays with far less grog that I dry very slowly. High palpable grog content means a weaker object, and I prefer more strength in objects that are handled frequently. Can be marbled with 798, but needs to dry slowly. Standard 420's straw color shows in the unglazed section of this planter's drip tray, and there's also some flashing from the glaze near the edges. I sanded the base of this piece so the slightly rough surface of Standard 420 wouldn't scratch tables, and you can see the contrast between the sanded bottom (outside) layer where the varied grogs are revealed and the rougher surfaces of the other layers where they are still covered by clay particles. This handbuilt planter was made of Standard 798 over multiple studio sessions. The sculptural coil structures attached readily with my regular slip and score process, and it dried evenly enough to not crack with my regular process of drying under a single plastic dry-cleaning bag. This coiled wall art piece was made out of equal parts Standard 112 and Standard 420 wedged fully together. There's still ample grog in this hybrid clay body to work the same as the Standard 798 planter's coiled structure. Standard 798 Black Sculpture: Cone 6: average shrinkage 10%, absorption 1.0% Dark brown when wet, fires to a gorgeous black at cone 6 when unglazed. Clear glazes will make this clay look brown, so you need to use a black like Coyote Black or Amaco Obsidian to preserve the black color if you want to glaze it. So much grog that it’s best described as working with wet sand, non-derogatory. The grog is white, and provides a lovely contrast when on the surface or sanded to be revealed. Like 420, you'll probably want to sand the bottom of anything you'll pick up and put down more than once. Very similar working qualities to 420 - a true joy for handbuilding! Can be marbled with 420, but needs to dry slowly.

a year ago 109 votes

More in programming

The McPhee method

When I first started writing professionally, for the Atlantic’s website, I taught myself “reporting” with a simple self-made curriculum unfolding over six or seven articles. The first two pieces I wrote from my head, with reference to things I already knew or to books I’d read. For the third, I layered in firsthand experience, when […]

13 hours ago 4 votes
The future of large files in Git is Git

.title {text-wrap:balance;} #content > p:first-child {text-wrap:balance;} If Git had a nemesis, it’d be large files. Large files bloat Git’s storage, slow down git clone, and wreak havoc on Git forges. In 2015, GitHub released Git LFS—a Git extension that hacked around problems with large files. But Git LFS added new complications and storage costs. Meanwhile, the Git project has been quietly working on large files. And while LFS ain’t dead yet, the latest Git release shows the path towards a future where LFS is, finally, obsolete. What you can do today: replace Git LFS with Git partial clone Git LFS works by storing large files outside your repo. When you clone a project via LFS, you get the repo’s history and small files, but skip large files. Instead, Git LFS downloads only the large files you need for your working copy. In 2017, the Git project introduced partial clones that provide the same benefits as Git LFS: Partial clone allows us to avoid downloading [large binary assets] in advance during clone and fetch operations and thereby reduce download times and disk usage. – Partial Clone Design Notes, git-scm.com Git’s partial clone and LFS both make for: Small checkouts – On clone, you get the latest copy of big files instead of every copy. Fast clones – Because you avoid downloading large files, each clone is fast. Quick setup – Unlike shallow clones, you get the entire history of the project—you can get to work right away. What is a partial clone? A Git partial clone is a clone with a --filter. For example, to avoid downloading files bigger than 100KB, you’d use: git clone --filter='blobs:size=100k' <repo> Later, Git will lazily download any files over 100KB you need for your checkout. By default, if I git clone a repo with many revisions of a noisome 25 MB PNG file, then cloning is slow and the checkout is obnoxiously large: $ time git clone https://github.com/thcipriani/noise-over-git Cloning into '/tmp/noise-over-git'... ... Receiving objects: 100% (153/153), 1.19 GiB real 3m49.052s Almost four minutes to check out a single 25MB file! $ du --max-depth=0 --human-readable noise-over-git/. 1.3G noise-over-git/. $ ^ 🤬 And 50 revisions of that single 25MB file eat 1.3GB of space. But a partial clone side-steps these problems: $ git config --global alias.pclone 'clone --filter=blob:limit=100k' $ time git pclone https://github.com/thcipriani/noise-over-git Cloning into '/tmp/noise-over-git'... ... Receiving objects: 100% (1/1), 24.03 MiB real 0m6.132s $ du --max-depth=0 --human-readable noise-over-git/. 49M noise-over-git/ $ ^ 😻 (the same size as a git lfs checkout) My filter made cloning 97% faster (3m 49s → 6s), and it reduced my checkout size by 96% (1.3GB → 49M)! But there are still some caveats here. If you run a command that needs data you filtered out, Git will need to make a trip to the server to get it. So, commands like git diff, git blame, and git checkout will require a trip to your Git host to run. But, for large files, this is the same behavior as Git LFS. Plus, I can’t remember the last time I ran git blame on a PNG 🙃. Why go to the trouble? What’s wrong with Git LFS? Git LFS foists Git’s problems with large files onto users. And the problems are significant: 🖕 High vendor lock-in – When GitHub wrote Git LFS, the other large file systems—Git Fat, Git Annex, and Git Media—were agnostic about the server-side. But GitHub locked users to their proprietary server implementation and charged folks to use it.1 💸 Costly – GitHub won because it let users host repositories for free. But Git LFS started as a paid product. Nowadays, there’s a free tier, but you’re dependent on the whims of GitHub to set pricing. Today, a 50GB repo on GitHub will cost $40/year for storage. In contrast, storing 50GB on Amazon’s S3 standard storage is $13/year. 😰 Hard to undo – Once you’ve moved to Git LFS, it’s impossible to undo the move without rewriting history. 🌀 Ongoing set-up costs – All your collaborators need to install Git LFS. Without Git LFS installed, your collaborators will get confusing, metadata-filled text files instead of the large files they expect. The future: Git large object promisors Large files create problems for Git forges, too. GitHub and GitLab put limits on file size2 because big files cost more money to host. Git LFS keeps server-side costs low by offloading large files to CDNs. But the Git project has a new solution. Earlier this year, Git merged a new feature: large object promisers. Large object promisors aim to provide the same server-side benefits as LFS, minus the hassle to users. This effort aims to especially improve things on the server side, and especially for large blobs that are already compressed in a binary format. This effort aims to provide an alternative to Git LFS – Large Object Promisors, git-scm.com What is a large object promisor? Large object promisors are special Git remotes that only house large files. In the bright, shiny future, large object promisors will work like this: You push a large file to your Git host. In the background, your Git host offloads that large file to a large object promisor. When you clone, the Git host tells your Git client about the promisor. Your client will clone from the Git host, and automagically nab large files from the promisor remote. But we’re still a ways off from that bright, shiny future. Git large object promisors are still a work in progress. Pieces of large object promisors merged to Git in March of 2025. But there’s more to do and open questions yet to answer. And so, for today, you’re stuck with Git LFS for giant files. But once large object promisors see broad adoption, maybe GitHub will let you push files bigger than 100MB. The future of large files in Git is Git. The Git project is thinking hard about large files, so you don’t have to. Today, we’re stuck with Git LFS. But soon, the only obstacle for large files in Git will be your half-remembered, ominous hunch that it’s a bad idea to stow your MP3 library in Git. Edited by Refactoring English Later, other Git forges made their own LFS servers. Today, you can push to multiple Git forges or use an LFS transfer agent, but all this makes set up harder for contributors. You’re pretty much locked-in unless you put in extra effort to get unlocked.↩︎ File size limits: 100MB for GitHub, 100MB for GitLab.com↩︎

2 days ago 11 votes
Just a Little More Context Bro, I Promise, and It’ll Fix Everything

Conrad Irwin has an article on the Zed blog “Why LLMs Can't Really Build Software”. He says it boils down to: the distinguishing factor of effective engineers is their ability to build and maintain clear mental models We do this by: Building a mental model of what you want to do Building a mental model of what the code does Reducing the difference between the two It’s kind of an interesting observation about how we (as humans) problem solve vs. how we use LLMs to problem solve: With LLMs, you stuff more and more information into context until it (hopefully) has enough to generate a solution. With your brain, you tweak, revise, or simplify your mental model more and more until the solution presents itself. One adds information — complexity you might even say — to solve a problem. The other eliminates it. You know what that sort of makes me think of? NPM driven development. Solving problems with LLMs is like solving front-end problems with NPM: the “solution” comes through installing more and more things — adding more and more context, i.e. more and more packages. LLM: Problem? Add more context. NPM: Problem? There’s a package for that. Contrast that with a solution that comes through simplification. You don’t add more context. You simplify your mental model so you need less to solve a problem — if you solve it at all, perhaps you eliminate the problem entirely! Rather than install another package to fix what ails you, you simplify your mental model which often eliminates the problem you had in the first place; thus eliminating the need to solve any problem at all, or to add any additional context or complexity (or dependency). As I’m typing this, I’m thinking of that image of the evolution of the Raptor engine, where it evolved in simplicity: This stands in contrast to my working with LLMs, which often wants more and more context from me to get to a generative solution: I know, I know. There’s probably a false equivalence here. This entire post started as a note and I just kept going. This post itself needs further thought and simplification. But that’ll have to come in a subsequent post, otherwise this never gets published lol. Email · Mastodon · Bluesky

2 days ago 5 votes
How to Leverage the CPU’s Micro-Op Cache for Faster Loops

Measuring, analyzing, and optimizing loops using Linux perf, Top-Down Microarchitectural Analysis, and the CPU’s micro-op cache

2 days ago 9 votes
Omarchy micro-forks Chromium

You can just change things! That's the power of open source. But for a lot of people, it might seem like a theoretical power. Can you really change, say, Chrome? Well, yes! We've made a micro fork of Chromium for Omarchy (our new 37signals Linux distribution). Just to add one feature needed for live theming. And now it's released as a package anyone can install on any flavor of Arch using the AUR (Arch User Repository). We got it all done in just four days. From idea, to solicitation, to successful patch, to release, to incorporation. And now it'll be part of the next release of Omarchy. There are no speed limits in open source. Nobody to ask for permission. You have the code, so you can make the change. All you need is skill and will (and maybe, if you need someone else to do it for you, a $5,000 incentive 😄).

3 days ago 6 votes