At the risk of getting downvoted myself, I wonder why all of your comments are getting downvoted. Is it such a terrible opinion that it doesn't even belong on HN? A lot of people turn off syntax highlighting. It can be legitimately distracting, and it messes up tooling.
Making vehement categorical statements about matters of taste is an old flamewar thing on programming message boards. I'm guessing the downvoters don't want that trope on HN. If so, I have to agree with them, because such discussion is basically never substantive.
Doing GUI calls is a notorious way to slow down apps. I sped up an app (major software from major large corporation) by a factor of 10x a few years back by removing GUI updates. What you have to do is create a thread that refreshes the GUI periodically and not let your main worker thread ever work on the GUI. This particular app was an Eclipse Plugin (a source control app) and the Eclipse SWT to update the console lo…
This strategy is also encouraged by best iOS development practices (main thread never works on GUI). Edit: 'main' as in the one doing the one doing the work, in the same spirit of the original post. In truth, the true main thread that runs in main() is where all the iOS GUI work happens. Apologies for the confusing wording.
Same was true of Java. Sun called it the "AWT event dispatch thread." Any process that does computation or blocks on IO should run in a separate thread and periodically post updates to the UI via an event queue.
Progress 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.
Even more important, npm doesn't reliably reproduce builds. Different runs of the same shrinkwrapped build could either fail or succeed -- which is odd given that builds should be deterministic. Additionally, shrinkwrap is also broken in the same way. This is the first time I've heard of ied, a little competition could go a long way!
same issue here.
this non-deterministic behavior is really fxxked up. there's one time that our building process suddenly begin to fail, spend a few hours on the issue, and it turned out to be one of the babel-core patch release is broken.
some of the very fundamental designs of npm is seriously wrong.
Doing GUI calls is a notorious way to slow down apps. I sped up an app (major software from major large corporation) by a factor of 10x a few years back by removing GUI updates. What you have to do is create a thread that refreshes the GUI periodically and not let your main worker thread ever work on the GUI. This particular app was an Eclipse Plugin (a source control app) and the Eclipse SWT to update the console lo…
When I gave the Nexus Mod Manager a try a little while ago, I wondered how it managed to take 18 hours to copy a few hundred files from one directory to another - on a SSD. Wouldn't be surprised if this was at least part of it.
Nexus Mod Manager is impressively bad. The interface is insanely laggy; select a mod, wait a second, list starts to refresh, wait a second, list finishes refreshing, wait a second, the mod info shows up. It's really easy to do things by mistake because of the lagginess (and probably just generally poor quality of programming). It has multithreaded downloads, but even these are messed up. Every time I tried them about 50% of the downloads got corrupted.
> Mix, Erlang's package manager (used by Phoenix / Elixir)
Slight nitpick: Mix is part of Elixir, I've never seen a (non-elixir) erlang project that use it. Don't think erlang has an equivalent officially blessed tool, but the most popular one is rebar / rebar3.
(While I'm nitpicking: mix and rebar are more build & dependency managers; mix uses hex for package management. I believe rebar3 can also use hex. In ruby terms, mix ~ bundler (among other things); hex ~ rubygems).
Someone with more UI development can comment here , but i always thought progress bars where more like a signal to the user that "something is being done" , and not a representation of how much is done and how much is left.
The whole point of a progressbar is to show work progress (as a fraction of total work). The issue is it's often difficult to map "work done" to a linear percentage, so either you do it on the cheap and your progressbar is just a souped-up spinner with no relation to wall-clock work time or you do lots of extra work to get more precise estimates but you end up taking more time overall.
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".
I'm genuinely interested. I've been using nodejs for hobby projects and scripts, so haven't seen too many issues. But I'd like to know how things are and what issues you've been seeing.
I have a project that's shrinkwrapped. I check out a new copy of the project and run `npm install`. My co-worker does the exact same thing, his fails, yet mine successfully builds. An install of a shrink-wrapped should be deterinistic, i.e. either succeed or fail, but not both.
From that doc page it sounds like that should be deterministic? Even without shrinkwrapping, a fresh install from package.json with empty node_modules should be deterministic. > The npm install command, when used exclusively to install packages from a package.json, will always produce the same tree. This is because install order from a package.json is always alphabetical. Same install order means that you will get th…
My understanding is that even when you fix your dependencies to exact versions, your dependencies probably haven't so without shrink-wrap you'll never know _exactly_ what gets installed.