quii

Well, the point I'm making is the technology choices we make, have an impact on the experience of the user, literally the 2nd paragraph.

OP here! The hx-boost hijacks links to make it feel like an SPA. I added it for fun NGL, removed it now though :)

OP here! The hx-boost hijacks links to make it feel like an SPA. I added it for fun NGL, removed it now though :)

Converting data to a HTML string is not a performance bottleneck you'll be worrying about. I wasn't worrying about it much in 2000, and you really shouldn't need to in 2023.

I think both are valid, as i mentioned in the article, for this particular case, the psuedo content-negotiation felt right

Thanks for taking the time to read the article :) A lot of the comments here seem to implying that I claim "htmx is the one hammer to solve all website needs", even when I explicitly say SPAs have their place in the article.

A hypermedia approach is the nice happy medium between a very static website and an SPA, not sure why so many people are close-minded about this possibility.

Hi, author here.

The project is open-source (https://github.com/quii/learn-go-with-tests) so there's a few options available to you.

In releases, you'll find PDFs and epubs, I'm pretty sure most epub readers will let you use a dark mode. Or you can just read the markdown files on GitHub, which also supports it.

Thanks for this, it's an important comment because it's linking to the master branch but I changed it to main a while ago so master is quite far behind.

I'm not sure how they're mutually exclusive. Also TDD is more of a _design_ technique than a testing technique. I've worked in languages with extremely expressive typesystems (like Scala) and I still practiced TDD

Just because something isn't skilled doesn't mean it's not important or doesn't bring value. The people who do these jobs deserve a decent wage and respect, not psuedo-wage-slavery

Well it's open source so just go take a look

https://github.com/quii/learn-go-with-tests

The point of "just writing enough to make the test pass" is to get you to the point where you have working software (proven by the test, even if the code is "bad")

This is the _only_ point where you can safely refactor, if your tests are failing how do you know you haven't broken something? So long as you keep things "green" you know you're ok

> The danger seems to be when you have to walk away from some code and you or whoever picks up your code doesn't know what you were up to.

Just don't do this. You're not "done" with the TDD cycle until you make it pass and have refactored.

I reflect this in my git usage too, roughly it goes

- Write a test -> Make it pass -> git commit -am "made it do something" -> refactor -> run tests (if i get in a mess, revert back to safety and try again) -> git add . -> git commit --amend --no-edit

> It seems "safer" to write tests that are going to stay broken until every little corner of everything works properly, even though this is less iterative.

The problem with this is how do you safely refactor when you have potentially dozens of tests failing?

A big point of this approach is it makes refactoring a continuous process and makes it easier because you have tests proving you haven't accidentally changed behaviour.

Hello, I wrote learn go with tests!

Your comment is exactly what I try to get across in the book but it's not always easy.

If you cant decide how you want something to look (as that's not always easy) just take a punt on something. Make sure it's a small decision and make something useful. Sure you might have to change it, but at least you'll be basing that on some real feedback.

Hoping there will be a thought leader who will show us how to conduct code review, review, review.

> I suppose techies don't have much need for social interaction

Sure....

A chapter zero is a great idea, just less exciting to write so the current one is what got priority ;)

I echo your sentiments, in the README.md in the root i talk about how writing tests is how I generally try and solidify knowledge.

I watched a few videos from a Coursera course called "learning how to learn" (or something like that) and it talked about how making your own analogies and examples helps you memorise stuff. To me, this style of learning works along those lines.

There's none really, other than my laziness.

I wanted to keep the various "versions" to hand as i developed it. I _could_ grab them from git but i found myself making little edits and copying and pasting, referring to them et al.

I am tempted to delete them and just leave the final version, will have a think

It absolutely will, in time.

Or if you're feeling brave, feel free to contribute :)

Thanks for the kind words. The reason I linked just the "hello-world" part is because it's the only part I feel is finished enough to share. (that being said I am literally making edits to it now).

It's a WIP project, there's a few other sections on integers and arrays but I hope to cover all the other Go features like channels, goroutines etc - all TDD'd

Once that's done I plan to do more involved examples, such as TDD-ing a basic webserver.

Is this as good as Play! framework?

OP here.

This is what I tried to address. "Too abstracted" is far too subjective. Is "map" on a collection too abstract?

Dont get me wrong, code can be too abstract. But dont mistake too abstract for the unfamiliar.

While I appreciate the sentiment when you set your goal as coding every day, that becomes your hammer to solve every problem.

The best example of this is your confguration project. I am amazed how many well-intentioned projects there are to do with configuration when really all you need is environment variables. No libraries, works everywhere, with every language and easy to understand.

http://12factor.net/

I do like the idea of Pact, I looked into it a few years ago. I guess what I wanted for this was a zero(ish) amount of code solution.

I think Pact and MJ have different advantages over each other.

Pact gives you more options but I think MJ is simpler to use and gives you options in terms of testing performance which is often neglected.

Ha, wow I had never seen this before and it is very similar.

I suppose the main difference is

- As far as I can see, Stubby doesn't provide CDCs-like functionality and MJ does. The idea of this is you can make sure your fake endpoints are valid. A common problem with mocks is that they go out of sync with a real server so your build is green, but it shouldn't be

- No flaky functionality

- Doesn't require any particular system dependencies (npm, maven or anything like that)

We haven't used the flakiness for builds, but just for performance tests. So we set up our service to point to a flaky MJ and the use siege to see how it handles it.

In one instance saw how certain scenarios meant we weren't releasing connections which then killed the app.

This is a project born of my frustration of making fake servers and CDCs over and over again as we break our monolith into tiny pieces.

I figured the requirements for both fake servers and CDCs in a lot of cases are the same. "Given a request, i want this response". So I thought, why not just define it once in configuration and be done with it. This stops the two things getting out of sync.

The wiki has lots of info as to how to use it and what the point of it is. Would appreciate any feedback, apart from mean things.

Boilerplate isn't a good thing, even if it's auto generated there is still overhead

Springer 2nd largest scientific publisher. London Office.

http://joinit.springer.com/

We primarily work with Scala and some other fancy databases like Cassandra and Marklogic. Dont worry too much if you dont have Scala experience, so long as you're clever and keen.

We're looking to fill a number of positions detailed on the website.

It's a cool idea, but I am struggling to understand why this is better than say BDD; which not only effectively documents what your code does but also verifies it does what it says it should do.

Just to note, I live in central London (as in Zone 1), on around £1500 a month quite comfortably. £2k a month is excessive