julik

The animations were there, but they were frame-based with the number of frames carefully calculated to show UI state changes that were relevant. For example, when you would open a folder, there would be an animation showing a window rect animating from the folder icon into the window shape, but it would be very subtle - I remember it being 1 or 2 intermediate frames at most. It was enough to show how you get from "there" to "here" but not dizziingly egregious the way it became in Aqua.

Truth be told, I do have a suspicion that some folks (possibly - some folks close to Avie or other former NeXT seniors post-acquisition) have noticed that with dynamic loading, hard drive speed, and ubiquitous dynamic dispatch of ObjC OSX would just be extremely, extremely slow. So they probably conjured a scheme to show fancy animations to people and wooing everyone with visual effects to conceal that a bit. Looney town theory, I know, but I do wonder. Rhapsody was also perceptually very slow, and probably not for animations.

There were also quite a few tricks used all the way from the dithering/blitting optimizations on the early Macs. For example, if you can blit a dotted rect for a window being dragged instead of buffering the entire window, everything underneath, the shadow mask - and then doing the shadow compositing and the window compositing on every redraw - you can save a ton of cycles.

You could very well have do-wait-do-wait loops when custom text compositing or layout was involved and not thoroughly optimized - like in early versions of InDesign, for instance - but it was the exception rather than the rule.

I'd rather say the zenith was 8.1 which was not very widely used. 8.5 did add some nice gimmicks like the app switcher palette but for some reason it felt way slower than 8.1.

That is an interesting difference. Also, from what I know, the German signaling is configured in such a way that there always be sufficient braking distance between signals - including speed reductions, whereas if you look at how tightly the UK speed signs are placed it seems that they do not give any "warning", they state the fact - and you better be prepared.

Most European railways require a driver to have done some route familiarization for most routes, which tends to work fairly well. What does not work very well is that the UK has very patchy and antiquated train safety systems (AWS / TPWS are somewhat rudimentary and deployed - by far - not everywhere) and signaling. Even speed restrictions in the UK are placed very, very tightly and you better know them by heart because they didn't get placed with the idea that the driver must have sufficient time to reduce speed / react between where they get a warning signal and where the restriction comes into effect.

I suspect the move from public to private ownership did adversely affect the upgrades of those, as well as electrification on several key routes.

If I remember correctly they do not even have something as basic as an electronic coursebook - which became mandatory in Germany in the 90s already. And at least in NL if you have a set of routes in a certain direction / route set - drivers would get route familiarization both for the main routes and for the bypasses.

It does seem like it - with the addition of "one sentence per paragraph", which - outside of its LinkedIn format - feels like yelling. This format doesn't incite trust in the person advising (let alone the tone).

...by the passing of which the name of the game will be to find another vehicle for occluding reality and creating optics. Something to replace "bets" with "shaping" and "appetite", for example.

Connecting effort and outcome is hard as orgs get bigger, and a lot (a LOT) of those strategies have to do with optics and the "sponsors" being "on the wave" at the moment (trusted by owners/board). While it is not realistic to say "we do the work until it works and costs be damned" some tools for this are required, and I would say putting out a "bet horizon" of a year or a quarter is setting up some nice political battles in the future.

Interesting scoop!

* Get appointed as paid managers of a non-profit * Get advice from legal * Legal suggests removing long-term maintainers without liability contract the same way people get fired: immediately and instantly, and screw the consequences. "Open-source? Never heard of it. Protect your entity legally" * Instantly follow the advice of the lawyers to the letter.

Well done, well done.

I have used Base quite a bit in the past but switched to SQLitePro as Base was quite crash-happy (and I never managed to understand why). Might give it a second try since it seems the Base development is progressing, while SQLitePro is stagnating.

Slit scan photography is very cool. And bonus points for making trains the subject matter! Fun fact: back in the day some acquaintances of mine actually made some photos with a flatbed scanner, utilizing its moving head as a slit aperture - was a neat project.

No, you are not the only one

I have regretted releasing OSS under the umbrella of employers, and will likely not do so in the future. And while I never regretted releasing OSS as such, I did often have regrets that while I know the software was better than what was currently available in the market, me being bad at marketing meant that it would still not get any use.

I get the point, but on mobile devices especially it is vastly more pleasant to read a decently-formatted HTML email with a dash of responsive design, for font sizing for example. And showing some text and a "Download PDF" widget - to find a PDF with exactly the same content - can actually be infuriating, because you would expect that the PDF would contain something _in addition_ to the plain text.

I doubt I agree with this statement. If a junior is causing a full table scan by doing a where(), I will teach them how to detect it - and how to avoid doing this in the future. If the idea of how a joint does applications is that a junior should be able to work with the codebase without being able to generate a SQL query of arbitrary complexity - that is a valid desire, but let's not call it "a better architecture", let's call it "I want cheap labour from people I don't trust and don't want to teach".

