I'd like to add that I use tools from fivefilters.org daily. (Mostly Push to Kindle) If the authors are on this thread, thank you so much for making these tools free to use and for such consistent uptime.
It's possible service development is happening very often, just not in the dev circles I spend time in. (web based startups)
Regarding writing interfaces for the service, that's fine too. It's just an easier way to integrate with a service. But there's a big difference between writing a service interface and a library that implements the service's functionality.
We do have plenty of open source services (e.g: Zookeeper, Redis, Kubernetes), but few product level like Stripe/Auth0. Yet there's a lot of duplicated effort in things like writing ecommerce/forum/blog/geolocation/social software. I wonder why we don't have more of these.
Please see the discussion at https://github.com/avh4/elm-format/issues/210. A fixed indent size is a feature, not a bug. Making a single tool that everyone uses is so nice. No need to mess around with .eslint files or the like.
It might have been fine if elm-format had chosen better defaults.
Go chose tabs over spaces which are configurable in your editor, so everyone wins. Elm has other awkward style choices, like 'comma-first', and excessive line-breaks in-and-around statements. If they had less obnoxious defaults, people might be less bothered about this issue.
And honestly, as a dev you work at a company for what, 3 months minimum. How hard is it to setup a .eslint file, vs. having to always write code in a style you don't enjoy.
Universal consistency of code format just isn't that important, consistency within a team or company is what matters, and you don't lose that by allowing configuration.
The interesting thing to me is that you highlight how priorities are different among different people/companies; to me, choice of indentation spacing is trivial. But to you and the sibling comment, it obviously is not. And that's the point: a developer should be respected to decide what is important for their work. In this case, we are talking about indentation flexibility. But this problem scales throughout on many other issues that I might find important but you do not. Most languages give developers more freedom, even if starting out with a consistent default that everyone can understand first.
Elm is an opinionated language. The framework comes built-in. The tooling comes built-in. A clever language designer once said "there is only one way to do it". Elm is that, but at the language level. Elm-Format is opinionated, and for people who love Elm, they also love that.
> It might have been fine if elm-format had chosen better defaults.
Subjective. This is a time old discussion. Please read the linked issue.
> Universal consistency of code format just isn't that important, consistency within a team or company is what matters, and you don't lose that by allowing configuration.
> You assume the OP is not actually using the language?
I'm making generalizations based on their statements -- the stats and anecdotal evidence tells us things about how the community at large.
> And yet you yourself said in another comment that you do not use the language.
Can you link that comment? I think you've gotten me confused with someone else -- I'm a very active member of the Elm community and write Elm as part of my day job and have done for over 2.5 years.
I'm not really making assumptions about their use, but more rather commenting on the feeling of the community as a whole. I basis this on my deep involvement and the stats that we have to hand. I know that Elm format is not considered an issue by a large majority of Elm users. In fact, I can only thing of a couple of people who dislike it. So while they might personally use Elm and dislike it, it is not representative of the community -- it's important not to spread FUD, as comments on HN often tend to. The people who are most vocal about elm-format being negative are those who have not actually used it outside of short trials.
I'm a little surprised to see it took this long to release what some teams consider an essential feature. I worked at a company where force-pushing master (by-accident) would put the master branch in lock down while someone could fix its history, which is easily solved by this feature.
We struggle with that last one all the time. Our sales team can't add issues with tags or assign them without write access to the repo. So they just have to dump them in issues and then engineers have to categorize them.
I don't think github was created with a shared repository model in mind. If you are forking which is the implied model this feature is relatively pointless because they offer you "pull only" from forks.
I'd love to see a source for this. I'm not trying to call bullshit on you or anything, but I can't imagine any hosted git implementation not at least accounting for branches. Forks are the "GitHub way," but branches are the "git way," no?
Sure I mean I can't give you a source per se but I think anyone that has been using github for a few years is familiar with the "forking" model( evidenced here with github giving steps for how to synchronize your forks - https://help.github.com/articles/syncing-a-fork/)
Branching is a separate concept and its certainly accounted for in the forking model. But we are talking about the process driven meta layer that github has stacked on top of git. Their original proposed workflow did not have a bunch of folks working out of the same shared repo instead(and this even extends to their enterprise model) every user that start working on a project would fork it. You'd make your changes and contribute them back to the authoritative repo as a "Pull Request". Branches model an evolutionary line of code, but a "Pull Request" models a change that you want to introduce typically into another repository. The implication here is that forks and branches are separate concepts that share some overlap. I often branch in my fork and contribute my change from my forked branch to be introduced into `master` in the authoritative repo without ever delivering the branch itself. Rather simply merging the changes into `master` as a discrete unit of work. Github's polite suggestion that you work this way is further evidenced by encouraging you to delete merged branches. I find this to be satisfactory but many people have personal hangups with deleting branches for reasons that are not entirely clear to me. This model allows me to sync my fork's version of "master" periodically with master in the repository of record(typically referred to as "upstream") and bring those changes into my branched work.
"Forks" and "Pull Requests" are not git concepts they are github concepts. Forking provided a nice little metaphor for locking down a repo because you couldn't create a disaster for anyone but yourself. Many git saavy organizations do not allow direct access to the authoritative repo instead only allowing "Pull only" access. This allows the authoritative repo to pull the changes that add value and reject those that do not without adding lots of cruft. This harkens the "Social Coding" aspect that github wanted to develop in their earlier days. With everyone contributing to everything forking left and right. Businesses wanted to piggy back of the toolchain they created but most folks weren't familiar with the idea of social coding and/or had needs that weren't addressed well by the social coding model. Github said no worries I think I can tailor this to a business. Which is why you have lots of fork based tools for private repos( organizations can take ownership of private forks, can force forks to be private, can set organizational ACLs on forks and private repos, etc, etc)
Some not so git/github saavy organizations work out of a shared repo for reasons that aren't very clear to me. Its usually a misinterpretation of who owns forks and/or the visibility of private code. I get a sense that github fought these ideas for a long time just saying "c'mon friends just use forks" and that this is their aim at a compromise.
>branches are the "git way," no?
This takes us to this. The answer is sort of. Really cloning is the git way. You clone a repo and synchronize it with other people's repos. Most organizations realize pretty quickly that some repo has to be the repository of record, but git doesn't care. To it a repo is a repo and you know what you are doing. Github just layers a little process on top of the "git way" turning a "clone" into a "fork" and add a little ceremony to the contribution process.
Wow, this is a really extensive answer, thank you. I really like the pull request model encouraged (enabled?) by GitHub -- it codifies the code review process, which is handy, especially when automated testing isn't up to par yet. That said, for dev teams, I'm not totally sold on the process.
>Some not so git/github saavy organizations work out of a shared repo for reasons that aren't very clear to me.
I've used the private GitHub services (private repos and Enterprise) with different companies for different projects, and the whole GH workflow seems to encourage something pretty clearly outside the realm of continuous integration. While the people I've worked with/for have almost always said we were working on building out the "CI/CD pipeline," the pull request workflow always ended up as a blocking function stuffed inside what would otherwise be called continuous integration. It's not continuous at all -- it places the onus of "merges" on people looking at stuff instead of trusting the tests, which means tests never get written and PRs are humongous.
Anyway, my point is that I like working out of shared repos because it makes it easier to just totally bypass the pull request workflow, though you're right, it can present the opportunity for rebase nightmare destruction derbies. For open source projects and big distributed things, pull requests are invaluable. But it seems kind of counterproductive in most of the scenarios in which I've seen it.
>and the whole GH workflow seems to encourage something pretty clearly outside the realm of continuous integration
The reason for this isn't clear to me. PRs are nothing but a `git merge` wrapped in a web ui that shows you a preview of the diff. Since those concepts are equivalent you have to then say "merging is pretty clearly outside the realm of continuous integration", but I'd say thats the concept that makes CI possible. By virtue of their equivalence PRs(if you choose to use them) can make CI possible too.
I want to be super clear about this using "Forking" and "Pull Requests" have zero limitations when it comes to CI/CD. In fact compared to working out of a shared repo there is only exactly one difference. Since your clone's master can diverge from authoritative master you have to periodically synchronize masters(thats that "sync your fork" link I put in the original post) I'll admit this is almost a justification for not using forks. Its annoying and tedious to explain to new git users.
>It's not continuous at all -- it places the onus of "merges" on people looking at stuff instead of trusting the tests
This sounds a bit off to me. Continuous integration is about getting good code into the delivery pipeline. Once that code is there you want to get it public as quick as possible. There is a relationship that describes the cost of bugs and bad design decisions as exponential given their proximity to getting into the customers hands. The tests will find regressions but won't stop a bad design or a design with a new bug, or a piece code without any tests at all. There are two things to note here catching things early is hugely cost effective and that code reviews are a vehicle for probing a completely different class of problems. The GH workflow is built around code reviews. This is because in the "Social Coding" model you want to make sure whatever rando is delivering code into your repo is respecting your style/development guide. Most organizations want this benefit as well. Do code reviews slow things down? ... yes. But I'd say thats a feature not a bug :) Are "pull requests" not "continuous". I don't understand exactly what you mean by that or what its value is. But it doesn't seem terribly useful by itself.
GitHub Enterprise has had the ability to deny force-push to master for a little over a year now. I think it might have had the ability to totally deny force-pushes before then, too. They seem to be steadily improving the granularity of the controls.
Well... actually the code contains a minimal 3D engine, it is not an illusion, you have the observer variable and could use it to navigate inside the map created in the initialization function. What is more 3D than that? :-)
It's simple, so you don't overload the visitor with information. But it does the 2 things I assume you want the best: What Tagmask does, and how to get started.
