Earlier quoted context omitted.
Didn't stop NUKE, PHP Nuke, DotNetNuke, etc.
That brings me way back. Any love for PostNuke out there anymore?
Since we're going back in time, let's not forget WWIV and WWIVnet.
Disabling npm's progress bar yields a 2x npm install speed improvement
121–130 of 187 posts
Re: Disabling npm's progress bar yields a 2x npm install speed improvement
#122Another product bitten by the dark side of progress indicators.
One of the most often underestimated areas of product development, though certainly not among the most important underestimates.
Easy to underestimate its cost and impact. After all, it's just a progress indicator.
Re: Disabling npm's progress bar yields a 2x npm install speed improvement
#123Earlier quoted context omitted.
Please refrain from adding unhelpful comments to the issue.
How is this unhelpful exactly? It's a link to another discussion that readers might be interested in.
Because I can't amend this comment:
I misunderstood the commenter above me. My sincerest apologies. Have a nice day!
Re: Disabling npm's progress bar yields a 2x npm install speed improvement
#124Earlier quoted context omitted.
Normally, I am not a fan of replacing words in the search engine with computer science stuff (think AJAX), but I can accept computer words replacing words that symbolize violence.
Your results, even when logged out, are heavily biased towards your previous query genres. For instance, I'm not logged in, but am at home with an IP address that hasn't changed in over a year despite being leased. When I search Google for the term "Ruby", the entire first page is for the Ruby programing language. My father works with jewelry. Last week while visiting him, I did in fact search for the term "Ruby" on…
Google understands that Ruby can mean different things to different people, although I don't think it's gotten there with "ied" yet (and rightfully so, it's probably not searched for very often, except in the violent sense)
Re: Disabling npm's progress bar yields a 2x npm install speed improvement
#125Progress bar or not, npm has gotten extremely slow with v3, to the extent that someone is working on a performance-centered alternative called ied: http://gugel.io/ied/ installs are literally the #1 thing npm needs to do well, and I really hope we see some improvement soon.
Speed and support for multiple module development that have cross dependencies. Npm link sucks and updating and publishing downstream dependencies is a chore I wouldn't wish on my worst enemy.
Re: Disabling npm's progress bar yields a 2x npm install speed improvement
#126Earlier quoted context omitted.
I agree, but I'm curious what other build systems have a lock file? Ruby does through bundler, who else does this right? I can't think of any.
I try and push devs to do pip freeze > requirements.txt Which has a similar effect.
This is a good start, but it has issues. You probably don't want all of your locally installed packages in a requirements.txt file. Instead, they should be curated. I've been using pip-compile [0] for a while now (see the author's blog post [1] for a detailed explanation) and have become a big fan of it. With this model, you should enumerate only what your application uses directly and let pip-compile convert this list to a full version-locked requirements.txt. (Shameless plug: I also wrote a bit about why this is the best currently available option for specifying Python dependencies [2].)
[0] https://github.com/nvie/pip-tools#example-usage-for-pip-comp...
[1] http://nvie.com/posts/better-package-management/
[2] https://www.jonafato.com/2015/12/15/Rethinking-requirements-...
Re: Disabling npm's progress bar yields a 2x npm install speed improvement
#127Well-designed server platform.
Don't even get me started on the number of reasons why nodejs should not be running on servers, I'll be here all day. We're currently deploying a NodeJS app and we'll never do it again - the amount of problems with that ecosystem is quite amazing. As I tweeted earlier today "JS ppl tend to have marketing & UI/UX experience so JS crapcode gets popularised, becomes widespread, then we have to deal with the fallout".
Re: Disabling npm's progress bar yields a 2x npm install speed improvement
#128Earlier quoted context omitted.
I try and push devs to do pip freeze > requirements.txt Which has a similar effect.
This is a good start, but it has issues. You probably don't want all of your locally installed packages in a requirements.txt file. Instead, they should be curated. I've been using pip-compile [0] for a while now (see the author's blog post [1] for a detailed explanation) and have become a big fan of it. With this model, you should enumerate only what your application uses directly and let pip-compile convert this li…
If one uses virtualenv as a Pythonista should, then your keep point doesn't carry much weight.
That said, this looks cool and I'll check it out.
Re: Disabling npm's progress bar yields a 2x npm install speed improvement
#129Earlier quoted context omitted.
I'm not 100% sure from your comment, but are you suggesting that by default you should vet every version exactly and freeze it at the point you defined it? As someone writing a lot of ruby, "give me whatever" is analogous to "give me the latest unless I specify otherwise", which I consider to be a very good default. It keeps me up to date with security issues, and incompatibilities between libraries that the respecti…
> are you suggesting that by default you should vet every version exactly and freeze it at the point you defined it? Yes, this is the way that Guix and Leiningen and rebar3 and a bunch of other things work, and it is wonderful. Pulling in new code without you asking is a fine idea for something like apt-get where you have a huge team doing QA on the entire system working together before it even hits your repositories…
If you want to do this in ruby you can just specify a version manually. If you don't, you still get versions frozen by default with Gemfile.lock. It doesn't pull in anything automatically—by default you get no updates, you can choose to update a single dependency, or the whole thing if you want to verify it works on the latest (useful for libraries for instance). I'm not sure I see the downside.
FWIW I have been doing ruby for over a decade now, and I hold up Bundler as one of the great success stories of open source, and it is one of the reasons I hold Yehuda Katz in high regard, in that he was able to solve a really big problem in the community and hammer it into shape aggressively over a period of two years with a lot of doubters and naysayers (even Rubygems core was against Bundler for a long time), until it finally got so solid for so many use cases (libraries vs apps, private vs public, development vs deployment, etc, etc) where it solved nearly everyone's problems in such a solid way that everyone adopted it.
Re: Disabling npm's progress bar yields a 2x npm install speed improvement
#130It's all good, Laurie fixed it - https://twitter.com/seldo/status/692192238445711360
Link to relevant commit?