Mojo is one to keep an eye on for #3.
5,521 karma · joined November 4, 2010
For example:
https://tina.io/blog/Introducing-Editorial-Workflow-Features...
We need more like this that doesn't require a SaaS-backed "business or enterprise plan", though.
Would be great to make the tech more accessible to those without the skills to recompile and deploy. It's such a fast and affordable way to build websites, but existing tools like Hugo assume a lot from users that can put the tooling out of reach.
(Enjoyed your write-up too. I wrote the original version of html-to-markdown that you used in your migration; it's great to see it's still useful.)
https://github.com/WordPress/wordpress-playground/issues/69
There’s likely more work that could be done to make this viable, though (or Cloudflare could raise limits).
https://github.com/sponsors/ValeLang
Let's use this post's time on the front page to help the project meet its $3,000/month goal.
I'd love to help Evan work on this full time (I'm a sponsor). A fast and safe language that's also fun to prototype with is worth supporting.
Did not expect Fediverse integration from Meta.
[1] https://9to5google.com/2023/07/03/threads-instagram-app-coun...
https://github.com/arximboldi/ewig
https://github.com/arximboldi/immer
See the author instantly opening a ~1GB text file with async loading, paging through, copying/pasting, and undoing/redoing in their prototype “ewig” text editor about 27 minutes into their talk here:
https://m.youtube.com/watch?v=sPhpelUfu8Q
It’s backed by a “vector of vectors” data structure called a relaxed radix balanced tree:
https://infoscience.epfl.ch/record/169879/files/RMTrees.pdf
That original paper has seen lots of attention and attempts at performance improvements, such as:
> Mojo is a general purpose language and can be used to replace C use cases like Rust does etc, but that isn't where we're focusing initial development. That doesn't mean we're excluding it, just that the libraries etc aren't the focus for us to build. We hope the community will be interested in filling that in and building out the use cases in time though.
https://github.com/modularml/mojo/discussions/302#discussion...
https://hitchhikers.fandom.com/wiki/Rory_Award
Definitely funnier as “Belgium”.
> One general point. A thing I have had said to me over and over again whenever I’ve done public appearances and readings and so on in the States is this: Please don’t let anyone Americanise it! We like it the way it is!
> There are some changes in the script that simply don’t make sense. Arthur Dent is English, the setting is England, and has been in every single manifestation of The Hitchhiker's Guide to the Galaxy ever. The ‘Horse and Groom’ pub that Arthur and Ford go to is an English pub, the ‘pounds’ they pay with are English (but make it twenty pounds rather than five – inflation). So why suddenly ‘Newark’ instead of ‘Rickmansworth’? And ‘Bloomingdales’ instead of ‘Marks & Spencer’? The fact that Rickmansworth is not within the continental United States doesn’t mean that it doesn’t exist! American audiences do not need to feel disturbed by the notion that places do exist outside the US or that people might suddenly refer to them in works of fiction.
https://news.lettersofnote.com/p/please-dont-let-anyone-amer...
I don’t know what the actual paper weight is but it looks in the “bible paper and cheap newsprint” range (~40-60gsm), which will probably rip as soon as a belt/orbital sander crosses the glue line into the looser leaves (and you have to cross the glue line to debind, and by nature that line isn’t normally straight, because glue does not melt evenly). You also destroy the spine, making it harder to identify issues at a glance.
A thermal binding machine would likely melt the glue in 45-90 seconds without those risks. And you might even be able to rebind after the scan with fresh glue strips using the same machine, assuming you don’t have to cut the cover wrap.
- Waste is high. To trim off a spine, you likely have to take more of the margin than you’d like (if you trim too close to the edge of a glued spine, the risk is higher that you may bludgeon the stack of pages under pressure instead of cutting it). Not great for double page spreads or Computer Shopper’s anaemic margins.
- Failure rate is non-zero. If you’re cutting a fresh print run, no big deal, you can reprint if you screw up. If you’re cutting rare magazines, you probably don’t want to lose many to slippage or mis-cuts.
- The blade needs regular sharpening, and it’s not something you can easily do in a home workshop, or that you probably want to do (huge heavy razor blades turn out to be quite dangerous).
What _might_ help Jason more is a “thermal binding machine”, designed to bind or debind a glued spine. He could (in theory) leave each mag in the debinder for a set time to heat the glue, then pry the pages free. Not a huge improvement over a hairdryer, but at least more hands-free, especially if people could donate or loan multiple machines.
“Driver side rear door” or “passenger side rear door” are pretty common, at least in the US and UK, where they mean the opposite.
“Nearside“ (passenger side nearest curb in a right-hand drive vehicle driving on the left) and “offside” (driver side furthest from curb) are also used in the UK.
Discovering that background noise is largely down to distance from mic plus gain makes me want to explore condenser mics again, paying more attention to polar patterns and learning how to set them up better somehow.
I preferred how I sounded with my condenser mics but struggled to reduce room noise without also reducing voice levels significantly, even when I was basically on top of the mic and hearing the proximity effect. I tried two condensers and both picked up ambient noise and road noise. I was researching noise gates/compressors at work when a colleague said, “just switch to a dynamic mic” and that ended up working, apparently for different reasons than I'd assumed — guessing a different pattern or gain…
1. Pick a dynamic mic (USB: Rode Podcaster, XLR: SM7B or Rode Procaster, USB+XLR: Rode MV7) over a condenser mic (Yeti) if your space isn't treated or quiet.
Dynamic mics generally reject room noise better than condenser mics and have a lower noise floor. Switching to a dynamic mic hugely reduced the physical sound treatment and audio adjustments I needed to get great sound.
2. Consider wired in-ear monitors for meetings. I like Shure's SE215 — they come in a clear colour that's pretty subtle. It completely removes audio feedback that some meeting apps are still not great at masking if you were using speakers before, and obviously prevents Bluetooth issues too.
> curl -sI https://formulae.brew.sh/api/formula.json | grep content-length => 19898457 (~19.9MB)
> curl -sI https://formulae.brew.sh/api/cask.json | grep content-length => 4023930 (~4MB)
But the JSON API has been around for a while so brew 4.0 just makes use of it by default.
Brew 3.3 added an off-by-default HOMEBREW_INSTALL_FROM_API bool to let you install from brew's JSON-based API instead of checking out the large (and slow) homebrew/core and homebrew/taps repos: https://formulae.brew.sh/docs/api/
Brew 4 just makes that the default and deprecates the env var (you can use HOMEBREW_NO_INSTALL_FROM_API=1 if you still want to check out the git repos for some reason).
They can and should! https://github.com/homebrew/brew#donations
Excellent! Thanks to the brew team for this — it was always frustrating to install something and have to wait for a full, slow update first.
It's a suggestion to correct course; to be self-aware; to get over your fears; to ensure you're pursuing things you find worthwhile and believe in; to accept that even for those things you will have days when you don't love them, but to consider a change if that feeling persists.
He goes on to say, “…all external expectations, all pride, all fear of embarrassment or failure — these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose”, which is less often quoted but just as important.
- Steve Jobs' 2005 Stanford Commencement Address
I recommend trying Swift/iOS/macOS development. No more editor or framework hopping or megatrees of unmaintained dependencies spewing dependabot hell. You will be using Xcode with Apple's APIs to build exciting things that often weren't possible with web tech alone. SwiftUI is easy to learn if you know React. The skills are in demand. The Swift/iOS communities are mature and supportive. Apple's hardware isn't going to become less interesting or less popular any time soon (Apple VR/AR products are on the horizon). Swift is a very nice language; much more fun to use than JS/TS.
Downsides are ecosystem lock-in, general lack of openness when you run into bugs with Apple's APIs, having Apple as a gatekeeper between you and your customers, and not being able to use latest Swift language features or APIs due to minimum OS versions, but if you're prepared for all of that it's a satisfying ecosystem to work in.
Others here are recommending backend, but having been in a similar position to you I get the feeling you might not love it. Large modern backend services are often just as over-engineered and prone to cargo-culting as frontend. You will likely spend more time writing YAML than you feel you have the emotional energy for. The cloud certificate courses people will send you on will feel like sales and marketing systems designed to lock you into building end-to-end solutions with a provider's stack; not satisfying education that promotes personal growth. You will probably have to be on-call, which is not as common for frontend or mobile/Swift devs. By all means explore it, but I'd be a little more careful on that path.
Good places to start are:
https://exercism.org/tracks/swift to learn Swift.
https://www.hackingwithswift.com/100/swiftui to learn SwiftUI.
For example, Feel Unique are pretty good for cosmetics:
https://eu.feelunique.com/brands/elemis?q=ELEMIS
https://eu.feelunique.com/help-centre/Feelunique+Order/Feelu...
https://www.apple.com/swift/playgrounds/ (I've had more success introducing programming with this than with any of the links below; it's a very compelling intro for those who already own an iPad/Mac, and the core concepts are generalisable to other languages/environments even if it's specific to Apple's APIs and hardware.)
~~~
For Python:
https://automatetheboringstuff.com
https://nostarch.com/big-book-small-python-projects
~~~
For JS:
https://eloquentjavascript.net (project-based and for beginners)
https://javascript30.com (not for total beginners or self-study, would need a friend/tutor)