Maybe if the generation of those queries is from templates and it is the concern at hand - a better approach is using a restricted templating system like Liquid where all possible queries are canned and pre-generated via specific template helpers, but I doubt this mandates a Repository still.

You mean the `def user_repository_provider` on the controller I believe?

That does not mirror my experience. What I did see a lot was either spinning wheels because multiple people had divergent ideas about how the complexity should be managed, or spinning wheels because people on the project did not want to work with Rails at all and just wanted a rewrite of everything in something else.

Complexity does not have to be an explosion, but it always will be if the team designs in a way that is not coherent - and coherence is hard to achieve.

That project is a treat - but it's effectively an FTP server, so most of its useful data will be in the files it hosts themselves. And it's deliberately built for being run off a single server. I had a similar project a long while ago which would "wrap" an FTP server with a WeTransfer-like web UI, and it also had no database - since none was needed.

"No build step for assets" is how I do my Rails apps these days if I can help it, luckily modern browsers allow for that to a great extent.

I love the series (and the "wat?" talk, of course - somewhat less the whole TypeScript desiderata of Ok, computer).

And yes, it is nicer to avoid expensive tests if you can help it. It has been my experience, however, that if you can use a slightly-more integrated test - which touches more parts of the system - you are likely to find more regressions and much quicker than if you subscribe to the notion of "testing one function with collaborators all around". It is academically very appealing, and your tests will be quite fast indeed - but they will be much harder to read and understand, and are always one "and_call_original" away from being useless.

As to decoupling from a framework in an ecosystem where, realistically, there is only one framework - and where, realistically, there are no deployment targets except for that framework - I don't believe this to be useful, sorry.

Yes, you can deploy your code into a cloud function (both AWS and GCP do Ruby cloud functions and you can get quite a bit of mileage out of it) but this is not an architecture you are likely to plan for - or need - until quite, quite late into the growth of a codebase. And even then - those runtimes have different constraints, so you may want to build a module which is accessible both from Rails and from such a cloud function.

What I don't like is the conversation of "you must decouple to decouple", which is not a way to advocate for something at all.

OP here - for what it's worth, this was the case on our application which was Rails 8. Some other gem or workflow may have been involved, but is highly unlikely.

So... Google Glass?

Undoubtedly! It's just that usually I see unit tests for such fixes, but not on projects in C/C++

I believe "transclusion" was the Angular 1.x vernacular for "slots", but don't quote me on that ;-)

Somehow this is not the first infrastructure OSS project written in C/C++ where I see two things being the case:

* There is some crucial counting/reference/condition code that contains a bug

* There is exactly 0 tests for that code

* A fix gets done, but no tests

Coming from dynlangs this does strike me as irresponsible. I believe the previous case I saw was the S3-compatibility header change in ceph, and similar with CORS configuration there too.

Is it so that experienced C developers assume the compiler will flag any bugs that matter?..

I know :-) Moreover - adding a pause inherent in batch processing allows you to have a last-line-of-defence for the intervention of a human operator / human assessment. It's a fine balance between "make the thing go fast" and "make sure the thing never allows fraud"

You can stop and ask that question. This quickly antagonizes the entire org - because that 57MB bundle is composed of sub-bundles owned by teams with their own incentives, and none of them are interested in doing a 404 page right - that they do not own, won't get promoted for and which doesn't show up in their KPIs.

From the desk opposite: This function name could have been an actual word (looking at you, Plan-9 inspired systems with a pervasive shortage of characters).

For most modern languages, something like an @internal annotation would work better. With compiled languages that need to conform to an ABI or export RPC definitions, there is merit to specifying what exactly must be exported (or must never be inlined), but even that could be tackled by an @internal or @nodoc or @private annotation - not a language construct.

See also https://steve-yegge.blogspot.com/2010/07/wikileaks-to-leak-5...

As a flicker-sensitive person: the sad part of it is that to do this properly you need to have your LEDs on a proper inverter, so for most scenarios getting rid of the flicker means "get expensive light fixtures _and_ rewire their supply _and_ you can't use your existing AC mains anymore, nor can you use switches". The PWM is a cheap way to do dimming given the AC input of the grid. And it will be especially prevalent when you do want LEDs but you don't want to "do anything special" to make them work well

Capitalism happened. My hope is on regulation - I don't see any other force being capable of prying these moat cans open.

Really curious how this improves the filesystem bridging situation (which with Docker Desktop was basically bouncing from "bad" to "worse" and back over the years). Or whether it changes it at all.