mrsharpoblunto

While the venerable keyboard and a good text editor are sufficient for most forms of text manipulation, there are cases where more specific tasks call for more specific hardware solutions.

Love a good graphics writeup - I've been working on similar things for my procedural space/planet generator. The cool thing with atmospheric scattering is you can combine it with volumetric cloud rendering and get amazing sunsets & sky scenes

https://www.threads.com/@mrsharpoblunto/post/DVS4wfYiG8f?xmt... https://www.threads.com/@mrsharpoblunto/post/C6Vc-S1O9mX?xmt... https://www.threads.com/@mrsharpoblunto/post/C6apksDRa8q?xmt...

Just let people enjoy things, if you don’t like dark mode, don’t use it.

I’ve since done a bunch more on planetary cloud rendering, need to do a proper write up, but it’s a combination of volumetric noise, flow fields & atmospheric scattering.

https://x.com/mr_sharpoblunto/status/1653986502106570757

The author dismisses cubemaps pretty quickly, but imo it’s the simplest solution & it’s what I did when rendering dynamic gas giants on my own personal project a number of years back* . Using a cubemap doesn’t result in a 6x increase in memory usage, you’re just splitting the texture size from one large rectangular face into 6 smaller rectangular faces, but the total texture detail is the same. The nice part about a cubemap is you don’t have to worry about pole pinching at all + you can use a 3 or 4 dimensional noise function to easily create a seamless flow field for texture animation/distortion.

* https://www.junkship.net/News/2016/06/09/jupiter-jazz

The story of how I rediscovered the first real project I built after teaching myself to program - an RPG written in QBasic and how I got it playable again 25 years later.

Great job explaning the whole process! I've been building some similar stuff recently for my procedural space-exploration side project (https://www.threads.net/@mrsharpoblunto/post/CufzeNxt9Ol). I was planning to do a dev blog post writing a lot of the details up, but yours covers most of the tricks :)

A couple of extra things I ended up doing were:

1) Using a lower-res texture to modulate the high-res raymarched density, this gives you control over the overall macro shape of the clouds and allows you to transition between LOD better (i.e. as you move from ground level up to space you can lerp between the raymarched renderer & just rendering the low-res 2D texture without any jarring transition.

2) Using some atmospheric simulation to colorize the clouds for sunrise/sunset. To make this performant I had to build some lookup tables for the atmospheric density at given angles of the sun.

3) Altering the step size of the raymarch based on density, I took this from the Horizon Zero Dawn developers where they have a coarse raymarch and as soon as they get a dense enough sample they step back and switch to a higher res step until the density hits zero again.

There’s also OpenC1, which is an almost complete open source remake of Carmageddon. Jeff also has posted a ton of content around the internal workings and file formats etc on his dev blog - http://1amstudios.com/projects/openc1/.

We have a new entry for the Dunning-Kruger hall of fame right here.

Hi bgirard! I support the FB team that works on this - it's on the roadmap to open source hopefully H1 next year :) It's continued to find significant leaks in other parts of our infra too, so hopefully it will be equally helpful to others. Great to see others looking at memory tools now too - I'll definitely be checking Fuite out

Makes me wonder if you could effectively apply Chernoff faces (https://en.wikipedia.org/wiki/Chernoff_face) to make different hashes easier for humans to recognize. TLDR map parts of the hash to modify aspects of a face (position, size, orientation of eyes, ears etc.) and you can take advantage of all the in-built circuitry in the human brain which can identify very small differences in facial appearance.

The idea is explored a bit in Peter Watts novel Blindsight - not for hashes, but visualizing high dimensional multivariate data via clouds of tormented faces :)

I used the 4000 for a number of years, but found that it was causing problems in my right shoulder. The reason is the inclusion of a full numpad makes the keyboard so wide that your mouse hand has to sit really far to your right, causing your shoulder to be in a position of constant rotation and eventual strain. I eventually took a hacksaw to it to remove the numpad, which improved things - but it was the main reason I preferred the successor (sculpt) as the numpad is a separate detachable piece. These days I'm a split keyboard ergodox weirdo because it lets me put a trackpad in between the keyboard segments which means my shoulders can stay in a neutral position the whole time

Thats why you should also track other metrics when AB testing performance changes. During my time at IG, even small perf improvements almost always corresponded to stat-sig improvements in engagement metrics. 100ms is a pretty significant performance win, definitely not noise - the other thing is that those wins often scale by the quality of device & connection. So a 100ms win for a high end desktop on fiber internet could be multiple seconds for a low end mobile on 3G.

Why do you think its in the margin of error? I never mentioned the error bars on the statistic - We did an extensive AB test and it was a 3% stat-sig improvement

