3 ms·

This is a very good point that I knew, but didn't express clearly in my OP and is exactly the sort of thing that I should be good at communicating. I definitely

This is a very good point that I knew, but didn't express clearly in my OP and is exactly the sort of thing that I should be good at communicating. I definitely would want to > Side projects probably don't need end to end testing. yea, with Selenium is a frustration that I generally avoid. I recently discovered https://www.cypress.io/ https://www.cypress.io/ which I'm just getting started with. On the general point of keeping it simple: I definitely agree that you shouldn't add tools you don't need. But automated testing is necessary self-care for software development.

brudgers 8y ago
My comments about testing were specifically triggered by Protractor which seemed to be a technology that was creating friction. More generally, testing is like any other engineering decision: subject to a cost benefit analysis not an end in and of itself. In the end, all that matters is the business logic...to the user. Something I sometimes see with people's side projects is a box full of tools thrown in the repository upfront and then little or no progress followed by abandonment. My take is that all that tooling for continuous integration and automated builds and so forth gets added because doing so is easier than solving the problem. Or more importantly building some prototypes and proofs of concepts and designs that fail. I suspect from observation and experience that all that tooling makes prototyping and spikes harder and more tedious due to configuration and complexity. Or to put it another way, setting up Selenium and Jenkins and whatnot right from the start looks like progress but isn't because there is nothing to test and no application to continuously deploy. Trying to avoid writing the app twice (or three times) often results in writing it zero times.
- afarrell 8y ago
  > In the end, all that matters is the business logic...to the user. If you're trying to build a side business and a side project to support that business, you are 100% correct. If you're trying to build a side project for your own learning, then the user is the developer, the primary interface is the codebase, and all that matters the developer experience. But you should start by understanding what developer experience you are trying to achieve and design from that. Trying to get yourself set up with a good red-green TDD loop? Adding Jenkins from the start is probably a mistake because it won't help you with your local dev environment. However, if you're starting out learning node then getting webpack configured will probably help you. But here too there is a trap: you want to avoid just collecting a list of tools you don't know and trying to assemble them into a dev environment all at once without guidence. I once spent a week trying to do that with gulp and it was nuts. This is one area where talking with someone who is experienced with the language's ecosystem will help you. At best, that person can point you to a recommended setup. The very least, that person can point out that some tool is 2 years old and doesn't play well with the others because it is out of date.

brudgers 8y ago

My comments about testing were specifically triggered by Protractor which seemed to be a technology that was creating friction. More generally, testing is like any other engineering decision: subject to a cost benefit analysis not an end in and of itself. In the end, all that matters is the business logic...to the user. Something I sometimes see with people's side projects is a box full of tools thrown in the repository upfront and then little or no progress followed by abandonment. My take is that all that tooling for continuous integration and automated builds and so forth gets added because doing so is easier than solving the problem. Or more importantly building some prototypes and proofs of concepts and designs that fail. I suspect from observation and experience that all that tooling makes prototyping and spikes harder and more tedious due to configuration and complexity. Or to put it another way, setting up Selenium and Jenkins and whatnot right from the start looks like progress but isn't because there is nothing to test and no application to continuously deploy. Trying to avoid writing the app twice (or three times) often results in writing it zero times.

afarrell 8y ago
> In the end, all that matters is the business logic...to the user. If you're trying to build a side business and a side project to support that business, you are 100% correct. If you're trying to build a side project for your own learning, then the user is the developer, the primary interface is the codebase, and all that matters the developer experience. But you should start by understanding what developer experience you are trying to achieve and design from that. Trying to get yourself set up with a good red-green TDD loop? Adding Jenkins from the start is probably a mistake because it won't help you with your local dev environment. However, if you're starting out learning node then getting webpack configured will probably help you. But here too there is a trap: you want to avoid just collecting a list of tools you don't know and trying to assemble them into a dev environment all at once without guidence. I once spent a week trying to do that with gulp and it was nuts. This is one area where talking with someone who is experienced with the language's ecosystem will help you. At best, that person can point you to a recommended setup. The very least, that person can point out that some tool is 2 years old and doesn't play well with the others because it is out of date.