aslakhellesoy

Spade in French

This aligns 100% with the philospohy of Varar (https://varar.dev).

In-between all those ephemeral agent sessions, spec, plan and design files, there is something that survives. The src/*.md files.

With Varar you can link small parts (cells) of those Markdown files to your code, so they stay in sync. So you (and agents) can find out what your system does without reading 300 million lines of code.

Full disclaimer: I am the guy who wrote Cucumber - that most people here hate. I eventually lost my love for that tool myself, but I did miss the ability to keep docs and code in sync. Hence Varar - a tool like that with fewer (different?) warts, for the agentic area.

Very interesting. This reminds me a lot of the CRAP metric - a combination of cyclomatic complexity and code coverage.

It would be intersting to combine your «attention» metric with CRAP.

Even 15 years ago this was such a big problem that someone tried to start a rebellion: https://contrastrebellion.com/

They forgot to AI-label that Bender-sounding voiceover in the article…

Dude it's Depeche Mode

Shhh don’t let them know!

FYI: DocuSign’s moat/USP is trust, not software.

DocuSign customers buy trust.

I wonder how this compares to csvkit [1].

[1]: https://csvkit.readthedocs.io/

I’ve been using Mermerd [1] for years and never looked back. Simple, does one thing well.

It gets even better with elk layout - just prepend this frontmatter snippet to mermerd’s output:

    ---
    config:
      layout: elk
    ---

[1]: https://github.com/KarnerTh/mermerd

This sounds very similar to AWS CDK. How does it compare?

Excellent - thanks!

Excellent work!

Postgraphile uses a naming convention for postgres functions to extend the GraphQL schema [1].

Do you have any plans to support a similar mechanism in pg_graphql?

[1]: https://www.graphile.org/postgraphile/functions/

Congratulations on the launch - this sounds interesting.

I'm currently using Postgraphile[0], which uses Postgres' introspection API to discover the schema structure.

Would this still work with Hydra?

[0] https://www.graphile.org/postgraphile/

This is exactly why I love Example Mapping.

https://cucumber.io/blog/bdd/example-mapping-introduction/

Looks very interesting! Any plans to support DynamoDB/Scylla?

I created a tool (bumbailiff) that allows a team to accrue a limited amount of debt, for a limited period of time. Then it fails the build.

Read more about it here: https://cucumber.io/blog/bdd/todo-or-not-todo/

Browser-monkey is awesome, and for a real project I'd consider using it. I'd also use a virtual dom UI library like Vue, React, Hyperdom or similar.

For a teaching example I think it's essential to reduce the number of external libraries, or else it's too much to take in.

Also related: https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti...

You and I have very different opinions on the purpose of TDD. You're presuming it's a design technique - many do. For me, TDD is all about validating a design in a way that gives me faster and better feedback than if I were just coding. I design the code before I write the first test. In fact, my test is derived from the design.

First I sketch a rough implementation design on a napkin or whiteboard. I don't worry about making it perfect, just good enough to create an initial mental model, and perhaps discuss it with someone.

Then, I write a test to express how I would like to interact with a small area of an implementation of this design, typically by calling a function or method and expressing a desired outcome.

I use the feedback from the test to drive out some simple code that resembles the design I sketched. If at any point this becomes hard, I take that as a clue that my napkin design can be improved, so I go back and tweak it.

Then I start over again. This is a quick cycle, typically 10 minutes or so. I get constant feedback on my design as well as my implementation.

I don't design code with TDD. I design code exactly the same way people who don't to TDD do it. Through intuition and experience. This is a skill, not a process. I only write tests to validate my design (not my implementation). Of course, because they are tests, they automatically validate my code as well, but that is not why I am doing it. If I only cared about testing, I might as well write them last.

More often than not my designs are imperfect, but by doing TDD I always improve them significantly, with relatively little time and effort.

It's taken me 15 years to get decent at it, and I'm still learning new techniques and abandoning others. There are many tricks to be learned. I usually only TDD when I care about the design. Quite often I don't, and then I just hack. I'm simply making a choice between going very fast now or going reasonably fast in a year. I haven't found a way to do both yet.

I gave a presentation called Testable Software Architecture [1] a week ago with very similar recommendations to this article.

Decoupling is essential in order to have fast, maintainable tests that give you confidence to deploy continuously.

My two favourite techniques for this is a ports&adapters architecture where we plug in fake adapters for the majority of the tests. We then use contract tests to be confident that the fakes behave the same as the real services.

[1] https://skillsmatter.com/skillscasts/8567-testable-software-...

Slightly related, Cucumber will soon support a typed expression format called Cucumber Expressions: https://docs.cucumber.io/cucumber-expressions/

It's a standalone library and may well be used outside of Cucumber.

It's currently implemented in JavaScript, Java and Ruby.

How does Gravitational compare to Replicated (http://www.replicated.com)?

Those methods are not on Map, but on Set and Collection.

I picked up many great tips from Nathan Powell's "The Creative Professional's Guide to Better Proposals". Highly recommended.

http://www.amazon.co.uk/Creative-Professionals-Guide-Better-...

Disclaimer: I'm the creator of Cucumber.

The biggest problem with Cucumber is that most people trying it out don't understand what it is.

Cucumber is not a tool for testing software. It is a tool for testing people's understanding of how software (yet to be written) should behave.

Most bugs and delays caused by rework arise from misunderstandings, and this is the problem Cucumber aims to solve.

Cucumber is a tool that facilitates collaboration and software design (especially domain-driven design).

Here is how it works: You pop a story off your backlog and run a 20 min. meeting (Discovery Workshop) with business folks (BAs, POs, domain experts) and IT folks (developers, UX, testers if you have them).

You have a conversation about the story and come up with some concrete examples to describe the various acceptance criteria for your stories. Not in Cucumber's Gherkin language - just in plain conversational language.

For example: "The one where I upload a picture that is too big". Or: "The one where there are five taxis in range". These conversations act as catalysts to uncover subtle details where business and IT might have a different understanding.

Two things can happen at the end of this short meeting. You ask people to do a thumbs-up or thumbs-down vote on whether they understand everything that needs to be done, and whether the story is small enough. If enough people give a thumbs down, you send the story back for further analysis, maybe breaking it up into something smaller. If it's mostly thumbs-up, you're good to go.

After the 20 min. meeting you have 2-5 concrete examples that a developer (and perhaps a tester) can flesh out in more detail using Gherkin (Given-When-Then) to make it even more concrete. For example:

  Scenario: Close taxis with higher rating win 
    Given taxi A with rating 0.8 is 1400m from the customer
    And taxi B with 0.9 is 1500m from the customer
    When the customer requests a taxi
    Then taxi B should be assigned

The dev shows the example to the business person, who confirms that this is right (or wrong).

Now, the developer follows the regular TDD workflow, using the Scenario to guide the development of the core domain logic. The Cucumber scenario doesn't go through a UI using Selenium WebDriver or similar. The domain logic is implemented in such a way that external services, message queues and databases are stubbed out.

Lower level unit tests are still written, and there are far more of those than Cucumber Scenarios.

Cucumber is there to make sure you write the right code.

Unit testing tools are there to make sure you write the code right.

Using UI testing tools together with Cucumber? Please don't - or at least do it very sparingly. UI tests are expensive to maintain (the UI is more volatile than your core domain). They are slow (2-3 orders of magnitude slower than test talking directly to the domain logic). And finally - when they fail they don't tell you where the bug is.

The purpose of Cucumber is to bridge the communication gap between business and IT by providing a small set of essential scenarios to illustrate core behaviour of unwritten software. These scenarios do become regression tests, but their real value is to prevent defects by uncovering bad assumptions up-front. You end up with executable, living documentation accessible to everyone on the team. -Documentation of how the software should behave - and how it actually behaves.