I added support for ES2017 bundles for compatible browsers for Instagram.com a couple of years ago - we saw a 5.7% reduction in the size of our core consumer JavaScript bundles when we removed all ES2017 transpiling plugins from our build. In testing we found that the end-to-end load times for the feed page improved by 3% for users who were served the ES2017 bundle compared with those who were not (more info here https://instagram-engineering.com/making-instagram-com-faste...)

Can we please stop overcomplicating the terminology around frontend architecture? The whole Isomorphism craze was bad enough - lets not make this stuff more complex than it needs to be and create confusion by over-loading existing terms like containers.

Whats being proposed here are dynamically linked shared libraries, they expose some functionality & also consume dependencies (that may be shared). Theres no need to be talking about containers, federation, orchestration etc...

Well you're loading the main feed page of instagram, you expect your feed photos to show right? We don't push random junk - its the content that the page needs to render something useful

Can't reveal the exact numbers, but yeah - a lot of people use IG on web :) Mobile web was always the big focus for us though - most people assume its just a desktop only web version, but actually the mobile web version is much more fully featured than the desktop version.

You're probably talking about the desktop web version I assume. If you check out the mobile web version its actually pretty close features wise, theres direct messaging, stories, creation with webgl filters,etc. The desktop version of these is admittedly lagging behind though - but I'm optimistic that desktop will get some more love in future :)

Might have been an earlier version we were testing before we built out the new posts pill, this feature went through several iterations.

Yeah, without constant focus on perf, things regress extremely quickly. We're building tight integration with perf budgets into our infra & dev workflows across both Instagram and Facebook, so that any perf regressions will be intentional tradeoffs with product experience rather than unfortunate accidents :)

(Author here) To clarify, we don't actually replace it automatically - we show a pill notification that new stories are available. You can either choose to tap it and see the new feed, or ignore it and continue with what you were doing

If global sunlight conditions change drastically, we're probably screwed regardless of how we're generating our power. Think crop failures, ecosystem collapse etc.

There will almost certainly be a UX impact in the form of performance though - the whole point of micro-frontends as I can see it is that it allows you to have different infra&dependencies in different parts of the UI. The only reason you'd want to do this is because you don't want to share the same infra&dependencies across the UI which inevitably leads to duplication of frontend infra.

e.g. if my whole app is React based, why do I need micro-frontends?, using them seems needlessly complex. It only seems relevant if for example I have a product where team A has a legacy jquery UI, team B wants to add a part of the UI built in Vue, and team C wants to build out some features using React - but in that case the user is now having to download 3x the JS infra code that they did before because none of the teams can agree on a shared stack.

Also this pattern would seem to make composability of the UI much more rigid and inflexible. In the IG example you mentioned, lets say stories and feed got built out using separate stacks with separate codebases and infra. Now lets say we want to add a saved stories unit to the profile page, or add some recent stories as a new unit in feed (real examples - I used to work at IG :)) If we were on a common stack like React, I could just re-use the React story reel component from the stories tray and drop it into the Profile page (& maybe tweak a few props). With a micro-frontend, I'd have to create a content area for the other team to put thier story unit, agree on what the expected interactions between the profile & story unit were going to be, agree on a contract etc. wait for the other team to adapt the story reel so it was usable in the new context, make sure they deploy the new version of thier story unit...

The only situation I can see a micro-frontend being beneficial is as a stopgap pattern while migrating legacy apps - it certainly doesn't seem like an ideal end-state to me.

While I can see some benefits in terms of deployment flexibility, this really seems like a case of prioritizing your organizational chart over the end user experience. Its already hard enough to optimize a large JavaScript SPA so that it runs well on mobile devices - are we really suggesting that its a good idea to ship a UI to users device containing N different versions of React, Angular, Redux etc. all built using different build tools/pipelines with the final UI cobbled together and have it give a comparable experience to a native application?

Micro services work on the backend because the its effectively hidden from the user - thier device hits and endpoint and gets a response. On the frontend its a different story, the users device has to download and execute all that duplicated code.

Dan Carlin’s Hardcore History podcast has a whole series on the Persian empire (King’s of King’s) that draws heavily from Herodotus. It gets quite meta in places with a lot of time dedicated to Herodotus and his storytelling style, and he ends up as one of the more fascinating characters in the story itself. Dan likens him to a modern day screenwriter with a sense for drama and emotion that previous historians lacked and that reading Herodotus vs earlier records is in some ways like the difference between the black and white silent film era and modern cinema.

Plus you lose all the benefits of linters, type checkers, & even things like syntax highlighting.

Awesome work! I noticed that you'd also done some work getting animated gifs displaying on the c64, seems like that would be a cool extra feature to have inline images display in the channel output, though I guess you'd have to do colorspace reduction & image resizing on the PI to avoid memory limitations on the c64 side.

I imagine the dealbreaker for most young couples expecting kids is the cost of renting a 3+ bedroom in SF more than any fear of raising kids in the city.

OP is not trying to fix things in a distributed manner. They're saying that the status quo is fine - the solutions are already here and that people aren't taking advantage of them. This is is not a constructive position because, the current status quo clearly doesn't work for many people, so there is scope for making changes and improvements.

Like any complex problem, there probably isn't a simple solution. Its not a binary issue of 'personal responsibility' vs 'central government', theres room for central, state & local governments as well as charities, communities, and companies to work together on this.