As a Node coder I used to avoid SASS since it was Ruby-based; now there's a fully-featured SASS parser in Node that keeps up with the specification. Bootstrap is moving from LESS to SASS, and they've always had their build step in Node.
There actually are things driving men out of the field. Look at how many head nurses are male. Men in nursing is a problem as well. But this isn't NurseNews, it's HackerNews.
Honestly, ES6 offers many of the advantages of Coffeescript (arrow functions, destructuring, etc.) and has the advantage of being a standard that will soon be natively understood by browsers, is fully backwards-compatible with ES5 (and therefore widely understood by developers), and also has a lot of IDE support and tooling available.
I agree with you, with one addition in GitFlow's favor--it standardizes how your team works. When you have multiple team members collaborating on a project, a poor standard is better than none at all.
> ...the history of a project managed using GitFlow for some time invariably starts to resemble a giant ball of spaghetti. Try to find out how the project progressed from something like this...
It's simple. Read backwards down the `develop` branch and read off the `feature/whatever` branches. Just because the graph isn't "pretty" doesn't mean it's useless.
In general, I'm starting to dislike "XXX considered harmful" articles. It seems to me like you can spout any opinion under a title of that format and generate lingering doubt, even if the article itself doesn't hold water. Not to generalize, of course--not all "XXX considered harmful" articles are harmful. They generally make at least some good points. I just think the title format feels kind of clickbaity at this point.
That said, kudos to the author for suggesting an alternative rather than just enumerating the shortcomings of GitFlow.
Articles like this are harmful. There are many of us successfully using gitflow without _any_ of the issues raised in the article.
And yet people who want to argue against the use of it simply because they don't want to learn something new now have a useful link to throw around as "proof" that a very successful strategy is "harmful". I guarantee in the next year I will have to go point by point and refute this damn article to some stubborn team lead or another senior dev.
Nobody should ever write an article outright bashing a strategy that they either don't fully understand or personally have not managed to integrate successfully in their own day-to-day. Bare minimum, if you're going to publish an article critical of a tool, don't name it so aggressively as to sound like it's fact rather than a single personal point of view.
Also this is a problem with Git not GitFlow. In Mercurial, for example, every commit is attached to a branch so it's very easy to follow where the changes happened.
HgFlow already exists and is actively developed: https://bitbucket.org/yujiewu/hgflow/wiki/Home. It even goes above and beyond GitFlow and adds generalized streams and sub-streams. I've never had to use those extra features, but the core model works well.
Mercurial branches are not meant to be used for short-lived feature branches, though. As "hg branch" puts it: "branches are permanent and global, did you want a bookmark?".
I'm not familiar with the gui git tools, preferring instead to work on the command line, but does whatever tool the author used to generate the graphs used on the web page support command line flags?
Specifically, git log --first-parent (--oneline --decorate) would look much better with the documented strategy. Instead of seeing all the commits in the branch, all that's shown is the merge commit. If you used the article's branch names, all you'd see is:
* Merge branch 'feature/SPA-138' into develop
* Merge branch 'feature/SPA-156' into develop
* Merge branch 'feature/SPA-136' into develop
If you actually used descriptive branch names, that would actually seem to be quite useful - see immediately see the features being added without seeing all the gritty details!
I feel like this could potentially work with "voting tokens" or something else that's not money. Maybe with some sort of crypto verification. You'd still have the scarcity that the system demands, but without the "inequality baggage" you'd start out with if the system were implemented with actual money.
If you implemented this system using money to buy votes, then you'd end up... well probably with something like the inequality situation we have today.
I think one feature of the system is that the accumulated funds are then distributed equally after the vote. With tokens, this would not be very useful, as if everybody gets the same amount tokens, there's no difference between getting one token and getting one million, tokens themselves have no value.
If voting tokens do not perish between votes, that leads to the similar inequalities if I abstain from voting for a number of cycles. If old tokens do expire, then it doesn't matter when everybody else gets the same - up to the limit of the quantization of tokens, how many tokens you have is less important than how much more tokens than your opponents you have . I.e. if there is a yes/no question, the important thing for you, if you favor "yes", it to have more tokens for "yes" than for "no", but how many tokens for each does not matter. In multilateral choice it's more complex but I think if you have enough tokens to not be limited to voting for one thing because you only have one token, it is again the same situation.
The whole point of the system is to railroad people into only voting for what really matters to them, by "saving up" their votes. I think this isn't a flaw but a feature.
I'd expect that there'd be a fairly large number of tokens so that quantization wouldn't come into play too much.
If you're already weeding through the code, why not invite the coworker to sit down next to you? In my experience, sometimes all someone needs is a pattern to adhere to, and once you show that pattern things might work out.
Of course, this is only good about 80% of the time. Sometimes people just don't get it.
