121–130 of 260 posts
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.
Earlier quoted context omitted.
Although the GPL allows authors to charge for software, it disposes of all legal copyright protections that make such charges practical. Charging for GPL software doesn't mean anyone will pay you, it just means that everyone will get the free builds from someone else, which is even less desirable than releasing free builds since you lose control of distribution. Look at Red Hat and CentOS for case in point.
You can always dual license, and sell the second, commercial-friendly license for a price. You need to be careful that you're the sole copyright holder though, so you need a strong contributor agreement.
I'd be interested in cases where people have made substantial money selling GPL software as if it were proprietary software; that is, where they are able to get the consumer to pay for the software after a short trial, in order to retain the privilege of using the software long-term. The GPL grants this privilege anyway, which is the problem. The consumer doesn't gain any value by exchanging their valuable money for something they already have (the right to use your software), so they don't do it.
I realize this is a pretty broad question, but what is it about Git that people find painful ? Could be Stockholm Syndrome on my part, but I have a pretty hard time understanding why someone can't spend a week getting up to speed with a tool they intend to use for years to come.
I rather like the visualisation that gitk gives me, though. I'll never use a GUI to manipulate the tree, but to visualise it, it's very useful.
I realize this is a pretty broad question, but what is it about Git that people find painful ? Could be Stockholm Syndrome on my part, but I have a pretty hard time understanding why someone can't spend a week getting up to speed with a tool they intend to use for years to come.
Yeah, I was coming here to post that Git is already painless. It's a tool you are intimately using if you're doing anything other than Hello World projects with your team; it doesn't seem too much to ask to actually learn how it works. And once you know it's painless. Edit: I was thinking about it a bit more and it's actually one of the least painful tools I have ever used on a computer...
There's something really satisfying about seeing a visual representation of my git repositories, but my overall impression is that I'm not going to get any productivity gains here. If you know what you're doing, CLI is just faster. I understand that it's aimed at more novice developers, but I think for those developers it's even more important to use the command line. Developers that get into the habit of using unnec…
This is quite true with other Git GUIs since they pretty much wrap the Git CLI and add a bunch of dialogs and whatnot, but GitUp was designed especially to avoid that. I'm a big user of the CLI myself, so the last thing I wanted was to build a Git client with a slower interaction model :)
Between the keyboard shortcuts and the fact it deals directly with the repo database, GitUp is actually faster than the CLI in a number of cases. Experienced Git users do notice it on Twitter and on the GitUp forums. One example from my workflow: just rebasing my work branch is instantaneous in GitUp while the Git CLT takes a couple seconds (the UX being as fast in both cases to perform the operation, so a net gain for sure).
YMMV of course and you can totally use GitUp for some operations and Git CLI for some others.
Earlier quoted context omitted.
+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.
How do you resolve 'executable' files in your VM? 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.
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.
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 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.
Earlier quoted context omitted.
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 possib…
Earlier quoted context omitted.
The Mac is a phenomenal platform to launch right now if you make software targeted at developers. There's huge growth in mobile development, and many mobile developers work on OS X. Not just iOS developers, I'm seeing lots of Android devlopers working on Macs too recently. And if you make a new tool, you should go where the young (in the sense of experience, not age) developers are. Experienced developers already hav…
>Experienced developers already have their workflows all set up and don't try new tools as often. Speak for yourself. I'm always trying new tools as they come available, and was thinking that GitUp would be a fun one to add to my toolset. And then I saw "Mac Only" and groaned. I don't own a Mac, and though I will likely buy one soon (for iOS dev reasons), it will always remain my ugly-stepchild dev box, that I own on…
I simply don't understand how so much weight gets thrown behind such a perverse walled garden from DEVELOPERS. We know far better than this and ObjC? Swift? Eat that right up. It's so unhealthy.
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.
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.
[1] https://visualstudiogallery.msdn.microsoft.com/cf49cf30-2ca6...