ddkto

The best part is that copilot commented on the PR saying that this doesn’t actually change the behaviour, creates inconsistency in the codebase and suggested reverting the change! (This comment seems to have been ignored…)

The configuration schema default was changed to "all", but the runtime fallback in extensions/git/src/repository.ts still calls config.get('addAICoAuthor', 'off'). This is now out of sync and can lead to unexpected behavior in contexts where the contributed configuration defaults aren't loaded (e.g., some tests/hosts), and it makes the intended default unclear. Update the runtime fallback to match the schema default (or omit the fallback so the contributed default is used).

The example usda data has a prim named `…_fbx` which suggests that maybe the original author uploaded an FBX file, and skechfab converted it to USD.

If sketchfab is converting the file format, it’s not so surprising that they get into the internals of the file.

My first language was also Logo, which I learned first in English at home, then in French at school. I wonder how many languages Logo was translated into?

Examples is French: https://www.tortue-logo.fr/fr/tortue-logo/exemples/

The academic / business divide is a great example of the correct model depending on what you want to do. The academic side wants to understand, the business side wants to take action.

For example, the Viable System Model[1] can capture a huge amount of nuance about how a team functions, but when you need to reorganize a disfunctional team, a simple org chart and concise role descriptions are much more effective.

[1] https://en.wikipedia.org/wiki/Viable_system_model

It’s hard to believe this is the first time I’ve seen Grasshopper on HN!

Just this morning, a colleague showed me a web app for building option exploration that he had vibe coded on Replit that wrapped around existing core logic in a Grasshopper script hosted in RhinoCompute [1].

The combination of visual programming, the tree data structure and Rhino’s geometry engine has made this the de facto standard for parametric design in architecture (sorry, Dynamo…)

[1] https://github.com/mcneel/compute.rhino3d

This is basically what the OP is doing - just think of this of the cursor rule as a summary (aka a compression) of the session.

I did something similar for a small vibe-coded app. After a few back and forths to develop the first working version, I asked the LLM summarize the requirements and state of the app so far. I saved that summary into a `description.md` file, and can include it in a fresh conversation.

I was using simonw's llm so adding a new feature or making a change looks like:

`llm -f description.md -f code.py "Instructions for making another change."`

Yes, but Bilbo does adopt him to make him his heir

Some more details: https://cloudnativegeo.org/blog/2025/02/geoparquet-2.0-going...

I also once got distracted by Spirographs. We got a Spirograph kit for our kids one Christmas, so I spent some time during the holidays writing a python package to draw them. Nothing fancy, just uses python’s built-in turtle graphics.

https://pypi.org/project/spiro/

The short answer is no, it is much more than that!

The long answer involves several hundreds of years of history…

Maple syrup is a minor luxury, easily substituted by other things like jam or honey.

Speaking as a Canadian, I suppose this is maybe technically true from an economic standpoint, but…we don’t even accept table syrup as a substitute, much less honey or jam.

(and I’ll bet IHOP serves table, not maple, syrup…)

Yeah, the flip side of there being 'less skilled' developers who operate at a higher level of abstraction is that it is easier to train more of them.

In absolute numbers, there are probably more people today who understand the fundamentals of computer hardware then there were 40 years ago, but it's a much smaller percentage of all the computing professionals.

Yes, absolutely - skills move from mainstream to niche, but are still required! For example, a much smaller proportion of the population knows how to farm today than 100 years ago, but it's still important :)

