Apple recommends adding some launch arguments and environment variables to your Xcode schemes to catch and debug Core Data problems.
Josh Betz
Made with 🧀 in Madison
Made with 🧀 in Madison
Apple recommends adding some launch arguments and environment variables to your Xcode schemes to catch and debug Core Data problems.
I built something over the holiday break to generate constantly updating RSS feeds (or Atom or JSON feeds) at any frequency you want. Each entry has sample content (generated by ChatGPT) and links to a corresponding web page. These pages include a randomly generated image and OpenGraph meta. The homepage even has feed discovery meta.
Companies that want to reduce the cost of their frontend tech becoming obsoleted so often should be looking to get back to fundamentals. Your teams should be working closer to the web platform with a lot less complex abstractions. We need to relearn what the web is capable of and go back to that.
You should really go read the whole article. There is a lot that resonates with me.
The ability to work on “legacy” code is a valuable skill that I specifically look for when I’m hiring. It’s fine to want to make things better and follow new conventions, but it shouldn’t be a blocker to being productive. Business doesn’t stop and wait while the app is rewritten to use React Hooks or whatever.
People that are learning the current tech ecosystem are absolutely not learning web fundamentals. They are too abstracted away. And when the stack changes again, these folks are going to be at a serious disadvantage when they have to adapt away from what they learned. It’s a deep disservice to people’s professional careers, and it’s going to cause a lot of heartache later.
I don’t work on the frontend very often these days, but I’m always thankful that I learned web development before React. I started my career reading CSS Tricks and deploying CSS, Javascript, and HTML files with FTP 🤣 I’ve noticed full stack engineers on social media worried about how fast frontend tech moves, but I think if you know these fundamentals, learning a new framework is not a big deal.
Imgproxy is an open source image processing proxy service. You supply image URLs and processing parameters in the URL. It downloads the image and applies the filters you’ve specified. It can also automatically serve WebP or AVIF images to clients that support those formats.
I started by installing imgproxy on the DigitalOcean App Platform. You can use the Docker image directly from Dockerhub. I recommend reading through the configuration options for more information about self hosting imgproxy. I’ve limited the allowed sources with IMGPROXY_ALLOWED_SOURCES and enabled WebP and AVIF detection.
IMGPROXY_ENABLE_AVIF_DETECTION=true
IMGPROXY_ENABLE_WEBP_DETECTION=true
IMGPROXY_ALLOWED_SOURCES=https://josh.blogDigitalOcean uses Cloudflare for the App Platform, so you can use the subdomain they provide or point a domain you control at the app.
To replace the WordPress image URLs with imgproxy URLs, I’ve written a small WordPress plugin. This does a few things.
srcset image URLs.This is similar to other image CDNs, but you can self host the processing service and host the images on your own domain.
Blurhash generates a short string that represents a blurry version of the image. These are used as placeholders while images are downloaded. On a fast internet connection you may not even notice this. I like to use a lot of large images, so it’s nice to have a representative placeholder while they download.
NASA’s image of the day is a gold mine for new wallpapers.