But then, I'm an oddball who works on Windows as my shell with the real work happening on a headless Linux box via SSH and Samba for 99% of my development.
I've not been able to run node apps because executables end up getting stored in /node_modules/, but if that is on a windows share, no executable flag is stored.
Resolving the FS differences has always been the biggest pain for me using windows as the core OS.
- SSH to linux box with node on it
- Edit files via Samba/CIFS from windows box
- Run node/iojs via nvm for the project on linux
- ???
- PROFIT!
Sounds like if either have to nest VMs (is that even possible?), check out the repo twice. Or have a config that is very different on windows vs everyone else.
Oh well... Maybe win 10 will support a Linux compatible FS.
Are you using npm shrinkwrap?
npm shrinkwrap isn't a solution, it's a temporary hack and it makes things worse in the long run. Maybe you're only working on new projects, but I work on things that will have to be maintained.
Most mysteries come down to loose dependency declarations and semver stuffups, sometimes in combination. One of your deps' deps takes a ~ on one of its deps, that dep makes a breaking change and changes its version from 0.3.2 to 0.4.0… boom. Your fresh npm install on workstation #2 inhales the breaking change and doesn't work, but workstation #1 still works fine.
Fix: temporarily shrinkwrap from workstation #1 while you wait for the maintainer of the package with the ~ dep on the 0.* package to change to a ^ dep.
It's a machine. It's a lot more predictable than you think.
And tracking down these versions by hand is not a reasonable solution: some of these libraries pull down dozens of dependencies, each with their own dependencies, and it's not feasible to read the docs for every single package to find breaking changes.
> Fix: temporarily shrinkwrap from workstation #1 while you wait for the maintainer of the package with the ~ dep on the 0.* package to change to a ^ dep.
If I have to rewrite my entire install script to pull from a specific machine, the package system is useless, and I'll switch to a package system which is competently managed. What you're describing isn't a fix, it's a workaround.
In a larger sense, one of the main motivations for using other people's libraries is that libraries should "just work" and not need to be debugged and tested. That's not an assumption you can make in the node ecosystem. There are reasons you might want to test libraries, such as if you're writing crypto, or critical code on which people's lives depend. But the issues in node's ecosystem aren't that, they're just developers not following very basic development practices.
I stand by what I said: the node ecosystem is a mess. You've told me how to fix the node ecosystem's mess (which I already new) but the fact is, I have better things to do than constantly trying to fix other people's messes.
And what they do with Cmd-vs-Alt drives my fingers crazy, so I can't configure a Mac to be sane no matter what I try. And I use keyboard navigation to peruse menus, which OS X still hasn't implemented...the list goes on, and I stick with Windows.
And Ctrl-F2 isn't exactly as discoverable as "hit Alt," so I'm not surprised.
The UI layer is absolutely not portable: it's all low-level CoreGraphics code for the rendering, some CoreAnimation, and a ton of AppKit of course.
You could have a version written in a cross-platform UI toolkit or Java or what have you, but you could not possibly get close to the level or polish and native performance required for an app like this IMO.
That said the most annoying thing about Macs is how much I'd love to be able to use one, even at their current price point they seem a good offer to me, - but after three years of trying to either adapt me or the Mac I have given up :-/
3years ago this worked in some applications, in others you had to use the old ctrl-a/ctrl-e (which couldn't be combined with shift) or cmd or control-left/right/up/down.
Can't remember the details anymore, but I think I figured I needed at least three different combos for home/end back then.
Are you referring to the arrows that signify home/end/page up/page down on the older full size keyboards?
On the laptop keyboard the Fn key is the outer key, followed by ctrl, then alt/option and then command on my full size keyboard it is placed above the delete button and to the left of the "home" button. It's not switched.
Either way, you could replace your Mac keyboard with one of your standard Windows ones and everything will continue to work without issues. So if the keyboard layout is a bother, that is easily fixed. You'll just need to remember to hit the windows key to copy/paste rather than ctrl.
http://superuser.com/questions/46452/weird-symbols-for-key-c...
Seems you are right about home and end having gotten text descriptions.
I would have understood this remark a few years back. After having made such remarks for the last several years, and after having so much work done on UI/UX studies, let's become engineers again and be able to specify exactly what is not right.
The list goes on. It's the same sort of list that can be made with Java based applications. CyberDuck was one of the few applications that surprised me when I first started using it with how well it fit into OS X and I didn't realise that it was a Java application underneath the hood.
Ultimately it comes down to the application "feeling" out of place simply because it is out of place and wasn't built or designed with OS X in mind.
also a repository viewer is not latency sensitive.
Another example: if I do something in terminal, I don't wanna have to wait 5s for the Git client UI to refresh.
All these little half a second here, a few hundred ms here, add up, especially when you're trying to deal with thousands of commits.
- GTK+
- Qt
- wxWidgets
I'm not saying I have used them or they are easy to use - but crossplatform UI toolkits do exist.
- QT apps look alien on Mac.
- wxWidgets look alien everywhere.
There is no real X-platform UI toolkit.
I think this could be done in Qt with QML, the most difficult problems would probably be the list that popped up on the right at one point and getting the scrollbars right. When it comes to graphics, animation and custom drawing Qt is very powerful, the issues that do pop up are with native controls.
[1] https://visualstudiogallery.msdn.microsoft.com/cf49cf30-2ca6...
1) Hardware - cost is 1/2 Mac hardware, and I can upgrade cheaper as well. For example, my ultralight notebook came with 4GB Ram and a 128GB SSD. For ~$1000 - Mac equivalent was ~$1400 at the time, with no option to match the screen (1080p). Since then, I've upgraded but the SSD and Ram for another $300 - would have cost almost $700 to do the equivalent upgrade on the Mac and it would have been at the time of purchase.
2) I've grown up using Windows, CMD, batch files, etc. I know my way (a little) around the registry, services, etc. I'd have to relearn all of that on the Mac.
3) I hate all the program menus being at the top of the screen. I have a Mac on my desk at work...and it just drives me nuts. I'm sure I'd adapt, but it bugs me.
I could find more, but I've come to admit that I'm just a Windows user. If I need Linux or something, I just install a VM and go to town.
Fair enough, I get this, but I also found that if its your main professional tool, a few hundred either way isn't that big an issue.
2) I've grown up using Windows
I actually found that learning OSX stuff is quite simple if you just see it as a tool as opposed to a hobby.
3) I hate all the program menus being at the top of the screen.
Fair enough, guess that's personal preference.
Seems like you have fairly decent reasons for your choice, but I couldn't go back.
- it has Visual Studio. Sure I can get around using an editor and a Makefile - or XCode if I really must, but nothing so far beats what VS gives me (note: mostly C, C++, C#)
- hardware indeed: decent, all kinds of form factors, not too expensive (though same goes for unix of course)
- legacy reasons: some of the hardware/software I work with only runs on Windows
- for desktop it is actually on par, if not better, then any other alternatives out there
- tried an MBP for 3 years but had a pretty bad experience with overall so turned back to PC harware. Yeah I know a single case is not representative but it was just too much trouble esp. given the money spent on it
I think there's definitely a decent market for this sort of thing - I've had plenty of conversations locally that end with "Wow, I'm so glad to get away from Visual Studio for this"
Pissing on devs who use Windows may have been somewhat valid a few years ago, but times are changing, and people use it even if they aren't doing VS/Eclipse work. (FWIW, I hate Eclipse. However, Visual Studio is a very good IDE, if you like IDEs)
The really nice thing about my setup is that because all I need is an SSH client, I can work from my Chromebook, Macbook, or even my phone if I have to, and I have full access to my whole dev environment from anywhere. The biggest thing I've lost is the ability to attach to processes directly to debug them, but I just end up using terminal-level debugging or remote debugging facilities when they're available, and it works fine.
DRM-protected video in general is a giant pain in the ass that you don't really notice on the "blessed" platforms.