(And sometimes these mainstream, practical, everyday skills stick around in funny ways: https://www.hillelwayne.com/post/linked-lists/)

Not that we shouldn't use modern tools, but having a generation of developers unable to do anything outside their chosen layer of abstraction is a sad state of affairs.

Funnily enough my day job is writing software for structural engineers (and I am a licensed engineer). Your comments are absolutely on point. One of the most important discussions I have with senior engineers is "how will we train tomorrow’s engineers, now that the computer does so much work?"

40 years ago, the junior engineers were the calculators, using methods like moment distribution, portal frame, etc… today the computer does the calculation using the finite element method. Engineers coming straight out of school are plunged right into higher level work right away - the type of work that junior engineers a couple of generations ago might not have seen for 5-10 years.

My first career development discussion with a senior engineer was "Just work for 10-15 years, then you'll know what you need to be a good engineer."

I have discussed this under the theme of Generation Gap (https://www.youtube.com/watch?v=5gqz2AeqkaQ&t=147s, 2:27 - 8:58), and have a similar conclusion to you: what at first appears as a different generational approaches are actually different facets of a well-rounded, senior technical skill set. Maybe the kids are just learning things in a different order than we did?

Pat Gelsinger et al's discussion of the demise of the tall, thin designer is another interesting perspective (https://www.researchgate.net/profile/Avinoam-Kolodny/publica...)

Simon Wardley would like a word…in his model this is the natural order of things. As technology matures and standardized and a new generation of tools is built on top of new abstractions, and the details of that tech no longer need to be understood in order to use it.

Subjects and skills that were requisite basics a generation* ago, become advanced, under the hood topics for specialists. The next generation of people need different skills in the day to day.

This post is a great account of what that feels like from the inside, from the perspective of the newer generation learning these (now) ‘advanced’ topics.

(Funnily enough, I don’t (yet) see anyone commenting "real men write assembler" - a skill that has long ago moved from required by all developers to super-specialized and not particularly useful to most people.)

*I am using the word generation in the broadest sense as it relates to cycles of technology

It appears that the two controls are physically linked, but have a 'fuse' mechanism. When the two pilots apply lower forces to their controls, the forces are transferred between the controls and they 'fight' each other to move the sticks. After a certain threshold (50 lbs?), the two controls move independently.

In all cases, the flight computer works of the average of the two sticks. When they are in sync, this works great. In a situation like this one, where the pilots are pushing in opposite directions, the average will all of a sudden, be quite different from both controls.

Circular economics: The Phoenix bridge: Improving circularity of 3D-concrete-printed unreinforced masonry structures - https://block.arch.ethz.ch/brg/publications/1310

(Edit : link format)

the project owner is always, in the end, responsible for the success of a project

This is very relevant to large government construction projects in the public-private partnership model (aka Alternative Financing and Procurement). These go best when the project sponsor (the gov’t) thinks clearly about what risks the private partner is best places to manage and transfers those risks to them (e.g. managing lots of construction sub trades), while retaining the risks that they are best placed to manage.

It becomes very expensive when the sponsor just tries to throw all the risk over the fence. As the author says, this gets expensive - either through change order or sometimes even in the upfront cost. If you pitch a risk to someone who is badly placed to manage it or who cannot quantify it upfront, they will cover their risk with a big fee.

You can shuffle the risk, but you can’t make it go away.

Professional business people are familiar with different business models, and when to apply them.

For instance, hourly billing makes a lot of sense if the scope is vague - the client carries the scope risk.

Fixed price is amazing when the client has a specific, measurable problem that they don’t know how to fix (but you do). You can solve it cheaply, get paid waaay more than hourly and have a happy client.

Being a professional means having multiple tools in your toolbox and knowing how and when to use them. Drafting contracts is all about deciding how the risk will be shared - you need the right risk-sharing model for each situation.

(edit: spelling)

Property taxes are usually set as a fixed amount to be collected, and the tax % is back calculated. In practice, this means that the only thing that matters is the value of a property relative to the rest of the city.

exactly - Google is acting like a VC, not a company. A VC isn't too worried if a large percentage of their investments go under, so long a few make it big.

It's like Google has the worst of both worlds: the upper management has the detachment of a VC firm, and the product teams have the detachment of being incentivized to start something new. At least in an actual startup, the team is committed to success.

It is interesting to consider this from a Stage-Gate vs Lean Startup perspective. These two product development processes can be seen as antithetical, but if you read the original sources (Winning at New Products and The Lean Startup), you find that they are both trying to achieve the exact same thing: delivering successful new products to market at minimal cost.

The differences between the two processes is a function of their environment. If you are working in a company with separate functional departments and a strong, existing brand, you need a step by step process to align everyone and get customer insight before launch. Stage-Gate answers this need and products that get killed die before they are formally launched (thus protecting the brand).

If you are a small team doing everything with an unknown brand, the most reliable way to get market feedback earlier is to just put something on the market. The Lean Startup comes from this perspective - if there isn’t enough traction, kill the product and invent a new brand.

(Of course, these processes can be adapted to other environments, but these are their native soil, so to speak.)

Google seems to be managing its product initiative like startups: they incentivize new product launches, and don’t hesitate to kill products that are already on the market. Perhaps we are better off adjust our expectation of the google brand: it’s just a VC brand (like a16z), not a product brand.

As a Quebecer, all I can say is, join the club! For everyone shocked by this, it is much less extensive and onerous than the Quebec languages laws.

Very roughly speaking, similar rules apply to all companies operating in Quebec with 25 or more employees, not just public officials.

but when the video window pops up again, it's a different size than it was before. I usually have the video window expanded to half a screen (the other half is for taking notes). If I share the other monitor, the sequence is:

1. share monitor to Teams 2. click on the little window to make it big again 3. reposition the video window back to where it was before

It's not clear to me the value of steps 2 and 3...

Seismic magnitude and intensity are two different measures.

Magnitude measures the amount of energy released by the ground movement. It is a property of the earthquake and is independent of where the measurements are taken. When someone says 'a magnitude 7 EQ', this what they are referring to. Today, the Moment Magnitude scale is used, which is a better version of the Richter scale.[1]

Intensity is a measure of the effects of an earthquake in a particular location. Intensity is commonly assessed with the Modified Mercalli Intensity scale[2], which is a qualitative measure of how the shaking was felt and what damage was done. (As an aside, since it is qualitative, it is the starting point for assessing the size of historical earthquakes.)

[1] https://www.usgs.gov/faqs/moment-magnitude-richter-scale-wha...

[2] https://www.usgs.gov/media/images/earthquake-intensity-scale

Kill it with Fire, by Marianne Bellotti is an excellent resource on this question. She addresses the team dynamics, corporate politics and technical side of modernizing legacy systems.

https://www.penguinrandomhouse.com/books/667571/kill-it-with...

Yes - I work at Arup (https://www.arup.com/), a large engineering design and consultancy firm. The founder (Ove Arup) and original 7 partners “sold” their shares to a trust in the 60s or 70s (for something like 1 GBP, so they were effectively donated). The main difference between Arup and Patagonia seems to be that the beneficiaries of the Arup trust are Arup employees, while the Patagonia trust has other aims.

Ove Arup had a strong philosophy of design and how the business ought to be run, and the trust was set up to allow that view to continue to drive how we work. (https://www.arup.com/-/media/arup/files/publications/k/ove-a...)

I worked at a smaller firm previously that had a very similar ethos to Arup, but the original shareholders sold to a publicly held firm and it evaporated in short order.

The board that manages the trusts is mostly made up of folks who have spent much of their career in the firm, which helps to keep the trust from drifting too far from the mission. Obviously, there are changes with time, but we can make these changes for reasons other than next quarter’s financials.

(ps, if anyone is curious to see this from the inside, I am hiring devs! My burning need is C++ devs, but we are also hiring for skills all across the tech spectrum)

I suppose the technically correct term would be reinforced concrete bike

“The Japanese Building Code (BSLJ) explicitly requires that buildings withstand moderate earthquakes with almost no damage, while collapse prevention and life-safety is required for severe earthquakes. It is expected that a typical building will be subjected to several moderate earthquakes during their service life, while the likelihood of occurrence of a severe earthquake during the same period is rare.”

(Comparison of the Seismic Code Provisions of the National Building Code of Canada and the Building Standard Law of Japan, https://www.caee.ca/12CCEEpdf/192-oZfU-119.pdf)

A similar approach is used in California and other places under the name Performance-Based Design.

Epoxy coating is falling out of favour, as it has two downsides: 1) is has a weaker bond to the concrete, so you need longer bars to transfer the force, and 2) if it gets damaged (scratched or cut), the corrosion will concentrate at that location, and you are more likely to end up with a fully rusted-through bar, as opposed to a small amount of corrosion spread over the whole bar.

Reinforced concrete is much like clothing: a stitch in time saves nine. With regular cleaning and maintenance, it can last much longer than if you just let it deteriorate.