10 ms·

I agree with you, I kicked off this workflow implementation phase with a simple bash script to see what parts need special knowledge and are ugly and not standa

by aalhour 11y ago

I agree with you, I kicked off this workflow implementation phase with a simple bash script to see what parts need special knowledge and are ugly and not standard and then pushed back to the team to fix them. Using a bash script to automate the development environment setup sounds good but I thought I might have missed something, hence the question. Do you think this is a good way to automate the boring workflow: * git clone project * make virtualenv * edit config file * npm install * bower install * exectue gulp build task * enable apache internal url for project * restart apache ?

dozzie 11y ago
> Using a bash script to automate the development environment setup sounds good [...] No, it doesn't sound good even remotely. This way you have method for setting up things that is very brittle, probably can't be run with confidence on a machine that was already set up, and this method is not suitable for production or test deployment, so you need to maintain two setup methods. You should look at how developers of various distributions (Debian, CentOS/Red Hat, Fedora, Ubuntu) package their software. All these foo-dev packages containing static libraries and headers, and foo packages with actual libraries and tools, either having their respective dependencies (e.g. foo-dev depending on gcc, so you'll get compiler by just running `apt-get install foo-dev'). Apache is not a good choice for development tool. It's not pretty to set up a second instance that runs without root privileges. I use uWSGI for those, I just use different communication protocols for production (FastCGI or uWSGI's own thing) and development (HTTP, to avoid setting up fully blown web server). Running `npm install' or `bower install' or `pip install' to just set up your environment is a method for a big stall in case of network outage (see this thread: https://news.ycombinator.com/item?id=10984775 https://news.ycombinator.com/item?id=10984775), unless you prepare local caches for all these repositories. You should have all the things in your local repository, either source control repository (your stuff) or packages repository (external dependencies).
- aalhour 11y ago
  Can you elaborate more on the last paragraph? Also what do you exactly refer to by package repository and how would installing pip, bower or npm modules become different?
  - dozzie 11y ago
    > Can you elaborate more on the last paragraph? There's not much to say. You depend on external services (and network connection) to write, build, and deploy locally developed things. All this fails badly when one of the services experiences problems. > Also what do you exactly refer to by package repository and how would installing pip, bower or npm modules become different? Dude, really? `apt-get' didn't give a hint? And all those modules are different from one, single package repository in that you won't install Python modules using npm, or JavaScript with pip, but you can do all those with `apt-get'. And you'll get repeatable process, since you control your package repository.
    - aalhour 11y ago
      I am either lacking some experience with apt-get or you're not clarifying your workflows enough. How would you clone a git repository, compile the SASS into CSS, uglify the javascript, and run a verticalization gulp task, after of course installing the frontend libraries through npm and bower all in apt-get? Oh no hold on, you won't use neither npm, nor bower to download the frontend deps... oh no, not even pip. Mind ``explaining like I'm 5``? :)
      - dozzie 11y ago
        Apparently you lack training in using your server system if you thought that binary packages system is to be used for running compilation. No, it is to be used to distribute, download, and install pre-compiled (e.g. minified) files. Also, to distribute build tools. For more explaination how package systems work, ask sysadmins in your company, as HN comments is not an appropriate medium for tutorial about them. If you don't have a sysadmin, well, you need to employ one anyway. And this is exactly what I meant when I said that programmers tend to avoid using sysadmins' tools.
        aalhour 11y ago
        Apparently you made me think of something else, I managed to do something similar to what you explained in a different workplace, but it seems that it needed to take forever to make you clarify your point. Anyway, thanks for coming back and writing, I really appreciate it.

by aalhour 11y ago

dozzie 11y ago

> Using a bash script to automate the development environment setup sounds good [...] No, it doesn't sound good even remotely. This way you have method for setting up things that is very brittle, probably can't be run with confidence on a machine that was already set up, and this method is not suitable for production or test deployment, so you need to maintain two setup methods. You should look at how developers of various distributions (Debian, CentOS/Red Hat, Fedora, Ubuntu) package their software. All these foo-dev packages containing static libraries and headers, and foo packages with actual libraries and tools, either having their respective dependencies (e.g. foo-dev depending on gcc, so you'll get compiler by just running `apt-get install foo-dev'). Apache is not a good choice for development tool. It's not pretty to set up a second instance that runs without root privileges. I use uWSGI for those, I just use different communication protocols for production (FastCGI or uWSGI's own thing) and development (HTTP, to avoid setting up fully blown web server). Running `npm install' or `bower install' or `pip install' to just set up your environment is a method for a big stall in case of network outage (see this thread: https://news.ycombinator.com/item?id=10984775 https://news.ycombinator.com/item?id=10984775), unless you prepare local caches for all these repositories. You should have all the things in your local repository, either source control repository (your stuff) or packages repository (external dependencies).

aalhour 11y ago
Can you elaborate more on the last paragraph? Also what do you exactly refer to by package repository and how would installing pip, bower or npm modules become different?
- dozzie 11y ago
  > Can you elaborate more on the last paragraph? There's not much to say. You depend on external services (and network connection) to write, build, and deploy locally developed things. All this fails badly when one of the services experiences problems. > Also what do you exactly refer to by package repository and how would installing pip, bower or npm modules become different? Dude, really? `apt-get' didn't give a hint? And all those modules are different from one, single package repository in that you won't install Python modules using npm, or JavaScript with pip, but you can do all those with `apt-get'. And you'll get repeatable process, since you control your package repository.
  - aalhour 11y ago
    I am either lacking some experience with apt-get or you're not clarifying your workflows enough. How would you clone a git repository, compile the SASS into CSS, uglify the javascript, and run a verticalization gulp task, after of course installing the frontend libraries through npm and bower all in apt-get? Oh no hold on, you won't use neither npm, nor bower to download the frontend deps... oh no, not even pip. Mind ``explaining like I'm 5``? :)
    - dozzie 11y ago
      Apparently you lack training in using your server system if you thought that binary packages system is to be used for running compilation. No, it is to be used to distribute, download, and install pre-compiled (e.g. minified) files. Also, to distribute build tools. For more explaination how package systems work, ask sysadmins in your company, as HN comments is not an appropriate medium for tutorial about them. If you don't have a sysadmin, well, you need to employ one anyway. And this is exactly what I meant when I said that programmers tend to avoid using sysadmins' tools.
      - aalhour 11y ago
        Apparently you made me think of something else, I managed to do something similar to what you explained in a different workplace, but it seems that it needed to take forever to make you clarify your point. Anyway, thanks for coming back and writing, I really appreciate it.