I was fascinated with Brooks' proposed "head surgeon" solution to the coordination problem for large projects - basically (and forgive me if my summary butchers this a bit), instead of having 1000 programmers on one repo arguing, you have a smaller number of vertically-integrated teams with a "head surgeon" at the top of each, and it is the head surgeons who have to coordinate. (Needless to say, the "head surgeon" has to know how to code pretty well and be significantly involved in the project rather than hovering at 20,000 feet...)
I guess most people would only like to be the "head surgeon" because of the implied status (and not really knowing what it is like to be e.g. Linus Torvalds). But personally, I wouldn't mind doing a specialized job like the tools programmer or language lawyer because these are still interesting jobs allowing good forward progress to be made.
If the load of tedious work like build systems is too much, and the best we can do is either load-balance it across the team or dump it on some schmuck, maybe that just means we should try harder to break up projects into smaller units so that process doesn't completely dominate them.
Fred Brooks wrote about the organizational complexity around larger projects in one of those books many cite but nobody reads, "The Mythical Man-Month." For example, he highlighted time spent on coordination among the n parties required to meet production targets. As you add more people, you might need anything up to n*n lines of communication; in other words, you have possibly an exponential growth in meetings. So he discussed some things IBM had tried, and some possible ways to mitigate that growth in coordination events.
Bear in mind that Brooks was mostly talking about his work on OS/360 at IBM. OS/360 wasn't a doghouse. IBM wasn't a small organization. His interest in reducing meetings wasn't caused by being anti-social, or having some antipathy toward management or PMs. It was caused by an interest in shipping products on time, which programmers are held accountable to do. (Consider that the next time you feel like accusing developers of being anti-social for wanting to get work done.)
Of course Brooks was discussing an idealized version of the problem, aimed at the essentials. But reality includes a lot of kinds of organizational bloat which really aren't necessary to software production goals, they're just hard to avoid in large organizations.
Say you are building a big house, and you can't wait for one person to finish it by herself, so you have to hire and manage and pay n workers and keep the pipelines full; so you need funding up front; long story short, you make a construction company.
Everything you're doing to scale up the organization encourages "leaks."
With more funding, more self-interested contention over where it goes, more fighting over who got it for the company, etc.
With more hiring, more competition among hiring managers to build empires underneath themselves.
With more management structure, more regulation and enforcement to justify and expand the management structure.
With more decisions, more attempts to influence or take credit for those decisions, and endless arguments down to useless bikeshedding. ('what are the right approaches, methods ...')
With more people, more internal social dynamics that become ends in themselves and change how the organization is steered and how resources are allocated in ways that often are actively harmful to the organization's stated goals.
Now relative to these real-world phenomena, does it make sense for software-producing organizations to see their chief risk as letting the programmers who know about code write the requested code as they know best how to do? Or to solve that "problem" with micromanagement, creating more and more barriers and distractions (and morale drains, and reasons to leave) for programmers?
I built a pretty comprehensive database of text editors and IDEs (with a ton of data on each one) and then exposed a subset of that data from this little one-page webapp, in order to help people find a tool worth learning for things like programming or system administration tasks. There's no commercial motive in any of this, it was just something I thought was needed.
What you see is not a curated list, in the sense that it contains a lot of stuff I would never use. But my eyeballs have been on everything in the database, a lot of manual work was involved.
Nor is it a listing of every editor which ever existed (for example, the platforms included are limited, especially I haven't included phone apps or e.g. MS-DOS editors; I don't include websites which purport to be text editors, and I try to avoid linking projects which their authors declared dead, and some which looked to me like possible scams or malware drops). And it doesn't include everything I gathered, just data for which I had reasonable coverage across editors (a lot of things you'd want to know are amazingly hard to find out for more than a few editors).
If you want programmatic access to the data, just use the JSON file, it isn't close to everything I have but it's enough if you find the app isn't giving you the kind of query power you want or something.
It looks like there is a lot of demand for --make/--remove options to vex so I will do those (and that should nearly approach the end of the new features I will do on vex).
Probably good to do some error checking on the arguments to mkvirtualenv and rmvirtualenv (sleepily hitting enter too early, etc.)
I did not know about invewrapper, thanks. pew is another decent name.
edit:
after looking at the doc, my impression is that invewrapper seems to follow virtualenvwrapper's design more closely with a large number of subcommands with names similar to virtualenvwrapper's, most of virtualenvwrapper's options and features (except hooks and maybe some of the project stuff). I would describe the options as "comprehensive."
I specifically wanted something with a dramatically simpler interface and feature set.
invewrapper also seems primarily or only intended to run a shell. I get personal use out of running arbitrary commands under vex as if it were sudo or something.
It is an improvement not to modify the current environment and couple tightly to specific shells either way, though.
I just discovered your project, so I haven't tried it yet, but since the approach seems similar, it should work just fine on Windows (maybe with some tweaks)... and you can just add the Powershell prompt to your docs, no need to envy it :)
I agree that pew is intended as a virtualenvwrapper replacement, obviously you can get something similar to `vex env cmd` with `pew in env cmd`...
Unfortunately I've neglected a little bit the project lately: the most serious thing I want to do is rewrite the test suite, to be able to run it on windows.
Since you mention PowerShell maybe you use it quite often? I'd like to get some feedback on Windows (I added Windows support out of completeness, but I seldom use that OS), since I don't know anyone who uses pew on windows :)
BTW, I discovered some new tools to manage environments in the last year:
pyenv (I actually already knew rbenv), modules[1] and I even started to use Nix
These have not the same scope, and in fact I appreciate the latter 2 idea of using the same system to manage dependencies and versions for all different kind of tools. I don't have an opinion yet on what's the correct way to do these things so, in the meanwhile, even tools that are python-specific (like ours) have a niche to fill
Downside is, ofc, that compared to just running something inside a virtualenv shell, vpython takes forever (up to 100ms-ish on my machine) to find the virtualenv, and set the correct env variables.
Most of my projects are long running though (webservers, number crunchers, etc), so the extra miliseconds it takes to load is really not that important.
Yes, there CAN be a way :) but would you do me a favor and write a spec for how you want that to work and jam that in a github issue? https://github.com/sashahart/vex/issues
Fully agreed, and the README for vex suggests this if you are worried about overhead from the wrapper especially for non-interactive purposes where you are repeatedly incurring python startup.
What is truly horrible is that I wrote my shell function, named it ave, thought it was a great name and then months later (edit: after I released vex) realized you had written a package named ave. Oh well.. :)
This is also worth checking out if you just want 'workon' type functionality without the fuss.
