Chemaclass

Keep agents, skills, rules, hooks, and MCP servers in one portable source. agnostic-ai writes each tool's native files and checks them for drift.

Phel has deep PHP interop built into the language: call any PHP function, instantiate classes, access globals via the php/ namespace from anywhere in your code.

We also ship a Phel nREPL: a bencode-over-TCP server (phel nrepl) compatible with editor tooling like Calva, CIDER, and Conjure. Connect your editor and evaluate Phel code against a running process directly.

Phel compiles a Clojure-flavoured Lisp to PHP. v0.36.0 ships exact rationals (1/2 literals), arbitrary-precision BigInteger with overflow auto-promotion, BigDecimal, first-class Vars (#'sym, alter-var-root, with-redefs, watches), and new value types (UUID, Queue, MapEntry). Plus REPL and test boot are notably faster.

Awesome!

Killing agility with excessive meetings

Let’s assume you already know what the agile manifesto is. Let’s consider that you apply most of the “extreme programming” values, principles, and practices. How can you work with other teams that aren’t agile?

Some thoughts about software quality among your team.

Some insights about how people can work better together.

Awesome!

That's fair enough. In such a case, I don't think pair-prog would be beneficial to apply every time for everything, certainly. However, I do think that small pair-prog timeboxed sessions might help developers to learn how to "think aloud" as a natural thing, where the goal is producing code while sharing knowledge at the same time.

There are different strategies for doing pair-prog. Developers could/should change roles and not always be the same drivers/navigators, for example.

I truly think pair-prog is a great practice for all developers who aim to work effectively within a team because it encourages communication between peers and a high-quality understanding of the business domain and technical knowledge.

I practice pair-prog not every-time for everything, but every-week with different team members and for different topics. It's up to the context and the task. The goal is to think loud and work together.

The whole point is to think loud together.

Yeah, I am totally with you on this one. Code style shouldn't be up for debate anymore. Nowadays we have plenty of linters and code style fixers that automates the whole code style of the project. That wasn't even the point I was trying to share on this article. PR and PP are on another level, focus on sharing knowledge rather than "code style", for sure :)

Yes, these are the main points :)

Totally. This is a relatively new concept since a year or so, but there are still people who doesn't use them. But I think a Draft-PR is a great opportunity to show the progress of your changes even if it's not finished yet.

Yes, that was what I meant. Thanks.