6 ms·

Part of the problem is that I'm not THAT good. I believe that there are a lot of things that can be fixed and/ or done better. And I'm fairly certain there are

Part of the problem is that I'm not THAT good. I believe that there are a lot of things that can be fixed and/ or done better. And I'm fairly certain there are certain programmers that could do that, unfortunately, I'm yet to be a programmer of that capability. I can't keep up with both the expected work and trying to setup CI (to the extent that would demonstrate its usefulness)

strlen 12y ago
FWIW You don't need to very good (or even write any code) to use travisci, it's very easy to do. You can start with just running basic compilation/lint checks: http://docs.travis-ci.com/user/getting-started/ http://docs.travis-ci.com/user/getting-started/ -- just compiling/linting the code (to check for missing libraries, files you forgot to add to git, syntax errors, etc...) is _already_ useful. E.g., if you have a python codebase and never you never run pychecker or pylint (or if you have a php codebase and never run php -c or if you have a Java project and never build it entirely until release day...) you may be missing something that can lead to hours of downtime 4-5 weeks down the line. If you're using a dynamically typed language I'd suggest very trivial (1-5 line) unit tests _just_ to test that you can instantiate the objects and catch basic type errors. If it's a web app, a simple script that starts a local instance and then make sures that retrieving "GET /" returns "200 OK" is again a huge improvement over _nothing_. Overall, my/tlb's recommendation remains: be in a position where good programmers can offer you good feedback and where you're pushed to improving your own capacity.
thomasvendetta 12y ago
> Part of the problem is that I'm not THAT good. Not with that attitude, you're not :)
Kaizyn 12y ago
The only way you're going to get approval for "improving things" is if you can do both of the following: 1. Build a sound business case that shows that there is return on effort for the startup, and 2. Build a proof of concept that shows HOW it can be done in your environment. If you can't do both, then it will be fairly difficult to sell your company on your ideas for process improvement.
Kaizyn 12y ago
Rather than worrying about setting up CI all at one go, what I would suggest you do is structure your personal development workflow around some form of automated testing - either test-driven development or by just frequently running an integration and/or unit test suite. Keep the test code in a separate git repo and start out simply: setup a git hook script to execute the test suite locally after every time you run 'git pull'. From there, just build up the cleverness of your testing apparatus as you have time. If you start finding defects in other team members' changes incidentally as part of your work practices, that will prove the method in a way little else could.
aye 12y ago
You're definitely that good. I hear you, and I know exactly how this feels. I've worked for two companies in the past year and a half, both with teams of ~5-10 developers, and nobody at either company was/is using any sort of automated tests. It's definitely frustrating -- not to mention lonely -- especially when you're immersed in a culture (hello HN) that's pimping a new test runner every two weeks. I like testing for one and a half reasons: to capture the software requirements, and to change the software easily when those requirements change. If you've got one test, that's better than zero. You don't have to set up your own Jenkins server -- Travis CI should do the trick nicely, and it's super easy to set up (although I know you're not supposed to say that kind of thing). Here's a thought: Could you persuade the CTO to let you add the tests as a submodule to the project repo?
- viredfox 12y ago
  None of the cloud CI would work for us: we have an inhouse hosted git server (the CTO does not trust open source, in general). So to do automated testing, I'd have to set up a Jenkins server on my own.
  - webmaven 12y ago
    That's strike two against him. Have you had the conversation with him about why he feels that way about open source? The attitude about cloud services is more understandable, though inconvenient. However, I think you may be laboring under a misapprehension: You don't need to have a CI server to run tests automatically, you can have a test suite running locally and trigger it with a pre-commit hook (so you can't actually commit if a test fails).

strlen 12y ago

FWIW You don't need to very good (or even write any code) to use travisci, it's very easy to do. You can start with just running basic compilation/lint checks: http://docs.travis-ci.com/user/getting-started/ http://docs.travis-ci.com/user/getting-started/ -- just compiling/linting the code (to check for missing libraries, files you forgot to add to git, syntax errors, etc...) is _already_ useful. E.g., if you have a python codebase and never you never run pychecker or pylint (or if you have a php codebase and never run php -c or if you have a Java project and never build it entirely until release day...) you may be missing something that can lead to hours of downtime 4-5 weeks down the line. If you're using a dynamically typed language I'd suggest very trivial (1-5 line) unit tests _just_ to test that you can instantiate the objects and catch basic type errors. If it's a web app, a simple script that starts a local instance and then make sures that retrieving "GET /" returns "200 OK" is again a huge improvement over _nothing_. Overall, my/tlb's recommendation remains: be in a position where good programmers can offer you good feedback and where you're pushed to improving your own capacity.

thomasvendetta 12y ago

> Part of the problem is that I'm not THAT good. Not with that attitude, you're not :)

Kaizyn 12y ago

The only way you're going to get approval for "improving things" is if you can do both of the following: 1. Build a sound business case that shows that there is return on effort for the startup, and 2. Build a proof of concept that shows HOW it can be done in your environment. If you can't do both, then it will be fairly difficult to sell your company on your ideas for process improvement.

Kaizyn 12y ago

Rather than worrying about setting up CI all at one go, what I would suggest you do is structure your personal development workflow around some form of automated testing - either test-driven development or by just frequently running an integration and/or unit test suite. Keep the test code in a separate git repo and start out simply: setup a git hook script to execute the test suite locally after every time you run 'git pull'. From there, just build up the cleverness of your testing apparatus as you have time. If you start finding defects in other team members' changes incidentally as part of your work practices, that will prove the method in a way little else could.

aye 12y ago

You're definitely that good. I hear you, and I know exactly how this feels. I've worked for two companies in the past year and a half, both with teams of ~5-10 developers, and nobody at either company was/is using any sort of automated tests. It's definitely frustrating -- not to mention lonely -- especially when you're immersed in a culture (hello HN) that's pimping a new test runner every two weeks. I like testing for one and a half reasons: to capture the software requirements, and to change the software easily when those requirements change. If you've got one test, that's better than zero. You don't have to set up your own Jenkins server -- Travis CI should do the trick nicely, and it's super easy to set up (although I know you're not supposed to say that kind of thing). Here's a thought: Could you persuade the CTO to let you add the tests as a submodule to the project repo?

viredfox 12y ago
None of the cloud CI would work for us: we have an inhouse hosted git server (the CTO does not trust open source, in general). So to do automated testing, I'd have to set up a Jenkins server on my own.
- webmaven 12y ago
  That's strike two against him. Have you had the conversation with him about why he feels that way about open source? The attitude about cloud services is more understandable, though inconvenient. However, I think you may be laboring under a misapprehension: You don't need to have a CI server to run tests automatically, you can have a test suite running locally and trigger it with a pre-commit hook (so you can't actually commit if a test fails).