hnthrowaway919
Re:IBM Closes Acquisition of Red Hat for $34B
on Tuesday July 09, 2019 @06:26PM (#20397340)
Interesting theory. Based on history and company performance (I don't have sources for this) Rometty's run as CEO has outlasted most expectations. This is definitely an interesting thought
Re:Git rebase in depth
on Tuesday May 14, 2019 @05:53PM (#19914226)
You certainly make some good points about the downsides of RTC. RTC's streams are often compared to git's branches because they're the closest construct, but they are definitely very different and have pretty minimal overlap, considering they're basically the parallel construct. IMO stashing changes was not bad (suspending change sets, I believe it was called), but perhaps I was mostly doing that within 1 stream and not between streams. I agree that code review was not great, though I'm not a _huge_ fan of GitHub's comment/PR review mechanism either. I'm not aware of code reviewing built in to git itself, though I could be totally missing it.
Re:Git rebase in depth
on Saturday May 11, 2019 @12:55PM (#19887114)
I know it's popular to shit on anything that isn't git these days, but you mentioned IBM CVS. I've used a couple of them, but primarily RTC (Rational Team Concert). I know that was an IBM acquisition and not a home-grown solution (what wasn't?). I personally prefer some features of RTC over how to do the equivalent in git. Namely, being able to move change sets (think commits) around freely, not having to deal with rebasing/merging into whatever branch you want to put it in/on. I also think there's something to be said for a CVS system that is built for teams that work together daily, compared to a system that's built for a "remote contributor" model.
That being said, I use git daily and find that I'm able to do everything I want and more, so I'm not looking to make a switch. Unfortunately, most people don't care to learn how to use git beyond "checkout, commit, push, call for help".
Re:Strangler pattern, a powerful simple concept to do refactoring
on Saturday February 09, 2019 @03:00PM (#19124256)
We opted for something similar when facing a technology pivot point in our front-end application. Instead of opting to re-write our entire application that had been built over the course of 3 years, we chose to integrate the replacement technology side-by-side with the original. This enabled us to add new features using the new technology as needed, along with allowing us to move old features over as we were able to. So far, I'm pretty happy with it. But, at some point, we will have to actively prioritize re-writing old content using the new technology, or else we'll be stuck with this frankenstein forever.