Wait, you push straight to main?

> We added a rule — batch related changes, avoid rapid-fire pushes. It's in our CLAUDE.md (the governance file that all our AI agents follow):

> Avoid rapid-fire pushes to main — 11 pushes in 2h caused overlapping Kamal deploys with concurrent SQLite access.

Wait, you let _Claude_ push your e-commerce code straight to main which immediately results in a production deploy?

> * ABSOLUTELY DO NOT use `@deprecated` on anything unless you are explicitly asked to. Always fully refactor and delete old code as-needed instead of deprecating it

https://github.com/yokuze/aix-config/blob/f5094b5c5169261fae...

With the debugging capabilities it gives agents, I find I don’t miss Chrome DevTools so much.

Let me know if I'm missing something.

This is a nice reference, and some properties like `scrollbar-gutter` can be used for progressive enhancement.

However, many options listed will require some kind of fallback if `autoprefixer`/`postcss`/etc. doesn't cover it, and if you don't want to exclude a large fraction of your users.

It's reasonable in some cases to have both "new" and the old fallback code side-by-side until _your users's_ browser adoption stats indicate that you can delete the old fallback code without breaking a substantial number of users.

But the reality of using the new CSS hotness is that if the code is not supported by a % threshold that is much higher than many of these techniques show, it actually _increases_ your workload in the near term. You write new + the fallback + ensure that they don't interfere with each other.

P.S. Note the emphasis on _your users_ in the paragraph above. Global browser stats are fine as a basic reference, but your specific site/app's userbase demographics affect the actual percentages tremendously. That may mean you can use ALL of these new techniques today, or some, or none of them.

If your audience is primarily software developers, then after measuring you may find you can use these without a fallback. If it includes people in less wealthy communities or countries, or in countries with restricted access to mobile phone markets, you likely cannot.

Much of my attention goes to switching: Checking on results, restarting stopped tasks, fixing errors or providing hints, etc.

The context-switching takes a toll in the form of distraction and inefficiency.

What do you do that helps with this?

Comments URL: https://news.ycombinator.com/item?id=47018290

Points: 3

# Comments: 2

It’s a CLI tool and MCP server for creating discrete, versioned “libraries” of RAG-able content.

Under the hood, it uses an embedding model locally. It chunks your content and stores embeddings in SQLite. The search functionality uses vector + keyword search + a re-ranking model.

You can also point it at any GitHub repo and it will create a RAG DB out of it.

You can also use the MCP server to create and query the libraries.

Site: https://www.libragen.dev/

> “Apparently only one layer of the windshield was damaged, and there was no depressurization.”

And from the photos, it looks like it was the outer layer. So, where would the glass have come from?

Some? Yes. Many? No.

This blurb from one of the course pages (unintentionally) says it well:

> Because the point of computer science isn't to teach you a language. Or to teach you to code. Or to teach you to be a fullstack software engineer. Computer Science is a very narrowly-applied applied math with wide-ranging practical usage. But if you strip away all the qualifying language, it's math. Which means it has certain overarching rules that are completely, totally independent of your implementation language.

In short: the point of Computer Science courses is not to teach you to do the thing that you will be doing when employed at the company that pays you.

Another:

> if you want to read white papers you're going to want to read Lisp

Most jobs are not about reading or writing white papers. Almost all Computer Science courses are an _academic_ pursuit, not a practical one, and are taught as such.

If your goal is to _work_ in the industry, this is _a_ path, but it is a very inefficient one.

Depending on what work you are happy with, 80%+ of the content here will not contribute to your success.

Will learning the things taught in these courses exercise your problem-solving and other mental abilities? Yes. Will they teach you broadly-applicable principles that you could apply to your work? Hard _maybe_, depending on their teaching and on how well you learn and generalize. In any case, you may well end up doing work that utilizes little of this.

If you want to work in research, a math-or-fundamental-sciences-heavy field, or with teams of folks creating new programming languages or database engines for example, then certainly some of these courses (and more) are required.

But it’s worth warning potential learners that a full Computer Science education is _neither an efficient nor a necessary path to a job in the field_.

What is?

One example: There is much available and satisfying work in building user-facing applications like web and mobile apps.

If your goal is to do that kind of work, then it’s best to relentlessly focus on the things that you will actually be doing at your job: Building things.

Broadly speaking, employers pay you using the money that they are making (or hope to make) by solving problems and/or providing services using software/applications that you will help write. So practice writing it. Learn to build real things: Mobile, web, or desktop apps that do a thing that _you_ would want to pay for. Find courses that teach that. Practice it. Hit a wall, research and figure out how to overcome it. Repeat. Submit PR’s to open source projects, especially ones where experienced maintainers review your code. Learn from that feedback. Read their code and understand how it comes together to create the app you are using. Have LLM’s review your code, even, if no skilled human is available.

Practice working with other people. Learn how to write and communicate clearly and unambiguously.

Find and fix bugs in open-source codebases.

Embrace that working in the field means a commitment to non-stop, career-long learning.

Later, after you’ve freed up mental space by mastering the basic mechanics of programming, begin researching and applying the techniques and methods for writing code that other people find pleasant to read, interact with, and modify/extend.

Build something that you can show to prospective employers.

You will also learn many more things from the people you work with.

Many of the hard skills you will learn through doing _these_ things will directly transfer to the work you do, because _it is the work you will do._

Reading/watch list:

- Thought and Knowledge: An Introduction to Critical Thinking, by Diane F. Halpern

- Understanding Arguments: An Introduction to Informal Logic, by Walter Sinnott-Armstrong, Robert J. Fogelin

- Predictably Irrational, by Dan Ariely

- Evidence-based Software Engineering - http://knosof.co.uk/ESEUR/ESEUR.pdf

- A Philosophy of Software Design, by John Ousterhout

- https://www.coursera.org/learn/mindware

This is research for a book I'm writing on that topic.

Now seems like a good opportunity for Alexa skill development after the number of device sales over the holiday period.

I've read this CNET article: https://www.cnet.com/news/amazon-alexa-economy-echo-speaker-google-assistant-siri/ but am looking for more data.

Comments URL: https://news.ycombinator.com/item?id=16021955

Points: 1

# Comments: 0

Maybe? But who would want to use something like that? Good programming languages, like most useful tools, are specialized. They support modes of thinking that allow effective problem solving, each within its own domain. (Think Haskell vs Java).

In other words, programming languages are tools, and tools are useful because they are limited.