hitchstory

11 ms·

91.
by hitchstory 3y ago
>Theyve already planned out their deliverables for the next 12 months and will be held accountable for meeting them.
92.
by hitchstory 3y ago
It's not completely meaningless but it does tend to be something people recite and then never think about - even when they're inadvertently following it. It's performative - a bit like reciting the bible. Take I as an example
93.
by hitchstory 3y ago
It's become almost a cliche as an interview question. That's the main reason I've thought about it enough to be able to critique it. I think it's not necessarily a bad question assuming that the candidate can recite it
94.
by hitchstory 3y ago
This software also tends to be waterfalled to hell and back. Theyve already planned out their deliverables for the next 12 months and will be held accountable for meeting them. Your bugfix doesnt fit into that picture unless an exec treats
95.
by hitchstory 3y ago
The problem is xUnit style tests are really bad at this and make it tedious - which is why people gravitate to LLMs for writing them. LLMs on the surface look like they can relieve the pain of using bad abstractions - but theyre still a
96.
by hitchstory 3y ago
This pattern keeps repeating because the creators of an app think they need a configuration language (which some users do) and then when eventually other users end up needing an API or some feature the config language doesnt have. They both
97.
by hitchstory 3y ago
I took the same "docs are tests and tests are docs" approach with integration testing when I created this library: https://github.com/hitchdev/hitchstory I realized at some point that a test and a how-to guid
98.
by hitchstory 3y ago
I have created a project for easily writing this type of test with YAML: https://github.com/hitchdev/hitchstory I dont think that this type of task is really appropriate for an LLM though. It is better to use hard, pre
99.
by hitchstory 3y ago
>The other kind of test is what I call a "storybook test." Table tests are less useful here Storybook tests lend themselves well to forked tests. E.g. steps: ... - click: shopping basket variations: Empty basket:
100.
by hitchstory 3y ago
>What I mean is that a big refactor might take 9 months to do atomically whereas it could have been done in 3 months as a massive single PR. My experience with these 3 month-long PRs is that they have a tendency to not get finished. Then
101.
by hitchstory 3y ago
>Does anyone use this method in practice? I used a very similar method to upgrade Django from a very low version to a very high version where I would periodically: 1) Upgrade the dependencies. 2) Find something that was broken and fix it
102.
by hitchstory 3y ago
I dont know much about nested text im afraid.
103.
by hitchstory 3y ago
It is on my to do list to make a spec and a language independent test suite but both of these things take time.
104.
by hitchstory 3y ago
>by being extremely strict about indentation, both in terms of the parser & also community convention. YAML hasn't This is why I created StrictYAML. A lot of the pain of changing YAML goes away if you strictly type it with a sch
105.
by hitchstory 3y ago
One example was when they decided to test out the idea of sending particular kinds of price change notification emails to users. They created one checkbox on a form our users could click and set up a trigger to fire notify somebody in the P
106.
by hitchstory 3y ago
The escape hatch is where most low code products fall down, I think. This is because of market fit as you correctly point out, but not only that. It's also because knowing where the escape hatch and how to use it requires greater than
107.
by hitchstory 3y ago
I've actually just been creating step by step markdown docs with screenshots with this approach but I love your idea of embedding annotations in videos with JS popups and a proxy cursor. Assuming playwright allows for it, I will experi
108.
by hitchstory 3y ago
The most successful company I ever worked out figured out a way to perform and get high quality feedback on low cost user experiments with a quick turnaround. About 4/10 failed, 5/10 did ok and then with 1/10 they would absol
109.
by hitchstory 3y ago
>Docs should be tested - because you may be sure that everything is right, but without real users, like with any other product, you won't know for certain. Test it and test it again. If you want to automate this, see: https:/&
110.
by hitchstory 3y ago
In Germany they vary aluminium production rates in response to electricity supply (i.e. produce much less when it's less sunny and windy). They just dont turn it off completely, ever. There's probably a lot more low hanging electr
111.
by hitchstory 3y ago
This sounds like TDD but with the humans writing the test and the machine writing the code.
112.
by hitchstory 3y ago
For those interested in the concept of having guaranteed/permanently up-to-date documentation (with or without screenshots) I built this testing framework based upon autogenerating good how-to or reference docs from tests: https:&#x2F
113.
by hitchstory 3y ago
>The reasons you would choose to include a 'before-all' method will vary from case to case. Not really. I would always purge anything that would cause tests to share state. I wouldn't do it on a case by case basis. >Wha
114.
by hitchstory 3y ago
>... constructing a particular set of circumstances which will never occur in the real-world system. What do you find unlikely about a scenario where a test uses an app in a realistic way (e.g. with a browser) set up in a realistic conte
115.
by hitchstory 3y ago
Nice and clean in the context of an integration doesn't mean no state it just means no state outside of the context of that test. If I set up an integration test that sets up a database from scratch and tears it down and tests only t
116.
by hitchstory 3y ago
Unit tests have lower up front costs but higher ongoing costs. By their very nature they couple more to implementation details, so they will not give you clear confirmation when code is broken. Integration tests can give unclear signals whe
117.
by hitchstory 3y ago
It's readable, it just desperately needs type safety: https://github.com/crdoconnor/strictyaml When I read "gbq enabled: yes" I don't worry about whether it's a string or a boolean when reading
118.
by hitchstory 3y ago
I don't like gherkin. I think that it has awkward syntax, it lacks type safety, it's very verbose and doesn't have enough ability to abstract scenarios. Rather than being a source for generating the documentation it tries to
119.
by hitchstory 3y ago
I started doing documentation driven development a while back (with FOSS code) I wrote and I realized at some point that my tests and my how to docs were doing the same thing - one was just an easier to read version of the other. Moreover,
120.
by hitchstory 3y ago
JSON is also supposed to be human readable in a pinch.

More ›