It's kind of amusing to me how the pendulum has swung, and we're now producing OS X-only developer software.
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.
+1 I was going to make a rather sarcastic comment that this is for "professional engineers", but is OS X only. Ubuntu on a VirtualBox on Windows for me.
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.
Disconnect is the management/config of VMs. We use vagrant, which means I have to check out the repo onto the drive to get the config...
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.
I for one do all sharing of files between guest and host using Dropbox and git. I've found that shared volumes have many problems like the one you cite, and treating them like two separate machines is usually the easiest way for me. If I had two physical machines with the same configuration as my guest/host, I would use network-based sync, so that's what I do on my Windows host (gaming pc at home, laptop that needs to be work friendly) with my Arch guest VM.
A fleet of appropriately-powered OS X boxes is substantially more expensive, and a fleet of Linux machines can't be operated efficiently by the rank-and-file.
The node ecosystem in general is a mess; I don't think you can blame that on the OS. I did a node project recently and I've still not been able to get it to run on two seemingly identical systems in the same way.
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.
I understand how such things occur, but that's not an ecosystem I want to be involved in. If ~ frequently lets in breaking changes (and it does) then nobody should be using it--the entire point of having versioned dependencies is to prevent breaking changes from entering your system.
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.
I tried npm shrinkwrap, but that only procrastinates on the problem: now instead of having to unravel a mess of dependencies on installation, you have to unravel a mess of dependencies whenever you want to upgrade a package. But now instead of having to solve a dependency problem that a bunch of other people have head to solve, you've created your own unique dependency problem. Not to mention that this completely bloats your installations.
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.
You're not the only oddball. Some of us work on Windows software and NEED the Windows box -- I also use too many Windows-only tools to make the jump to Mac.
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.
Yup. I love that OS X is an actual POSIX environment with easy access to the standard GNU toolchain, but the UX drives me absolutely up the wall. I think that Windows 10 is actually a much nicer desktop than OS X.
I'll have a new Mac box soon. I'll try it. Last time I checked there was no keyboard menu navigation, and you're the first person to tell me that there is, so it must not be widely known.
And Ctrl-F2 isn't exactly as discoverable as "hit Alt," so I'm not surprised.
Could someone comment on the main complications on developing something like this for both Mac and Linux? From my point of view, they is so much common ground, comparing to a Mac/Windows support, that I'd strive for an application to cover both! And that's not something that you could always decide after launching the first time, you need to have it in consideration during design...
The non-UI layer can be made 100% portable for sure (although in the GitUp case it's not really since I chose to write it in Obj-C for productivity reasons).
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.
I was under the impression Qt has been maintaining their Cocoa styling well. Has that changed? I haven't actually tested Qt software on OSX in about three years.
Even with the Cocoa styling, Qt based applications always seem to feel weird or out of place. Things like button placement, toolbars, things of that nature just don't "feel" right.
Thats the "weird" thing about Mac users: noticing that things "doesn't feel right" while completely missing that somebody has mangled their keyboard (where is home/end? pg up/pg dn? Waht are these extra arrow up left and arrow down right thingies on my keyboard that even long time Mac users cannot explain? (Feel free to explain it and I'll give you an upvote tomorrow morning if I remember : ) why is fn/ctrl switched on laptop but not on full keyboard?
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 :-/
I've got a full sized keyboard, I've got an home/end, a page up/page down, and I am wondering what you mean with extra arrow up left, and arrow down right?
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.
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.
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 size and location of buttons is off, the font rendering isn't as crisp, in some cases the buttons are swapped, developers tend to not follow the HIG and buttons are named differently from their OS X counter parts. The toolbar will use icons that don't fit in with the rest of OS X. Closing the primary window will sometimes take the whole application down with it, rather than just closing that particular pane of glass, right clicking on the icon sometimes won't display the windows that are open, drag and drop doesn't seem to work as well onto certain fields. Text sometimes renders wrong, or buttons are not made auto scale-able so you have text hanging off the end. Keystrokes you expect to work in text fields don't, no dictionary or auto-correct (although that was about two years ago when I last built a Qt based application for Windows/OS X).
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.
I have only looked at the movie, because I avoid tools that work with only one provider, however this app doesn't seem to use that many OS X controls, and quite a lot of custom drawing (branches, editor, etc).
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.
The GUI systems are utterly different, so, for a GUI tool like this, you'd have to write the front-end twice. I don't think OS X and Linux are especially closer to each other than either with Windows when you're in that department.
Absolutely true... not to mention, that cross-platform gui toolkits look alien somewhere/everywhere ... IT's never/rarely a great experience. That said.
There's no market for this sort of thing on Windows. The vast majority of development that happens on Windows takes place in either Visual Studio or Eclipse, and those developers prefer tools that integrate with their IDE rather than be standalone.
Maybe I'm odd but apart from working in VS, none of your statements hold true for me. I saw this and was like 'gimme gimme' only to find out it is OSX only. Quite a disappointment, especially given the recent stall (afaik) in SourceTree for Windows development, making me go back to the command line more and more again. I vastly prefer standalone tools for things like git because else I have to learn the builtin tools for each environment seperately. (I do use Git Diff Margin for VS [1] though - in fact it's becoming more and more indispensable to me which actually shows what a great tool it is)
At my previous workplace I tried to introduce something better for code versioning than tarballs or (more often than not) date suffixed folders. We used windows. CLI was just a total no no. Long story short, I tried bunch of GUI tools/plugins. Most tools were either too simple for anything beyond personal repo or graphical git command/switch selector.
Out of everything I tried SmartGit [1] stood out for its power (never had to use shell for about half a year) and still graspable simplicity. IIRC supports custom providers OOB.
Take a look at P4Merge for doing your merges/diffs - it's a very nice tool for merging. You don't need the entire P4 ecosystem, the merge tool is standalone.
hear hear! I've been using P4Merge for years since it's indeed very nice, also have it set as 'external difftool' in ST. Only disadavantge for me: line ending settings for the merged file are fixed, which is messy if you have repositories from different sources and/or different autocrlf settings
Not the person you asked the question of, but I have a few reasons:
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.
Main reason: I know it properly and hence can get pretty much anything done fast - faster than in the other 2 main OS'es. Although admittedly if I spent more time learning the others I could get things done there as fast or maybe faster as well.
Other reasons roughly ordered by priority:
- 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
We use git exclusively as a Windows-based shop and only 1 person uses the git integration with Visual Studio. Everyone else uses different solutions from tortoise to source tree to command line.
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"
I completely disagree, that is the kind of thinking that causes OSX only software to be written. I use Windows because that's what I grew up on and as a practical matter, I can buy the same equipment for half the price of a Mac. And I use all maner of "cool tools" like this as much as possible.
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)
1. The git integration in visual studio is incomplete (no ssh transport and no log rendering) so you have to complement it with an external tool. 2. Everything in a repo doesn't always belongs to a specific visual studio project.
I use this setup at work and I love it, the only thing I miss from my at-home linux setup is that I can't yank and paste directly to system clipboard with Windows. It's pretty sweet being able to yank in one buffer, flip over to another tmux window or pane and be able to paste seamlessly.
Yeah, I've just learned to use the Windows clipboard rather than buffers when I want to move stuff. Takes a bit of self-training, but it's not too bad now.
I have tried many flavors of Linux (I presume you mean desktops - I've run GNOME, KDE, Xfce, and a bunch of others), and I run Fedora (dev) and Ubuntu (HTPC) boxes at home. I've tinkered with switching fulltime to Linux desktops a number of times, and they're great 99% solutions, but the big showstoppers for me have been DRM'd video (Netflix, Amazon) and Steam (I'm a gamer, and 95% of my library doesn't run on Linux). With my setup, literally everything I care about runs without any real effort, and I don't sacrifice any dev power.
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.
Netflix now works under Chrome (not Chromium) as of...October? But Amazon has broken as of a few months before that - they switched the DRM they use and the old solutions are no longer valid. As far as I know, there is no workable solution for Amazon video on Linux anymore.
DRM-protected video in general is a giant pain in the ass that you don't really notice on the "blessed" platforms.
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.